[Xenomai-core] debian/rules update

[Xenomai-core] debian/rules update

[Paul]

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


Attached, a patch to include code examples in the final -dev package along 
with some cleanup of the patches. Also contains a bug fix for the postinst 
script that I hit on when installing a new build.

A question for the project admins: Do you have a Release Manager to coordinate 
package releases ?


Regards, Paul.




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

Index: debian/control
===================================================================
--- debian/control	(revision 2291)
+++ debian/control	(working copy)
@@ -14,7 +14,12 @@ 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.
+ 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:
+ .
 
 Package: xenomai
 Section: devel
@@ -37,6 +42,9 @@ Description: Headers and static libs for
  .
  This package also contains the static libraries and scripts used
  to compile realtime applications.
+ .
+ User space and kernel examples can be found in /usr/share/xenomai
+ along with suitable make files.
 
 Package: xenomai-docs
 Section: devel
Index: debian/xenomai.postinst
===================================================================
--- debian/xenomai.postinst	(revision 2291)
+++ debian/xenomai.postinst	(working copy)
@@ -1,5 +1,6 @@
 #!/bin/sh
 
-ln -s ../xenomai.rules /etc/udev/rules.d/xenomai.rules
+rm -f /etc/udev/rules.d/xenomai.rules
+ln -sf ../xenomai.rules /etc/udev/rules.d/xenomai.rules
 
 #DEBHELPER#
Index: debian/prepare-patch.sh
===================================================================
--- debian/prepare-patch.sh	(revision 2291)
+++ debian/prepare-patch.sh	(working copy)
@@ -64,8 +64,9 @@ echo " cp $xenomai_root/$target_dir/$f $
 generate_patch() {
     (
     cd "$temp_tree"
+    find . -name demos -o -name snippets -exec rm -fR {} \+ &&
     find . -type f |
-    while read f; do
+    while read f ; do
         diff -Naurd "$linux_tree/$f" "$f" |
         sed -e "s,^--- ${linux_tree}/\.\(/.*\)$,--- linux\1," \
             -e "s,^+++ \.\(/.*\)$,+++ linux-patched\1,"
@@ -139,8 +140,6 @@ echo "Patch-name: Xenomai realtime kerne
 echo "Patch-id: xenomai" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
 echo "Architecture: all" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
 
-echo "" >> $xenomai_root/debian/linux-patch-xenomai.kpatches
-
 find $xenomai_root/ksrc/ -name "adeos-ipipe-2.6.*.patch" |
 while read f ; do
 
Index: debian/changelog
===================================================================
--- debian/changelog	(revision 2291)
+++ debian/changelog	(working copy)
@@ -1,3 +1,18 @@
+xenomai (2.3.50-04) unstable; urgency=low
+
+  * Remove demo & snippets from the patches - Installed in xenomai-dev
+  * linux-patches-xenomai lists patches, architectures, & kernel version
+    in the package description meta-data.
+
+ -- Paul Corner <paul_c@domain.hid>  Mon, 12 Mar 2007 17:30:00 +0000
+
+xenomai (2.3.50-03) unstable; urgency=low
+
+  * Revision 2281
+  * Fix bug in postinst script - Need to overwrite the symlink
+
+ -- Paul Corner <paul_c@domain.hid>  Sun, 11 Mar 2007 20:30:00 +0000
+
 xenomai (2.3.50-02) unstable; urgency=low
 
   * Apply patch to fix includedir bug - rules updated..
Index: debian/rules
===================================================================
--- debian/rules	(revision 2291)
+++ debian/rules	(working copy)
@@ -86,17 +86,26 @@ install: build
 #	test applications.
 	mkdir -p $(CURDIR)/debian/xenomai/usr/share
 	mv -f $(CURDIR)/debian/tmp/usr/share/xenomai $(CURDIR)/debian/xenomai/usr/share
-	mkdir -p $(CURDIR)/debian/xenomai/etc/udev
 #	install $(CURDIR)/ksrc/nucleus/udev/*.rules $(CURDIR)/debian/xenomai/etc/udev
+	mkdir -p $(CURDIR)/debian/xenomai/etc/udev
 	for f in $(CURDIR)/ksrc/nucleus/udev/*.rules ; do \
 	    cat $$f >> $(CURDIR)/debian/xenomai/etc/udev/xenomai.rules ; \
 	done
+#	Install examples in the dev package.
+	mkdir -p $(CURDIR)/debian/xenomai-dev/usr/share/xenomai
+	cp -fR $(CURDIR)/examples $(CURDIR)/debian/xenomai-dev/usr/share/xenomai
+#	 then kernel demos & snippets
+	cd $(CURDIR)/ksrc && find . -name demos -o  -name snippets | \
+	    while read d ; do \
+	        mkdir -p $(CURDIR)/debian/xenomai-dev/usr/share/xenomai/examples/kernel/$$d ; \
+	        install -m 0644 $$d/* $(CURDIR)/debian/xenomai-dev/usr/share/xenomai/examples/kernel/$$d ; \
+	    done ; \
+	cd $(CURDIR)
 #	The kernel patches get installed next..
 	dh_installkpatches
 
-
 # Build architecture-independent files here.
-binary-indep: build install
+binary-indep: install
 	dh_testdir
 	dh_testroot
 	dh_installdocs
@@ -110,6 +119,12 @@ binary-indep: build install
 	dh_shlibdeps -L xenomai -L xenomai-dev
 #	dh_shlibdeps
 	dh_gencontrol
+#	 Here follows a little hackery to insert the patch list        
+#	 into the control file for linux-patch-xenomai
+	cat $(CURDIR)/debian/linux-patch-xenomai.kpatches | \
+	    awk 'NR>4 {sub(/^/," ");print}' >> \
+	        $(CURDIR)/debian/linux-patch-xenomai/DEBIAN/control
+#	 End of hackery.
 	dh_md5sums
 	dh_builddeb
 

Re: [Xenomai-core] debian/rules update

[Philippe Gerum]

On Mon, 2007-03-12 at 17:56 +0000, Paul wrote:
> Attached, a patch to include code examples in the final -dev package along 
> with some cleanup of the patches. Also contains a bug fix for the postinst 
> script that I hit on when installing a new build.
> 

Merged, thanks.

> A question for the project admins: Do you have a Release Manager to coordinate 
> package releases ?
> 

I'm currently coordinating the Xenomai releases, with input from the
sub-systems/architecture maintainers. I guess that by "package", you are
referring to another division of the work, though.

> 
> Regards, Paul.
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

Re: [Xenomai-core] debian/rules update

[Paul]

Hi Philippe

On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > A question for the project admins: Do you have a Release Manager to
> > coordinate package releases ?
>
> I'm currently coordinating the Xenomai releases, with input from the
> sub-systems/architecture maintainers. I guess that by "package", you are
> referring to another division of the work, though.

By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst I'm 
happy to build and host i386/x86 Debian packages, I'm concerned about 
treading on someone's toes without a discussion about revision numbers and 
general policy about "official" releases. For example, the packages I've 
built to date have used 2.3.50 even although a tarball of that version hasn't 
been released.. That could well cause confusion for users and yourself if 
bugs are reported. There is also a minor problem with keeping the 
debian/changelog in sync.

 One possible answer is for me to rebuild my repository from scratch and 
append the SVN revision number to revision number so that we end up with 
2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to override 
the ~r2289 revision..


Regards, Paul.

Re: [Xenomai-core] debian/rules update

[Philippe Gerum]

On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> Hi Philippe
> 
> On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > > A question for the project admins: Do you have a Release Manager to
> > > coordinate package releases ?
> >
> > I'm currently coordinating the Xenomai releases, with input from the
> > sub-systems/architecture maintainers. I guess that by "package", you are
> > referring to another division of the work, though.
> 
> By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst I'm 
> happy to build and host i386/x86 Debian packages, I'm concerned about 
> treading on someone's toes without a discussion about revision numbers and 
> general policy about "official" releases.

So far, we don't have an established policy for making distro-oriented
packages; a few people have contributed some of them from time to time,
but there is no "appointed" maintainer doing sustained work for the
project on this issue yet.

>  For example, the packages I've 
> built to date have used 2.3.50 even although a tarball of that version hasn't 
> been released.. That could well cause confusion for users and yourself if 
> bugs are reported. There is also a minor problem with keeping the 
> debian/changelog in sync.
> 
>  One possible answer is for me to rebuild my repository from scratch and 
> append the SVN revision number to revision number so that we end up with 
> 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to override 
> the ~r2289 revision..
> 

It would be saner to use the commit number indeed, especially since it
allows decouple the package versioning from the source releases while
keeping a reference to a common history of changes.

Some information about the current naming scheme I'm using for tagging
the intermediate development milestones:

1- when reopened after a major version X.Y has been rolled out, the
development branch (i.e. SVN trunk/) is always tagged as X.Y.50. There
is no X.Y.51 version and beyond; the next step is always to enter the
release candidate cycle when appropriate.

2- when the development branch enters the release candidate cycle, this
tag is bumped to X.Y.90 for -rc1, X.Y.91 for -rc2 and so on.

3- a release candidate that goes final is eventually tagged as X.{Y
+1}.O, and the development cycle restarts at step 1.

> 
> Regards, Paul.
> 
-- 
Philippe.

Re: [Xenomai-core] debian/rules update

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> 
>>Hi Philippe
>>
>>On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
>>
>>>>A question for the project admins: Do you have a Release Manager to
>>>>coordinate package releases ?
>>>
>>>I'm currently coordinating the Xenomai releases, with input from the
>>>sub-systems/architecture maintainers. I guess that by "package", you are
>>>referring to another division of the work, though.
>>
>>By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst I'm 
>>happy to build and host i386/x86 Debian packages, I'm concerned about 
>>treading on someone's toes without a discussion about revision numbers and 
>>general policy about "official" releases.
> 
> 
> So far, we don't have an established policy for making distro-oriented
> packages; a few people have contributed some of them from time to time,
> but there is no "appointed" maintainer doing sustained work for the
> project on this issue yet.
> 
> 
>> For example, the packages I've 
>>built to date have used 2.3.50 even although a tarball of that version hasn't 
>>been released.. That could well cause confusion for users and yourself if 
>>bugs are reported. There is also a minor problem with keeping the 
>>debian/changelog in sync.
>>
>> One possible answer is for me to rebuild my repository from scratch and 
>>append the SVN revision number to revision number so that we end up with 
>>2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to override 
>>the ~r2289 revision..
>>
> 
> 
> It would be saner to use the commit number indeed, especially since it
> allows decouple the package versioning from the source releases while
> keeping a reference to a common history of changes.

Do we really want to make debian packages with trunk ? Would not it make
sense to only make debian packages from stable releases ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] debian/rules update

[Philippe Gerum]

On Wed, 2007-03-14 at 11:59 +0100, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> > 
> >>Hi Philippe
> >>
> >>On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> >>
> >>>>A question for the project admins: Do you have a Release Manager to
> >>>>coordinate package releases ?
> >>>
> >>>I'm currently coordinating the Xenomai releases, with input from the
> >>>sub-systems/architecture maintainers. I guess that by "package", you are
> >>>referring to another division of the work, though.
> >>
> >>By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst I'm 
> >>happy to build and host i386/x86 Debian packages, I'm concerned about 
> >>treading on someone's toes without a discussion about revision numbers and 
> >>general policy about "official" releases.
> > 
> > 
> > So far, we don't have an established policy for making distro-oriented
> > packages; a few people have contributed some of them from time to time,
> > but there is no "appointed" maintainer doing sustained work for the
> > project on this issue yet.
> > 
> > 
> >> For example, the packages I've 
> >>built to date have used 2.3.50 even although a tarball of that version hasn't 
> >>been released.. That could well cause confusion for users and yourself if 
> >>bugs are reported. There is also a minor problem with keeping the 
> >>debian/changelog in sync.
> >>
> >> One possible answer is for me to rebuild my repository from scratch and 
> >>append the SVN revision number to revision number so that we end up with 
> >>2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to override 
> >>the ~r2289 revision..
> >>
> > 
> > 
> > It would be saner to use the commit number indeed, especially since it
> > allows decouple the package versioning from the source releases while
> > keeping a reference to a common history of changes.
> 
> Do we really want to make debian packages with trunk ? Would not it make
> sense to only make debian packages from stable releases ?
> 

Not necessarily, the same way one may want to base his work on sid,
because some features only available in the development branch are
needed (e.g. support for multiple time bases is only available in the
trunk/ and not with 2.3.x, and one would need such feature to run
VxWorks and the POSIX skins in parallel for instance). Provided we do
have a non-confusing way to name such intermediate releases, of course.

-- 
Philippe.

Re: [Xenomai-core] debian/rules update

[Paul]

On Wednesday 14 March 2007 10:56, Philippe Gerum wrote:
> On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> > Hi Philippe
> >
> > On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > > > A question for the project admins: Do you have a Release Manager to
> > > > coordinate package releases ?
> > >
> > > I'm currently coordinating the Xenomai releases, with input from the
> > > sub-systems/architecture maintainers. I guess that by "package", you
> > > are referring to another division of the work, though.
> >
> > By "package", I mean binaries in the form of *.deb and/or *.rpm - Whilst
> > I'm happy to build and host i386/x86 Debian packages, I'm concerned about
> > treading on someone's toes without a discussion about revision numbers
> > and general policy about "official" releases.
>
> So far, we don't have an established policy for making distro-oriented
> packages; a few people have contributed some of them from time to time,
> but there is no "appointed" maintainer doing sustained work for the
> project on this issue yet.
>
> >  For example, the packages I've
> > built to date have used 2.3.50 even although a tarball of that version
> > hasn't been released.. That could well cause confusion for users and
> > yourself if bugs are reported. There is also a minor problem with keeping
> > the debian/changelog in sync.
> >
> >  One possible answer is for me to rebuild my repository from scratch and
> > append the SVN revision number to revision number so that we end up with
> > 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release to
> > override the ~r2289 revision..
>
> It would be saner to use the commit number indeed, especially since it
> allows decouple the package versioning from the source releases while
> keeping a reference to a common history of changes.
>
> Some information about the current naming scheme I'm using for tagging
> the intermediate development milestones:
>
> 1- when reopened after a major version X.Y has been rolled out, the
> development branch (i.e. SVN trunk/) is always tagged as X.Y.50. There
> is no X.Y.51 version and beyond; the next step is always to enter the
> release candidate cycle when appropriate.

That sounds reasonable - Any packages built from trunk would probably better 
off following an X.Y.50+r<svn tag>.

> 2- when the development branch enters the release candidate cycle, this
> tag is bumped to X.Y.90 for -rc1, X.Y.91 for -rc2 and so on.
>
> 3- a release candidate that goes final is eventually tagged as X.{Y
> +1}.O, and the development cycle restarts at step 1.

So X.{Y+1}.0 will always override an X.Y.50+rnnnn - Works for me.


Regards, Paul.

Re: [Xenomai-core] debian/rules update

[Paul]

On Wednesday 14 March 2007 11:14, Philippe Gerum wrote:
> On Wed, 2007-03-14 at 11:59 +0100, Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> > >>Hi Philippe
> > >>
> > >>On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > >>>>A question for the project admins: Do you have a Release Manager to
> > >>>>coordinate package releases ?
> > >>>
> > >>>I'm currently coordinating the Xenomai releases, with input from the
> > >>>sub-systems/architecture maintainers. I guess that by "package", you
> > >>> are referring to another division of the work, though.
> > >>
> > >>By "package", I mean binaries in the form of *.deb and/or *.rpm -
> > >> Whilst I'm happy to build and host i386/x86 Debian packages, I'm
> > >> concerned about treading on someone's toes without a discussion about
> > >> revision numbers and general policy about "official" releases.
> > >
> > > So far, we don't have an established policy for making distro-oriented
> > > packages; a few people have contributed some of them from time to time,
> > > but there is no "appointed" maintainer doing sustained work for the
> > > project on this issue yet.
> > >
> > >> For example, the packages I've
> > >>built to date have used 2.3.50 even although a tarball of that version
> > >> hasn't been released.. That could well cause confusion for users and
> > >> yourself if bugs are reported. There is also a minor problem with
> > >> keeping the debian/changelog in sync.
> > >>
> > >> One possible answer is for me to rebuild my repository from scratch
> > >> and append the SVN revision number to revision number so that we end
> > >> up with 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release
> > >> to override the ~r2289 revision..
> > >
> > > It would be saner to use the commit number indeed, especially since it
> > > allows decouple the package versioning from the source releases while
> > > keeping a reference to a common history of changes.
> >
> > Do we really want to make debian packages with trunk ? Would not it make
> > sense to only make debian packages from stable releases ?
>
> Not necessarily, the same way one may want to base his work on sid,
> because some features only available in the development branch are
> needed (e.g. support for multiple time bases is only available in the
> trunk/ and not with 2.3.x, and one would need such feature to run
> VxWorks and the POSIX skins in parallel for instance). Provided we do
> have a non-confusing way to name such intermediate releases, of course.

With a Debian pool style of repository, the X.Y.50+rnnn packages would always 
go in unstable (Sid) or even experimental. When the release number gets 
bumped up to X.{Y+1}.0, it would go in testing (Etch), and when Etch becomes 
the default "stable", any X.Y.0 releases would automatically migrate across.
Bug fixes to X.Y.{0+n} would normally appear in testing and/or stable leaving 
Sid to track the trunk of SVN - Primarily a repository management issue..

Following this proposal, the end user can opt for stable/testing or unstable. 
Should he/she choose, it is a simple matter to "downgrade" from unstable or 
track the unstable releases.. That said, I suspect most users would compile 
from source, perhaps using the debian/rules as an aid to install/remove.. 
Prebuilt binaries & kernels would most likely be used by people wanting to 
try Xenomai before committing time to a patch/build cycle.


Regards, Paul.

Re: [Xenomai-core] debian/rules update

[Philippe Gerum]

On Wed, 2007-03-14 at 16:48 +0000, Paul wrote:
> On Wednesday 14 March 2007 11:14, Philippe Gerum wrote:
> > On Wed, 2007-03-14 at 11:59 +0100, Gilles Chanteperdrix wrote:
> > > Philippe Gerum wrote:
> > > > On Tue, 2007-03-13 at 20:32 +0000, Paul wrote:
> > > >>Hi Philippe
> > > >>
> > > >>On Tuesday 13 March 2007 16:30, Philippe Gerum wrote:
> > > >>>>A question for the project admins: Do you have a Release Manager to
> > > >>>>coordinate package releases ?
> > > >>>
> > > >>>I'm currently coordinating the Xenomai releases, with input from the
> > > >>>sub-systems/architecture maintainers. I guess that by "package", you
> > > >>> are referring to another division of the work, though.
> > > >>
> > > >>By "package", I mean binaries in the form of *.deb and/or *.rpm -
> > > >> Whilst I'm happy to build and host i386/x86 Debian packages, I'm
> > > >> concerned about treading on someone's toes without a discussion about
> > > >> revision numbers and general policy about "official" releases.
> > > >
> > > > So far, we don't have an established policy for making distro-oriented
> > > > packages; a few people have contributed some of them from time to time,
> > > > but there is no "appointed" maintainer doing sustained work for the
> > > > project on this issue yet.
> > > >
> > > >> For example, the packages I've
> > > >>built to date have used 2.3.50 even although a tarball of that version
> > > >> hasn't been released.. That could well cause confusion for users and
> > > >> yourself if bugs are reported. There is also a minor problem with
> > > >> keeping the debian/changelog in sync.
> > > >>
> > > >> One possible answer is for me to rebuild my repository from scratch
> > > >> and append the SVN revision number to revision number so that we end
> > > >> up with 2.3.50-1~r2289 - This would allow an official 2.3.50-1 release
> > > >> to override the ~r2289 revision..
> > > >
> > > > It would be saner to use the commit number indeed, especially since it
> > > > allows decouple the package versioning from the source releases while
> > > > keeping a reference to a common history of changes.
> > >
> > > Do we really want to make debian packages with trunk ? Would not it make
> > > sense to only make debian packages from stable releases ?
> >
> > Not necessarily, the same way one may want to base his work on sid,
> > because some features only available in the development branch are
> > needed (e.g. support for multiple time bases is only available in the
> > trunk/ and not with 2.3.x, and one would need such feature to run
> > VxWorks and the POSIX skins in parallel for instance). Provided we do
> > have a non-confusing way to name such intermediate releases, of course.
> 
> With a Debian pool style of repository, the X.Y.50+rnnn packages would always 
> go in unstable (Sid) or even experimental. When the release number gets 
> bumped up to X.{Y+1}.0, it would go in testing (Etch), and when Etch becomes 
> the default "stable", any X.Y.0 releases would automatically migrate across.
> Bug fixes to X.Y.{0+n} would normally appear in testing and/or stable leaving 
> Sid to track the trunk of SVN - Primarily a repository management issue..
> 
> Following this proposal, the end user can opt for stable/testing or unstable. 
> Should he/she choose, it is a simple matter to "downgrade" from unstable or 
> track the unstable releases.. That said, I suspect most users would compile 
> from source, perhaps using the debian/rules as an aid to install/remove.. 
> Prebuilt binaries & kernels would most likely be used by people wanting to 
> try Xenomai before committing time to a patch/build cycle.
> 

Ack, hence the importance of having Xenomai work out of the box on
common hardware, so that succcesful tries lead to adoption.

> 
> Regards, Paul.
-- 
Philippe.