[Xenomai] Debian package of Xenomai 2.6.4

[Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

Hi,

in the lasts days I have been working in the Debian package of xenomai. By now  
2.6.4, but 3.0 is in the agenda, so I will begin to work on it soon.

I'm working for the "officially" Debian package for the Debian organization. 
I'm not alone, I'm collaborating with official maintainer (Roland Stigge). So, 
my main target is to have one good package for Debian. 

However, say that, IMHO it's important that the package could solve the needs 
of more people, so, I'm open to adapt, modify or whatever in a good manner to 
help the needs of the users of that package: Debian users or Debian 
derivatives users.

The Debian package follows mainly the upstream (Xenomai project) package. 
However, I have introduced several changes from the original Debian one:

- Renamed linux-patch-xenomai by xenomai-kernel-source
We are using Upstream nomenclature.

- Renamed xenomai-runtime by xenomai-system-tools.
Udev files, init file, test utilities, modprobe utilities. All this stuff goes 
to that package.

- Drop /dev from libxenomai1.
The /dev directory is created by udev. All debian systems have udev. However, 
I'm thinking to have another package with this stuff. What do you think?

- Install the libraries in /usr/lib/$ARCH/.
I'm following the Multi-Arch schema. In theory we could have several libraries 
co-installed. Need to test.

- Copyright file migrated to copyright-format 1.0
I have worked a lot to have some kind of Copyright file complete. If someone 
found something wrong, please tell me something.

- I have removed the previous debian patches (incorporated by upstream) but I 
have added one commit from upstream to build with 2.6.4 kernels => 3.11.

Checking the package I have found some interesting things:

X: xenomai source: deprecated-configure-filename
N: 
N:    The use of 'configure.in' with automake is deprecated and will not be
N:    supported in future versions of automake. Please consider (helping
N:    upstream) migrating to 'configure.ac' instead.
N:    

P: xenomai source: source-contains-prebuilt-javascript-object 
doc/generated/html/api/jquery.js mean line length is about 16131 characters
N: 
N:    The source tarball contains a prebuilt (minified) JavaScript object.
N:    They are usually left by mistake when generating the tarball by not 
N:    cleaning the source directory first. You may want to report this as an
N:    upstream bug, in case there is no sign that this was intended.


W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
N:
N:    This package provides an ELF binary that lacks the "read-only
N:    relocation" link flag. This package was likely not built with the
N:    default Debian compiler flags defined by dpkg-buildflags. If built using
N:    dpkg-buildflags directly, be sure to import LDFLAGS.
N:
N:    Refer to https://wiki.debian.org/Hardening for details.
N:
N:    Severity: normal, Certainty: certain
N:
N:    Check: binaries, Type: binary, udeb
N:
W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/native+posix/mq_select
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/native/heap
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/native/leaks
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/native/sigdebug
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/native/tsc
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/leaks
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/mprotect
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/nano_test
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/shm
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/test_pip_exit
W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
gnu/xenomai/regression/posix/xddp_test
W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig


Any volunteer?

W: xenomai-system-tools: binary-without-manpage usr/sbin/analogy_config
W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_bits
W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_read
W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_write
W: xenomai-system-tools: binary-without-manpage usr/bin/insn_bits
W: xenomai-system-tools: binary-without-manpage usr/bin/insn_read
W: xenomai-system-tools: binary-without-manpage usr/bin/insn_write
W: xenomai-system-tools: binary-without-manpage usr/sbin/rtps
W: xenomai-system-tools: binary-without-manpage usr/bin/wf_generate
W: xenomai-system-tools: binary-without-manpage usr/bin/wrap-link
W: xenomai-system-tools: binary-without-manpage usr/bin/xeno-regression-test


X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libnative.so.3.0.0
N: 
N:    The listed shared library calls the C library exit() or _exit()
N:    functions.
N: 
N:    In the case of an error, the library should instead return an
N:    appropriate error code to the calling program which can then determine
N:    how to handle the error, including performing any required clean-up.  
N: 
N:    In most cases, removing the call should be discussed with upstream,
N:    particularly as it may produce an ABI change.
N: 
N:    Severity: wishlist, Certainty: possible
N: 
N:    Check: shared-libs, Type: binary, udeb
N: 
N:    This tag is marked experimental, which means that the code that
N:    generates it is not as well-tested as the rest of Lintian and might
N:    still give surprising results. Feel free to ignore experimental tags
N:    that do not seem to make sense, though of course bug reports are always
N:    welcome.
N: 
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libpsos.so.0.0.0
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-
gnu/libpthread_rt.so.1.0.0
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libuitron.so.0.0.0
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libvrtx.so.0.0.0  
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libvxworks.so.1.0.0
X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libxenomai.so.0.0.0


The package git is located here: 

http://anonscm.debian.org/cgit/collab-maint/xenomai.git


Best regards,

Leopold



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/d7129990/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> in the lasts days I have been working in the Debian package of xenomai. By now  
> 2.6.4, but 3.0 is in the agenda, so I will begin to work on it soon.
> 
> I'm working for the "officially" Debian package for the Debian organization. 
> I'm not alone, I'm collaborating with official maintainer (Roland Stigge). So, 
> my main target is to have one good package for Debian. 
> 
> However, say that, IMHO it's important that the package could solve the needs 
> of more people, so, I'm open to adapt, modify or whatever in a good manner to 
> help the needs of the users of that package: Debian users or Debian 
> derivatives users.
> 
> The Debian package follows mainly the upstream (Xenomai project) package. 
> However, I have introduced several changes from the original Debian one:
> 
> - Renamed linux-patch-xenomai by xenomai-kernel-source
> We are using Upstream nomenclature.

The move from linux-patch-xenomai to xenomai-kernel-source is not a
simple rename. Providing patches as linux-patch-xenomai did has been
obsolete for several debian releases (3 or 4, something like that),
and so no longer justified the costly maintenance of the script
generating those patches. So, the xenomai-kernel-source package
simply contains the part of the xenomai sources and the
prepare-kernel.sh script allowing to build a kernel with xenomai
support, making the preparation of a kernel the same as the one
documented by the upstream package.

> 
> - Renamed xenomai-runtime by xenomai-system-tools.
> Udev files, init file, test utilities, modprobe utilities. All this stuff goes 
> to that package.
> 
> - Drop /dev from libxenomai1.
> The /dev directory is created by udev. All debian systems have udev. However, 
> I'm thinking to have another package with this stuff. What do you think?
> 
> - Install the libraries in /usr/lib/$ARCH/.
> I'm following the Multi-Arch schema. In theory we could have several libraries 
> co-installed. Need to test.
> 
> - Copyright file migrated to copyright-format 1.0
> I have worked a lot to have some kind of Copyright file complete. If someone 
> found something wrong, please tell me something.
> 
> - I have removed the previous debian patches (incorporated by upstream) but I 
> have added one commit from upstream to build with 2.6.4 kernels => 3.11.
> 
> Checking the package I have found some interesting things:
> 
> X: xenomai source: deprecated-configure-filename
> N: 
> N:    The use of 'configure.in' with automake is deprecated and will not be
> N:    supported in future versions of automake. Please consider (helping
> N:    upstream) migrating to 'configure.ac' instead.
> N:    

configure.in has been renamed configure.ac in xenomai 3.x. It will
not be renamed in xenomai 2.6.x.

> 
> P: xenomai source: source-contains-prebuilt-javascript-object 
> doc/generated/html/api/jquery.js mean line length is about 16131 characters
> N: 
> N:    The source tarball contains a prebuilt (minified) JavaScript object.
> N:    They are usually left by mistake when generating the tarball by not 
> N:    cleaning the source directory first. You may want to report this as an
> N:    upstream bug, in case there is no sign that this was intended.

No, this is intended, this file is part of the documentation
generated by doxygen, and we want that documentation to be
installable on the users system without any need to install doxygen. 

> 
> 
> W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> N:
> N:    This package provides an ELF binary that lacks the "read-only
> N:    relocation" link flag. This package was likely not built with the
> N:    default Debian compiler flags defined by dpkg-buildflags. If built using
> N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> N:
> N:    Refer to https://wiki.debian.org/Hardening for details.
> N:
> N:    Severity: normal, Certainty: certain
> N:
> N:    Check: binaries, Type: binary, udeb
> N:
> W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/native+posix/mq_select
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/native/heap
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/native/leaks
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/native/sigdebug
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/native/tsc
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/leaks
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/mprotect
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/nano_test
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/shm
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/test_pip_exit
> W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> gnu/xenomai/regression/posix/xddp_test
> W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
> W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> 
> 
> Any volunteer?

Please provide the patch to the debian/rules to apply this change. I
do not think we did anything special to avoid using the default flags.

> 
> W: xenomai-system-tools: binary-without-manpage usr/sbin/analogy_config
> W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_bits
> W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_read
> W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_write
> W: xenomai-system-tools: binary-without-manpage usr/bin/insn_bits
> W: xenomai-system-tools: binary-without-manpage usr/bin/insn_read
> W: xenomai-system-tools: binary-without-manpage usr/bin/insn_write
> W: xenomai-system-tools: binary-without-manpage usr/sbin/rtps
> W: xenomai-system-tools: binary-without-manpage usr/bin/wf_generate
> W: xenomai-system-tools: binary-without-manpage usr/bin/wrap-link
> W: xenomai-system-tools: binary-without-manpage usr/bin/xeno-regression-test
> 
> 
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libnative.so.3.0.0
> N: 
> N:    The listed shared library calls the C library exit() or _exit()
> N:    functions.
> N: 
> N:    In the case of an error, the library should instead return an
> N:    appropriate error code to the calling program which can then determine
> N:    how to handle the error, including performing any required clean-up.  
> N: 
> N:    In most cases, removing the call should be discussed with upstream,
> N:    particularly as it may produce an ABI change.
> N: 
> N:    Severity: wishlist, Certainty: possible
> N: 
> N:    Check: shared-libs, Type: binary, udeb
> N: 
> N:    This tag is marked experimental, which means that the code that
> N:    generates it is not as well-tested as the rest of Lintian and might
> N:    still give surprising results. Feel free to ignore experimental tags
> N:    that do not seem to make sense, though of course bug reports are always
> N:    welcome.
> N: 
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libpsos.so.0.0.0
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-
> gnu/libpthread_rt.so.1.0.0
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libuitron.so.0.0.0
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libvrtx.so.0.0.0  
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libvxworks.so.1.0.0
> X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libxenomai.so.0.0.0
> 
> 
> The package git is located here: 
> 
> http://anonscm.debian.org/cgit/collab-maint/xenomai.git

Calling exit in those libs is intentional, and will not be modified.

-- 
					    Gilles.

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

El Dijous, 25 de juny de 2015, a les 14:01:16, Gilles Chanteperdrix va 
escriure:
> On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> > Hi,
> > 
> > in the lasts days I have been working in the Debian package of xenomai. By
> > now 2.6.4, but 3.0 is in the agenda, so I will begin to work on it soon.
> > 
> > I'm working for the "officially" Debian package for the Debian
> > organization. I'm not alone, I'm collaborating with official maintainer
> > (Roland Stigge). So, my main target is to have one good package for
> > Debian.
> > 
> > However, say that, IMHO it's important that the package could solve the
> > needs of more people, so, I'm open to adapt, modify or whatever in a good
> > manner to help the needs of the users of that package: Debian users or
> > Debian derivatives users.
> > 
> > The Debian package follows mainly the upstream (Xenomai project) package.
> > However, I have introduced several changes from the original Debian one:
> > 
> > - Renamed linux-patch-xenomai by xenomai-kernel-source
> > We are using Upstream nomenclature.
> 
> The move from linux-patch-xenomai to xenomai-kernel-source is not a
> simple rename. Providing patches as linux-patch-xenomai did has been
> obsolete for several debian releases (3 or 4, something like that),
> and so no longer justified the costly maintenance of the script
> generating those patches. So, the xenomai-kernel-source package
> simply contains the part of the xenomai sources and the
> prepare-kernel.sh script allowing to build a kernel with xenomai
> support, making the preparation of a kernel the same as the one
> documented by the upstream package.

Good. I agree.

> > - Renamed xenomai-runtime by xenomai-system-tools.
> > Udev files, init file, test utilities, modprobe utilities. All this stuff
> > goes to that package.
> > 
> > - Drop /dev from libxenomai1.
> > The /dev directory is created by udev. All debian systems have udev.
> > However, I'm thinking to have another package with this stuff. What do
> > you think?

You didn't answer this ..

[...]

> > N:
> configure.in has been renamed configure.ac in xenomai 3.x. It will
> not be renamed in xenomai 2.6.x.
> 
> > P: xenomai source: source-contains-prebuilt-javascript-object
> > doc/generated/html/api/jquery.js mean line length is about 16131
> > characters
> > N:
> > N:    The source tarball contains a prebuilt (minified) JavaScript object.
> > N:    They are usually left by mistake when generating the tarball by not
> > N:    cleaning the source directory first. You may want to report this as
> > an N:    upstream bug, in case there is no sign that this was intended.
> No, this is intended, this file is part of the documentation
> generated by doxygen, and we want that documentation to be
> installable on the users system without any need to install doxygen.

Ok, I know.

> > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> > N:
> > N:    This package provides an ELF binary that lacks the "read-only
> > N:    relocation" link flag. This package was likely not built with the
> > N:    default Debian compiler flags defined by dpkg-buildflags. If built
> > using N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> > N:
> > N:    Refer to https://wiki.debian.org/Hardening for details.
> > N:
> > N:    Severity: normal, Certainty: certain
> > N:
> > N:    Check: binaries, Type: binary, udeb
> > N:
> > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> > W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/native+posix/mq_select
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/native/heap
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/native/leaks
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/native/sigdebug
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/native/tsc
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/leaks
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/mprotect
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/nano_test
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/shm
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/test_pip_exit
> > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > gnu/xenomai/regression/posix/xddp_test
> > W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
> > W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> > 
> 
> Please provide the patch to the debian/rules to apply this change. I
> do not think we did anything special to avoid using the default flags.


my configure line says:

CONFIG_OPTS += --prefix=/usr \
                    --includedir=/usr/include/xenomai \
                    --mandir=/usr/share/man \
                    --with-testdir=/usr/lib/$(DEB_HOST_MULTIARCH)/xenomai \
                    --enable-fortify \
                    --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)/'


plus some specific arch params. I have tested it with --enable-fortify and 
without.

I have also:
DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie

following

https://wiki.debian.org/Hardening

any help in this stuff will help.



> > 
> > Any volunteer?


> > W: xenomai-system-tools: binary-without-manpage usr/sbin/analogy_config
> > W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_bits
> > W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_read
> > W: xenomai-system-tools: binary-without-manpage usr/bin/cmd_write
> > W: xenomai-system-tools: binary-without-manpage usr/bin/insn_bits
> > W: xenomai-system-tools: binary-without-manpage usr/bin/insn_read
> > W: xenomai-system-tools: binary-without-manpage usr/bin/insn_write
> > W: xenomai-system-tools: binary-without-manpage usr/sbin/rtps
> > W: xenomai-system-tools: binary-without-manpage usr/bin/wf_generate
> > W: xenomai-system-tools: binary-without-manpage usr/bin/wrap-link
> > W: xenomai-system-tools: binary-without-manpage
> > usr/bin/xeno-regression-test
> > 
> > 
> > X: libxenomai1: shlib-calls-exit
> > usr/lib/x86_64-linux-gnu/libnative.so.3.0.0 N:
> > N:    The listed shared library calls the C library exit() or _exit()
> > N:    functions.
> > N:
> > N:    In the case of an error, the library should instead return an
> > N:    appropriate error code to the calling program which can then
> > determine N:    how to handle the error, including performing any
> > required clean-up. N:
> > N:    In most cases, removing the call should be discussed with upstream,
> > N:    particularly as it may produce an ABI change.
> > N:
> > N:    Severity: wishlist, Certainty: possible
> > N:
> > N:    Check: shared-libs, Type: binary, udeb
> > N:
> > N:    This tag is marked experimental, which means that the code that
> > N:    generates it is not as well-tested as the rest of Lintian and might
> > N:    still give surprising results. Feel free to ignore experimental tags
> > N:    that do not seem to make sense, though of course bug reports are
> > always N:    welcome.
> > N:
> > X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-gnu/libpsos.so.0.0.0
> > X: libxenomai1: shlib-calls-exit usr/lib/x86_64-linux-
> > gnu/libpthread_rt.so.1.0.0
> > X: libxenomai1: shlib-calls-exit
> > usr/lib/x86_64-linux-gnu/libuitron.so.0.0.0 X: libxenomai1:
> > shlib-calls-exit usr/lib/x86_64-linux-gnu/libvrtx.so.0.0.0 X:
> > libxenomai1: shlib-calls-exit
> > usr/lib/x86_64-linux-gnu/libvxworks.so.1.0.0 X: libxenomai1:
> > shlib-calls-exit usr/lib/x86_64-linux-gnu/libxenomai.so.0.0.0
> > 
> > 
> > The package git is located here:
> > 
> > http://anonscm.debian.org/cgit/collab-maint/xenomai.git
> 
> Calling exit in those libs is intentional, and will not be modified.


OK,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/6e9bc49b/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 02:41:08PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dijous, 25 de juny de 2015, a les 14:01:16, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> > > Hi,
> > > 
> > > in the lasts days I have been working in the Debian package of xenomai. By
> > > now 2.6.4, but 3.0 is in the agenda, so I will begin to work on it soon.
> > > 
> > > I'm working for the "officially" Debian package for the Debian
> > > organization. I'm not alone, I'm collaborating with official maintainer
> > > (Roland Stigge). So, my main target is to have one good package for
> > > Debian.
> > > 
> > > However, say that, IMHO it's important that the package could solve the
> > > needs of more people, so, I'm open to adapt, modify or whatever in a good
> > > manner to help the needs of the users of that package: Debian users or
> > > Debian derivatives users.
> > > 
> > > The Debian package follows mainly the upstream (Xenomai project) package.
> > > However, I have introduced several changes from the original Debian one:
> > > 
> > > - Renamed linux-patch-xenomai by xenomai-kernel-source
> > > We are using Upstream nomenclature.
> > 
> > The move from linux-patch-xenomai to xenomai-kernel-source is not a
> > simple rename. Providing patches as linux-patch-xenomai did has been
> > obsolete for several debian releases (3 or 4, something like that),
> > and so no longer justified the costly maintenance of the script
> > generating those patches. So, the xenomai-kernel-source package
> > simply contains the part of the xenomai sources and the
> > prepare-kernel.sh script allowing to build a kernel with xenomai
> > support, making the preparation of a kernel the same as the one
> > documented by the upstream package.
> 
> Good. I agree.
> 
> > > - Renamed xenomai-runtime by xenomai-system-tools.
> > > Udev files, init file, test utilities, modprobe utilities. All this stuff
> > > goes to that package.
> > > 
> > > - Drop /dev from libxenomai1.
> > > The /dev directory is created by udev. All debian systems have udev.
> > > However, I'm thinking to have another package with this stuff. What do
> > > you think?
> 
> You didn't answer this ..
> 
> [...]
> 
> > > N:
> > configure.in has been renamed configure.ac in xenomai 3.x. It will
> > not be renamed in xenomai 2.6.x.
> > 
> > > P: xenomai source: source-contains-prebuilt-javascript-object
> > > doc/generated/html/api/jquery.js mean line length is about 16131
> > > characters
> > > N:
> > > N:    The source tarball contains a prebuilt (minified) JavaScript object.
> > > N:    They are usually left by mistake when generating the tarball by not
> > > N:    cleaning the source directory first. You may want to report this as
> > > an N:    upstream bug, in case there is no sign that this was intended.
> > No, this is intended, this file is part of the documentation
> > generated by doxygen, and we want that documentation to be
> > installable on the users system without any need to install doxygen.
> 
> Ok, I know.
> 
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> > > N:
> > > N:    This package provides an ELF binary that lacks the "read-only
> > > N:    relocation" link flag. This package was likely not built with the
> > > N:    default Debian compiler flags defined by dpkg-buildflags. If built
> > > using N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> > > N:
> > > N:    Refer to https://wiki.debian.org/Hardening for details.
> > > N:
> > > N:    Severity: normal, Certainty: certain
> > > N:
> > > N:    Check: binaries, Type: binary, udeb
> > > N:
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> > > W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/native+posix/mq_select
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/native/heap
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/native/leaks
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/native/sigdebug
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/native/tsc
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/leaks
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/mprotect
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/nano_test
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/shm
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/test_pip_exit
> > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > gnu/xenomai/regression/posix/xddp_test
> > > W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
> > > W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> > > 
> > 
> > Please provide the patch to the debian/rules to apply this change. I
> > do not think we did anything special to avoid using the default flags.
> 
> 
> my configure line says:
> 
> CONFIG_OPTS += --prefix=/usr \
>                     --includedir=/usr/include/xenomai \
>                     --mandir=/usr/share/man \
>                     --with-testdir=/usr/lib/$(DEB_HOST_MULTIARCH)/xenomai \
>                     --enable-fortify \
>                     --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)/'
> 
> 
> plus some specific arch params.

What specific arch params? Last time I checked in the in-tree
debian/rules, these arch params were obsolete, so, I removed them
all.


> I have tested it with --enable-fortify and 
> without.

--enable-fortify, as documented, allows applications built for the
POSIX skin with the fortify define (_FORTIFY_SOURCE), to correctly
link with Xenomai libraries (IOW, it provides implementation of
__wrap_printf_chk and the like). It has no influence on building
Xenomai with that flag.

> 
> I have also:
> DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
> 
> following
> 
> https://wiki.debian.org/Hardening
> 
> any help in this stuff will help.

The in-tree debian/rules exports the variable DEB_BUILD_HARDENING=1
to build the package with hardening. At the time I read the wiki,
this was one recommended way, supposing that the wiki was up to date
when I read it. I am afraid I can you help more on this, this looks
like a debian specific problem.


-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/27c09373/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

El Dijous, 25 de juny de 2015, a les 14:54:14, Gilles Chanteperdrix va 
escriure:
> > > > 
> > > > - Drop /dev from libxenomai1.
> > > > The /dev directory is created by udev. All debian systems have udev.
> > > > However, I'm thinking to have another package with this stuff. What do
> > > > you think?
> > 
> > You didn't answer this ..
Gilles,

I have dropped /dev from libxenomai. Could be problematic?

[...]


> > 
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> > > > N:
> > > > N:    This package provides an ELF binary that lacks the "read-only
> > > > N:    relocation" link flag. This package was likely not built with
> > > > the
> > > > N:    default Debian compiler flags defined by dpkg-buildflags. If
> > > > built
> > > > using N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> > > > N:
> > > > N:    Refer to https://wiki.debian.org/Hardening for details.
> > > > N:
> > > > N:    Severity: normal, Certainty: certain
> > > > N:
> > > > N:    Check: binaries, Type: binary, udeb
> > > > N:
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> > > > W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/native+posix/mq_select
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/native/heap
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/native/leaks
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/native/sigdebug
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/native/tsc
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/leaks
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/mprotect
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/nano_test
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/shm
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/test_pip_exit
> > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > gnu/xenomai/regression/posix/xddp_test
> > > > W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
> > > > W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> > > 
> > > Please provide the patch to the debian/rules to apply this change. I
> > > do not think we did anything special to avoid using the default flags.
> > 
> > my configure line says:
> > 
> > CONFIG_OPTS += --prefix=/usr \
> > 
> >                     --includedir=/usr/include/xenomai \
> >                     --mandir=/usr/share/man \
> >                     --with-testdir=/usr/lib/$(DEB_HOST_MULTIARCH)/xenomai
> >                     \
> >                     --enable-fortify \
> >                     --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)/'
> > 
> > plus some specific arch params.
> 
> What specific arch params? Last time I checked in the in-tree
> debian/rules, these arch params were obsolete, so, I removed them
> all.

ifeq ($(DEB_HOST_ARCH), i386)
        CONFIG_OPTS = \
                    --enable-x86-tsc
endif
ifeq ($(DEB_HOST_ARCH), amd64)
        CONFIG_OPTS = \
                    --enable-x86-tsc \
                    --enable-x86-sep  
endif
ifeq ($(DEB_HOST_ARCH), powerpc)
        CONFIG_OPTS =
endif
ifeq ($(DEB_HOST_ARCH), armeb)
        CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
endif
ifeq ($(DEB_HOST_ARCH), armel)
        CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
endif
ifeq ($(DEB_HOST_ARCH), arm)
        CONFIG_OPTS = --enable-arm-mach=generic
endif


> > I have tested it with --enable-fortify and
> > without.
> 
> --enable-fortify, as documented, allows applications built for the
> POSIX skin with the fortify define (_FORTIFY_SOURCE), to correctly
> link with Xenomai libraries (IOW, it provides implementation of
> __wrap_printf_chk and the like). It has no influence on building
> Xenomai with that flag.
> 
> > I have also:
> > DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
> > 
> > following
> > 
> > https://wiki.debian.org/Hardening
> > 
> > any help in this stuff will help.
> 
> The in-tree debian/rules exports the variable DEB_BUILD_HARDENING=1
> to build the package with hardening. At the time I read the wiki,
> this was one recommended way, supposing that the wiki was up to date
> when I read it. I am afraid I can you help more on this, this looks
> like a debian specific problem.

Ok,

the other people have the same issue?

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/5031107f/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 03:56:49PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dijous, 25 de juny de 2015, a les 14:54:14, Gilles Chanteperdrix va 
> escriure:
> > > > > 
> > > > > - Drop /dev from libxenomai1.
> > > > > The /dev directory is created by udev. All debian systems have udev.
> > > > > However, I'm thinking to have another package with this stuff. What do
> > > > > you think?
> > > 
> > > You didn't answer this ..
> Gilles,
> 
> I have dropped /dev from libxenomai. Could be problematic?

How should I know, I never did that. I would think not since the
udev rules should create the nodes, but you have to check.

> 
> [...]
> 
> 
> > > 
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> > > > > N:
> > > > > N:    This package provides an ELF binary that lacks the "read-only
> > > > > N:    relocation" link flag. This package was likely not built with
> > > > > the
> > > > > N:    default Debian compiler flags defined by dpkg-buildflags. If
> > > > > built
> > > > > using N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> > > > > N:
> > > > > N:    Refer to https://wiki.debian.org/Hardening for details.
> > > > > N:
> > > > > N:    Severity: normal, Certainty: certain
> > > > > N:
> > > > > N:    Check: binaries, Type: binary, udeb
> > > > > N:
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/native+posix/mq_select
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/native/heap
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/native/leaks
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/native/sigdebug
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/native/tsc
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/leaks
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/mprotect
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/nano_test
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/shm
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/test_pip_exit
> > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > gnu/xenomai/regression/posix/xddp_test
> > > > > W: xenomai-system-tools: hardening-no-relro usr/sbin/analogy_config
> > > > > W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> > > > 
> > > > Please provide the patch to the debian/rules to apply this change. I
> > > > do not think we did anything special to avoid using the default flags.
> > > 
> > > my configure line says:
> > > 
> > > CONFIG_OPTS += --prefix=/usr \
> > > 
> > >                     --includedir=/usr/include/xenomai \
> > >                     --mandir=/usr/share/man \
> > >                     --with-testdir=/usr/lib/$(DEB_HOST_MULTIARCH)/xenomai
> > >                     \
> > >                     --enable-fortify \
> > >                     --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)/'
> > > 
> > > plus some specific arch params.
> > 
> > What specific arch params? Last time I checked in the in-tree
> > debian/rules, these arch params were obsolete, so, I removed them
> > all.
> 
> ifeq ($(DEB_HOST_ARCH), i386)
>         CONFIG_OPTS = \
>                     --enable-x86-tsc
> endif
> ifeq ($(DEB_HOST_ARCH), amd64)
>         CONFIG_OPTS = \
>                     --enable-x86-tsc \
>                     --enable-x86-sep  
> endif
> ifeq ($(DEB_HOST_ARCH), powerpc)
>         CONFIG_OPTS =
> endif
> ifeq ($(DEB_HOST_ARCH), armeb)
>         CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
> endif
> ifeq ($(DEB_HOST_ARCH), armel)
>         CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
> endif
> ifeq ($(DEB_HOST_ARCH), arm)
>         CONFIG_OPTS = --enable-arm-mach=generic
> endif

ARM options are obsolete (and cause configure to emit a warning
BTW), x86 are not, but are useless since these options have been the
default for a long time.

> 
> 
> > > I have tested it with --enable-fortify and
> > > without.
> > 
> > --enable-fortify, as documented, allows applications built for the
> > POSIX skin with the fortify define (_FORTIFY_SOURCE), to correctly
> > link with Xenomai libraries (IOW, it provides implementation of
> > __wrap_printf_chk and the like). It has no influence on building
> > Xenomai with that flag.
> > 
> > > I have also:
> > > DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
> > > 
> > > following
> > > 
> > > https://wiki.debian.org/Hardening
> > > 
> > > any help in this stuff will help.
> > 
> > The in-tree debian/rules exports the variable DEB_BUILD_HARDENING=1
> > to build the package with hardening. At the time I read the wiki,
> > this was one recommended way, supposing that the wiki was up to date
> > when I read it. I am afraid I can you help more on this, this looks
> > like a debian specific problem.
> 
> Ok,
> 
> the other people have the same issue?

What debian defines as "hardening" is debian-specific, so, I do not
know whether all of these options work. Someone has to check, and
you are the best person for the job.

-- 
					    Gilles.
https://click-hack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/b8548b52/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

El Dijous, 25 de juny de 2015, a les 16:06:41, Gilles Chanteperdrix va 
escriure:
> On Thu, Jun 25, 2015 at 03:56:49PM +0200, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 25 de juny de 2015, a les 14:54:14, Gilles Chanteperdrix va
> > 
> > escriure:
> > > > > > - Drop /dev from libxenomai1.
> > > > > > The /dev directory is created by udev. All debian systems have
> > > > > > udev.
> > > > > > However, I'm thinking to have another package with this stuff.
> > > > > > What do
> > > > > > you think?
> > > > 
> > > > You didn't answer this ..
> > 
> > Gilles,
> > 
> > I have dropped /dev from libxenomai. Could be problematic?
> 
> How should I know, I never did that. I would think not since the
> udev rules should create the nodes, but you have to check.

My tests have reported that nothing have happened, so I guess that nothing.

> 
> > [...]
> > 
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_bits
> > > > > > N:
> > > > > > N:    This package provides an ELF binary that lacks the
> > > > > > "read-only
> > > > > > N:    relocation" link flag. This package was likely not built
> > > > > > with
> > > > > > the
> > > > > > N:    default Debian compiler flags defined by dpkg-buildflags. If
> > > > > > built
> > > > > > using N:    dpkg-buildflags directly, be sure to import LDFLAGS.
> > > > > > N:
> > > > > > N:    Refer to https://wiki.debian.org/Hardening for details.
> > > > > > N:
> > > > > > N:    Severity: normal, Certainty: certain
> > > > > > N:
> > > > > > N:    Check: binaries, Type: binary, udeb
> > > > > > N:
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_read
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/cmd_write
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_bits
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_read
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/insn_write
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcanrecv
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/rtcansend
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/bin/wf_generate
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/native+posix/mq_select
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/native/heap
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/native/leaks
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/native/sigdebug
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/native/tsc
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/leaks
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/mprotect
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/nano_test
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/shm
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/test_pip_exit
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/lib/x86_64-linux-
> > > > > > gnu/xenomai/regression/posix/xddp_test
> > > > > > W: xenomai-system-tools: hardening-no-relro
> > > > > > usr/sbin/analogy_config
> > > > > > W: xenomai-system-tools: hardening-no-relro usr/sbin/rtcanconfig
> > > > > 
> > > > > Please provide the patch to the debian/rules to apply this change. I
> > > > > do not think we did anything special to avoid using the default
> > > > > flags.
> > > > 
> > > > my configure line says:
> > > > 
> > > > CONFIG_OPTS += --prefix=/usr \
> > > > 
> > > >                     --includedir=/usr/include/xenomai \
> > > >                     --mandir=/usr/share/man \
> > > >                     --with-testdir=/usr/lib/$(DEB_HOST_MULTIARCH)/xeno
> > > >                     mai
> > > >                     \
> > > >                     --enable-fortify \
> > > >                     --libdir='$${prefix}/lib/$(DEB_HOST_MULTIARCH)/'
> > > > 
> > > > plus some specific arch params.
> > > 
> > > What specific arch params? Last time I checked in the in-tree
> > > debian/rules, these arch params were obsolete, so, I removed them
> > > all.
> > 
> > ifeq ($(DEB_HOST_ARCH), i386)
> > 
> >         CONFIG_OPTS = \
> >         
> >                     --enable-x86-tsc
> > 
> > endif
> > ifeq ($(DEB_HOST_ARCH), amd64)
> > 
> >         CONFIG_OPTS = \
> >         
> >                     --enable-x86-tsc \
> >                     --enable-x86-sep
> > 
> > endif
> > ifeq ($(DEB_HOST_ARCH), powerpc)
> > 
> >         CONFIG_OPTS =
> > 
> > endif
> > ifeq ($(DEB_HOST_ARCH), armeb)
> > 
> >         CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
> > 
> > endif
> > ifeq ($(DEB_HOST_ARCH), armel)
> > 
> >         CONFIG_OPTS = --enable-arm-mach=generic --enable-arm-eabi
> > 
> > endif
> > ifeq ($(DEB_HOST_ARCH), arm)
> > 
> >         CONFIG_OPTS = --enable-arm-mach=generic
> > 
> > endif
> 
> ARM options are obsolete (and cause configure to emit a warning
> BTW), x86 are not, but are useless since these options have been the
> default for a long time.

Ok, so, may I drop the defaults options to: arm, armel, armeb, i386 amd amd64?

Or, better, may I drop all?


> > > > I have tested it with --enable-fortify and
> > > > without.
> > > 
> > > --enable-fortify, as documented, allows applications built for the
> > > POSIX skin with the fortify define (_FORTIFY_SOURCE), to correctly
> > > link with Xenomai libraries (IOW, it provides implementation of
> > > __wrap_printf_chk and the like). It has no influence on building
> > > Xenomai with that flag.
> > > 
> > > > I have also:
> > > > DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
> > > > 
> > > > following
> > > > 
> > > > https://wiki.debian.org/Hardening
> > > > 
> > > > any help in this stuff will help.
> > > 
> > > The in-tree debian/rules exports the variable DEB_BUILD_HARDENING=1
> > > to build the package with hardening. At the time I read the wiki,
> > > this was one recommended way, supposing that the wiki was up to date
> > > when I read it. I am afraid I can you help more on this, this looks
> > > like a debian specific problem.
> > 
> > Ok,
> > 
> > the other people have the same issue?
> 
> What debian defines as "hardening" is debian-specific, so, I do not
> know whether all of these options work. Someone has to check, and
> you are the best person for the job.

Ok, I will investigate.


Thanks for all,


Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/15c1e17b/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> - I have removed the previous debian patches (incorporated by upstream) but I 
> have added one commit from upstream to build with 2.6.4 kernels => 3.11.

Would be interested to know about this patch, because Xenomai 2.6.4
has been built-tested with kernels up to 3.14, so, there is no
problem to build it with versions superior to 3.11 that I know of.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

El Dijous, 25 de juny de 2015, a les 22:56:08, Gilles Chanteperdrix va 
escriure:
> On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> > - I have removed the previous debian patches (incorporated by upstream)
> > but I have added one commit from upstream to build with 2.6.4 kernels =>
> > 3.11.
> Would be interested to know about this patch, because Xenomai 2.6.4
> has been built-tested with kernels up to 3.14, so, there is no
> problem to build it with versions superior to 3.11 that I know of.

Gilles,

on 2014-09-25 you released 2.6.4.

on 2015-01-16 you did a commit (can/flexcan: fixup for kernel release >= 3.11) 
that is the one that I noticed.

However, looking now the log there are two commits that will affect on arm 
platforms:
2014-11-24	hal/arm: fixup for Linux 3.16	
2014-11-05	hal: fixups for kernel 3.16

So, probably I will need them too.

All this patches came after the official released 2.6.4.

Personally, I would love a 2.6.5 with all the fixes ...

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150625/0355eaf7/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 11:10:32PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dijous, 25 de juny de 2015, a les 22:56:08, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> > > - I have removed the previous debian patches (incorporated by upstream)
> > > but I have added one commit from upstream to build with 2.6.4 kernels =>
> > > 3.11.
> > Would be interested to know about this patch, because Xenomai 2.6.4
> > has been built-tested with kernels up to 3.14, so, there is no
> > problem to build it with versions superior to 3.11 that I know of.
> 
> Gilles,
> 
> on 2014-09-25 you released 2.6.4.
> 
> on 2015-01-16 you did a commit (can/flexcan: fixup for kernel release >= 3.11) 
> that is the one that I noticed.
> 
> However, looking now the log there are two commits that will affect on arm 
> platforms:
> 2014-11-24	hal/arm: fixup for Linux 3.16	
> 2014-11-05	hal: fixups for kernel 3.16
> 
> So, probably I will need them too.
> 
> All this patches came after the official released 2.6.4.
> 
> Personally, I would love a 2.6.5 with all the fixes ...

2.6.5 will probably happen, but not before the work on 3.0 is finished.

-- 
					    Gilles.
https://click-hack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150626/b18ced63/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Gilles Chanteperdrix]

On Thu, Jun 25, 2015 at 11:10:32PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dijous, 25 de juny de 2015, a les 22:56:08, Gilles Chanteperdrix va 
> escriure:
> > On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda wrote:
> > > - I have removed the previous debian patches (incorporated by upstream)
> > > but I have added one commit from upstream to build with 2.6.4 kernels =>
> > > 3.11.
> > Would be interested to know about this patch, because Xenomai 2.6.4
> > has been built-tested with kernels up to 3.14, so, there is no
> > problem to build it with versions superior to 3.11 that I know of.
> 
> Gilles,
> 
> on 2014-09-25 you released 2.6.4.
> 
> on 2015-01-16 you did a commit (can/flexcan: fixup for kernel release >= 3.11) 
> that is the one that I noticed.

Indeed, merging that one makes sense.

> 
> However, looking now the log there are two commits that will affect on arm 
> platforms:
> 2014-11-24	hal/arm: fixup for Linux 3.16	
> 2014-11-05	hal: fixups for kernel 3.16
> 
> So, probably I will need them too.

I would not recommend that. Xenomai 2.6.4 has been tested and
released to support kernel versions up to 3.14, so, I would keep it
like that. Xenomai 3.0 supports higher kernel versions, Xenomai
2.6.5 will probably also, but I will test the 3.16 and 3.18 versions
extensively before releasing it.

-- 
					    Gilles.
https://click-hack.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150626/9c1af026/attachment.sig>

Re: [Xenomai] Debian package of Xenomai 2.6.4

[Leopold Palomo-Avellaneda]

El Divendres, 26 de juny de 2015, a les 14:49:47, Gilles Chanteperdrix va 
escriure:
> On Thu, Jun 25, 2015 at 11:10:32PM +0200, Leopold Palomo-Avellaneda wrote:
> > El Dijous, 25 de juny de 2015, a les 22:56:08, Gilles Chanteperdrix va
> > 
> > escriure:
> > > On Thu, Jun 25, 2015 at 01:43:51PM +0200, Leopold Palomo-Avellaneda 
wrote:
> > > > - I have removed the previous debian patches (incorporated by
> > > > upstream)
> > > > but I have added one commit from upstream to build with 2.6.4 kernels
> > > > =>
> > > > 3.11.
> > > 
> > > Would be interested to know about this patch, because Xenomai 2.6.4
> > > has been built-tested with kernels up to 3.14, so, there is no
> > > problem to build it with versions superior to 3.11 that I know of.
> > 
> > Gilles,
> > 
> > on 2014-09-25 you released 2.6.4.
> > 
> > on 2015-01-16 you did a commit (can/flexcan: fixup for kernel release >=
> > 3.11) that is the one that I noticed.
> 
> Indeed, merging that one makes sense.
> 
> > However, looking now the log there are two commits that will affect on arm
> > platforms:
> > 2014-11-24	hal/arm: fixup for Linux 3.16
> > 2014-11-05	hal: fixups for kernel 3.16
> > 
> > So, probably I will need them too.
> 
> I would not recommend that. Xenomai 2.6.4 
ftp://ftp.kernel.org/pub/linux/kernel/v3.x/linux-3.16.7.tar.xzhas been tested 
and
> released to support kernel versions up to 3.14, so, I would keep it
> like that. Xenomai 3.0 supports higher kernel versions, Xenomai
> 2.6.5 will probably also, but I will test the 3.16 and 3.18 versions
> extensively before releasing it.

Perfect. I have _only_ tested amd64 platform and it have been worked with 3.16 
without any noticeable problem.

Leopold 

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150626/ada46503/attachment.sig>