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

[Karl Goetz]

On Fri, 19 Jun 2009 22:34:52 +0300
Yavor Doganov <address@hidden> wrote:

> 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:
> 
> > 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).

I've not played with dupload, I must have a look.

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

The thanks goes to Robert.

> > (PPC isn't well loved these days sadly).
> 
> Sad, but true.
> 
> > TRT?
> 
> TRT == The Right Thing
> DTRT == Do The Right Thing

Thanks.

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

Ah, yes.

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

Don't worry, I understand. All my servers still run Debian. The amount
of support in LTS is pretty laughable. (I hear the policies on updates
are much better in the last 6-9 months, but even so).

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

As a long term goal, I'd thought about something similar (more what I
described in my first email though).
What you describe is interesting though, and I'd definitely consider
changing my plan a bit.

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

Sorry for misquoting/misunderstanding then. The clarification did help,
thanks.

> >  http://www.gnewsense-unofficial.org/
> 
> Nice, I was not aware of this.

Only 3 people were.

> > - finish setting up simple buildd to get things rolling
> 
> Another tangential point: Debian does not support source uploads,

Pardon? Debian does support source uploads, but also allows binary only
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'm not sure I'd agree with that assertion. Packages should always be
tested before upload, wether they be binary or source only.

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

That would mean uploading all the binary debs produced by a package -
in the case of Linux thats a huge amount to upload if you have a slow
connection. I Believe at the moment you could get away with a debdiff
when uploading a package.

> > Robert has taken care of a large part of the work to build gNS on
> > Debian
> 
> Yes, kudos for the great work!

Definitely.

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

By site specific I meant "Have these been customised to the way
me/a friend/the boss does their work". 

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

No, that's not particularly freedom friendly.

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

ok.

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

Fair enough.

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

The scale is 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.

As a distribution builder, its possible to build it all, and build it
all with debug symbols.

For Claws-mail in Debian the package sizes are:
With debug symbols (i386) 3.8M
Without debug symbols (i386) 1.2M

That's a big difference. On install media, mirrors, downloading updates,
etc etc.

Then again, I'm not entirely sure what your 'not something
unmanageable, especially nowadays.' refers to exactly.

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

It would require patching apt/dpkg, and potentially some of the archive
tools depending on how its implemented server side.

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

Ah, I'd only searched for binary packages.

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

I dislike needing to read a manual on how to read help. If I'm
feeling interested then yes, a bit more knowledge is nice. When I want
to know what --foo does I just want to look that up.

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

ok

> > >   - 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.)

In both distros depending on the package updates might be from a days
through to never. 'in time' really needs some timeframe (eg, a week or
two).

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

Yup, understood. I'm not sure how to help with the obscure packages
problem, other then to point people who volunteer at the less assisted
groups. It would require some 'sign off' from the team/lead maintainer
on all assistance from volunteers, but might help a bit.

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

GNU Ball is new to me.

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

These are all... interesting. Thanks for the examples.

> - Try to set up a Cyrillic with console-setup.  Then please share the
>   recipe :-)

This one, well, good luck!

> 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).

> > ( 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.

Nice, so it does.
I'll try and remember that.

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

I'm going away for two weeks next Wednesday - minimal hacking, just
dropping by irc/email - so I've been putting of discussion until after
I get back.
Now seemed like a worthwhile time to mention it on this list though.
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK5FOSS)
Debian contributor / gNewSense Maintainer
http://www.kgoetz.id.au
No, I won't join your social networking group

signature.asc
Description: PGP signature