[GNU-linux-libre] Re: any Free BSD variant?

[Yavor Doganov]

JFTR, when I say "gNS" I really mean "gNewSense", it's just an
(already established?) abbreviation.  My effort that I described
briefly does not have a name, except the working name "jungle" which
clearly suggests it's something unofficial and not ready for those who
don't have a clue what a jungle is, and what are the possible
consequences of having a trip there.

Karl Goetz wrote:
> Some of Debians problem there is promoting itself as a completely free
> software distro (like a popular derivative starting with U). If that
> wasn't the case, people would be less upset when it isn't completely
> free.

Yes, this is something that has annoyed me most.  They are loudly
trumpeteering about freedom, while the actions do not match the words.

> A PPAs are not part of the official Ubuntu repos, and don't
> facilitate the packages reaching the archive any easier then a
> standard dput (that I'm aware of).

Right, that's why I dislike this approach (dupload user here, but this
doesn't matter).

> > Although very slowly, interested developers/users will find their
> > way through.

> The distinction exists, but is not solid - people can move between
> groups.

Sure.  Everyone is free to do this, and people can choose to support a
particular package for more than one distro, in different ways.

(Another drastic example is that any GNU maintainer can upload his own
non-free software program almost anywhere, but _not_ at ftp.gnu.org or
Savannah.  For Savannah hosting she has to fulfil the Savannah
requirements, and for official GNU software the package has to be
dubbed as such, which presumably also means the maintainer has to
follow standards.texi and maintain.texi.)

> With some hacking should work on G3/4/5.

One G3 here and and older one (Performa series).  Will give it a try
as soon as I manage to settle out the hardware problems.  Thanks for
working on this port.

> (PPC isn't well loved these days sadly).

Sad, but true.

> TRT?

TRT == The Right Thing
DTRT == Do The Right Thing

> > OTOH, keeping the basic system as stable as possible is very
> > important.
> 
> Do you mean 'stable' as in 'low churn' or 'wont crash'? something else?

By stable I mean like Debian stable.  Surely there are bugs there too,
but not so much as in an LTS produced for 6 months.

What I really meant in this paragraph is that great care should be
taken in the effort that I described not to introduce regressions.
For example, it's completely out of the question to upload GCC 4.4 or
newest binutils even if there is an absolutely capable maintainer (not
me, of course).  Lots of existing packages will become insta-buggy,
and many things will break badly.

> Or (and this is what I hope) - there's a number of people happily
> running gNS who dont feel the need to complain about it as it is. That
> would be nice!

Of course!  I am sorry if you feel offended, this was not the
intention at all and you bear zero responsibility for my
disappointments anyway.

Perhaps my requirements are higher.  I come from the Debian land,
where I'm used to a certain extent of stability, especially in stable
releases.

> Apart from anything else the 'community repo' will be a place for
> testing ideas before inflicting it on the main distro. At the moment we
> don't have a testing branch, so we don't have the luxury of breaking
> stuff there.

This sounds good.  Have you considered the idea of using exactly
Debian's scheme, e.g.

Debian testing -> gNS analogue of sid -> gNS analogue of testing with
migration scripts and freezes -> gNS stable?

That's my idea about the release process.  gNS sid will be syncs from
Debian testing + uploads of gNS developers, and the same migration
rules/periods for (gNS) sid->testing could apply.

> > if more knowledgeable people than me comment on the sketch, and point
> > out evident weaknesses right away.
> 
> I suspect I'm not one of those people

Of course you are, and thanks for the comments.

> Outside of {P,K}FV I can count the recent gNS (code) contributors on
> my thumbs, and those making other useful contributions for > 30 days
> on one hand.

Yes, I don't expect contributors coming in droves, no matter what
happens and what direction for further development is taken.

> I disagree that trying to work with other distributions is
> impossible.

I did not say this.  I said it is impossible to change Debian in the
way that we want it to change, that is, in a way that would make a
distro like gNS completely unnecessary, so we could all roll up our
sleeves and contribute to Debian without the moral dillema I'm
personally facing every time.

> This is *not* going to happen to gNS in the near future.

That's understandable and IMHO the right decision given the current
circumstances.

>  http://www.gnewsense-unofficial.org/

Nice, I was not aware of this.

> - finish setting up simple buildd to get things rolling

Another tangential point: Debian does not support source uploads,
while Ubuntu do not to binary uploads.  In Debian, sometimes bugs are
introduced because the maintainer uploaded a package not built in a
clean environment, while in Ubuntu the fact that the builds are
performed by the autobuilders encourages them to make only source
changes and upload without testing.

I think a proper behavior would be: The archive software should
require .debs to be present, but they have to be thrown away and the
package should get rebuilt afresh by all the buildds.

> Robert has taken care of a large part of the work to build gNS on
> Debian

Yes, kudos for the great work!

> Its harder to maintain it all from scratch. 

Not all.  What we can manage, as a beginning.  Step by step, milestone
by milestone.  Much like the initial (and current) plan for GNU.

> > 2+ years old attempt to maintain some packages for gNS at
> > http://gns.katsarov.org [1].
> 
> Are these packages site specific, or generic?

Not sure what you mean by "site specific"?  These packages should (in
theory) install and work well on a gNewSense DeltaH system.

> > The long term solution, in my view, is to develop an absolutely free
> > distro from scratch, of course basing it off (initially at least, and
> > probably forever for the packaging-specific toolchain) an existing
> > one.
> 
> No small task.

Undoubtedly.  

> > They just don't listen to us, and there's no way to change that.)
> 
> I don't feel 'they just don't listen to us' is an accurate reading of
> the situation. Many of them do listen, but will wait for a patch to fix
> <the problem>. 

Hmm.  The non-free kernel issue is being "solved" by using
`request_firmware' and providing the non-free stuff in the non-free
archive.  Even d-i was modified to use that by default.  That's not a
solution, in my view, and not something that I'd treat as "properly
patched" or dealth with.

>  1 week before release 2 bits of non-free firmware are found in the
> kernel. Would you delay release? remove them in an update ASAP after
> release (to allow testing)? something else?

Yes, I would delay the release because all of this is relevantly
easily and quickly fixable, as demonstrated by the work Brian Brazil
has done for gNS and later Jeff Moe/Alexandre Oliva while maintaining
linux-libre.  These are easily fixable bugs by just removing that
stuff.  AFAIK, linux-libre even don't go that far, as some stuff works
without the firmware in certain situations.

Now, if something like OpenGL is discovered, a delay of the release
may be something undesirable, provided that the issue is fixed ASAP in
a stable update.

The only reason why these issues are not fixed in Debian is not
because they're hard to fix, but because by fixing them (in the
easiest way, i.e. removal) they'll lose users and they don't want to.
Fixing them requires a sacrifice they're not willing to make.

> Debians policy is not to change the archive post release - it would be
> a matter of policy to add a clause 'freedom bugs mean package removal'
> as we do in gNS, and the system under discussion would be good to go.

They do fix such bugs (and treat them as RC), as a matter of fact, but
not consistently.  TeX and Linux have an exception by the RT.

> Switching to GNU packages is a nice long term goal, but where the
> system is the only one using them in a certain way it puts all the
> burden of testing and integration onto that distro.

Right, that's a bald move.  But I stand by what I said: this pioneer
effort will help tremendously the GNU project, in the long term.  IMHO
distros which embrace GNU ideals should attempt to do it, iff
feasible.

> Sometimes upstreams are difficult (not knowing the dialogue your
> talking about I cant comment, but I thought I'd throw that idea into
> the mix). Debian bug 531221 could be seen as an example of that.

Yeah.  Here's it's obvious what's the right thing to do.  There's a
reason why GNU gv does not implement this anti-feature.  Go hell to
standards if they contradict our fundamental values.

> > * In continuation of the above item, the system should include
> >   debugging symbols by default (via Recommends).  Every arch-dep
> 
> This I can't agree with. The overhead in cpu/memory/disk/network usage
> cant be justified by the few times that debugging symbols are needed.

So you say that nearly all build systems behave wrongly by default by
not stripping the binaries?  Why should a distro be different?

> One reason is of course they only build and host a handful of
> packages, not 15,000.

While archive size is a real concern, it is not something
unmanageable, especially nowadays.

> I think a better option would be an option in package management to
> enable installing -dbg for each package. It allows opt in if desired,
> and doesn't introduce overheads for all those who /dont/ debug.
> 
> For example, one could add it like this:
> cat <<EOF>> /etc/apt/apt.conf.d/01-enable-debug-packages
> APT::INSTALL::DEBUG=yes
> EOF

Yes, this is much better than simple Recommends: and I have thought
about it myself.  It's hard to be achieved in practice, though.

> I can't find a 'make-dfsg'.

$ apt-cache showsrc make-dfsg | egrep '^(Package|Binary)'
Package: make-dfsg
Binary: make
$ apt-cache showsrc make-doc-non-dfsg | egrep '^(Package|Binary)'
Package: make-doc-non-dfsg
Binary: make-doc

> Navigating through info is like nethack (only the monsters are scarier
> when using info)

Only when you don't read the manual.  It's really a breeze after
that, and you'll never look back.  The Info format is ancient, and has
many deficiencies.  Still, no replacement was invented so far.

> >     That way, fewer non-free packages will unintentionally sneak in

> I assume your talking about the 'bootstrapped from the ground' system,
> rather then gNS itself. 

I'm talking about both.

> >   - The maintainer will update the package in time, making the system
> 
> What is "in time"?

"In time" ~= "faster than the Debain and/or Ubuntu maintainers"

If I don't upload a new upstream release within days, I'm doing a
clumsy job.  (Yes, this means I'm doing a slightly clumsy job for some
of the packages I maintain in Debian.)

> This leaves me wondering what your idea of the stable release is -
> snapshots like you would find in Gentoo?

No.  Stable releases like Debian's in a roughly 1-2 years interval.
Nobody can spit out anything stable for 6 months (even with the help
of lots of pay cheques flowing from the supporting company), and a
platform that is 1.5+ years old is progressively becoming obsolete for
many uses.

> Each package is maintained by a group, of which one or two people are
> the lead maintainers. This means anyone in the group can upload a fixed
> package if needed, but there is a quantity of direct knowledge from the
> package leads.

Yes, this is a perfect approach.  The question is that nobody
volunteers for obscure and unpopular packages, so effectively one
person is the group.  In the Debian GNUstep team we are 3 people, and
maintain a relevantly large stack of packages (some rather complex),
including rendering help to other maintainers (Debian-Med,
Debian-Games).  This includes non-trivial library transitions and
constantly porting applications to new APIs, because most of the
upstream maintainers are not active.  A really hard and ungrateful
job.

Who'll volunteer for a Kazehakase or GNU Ball and Paddle maintainer
group?  Probably nobody on this list; perhaps many of you hear about
these packages for the first time.

> Can you expand on "embarrassing bugs"? I'm interested.

Sure.  Just a few examples:

- Install the kazehakase package from the genuine gNS archive.  Go
  to Edit -> Preferences to configure the browser.  It crashes.
- Make kazehakase your default browser via the x-www-browser
  alternative and in GNOME's preferences.  Now type "dhelp".  Another
  browser will be launched, because dhelp uses sensible browser which
  detects you're using GNOME and uses the gnome-www-browser
  alternative.

  Now temporarily install my package from jungle (after doing all the
  QA checks, of course).  These bugs do not exist, and the killer
  "search" feature works without even depending on the hyperestrayer
  daemon (because that's unnecessary).  (FTR, this feature allows me
  not to use search engines at all; something I'm unconfortable with.)

  I've improved the build system of GCompris and Freetalk (patches
  accepted upstream), and plan to further improve the former as soon
  as I manage to refine the patch.

- Install gnustep-base-doc.  It is an empty package.
- The GNUstep cairo backend is broken on all 64-bit architectures.
- gnome-desktop-environment was broken by not depending on a
  non-existent package.  This was fixed in Hardy (very late), probably
  already fixed in gNS as well.
- Try to set up a Cyrillic with console-setup.  Then please share the
  recipe :-)

Now, for most of these bugs I have submitted a report to Debian,
sometimes with a patch.  Sometimes I've fixed the bug myself, if I was
responsible for the Debian package.  As a Debian package maintainer, I
would never allow such bugs to slip in a stable release; they're
clearly release-critical.

I don't feel I have a moral obligation to provide a patch for
everything I fix in `jungle' -- these packages are forks, and I
derived from "upstream" only initially.  Sometimes even that's not
true, because the package does not exist in Debian (gnu-c-manual), or
I remade the packaging work from scratch (gajim), because I found it
inappropriate (that's subjective, of course).

> While I dislike Ubuntus release process, I don't agree that "least one
> important bug" is an accurate assertion.

Yes, this was an exaggeration of mine.  It is not an accurate assertion.

> ( Reportbug even had a GTK UI in the past, it may be possible to
> dig it up and polish it off.)

It has a new one now.

> >     The packages in `jungle' are not Ubuntu-like merges from Debian
> >     unstable, they are essential forks.  I decided it's worth to
> 
> Forks of Debian packages or Ubuntu packages?

Of Debian's.  I didn't incorporate any patch from Ubuntu because I
have found none that's worth considering (this is not to say that
there are none, not at all -- just like that *I* haven't found such
for my packages).

> Out of interest, do you check them with lintian?

Sure.  Everyone can check them first without risking installation.  I
never upload without running certain QA checks, lintian run being
naturally one of them.  Of course, for the unofficial gNS packages, I
"filter" lintian's output through my view of what the system should
be, i.e. things like

| E: bad-distribution-in-changes-file jungle
This is ignored completely.
| W: gajim: binary-without-manpage usr/bin/gajim-history-manager
This is reduced to a "pedantic" warning in my mind.

I also follow closely Debian development, and try to implement good
changes right away iff the toolchain in gNS allows it.

Not everything I do kills babies, although there are certainly changes
that are not good.  Of course I do not purport that I'm a good
maintainer.  I try to be according to my understanding and my
technical abilities, that's all.


Many thanks you for your comments about Builder and current gNS
development.  I'd wish you (and other people deeply involved) could do
them regularly on the gNS mailing lists.