[Xenomai-core] Xenomai v2.4-rc6

[Xenomai-core] Xenomai v2.4-rc6

[Philippe Gerum]

Here is the sixth candidate release for the v2.4.x branch.

	[nucleus]

	* LTT support overhaul.
	* Fix select() breakage with message pipes.
	* Return EOF condition to the real-time side when the Linux
          peer closes the message pipe.

	[i386, x86_64 => x86]

	* Merge i386 and x86_64 arch-dep support as x86.
 	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.

	[posix]

	* Fix pthread_cond_*wait() handling of signal receipt.

	[native]

	* Fix API for requesting I/O regions; add support for IOMEM
          space. See API.CHANGES for more.
	* Allow rt_task_inquire() to only probe for the existence of a
          task.
	
	[psos]

	* Provide tm_getc() service to get the count of elapsed
          ticks for the pSOS timebase.

	[rtai]

	* Set up default CPU affinity for tasks.
	* Fix shared memory allocation for small heap sizes.

http://download.gna.org/xenomai/testing/xenomai-2.4-rc6.tar.bz2

-- 
Philippe.

Re: [Xenomai-help] Xenomai v2.4-rc6

[Leopold Palomo-Avellaneda]

A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
> Here is the sixth candidate release for the v2.4.x branch.
[....]
>
> 	[i386, x86_64 => x86]
>
> 	* Merge i386 and x86_64 arch-dep support as x86.
>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.

[...]

this has break the creation of the debian packages. I can understand that 
conceptually they are the same arch (one with 32bits and another with 64 and 
more extensions) in general _all_ the distros treat them as two different 
arch. So this changes break things. I don't think that it's a good idea do it 
in a release candidate, IMHO.

Regards,

Leo

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Leopold Palomo-Avellaneda wrote:
> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
>> Here is the sixth candidate release for the v2.4.x branch.
> [....]
>> 	[i386, x86_64 => x86]
>>
>> 	* Merge i386 and x86_64 arch-dep support as x86.
>>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
> 
> [...]
> 
> this has break the creation of the debian packages. I can understand that 
> conceptually they are the same arch (one with 32bits and another with 64 and 
> more extensions) in general _all_ the distros treat them as two different 
> arch.

How long do you think this is going to be that way, with 2.6.24 actually
merging those supports at kernel level?

 So this changes break things. I don't think that it's a good idea do it
> in a release candidate, IMHO.

We discussed this issue and the reason for doing this change asap in
length on the mailing list two weeks ago or so. Please have a look at
the archive for more. You will also find some significant patches
already exploiting the new common tree in order to streamline the code,
and ease maintenance on our side. Few resources, large work, we have to
be efficient, and maintaining two closely related archs sharing bits in
separate code bases is pointless, and a loss of time for the project.

> 
> Regards,
> 
> Leo
> 


-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Gilles Chanteperdrix]

On Nov 14, 2007 10:56 AM, Leopold Palomo-Avellaneda <lepalom@domain.hid> wrote:
> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
> > Here is the sixth candidate release for the v2.4.x branch.
> [....]
> >
> >       [i386, x86_64 => x86]
> >
> >       * Merge i386 and x86_64 arch-dep support as x86.
> >       * Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
>
> [...]
>
> this has break the creation of the debian packages.

Common, this problem is certainly not insurmountable, I would bet it
is just an issue with the directory name.

-- 
                                               Gilles Chanteperdrix

Re: [Xenomai-help] Xenomai v2.4-rc6

[Leopold Palomo-Avellaneda]

A Dimecres 14 Novembre 2007, Philippe Gerum va escriure:
> Leopold Palomo-Avellaneda wrote:
> > A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
> >> Here is the sixth candidate release for the v2.4.x branch.
> >
> > [....]
> >
> >> 	[i386, x86_64 => x86]
> >>
> >> 	* Merge i386 and x86_64 arch-dep support as x86.
> >>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
> >
> > [...]
> >
> > this has break the creation of the debian packages. I can understand that
> > conceptually they are the same arch (one with 32bits and another with 64
> > and more extensions) in general _all_ the distros treat them as two
> > different arch.
>
> How long do you think this is going to be that way, with 2.6.24 actually
> merging those supports at kernel level?
>
>  So this changes break things. I don't think that it's a good idea do it
>
> > in a release candidate, IMHO.
>
> We discussed this issue and the reason for doing this change asap in
> length on the mailing list two weeks ago or so. Please have a look at
> the archive for more. You will also find some significant patches
> already exploiting the new common tree in order to streamline the code,
> and ease maintenance on our side. Few resources, large work, we have to
> be efficient, and maintaining two closely related archs sharing bits in
> separate code bases is pointless, and a loss of time for the project.
>

Ok,

I'm not subscribing to xenomai-core, so I don't know if this have been 
discussed on the list.

Yes, I didn't have done a search on the web/list about if this have been 
discused, I just have pointed that you are working (with a few resources, 
etc) to release a new version rc-6 and have done a change that break 
our "lazy way" of install/ compile xenomai. I don't know if others things.

I'm sure that you have worked/thought that this is the best way to do the 
things. Now I have read the thread about it and well, it's just a normal 
discussions about to make a important change and the people comment. You as 
project leader have an idea that you think that it's good for the project, 
and you implement it. And other people saying, ok, if you want to do it, I 
will try to help...

I can understand that my post have ..... I don't know the verb in english, in 
catalan will be "tocar-te els collons" and in english something like "touch 
your balls". That's not my intention, really.

I also will try to help it and I will look the debian packages to solve 
this ... ;-) and probably I'm one this strange people that if I use a open 
source soft and I begin I use a release candidate to test it and try help. At 
least some kind of .. please could you run bla, or can you try bla ... but 
I'm not statistically important because I'm not showed at google ;-)

Leo

PS from some mail that I have read:
... sun is still shining, birds are still singing, hardware is not burning - 
yet. 

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Paul]

On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote:
> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
> > Here is the sixth candidate release for the v2.4.x branch.
>
> [....]
>
> > 	[i386, x86_64 => x86]
> >
> > 	* Merge i386 and x86_64 arch-dep support as x86.
> >  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
>
> [...]
>
> this has break the creation of the debian packages. I can understand that
> conceptually they are the same arch (one with 32bits and another with 64
> and more extensions) in general _all_ the distros treat them as two
> different arch. So this changes break things. I don't think that it's a
> good idea do it in a release candidate, IMHO.

I'm right in the middle of looking at the packaging scripts, so expect a patch 
within the next few days.

Giles/Philippe: Is there likely to be a 2.6.24 ipipe patch out before Xenomai 
reaches 2.4.0 ?


Regards, Paul.

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Paul wrote:
> On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote:
>> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
>>> Here is the sixth candidate release for the v2.4.x branch.
>> [....]
>>
>>> 	[i386, x86_64 => x86]
>>>
>>> 	* Merge i386 and x86_64 arch-dep support as x86.
>>>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
>> [...]
>>
>> this has break the creation of the debian packages. I can understand that
>> conceptually they are the same arch (one with 32bits and another with 64
>> and more extensions) in general _all_ the distros treat them as two
>> different arch. So this changes break things. I don't think that it's a
>> good idea do it in a release candidate, IMHO.
> 
> I'm right in the middle of looking at the packaging scripts, so expect a patch 
> within the next few days.
> 
> Giles/Philippe: Is there likely to be a 2.6.24 ipipe patch out before Xenomai 
> reaches 2.4.0 ?
> 
> 

I don't think so, at least for 2.6.26/x86*. Even if we do have an
experimental patch for 2.6.24-rc1/x86, it would make sense to go for a
combo x86_32/64 bit support patch for 2.6.24 directly. To get that, I'd
rather take the needed time to properly merge both I-pipe branches
without any release deadline pressure, and since we already have the
proper infrastructure available in 2.4-rc to run over the latest x86*
kernels, we may provide support for 2.6.24 during the Xenomai 2.4
maintenance cycle anyway.

-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Paul wrote:
> On Wednesday 14 November 2007 09:56, Leopold Palomo-Avellaneda wrote:
>> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
>>> Here is the sixth candidate release for the v2.4.x branch.
>> [....]
>>
>>> 	[i386, x86_64 => x86]
>>>
>>> 	* Merge i386 and x86_64 arch-dep support as x86.
>>>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
>> [...]
>>
>> this has break the creation of the debian packages. I can understand that
>> conceptually they are the same arch (one with 32bits and another with 64
>> and more extensions) in general _all_ the distros treat them as two
>> different arch. So this changes break things. I don't think that it's a
>> good idea do it in a release candidate, IMHO.
> 
> I'm right in the middle of looking at the packaging scripts, so expect a patch 
> within the next few days.
> 
> Giles/Philippe: Is there likely to be a 2.6.24 ipipe patch out before Xenomai 
> reaches 2.4.0 ?
> 
> 

I don't think so, at least for 2.6.24/x86*.

Even if we do have an experimental patch for 2.6.24-rc1/x86, it would
make sense to go for a combo x86_32/64 bit support patch for 2.6.24
directly. To get that, I'd rather take the needed time to properly merge
both I-pipe branches without any release deadline pressure, and since we
already have the proper infrastructure available in 2.4-rc to run over
the latest x86* kernels, we may provide support for 2.6.24 during the
Xenomai 2.4 maintenance cycle anyway.

-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Leopold Palomo-Avellaneda wrote:
> A Dimecres 14 Novembre 2007, Philippe Gerum va escriure:
>> Leopold Palomo-Avellaneda wrote:
>>> A Dimarts 13 Novembre 2007, Philippe Gerum va escriure:
>>>> Here is the sixth candidate release for the v2.4.x branch.
>>> [....]
>>>
>>>> 	[i386, x86_64 => x86]
>>>>
>>>> 	* Merge i386 and x86_64 arch-dep support as x86.
>>>>  	* Update Adeos/i386 support for 2.6.20, 2.6.22 and 2.6.23.
>>> [...]
>>>
>>> this has break the creation of the debian packages. I can understand that
>>> conceptually they are the same arch (one with 32bits and another with 64
>>> and more extensions) in general _all_ the distros treat them as two
>>> different arch.
>> How long do you think this is going to be that way, with 2.6.24 actually
>> merging those supports at kernel level?
>>
>>  So this changes break things. I don't think that it's a good idea do it
>>
>>> in a release candidate, IMHO.
>> We discussed this issue and the reason for doing this change asap in
>> length on the mailing list two weeks ago or so. Please have a look at
>> the archive for more. You will also find some significant patches
>> already exploiting the new common tree in order to streamline the code,
>> and ease maintenance on our side. Few resources, large work, we have to
>> be efficient, and maintaining two closely related archs sharing bits in
>> separate code bases is pointless, and a loss of time for the project.
>>
> 
> Ok,
> 
> I'm not subscribing to xenomai-core, so I don't know if this have been 
> discussed on the list.
> 
> Yes, I didn't have done a search on the web/list about if this have been 
> discused, I just have pointed that you are working (with a few resources, 
> etc) to release a new version rc-6 and have done a change that break 
> our "lazy way" of install/ compile xenomai. I don't know if others things.
> 
> I'm sure that you have worked/thought that this is the best way to do the 
> things. Now I have read the thread about it and well, it's just a normal 
> discussions about to make a important change and the people comment. You as 
> project leader have an idea that you think that it's good for the project, 
> and you implement it. And other people saying, ok, if you want to do it, I 
> will try to help...
> 
> I can understand that my post have ..... I don't know the verb in english, in 
> catalan will be "tocar-te els collons" and in english something like "touch 
> your balls". That's not my intention, really.
>

That's ok. Asbestos underwear should be part of any maintainer's outfit
for that very reason.

> I also will try to help it and I will look the debian packages to solve 
> this ... ;-) and probably I'm one this strange people that if I use a open 
> source soft and I begin I use a release candidate to test it and try help.

Testing -rcS is actually what helps us the most, so I'm not going to
mumble about this, but rather thank you instead.

The actual issue I raised was more about putting things in the right
perspective. We always have to adapt to new kernel releases, and since
we also have to move forward in order to do a better job, distros may
also have to fix things on their side from time to time. This said, we
still try to avoid pointless changes because there is no benefit in
causing havoc downstream just for the "fun" of it (unless the maintainer
really has to get an appointment asap with his favorite shrink, that is).

In the x86* merge case, doing it after 2.4.0 final would have made the
maintenance of 2.4.x way more complex while working on 2.5.x in
parallel, since we would have had two rapidly diverging branches: one
old-fashioned with separate x86* trees, and another one with a merged
support being continuously streamlined. Moving patches both ways would
have been a real pain in the neck, without any upside for us. One has to
keep in mind that a Xenomai maintenance cycle is roughly one year long,
during which we commit to routinely issue bug fix releases, which is not
that bad when you compare to the average free software project.

 At
> least some kind of .. please could you run bla, or can you try bla ... but 
> I'm not statistically important because I'm not showed at google ;-)
> 

Well, Google says that "shrek" amounts for more than 27 millions
matches, but despite this fact, I'm not going to expect any
advice/comment for him regarding Xenomai. So, the best way to move
forward is that real people keep posting comments here, like you've just
done.

-- 
Philippe.

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Paul]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On Wednesday 14 November 2007 16:37, Paul wrote:
> I'm right in the middle of looking at the packaging scripts, so expect a
> patch within the next few days.

Attached, one patch for the Debian rules. The debian/changelog version will 
need to be bumped up to 2.4.0-1 once we get out of the -rc phase. I'll submit 
a trivial patch at that point and build a set of i386 & amd64 packages.

Regards, Paul.





[-- Attachment #2: debian_rules.diff --]
[-- Type: text/x-diff, Size: 3635 bytes --]

Index: debian/changelog
===================================================================
--- debian/changelog	(revision 3182)
+++ debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+xenomai (2.4.0-0+rc6) unstable; urgency=low
+
+  * Update prepare-patch.sh to use combined x86/i386 Xenomai tree.
+  * Split patch generation out of build-stamp so that it only gets
+    called once along with the configure.
+
+ -- Paul Corner <paul_c@domain.hid>  Wed, 14 Nov 2007 21:48:27 +0000
+
 xenomai (2.3.50-05+r2299) unstable; urgency=low
 
   * Add top level ChangeLog and CREDITS to each package.
Index: debian/prepare-patch.sh
===================================================================
--- debian/prepare-patch.sh	(revision 3182)
+++ debian/prepare-patch.sh	(working copy)
@@ -54,7 +54,6 @@ patch_link() {
             if test ! -d  $temp_tree/$link_dir/$d ; then
                 mkdir -p $temp_tree/$link_dir/$d
             fi
-echo " cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f"
             cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f
         done
     )
@@ -77,7 +76,6 @@ generate_patch() {
 diff_addons() {
     lines=`(echo ; echo ; cat $xenomai_root/scripts/Kconfig.frag) | wc -l`
 
-#    echo "diff -u1wbr orig/arch/$linux_arch/Kconfig new/arch/$linux_arch/Kconfig" >> $patch_file
     echo "--- linux/arch/$linux_arch/Kconfig	1970-01-01 01:00:00.000000000 +0100" >> $patch_file
     echo "+++ linux-patched/arch/$linux_arch/Kconfig	2007-03-06 17:55:58.000000000 +0000" >> $patch_file
     echo "@@ -40,2 +40,$lines @@" >> $patch_file
@@ -97,9 +95,22 @@ mkdir -p $xenomai_root/tmp/linux.new
 linux_tree="$xenomai_root/tmp/linux"
 temp_tree="$xenomai_root/tmp/linux.new"
 
+
 for linux_arch in $supported_arch ; do
-    patch_link r m ksrc/arch/$linux_arch arch/$linux_arch/xenomai
-    patch_link r n include/asm-$linux_arch include/asm-$linux_arch/xenomai
+    case $linux_arch in
+        i386)
+            base_arch=x86
+            ;;
+        x86_64)
+            base_arch=x86
+            ;;
+        *)
+            base_arch=$linux_arch
+            ;;
+    esac
+
+    patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
+    patch_link r n include/asm-$base_arch include/asm-$linux_arch/xenomai
 
     p="+drivers-\$(CONFIG_XENOMAI)		+= arch/$linux_arch/xenomai/"
     echo $p | patch_append arch/$linux_arch/Makefile
@@ -115,7 +126,6 @@ echo $p | patch_append kernel/Makefile
 # Create local directories then symlink to the source files from
 # there, so that we don't pollute the Xenomai source tree with
 # compilation files.
-
 patch_link n m ksrc/ kernel/xenomai
 patch_link n m ksrc/arch kernel/xenomai/arch
 patch_link r m ksrc/arch/generic kernel/xenomai/arch/generic
Index: debian/rules
===================================================================
--- debian/rules	(revision 3182)
+++ debian/rules	(working copy)
@@ -34,21 +34,25 @@ endif
 	            --includedir=/usr/include/xenomai \
 	            --mandir=/usr/share/man
 
-build: build-stamp
-	./configure $(CONFIG_OPTS)
+build: build-stamp patch-stamp
 	$(MAKE)
-#	The kernel patches get generated next - Likely to involve some
-#	additional scripting..
+
+patch-stamp:
+	dh_testdir
+	touch patch-stamp
+#	The kernel patches get generated next - Need to revisit again
+#	when 2.6.24 ipipe patch is released.
 	$(CURDIR)/debian/prepare-patch.sh arm i386 powerpc x86_64
 
 build-stamp:
 	dh_testdir
 	touch build-stamp
+	./configure $(CONFIG_OPTS)
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp
+	rm -f *-stamp
 	dh_clean
 	if test -f Makefile ; then \
 	    $(MAKE) distclean 2>/dev/null ; \

Re: [Xenomai-help] [Xenomai-core] Xenomai v2.4-rc6

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 3486 bytes --]

A Dimecres 14 Novembre 2007, Paul va escriure:
> On Wednesday 14 November 2007 16:37, Paul wrote:
> > I'm right in the middle of looking at the packaging scripts, so expect a
> > patch within the next few days.
>
> Attached, one patch for the Debian rules. The debian/changelog version will
> need to be bumped up to 2.4.0-1 once we get out of the -rc phase. I'll
> submit a trivial patch at that point and build a set of i386 & amd64
> packages.
>
Thank's,

the patch has worked well for me (amd64), however I should say that the 
packages are not lintian free. I can mention:

package xenomai-dev
-------------------------------------------------------------------------------
W: xenomai-dev: symlink-is-self-recursive 
usr/include/xenomai/asm-sim/xenomai .
N:
N:   The symbolic link is recursive to a higher directory of the symlink
N:   itself. This means, that you can infinitely chdir with this symlink.
N:   This is usually not okay, but sometimes wanted behaviour.
N:
W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/asm-sim/asm .
W: xenomai-dev: symlink-is-self-recursive 
usr/include/xenomai/asm-x86/xenomai .
W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/xenomai .
W: xenomai-dev: symlink-is-self-recursive 
usr/include/xenomai/asm-generic/xenomai .

package xenomai
-------------------------------------------------------------------------------
E: xenomai: shell-script-fails-syntax-check ./usr/bin/xeno-test
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/cyclic/run
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/irqbench/run
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchtest/run
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/latency/run
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/clocktest/run
W: xenomai: 
executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchbench/run
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpsos.so.0.0.0 
usr/lib/libpsos.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtai.so.0.0.0 
usr/lib/librtai.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libnative.so.1.0.0 
usr/lib/libnative.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libuitron.so.0.0.0 
usr/lib/libuitron.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdm.so.1.0.0 
usr/lib/librtdm.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpthread_rt.so.1.0.0 
usr/lib/libpthread_rt.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvxworks.so.1.0.0 
usr/lib/libvxworks.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdk.so.0.0.0 
usr/lib/librtdk.so
W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvrtx.so.0.0.0 
usr/lib/libvrtx.so
E: xenomai: postinst-must-call-ldconfig usr/lib/librtdk.so.0.0.0
W: xenomai: postrm-should-call-ldconfig usr/lib/librtdk.so.0.0.0
E: xenomai: description-starts-with-package-name
W: xenomai: description-synopsis-might-not-be-phrased-properly
W: xenomai: package-name-doesnt-match-sonames libpsos0 librtdm1 libvxworks1 
libuitron0 librtdk0 librtai0 libnative1 libvrtx0 libpthread-rt1


lintian linux-patch-xenomai_2.4.0-0+rc6_all.deb
internal error: syntax error in section 1 after the tag description:  
Patch-file: adeos-ipipe-2.6.15-arm-1.5-08.patch

regards,

Leo

-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Paul]

[-- Attachment #1: Type: text/plain, Size: 4205 bytes --]

On Wednesday 14 November 2007 23:13, Leopold Palomo Avellaneda wrote:
> A Dimecres 14 Novembre 2007, Paul va escriure:
> > On Wednesday 14 November 2007 16:37, Paul wrote:
> > > I'm right in the middle of looking at the packaging scripts, so expect
> > > a patch within the next few days.
> >
> > Attached, one patch for the Debian rules. The debian/changelog version
> > will need to be bumped up to 2.4.0-1 once we get out of the -rc phase.
> > I'll submit a trivial patch at that point and build a set of i386 & amd64
> > packages.
>
> Thank's,
>
> the patch has worked well for me (amd64), however I should say that the
> packages are not lintian free. I can mention:
>
> package xenomai-dev
> ---------------------------------------------------------------------------
>---- W: xenomai-dev: symlink-is-self-recursive
> usr/include/xenomai/asm-sim/xenomai .
> N:
> N:   The symbolic link is recursive to a higher directory of the symlink
> N:   itself. This means, that you can infinitely chdir with this symlink.
> N:   This is usually not okay, but sometimes wanted behaviour.
> N:
> W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/asm-sim/asm .
> W: xenomai-dev: symlink-is-self-recursive
> usr/include/xenomai/asm-x86/xenomai .
> W: xenomai-dev: symlink-is-self-recursive usr/include/xenomai/xenomai .
> W: xenomai-dev: symlink-is-self-recursive
> usr/include/xenomai/asm-generic/xenomai .

I'm aware of the recursion - Removing the symlinks in question could be 
tackled in automake, but may well break for other people.

> package xenomai
> ---------------------------------------------------------------------------
>---- E: xenomai: shell-script-fails-syntax-check ./usr/bin/xeno-test
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/cyclic/run
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/irqbench/run
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchtest/run
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/latency/run
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/clocktest/run
> W: xenomai:
> executable-not-elf-or-script ./usr/share/xenomai/testsuite/switchbench/run
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpsos.so.0.0.0
> usr/lib/libpsos.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtai.so.0.0.0
> usr/lib/librtai.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libnative.so.1.0.0
> usr/lib/libnative.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libuitron.so.0.0.0
> usr/lib/libuitron.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdm.so.1.0.0
> usr/lib/librtdm.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libpthread_rt.so.1.0.0
> usr/lib/libpthread_rt.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvxworks.so.1.0.0
> usr/lib/libvxworks.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/librtdk.so.0.0.0
> usr/lib/librtdk.so
> W: xenomai: non-dev-pkg-with-shlib-symlink usr/lib/libvrtx.so.0.0.0
> usr/lib/libvrtx.so

The exec status & symlinks, I feel are outside my remit, as is the libtool 
versioning..

> E: xenomai: postinst-must-call-ldconfig usr/lib/librtdk.so.0.0.0
> W: xenomai: postrm-should-call-ldconfig usr/lib/librtdk.so.0.0.0

Fixed with the new patch.

> E: xenomai: description-starts-with-package-name
> W: xenomai: description-synopsis-might-not-be-phrased-properly

Is it really a problem - I don't feel it is.

> W: xenomai: package-name-doesnt-match-sonames libpsos0 librtdm1 libvxworks1
> libuitron0 librtdk0 librtai0 libnative1 libvrtx0 libpthread-rt1

Current Debian policy appears to be moving towards individual packages for 
each library - Could follow suit, maybe if/when Xenomai is accepted into 
Debian.

> lintian linux-patch-xenomai_2.4.0-0+rc6_all.deb
> internal error: syntax error in section 1 after the tag description:
> Patch-file: adeos-ipipe-2.6.15-arm-1.5-08.patch

Yup, that one has me stumped - If you have any suggestions on eradicating the 
error, I'll use it.
Should point out that the patch generation is *very* rough'n'ready in the 
absence of a kernel source tree.


Regards, Paul.



[-- Attachment #2: debian_rules-rev2.diff --]
[-- Type: text/x-diff, Size: 6052 bytes --]

Index: debian/control
===================================================================
--- debian/control	(revision 3185)
+++ debian/control	(working copy)
@@ -14,9 +14,9 @@ Description: Linux kernel patches for Xe
  Xenomai kernel patches - See www.xenomai.org
  .
  Patches for 2.6 series kernels - These are intended for use with kernel-package
- and a virgin linux source tree. Note: These patches include the base adeos-ipipe
- patch along with all the additional material normally added by the prepare-kernel.sh
- script.
+ and a virgin linux source tree. Note: These patches include the base
+ adeos-ipipe patch along with all the additional material normally added by the 
+ prepare-kernel.sh script.
  .
  This package contains the following patches:
  .
Index: debian/xenomai.postinst
===================================================================
--- debian/xenomai.postinst	(revision 3185)
+++ debian/xenomai.postinst	(working copy)
@@ -3,4 +3,8 @@
 rm -f /etc/udev/rules.d/xenomai.rules
 ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules
 
+if [ "$1" = "configure" ]; then
+	ldconfig
+fi
+
 #DEBHELPER#
Index: debian/xenomai.postrm
===================================================================
--- debian/xenomai.postrm	(revision 3185)
+++ debian/xenomai.postrm	(working copy)
@@ -1,8 +1,9 @@
 #!/bin/sh
 
 case "$1" in
-  purge)
+  purge | remove)
   [ ! -L /etc/udev/rules.d/xenomai.rules ] || rm /etc/udev/rules.d/xenomai.rules
+  ldconfig
   ;;
 esac
 
Index: debian/prepare-patch.sh
===================================================================
--- debian/prepare-patch.sh	(revision 3185)
+++ debian/prepare-patch.sh	(working copy)
@@ -54,7 +54,6 @@ patch_link() {
             if test ! -d  $temp_tree/$link_dir/$d ; then
                 mkdir -p $temp_tree/$link_dir/$d
             fi
-echo " cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f"
             cp $xenomai_root/$target_dir/$f $temp_tree/$link_dir/$f
         done
     )
@@ -77,7 +76,6 @@ generate_patch() {
 diff_addons() {
     lines=`(echo ; echo ; cat $xenomai_root/scripts/Kconfig.frag) | wc -l`
 
-#    echo "diff -u1wbr orig/arch/$linux_arch/Kconfig new/arch/$linux_arch/Kconfig" >> $patch_file
     echo "--- linux/arch/$linux_arch/Kconfig	1970-01-01 01:00:00.000000000 +0100" >> $patch_file
     echo "+++ linux-patched/arch/$linux_arch/Kconfig	2007-03-06 17:55:58.000000000 +0000" >> $patch_file
     echo "@@ -40,2 +40,$lines @@" >> $patch_file
@@ -97,9 +95,22 @@ mkdir -p $xenomai_root/tmp/linux.new
 linux_tree="$xenomai_root/tmp/linux"
 temp_tree="$xenomai_root/tmp/linux.new"
 
+
 for linux_arch in $supported_arch ; do
-    patch_link r m ksrc/arch/$linux_arch arch/$linux_arch/xenomai
-    patch_link r n include/asm-$linux_arch include/asm-$linux_arch/xenomai
+    case $linux_arch in
+        i386)
+            base_arch=x86
+            ;;
+        x86_64)
+            base_arch=x86
+            ;;
+        *)
+            base_arch=$linux_arch
+            ;;
+    esac
+
+    patch_link r m ksrc/arch/$base_arch arch/$linux_arch/xenomai
+    patch_link r n include/asm-$base_arch include/asm-$linux_arch/xenomai
 
     p="+drivers-\$(CONFIG_XENOMAI)		+= arch/$linux_arch/xenomai/"
     echo $p | patch_append arch/$linux_arch/Makefile
@@ -115,7 +126,6 @@ echo $p | patch_append kernel/Makefile
 # Create local directories then symlink to the source files from
 # there, so that we don't pollute the Xenomai source tree with
 # compilation files.
-
 patch_link n m ksrc/ kernel/xenomai
 patch_link n m ksrc/arch kernel/xenomai/arch
 patch_link r m ksrc/arch/generic kernel/xenomai/arch/generic
Index: debian/changelog
===================================================================
--- debian/changelog	(revision 3185)
+++ debian/changelog	(working copy)
@@ -1,3 +1,15 @@
+xenomai (2.4.0-0+rc6) unstable; urgency=low
+
+  * Update prepare-patch.sh to use combined x86/i386 Xenomai tree.
+  * Split patch generation out of build-stamp so that it only gets
+    called once along with the configure.
+  * In pursuit of silencing lintian:
+    * Rename top level ChangeLog to changelog when installed.
+    * Add ldconfig to post install/remove scripts.
+    * Compress changelogs.
+
+ -- Paul Corner <paul_c@domain.hid>  Wed, 14 Nov 2007 21:48:27 +0000
+
 xenomai (2.3.50-05+r2299) unstable; urgency=low
 
   * Add top level ChangeLog and CREDITS to each package.
Index: debian/rules
===================================================================
--- debian/rules	(revision 3185)
+++ debian/rules	(working copy)
@@ -34,21 +34,25 @@ endif
 	            --includedir=/usr/include/xenomai \
 	            --mandir=/usr/share/man
 
-build: build-stamp
-	./configure $(CONFIG_OPTS)
+build: build-stamp patch-stamp
 	$(MAKE)
-#	The kernel patches get generated next - Likely to involve some
-#	additional scripting..
+
+patch-stamp:
+	dh_testdir
+	touch patch-stamp
+#	The kernel patches get generated next - Need to revisit again
+#	when 2.6.24 ipipe patch is released.
 	$(CURDIR)/debian/prepare-patch.sh arm i386 powerpc x86_64
 
 build-stamp:
 	dh_testdir
 	touch build-stamp
+	./configure $(CONFIG_OPTS)
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp
+	rm -f *-stamp
 	dh_clean
 	if test -f Makefile ; then \
 	    $(MAKE) distclean 2>/dev/null ; \
@@ -109,9 +113,10 @@ install: build
 #	Add CREDITS, ChangeLog, and READMEs to all packages.
 	for p in linux-patch-xenomai xenomai xenomai-dev xenomai-docs ; do \
 	    mkdir -p $(CURDIR)/debian/$$p/usr/share/doc/$$p ; \
-	    for f in CREDITS ChangeLog README.INSTALL TROUBLESHOOTING ; do \
+	    for f in CREDITS README.INSTALL TROUBLESHOOTING ; do \
 	        install -m 0644 $$f $(CURDIR)/debian/$$p/usr/share/doc/$$p/ ; \
 	    done ; \
+	    install -m 0644 -T ChangeLog $(CURDIR)/debian/$$p/usr/share/doc/$$p/changelog ; \
 	done
 
 # Build architecture-independent files here.
@@ -122,7 +127,7 @@ binary-indep: install
 	dh_installchangelogs
 	dh_link
 	dh_strip
-#	dh_compress
+	dh_compress
 	dh_fixperms
 	dh_installdeb
 	dh_makeshlibs

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Paul wrote:
> 
> Fixed with the new patch.

Merged, thanks.

-- 
Philippe.

Re: [Xenomai-help] [Xenomai-core] Xenomai v2.4-rc6

[Leopold Palomo-Avellaneda]

A Dilluns 19 Novembre 2007, Philippe Gerum va escriure:
> Paul wrote:
> > Fixed with the new patch.
>
> Merged, thanks.

trunk now is xenomai-rc6  with the new patches for debian?

Regards,

Leo

Re: [Xenomai-core] [Xenomai-help] Xenomai v2.4-rc6

[Philippe Gerum]

Leopold Palomo-Avellaneda wrote:
> A Dilluns 19 Novembre 2007, Philippe Gerum va escriure:
>> Paul wrote:
>>> Fixed with the new patch.
>> Merged, thanks.
> 
> trunk now is xenomai-rc6  with the new patches for debian?
> 

Aside of other changes scheduled for -rc7, yes.

> Regards,
> 
> Leo
> 


-- 
Philippe.