Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Hi, Gilles Chanteperdrix wrote: the way Debian maintained a patch to the ssh package is the reason why a bug could remain unnoticed during two years in Debian distributions, including so-called stable distributions. So, maybe it is time for a change. First, it doesn't matter most how you maintain a patch. Most important is that sufficient code review is done, which unfortunately didn't happen in the libssl case. Second, the actual libssl patch in .diff.gz was the following: === diff -u openssl-0.9.8g/crypto/rand/md_rand.c openssl-0.9.8g/crypto/rand/md_rand.c --- openssl-0.9.8g/crypto/rand/md_rand.c +++ openssl-0.9.8g/crypto/rand/md_rand.c @@ -271,7 +271,10 @@ else MD_Update(m,(state[st_idx]),j); +/* + * Don't add uninitialised data. MD_Update(m,buf,j); +*/ MD_Update(m,(unsigned char *)(md_c[0]),sizeof(md_c)); MD_Final(m,local_md); md_c[1]++; === I.e. quite clear in my opinion. It wouldn't be if Debian wouldn't ship .diff.gz separately. (The above patch was actually reported upstream and there was no objection.) Third, the above case is different from our case: While I consider debian/* as Debian specific, the above patch was not Debian specific (it was actually introduced to ease valgrind usage). Therefore, I even consider the libssl patch style (not the semantics! :-) ) above as good; but patching debian/* in Debian's diff.gz as bad. Fourth, you are proposing the same patching technique as above (which you criticize as not appropriate). But of course, if you insist, this probably can be worked around by writing some merging script. Yeah, maybe this is the way to go. Easy to implement and minimizes the work for all participants. bye, Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
On Tue, May 27, 2008 at 11:00 AM, Roland Stigge [EMAIL PROTECTED] wrote: Hi, Gilles Chanteperdrix wrote: the way Debian maintained a patch to the ssh package is the reason why a bug could remain unnoticed during two years in Debian distributions, including so-called stable distributions. So, maybe it is time for a change. First, it doesn't matter most how you maintain a patch. Most important is that sufficient code review is done, which unfortunately didn't happen in the libssl case. Second, the actual libssl patch in .diff.gz was the following: === diff -u openssl-0.9.8g/crypto/rand/md_rand.c openssl-0.9.8g/crypto/rand/md_rand.c --- openssl-0.9.8g/crypto/rand/md_rand.c +++ openssl-0.9.8g/crypto/rand/md_rand.c @@ -271,7 +271,10 @@ else MD_Update(m,(state[st_idx]),j); +/* + * Don't add uninitialised data. MD_Update(m,buf,j); +*/ MD_Update(m,(unsigned char *)(md_c[0]),sizeof(md_c)); MD_Final(m,local_md); md_c[1]++; === I.e. quite clear in my opinion. It wouldn't be if Debian wouldn't ship .diff.gz separately. (The above patch was actually reported upstream and there was no objection.) Third, the above case is different from our case: While I consider debian/* as Debian specific, the above patch was not Debian specific (it was actually introduced to ease valgrind usage). Therefore, I even consider the libssl patch style (not the semantics! :-) ) above as good; but patching debian/* in Debian's diff.gz as bad. Fourth, you are proposing the same patching technique as above (which you criticize as not appropriate). What I criticize is patching without submitting patches upstream, or without consulting upstream package maintainers, or making debian patches hard to apply upstream. For instance I saw there was a bug with generating debian packages for ARM. Instead of reporting this bug upstream, which, as the maintainer of Xenomai ARM port, I could have helped to resolve, you chose to resolve the bug silently, but unfortunately chose a solution which will not work with the imx21 and more generally for machines which do not provide tsc emulation in user-space based on a free-running counter. The proper solution is to add a generic architecture to the --enable-arm-mach option of the configure script, which sets the architecture to 4, disables the tsc emulation, and enables the SA1100 quirks. I will try to do this for the 2.4.4 release. But of course, if you insist, this probably can be worked around by writing some merging script. Yeah, maybe this is the way to go. Easy to implement and minimizes the work for all participants. Ok. Will do that. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Hi, Gilles Chanteperdrix wrote: What I criticize is patching without submitting patches upstream, or without consulting upstream package maintainers, or making debian patches hard to apply upstream. I both submitted to Xenomai upstream and provided an easy patch (not even assuming the stripped debian/*), you should be fully satisfied now... ;-) For the libssl case, it was basically the same, as I understand it. (I'm not involved into Debian's openssl packaging, though.) For instance I saw there was a bug with generating debian packages for ARM. Instead of reporting this bug upstream, which, as the maintainer of Xenomai ARM port, I could have helped to resolve, you chose to resolve the bug silently [...] I just incorporated the patch by Riku Voipio for Debian #477720 which resolved the problem for Debian's ARM porters. (Further, I sent you the patch in a convenient way...) If you have further improvements in 2.4.4, fine. :-) bye, Roland PS: I hope it doesn't look to the others like we are complaining about each other's work. So for the rest of xenomai-core developers: This is just mine and Gilles' way to say thanks for your work to each other. ;-))) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
On Tue, May 27, 2008 at 3:19 PM, Roland Stigge [EMAIL PROTECTED] wrote: Hi, Gilles Chanteperdrix wrote: What I criticize is patching without submitting patches upstream, or without consulting upstream package maintainers, or making debian patches hard to apply upstream. I both submitted to Xenomai upstream and provided an easy patch (not even assuming the stripped debian/*), you should be fully satisfied now... ;-) For the libssl case, it was basically the same, as I understand it. (I'm not involved into Debian's openssl packaging, though.) For instance I saw there was a bug with generating debian packages for ARM. Instead of reporting this bug upstream, which, as the maintainer of Xenomai ARM port, I could have helped to resolve, you chose to resolve the bug silently [...] I just incorporated the patch by Riku Voipio for Debian #477720 which resolved the problem for Debian's ARM porters. (Further, I sent you the patch in a convenient way...) If you have further improvements in 2.4.4, fine. :-) Ok. I have no excuse, it was even in the changelog if I did not want to read the whole patch. But technically you did not announce the 2.4.3-7 patch on Xenomai mailing list :-) PS: I hope it doesn't look to the others like we are complaining about each other's work. So for the rest of xenomai-core developers: This is just mine and Gilles' way to say thanks for your work to each other. ;-))) Yes, I should stress that I consider it as a great advance for the Xenomai project to have a Debian package, and thank you for the packaging hard work. -- Gilles ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Roland Stigge wrote: Hi, Gilles Chanteperdrix wrote: Shipping the xenomai tarball with the debian directory has a real added value: it allows people to build debian package without anything else, this is an unofficial package, of course, but it can be built before the Debian patch is generated. Well, for people who catch the package within the few hours between Xenomai release and the Debian version of it. ;-) We like the Xenomai package to be as much self-contained as possible, which is why it ships with the generated autotools files, the generated documentation, the drivers and examples directories, and why I would prefer it to ship with a working debian directory. IMO, it would make your life easier if you considered the debian directory part of the Xenomai package, and start working from this directory. If you ask for it, we can probably even give you write access to the repository, so that the debian packaging effort is fully integrated to Xenomai. As discussed earlier this year: Every Debian package is a (small) fork of the respective upstream release, with own Debian release numbers between upstream releases, e.g. 2.4.4-1 and 2.4.4-2. Maintaining this at xenomai.org would require branches on every (minor) Xenomai release, e.g. 2.4.3 and 2.4.4 (besides me having repository write access), because Debian revisions usually come out more often than upstream versions (as you have seen 2.4.3-1 ... 2.4.3-7). Therefore, I prefer maintaining it at Debian like most other packages. We already have trunk and the stable release branches at xenomai.org. The above would require an additional level of branching, maintenance and synchronization work. Another solution at Debian is called native packages where Debian revisions and upstream versions are synchronized (i.e. no separate Debian revisions). The problem here is that at every point in time, Debian can decide to do a new revision (e.g. within a few hours on security fixes) which may not be in the interest of other xenomai maintainers. E.g. this way, Debian would decide when 2.4.5 and 2.4.6 (or 2.4.4.1 and 2.4.4.2?) will be released. This doesn't scale well with the number of Linux distros. ;) For non-native packages in Debian (as Xenomai is currently), the debian/ directory is separated out into the .diff.gz patch which is good for seeing how e.g. debian/rules looks like. If I would take the current upstream tarball and only patch debian/rules in the diff.gz, the resulting contents of the file is no recognizable from the patch alone. Therefore, this is not common practice in Debian. Further, it's not only me who works on Debian packages. Sometimes, when I'm not available, one of the other 1000 Debian developers will do Debian adjustments to the xenomai package in Debian. I guess you don't want to give all of them write access to xenomai.org. ;) So you have the choice between the following possibilities: 1) Leave the process as it is (Debian using the upstream tarball, stripped from debian/*, and adding an own debian/* in a separately shipped patch) 2) Give me (and maybe Debian as a whole) write access to Xenomai.org and the right to branch at every normal Xenomai release, doing Debian revisions. Problem here: Additional work for Debian because not only Debian revisions must be done but also synchronization to the v2.4.x (stable) brach and trunk. (I.e. changes are most often in 3 places) 3) Give me (and maybe Debian as a whole) write access to Xenomai.org and the right to do xenomai releases whenever Debian wants (i.e. native Debian package) I guess you prefer (1)? ;-) I am sorry to use this argument, because I love Debian as an end-user (actually, I installed my first Debian in 1997 and upgraded it until now, copying my hard disks when changing machines), but as far as I understood, the way Debian maintained a patch to the ssh package is the reason why a bug could remain unnoticed during two years in Debian distributions, including so-called stable distributions. So, maybe it is time for a change. The only problem I have with the current scheme is that merging back debian patches in xenomai repository is rendered hard by the fact that the patch is generated against an empty debian directory. So, it looks to me like it would be much simpler for you to simply keep Xenomai own debian directory and generate patches against it. Of course it makes the patch a bit less readable, but I do not see how it violates a Debian policy. But of course, if you insist, this probably can be worked around by writing some merging script. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Hi,
Gilles Chanteperdrix wrote:
So feel free to do a 2.4.4 (or whatever) release soon. :-)
(For integrating the Debian changes in addition to the respective
upstream changes, just remove the man pages in debian/,
debian/xenomai-runtime.manpages and the /bin/bash patch.)
I would have felt more comfortable if you could have done it (and more
importantly test it). Besides, the 2.4.4 release is coming, and I would
have liked to release it with all the changes that you made.
I'm attaching a patch that I would apply to branches/v2.4.x if it would
be considered as 2.4.4.
Please note that on integrating Xenomai 2.4.4 (or whatever) upstream in
Debian, I will strip debian/* from the original tarball to separate the
Debian part from upstream. For the same reason, please consider to
remove it from the tarball. (It can stay in SVN, though.)
bye,
Roland
diff -ruN xenomai-2.4.x/configure.in debian/xenomai-2.4.4/configure.in
--- xenomai-2.4.x/configure.in 2008-05-26 13:23:26.0 +0200
+++ debian/xenomai-2.4.4/configure.in 2008-05-26 11:55:24.0 +0200
@@ -799,6 +799,17 @@
doc/Makefile \
doc/txt/Makefile \
doc/man/Makefile \
+ doc/man/clocktest.man \
+ doc/man/cyclictest.man \
+ doc/man/irqbench.man \
+ doc/man/irqloop.man \
+ doc/man/klatency.man \
+ doc/man/latency.man \
+ doc/man/rtcanconfig.man \
+ doc/man/rtcanrecv.man \
+ doc/man/rtcansend.man \
+ doc/man/switchbench.man \
+ doc/man/switchtest.man \
doc/man/runinfo.man \
doc/man/xeno-config.man \
doc/man/xeno-info.man \
diff -ruN xenomai-2.4.x/debian/changelog debian/xenomai-2.4.4/debian/changelog
--- xenomai-2.4.x/debian/changelog 2008-05-26 10:52:55.0 +0200
+++ debian/xenomai-2.4.4/debian/changelog 2008-05-26 12:32:42.0 +0200
@@ -1,3 +1,63 @@
+xenomai (2.4.4-1) unstable; urgency=low
+
+ * New upstream release
+
+ -- Roland Stigge [EMAIL PROTECTED] Mon, 26 May 2008 11:58:30 +0200
+
+xenomai (2.4.3-7) unstable; urgency=low
+
+ * Included patch from Riku Voipio to fix ARM compile issues
+(Closes: #477720)
+
+ -- Roland Stigge [EMAIL PROTECTED] Thu, 24 Apr 2008 23:18:01 +0200
+
+xenomai (2.4.3-6) unstable; urgency=low
+
+ * Added lintian override for recursive include directories (necessary
+according to upstream)
+ * Added missing man pages (can be removed when integrated upstream)
+ * debian/rules: Fixed klatency/run script to be proper shell script
+
+ -- Roland Stigge [EMAIL PROTECTED] Tue, 22 Apr 2008 12:23:22 +0200
+
+xenomai (2.4.3-5) unstable; urgency=low
+
+ * Install xeno-config into libxenomai-dev where the executable is
+
+ -- Roland Stigge [EMAIL PROTECTED] Sat, 19 Apr 2008 22:15:07 +0200
+
+xenomai (2.4.3-4) unstable; urgency=low
+
+ * Move /usr/lib/xenomai to original upstream /usr/share/xenomai
+
+ -- Roland Stigge [EMAIL PROTECTED] Fri, 18 Apr 2008 19:51:49 +0200
+
+xenomai (2.4.3-3) unstable; urgency=low
+
+ * debian/rules: Separated prepare-patch.sh calls for individual
+architectures (Closes: #473098)
+
+ -- Roland Stigge [EMAIL PROTECTED] Thu, 10 Apr 2008 10:01:33 +0200
+
+xenomai (2.4.3-2) unstable; urgency=low
+
+ * Enable x86 patches for both i386 and amd64 (Closes: #473098)
+
+ -- Roland Stigge [EMAIL PROTECTED] Tue, 01 Apr 2008 10:04:51 +0200
+
+xenomai (2.4.3-1) unstable; urgency=low
+
+ * New upstream release
+ * Added debian/watch
+
+ -- Roland Stigge [EMAIL PROTECTED] Tue, 25 Mar 2008 14:13:50 +0100
+
+xenomai (2.4.2-3) unstable; urgency=low
+
+ * Fixed bashisms by using #!/bin/bash (Closes: #471871)
+
+ -- Roland Stigge [EMAIL PROTECTED] Sat, 22 Mar 2008 17:01:11 +0100
+
xenomai (2.4.2-2) unstable; urgency=low
* debian/copyright: Refined Copyrights
diff -ruN xenomai-2.4.x/debian/control debian/xenomai-2.4.4/debian/control
--- xenomai-2.4.x/debian/control 2008-05-26 10:52:55.0 +0200
+++ debian/xenomai-2.4.4/debian/control 2008-05-26 11:58:29.0 +0200
@@ -8,7 +8,7 @@
Package: xenomai-runtime
Section: devel
-Architecture: amd64 arm i386 ia64 powerpc
+Architecture: amd64 arm armeb armel i386 ia64 powerpc
Depends: ${shlibs:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
@@ -47,7 +47,7 @@
Package: libxenomai1
Section: libs
-Architecture: amd64 arm i386 ia64 powerpc
+Architecture: amd64 arm armeb armel i386 ia64 powerpc
Depends: ${shlibs:Depends}
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
@@ -64,7 +64,7 @@
Package: libxenomai-dev
Section: libdevel
-Architecture: amd64 arm i386 ia64 powerpc
+Architecture: amd64 arm armeb armel i386 ia64 powerpc
Depends: libxenomai1 (= ${binary:Version})
Suggests: linux-patch-xenomai, xenomai-doc
Replaces: xenomai
diff -ruN xenomai-2.4.x/debian/libxenomai1.lintian debian/xenomai-2.4.4/debian/libxenomai1.lintian
--- xenomai-2.4.x/debian/libxenomai1.lintian 2008-05-26 10:52:55.0 +0200
+++ debian/xenomai-2.4.4/debian/libxenomai1.lintian 2008-05-26 11:58:29.0 +0200
@@ -1 +1,2 @@
+# no contained shared library names refer
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Hi, Gilles Chanteperdrix wrote: Shipping the xenomai tarball with the debian directory has a real added value: it allows people to build debian package without anything else, this is an unofficial package, of course, but it can be built before the Debian patch is generated. Well, for people who catch the package within the few hours between Xenomai release and the Debian version of it. ;-) IMO, it would make your life easier if you considered the debian directory part of the Xenomai package, and start working from this directory. If you ask for it, we can probably even give you write access to the repository, so that the debian packaging effort is fully integrated to Xenomai. As discussed earlier this year: Every Debian package is a (small) fork of the respective upstream release, with own Debian release numbers between upstream releases, e.g. 2.4.4-1 and 2.4.4-2. Maintaining this at xenomai.org would require branches on every (minor) Xenomai release, e.g. 2.4.3 and 2.4.4 (besides me having repository write access), because Debian revisions usually come out more often than upstream versions (as you have seen 2.4.3-1 ... 2.4.3-7). Therefore, I prefer maintaining it at Debian like most other packages. We already have trunk and the stable release branches at xenomai.org. The above would require an additional level of branching, maintenance and synchronization work. Another solution at Debian is called native packages where Debian revisions and upstream versions are synchronized (i.e. no separate Debian revisions). The problem here is that at every point in time, Debian can decide to do a new revision (e.g. within a few hours on security fixes) which may not be in the interest of other xenomai maintainers. E.g. this way, Debian would decide when 2.4.5 and 2.4.6 (or 2.4.4.1 and 2.4.4.2?) will be released. This doesn't scale well with the number of Linux distros. ;) For non-native packages in Debian (as Xenomai is currently), the debian/ directory is separated out into the .diff.gz patch which is good for seeing how e.g. debian/rules looks like. If I would take the current upstream tarball and only patch debian/rules in the diff.gz, the resulting contents of the file is no recognizable from the patch alone. Therefore, this is not common practice in Debian. Further, it's not only me who works on Debian packages. Sometimes, when I'm not available, one of the other 1000 Debian developers will do Debian adjustments to the xenomai package in Debian. I guess you don't want to give all of them write access to xenomai.org. ;) So you have the choice between the following possibilities: 1) Leave the process as it is (Debian using the upstream tarball, stripped from debian/*, and adding an own debian/* in a separately shipped patch) 2) Give me (and maybe Debian as a whole) write access to Xenomai.org and the right to branch at every normal Xenomai release, doing Debian revisions. Problem here: Additional work for Debian because not only Debian revisions must be done but also synchronization to the v2.4.x (stable) brach and trunk. (I.e. changes are most often in 3 places) 3) Give me (and maybe Debian as a whole) write access to Xenomai.org and the right to do xenomai releases whenever Debian wants (i.e. native Debian package) I guess you prefer (1)? ;-) bye, Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Roland Stigge wrote: [Warning: First in a series of several issues applicable to xenomai.org's code.] Hi, at http://packages.qa.debian.org/x/xenomai.html, you can find the latest version of Debian's package xenomai. The diff to xenomai 2.4.3 applies to the normal Xenomai distribution with an empty debian/ directory. Feel free to synchronize the Debian changes back to the mainline Xenomai repository, especially the Debian packaging has been fixed. Hi Roland, I am trying to merge the debian changes back into Xenomai, however, I have two problems: - I can not find back the 2.4.3-4 patch, I only find 2.4.3-7; - I do not want to merge changes that replace /bin/sh with /bin/bash since we fixed the bashism the right way (it is important for people of the embedded world, that Xenomai does not require /bin/bash, since embedded boxes may use other shells); - I do not want to include the manual pages in the debian/ sub-directory since I merged your patch adding manual pages to the proper place. So, could you re-generate a patch using Xenomai v2.4.x branch fixing these two issues ? I promise, this time I will not wait one month before merging the changes. Thanks in advance. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Hi Gilles, thanks for your response. ;-))) Gilles Chanteperdrix wrote: I am trying to merge the debian changes back into Xenomai, however, I have two problems: - I can not find back the 2.4.3-4 patch, I only find 2.4.3-7; No problem - always just take the latest one, currently 2.4.3-7. - I do not want to merge changes that replace /bin/sh with /bin/bash since we fixed the bashism the right way (it is important for people of the embedded world, that Xenomai does not require /bin/bash, since embedded boxes may use other shells); - I do not want to include the manual pages in the debian/ sub-directory since I merged your patch adding manual pages to the proper place. Fine. Just do the changes the way you like it Xenomai (upstream): Bashism fixes and man pages in the proper upstream place. On next merge from Xenomai (e.g. 2.4.4 to Debian 2.4.4-1), I will synchronize it from xenomai.org. For 2.4.3, the respective change would require maintainer script regeneration due to changes in Makefile.am's, which I would like to prevent. So feel free to do a 2.4.4 (or whatever) release soon. :-) (For integrating the Debian changes in addition to the respective upstream changes, just remove the man pages in debian/, debian/xenomai-runtime.manpages and the /bin/bash patch.) bye, Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Roland Stigge wrote: Hi Gilles, thanks for your response. ;-))) Gilles Chanteperdrix wrote: I am trying to merge the debian changes back into Xenomai, however, I have two problems: - I can not find back the 2.4.3-4 patch, I only find 2.4.3-7; No problem - always just take the latest one, currently 2.4.3-7. - I do not want to merge changes that replace /bin/sh with /bin/bash since we fixed the bashism the right way (it is important for people of the embedded world, that Xenomai does not require /bin/bash, since embedded boxes may use other shells); - I do not want to include the manual pages in the debian/ sub-directory since I merged your patch adding manual pages to the proper place. Fine. Just do the changes the way you like it Xenomai (upstream): Bashism fixes and man pages in the proper upstream place. On next merge from Xenomai (e.g. 2.4.4 to Debian 2.4.4-1), I will synchronize it from xenomai.org. For 2.4.3, the respective change would require maintainer script regeneration due to changes in Makefile.am's, which I would like to prevent. So feel free to do a 2.4.4 (or whatever) release soon. :-) (For integrating the Debian changes in addition to the respective upstream changes, just remove the man pages in debian/, debian/xenomai-runtime.manpages and the /bin/bash patch.) I would have felt more comfortable if you could have done it (and more importantly test it). Besides, the 2.4.4 release is coming, and I would have liked to release it with all the changes that you made. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Debian package xenomai-2.4.3-4 available
Roland Stigge wrote: [Warning: First in a series of several issues applicable to xenomai.org's code.] Hi, at http://packages.qa.debian.org/x/xenomai.html, you can find the latest version of Debian's package xenomai. The diff to xenomai 2.4.3 applies to the normal Xenomai distribution with an empty debian/ directory. Feel free to synchronize the Debian changes back to the mainline Xenomai repository, especially the Debian packaging has been fixed. Hi Roland, reading your mail, I realize that the patch to remove the few bashisms in xenomai scripts was forgotten. So, since nobody complained, I will apply it now, so that you will not have to replace /bin/sh with /bin/bash in the next release. Thanks for your work. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Debian package xenomai-2.4.3-4 available
[Warning: First in a series of several issues applicable to xenomai.org's code.] Hi, at http://packages.qa.debian.org/x/xenomai.html, you can find the latest version of Debian's package xenomai. The diff to xenomai 2.4.3 applies to the normal Xenomai distribution with an empty debian/ directory. Feel free to synchronize the Debian changes back to the mainline Xenomai repository, especially the Debian packaging has been fixed. Thanks, Roland ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
