[Xenomai] Debian package build problems

[Xenomai] Debian package build problems

[John Morris]

Hi list,

I encountered a couple of problems building packages for 2.6.2 when
following the instructions to build from git in this link:

http://www.xenomai.org/index.php/Building_Debian_packages

First, the autoconf-generated 'configure' script is checked into git.
When git-buildpackage cleans up, it removes the configure script, and
then bombs out when it finds uncommitted changes (i.e. the configure
script removed) in the git tree.  I hacked around it by committing a
'git rm configure' in my own tree, but don't have a more sophisticated
fix (is the configure script committed in git for a reason?).

Second, the kernel patch copying code in debian/rules is out of date.
It expects to find "adeos-ipipe-*.patch" in the top-level directory.
Here's a patch to copy the ipipe-core patch files from the
ksrc/arch/<arch>/patches/ directory instead.

One more problem when building the 3.2.21 kernel (I'm building 3.5.3
now, but since I have the fix, may as well report it).  The ipipe-core
patch introduces a syntax error in arch/x86/kernel/apic/io_apic.c,
breaking compile.  Here's a second patch to fix that.

Thanks-

	John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xenomai-2.6.2-debian_rules_copy_kernel_patches.patch
Type: text/x-patch
Size: 1850 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130107/dff1e42e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xenomai-2.6.2-ipipe_core_3.2.21_io_apic.c_compile.patch
Type: text/x-patch
Size: 632 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130107/dff1e42e/attachment-0001.bin>

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/07/2013 10:55 AM, John Morris wrote:

> Hi list,


Hi,

> 
> I encountered a couple of problems building packages for 2.6.2 when
> following the instructions to build from git in this link:
> 
> http://www.xenomai.org/index.php/Building_Debian_packages
> 
> First, the autoconf-generated 'configure' script is checked into git.
> When git-buildpackage cleans up, it removes the configure script, and
> then bombs out when it finds uncommitted changes (i.e. the configure
> script removed) in the git tree.  I hacked around it by committing a
> 'git rm configure' in my own tree, but don't have a more sophisticated
> fix (is the configure script committed in git for a reason?).


The configure script is commited in the repository in order to allow
users to compile the xenomai package without the need to install the
correct version of the autotools.

> 
> Second, the kernel patch copying code in debian/rules is out of date.
> It expects to find "adeos-ipipe-*.patch" in the top-level directory.
> Here's a patch to copy the ipipe-core patch files from the
> ksrc/arch/<arch>/patches/ directory instead.
> 
> One more problem when building the 3.2.21 kernel (I'm building 3.5.3
> now, but since I have the fix, may as well report it).  The ipipe-core
> patch introduces a syntax error in arch/x86/kernel/apic/io_apic.c,
> breaking compile.  Here's a second patch to fix that.


These issues have been fixed in xenomai git, if you are interested by
xenomai packages (currently only on the amd64 architectures) see:
http://www.xenomai.org/pipermail/xenomai/2013-January/027252.html

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Debian package build problems

[John Morris]

Hi Gilles,
On 01/07/2013 04:43 PM, Gilles Chanteperdrix wrote:
> On 01/07/2013 10:55 AM, John Morris wrote:
>> I encountered a couple of problems building packages for 2.6.2 when
>> following the instructions to build from git in this link:
>>
>> http://www.xenomai.org/index.php/Building_Debian_packages
>>
>> First, the autoconf-generated 'configure' script is checked into git.
>> When git-buildpackage cleans up, it removes the configure script, and
>> then bombs out when it finds uncommitted changes (i.e. the configure
>> script removed) in the git tree.  I hacked around it by committing a
>> 'git rm configure' in my own tree, but don't have a more sophisticated
>> fix (is the configure script committed in git for a reason?).
> 
> The configure script is commited in the repository in order to allow
> users to compile the xenomai package without the need to install the
> correct version of the autotools.

I suspected that was the reason.  To work around the problem, one may
add '--git-ignore-new' to the git-buildpackage command line.

>> Second, the kernel patch copying code in debian/rules is out of date.
>> It expects to find "adeos-ipipe-*.patch" in the top-level directory.
>> Here's a patch to copy the ipipe-core patch files from the
>> ksrc/arch/<arch>/patches/ directory instead.
>>
>> One more problem when building the 3.2.21 kernel (I'm building 3.5.3
>> now, but since I have the fix, may as well report it).  The ipipe-core
>> patch introduces a syntax error in arch/x86/kernel/apic/io_apic.c,
>> breaking compile.  Here's a second patch to fix that.
> 
> These issues have been fixed in xenomai git, 

The master branch does indeed work, great!  I needed another small
addition to the git-buildpackage command line to fix the tarball
creation breaking:  '--git-upstream-branch=master
--git-upstream-tree=branch'.

> if you are interested by
> xenomai packages (currently only on the amd64 architectures) see:
> http://www.xenomai.org/pipermail/xenomai/2013-January/027252.html

Yes, I am interested in xenomai packages, thank you!  I'm working on the
project to add new RT systems to LinuxCNC (you might know Michael
Haberler, who wrote the Xenomai ports).  Now that we have a version
ready for testing, we find that the community is having trouble building
working kernels.  They all run Debian-like distros, the only ones
supported by LinuxCNC, so despite having never used Debian/Ubuntu, I
have been busy writing instructions for creating Ubuntu packages.  Next
step is to create a package repo to make it even easier.

The most difficult part has been to create a kernel config that works on
everybody's hardware.  My approach to solving that problem is to create
a well-documented, minimal set of configuration changes that may be
applied to stock distro kernels.  My results have been tested on EL6,
x86_64 (not Deb or 32-bit yet), and the config files can be seen here:

https://github.com/zultron/kernel-tools/tree/master/configs

The community mostly seems to run 32-bit machines, so your repo doesn't
satisfy all their needs yet.  :)  There will soon be a BeagleBone port,
too, an arch I haven't begun to tackle yet.

It seems terrible to duplicate this effort, so let me know if there's
anything I can do to help.  I can also supply packages for EL6 (my own
most familiar distro).

	John

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/08/2013 09:37 AM, John Morris wrote:

> Hi Gilles,
> On 01/07/2013 04:43 PM, Gilles Chanteperdrix wrote:
>> On 01/07/2013 10:55 AM, John Morris wrote:
>>> I encountered a couple of problems building packages for 2.6.2 when
>>> following the instructions to build from git in this link:
>>>
>>> http://www.xenomai.org/index.php/Building_Debian_packages
>>>
>>> First, the autoconf-generated 'configure' script is checked into git.
>>> When git-buildpackage cleans up, it removes the configure script, and
>>> then bombs out when it finds uncommitted changes (i.e. the configure
>>> script removed) in the git tree.  I hacked around it by committing a
>>> 'git rm configure' in my own tree, but don't have a more sophisticated
>>> fix (is the configure script committed in git for a reason?).
>>
>> The configure script is commited in the repository in order to allow
>> users to compile the xenomai package without the need to install the
>> correct version of the autotools.
> 
> I suspected that was the reason.  To work around the problem, one may
> add '--git-ignore-new' to the git-buildpackage command line.
> 
>>> Second, the kernel patch copying code in debian/rules is out of date.
>>> It expects to find "adeos-ipipe-*.patch" in the top-level directory.
>>> Here's a patch to copy the ipipe-core patch files from the
>>> ksrc/arch/<arch>/patches/ directory instead.
>>>
>>> One more problem when building the 3.2.21 kernel (I'm building 3.5.3
>>> now, but since I have the fix, may as well report it).  The ipipe-core
>>> patch introduces a syntax error in arch/x86/kernel/apic/io_apic.c,
>>> breaking compile.  Here's a second patch to fix that.
>>
>> These issues have been fixed in xenomai git, 
> 
> The master branch does indeed work, great!  I needed another small
> addition to the git-buildpackage command line to fix the tarball
> creation breaking:  '--git-upstream-branch=master
> --git-upstream-tree=branch'.
> 
>> if you are interested by
>> xenomai packages (currently only on the amd64 architectures) see:
>> http://www.xenomai.org/pipermail/xenomai/2013-January/027252.html
> 
> Yes, I am interested in xenomai packages, thank you!  I'm working on the
> project to add new RT systems to LinuxCNC (you might know Michael
> Haberler, who wrote the Xenomai ports).  Now that we have a version
> ready for testing, we find that the community is having trouble building
> working kernels.  They all run Debian-like distros, the only ones
> supported by LinuxCNC, so despite having never used Debian/Ubuntu, I
> have been busy writing instructions for creating Ubuntu packages.  Next
> step is to create a package repo to make it even easier.
> 
> The most difficult part has been to create a kernel config that works on
> everybody's hardware.  My approach to solving that problem is to create
> a well-documented, minimal set of configuration changes that may be
> applied to stock distro kernels.


This minimal set of change is documented, for xenomai, on the website.
If you find you need other changes, they may be bugs, and could need fixing.

  My results have been tested on EL6,
> x86_64 (not Deb or 32-bit yet), and the config files can be seen here:
> 
> https://github.com/zultron/kernel-tools/tree/master/configs
> 
> The community mostly seems to run 32-bit machines, so your repo doesn't
> satisfy all their needs yet.  :) 


I am going to compile the i686 packages, I guess we need to provide two
packages, one for UP, one for SMP.


> There will soon be a BeagleBone port,
> too, an arch I haven't begun to tackle yet.
> 
> It seems terrible to duplicate this effort, so let me know if there's
> anything I can do to help.  I can also supply packages for EL6 (my own
> most familiar distro).


we realized recently that:
- we need to test whether the in-tree debian packaging works for every
release, otherwise we make broken releases, the only way to do that is
to well, generate the debian packages and install them to see whether
they work;
- many newbies questions are about compiling kernels, mostly for the x86
architecture, so, if we provide the packaged kernels, we will avoid
these questions, and people will not have to master kernel compilation
and installation to be able to use xenomai. This did not look so hard a
few days ago, as learning to compile your own kernel was part of
learning to use Linux, but these days, with the one-fits-all distros
kernel, we find that people no longer know how to compile a kernel
(however easy it seems).

So, we tried and improved the I-pipe patches so that a single or a pair
of kernels (SMP and UP) can be generated for each architecture.

I started setting up a repository on the xenomai server, but obviously,
can not do it for all distributions, so, any help is welcome. What I can
propose is to set-up an inoticoming repository, give you access to an
incoming repository through scp (you whould have to send me your ssh
public key for that). Then, before a release, we would work to provide
the corresponding debian and ubuntu packages. As for the fedora
packages, I do not know the equivalent of reprepro and inoticoming.

Regards.

-- 
                                                                Gilles.

Re: [Xenomai] Debian package build problems

[John Morris]

On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
> On 01/08/2013 09:37 AM, John Morris wrote:
>> The most difficult part has been to create a kernel config that works on
>> everybody's hardware.  My approach to solving that problem is to create
>> a well-documented, minimal set of configuration changes that may be
>> applied to stock distro kernels.
> 
> 
> This minimal set of change is documented, for xenomai, on the website.
> If you find you need other changes, they may be bugs, and could need fixing.

Actually, I spent a few days bisecting the RedHat 2.6.38.8 kernel
.config with those minimal changes applied to locate a few problems.
See the config snippet pasted at the end.

As for 3.5.x, the only change was to disable CPUMASK_OFFSTACK, enabled
by default in RH kernels.

>> It seems terrible to duplicate this effort, so let me know if there's
>> anything I can do to help.  I can also supply packages for EL6 (my own
>> most familiar distro).
> 
> 
> we realized recently that:
> - we need to test whether the in-tree debian packaging works for every
> release, otherwise we make broken releases, the only way to do that is
> to well, generate the debian packages and install them to see whether
> they work;
> - many newbies questions are about compiling kernels, mostly for the x86
> architecture, so, if we provide the packaged kernels, we will avoid
> these questions, and people will not have to master kernel compilation
> and installation to be able to use xenomai. This did not look so hard a
> few days ago, as learning to compile your own kernel was part of
> learning to use Linux, but these days, with the one-fits-all distros
> kernel, we find that people no longer know how to compile a kernel
> (however easy it seems).

Also, there are many newbie pitfalls in generating a valid kernel
.config, as I'm finding out!

> So, we tried and improved the I-pipe patches so that a single or a pair
> of kernels (SMP and UP) can be generated for each architecture.

Great!  This is the right way to go in order to increase adoption.

> I started setting up a repository on the xenomai server, but obviously,
> can not do it for all distributions, so, any help is welcome. What I can
> propose is to set-up an inoticoming repository, give you access to an
> incoming repository through scp (you whould have to send me your ssh
> public key for that). Then, before a release, we would work to provide
> the corresponding debian and ubuntu packages. As for the fedora
> packages, I do not know the equivalent of reprepro and inoticoming.

I've been thinking about what I can offer over the last few days.  I'm
really too inexperienced with Deb-like distros and I'm poor at
maintenance.  My solution would be to automate this chore with some type
of build infrastructure, but that would probably take me much longer
than someone else more at home with Debian.

On the other hand, it would be quite easy for me to do this for el6 and,
once I have packages, Fedora, since we do have the automated build
infrastructure (and the expertise) in the shop that it wouldn't be
difficult.  In this case, it would be easiest to keep a git repo of the
RPM files online (just like the one I recently pointed to in other
threads) to keep the development open, compile the packages on our
infrastructure, and rsync the resulting repo either to the xenomai.org
site, my site, or anywhere else suitable.  The only piece missing would
be a public view of the build system (called 'koji', the same as the
Fedora project uses), which could come in time if we choose.

At any rate, I will certainly have my own el6 repo up soon, and I'll
announce it here for folks to try out.

	John


Config changes needed against stock RH kernel config for 2.6.38.8

# CONFIG_CPUMASK_OFFSTACK is enabled in the RH kernel configs
# Having this turned on caused compile errors:
# kernel/xenomai/nucleus/shadow.c: In function 'gatekeeper_thread':
# kernel/xenomai/nucleus/shadow.c:867: error: implicit declaration \
#   of function 'set_cpus_allowed'
# CONFIG_CPUMASK_OFFSTACK is not set
#
# CONFIG_SLAB and CONFIG_MODVERSION enabled cause unresolved module
# symbols:
#   rtapi: Unknown symbol kmalloc_caches (err 0)
# CONFIG_SLAB is not set
# CONFIG_MODVERSIONS is not set
#
# Avoid a problem where modules have a '[permanent]' tag in lsmod,
# and can't be unloaded:
#   ERROR: Module hal_lib is in use by timedelta,threads,[permanent]
CONFIG_JUMP_LABEL=y
#
# Fix rtapi init problem
#      RTAPI: ERROR: rtapi_init: rt_heap_bind() returns -11 - \
#         Resource temporarily unavailable
#      ERROR: could not not initialize RTAPI
CONFIG_UNUSED_SYMBOLS=y

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/13/2013 08:37 AM, John Morris wrote:

> 
> 
> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>> On 01/08/2013 09:37 AM, John Morris wrote:
>>> The most difficult part has been to create a kernel config that works on
>>> everybody's hardware.  My approach to solving that problem is to create
>>> a well-documented, minimal set of configuration changes that may be
>>> applied to stock distro kernels.
>>
>>
>> This minimal set of change is documented, for xenomai, on the website.
>> If you find you need other changes, they may be bugs, and could need fixing.
> 
> Actually, I spent a few days bisecting the RedHat 2.6.38.8 kernel
> .config with those minimal changes applied to locate a few problems.
> See the config snippet pasted at the end.


I understand this, what I mean is that you should post (or have posted)
the problems on the list. Disabling a configuration option is simply
papering over the bug, and most of these issues can be fixed in a way
that allow keeping the choice of enabling or disabling the option.

> 
> As for 3.5.x, the only change was to disable CPUMASK_OFFSTACK, enabled
> by default in RH kernels.


Looking at the kernel headers, it simply means that Xenomai has to use
set_cpus_allowed_ptr and provide a wrapper for older kernels which had
only set_cpus_allowed.

> Also, there are many newbie pitfalls in generating a valid kernel
> .config, as I'm finding out!


The problem is that it is difficult for us to test every possible
configurations combinations, so, when you find such a problem, please
post about it.

> 
>> So, we tried and improved the I-pipe patches so that a single or a pair
>> of kernels (SMP and UP) can be generated for each architecture.
> 
> Great!  This is the right way to go in order to increase adoption.
> 
>> I started setting up a repository on the xenomai server, but obviously,
>> can not do it for all distributions, so, any help is welcome. What I can
>> propose is to set-up an inoticoming repository, give you access to an
>> incoming repository through scp (you whould have to send me your ssh
>> public key for that). Then, before a release, we would work to provide
>> the corresponding debian and ubuntu packages. As for the fedora
>> packages, I do not know the equivalent of reprepro and inoticoming.
> 
> I've been thinking about what I can offer over the last few days.  I'm
> really too inexperienced with Deb-like distros and I'm poor at
> maintenance.  My solution would be to automate this chore with some type
> of build infrastructure, but that would probably take me much longer
> than someone else more at home with Debian.


I have been thinking about that too. Actually, running my tests on x86
from the Debian package instead of custom build kernels does not change
much (except the compilation time for the kernel, so, it has to be done
once I have a working kernel). Though I am going to test only Debian
stable, not Ubuntu.

> 
> On the other hand, it would be quite easy for me to do this for el6 and,
> once I have packages, Fedora, since we do have the automated build
> infrastructure (and the expertise) in the shop that it wouldn't be
> difficult.  In this case, it would be easiest to keep a git repo of the
> RPM files online (just like the one I recently pointed to in other
> threads) to keep the development open, compile the packages on our
> infrastructure, and rsync the resulting repo either to the xenomai.org
> site, my site, or anywhere else suitable.  The only piece missing would
> be a public view of the build system (called 'koji', the same as the
> Fedora project uses), which could come in time if we choose.
> 
> At any rate, I will certainly have my own el6 repo up soon, and I'll
> announce it here for folks to try out.


Ok, as you wish, it is not really a problem for us to provide you with a
git access, and an access to set-up a repository. At any rate, whatever
we do, we should also have a page in the wiki explaining how to get the
Fedora packages.

-- 
                                                                Gilles.

Re: [Xenomai] Debian package build problems

[John Morris]

On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
> On 01/13/2013 08:37 AM, John Morris wrote:
> 
>>
>>
>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>> On 01/08/2013 09:37 AM, John Morris wrote:
>>>> The most difficult part has been to create a kernel config that works on
>>>> everybody's hardware.  My approach to solving that problem is to create
>>>> a well-documented, minimal set of configuration changes that may be
>>>> applied to stock distro kernels.
>>>
>>>
>>> This minimal set of change is documented, for xenomai, on the website.
>>> If you find you need other changes, they may be bugs, and could need fixing.
>>
>> Actually, I spent a few days bisecting the RedHat 2.6.38.8 kernel
>> .config with those minimal changes applied to locate a few problems.
>> See the config snippet pasted at the end.
> 
> 
> I understand this, what I mean is that you should post (or have posted)
> the problems on the list. Disabling a configuration option is simply
> papering over the bug, and most of these issues can be fixed in a way
> that allow keeping the choice of enabling or disabling the option.

Ah yes, understood.  I did intend to bring this to the list, but to do
what I could by myself first.

>> As for 3.5.x, the only change was to disable CPUMASK_OFFSTACK, enabled
>> by default in RH kernels.
> 
> 
> Looking at the kernel headers, it simply means that Xenomai has to use
> set_cpus_allowed_ptr and provide a wrapper for older kernels which had
> only set_cpus_allowed.

Right.  I went through and fixed about half of them in Xenomai, but then
came upon one that looked like it touched the API, and realized I'd
better stop.  It's a pretty easy fix, though.

>> Also, there are many newbie pitfalls in generating a valid kernel
>> .config, as I'm finding out!
> 
> 
> The problem is that it is difficult for us to test every possible
> configurations combinations, so, when you find such a problem, please
> post about it.

Will do.  I predict I'll have a bunch of users reporting problems with
packages to me soon.

>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>> of kernels (SMP and UP) can be generated for each architecture.
>>
>> Great!  This is the right way to go in order to increase adoption.
>>
>>> I started setting up a repository on the xenomai server, but obviously,
>>> can not do it for all distributions, so, any help is welcome. What I can
>>> propose is to set-up an inoticoming repository, give you access to an
>>> incoming repository through scp (you whould have to send me your ssh
>>> public key for that). Then, before a release, we would work to provide
>>> the corresponding debian and ubuntu packages. As for the fedora
>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>
>> I've been thinking about what I can offer over the last few days.  I'm
>> really too inexperienced with Deb-like distros and I'm poor at
>> maintenance.  My solution would be to automate this chore with some type
>> of build infrastructure, but that would probably take me much longer
>> than someone else more at home with Debian.
> 
> 
> I have been thinking about that too. Actually, running my tests on x86
> from the Debian package instead of custom build kernels does not change
> much (except the compilation time for the kernel, so, it has to be done
> once I have a working kernel). Though I am going to test only Debian
> stable, not Ubuntu.

Understood.  Actually, testing could be automated by installing the OS
with the kernel to be tested and run xeno-regression-test.  That's some
infrastructure that I don't have ATM, but wouldn't be a huge leap.

>> On the other hand, it would be quite easy for me to do this for el6 and,
>> once I have packages, Fedora, since we do have the automated build
>> infrastructure (and the expertise) in the shop that it wouldn't be
>> difficult.  In this case, it would be easiest to keep a git repo of the
>> RPM files online (just like the one I recently pointed to in other
>> threads) to keep the development open, compile the packages on our
>> infrastructure, and rsync the resulting repo either to the xenomai.org
>> site, my site, or anywhere else suitable.  The only piece missing would
>> be a public view of the build system (called 'koji', the same as the
>> Fedora project uses), which could come in time if we choose.
>>
>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>> announce it here for folks to try out.
> 
> 
> Ok, as you wish, it is not really a problem for us to provide you with a
> git access, and an access to set-up a repository. At any rate, whatever
> we do, we should also have a page in the wiki explaining how to get the
> Fedora packages.

Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
and then see what looks like the best option.

	John

Re: [Xenomai] Debian package build problems

[John Morris]

On 01/13/2013 01:46 PM, John Morris wrote:
> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>> On 01/13/2013 08:37 AM, John Morris wrote:
>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>
>>> Great!  This is the right way to go in order to increase adoption.
>>>
>>>> I started setting up a repository on the xenomai server, but obviously,
>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>> propose is to set-up an inoticoming repository, give you access to an
>>>> incoming repository through scp (you whould have to send me your ssh
>>>> public key for that). Then, before a release, we would work to provide
>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>
>>> I've been thinking about what I can offer over the last few days.  I'm
>>> really too inexperienced with Deb-like distros and I'm poor at
>>> maintenance.  My solution would be to automate this chore with some type
>>> of build infrastructure, but that would probably take me much longer
>>> than someone else more at home with Debian.
>>
>>
>> I have been thinking about that too. Actually, running my tests on x86
>> from the Debian package instead of custom build kernels does not change
>> much (except the compilation time for the kernel, so, it has to be done
>> once I have a working kernel). Though I am going to test only Debian
>> stable, not Ubuntu.
> 
> Understood.  Actually, testing could be automated by installing the OS
> with the kernel to be tested and run xeno-regression-test.  That's some
> infrastructure that I don't have ATM, but wouldn't be a huge leap.
> 
>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>> once I have packages, Fedora, since we do have the automated build
>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>> RPM files online (just like the one I recently pointed to in other
>>> threads) to keep the development open, compile the packages on our
>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>> site, my site, or anywhere else suitable.  The only piece missing would
>>> be a public view of the build system (called 'koji', the same as the
>>> Fedora project uses), which could come in time if we choose.
>>>
>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>> announce it here for folks to try out.
>>
>>
>> Ok, as you wish, it is not really a problem for us to provide you with a
>> git access, and an access to set-up a repository. At any rate, whatever
>> we do, we should also have a page in the wiki explaining how to get the
>> Fedora packages.
> 
> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
> and then see what looks like the best option.

Hi Gilles,

I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
12.04 Precise:

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages

The packages are not good for anything except initial testing, and I've
asked the folks on the emc-devel list to give them a try.  The first
success has been reported, but there may not be many testers until
packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
users are stuck.

I have working EL6 packages too, but haven't put up a repository yet;
hopefully in the next couple of days.

My project depends on LinuxCNC and therefore Xenomai, and I plan to
maintain the RedHat packages myself.  I haven't decided exactly what to
do about the Debian packages yet, but I need to ensure quality,
up-to-date .deb packages are maintained for x86 architecture for at
least a couple of years.

	John

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/28/2013 08:34 AM, John Morris wrote:

> On 01/13/2013 01:46 PM, John Morris wrote:
>> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>>> On 01/13/2013 08:37 AM, John Morris wrote:
>>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>>
>>>> Great!  This is the right way to go in order to increase adoption.
>>>>
>>>>> I started setting up a repository on the xenomai server, but obviously,
>>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>>> propose is to set-up an inoticoming repository, give you access to an
>>>>> incoming repository through scp (you whould have to send me your ssh
>>>>> public key for that). Then, before a release, we would work to provide
>>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>>
>>>> I've been thinking about what I can offer over the last few days.  I'm
>>>> really too inexperienced with Deb-like distros and I'm poor at
>>>> maintenance.  My solution would be to automate this chore with some type
>>>> of build infrastructure, but that would probably take me much longer
>>>> than someone else more at home with Debian.
>>>
>>>
>>> I have been thinking about that too. Actually, running my tests on x86
>>> from the Debian package instead of custom build kernels does not change
>>> much (except the compilation time for the kernel, so, it has to be done
>>> once I have a working kernel). Though I am going to test only Debian
>>> stable, not Ubuntu.
>>
>> Understood.  Actually, testing could be automated by installing the OS
>> with the kernel to be tested and run xeno-regression-test.  That's some
>> infrastructure that I don't have ATM, but wouldn't be a huge leap.
>>
>>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>>> once I have packages, Fedora, since we do have the automated build
>>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>>> RPM files online (just like the one I recently pointed to in other
>>>> threads) to keep the development open, compile the packages on our
>>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>>> site, my site, or anywhere else suitable.  The only piece missing would
>>>> be a public view of the build system (called 'koji', the same as the
>>>> Fedora project uses), which could come in time if we choose.
>>>>
>>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>>> announce it here for folks to try out.
>>>
>>>
>>> Ok, as you wish, it is not really a problem for us to provide you with a
>>> git access, and an access to set-up a repository. At any rate, whatever
>>> we do, we should also have a page in the wiki explaining how to get the
>>> Fedora packages.
>>
>> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
>> and then see what looks like the best option.
> 
> Hi Gilles,
> 
> I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
> 12.04 Precise:
> 
> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
> 
> The packages are not good for anything except initial testing, and I've
> asked the folks on the emc-devel list to give them a try.  The first
> success has been reported, but there may not be many testers until
> packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
> users are stuck.
> 
> I have working EL6 packages too, but haven't put up a repository yet;
> hopefully in the next couple of days.
> 
> My project depends on LinuxCNC and therefore Xenomai, and I plan to
> maintain the RedHat packages myself.  I haven't decided exactly what to
> do about the Debian packages yet, but I need to ensure quality,
> up-to-date .deb packages are maintained for x86 architecture for at
> least a couple of years.


I have compiled and tested the xenomai packages for Debian stable (for
amd64 and i686), and am going to put them in the repository. The plan is
to push them with every release.

Though, I confirmed the issue reported with the i915 graphic card, and
need to investigate this.


-- 
                                                                Gilles.

Re: [Xenomai] Debian package build problems

[John Morris]

On 01/28/2013 01:39 AM, Gilles Chanteperdrix wrote:
> On 01/28/2013 08:34 AM, John Morris wrote:
> 
>> On 01/13/2013 01:46 PM, John Morris wrote:
>>> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>>>> On 01/13/2013 08:37 AM, John Morris wrote:
>>>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>>>
>>>>> Great!  This is the right way to go in order to increase adoption.
>>>>>
>>>>>> I started setting up a repository on the xenomai server, but obviously,
>>>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>>>> propose is to set-up an inoticoming repository, give you access to an
>>>>>> incoming repository through scp (you whould have to send me your ssh
>>>>>> public key for that). Then, before a release, we would work to provide
>>>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>>>
>>>>> I've been thinking about what I can offer over the last few days.  I'm
>>>>> really too inexperienced with Deb-like distros and I'm poor at
>>>>> maintenance.  My solution would be to automate this chore with some type
>>>>> of build infrastructure, but that would probably take me much longer
>>>>> than someone else more at home with Debian.
>>>>
>>>>
>>>> I have been thinking about that too. Actually, running my tests on x86
>>>> from the Debian package instead of custom build kernels does not change
>>>> much (except the compilation time for the kernel, so, it has to be done
>>>> once I have a working kernel). Though I am going to test only Debian
>>>> stable, not Ubuntu.
>>>
>>> Understood.  Actually, testing could be automated by installing the OS
>>> with the kernel to be tested and run xeno-regression-test.  That's some
>>> infrastructure that I don't have ATM, but wouldn't be a huge leap.
>>>
>>>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>>>> once I have packages, Fedora, since we do have the automated build
>>>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>>>> RPM files online (just like the one I recently pointed to in other
>>>>> threads) to keep the development open, compile the packages on our
>>>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>>>> site, my site, or anywhere else suitable.  The only piece missing would
>>>>> be a public view of the build system (called 'koji', the same as the
>>>>> Fedora project uses), which could come in time if we choose.
>>>>>
>>>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>>>> announce it here for folks to try out.
>>>>
>>>>
>>>> Ok, as you wish, it is not really a problem for us to provide you with a
>>>> git access, and an access to set-up a repository. At any rate, whatever
>>>> we do, we should also have a page in the wiki explaining how to get the
>>>> Fedora packages.
>>>
>>> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
>>> and then see what looks like the best option.
>>
>> Hi Gilles,
>>
>> I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
>> 12.04 Precise:
>>
>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
>>
>> The packages are not good for anything except initial testing, and I've
>> asked the folks on the emc-devel list to give them a try.  The first
>> success has been reported, but there may not be many testers until
>> packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
>> users are stuck.
>>
>> I have working EL6 packages too, but haven't put up a repository yet;
>> hopefully in the next couple of days.
>>
>> My project depends on LinuxCNC and therefore Xenomai, and I plan to
>> maintain the RedHat packages myself.  I haven't decided exactly what to
>> do about the Debian packages yet, but I need to ensure quality,
>> up-to-date .deb packages are maintained for x86 architecture for at
>> least a couple of years.
> 
> 
> I have compiled and tested the xenomai packages for Debian stable (for
> amd64 and i686), and am going to put them in the repository. The plan is
> to push them with every release.

The xenomai packages in my repo are built with little change from the
2.6.2.1 release, of course.

My kernel packages are not related to yours, so I assume you mean you
recompiled your own packages.

Do you have a place you keep the kernel package sources?  I didn't see
those last time around.  (Looks like your repo is undergoing maintenance
right now, so I'm unable to check again.)

> Though, I confirmed the issue reported with the i915 graphic card, and
> need to investigate this.

	John

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/28/2013 08:48 AM, John Morris wrote:

> 
> 
> On 01/28/2013 01:39 AM, Gilles Chanteperdrix wrote:
>> On 01/28/2013 08:34 AM, John Morris wrote:
>>
>>> On 01/13/2013 01:46 PM, John Morris wrote:
>>>> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>>>>> On 01/13/2013 08:37 AM, John Morris wrote:
>>>>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>>>>
>>>>>> Great!  This is the right way to go in order to increase adoption.
>>>>>>
>>>>>>> I started setting up a repository on the xenomai server, but obviously,
>>>>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>>>>> propose is to set-up an inoticoming repository, give you access to an
>>>>>>> incoming repository through scp (you whould have to send me your ssh
>>>>>>> public key for that). Then, before a release, we would work to provide
>>>>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>>>>
>>>>>> I've been thinking about what I can offer over the last few days.  I'm
>>>>>> really too inexperienced with Deb-like distros and I'm poor at
>>>>>> maintenance.  My solution would be to automate this chore with some type
>>>>>> of build infrastructure, but that would probably take me much longer
>>>>>> than someone else more at home with Debian.
>>>>>
>>>>>
>>>>> I have been thinking about that too. Actually, running my tests on x86
>>>>> from the Debian package instead of custom build kernels does not change
>>>>> much (except the compilation time for the kernel, so, it has to be done
>>>>> once I have a working kernel). Though I am going to test only Debian
>>>>> stable, not Ubuntu.
>>>>
>>>> Understood.  Actually, testing could be automated by installing the OS
>>>> with the kernel to be tested and run xeno-regression-test.  That's some
>>>> infrastructure that I don't have ATM, but wouldn't be a huge leap.
>>>>
>>>>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>>>>> once I have packages, Fedora, since we do have the automated build
>>>>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>>>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>>>>> RPM files online (just like the one I recently pointed to in other
>>>>>> threads) to keep the development open, compile the packages on our
>>>>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>>>>> site, my site, or anywhere else suitable.  The only piece missing would
>>>>>> be a public view of the build system (called 'koji', the same as the
>>>>>> Fedora project uses), which could come in time if we choose.
>>>>>>
>>>>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>>>>> announce it here for folks to try out.
>>>>>
>>>>>
>>>>> Ok, as you wish, it is not really a problem for us to provide you with a
>>>>> git access, and an access to set-up a repository. At any rate, whatever
>>>>> we do, we should also have a page in the wiki explaining how to get the
>>>>> Fedora packages.
>>>>
>>>> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
>>>> and then see what looks like the best option.
>>>
>>> Hi Gilles,
>>>
>>> I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
>>> 12.04 Precise:
>>>
>>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
>>>
>>> The packages are not good for anything except initial testing, and I've
>>> asked the folks on the emc-devel list to give them a try.  The first
>>> success has been reported, but there may not be many testers until
>>> packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
>>> users are stuck.
>>>
>>> I have working EL6 packages too, but haven't put up a repository yet;
>>> hopefully in the next couple of days.
>>>
>>> My project depends on LinuxCNC and therefore Xenomai, and I plan to
>>> maintain the RedHat packages myself.  I haven't decided exactly what to
>>> do about the Debian packages yet, but I need to ensure quality,
>>> up-to-date .deb packages are maintained for x86 architecture for at
>>> least a couple of years.
>>
>>
>> I have compiled and tested the xenomai packages for Debian stable (for
>> amd64 and i686), and am going to put them in the repository. The plan is
>> to push them with every release.
> 
> The xenomai packages in my repo are built with little change from the
> 2.6.2.1 release, of course.
> 
> My kernel packages are not related to yours, so I assume you mean you
> recompiled your own packages.


>From what I understand, you made packages for Ubuntu, my target is
Debian stable.

> 
> Do you have a place you keep the kernel package sources?  I didn't see
> those last time around.  (Looks like your repo is undergoing maintenance
> right now, so I'm unable to check again.)


Well, the kernel sources are a vanilla kernel with the xenomai patch
applied, so, nothing that can not be reproduced. But I guess I could put
the kernel sources packages in the repository. Maintenance should be
finished, now.

-- 
                                                                Gilles.

Re: [Xenomai] Debian package build problems

[John Morris]

On 01/28/2013 02:09 AM, Gilles Chanteperdrix wrote:
> On 01/28/2013 08:48 AM, John Morris wrote:
> 
>>
>>
>> On 01/28/2013 01:39 AM, Gilles Chanteperdrix wrote:
>>> On 01/28/2013 08:34 AM, John Morris wrote:
>>>
>>>> On 01/13/2013 01:46 PM, John Morris wrote:
>>>>> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>>>>>> On 01/13/2013 08:37 AM, John Morris wrote:
>>>>>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>>>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>>>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>>>>>
>>>>>>> Great!  This is the right way to go in order to increase adoption.
>>>>>>>
>>>>>>>> I started setting up a repository on the xenomai server, but obviously,
>>>>>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>>>>>> propose is to set-up an inoticoming repository, give you access to an
>>>>>>>> incoming repository through scp (you whould have to send me your ssh
>>>>>>>> public key for that). Then, before a release, we would work to provide
>>>>>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>>>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>>>>>
>>>>>>> I've been thinking about what I can offer over the last few days.  I'm
>>>>>>> really too inexperienced with Deb-like distros and I'm poor at
>>>>>>> maintenance.  My solution would be to automate this chore with some type
>>>>>>> of build infrastructure, but that would probably take me much longer
>>>>>>> than someone else more at home with Debian.
>>>>>>
>>>>>>
>>>>>> I have been thinking about that too. Actually, running my tests on x86
>>>>>> from the Debian package instead of custom build kernels does not change
>>>>>> much (except the compilation time for the kernel, so, it has to be done
>>>>>> once I have a working kernel). Though I am going to test only Debian
>>>>>> stable, not Ubuntu.
>>>>>
>>>>> Understood.  Actually, testing could be automated by installing the OS
>>>>> with the kernel to be tested and run xeno-regression-test.  That's some
>>>>> infrastructure that I don't have ATM, but wouldn't be a huge leap.
>>>>>
>>>>>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>>>>>> once I have packages, Fedora, since we do have the automated build
>>>>>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>>>>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>>>>>> RPM files online (just like the one I recently pointed to in other
>>>>>>> threads) to keep the development open, compile the packages on our
>>>>>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>>>>>> site, my site, or anywhere else suitable.  The only piece missing would
>>>>>>> be a public view of the build system (called 'koji', the same as the
>>>>>>> Fedora project uses), which could come in time if we choose.
>>>>>>>
>>>>>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>>>>>> announce it here for folks to try out.
>>>>>>
>>>>>>
>>>>>> Ok, as you wish, it is not really a problem for us to provide you with a
>>>>>> git access, and an access to set-up a repository. At any rate, whatever
>>>>>> we do, we should also have a page in the wiki explaining how to get the
>>>>>> Fedora packages.
>>>>>
>>>>> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
>>>>> and then see what looks like the best option.
>>>>
>>>> Hi Gilles,
>>>>
>>>> I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
>>>> 12.04 Precise:
>>>>
>>>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
>>>>
>>>> The packages are not good for anything except initial testing, and I've
>>>> asked the folks on the emc-devel list to give them a try.  The first
>>>> success has been reported, but there may not be many testers until
>>>> packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
>>>> users are stuck.
>>>>
>>>> I have working EL6 packages too, but haven't put up a repository yet;
>>>> hopefully in the next couple of days.
>>>>
>>>> My project depends on LinuxCNC and therefore Xenomai, and I plan to
>>>> maintain the RedHat packages myself.  I haven't decided exactly what to
>>>> do about the Debian packages yet, but I need to ensure quality,
>>>> up-to-date .deb packages are maintained for x86 architecture for at
>>>> least a couple of years.
>>>
>>>
>>> I have compiled and tested the xenomai packages for Debian stable (for
>>> amd64 and i686), and am going to put them in the repository. The plan is
>>> to push them with every release.
>>
>> The xenomai packages in my repo are built with little change from the
>> 2.6.2.1 release, of course.
>>
>> My kernel packages are not related to yours, so I assume you mean you
>> recompiled your own packages.
> 
> 
> From what I understand, you made packages for Ubuntu, my target is
> Debian stable.

Yes, I made packages for Ubuntu Precise.  My other targets are Lucid and
Debian stable, which I hope to build from the same source package.

>> Do you have a place you keep the kernel package sources?  I didn't see
>> those last time around.  (Looks like your repo is undergoing maintenance
>> right now, so I'm unable to check again.)
> 
> 
> Well, the kernel sources are a vanilla kernel with the xenomai patch
> applied, so, nothing that can not be reproduced. But I guess I could put
> the kernel sources packages in the repository. Maintenance should be
> finished, now.

If your package sources are not important, then maybe you're using
make-kpkg?  Where did the base kernel .config come from?

	John

Re: [Xenomai] Debian package build problems

[Gilles Chanteperdrix]

On 01/28/2013 09:19 AM, John Morris wrote:

> On 01/28/2013 02:09 AM, Gilles Chanteperdrix wrote:
>> On 01/28/2013 08:48 AM, John Morris wrote:
>>
>>>
>>>
>>> On 01/28/2013 01:39 AM, Gilles Chanteperdrix wrote:
>>>> On 01/28/2013 08:34 AM, John Morris wrote:
>>>>
>>>>> On 01/13/2013 01:46 PM, John Morris wrote:
>>>>>> On 01/13/2013 06:19 AM, Gilles Chanteperdrix wrote:
>>>>>>> On 01/13/2013 08:37 AM, John Morris wrote:
>>>>>>>> On 01/08/2013 02:25 PM, Gilles Chanteperdrix wrote:
>>>>>>>>> So, we tried and improved the I-pipe patches so that a single or a pair
>>>>>>>>> of kernels (SMP and UP) can be generated for each architecture.
>>>>>>>>
>>>>>>>> Great!  This is the right way to go in order to increase adoption.
>>>>>>>>
>>>>>>>>> I started setting up a repository on the xenomai server, but obviously,
>>>>>>>>> can not do it for all distributions, so, any help is welcome. What I can
>>>>>>>>> propose is to set-up an inoticoming repository, give you access to an
>>>>>>>>> incoming repository through scp (you whould have to send me your ssh
>>>>>>>>> public key for that). Then, before a release, we would work to provide
>>>>>>>>> the corresponding debian and ubuntu packages. As for the fedora
>>>>>>>>> packages, I do not know the equivalent of reprepro and inoticoming.
>>>>>>>>
>>>>>>>> I've been thinking about what I can offer over the last few days.  I'm
>>>>>>>> really too inexperienced with Deb-like distros and I'm poor at
>>>>>>>> maintenance.  My solution would be to automate this chore with some type
>>>>>>>> of build infrastructure, but that would probably take me much longer
>>>>>>>> than someone else more at home with Debian.
>>>>>>>
>>>>>>>
>>>>>>> I have been thinking about that too. Actually, running my tests on x86
>>>>>>> from the Debian package instead of custom build kernels does not change
>>>>>>> much (except the compilation time for the kernel, so, it has to be done
>>>>>>> once I have a working kernel). Though I am going to test only Debian
>>>>>>> stable, not Ubuntu.
>>>>>>
>>>>>> Understood.  Actually, testing could be automated by installing the OS
>>>>>> with the kernel to be tested and run xeno-regression-test.  That's some
>>>>>> infrastructure that I don't have ATM, but wouldn't be a huge leap.
>>>>>>
>>>>>>>> On the other hand, it would be quite easy for me to do this for el6 and,
>>>>>>>> once I have packages, Fedora, since we do have the automated build
>>>>>>>> infrastructure (and the expertise) in the shop that it wouldn't be
>>>>>>>> difficult.  In this case, it would be easiest to keep a git repo of the
>>>>>>>> RPM files online (just like the one I recently pointed to in other
>>>>>>>> threads) to keep the development open, compile the packages on our
>>>>>>>> infrastructure, and rsync the resulting repo either to the xenomai.org
>>>>>>>> site, my site, or anywhere else suitable.  The only piece missing would
>>>>>>>> be a public view of the build system (called 'koji', the same as the
>>>>>>>> Fedora project uses), which could come in time if we choose.
>>>>>>>>
>>>>>>>> At any rate, I will certainly have my own el6 repo up soon, and I'll
>>>>>>>> announce it here for folks to try out.
>>>>>>>
>>>>>>>
>>>>>>> Ok, as you wish, it is not really a problem for us to provide you with a
>>>>>>> git access, and an access to set-up a repository. At any rate, whatever
>>>>>>> we do, we should also have a page in the wiki explaining how to get the
>>>>>>> Fedora packages.
>>>>>>
>>>>>> Ok, thanks.  Taking the lazy approach, let's wait until my repos are up,
>>>>>> and then see what looks like the best option.
>>>>>
>>>>> Hi Gilles,
>>>>>
>>>>> I put up an experimental PPA with 2.6.2.1 release packages for Ubuntu
>>>>> 12.04 Precise:
>>>>>
>>>>> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?XenomaiKernelPackages
>>>>>
>>>>> The packages are not good for anything except initial testing, and I've
>>>>> asked the folks on the emc-devel list to give them a try.  The first
>>>>> success has been reported, but there may not be many testers until
>>>>> packages are available for Ubuntu 10.04 Lucid, where current LinuxCNC
>>>>> users are stuck.
>>>>>
>>>>> I have working EL6 packages too, but haven't put up a repository yet;
>>>>> hopefully in the next couple of days.
>>>>>
>>>>> My project depends on LinuxCNC and therefore Xenomai, and I plan to
>>>>> maintain the RedHat packages myself.  I haven't decided exactly what to
>>>>> do about the Debian packages yet, but I need to ensure quality,
>>>>> up-to-date .deb packages are maintained for x86 architecture for at
>>>>> least a couple of years.
>>>>
>>>>
>>>> I have compiled and tested the xenomai packages for Debian stable (for
>>>> amd64 and i686), and am going to put them in the repository. The plan is
>>>> to push them with every release.
>>>
>>> The xenomai packages in my repo are built with little change from the
>>> 2.6.2.1 release, of course.
>>>
>>> My kernel packages are not related to yours, so I assume you mean you
>>> recompiled your own packages.
>>
>>
>> From what I understand, you made packages for Ubuntu, my target is
>> Debian stable.
> 
> Yes, I made packages for Ubuntu Precise.  My other targets are Lucid and
> Debian stable, which I hope to build from the same source package.


Ok, providing the packages for Debian stable is something new for us,
the idea is to avoid recurring questions on the mailing list about
compiling kernel by avoiding kernel compilation to the user, but if
someone wants to do that work, there is no reason to duplicate it.

> 
>>> Do you have a place you keep the kernel package sources?  I didn't see
>>> those last time around.  (Looks like your repo is undergoing maintenance
>>> right now, so I'm unable to check again.)
>>
>>
>> Well, the kernel sources are a vanilla kernel with the xenomai patch
>> applied, so, nothing that can not be reproduced. But I guess I could put
>> the kernel sources packages in the repository. Maintenance should be
>> finished, now.
> 
> If your package sources are not important, then maybe you're using
> make-kpkg?  Where did the base kernel .config come from?


Yes, I am using make-kpkg, the .config is derived from Debian kernel
configuration for Linux 3.2.0 (from debian backports) with the usual
modifications made for Xenomai, most new options in the configuration
enabled as "module", or "yes" if module is not possible, and ftrace
disabled.

-- 
                                                                Gilles.