[Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

Since 8871363fa57266af4c8d8a06965f2898b940fb48 the binary and its man-page
are in the base package (xenomai-runtime). Remove the files from the -dev
package to resolve the current package conflict.

Signed-off-by: Henning Schild <henning.schild@siemens.com>
---
 debian/libxenomai-dev.install | 2 --
 1 file changed, 2 deletions(-)

diff --git a/debian/libxenomai-dev.install b/debian/libxenomai-dev.install
index 40ae57d..7b107cb 100644
--- a/debian/libxenomai-dev.install
+++ b/debian/libxenomai-dev.install
@@ -1,8 +1,6 @@
-usr/bin/xeno-config
 usr/include
 usr/lib/*.la
 usr/lib/*.a
 usr/lib/*.so
 usr/lib/cobalt.wrappers
 usr/lib/dynlist.ld
-usr/share/man/man1/xeno-config.1
-- 
1.9.1

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, Apr 30, 2015 at 01:59:54PM +0200, Henning Schild wrote:
> Since 8871363fa57266af4c8d8a06965f2898b940fb48 the binary and its man-page
> are in the base package (xenomai-runtime). Remove the files from the -dev
> package to resolve the current package conflict.

I would rather do things the other way around: move xeno-config and
its man page to the -dev package and remove them from the runtime
package.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Leopold Palomo-Avellaneda]

El Dijous, 30 d'abril de 2015, a les 14:23:59, Gilles Chanteperdrix va 
escriure:
> On Thu, Apr 30, 2015 at 01:59:54PM +0200, Henning Schild wrote:
> > Since 8871363fa57266af4c8d8a06965f2898b940fb48 the binary and its man-page
> > are in the base package (xenomai-runtime). Remove the files from the -dev
> > package to resolve the current package conflict.
> 
> I would rather do things the other way around: move xeno-config and
> its man page to the -dev package and remove them from the runtime
> package.
+1 

-- 
--
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?

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

On Thu, 30 Apr 2015 14:23:59 +0200
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> On Thu, Apr 30, 2015 at 01:59:54PM +0200, Henning Schild wrote:
> > Since 8871363fa57266af4c8d8a06965f2898b940fb48 the binary and its
> > man-page are in the base package (xenomai-runtime). Remove the
> > files from the -dev package to resolve the current package conflict.
> 
> I would rather do things the other way around: move xeno-config and
> its man page to the -dev package and remove them from the runtime
> package.
> 

Ok with me. "git revert 8871363fa57266af4c8d8a06965f2898b940fb48"

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

On Thu, 30 Apr 2015 15:04:20 +0200
Henning Schild <henning.schild@siemens.com> wrote:

> Ok with me. "git revert 8871363fa57266af4c8d8a06965f2898b940fb48"

Bump. Should i send the revert patch?

Henning

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

Hey Guys,

we have a continuous integration setup here at Siemens. Next to our own
repos we also compile and test upstream to detect problems before
merging.
I know the changes to the debian directory seem unimportant, but our
current CI infrastructure is built on that. So please consider applying
my suggestions. Using the CI we hope to find and fix issues in the
whole project but for that to work we need a reliable way of deploying
binaries to our test systems.

If there is a debian directory in the tree, it should be consistent.
The other option would be to remove it all together, i personally
prefer the first option.

regards,
Henning

On Thu, 30 Apr 2015 13:59:54 +0200
Henning Schild <henning.schild@siemens.com> wrote:

> Since 8871363fa57266af4c8d8a06965f2898b940fb48 the binary and its
> man-page are in the base package (xenomai-runtime). Remove the files
> from the -dev package to resolve the current package conflict.
> 
> Signed-off-by: Henning Schild <henning.schild@siemens.com>
> ---
>  debian/libxenomai-dev.install | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/debian/libxenomai-dev.install
> b/debian/libxenomai-dev.install index 40ae57d..7b107cb 100644
> --- a/debian/libxenomai-dev.install
> +++ b/debian/libxenomai-dev.install
> @@ -1,8 +1,6 @@
> -usr/bin/xeno-config
>  usr/include
>  usr/lib/*.la
>  usr/lib/*.a
>  usr/lib/*.so
>  usr/lib/cobalt.wrappers
>  usr/lib/dynlist.ld
> -usr/share/man/man1/xeno-config.1

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Philippe Gerum]

On 05/27/2015 11:11 AM, Henning Schild wrote:
> Hey Guys,
> 
> we have a continuous integration setup here at Siemens. Next to our own
> repos we also compile and test upstream to detect problems before
> merging.
> I know the changes to the debian directory seem unimportant, but our
> current CI infrastructure is built on that. So please consider applying
> my suggestions. Using the CI we hope to find and fix issues in the
> whole project but for that to work we need a reliable way of deploying
> binaries to our test systems.
> 
> If there is a debian directory in the tree, it should be consistent.
> The other option would be to remove it all together, i personally
> prefer the first option.

You mean this?

http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6197b64eb8edba8fbee4

-- 
Philippe.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

On Wed, 27 May 2015 11:21:33 +0200
Philippe Gerum <rpm@xenomai.org> wrote:
 
> You mean this?
> 
> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6197b64eb8edba8fbee4

Ahh. Yes i meant this. The actual conclusion of the discussion to this
patch was to revert the change that introduced the problem and not
apply my patch. But for me either way is fine.

I also referred to another change i suggested and am still waiting for
feedback:
https://xenomai.org/pipermail/xenomai/2015-April/034105.html

regards,
Henning

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Philippe Gerum]

On 05/27/2015 01:09 PM, Henning Schild wrote:
> On Wed, 27 May 2015 11:21:33 +0200
> Philippe Gerum <rpm@xenomai.org> wrote:
>  
>> You mean this?
>>
>> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6197b64eb8edba8fbee4
> 
> Ahh. Yes i meant this. The actual conclusion of the discussion to this
> patch was to revert the change that introduced the problem and not
> apply my patch. But for me either way is fine.
> 

Actually, the right approach is to move xeno-config to the base package,
since it now delivers information about the runtime system as well.

> I also referred to another change i suggested and am still waiting for
> feedback:
> https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> 

Looks ok. I'll pick that one unless Gilles pulls the break for any
debian-specific issue.

-- 
Philippe.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Wed, May 27, 2015 at 01:49:20PM +0200, Philippe Gerum wrote:
> On 05/27/2015 01:09 PM, Henning Schild wrote:
> > On Wed, 27 May 2015 11:21:33 +0200
> > Philippe Gerum <rpm@xenomai.org> wrote:
> >  
> >> You mean this?
> >>
> >> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6197b64eb8edba8fbee4
> > 
> > Ahh. Yes i meant this. The actual conclusion of the discussion to this
> > patch was to revert the change that introduced the problem and not
> > apply my patch. But for me either way is fine.
> > 
> 
> Actually, the right approach is to move xeno-config to the base package,
> since it now delivers information about the runtime system as well.
> 
> > I also referred to another change i suggested and am still waiting for
> > feedback:
> > https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> > 
> 
> Looks ok. I'll pick that one unless Gilles pulls the break for any
> debian-specific issue.

No, that is fine by me. As of 2014, I have stopped being a Debian
user (after being one for 17 years), so, I care less and less about
it, I have reached a point where everything about this distribution
seems over-designed, gets in the way on the desktop of someone who
mainly does software development, and paradoxically lead to bad
quality software. 

In any case, I am no longer running Debian on my desktop, and
restarting a server to test a Xenomai release is out of the
question, so it would not be easy for me to test Debian packaging.
Since we do not really have a Debian maintainer (and we never did
really have one judging by the work the person that claimed to be
one did), I would be in favor of dropping the ball and removing the
debian directory, unless someone steps up for assuming this role,
but I mean, with a real intention of commitment to the task.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

On Wed, 27 May 2015 15:43:18 +0200
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> In any case, I am no longer running Debian on my desktop, and
> restarting a server to test a Xenomai release is out of the
> question, so it would not be easy for me to test Debian packaging.
> Since we do not really have a Debian maintainer (and we never did
> really have one judging by the work the person that claimed to be
> one did), I would be in favor of dropping the ball and removing the
> debian directory, unless someone steps up for assuming this role,
> but I mean, with a real intention of commitment to the task.

I am not sure to what degree i can guarantee my personal commitment,
that will depend on project assignments. At the moment we are back to
a working state so please do not drop it.
We at Siemens will continue to have a need for it, and will continue to
recognize when it breaks. I hope that is enough commitment for now ;).

Henning

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Wed, May 27, 2015 at 03:55:42PM +0200, Henning Schild wrote:
> On Wed, 27 May 2015 15:43:18 +0200
> Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> 
> > In any case, I am no longer running Debian on my desktop, and
> > restarting a server to test a Xenomai release is out of the
> > question, so it would not be easy for me to test Debian packaging.
> > Since we do not really have a Debian maintainer (and we never did
> > really have one judging by the work the person that claimed to be
> > one did), I would be in favor of dropping the ball and removing the
> > debian directory, unless someone steps up for assuming this role,
> > but I mean, with a real intention of commitment to the task.
> 
> I am not sure to what degree i can guarantee my personal commitment,
> that will depend on project assignments. At the moment we are back to
> a working state so please do not drop it.
> We at Siemens will continue to have a need for it, and will continue to
> recognize when it breaks. I hope that is enough commitment for now ;).

I see more a maintainer as someone who takes responsibility for
something, than someone who just "patches it up when it is broken".
The latter is what we had until now.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Lennart Sorensen]

On Wed, May 27, 2015 at 03:43:18PM +0200, Gilles Chanteperdrix wrote:
> No, that is fine by me. As of 2014, I have stopped being a Debian
> user (after being one for 17 years), so, I care less and less about
> it, I have reached a point where everything about this distribution
> seems over-designed, gets in the way on the desktop of someone who
> mainly does software development, and paradoxically lead to bad
> quality software. 
> 
> In any case, I am no longer running Debian on my desktop, and
> restarting a server to test a Xenomai release is out of the
> question, so it would not be easy for me to test Debian packaging.
> Since we do not really have a Debian maintainer (and we never did
> really have one judging by the work the person that claimed to be
> one did), I would be in favor of dropping the ball and removing the
> debian directory, unless someone steps up for assuming this role,
> but I mean, with a real intention of commitment to the task.

Please don't, it actually works and is really handy for those of us that
do use Debian.  The debian files in the xenomai git tree are in much
better condition than anything that was every included with debian
officially, so it is actually quite good right now.

-- 
Len Sorensen

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Lennart Sorensen]

On Wed, May 27, 2015 at 03:55:42PM +0200, Henning Schild wrote:
> I am not sure to what degree i can guarantee my personal commitment,
> that will depend on project assignments. At the moment we are back to
> a working state so please do not drop it.
> We at Siemens will continue to have a need for it, and will continue to
> recognize when it breaks. I hope that is enough commitment for now ;).

And we at a different division of Siemens use it too. :)

-- 
Len Sorensen

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Wed, May 27, 2015 at 03:43:18PM +0200, Gilles Chanteperdrix wrote:
> On Wed, May 27, 2015 at 01:49:20PM +0200, Philippe Gerum wrote:
> > On 05/27/2015 01:09 PM, Henning Schild wrote:
> > > On Wed, 27 May 2015 11:21:33 +0200
> > > Philippe Gerum <rpm@xenomai.org> wrote:
> > >  
> > >> You mean this?
> > >>
> > >> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6197b64eb8edba8fbee4
> > > 
> > > Ahh. Yes i meant this. The actual conclusion of the discussion to this
> > > patch was to revert the change that introduced the problem and not
> > > apply my patch. But for me either way is fine.
> > > 
> > 
> > Actually, the right approach is to move xeno-config to the base package,
> > since it now delivers information about the runtime system as well.
> > 
> > > I also referred to another change i suggested and am still waiting for
> > > feedback:
> > > https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> > > 
> > 
> > Looks ok. I'll pick that one unless Gilles pulls the break for any
> > debian-specific issue.
> 
> No, that is fine by me. As of 2014, I have stopped being a Debian
> user (after being one for 17 years), so, I care less and less about
> it, I have reached a point where everything about this distribution
> seems over-designed, gets in the way on the desktop of someone who
> mainly does software development, and paradoxically lead to bad
> quality software. 
> 
> In any case, I am no longer running Debian on my desktop, and
> restarting a server to test a Xenomai release is out of the
> question, so it would not be easy for me to test Debian packaging.
> Since we do not really have a Debian maintainer (and we never did
> really have one judging by the work the person that claimed to be
> one did), I would be in favor of dropping the ball and removing the
> debian directory, unless someone steps up for assuming this role,
> but I mean, with a real intention of commitment to the task.

Just to add something more to the subject: I do not think being the
debian maintainer of the Xenomai package is a hard task. I mean come
on, it is just basically a Makefile shorter than some other
Makefiles in the project. But this requires staying in touch with
the Debian project to know what the "good practices" are, what
practices have become deprecated and what new debian helper could
make the packaging even simpler, things I do not care to do. In any
case, this should be a good reason not to botch the task. A botched
hard task is easier to understand than a botched easy task.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Leopold Palomo-Avellaneda]

El Dimecres, 27 de maig de 2015, a les 17:57:32, Gilles Chanteperdrix va 
escriure:
> On Wed, May 27, 2015 at 03:43:18PM +0200, Gilles Chanteperdrix wrote:
> > On Wed, May 27, 2015 at 01:49:20PM +0200, Philippe Gerum wrote:
> > > On 05/27/2015 01:09 PM, Henning Schild wrote:
> > > > On Wed, 27 May 2015 11:21:33 +0200
> > > > 
> > > > Philippe Gerum <rpm@xenomai.org> wrote:
> > > >> You mean this?
> > > >> 
> > > >> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6
> > > >> 197b64eb8edba8fbee4> > > 
> > > > Ahh. Yes i meant this. The actual conclusion of the discussion to this
> > > > patch was to revert the change that introduced the problem and not
> > > > apply my patch. But for me either way is fine.
> > > 
> > > Actually, the right approach is to move xeno-config to the base package,
> > > since it now delivers information about the runtime system as well.
> > > 
> > > > I also referred to another change i suggested and am still waiting for
> > > > feedback:
> > > > https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> > > 
> > > Looks ok. I'll pick that one unless Gilles pulls the break for any
> > > debian-specific issue.
> > 
> > No, that is fine by me. As of 2014, I have stopped being a Debian
> > user (after being one for 17 years), so, I care less and less about
> > it, I have reached a point where everything about this distribution
> > seems over-designed, gets in the way on the desktop of someone who
> > mainly does software development, and paradoxically lead to bad
> > quality software.
> > 
> > In any case, I am no longer running Debian on my desktop, and
> > restarting a server to test a Xenomai release is out of the
> > question, so it would not be easy for me to test Debian packaging.
> > Since we do not really have a Debian maintainer (and we never did
> > really have one judging by the work the person that claimed to be
> > one did), I would be in favor of dropping the ball and removing the
> > debian directory, unless someone steps up for assuming this role,
> > but I mean, with a real intention of commitment to the task.

It's sad to me that a debian user with a long experience like you have 
abandoned the distro. But I'm sure that you will have a good reasons. Anyway, 
please, share them and we could try to improve that.

> Just to add something more to the subject: I do not think being the
> debian maintainer of the Xenomai package is a hard task. I mean come
> on, it is just basically a Makefile shorter than some other
> Makefiles in the project. But this requires staying in touch with
> the Debian project to know what the "good practices" are, what
> practices have become deprecated and what new debian helper could
> make the packaging even simpler, things I do not care to do. In any
> case, this should be a good reason not to botch the task. A botched
> hard task is easier to understand than a botched easy task.

Just to inform, because i have been in silence all this thread that some weeks 
ago (maybe two month) I contacted with the debian maintainer of xenomai. I 
offered my help because I was interested in maintain the package. We finally 
will work together, and the debian directory will be hosted in collab-maint 
git, in alioth, a git server of debian.

Said that, because time constraints of the last weeks, I'm just in the 
beginning of review all the packaging of xenomai. I will begin with 2.6.4 and 
after that, I will jump to 3.0 when you released an official one. So, don't try 
to find anything there, because I have nothing done. I will try to inform the 
list about my progress.

Anyway, the idea is to drop your debian directory and put a new one, trying to 
use the "good practices" and the updated debhelper tools. I will try to keep 
the package in a good shape, sync with the upstream last versions, at least in 
unstable. If I could, some backport (because I used it) could be possible.

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/20150527/421774ce/attachment.sig>

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Wed, May 27, 2015 at 11:27:27PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dimecres, 27 de maig de 2015, a les 17:57:32, Gilles Chanteperdrix va 
> escriure:
> > On Wed, May 27, 2015 at 03:43:18PM +0200, Gilles Chanteperdrix wrote:
> > > On Wed, May 27, 2015 at 01:49:20PM +0200, Philippe Gerum wrote:
> > > > On 05/27/2015 01:09 PM, Henning Schild wrote:
> > > > > On Wed, 27 May 2015 11:21:33 +0200
> > > > > 
> > > > > Philippe Gerum <rpm@xenomai.org> wrote:
> > > > >> You mean this?
> > > > >> 
> > > > >> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6
> > > > >> 197b64eb8edba8fbee4> > > 
> > > > > Ahh. Yes i meant this. The actual conclusion of the discussion to this
> > > > > patch was to revert the change that introduced the problem and not
> > > > > apply my patch. But for me either way is fine.
> > > > 
> > > > Actually, the right approach is to move xeno-config to the base package,
> > > > since it now delivers information about the runtime system as well.
> > > > 
> > > > > I also referred to another change i suggested and am still waiting for
> > > > > feedback:
> > > > > https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> > > > 
> > > > Looks ok. I'll pick that one unless Gilles pulls the break for any
> > > > debian-specific issue.
> > > 
> > > No, that is fine by me. As of 2014, I have stopped being a Debian
> > > user (after being one for 17 years), so, I care less and less about
> > > it, I have reached a point where everything about this distribution
> > > seems over-designed, gets in the way on the desktop of someone who
> > > mainly does software development, and paradoxically lead to bad
> > > quality software.
> > > 
> > > In any case, I am no longer running Debian on my desktop, and
> > > restarting a server to test a Xenomai release is out of the
> > > question, so it would not be easy for me to test Debian packaging.
> > > Since we do not really have a Debian maintainer (and we never did
> > > really have one judging by the work the person that claimed to be
> > > one did), I would be in favor of dropping the ball and removing the
> > > debian directory, unless someone steps up for assuming this role,
> > > but I mean, with a real intention of commitment to the task.
> 
> It's sad to me that a debian user with a long experience like you have 
> abandoned the distro. But I'm sure that you will have a good reasons. Anyway, 
> please, share them and we could try to improve that.

I warn you, it is like when you have been knowing someone a very
long time, you have tendency to find unbearable, some defaults that
would seem very small to people with a shorter contact.

Anyway, my recriminations against Debian are:
- the lib/dev/doc package split is really a major PITA when you are
spending your time writing or compiling code built upon third party
libraries;

- the removal of FSF info documentation is a major PITA for the
workstation of a developer that was used to it;

- Debian strives at being simple for the user, but to do so
implements a lot of distribution-specific software, that has a
complex design, requires you to learn how it works, and sometime
even to debug it, because well, complex software inevitably contain
bugs; I prefer a distribution that may be a little less easy to use,
but based on tools with a simple design.

- Debian is supposedly about freedom, but refuses access to its wiki
to us unlucky people living in countries with state required
surveillance policies by ISPs and/or censorship by internet servers
blacklisting who consequently have to use off-shore VPNs to preserve
their freedom;

- the quality of software shipped by Debian depends on the work of
its maintainer more than on the quality of the upstream package,
because many Debian packages are patched to the teeth, resulting in:
. security issues
. packages with reworked organisation of the configuration, which is
thus not the same as the documented upstream one;
. linux kernels that oops and that require you to reboot your
machine from time to time.
. poor packages quality when they are used by very little number of
users, because well, no users tests them, and apparently neither the
maintainer, including in the so-called "Debian stable" distribution

- Debian stable benefits from the best debugging cycle, so is the
Debian distribution of choice, except that not all packages are
debugged equally (see last point), so it is not that stable, but
there is one thing for sure, the packages versions in Debian stable
are outdated. This is mostly a problem for desktop software. I do
not care about running an outdated apache on a server, so long as
the security team provides security updates, I sure as hell care
about the version of xorg, libva, mesa, libqt, firefox, ffmpeg, vlc
or libreoffice I am using though. And no, debian backports and
deb-multimedia do not contain all the packages I would like, and I
do not want to use Debian testing or Debian unstable, because I have
experience of doing so and having the repository containing broken
packages occasionally, and remaining so for some time, which is too
bad if you need the said package.

- since we are at it, the way Christian Marillat, the maintainer of
the repository formerly called "Debian multimedia" was treated;

- the KDE desktop environment does not work so great in Debian, I do
not know to which of the previous point this is due (not many users,
too old versions, buggy patches, or maybe all combined, or maybe
another reason). Unfortunately, this is the desktop I want to use.

- the systemd debacle

- correct me if I am wrong, but a Debian maintainer is not required
to contact upstream when he applies a patch, this results in Debian
packages including patches that would never have been accepted
upstream, and which degrade the package quality. Since a Debian
maintainer also has his own bug tracking system, he can make things
things up "behind upstream's back", cutting himself from the review
of the upstream package, and cutting Debian users from the upstream
package maintainers. This point happened to Xenomai Debian package.
What is more, (again, correctly if I am wrong) a Debian maintainer
is not exactly required to be a developer, so when a Debian user
sends a patch that supposedly "fixes something", the patch may be
utter crap and the maintainer not be able to judge, if he decides to
work in isolation from upstream, the down goes again the package
quality.

I will not provide detailed bug reports, because, well, as I said, I
no longer care about Debian. Maybe you will find this is FUD, and an
easy escape. But you asked for it, and again, I do not care. I am
certainly not going to boot a Debian again, just to give you precise
details.

> 
> > Just to add something more to the subject: I do not think being the
> > debian maintainer of the Xenomai package is a hard task. I mean come
> > on, it is just basically a Makefile shorter than some other
> > Makefiles in the project. But this requires staying in touch with
> > the Debian project to know what the "good practices" are, what
> > practices have become deprecated and what new debian helper could
> > make the packaging even simpler, things I do not care to do. In any
> > case, this should be a good reason not to botch the task. A botched
> > hard task is easier to understand than a botched easy task.
> 
> Just to inform, because i have been in silence all this thread that some weeks 
> ago (maybe two month) I contacted with the debian maintainer of xenomai. I 
> offered my help because I was interested in maintain the package. We finally 
> will work together, and the debian directory will be hosted in collab-maint 
> git, in alioth, a git server of debian.
> 
> Said that, because time constraints of the last weeks, I'm just in the 
> beginning of review all the packaging of xenomai. I will begin with 2.6.4 and 
> after that, I will jump to 3.0 when you released an official one. So, don't try 
> to find anything there, because I have nothing done. I will try to inform the 
> list about my progress.
> 
> Anyway, the idea is to drop your debian directory and put a new one, trying to 
> use the "good practices" and the updated debhelper tools. I will try to keep 
> the package in a good shape, sync with the upstream last versions, at least in 
> unstable. If I could, some backport (because I used it) could be possible.

So, you want to reiterate the previous maintainer mistakes, and
continue to maintain the Xenomai Debian packaging outside of the
Xenomai project. See my last point for why this is a bad idea.
Please, come maintaining Xenomai debian directory, allowing us to
review your work and discuss the patches proposed by Debian users.
If you want to make a new release because of a correction in the
Debian directory, we can arrange something I am sure with a
maintenance branch, or a git tag.

-- 
					    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/20150528/8b49a348/attachment.sig>

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, May 28, 2015 at 01:51:31AM +0200, Gilles Chanteperdrix wrote:
> On Wed, May 27, 2015 at 11:27:27PM +0200, Leopold Palomo-Avellaneda wrote:
> > El Dimecres, 27 de maig de 2015, a les 17:57:32, Gilles Chanteperdrix va 
> > escriure:
> > > On Wed, May 27, 2015 at 03:43:18PM +0200, Gilles Chanteperdrix wrote:
> > > > On Wed, May 27, 2015 at 01:49:20PM +0200, Philippe Gerum wrote:
> > > > > On 05/27/2015 01:09 PM, Henning Schild wrote:
> > > > > > On Wed, 27 May 2015 11:21:33 +0200
> > > > > > 
> > > > > > Philippe Gerum <rpm@xenomai.org> wrote:
> > > > > >> You mean this?
> > > > > >> 
> > > > > >> http://git.xenomai.org/xenomai-3.git/commit/?id=571ec165ad6a22d3f93f6
> > > > > >> 197b64eb8edba8fbee4> > > 
> > > > > > Ahh. Yes i meant this. The actual conclusion of the discussion to this
> > > > > > patch was to revert the change that introduced the problem and not
> > > > > > apply my patch. But for me either way is fine.
> > > > > 
> > > > > Actually, the right approach is to move xeno-config to the base package,
> > > > > since it now delivers information about the runtime system as well.
> > > > > 
> > > > > > I also referred to another change i suggested and am still waiting for
> > > > > > feedback:
> > > > > > https://xenomai.org/pipermail/xenomai/2015-April/034105.html
> > > > > 
> > > > > Looks ok. I'll pick that one unless Gilles pulls the break for any
> > > > > debian-specific issue.
> > > > 
> > > > No, that is fine by me. As of 2014, I have stopped being a Debian
> > > > user (after being one for 17 years), so, I care less and less about
> > > > it, I have reached a point where everything about this distribution
> > > > seems over-designed, gets in the way on the desktop of someone who
> > > > mainly does software development, and paradoxically lead to bad
> > > > quality software.
> > > > 
> > > > In any case, I am no longer running Debian on my desktop, and
> > > > restarting a server to test a Xenomai release is out of the
> > > > question, so it would not be easy for me to test Debian packaging.
> > > > Since we do not really have a Debian maintainer (and we never did
> > > > really have one judging by the work the person that claimed to be
> > > > one did), I would be in favor of dropping the ball and removing the
> > > > debian directory, unless someone steps up for assuming this role,
> > > > but I mean, with a real intention of commitment to the task.
> > 
> > It's sad to me that a debian user with a long experience like you have 
> > abandoned the distro. But I'm sure that you will have a good reasons. Anyway, 
> > please, share them and we could try to improve that.
> 
> I warn you, it is like when you have been knowing someone a very
> long time, you have tendency to find unbearable, some defaults that
> would seem very small to people with a shorter contact.
> 
> Anyway, my recriminations against Debian are:
> - the lib/dev/doc package split is really a major PITA when you are
> spending your time writing or compiling code built upon third party
> libraries;
> 
> - the removal of FSF info documentation is a major PITA for the
> workstation of a developer that was used to it;
> 
> - Debian strives at being simple for the user, but to do so
> implements a lot of distribution-specific software, that has a
> complex design, requires you to learn how it works, and sometime
> even to debug it, because well, complex software inevitably contain
> bugs; I prefer a distribution that may be a little less easy to use,
> but based on tools with a simple design.
> 
> - Debian is supposedly about freedom, but refuses access to its wiki
> to us unlucky people living in countries with state required
> surveillance policies by ISPs and/or censorship by internet servers
> blacklisting who consequently have to use off-shore VPNs to preserve
> their freedom;
> 
> - the quality of software shipped by Debian depends on the work of
> its maintainer more than on the quality of the upstream package,
> because many Debian packages are patched to the teeth, resulting in:
> . security issues
> . packages with reworked organisation of the configuration, which is
> thus not the same as the documented upstream one;
> . linux kernels that oops and that require you to reboot your
> machine from time to time.
> . poor packages quality when they are used by very little number of
> users, because well, no users tests them, and apparently neither the
> maintainer, including in the so-called "Debian stable" distribution
> 
> - Debian stable benefits from the best debugging cycle, so is the
> Debian distribution of choice, except that not all packages are
> debugged equally (see last point), so it is not that stable, but
> there is one thing for sure, the packages versions in Debian stable
> are outdated. This is mostly a problem for desktop software. I do
> not care about running an outdated apache on a server, so long as
> the security team provides security updates, I sure as hell care
> about the version of xorg, libva, mesa, libqt, firefox, ffmpeg, vlc
> or libreoffice I am using though. And no, debian backports and
> deb-multimedia do not contain all the packages I would like, and I
> do not want to use Debian testing or Debian unstable, because I have
> experience of doing so and having the repository containing broken
> packages occasionally, and remaining so for some time, which is too
> bad if you need the said package.
> 
> - since we are at it, the way Christian Marillat, the maintainer of
> the repository formerly called "Debian multimedia" was treated;
> 
> - the KDE desktop environment does not work so great in Debian, I do
> not know to which of the previous point this is due (not many users,
> too old versions, buggy patches, or maybe all combined, or maybe
> another reason). Unfortunately, this is the desktop I want to use.
> 
> - the systemd debacle
> 
> - correct me if I am wrong, but a Debian maintainer is not required
> to contact upstream when he applies a patch, this results in Debian
> packages including patches that would never have been accepted
> upstream, and which degrade the package quality. Since a Debian
> maintainer also has his own bug tracking system, he can make things
> things up "behind upstream's back", cutting himself from the review
> of the upstream package, and cutting Debian users from the upstream
> package maintainers. This point happened to Xenomai Debian package.
> What is more, (again, correctly if I am wrong) a Debian maintainer
> is not exactly required to be a developer, so when a Debian user
> sends a patch that supposedly "fixes something", the patch may be
> utter crap and the maintainer not be able to judge, if he decides to
> work in isolation from upstream, the down goes again the package
> quality.
> 
> I will not provide detailed bug reports, because, well, as I said, I
> no longer care about Debian. Maybe you will find this is FUD, and an
> easy escape. But you asked for it, and again, I do not care. I am
> certainly not going to boot a Debian again, just to give you precise
> details.

I forgot a few ones.

Starting with woody, and because of the defects of Debian stable, I
started backporting packages myself. Very often, you can compile a
newer version of a package, still using the old libraries in Debian
stable. The problem is, doing so has become increasingly painful
over time, because for some reason, most Debian testing/unstable
package control files ask for the version of libraries part of
testing/unstable even though they do not require it. So, in order to
try and compile a package, the workflow becomes, download the
package, change its control file to try and compile with stable
versions, if that fails, restore the library dependencies, download
and install the new version of the library, and try compiling the
package again. With the obvious recursive nature of this process,
this makes things really really uselessly painful, and not unlike
playing the game of mikado. If the version required by a control
file indicated the real version needed by a package, you would not
have two steps by package, and things would be straightforward.

There is a paradox in the way in which packages are split and depend
on each other. On the one hand, the painful way a package, the -dev
package and the -doc package are split would seem to indicate that
the goal of Debian is to allow you to have a rootfs where you have
great control over its contents. On the other hand, the usual way a
package is compiled is with every possible options on, creating a
lot of dependencies you could avoid, and resulting in exactly the
contrary of the previous feature: you installing lots of files in
your rootfs you would not need. So, you have the inconveniences of a
fine grained control without the advantages.

Also, the Debian wiki contents are not of very good quality. Compare
them for examples with the Archlinux distribution wiki.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Henning Schild]

On Thu, 28 May 2015 01:51:31 +0200
Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:

> > Just to inform, because i have been in silence all this thread that
> > some weeks ago (maybe two month) I contacted with the debian
> > maintainer of xenomai. I offered my help because I was interested
> > in maintain the package. We finally will work together, and the
> > debian directory will be hosted in collab-maint git, in alioth, a
> > git server of debian.
> > 
> > Said that, because time constraints of the last weeks, I'm just in
> > the beginning of review all the packaging of xenomai. I will begin
> > with 2.6.4 and after that, I will jump to 3.0 when you released an
> > official one. So, don't try to find anything there, because I have
> > nothing done. I will try to inform the list about my progress.
> > 
> > Anyway, the idea is to drop your debian directory and put a new
> > one, trying to use the "good practices" and the updated debhelper
> > tools. I will try to keep the package in a good shape, sync with
> > the upstream last versions, at least in unstable. If I could, some
> > backport (because I used it) could be possible.
> 
> So, you want to reiterate the previous maintainer mistakes, and
> continue to maintain the Xenomai Debian packaging outside of the
> Xenomai project. See my last point for why this is a bad idea.
> Please, come maintaining Xenomai debian directory, allowing us to
> review your work and discuss the patches proposed by Debian users.
> If you want to make a new release because of a correction in the
> Debian directory, we can arrange something I am sure with a
> maintenance branch, or a git tag.

It should stay in the tree, especially when using it against git and
not releases. So additional to the already mentioned problems we would
have to match two repos with submodules or whatever. Send patches to
two communities .. no thanks.
Several people said that they use it and want to keep it. And Leopold
offered to maintain it. I hope that offer stands also if the directory
stays in the xenomai tree. If so i think the problem is solved and we
can all continue this thread with a nice distro war ;).

Henning 

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Leopold Palomo-Avellaneda]

El Dijous, 28 de maig de 2015, a les 01:51:31, Gilles Chanteperdrix va 
escriure:
[...]

dropped all your complains to debian. I must read and answer more careful and 
I don't know if the xenomai list is the proper audience.
 
 
> > > Just to add something more to the subject: I do not think being the
> > > debian maintainer of the Xenomai package is a hard task. I mean come
> > > on, it is just basically a Makefile shorter than some other
> > > Makefiles in the project. But this requires staying in touch with
> > > the Debian project to know what the "good practices" are, what
> > > practices have become deprecated and what new debian helper could
> > > make the packaging even simpler, things I do not care to do. In any
> > > case, this should be a good reason not to botch the task. A botched
> > > hard task is easier to understand than a botched easy task.
> > 
> > Just to inform, because i have been in silence all this thread that some
> > weeks ago (maybe two month) I contacted with the debian maintainer of
> > xenomai. I offered my help because I was interested in maintain the
> > package. We finally will work together, and the debian directory will be
> > hosted in collab-maint git, in alioth, a git server of debian.
> > 
> > Said that, because time constraints of the last weeks, I'm just in the
> > beginning of review all the packaging of xenomai. I will begin with 2.6.4
> > and after that, I will jump to 3.0 when you released an official one. So,
> > don't try to find anything there, because I have nothing done. I will try
> > to inform the list about my progress.
> > 
> > Anyway, the idea is to drop your debian directory and put a new one,
> > trying to use the "good practices" and the updated debhelper tools. I
> > will try to keep the package in a good shape, sync with the upstream last
> > versions, at least in unstable. If I could, some backport (because I used
> > it) could be possible.
> So, you want to reiterate the previous maintainer mistakes, and
> continue to maintain the Xenomai Debian packaging outside of the
> Xenomai project. See my last point for why this is a bad idea.

It's your opinion. I don't agree with you. Anyway, let me begin, try to find 
some kind of confluence that fits debian requirements and upstream 
requirements. Please, try to begin from zero, the past is in the past (Queen 
Elsa dixit :-))

> Please, come maintaining Xenomai debian directory, allowing us to
> review your work and discuss the patches proposed by Debian users.
> If you want to make a new release because of a correction in the
> Debian directory, we can arrange something I am sure with a
> maintenance branch, or a git tag.

Sure, we will find a solution. I'm a bit overflow these days. Let me try to 
work on xenomai packaging soon and we can discuss the rest.

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/20150528/710a3540/attachment.sig>

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, May 28, 2015 at 03:09:26PM +0200, Leopold Palomo-Avellaneda wrote:
> El Dijous, 28 de maig de 2015, a les 01:51:31, Gilles Chanteperdrix va 
> escriure:
> [...]
> 
> dropped all your complains to debian. I must read and answer more careful and 
> I don't know if the xenomai list is the proper audience.
>  
>  
> > > > Just to add something more to the subject: I do not think being the
> > > > debian maintainer of the Xenomai package is a hard task. I mean come
> > > > on, it is just basically a Makefile shorter than some other
> > > > Makefiles in the project. But this requires staying in touch with
> > > > the Debian project to know what the "good practices" are, what
> > > > practices have become deprecated and what new debian helper could
> > > > make the packaging even simpler, things I do not care to do. In any
> > > > case, this should be a good reason not to botch the task. A botched
> > > > hard task is easier to understand than a botched easy task.
> > > 
> > > Just to inform, because i have been in silence all this thread that some
> > > weeks ago (maybe two month) I contacted with the debian maintainer of
> > > xenomai. I offered my help because I was interested in maintain the
> > > package. We finally will work together, and the debian directory will be
> > > hosted in collab-maint git, in alioth, a git server of debian.
> > > 
> > > Said that, because time constraints of the last weeks, I'm just in the
> > > beginning of review all the packaging of xenomai. I will begin with 2.6.4
> > > and after that, I will jump to 3.0 when you released an official one. So,
> > > don't try to find anything there, because I have nothing done. I will try
> > > to inform the list about my progress.
> > > 
> > > Anyway, the idea is to drop your debian directory and put a new one,
> > > trying to use the "good practices" and the updated debhelper tools. I
> > > will try to keep the package in a good shape, sync with the upstream last
> > > versions, at least in unstable. If I could, some backport (because I used
> > > it) could be possible.
> > So, you want to reiterate the previous maintainer mistakes, and
> > continue to maintain the Xenomai Debian packaging outside of the
> > Xenomai project. See my last point for why this is a bad idea.
> 
> It's your opinion. I don't agree with you. Anyway, let me begin, try to find 
> some kind of confluence that fits debian requirements and upstream 
> requirements. Please, try to begin from zero, the past is in the past (Queen 
> Elsa dixit :-))

My opinion is backed by concrete evidence. You just have to look at
the current contents of the Debian project debian/rules for Xenomai
project that install hook for the kernel-package package that have
stopped working for something like 5 debian releases, that to do so
uses the "prepare-patch.sh" script which has been a pain to maintain
and has thus becomes useless for 5 debian releases, that passes
option to the configure script which have been removed for many
releases and cause configure to emit a warning. And at the accepted
patches sent by users (notably the one that "fixes" powerpc SPE) to
see that keeping it out of sight of the upstream project was a bad
idea. Really.

-- 
					    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/20150528/85229005/attachment.sig>

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Lennart Sorensen]

On Thu, May 28, 2015 at 01:51:31AM +0200, Gilles Chanteperdrix wrote:
> I warn you, it is like when you have been knowing someone a very
> long time, you have tendency to find unbearable, some defaults that
> would seem very small to people with a shorter contact.
> 
> Anyway, my recriminations against Debian are:
> - the lib/dev/doc package split is really a major PITA when you are
> spending your time writing or compiling code built upon third party
> libraries;

Sure but it saves a lot of disk space and download time for those that
don't need it.

> - the removal of FSF info documentation is a major PITA for the
> workstation of a developer that was used to it;

Is that the stuff due to the non-free FSF documentation license?

> - Debian strives at being simple for the user, but to do so
> implements a lot of distribution-specific software, that has a
> complex design, requires you to learn how it works, and sometime
> even to debug it, because well, complex software inevitably contain
> bugs; I prefer a distribution that may be a little less easy to use,
> but based on tools with a simple design.

I didn't think that was the goal.

> - Debian is supposedly about freedom, but refuses access to its wiki
> to us unlucky people living in countries with state required
> surveillance policies by ISPs and/or censorship by internet servers
> blacklisting who consequently have to use off-shore VPNs to preserve
> their freedom;

I had not heard of that before.

> - the quality of software shipped by Debian depends on the work of
> its maintainer more than on the quality of the upstream package,
> because many Debian packages are patched to the teeth, resulting in:
> . security issues
> . packages with reworked organisation of the configuration, which is
> thus not the same as the documented upstream one;

If some upstreams didn't do such a shitty job they wouldn't have to.

> . linux kernels that oops and that require you to reboot your
> machine from time to time.

OK, never had this happen that I can recall.

> . poor packages quality when they are used by very little number of
> users, because well, no users tests them, and apparently neither the
> maintainer, including in the so-called "Debian stable" distribution

That is a problem in just about any distribution and often even in the
upstream code in that case.

> - Debian stable benefits from the best debugging cycle, so is the
> Debian distribution of choice, except that not all packages are
> debugged equally (see last point), so it is not that stable, but
> there is one thing for sure, the packages versions in Debian stable
> are outdated. This is mostly a problem for desktop software. I do
> not care about running an outdated apache on a server, so long as
> the security team provides security updates, I sure as hell care
> about the version of xorg, libva, mesa, libqt, firefox, ffmpeg, vlc
> or libreoffice I am using though. And no, debian backports and
> deb-multimedia do not contain all the packages I would like, and I
> do not want to use Debian testing or Debian unstable, because I have
> experience of doing so and having the repository containing broken
> packages occasionally, and remaining so for some time, which is too
> bad if you need the said package.

Well good testing and up to date software are pretty much mutually
exclusive.  Mint-DE tries.

> - since we are at it, the way Christian Marillat, the maintainer of
> the repository formerly called "Debian multimedia" was treated;

That could probably have been handled better.

> - the KDE desktop environment does not work so great in Debian, I do
> not know to which of the previous point this is due (not many users,
> too old versions, buggy patches, or maybe all combined, or maybe
> another reason). Unfortunately, this is the desktop I want to use.
> 
> - the systemd debacle

That was probably the biggest mess I have ever seen in Debian.

> - correct me if I am wrong, but a Debian maintainer is not required
> to contact upstream when he applies a patch, this results in Debian
> packages including patches that would never have been accepted
> upstream, and which degrade the package quality. Since a Debian
> maintainer also has his own bug tracking system, he can make things
> things up "behind upstream's back", cutting himself from the review
> of the upstream package, and cutting Debian users from the upstream
> package maintainers. This point happened to Xenomai Debian package.
> What is more, (again, correctly if I am wrong) a Debian maintainer
> is not exactly required to be a developer, so when a Debian user
> sends a patch that supposedly "fixes something", the patch may be
> utter crap and the maintainer not be able to judge, if he decides to
> work in isolation from upstream, the down goes again the package
> quality.

Not required to, but usually does submit upstream.  Of course there are
also cases of upstream being impossible to work with, or in some cases
no longer exists.  There are packages for which Debian has become the
defacto maintainer because the upstream is no longer there.

> I will not provide detailed bug reports, because, well, as I said, I
> no longer care about Debian. Maybe you will find this is FUD, and an
> easy escape. But you asked for it, and again, I do not care. I am
> certainly not going to boot a Debian again, just to give you precise
> details.

I think you have many very valid points.  I am sticking with Debian
because I find it works quite well, and I have not seen any distribution
that is better.

> So, you want to reiterate the previous maintainer mistakes, and
> continue to maintain the Xenomai Debian packaging outside of the
> Xenomai project. See my last point for why this is a bad idea.
> Please, come maintaining Xenomai debian directory, allowing us to
> review your work and discuss the patches proposed by Debian users.
> If you want to make a new release because of a correction in the
> Debian directory, we can arrange something I am sure with a
> maintenance branch, or a git tag.

Putting the package into Debian does not really make sense, because the
kernel in Debian is not xenomai enabled, and the xenomai patch rarely
applies to Debian's kernel source.

Using xenomai pretty much requires a custom kernel.  Using Debian packages
for the rest of the system, and hence being able to build the xenomai
libraries and such as debian packages is very handy.

So I very much like the debian directory in xenomai as it is (although
perhaps I should look into modernizing it and simplifying it if there
is any need for that), but to actually bother putting it into Debian
officially I see no value in.  It did not work very well before.

-- 
Len Sorensen

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, May 28, 2015 at 11:58:04AM -0400, Lennart Sorensen wrote:
> On Thu, May 28, 2015 at 01:51:31AM +0200, Gilles Chanteperdrix wrote:
> > I warn you, it is like when you have been knowing someone a very
> > long time, you have tendency to find unbearable, some defaults that
> > would seem very small to people with a shorter contact.
> > 
> > Anyway, my recriminations against Debian are:
> > - the lib/dev/doc package split is really a major PITA when you are
> > spending your time writing or compiling code built upon third party
> > libraries;
> 
> Sure but it saves a lot of disk space and download time for those that
> don't need it.

As I said in the next mail, this is ridiculous. First a few headers
and a .pc file do not occupy that much room, I mean come on, people
have tera bytes disks now, and what does a Debian occupy with all
the packages installed 100 GiB ? And second the Debian system is
spending way much more space elsewhere with its package with all
options enabled that get a lot of stuff installed on your system
that you actually do not need. Look at libav dependencies for
instance. libav can be configured to have no external dependencies
and this is generally sufficient for common use like watching
videos. In addition to that, there are packages that you do not need
or want, that will cause apt to uninstall half the distribution if
you remove them, so, you have to keep them, and they are more than
just a few headers and a .pc file.

> 
> > - the removal of FSF info documentation is a major PITA for the
> > workstation of a developer that was used to it;
> 
> Is that the stuff due to the non-free FSF documentation license?

"non-free Free Software Foundation documentation" sounds like a
cheap oxymoron does not it? And does not Debian have a directory
named "non-free" in its repository for this case? From a user-space
experience point of view, this was a frustrating change. That and
the gratuitous move of /usr/doc to /usr/share/doc, but that was a
long time ago.

> > - Debian is supposedly about freedom, but refuses access to its wiki
> > to us unlucky people living in countries with state required
> > surveillance policies by ISPs and/or censorship by internet servers
> > blacklisting who consequently have to use off-shore VPNs to preserve
> > their freedom;
> 
> I had not heard of that before.

Well, I do not seem to have the problem right now, otherwise I would
have sent a screenshot. But I assure you I had it at some point.
Maybe it depends on some static IP range. But the error message made
it clear that your access was denied because you were using an
anonymous VPN service. Maybe the problem was fixed in the mean time.


> 
> > - the quality of software shipped by Debian depends on the work of
> > its maintainer more than on the quality of the upstream package,
> > because many Debian packages are patched to the teeth, resulting in:
> > . security issues
> > . packages with reworked organisation of the configuration, which is
> > thus not the same as the documented upstream one;
> 
> If some upstreams didn't do such a shitty job they wouldn't have to.

I do not find that the Apache httpd project does "a shitty job", but
I find the Debian apache configuration system over-engineered with
its specialized helpers, yet weak on the point of implicit
configuration file order, so shitty in a way. And requires to
acquire knowledge about the package not available in the upstream
documentation.

> 
> > . linux kernels that oops and that require you to reboot your
> > machine from time to time.
> 
> OK, never had this happen that I can recall.

My desktop runs 24/7, maybe that is the reason.

> 
> > . poor packages quality when they are used by very little number of
> > users, because well, no users tests them, and apparently neither the
> > maintainer, including in the so-called "Debian stable" distribution
> 
> That is a problem in just about any distribution and 

I currently use Slackware, and the Slackware base system only
contains very few packages (a Slackware with all packages installed,
yes, this includes the library headers and documentation, occupies 8
GiB of disk space), and I guess none that few people use. The
distribution does not make promises it can't keep.

> often even in the upstream code in that case.

>From my point of view, a Debian package maintainer is responsible
for the Debian package quality. So, if he can not reach that quality
because the upstream code does not have a high enough quality, he
should not package it. Packaging low quality software without fixing
the quality issue is a bad service to the user. Again, a frustrating
experience from the end-user point of view.

> 
> > - Debian stable benefits from the best debugging cycle, so is the
> > Debian distribution of choice, except that not all packages are
> > debugged equally (see last point), so it is not that stable, but
> > there is one thing for sure, the packages versions in Debian stable
> > are outdated. This is mostly a problem for desktop software. I do
> > not care about running an outdated apache on a server, so long as
> > the security team provides security updates, I sure as hell care
> > about the version of xorg, libva, mesa, libqt, firefox, ffmpeg, vlc
> > or libreoffice I am using though. And no, debian backports and
> > deb-multimedia do not contain all the packages I would like, and I
> > do not want to use Debian testing or Debian unstable, because I have
> > experience of doing so and having the repository containing broken
> > packages occasionally, and remaining so for some time, which is too
> > bad if you need the said package.
> 
> Well good testing and up to date software are pretty much mutually
> exclusive.  Mint-DE tries.

For some software (mostly server/infrastructure software) a good
testing matters. And for some other (mostly desktop software and
developer tools like the autotools, toolchain and debugger I forgot
to mention), having the latest version is imperative. By using
debian testing/unstable you give up on the first. By using debian
stable, you give up on the second. The only solution on Debian is to
compile testing packages on stable, but as I explained, even this
only available solution is made uselessly difficult by the control
files requiring newer versions of the libraries that they do not
actually strictly need. Compiling packages yourself is much easier
on other distributions.

> 
> > - since we are at it, the way Christian Marillat, the maintainer of
> > the repository formerly called "Debian multimedia" was treated;
> 
> That could probably have been handled better.
> 
> > - the KDE desktop environment does not work so great in Debian, I do
> > not know to which of the previous point this is due (not many users,
> > too old versions, buggy patches, or maybe all combined, or maybe
> > another reason). Unfortunately, this is the desktop I want to use.
> > 
> > - the systemd debacle
> 
> That was probably the biggest mess I have ever seen in Debian.

I was rather referring to the conclusion of the mess.

> 
> > - correct me if I am wrong, but a Debian maintainer is not required
> > to contact upstream when he applies a patch, this results in Debian
> > packages including patches that would never have been accepted
> > upstream, and which degrade the package quality. Since a Debian
> > maintainer also has his own bug tracking system, he can make things
> > things up "behind upstream's back", cutting himself from the review
> > of the upstream package, and cutting Debian users from the upstream
> > package maintainers. This point happened to Xenomai Debian package.
> > What is more, (again, correctly if I am wrong) a Debian maintainer
> > is not exactly required to be a developer, so when a Debian user
> > sends a patch that supposedly "fixes something", the patch may be
> > utter crap and the maintainer not be able to judge, if he decides to
> > work in isolation from upstream, the down goes again the package
> > quality.
> 
> Not required to, but usually does submit upstream.  Of course there are
> also cases of upstream being impossible to work with, or in some cases
> no longer exists.  There are packages for which Debian has become the
> defacto maintainer because the upstream is no longer there.

I do not think Xenomai was in either of these cases.

> 
> > I will not provide detailed bug reports, because, well, as I said, I
> > no longer care about Debian. Maybe you will find this is FUD, and an
> > easy escape. But you asked for it, and again, I do not care. I am
> > certainly not going to boot a Debian again, just to give you precise
> > details.
> 
> I think you have many very valid points.  I am sticking with Debian
> because I find it works quite well, and I have not seen any distribution
> that is better.

I thought it worked well, and believed like you that problems came
from upstream packages, until I tried another one and found out it
worked better, so, the Debian problems definitely not all come from
the upstream packages.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, May 28, 2015 at 11:58:04AM -0400, Lennart Sorensen wrote:
> > - Debian is supposedly about freedom, but refuses access to its wiki
> > to us unlucky people living in countries with state required
> > surveillance policies by ISPs and/or censorship by internet servers
> > blacklisting who consequently have to use off-shore VPNs to preserve
> > their freedom;
> 
> I had not heard of that before.

https://lists.debian.org/debian-user/2014/03/msg00823.html

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Thu, May 28, 2015 at 07:32:26PM +0200, Gilles Chanteperdrix wrote:
> On Thu, May 28, 2015 at 11:58:04AM -0400, Lennart Sorensen wrote:
> > That is a problem in just about any distribution and 
> 
> I currently use Slackware, and the Slackware base system only
> contains very few packages (a Slackware with all packages installed,
> yes, this includes the library headers and documentation, occupies 8
> GiB of disk space), and I guess none that few people use. The
> distribution does not make promises it can't keep.

Not "very few pacakges". But less than Debian.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Lennart Sorensen]

On Thu, May 28, 2015 at 07:32:26PM +0200, Gilles Chanteperdrix wrote:
> As I said in the next mail, this is ridiculous. First a few headers
> and a .pc file do not occupy that much room, I mean come on, people
> have tera bytes disks now, and what does a Debian occupy with all
> the packages installed 100 GiB ? And second the Debian system is
> spending way much more space elsewhere with its package with all
> options enabled that get a lot of stuff installed on your system
> that you actually do not need. Look at libav dependencies for
> instance. libav can be configured to have no external dependencies
> and this is generally sufficient for common use like watching
> videos. In addition to that, there are packages that you do not need
> or want, that will cause apt to uninstall half the distribution if
> you remove them, so, you have to keep them, and they are more than
> just a few headers and a .pc file.

We ship Debian on systems with 512MB of flash.  Not everything is a
desktop or a server.  We like how Debian splits things, it is very
convinient.

> "non-free Free Software Foundation documentation" sounds like a
> cheap oxymoron does not it? And does not Debian have a directory
> named "non-free" in its repository for this case? From a user-space
> experience point of view, this was a frustrating change. That and
> the gratuitous move of /usr/doc to /usr/share/doc, but that was a
> long time ago.

That was a long time ago.  And the FSF making such a blunder is odd,
but they did it, not Debian.

> Well, I do not seem to have the problem right now, otherwise I would
> have sent a screenshot. But I assure you I had it at some point.
> Maybe it depends on some static IP range. But the error message made
> it clear that your access was denied because you were using an
> anonymous VPN service. Maybe the problem was fixed in the mean time.

I wonder if they came up with a better way to prevent spammers messing
with the wiki.

> I do not find that the Apache httpd project does "a shitty job", but
> I find the Debian apache configuration system over-engineered with
> its specialized helpers, yet weak on the point of implicit
> configuration file order, so shitty in a way. And requires to
> acquire knowledge about the package not available in the upstream
> documentation.

I think both the apache way and the Debian way are a mess. :)

> My desktop runs 24/7, maybe that is the reason.

Mine do too.

> I currently use Slackware, and the Slackware base system only
> contains very few packages (a Slackware with all packages installed,
> yes, this includes the library headers and documentation, occupies 8
> GiB of disk space), and I guess none that few people use. The
> distribution does not make promises it can't keep.

I can't possible go back to that shitty "packaging" system (if you can
even call it that)..  No way.  I went from there to redhat which was a
huge improvement, and then to Debian which was another huge improvement.

And last I checked it looked like slackware had been dead for a couple
of years, which would make it even more stale than Debian stable.

> > often even in the upstream code in that case.
> 
> From my point of view, a Debian package maintainer is responsible
> for the Debian package quality. So, if he can not reach that quality
> because the upstream code does not have a high enough quality, he
> should not package it. Packaging low quality software without fixing
> the quality issue is a bad service to the user. Again, a frustrating
> experience from the end-user point of view.

Well if people want the code even in the state it is in, it can be
packaged.  Perhaps Ubuntu's concept of having core packages, and then
optional repositories of lower quality software makes sense there.

> For some software (mostly server/infrastructure software) a good
> testing matters. And for some other (mostly desktop software and
> developer tools like the autotools, toolchain and debugger I forgot
> to mention), having the latest version is imperative. By using
> debian testing/unstable you give up on the first. By using debian
> stable, you give up on the second. The only solution on Debian is to
> compile testing packages on stable, but as I explained, even this
> only available solution is made uselessly difficult by the control
> files requiring newer versions of the libraries that they do not
> actually strictly need. Compiling packages yourself is much easier
> on other distributions.

That's a matter of ones preference.  I find building debian packages
fairly simply.  Redhat is complicated.  Some distributions I guess you
just build from source and throw it in and it's your problem to get the
things that work together right.  Some consider that easier.

> I was rather referring to the conclusion of the mess.

The conclussion and the entire progress towards it.  I am not convinced
it is even over yet.

> > Not required to, but usually does submit upstream.  Of course there are
> > also cases of upstream being impossible to work with, or in some cases
> > no longer exists.  There are packages for which Debian has become the
> > defacto maintainer because the upstream is no longer there.
> 
> I do not think Xenomai was in either of these cases.

I entirely agree. :)

> I thought it worked well, and believed like you that problems came
> from upstream packages, until I tried another one and found out it
> worked better, so, the Debian problems definitely not all come from
> the upstream packages.

Well I know slackware, and I can't think of anything it does well,
so unless you have some other distribution suggestions to look at,
I am stuck with Debian.  Oh well.

-- 
Len Sorensen

Re: [Xenomai] [PATCH] debian: remove xeno-config from libxenomai-dev package

[Gilles Chanteperdrix]

On Fri, May 29, 2015 at 04:16:18PM -0400, Lennart Sorensen wrote:
> On Thu, May 28, 2015 at 07:32:26PM +0200, Gilles Chanteperdrix wrote:
> > As I said in the next mail, this is ridiculous. First a few headers
> > and a .pc file do not occupy that much room, I mean come on, people
> > have tera bytes disks now, and what does a Debian occupy with all
> > the packages installed 100 GiB ? And second the Debian system is
> > spending way much more space elsewhere with its package with all
> > options enabled that get a lot of stuff installed on your system
> > that you actually do not need. Look at libav dependencies for
> > instance. libav can be configured to have no external dependencies
> > and this is generally sufficient for common use like watching
> > videos. In addition to that, there are packages that you do not need
> > or want, that will cause apt to uninstall half the distribution if
> > you remove them, so, you have to keep them, and they are more than
> > just a few headers and a .pc file.
> 
> We ship Debian on systems with 512MB of flash.  Not everything is a
> desktop or a server.  We like how Debian splits things, it is very
> convinient.

Once again, a few headers files is not going a problem. And I have
run root filesystems on 6MB flashes, Debian can not do that. So,
obviously, Debian pretends to do something that it can not do
completely. However, on a developer desktop, this makes things
uselessly painful. I run my distribution on a desktop, I do not care
what it does for other configurations. And on other configurations I
certainly would not use this distribution either, because of its
tendency to embark things on the filesystem I do not need and make
them unavoidable through false dependencies. So, I maintain this
over splitting of packages is ridiculous. The Linux foundation chose
yocto as the embedded distribution, not Debian.

> 
> > "non-free Free Software Foundation documentation" sounds like a
> > cheap oxymoron does not it? And does not Debian have a directory
> > named "non-free" in its repository for this case? From a user-space
> > experience point of view, this was a frustrating change. That and
> > the gratuitous move of /usr/doc to /usr/share/doc, but that was a
> > long time ago.
> 
> That was a long time ago.  And the FSF making such a blunder is odd,
> but they did it, not Debian.

The point remains: Debian had a non-free directory to move the
packages to.

> 
> > Well, I do not seem to have the problem right now, otherwise I would
> > have sent a screenshot. But I assure you I had it at some point.
> > Maybe it depends on some static IP range. But the error message made
> > it clear that your access was denied because you were using an
> > anonymous VPN service. Maybe the problem was fixed in the mean time.
> 
> I wonder if they came up with a better way to prevent spammers messing
> with the wiki.

The Xenomai project had a wiki some time ago, and had spamming
issues too. We never resorted to something as stupid as blocking IP
address ranges to avoid spam.

> And last I checked it looked like slackware had been dead for a couple
> of years, which would make it even more stale than Debian stable.

Debian stable is also not released often (that is a euphemism). 
I can give details on that. I installed Slackware 14.1, which had
more recent packages than Debian wheezy (this was before the jessie
release, obviously). And Slackware has a repository where volunteers
package upstream packages themselves and provide the build script,
and: 
- the versions of these packages are current, and if they are not,
trying a more recent version is easy enough; 
- the packages are the verbatim upstream packages, with much less 
patches than the Debian distribution; 
- if such package configure script has some
optional dependencies, you can usually choose whether you compile
the package to use that dependency, and if you can't, again,
modifying the build script is easy enough.

> 
> > > often even in the upstream code in that case.
> > 
> > From my point of view, a Debian package maintainer is responsible
> > for the Debian package quality. So, if he can not reach that quality
> > because the upstream code does not have a high enough quality, he
> > should not package it. Packaging low quality software without fixing
> > the quality issue is a bad service to the user. Again, a frustrating
> > experience from the end-user point of view.
> 
> Well if people want the code even in the state it is in, it can be
> packaged.  Perhaps Ubuntu's concept of having core packages, and then
> optional repositories of lower quality software makes sense there.

My two finals candidates, Slackware and archlinux do that too. That
is way more honest than calling a distribution "Debian stable" and
have it contain buggy packages.

> 
> > For some software (mostly server/infrastructure software) a good
> > testing matters. And for some other (mostly desktop software and
> > developer tools like the autotools, toolchain and debugger I forgot
> > to mention), having the latest version is imperative. By using
> > debian testing/unstable you give up on the first. By using debian
> > stable, you give up on the second. The only solution on Debian is to
> > compile testing packages on stable, but as I explained, even this
> > only available solution is made uselessly difficult by the control
> > files requiring newer versions of the libraries that they do not
> > actually strictly need. Compiling packages yourself is much easier
> > on other distributions.
> 
> That's a matter of ones preference.  I find building debian packages
> fairly simply.  Redhat is complicated.  Some distributions I guess you
> just build from source and throw it in and it's your problem to get the
> things that work together right.  Some consider that easier.

Once again, no. Compiling a Debian testing package on Debian stable
is made stupidly painful by the fact that the average Debian testing
package control file requires the Debian testing versions of the
libraries it uses whereas in fact, it could very well compile with
the Debian stable versions. The result is that if you want to
compile the Debian testing version on a Debian stable, you end up
uselessly upgrading a lot of stable packages with testing ones, or
spending a lot of time compiling and recompiling a package to try
whether it could work with the Debian stable libraries.

> 
> > I was rather referring to the conclusion of the mess.
> 
> The conclussion and the entire progress towards it.  I am not convinced
> it is even over yet.

In a few years from now, not using systemd on Debian will be
impossible, because the classical init scripts will not have been
tested (lots of users who want classical init systems have fled
Debian anyway, there is even a Debian fork without systemd, Devuan
?) and will have become rotten. I guess someone else probably said
that during the debate, so, it is pointless to even mention it.

> 
> > > Not required to, but usually does submit upstream.  Of course there are
> > > also cases of upstream being impossible to work with, or in some cases
> > > no longer exists.  There are packages for which Debian has become the
> > > defacto maintainer because the upstream is no longer there.
> > 
> > I do not think Xenomai was in either of these cases.
> 
> I entirely agree. :)

That is not exactly true, my relations with the Debian maintainer
have been bad from the early start. But that is because very early
on, he started applying crappy patches behind our back.

> 
> > I thought it worked well, and believed like you that problems came
> > from upstream packages, until I tried another one and found out it
> > worked better, so, the Debian problems definitely not all come from
> > the upstream packages.
> 
> Well I know slackware, and I can't think of anything it does well,
> so unless you have some other distribution suggestions to look at,
> I am stuck with Debian.  Oh well.

I guess it is a matter of preferences, so it is probably better not
to continue discussing. But what I find Slackware does well is that:
- it does not flood you with tons of distribution specific helpers,
there are a handful of such helpers on slackware, it has a
definitely simple design;
- it patches much less the upstream packages
- it has the split between a base of not-so-current stable system
base, with the possibility to install recent packages on top that is
ideal for me
- I find the slackbuilds, which are basically shell scripts, using
one unique helper, easier to work with than the Debian equivalent, the
debian/rules
- once done installing it, and doing the basic configuration, it 
just works, and works well, especially KDE.

The other distribution I considered is archlinux, I have tried it a
bit on windows with the "msys2" system, and their wiki is really
great. The reason I did not go that way is that systemd is the
official init system of archlinux.

-- 
					    Gilles.