[Xenomai] [Announce] Xenomai v2.6.1

[Xenomai] [Announce] Xenomai v2.6.1

[Gilles Chanteperdrix]

Hi,

At long last, please find Xenomai 2.6.1 at the following URL:
http://download.gna.org/xenomai/stable/xenomai-2.6.1.tar.bz2

We have been waiting so long since 2.6.0 that quite a few commits
happened. To try and summarize, we got:
* fixes, there are too many to list there, see the shortlog

* the usual updates of I-pipe patches, the main one being the I-pipe
core 3.2 patch, by Philippe, a much simplified and refactored version
of the Adeos patch.

The complete shortlog follows.
Thanks to all those who have contributed.
Regards.

Christophe Blaess (1):
      tools: fix rtps with NULL name tasks

Paul Janzen (1):
      Mask signals in rt_print:printer_loop()

Fabrice Gasnier (2):
      mpc5121 can: adapt to platform driver infrastructure changes for 2.6.35
      fix mscan init on mpc5121

Wolfgang Grandegger (5):
      rtdm: add rtdm_printk_ratelimited
      serial/16650a: fix missing value in default_config initialization
      serial: add shift register empty event and RS485 support flag
      serial: add driver for the MPC52xx PSC UARTs
      nucleus: fix poll EOF issue with xnpipe/rt_pipe

Jan Kiszka (14):
      nucleus: Privatize __xnpod_reset_thread
      x86: Fire root preemption notifier
      nucleus: Fix relaxed owner check
      mayday: Fix code setup for x86 and blackfin
      Add sigdebug unit test
      Remove obsolete mayday regression test
      native: Interrupt rt_timer_spin syscall on pending signals
      Add dependency of skin libraries on libxenomai
      Only export required CFLAGS via xeno-config
      mq_select: Fix for --enable-dlopen-skins
      Re-apply 2dc4288baba1bb701aeb61c44f12a2115b0aef77
      Append missing newline to rt_[f]puts output
      testsuite: Only use rt_print services in leak test
      Add regression test for mprotect on pinned memory

Philippe Gerum (43):
      native/queue: fix rt_queue_flush()
      nucleus/pod: dequeue kicked threads from any synch wait list
      powerpc: upgrade I-pipe support to 3.0.13-powerpc-2.13-06, ipipe-3.1.5-powerpc-2.13-06
      Merge branch 'master' of ssh+git://xenomai.org/xenomai-2.6
      hal: detect and enable upcoming pipeline core
      x86: upgrade I-pipe support to 2.6.38.8-x86-2.11-01
      hal: don't expect return values from SMP-specific core IRQ routines
      scripts: prepare for upcoming pipeline core series
      hal/powerpc: plug race in thread context switch
      hal/x86: drop wrappers to IPI vectors
      nucleus: drop pointless CPU synchronization upon shutdown
      Revert "hal/x86: drop wrappers to IPI vectors"
      hal, nucleus: introduce support for pipeline core IPIs
      hal: introduce support for mm tracking w/ pipeline core
      nucleus: set as pipeline head w/ pipeline core series
      Merge branch 'master' of ssh+git://xenomai.org/xenomai-2.6
      Merge branch 'keepme'
      nucleus/sched: keep non-rt thread flag unaffected by priority boost
      nucleus, native, psos, vxworks: fix build w/ OPT_PERVASIVE disabled
      Merge branch 'master' of ssh+git://xenomai.org/xenomai-2.6
      hal/powerpc: fixup for refactored timers of pipeline -core series
      nucleus/sched: update scheduling class weights
      nucleus: silence warning
      powerpc: upgrade I-pipe support to 3.1.10-powerpc-2.13-07
      hal/powerpc: fixup for refactored timers (take #2)
      nucleus: enable back PREEMPT_RT support
      hal/powerpc: introduce calibration data for P1022
      nucleus: deprecate priority coupling
      Merge branch 'master' of ssh+git://xenomai.org/xenomai-2.6
      hal/blackfin: fix build enabling refactored timer API
      Merge branch 'master' of ssh+git://xenomai.org/xenomai-2.6
      hal/blackfin: fix build for legacy timer code
      Merge branch 'master' of ssh+git://xenomai.org:2322/xenomai-2.6
      build: fix up for autoconf 2.68, automake 1.11.3, libtool 2.4.2
      hal/x86_64: fix build over legacy pipeline
      x86: fix mayday support in 32bit+SEP mode
      build/x86: assume x86-sep available by default
      hal/generic: enable/fix threaded APC with PREEMPT_RT
      hal/powerpc: fix build over legacy 2.4 kernel
      Merge branch 'master' of git://xenomai.org/xenomai-2.6
      powerpc: upgrade I-pipe support to 2.6.36.4-powerpc-2.12-05, 3.1.10-powerpc-2.13-08
      powerpc: remove obsolete ipipe-3.0.13-powerpc-2.13-06
      blackfin: remove obsolete ipipe-2.6.34-blackfin-1.15-01

Gilles Chanteperdrix (78):
      posix: fix compilation for LFS
      testsuite: install regression testsuite with other tests
      rtdk/posix: implement fwrite
      posix: fix pthread_mutex_trylock in FASTSYNCH case
      x86: compile user-space with frame pointers
      posix: add forward declaration of struct sched_param_ex
      examples: fix compilation issues
      examples: fix compilation with kernel 3.0
      tests: global exit using exit() instead of rt_task_delete()
      arm: no known SOC supports SMP with pre-v6 architecture, forbid this option
      arm: clarify README.INSTALL
      arm: clarify README.INSTALL again
      rt_print: wait for first initialization before spanwning rt_print thread
      nucleus: fix switchback with explicit migration
      posix: fix linux-side posix threads priority
      testsuite: add auto-switchback feature test
      xeno-test: use monotonic time
      x86: remove old adeos patch
      arm: upgrade adeos patches
      posix: avoid kernel oops
      arm: add support for imx6q to mxc patches
      arm: fix heaps pre-faulting with kernel newer than 2.6.22
      nucleus: do not touch XNOTHER bit for threads under PIP boost
      arm: fix mayday assembly
      bootstrap
      debug: enable the relaxed owner check by default
      testsuite: get the sigdebug test running on ARM
      testsuite: run sigdebug instead of mayday in regression test script
      testsuite: test auto-switchback feature better
      arm: upgrade adeos patches
      arm: (re)fix OABI mayday code
      posix: fix pthread_mutex_trylock in XNOTHER case
      posix: cosmetic fixes in src/skins/posix/mutex.c
      posix: use wrap-link.sh to link posix tests
      bootstrap
      Revert 7c601b91f218d05bf6c243469cc21c97ae2d237c
      Revert 2dc4288baba1bb701aeb61c44f12a2115b0aef77
      testsuite: fix mq_select in the auto-shadowing case
      Fix previous change
      arm: adapt to ipipe core 3.2
      arm: forcibly select unlocked context switches when SMP is enabled
      arm: optimize tsc emulation
      hal: unregister virq handler before freeing virq
      arm: add suppport for spear6xx
      common/rt_print: mask all signals for logging thread
      scripts: fix extract-doc, git-clone no longer exists
      hal/arm: support new type of tsc (spear tsc)
      rt_print: add support for fputc and putchar
      hal/arm: fixup for refactored timers
      testsuite: try running clocktest with CLOCK_HOST_REALTIME
      nucleus: get CLOCK_HOSTRT working with ipipe-core
      hal/blackfin: fixup for refactored timers
      arm: upgrade I-pipe support to 3.0.13-arm-1.18-08
      hal/arm: fix compilation in the non ipipe-core case
      hal/arm: use a more sensible timer load value for calibration
      arm: upgrade mxc I-pipe support to 3.0.13-arm-1.18-08
      hal/arm: support backport of linux 3.2 VFP fixes
      posix: fix build with LFS flags on 64 bits platform
      wrappers: avoid warning due to CONFIG_PREEMPT_RT
      hal/x86: fixup for refactored timers
      testsuite: add latency options and gnuplot script to generate histograms
      posix: get pthread_set_name_np to set linux thread name too
      mayday: fix xnshadow_sys_mayday return value
      hal/x86 adapt to newer kernels where TS_USEDFPU was replaced
      doc: change mailing lists address
      hal/x86: warn user when using a kernel without tsc on a cpu with tsc
      hal/arm: update adeos patches
      x86: only compile xenomai libraries with frame pointers enabled
      posix: fix nanosleep when interrupted by a signal
      testsuite: add nanosleep regression test
      testsuite: fix x86 compilation issues in nanosleep test
      build: only enable frame pointers on x86_32
      testsuite/nano_test: do not assume auto-shadowing of the maint thread
      doc: fix various doxygen warnings
      nucleus/vfile: avoid buffer overflow
      doc: use the more complete server based search engine
      hal: upgrade adeos patches with ipipe-core patches
      build: bump version number and bootstrap
      documentation: regenerate

-- 
                                                                Gilles.

[Xenomai] Debian packaging bug in Xenomai v2.6.1

[Jeff Webb]

On 07/10/2012 03:00 PM, Gilles Chanteperdrix wrote:
> At long last, please find Xenomai 2.6.1 at the following URL:
> http://download.gna.org/xenomai/stable/xenomai-2.6.1.tar.bz2

Wonderful!  I have been looking forward to this release.  I have been 
using a version I checked out from the Xenomai-2.6 git repository around 
April 20th.

In the process of building a new set of debian packages for 2.6.1, I was 
painfully reminded of an issue I discovered back in April, but failed to 
report.  When I issue the 'debuild -uc -us' command in the xenomai-2.6.1 
directory, I eventually get an error that says:

cp: cannot stat `debian/tmp/usr/share/xenomai': No such file or directory
dh_install: cp -a debian/tmp/usr/share/xenomai 
debian/xenomai-runtime//usr/share/ returned exit code 1
make: *** [install] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2

If I remove the 'usr/share/xenomai' line from 
xenomai-2.6.1/debian/xenomai-runtime.install, the error goes away.

I am building on ubuntu-12.04, if that makes any difference.  I 
apologize for not reporting this earlier, so a fix could be included in 
this point release.  Let me know if there is any more information I can 
provide to help this get fixed for future releases.

Thanks,

-Jeff

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Gilles Chanteperdrix]

On 07/11/2012 05:53 PM, Jeff Webb wrote:
> On 07/10/2012 03:00 PM, Gilles Chanteperdrix wrote:
>> At long last, please find Xenomai 2.6.1 at the following URL:
>> http://download.gna.org/xenomai/stable/xenomai-2.6.1.tar.bz2
> 
> Wonderful!  I have been looking forward to this release.  I have been 
> using a version I checked out from the Xenomai-2.6 git repository around 
> April 20th.
> 
> In the process of building a new set of debian packages for 2.6.1, I was 
> painfully reminded of an issue I discovered back in April, but failed to 
> report.  When I issue the 'debuild -uc -us' command in the xenomai-2.6.1 
> directory, I eventually get an error that says:
> 
> cp: cannot stat `debian/tmp/usr/share/xenomai': No such file or directory
> dh_install: cp -a debian/tmp/usr/share/xenomai 
> debian/xenomai-runtime//usr/share/ returned exit code 1
> make: *** [install] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
> status 2
> 
> If I remove the 'usr/share/xenomai' line from 
> xenomai-2.6.1/debian/xenomai-runtime.install, the error goes away.
> 
> I am building on ubuntu-12.04, if that makes any difference.  I 
> apologize for not reporting this earlier, so a fix could be included in 
> this point release.  Let me know if there is any more information I can 
> provide to help this get fixed for future releases.

Well, maybe we should, from time to time, import the changes which are
done by the debian maintainers. Or forget the debian directory
altogether, as there is one correctly maintained by the debian
maintainer. I do not really know what to think of this as I do not use
the debian packaging. As a user of debian packaging, what do you think?

-- 
					    Gilles.

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Lennart Sorensen]

On Wed, Jul 11, 2012 at 06:52:41PM +0200, Gilles Chanteperdrix wrote:
> Well, maybe we should, from time to time, import the changes which are
> done by the debian maintainers. Or forget the debian directory
> altogether, as there is one correctly maintained by the debian
> maintainer. I do not really know what to think of this as I do not use
> the debian packaging. As a user of debian packaging, what do you think?

Perhaps it is a question of occationally testing that 'make install'
with DESTDIR set to some /tmp/ place that doesn't exist actually works.
Very easy to have a makefile assume /usr/share exists and forget to
create it before copying files to it.

-- 
Len Sorensen

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Gilles Chanteperdrix]

On 07/11/2012 07:48 PM, Lennart Sorensen wrote:
> On Wed, Jul 11, 2012 at 06:52:41PM +0200, Gilles Chanteperdrix wrote:
>> Well, maybe we should, from time to time, import the changes which are
>> done by the debian maintainers. Or forget the debian directory
>> altogether, as there is one correctly maintained by the debian
>> maintainer. I do not really know what to think of this as I do not use
>> the debian packaging. As a user of debian packaging, what do you think?
> 
> Perhaps it is a question of occationally testing that 'make install'
> with DESTDIR set to some /tmp/ place that doesn't exist actually works.
> Very easy to have a makefile assume /usr/share exists and forget to
> create it before copying files to it.

We run "make distcheck" as part of what is done when releasing xenomai,
so, the sort of error you mention should not exist. In particular, since
we use the autotools, these things are being taken care of automatically.

The problem is that we use to have files in the /usr/share/xenomai
directory, the debian files were written with this assumption, we now no
longer install any file in /usr/share/xenomai, and we did not change the
debian files, simply because nobody tested the debian package
generation, or more accurately someone did but forgot to report the bug.

-- 
                                                                Gilles.

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Roland Stigge]

On 07/12/2012 02:20 AM, Gilles Chanteperdrix wrote:
> The problem is that we use to have files in the /usr/share/xenomai
> directory, the debian files were written with this assumption, we now no
> longer install any file in /usr/share/xenomai, and we did not change the
> debian files, simply because nobody tested the debian package
> generation, or more accurately someone did but forgot to report the bug.

>From the Debian perspective, the debian/ directory in "upstream" Xenomai
is a bit confusing. At Debian, this one is ignored anyway and replaced
with Debian's up-to-date variant.

I unfortunately don't have the ressources to regularly sync/update
debian/* in the xenomai.org dev repository.

FYI: Unfortunate coincidence that the freeze for the next Debian release
("wheezy") was shortly before the Xenomai 2.6.1 release. So I'll be
stuck with 2.6.0 for a while now.

Will put 2.6.1 into Debian "experimental", however, shortly.

Roland

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Gilles Chanteperdrix]

On 07/12/2012 10:31 AM, Roland Stigge wrote:
> On 07/12/2012 02:20 AM, Gilles Chanteperdrix wrote:
>> The problem is that we use to have files in the /usr/share/xenomai
>> directory, the debian files were written with this assumption, we now no
>> longer install any file in /usr/share/xenomai, and we did not change the
>> debian files, simply because nobody tested the debian package
>> generation, or more accurately someone did but forgot to report the bug.
> 
> From the Debian perspective, the debian/ directory in "upstream" Xenomai
> is a bit confusing. At Debian, this one is ignored anyway and replaced
> with Debian's up-to-date variant.

We maintain our own debian directory for convenience, because we like
the idea of a self-contained package. But obviously this only makes
sense if this debian directory is maintained.

> 
> I unfortunately don't have the ressources to regularly sync/update
> debian/* in the xenomai.org dev repository.

I understand that. You already maintain a debian directory on your side,
you have absolutely no reason to maintain the debian directory of the
xenomai project.

Anyway, what I would like to know if people find useful the "feature" of
shipping with a debian directory.

> FYI: Unfortunate coincidence that the freeze for the next Debian release
> ("wheezy") was shortly before the Xenomai 2.6.1 release. So I'll be
> stuck with 2.6.0 for a while now.
> 
> Will put 2.6.1 into Debian "experimental", however, shortly.

Too bad. But maybe you could say that Debian uses Xenomai 2.6, and the
third version numbers are just security updates ;-) I am just half
kidding, after all, the policy is that all releases in the same branch
are binary compatibles.

-- 
					    Gilles.

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Jeff Webb]

On 07/12/2012 04:10 AM, Gilles Chanteperdrix wrote:
> On 07/12/2012 10:31 AM, Roland Stigge wrote:
>> On 07/12/2012 02:20 AM, Gilles Chanteperdrix wrote:
>>> The problem is that we use to have files in the /usr/share/xenomai
>>> directory, the debian files were written with this assumption, we now no
>>> longer install any file in /usr/share/xenomai, and we did not change the
>>> debian files, simply because nobody tested the debian package
>>> generation, or more accurately someone did but forgot to report the bug.
>>
>>  From the Debian perspective, the debian/ directory in "upstream" Xenomai
>> is a bit confusing. At Debian, this one is ignored anyway and replaced
>> with Debian's up-to-date variant.
>
> We maintain our own debian directory for convenience, because we like
> the idea of a self-contained package. But obviously this only makes
> sense if this debian directory is maintained.
>
>>
>> I unfortunately don't have the ressources to regularly sync/update
>> debian/* in the xenomai.org dev repository.

Do you have the resources to update debian/* on xenomai.org just before 
each release is made?  I don't think it's necessary to update it any 
more often than that.  I'm assuming that you eventually package each 
release anyway, so it would be nice to do it before a release is made 
official.  Of course, if you don't have time for that or your 
availability doesn't line up with the timeframe for a release, that is 
understandable.  I am just asking if the problem is trying to keep the 
git repository up to date all the time, or if you don't even have time 
to do it for each release.

> I understand that. You already maintain a debian directory on your side,
> you have absolutely no reason to maintain the debian directory of the
> xenomai project.
>
> Anyway, what I would like to know if people find useful the "feature" of
> shipping with a debian directory.

I find it useful, and have not had any trouble with it not working 
before.  That being said, I wouldn't object to getting the debian 
directory from another location, as long as the information at:

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

is updated with detailed instructions on exactly how to download, 
extract, and graft the appropriate debian directory into a xenomai 
source tree that was created from a release tarball or git repository.

Thank you for providing a mechanism to easily build debian packages.  I 
find it very valuable for many reasons.

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Roland Stigge]

On 07/12/2012 05:14 PM, Jeff Webb wrote:
>>> I unfortunately don't have the ressources to regularly sync/update
>>> debian/* in the xenomai.org dev repository.
> 
> Do you have the resources to update debian/* on xenomai.org just before
> each release is made?  I don't think it's necessary to update it any
> more often than that.  I'm assuming that you eventually package each
> release anyway, so it would be nice to do it before a release is made
> official.  Of course, if you don't have time for that or your
> availability doesn't line up with the timeframe for a release, that is
> understandable.  I am just asking if the problem is trying to keep the
> git repository up to date all the time, or if you don't even have time
> to do it for each release.

It would be possible for me if I get ~2 weeks notice before a Xenomai
release to already do _before_ the Xenomai release what I would normally
do _afterwards_ anyway (for Debian). Gilles, is this possible?

But keep in mind that from time to time Debian does intermitted
revisions and it would be necessary to synchronize with xenomai.org.
Much duplicated work that I would like to prevent.

Looks like this feature is more popular than I was thinking, so I'll try
my best.

BTW: There is the patch tracker at

	http://packages.qa.debian.org/x/xenomai.html

(see down on the right)

which could be used for automating or helping with sync with incremental
Debian revisions?

Gilles? Philippe?

> I find it useful, and have not had any trouble with it not working
> before.  That being said, I wouldn't object to getting the debian
> directory from another location, as long as the information at:
> 
>  http://www.xenomai.org/index.php/Building_Debian_packages
> 
> is updated with detailed instructions on exactly how to download,
> extract, and graft the appropriate debian directory into a xenomai
> source tree that was created from a release tarball or git repository.

I remember having updated one of those pages, but the current version
quite deviated. Hope everything works fine?

Thanks,

Roland

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Gilles Chanteperdrix]

On 07/12/2012 05:41 PM, Roland Stigge wrote:
> On 07/12/2012 05:14 PM, Jeff Webb wrote:
>>>> I unfortunately don't have the ressources to regularly sync/update
>>>> debian/* in the xenomai.org dev repository.
>>
>> Do you have the resources to update debian/* on xenomai.org just before
>> each release is made?  I don't think it's necessary to update it any
>> more often than that.  I'm assuming that you eventually package each
>> release anyway, so it would be nice to do it before a release is made
>> official.  Of course, if you don't have time for that or your
>> availability doesn't line up with the timeframe for a release, that is
>> understandable.  I am just asking if the problem is trying to keep the
>> git repository up to date all the time, or if you don't even have time
>> to do it for each release.
> 
> It would be possible for me if I get ~2 weeks notice before a Xenomai
> release to already do _before_ the Xenomai release what I would normally
> do _afterwards_ anyway (for Debian). Gilles, is this possible?

Yes, it is possible, of course.

Next question: the current debian directory is (I believe), compatible
with Debian stable. The rationale being that it allows people to install
the latest xenomai revision on Debian stable.

Is this "feature" useful, or simply something that nobody does (I feel
few people are using Debian stable these days)?

-- 
					    Gilles.

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Roland Stigge]

On 07/12/2012 05:49 PM, Gilles Chanteperdrix wrote:
> On 07/12/2012 05:41 PM, Roland Stigge wrote:
>> On 07/12/2012 05:14 PM, Jeff Webb wrote:
>>>>> I unfortunately don't have the ressources to regularly sync/update
>>>>> debian/* in the xenomai.org dev repository.
>>>
>>> Do you have the resources to update debian/* on xenomai.org just before
>>> each release is made?  I don't think it's necessary to update it any
>>> more often than that.  I'm assuming that you eventually package each
>>> release anyway, so it would be nice to do it before a release is made
>>> official.  Of course, if you don't have time for that or your
>>> availability doesn't line up with the timeframe for a release, that is
>>> understandable.  I am just asking if the problem is trying to keep the
>>> git repository up to date all the time, or if you don't even have time
>>> to do it for each release.
>>
>> It would be possible for me if I get ~2 weeks notice before a Xenomai
>> release to already do _before_ the Xenomai release what I would normally
>> do _afterwards_ anyway (for Debian). Gilles, is this possible?
> 
> Yes, it is possible, of course.
> 
> Next question: the current debian directory is (I believe), compatible
> with Debian stable. The rationale being that it allows people to install
> the latest xenomai revision on Debian stable.

Yes, that makes sense. All other targets are moving too quickly. ;-)

A build using this debian/* will also most often work (but not
guaranteed to be working always) on Debian testing/unstable. (In
contrast to testing/unstable's debian/* which will often break on Debian
stable systems.)

Responsible users would either use Debian stable, or be proficient
enough to know the differences between stable/testing/unstable and be
able to tweak things.

Roland

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Willy Lambert]

2012/7/12 Roland Stigge <stigge@antcom.de>

> On 07/12/2012 05:49 PM, Gilles Chanteperdrix wrote:
> > On 07/12/2012 05:41 PM, Roland Stigge wrote:
> >> On 07/12/2012 05:14 PM, Jeff Webb wrote:
> >>>>> I unfortunately don't have the ressources to regularly sync/update
> >>>>> debian/* in the xenomai.org dev repository.
> >>>
> >>> Do you have the resources to update debian/* on xenomai.org just
> before
> >>> each release is made?  I don't think it's necessary to update it any
> >>> more often than that.  I'm assuming that you eventually package each
> >>> release anyway, so it would be nice to do it before a release is made
> >>> official.  Of course, if you don't have time for that or your
> >>> availability doesn't line up with the timeframe for a release, that is
> >>> understandable.  I am just asking if the problem is trying to keep the
> >>> git repository up to date all the time, or if you don't even have time
> >>> to do it for each release.
> >>
> >> It would be possible for me if I get ~2 weeks notice before a Xenomai
> >> release to already do _before_ the Xenomai release what I would normally
> >> do _afterwards_ anyway (for Debian). Gilles, is this possible?
> >
> > Yes, it is possible, of course.
> >
> > Next question: the current debian directory is (I believe), compatible
> > with Debian stable. The rationale being that it allows people to install
> > the latest xenomai revision on Debian stable.
>
> Yes, that makes sense. All other targets are moving too quickly. ;-)
>
>
+1, especially since last year when unstable squeeze switched to stable.


> A build using this debian/* will also most often work (but not
> guaranteed to be working always) on Debian testing/unstable. (In
> contrast to testing/unstable's debian/* which will often break on Debian
> stable systems.)
>
> Responsible users would either use Debian stable, or be proficient
> enough to know the differences between stable/testing/unstable and be
> able to tweak things.
>
> Roland
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Leopold Palomo-Avellaneda]

A Dijous 12 Juliol 2012, Gilles Chanteperdrix va escriure:
> On 07/12/2012 05:41 PM, Roland Stigge wrote:
> > On 07/12/2012 05:14 PM, Jeff Webb wrote:
> >>>> I unfortunately don't have the ressources to regularly sync/update
> >>>> debian/* in the xenomai.org dev repository.
> >>
> >> Do you have the resources to update debian/* on xenomai.org just before
> >> each release is made?  I don't think it's necessary to update it any
> >> more often than that.  I'm assuming that you eventually package each
> >> release anyway, so it would be nice to do it before a release is made
> >> official.  Of course, if you don't have time for that or your
> >> availability doesn't line up with the timeframe for a release, that is
> >> understandable.  I am just asking if the problem is trying to keep the
> >> git repository up to date all the time, or if you don't even have time
> >> to do it for each release.
> > 
> > It would be possible for me if I get ~2 weeks notice before a Xenomai
> > release to already do _before_ the Xenomai release what I would normally
> > do _afterwards_ anyway (for Debian). Gilles, is this possible?
> 
> Yes, it is possible, of course.
> 
> Next question: the current debian directory is (I believe), compatible
> with Debian stable. The rationale being that it allows people to install
> the latest xenomai revision on Debian stable.
> 
> Is this "feature" useful, or simply something that nobody does (I feel
> few people are using Debian stable these days)?
> 

well, I'm now trying to compile 2.6.1 in a Debian stable. Now there's another 
bug, in the package of the patches (linux-patch-xenomai_2.6.1_all.deb). The 
rules script call to prepare-patch.sh, and this script has this line:

find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*-$supported_arch-*.patch"

that changed to 

find $xenomai_root/ksrc/ -name "*ipipe*$supported_arch-*.patch" |

make the package filled with all patches. However, I don't know the pre patch 
i post patch question, and how will be affected in the debian package.

About the Gilles question did .... YES!!! it's useful. I'm maintaining a group 
of boxes with stable and I would like to use the latest version of xenomai. 

And, not a few people are using Debian stable ....


-- 
--
Linux User 152692
Catalonia

Re: [Xenomai] Debian packaging bug in Xenomai v2.6.1

[Gilles Chanteperdrix]

On 07/13/2012 01:21 PM, Leopold Palomo-Avellaneda wrote:
> A Dijous 12 Juliol 2012, Gilles Chanteperdrix va escriure:
>> On 07/12/2012 05:41 PM, Roland Stigge wrote:
>>> On 07/12/2012 05:14 PM, Jeff Webb wrote:
>>>>>> I unfortunately don't have the ressources to regularly sync/update
>>>>>> debian/* in the xenomai.org dev repository.
>>>>
>>>> Do you have the resources to update debian/* on xenomai.org just before
>>>> each release is made?  I don't think it's necessary to update it any
>>>> more often than that.  I'm assuming that you eventually package each
>>>> release anyway, so it would be nice to do it before a release is made
>>>> official.  Of course, if you don't have time for that or your
>>>> availability doesn't line up with the timeframe for a release, that is
>>>> understandable.  I am just asking if the problem is trying to keep the
>>>> git repository up to date all the time, or if you don't even have time
>>>> to do it for each release.
>>>
>>> It would be possible for me if I get ~2 weeks notice before a Xenomai
>>> release to already do _before_ the Xenomai release what I would normally
>>> do _afterwards_ anyway (for Debian). Gilles, is this possible?
>>
>> Yes, it is possible, of course.
>>
>> Next question: the current debian directory is (I believe), compatible
>> with Debian stable. The rationale being that it allows people to install
>> the latest xenomai revision on Debian stable.
>>
>> Is this "feature" useful, or simply something that nobody does (I feel
>> few people are using Debian stable these days)?
>>
> 
> well, I'm now trying to compile 2.6.1 in a Debian stable. Now there's another 
> bug, in the package of the patches (linux-patch-xenomai_2.6.1_all.deb). The 
> rules script call to prepare-patch.sh, and this script has this line:
> 
> find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*-$supported_arch-*.patch"
> 
> that changed to 
> 
> find $xenomai_root/ksrc/ -name "*ipipe*$supported_arch-*.patch" |
> 
> make the package filled with all patches. However, I don't know the pre patch 
> i post patch question, and how will be affected in the debian package.

That is the problem, we have not had someone really dedicated to the
maintenance of xenomai package debian directory. So, it bitrots. But now
Roland has agreed to maintain it.

> 
> About the Gilles question did .... YES!!! it's useful. I'm maintaining a group 
> of boxes with stable and I would like to use the latest version of xenomai. 
> 
> And, not a few people are using Debian stable ....

I am a Debian stable user too... but it has become a common troll
subject these days.

-- 
					    Gilles.