ITP: nbd -- supporting utilities for the Linux Kernel's Network Block Device

[wouter]

I intent to package the nbd utilities by Pavel Machek, that support the
Network Block Device in the Linux Kernel. This block device is essentially
a disk server-protocol, which makes it possible to do swapping over
TCP/IP, or use the device as a filesystem when NFS or other Network
Filesystem Protocols are not sufficient for some reason.

The upstream packages are (for now) available from
http://atrey.karlin.mff.cuni.cz/~pavel/nbd/nbd.html

(Please Cc me any replies, as I'm not subscribed to -devel)

Wouter

Re: ITP: nbd -- supporting utilities for the Linux Kernel's Network Block Device

[wouter]

On Mon, 7 May 2001, Dimitri Maziuk wrote:

> On Mon, May 07, 2001 at 10:32:54PM +0200, [EMAIL PROTECTED] wrote:
> > I intent to package the nbd utilities by Pavel Machek, that support the
> > Network Block Device in the Linux Kernel. 
> 
> There is E (enhanced) NBD by Peter Breuer at http://www.it.uc3m.es/~ptb/nbd
> Any reason you picked nbd over enbd? 

I didn't know it exists... I'll have to look at that.

> -- from what Peter says, enbd has
> a few improvements over nbd...

Probably, if he calls it "enhanced" ;-)

Re: ddts: notification about pt_BR-translation of the hello-debhelper description

[wouter]

On Wed, 5 Sep 2001, Branden Robinson wrote:

> On Wed, Sep 05, 2001 at 08:46:12PM +0200, Michael Bramer wrote:
> >The maintainer need not do anything. Maybe he don't know the
> >translation. The user only use this. This need only the
> >translators.
> 
> While we're on the subject, can you get someone to translate your mails
> into a comprehensible dialect of English?

Branden, please don't be rude.

The very fact that grisu's English is not that good, explains why it's so
damn important to support translations.

-- 
wouter dot verhelst at advalvas in Belgium

This is Linux world. On a quiet day, you can hear Windows reboot.

Re: Mounts with fs type 'none'

[wouter]

On Wed, 26 Sep 2001, Steve Greenland wrote:

> > mount -t none -o bind /somewhere /some/where/else
> 
> Thanks. Does anything else use '-t none'?

Swapspace. But that's hardly an issue...

-- 
wouter dot verhelst at advalvas in Belgium

This is Linux world. On a quiet day, you can hear Windows reboot.

Re: A language by any other name

[wouter]

On Thu, 27 Sep 2001, Martijn van Oosterhout wrote:

> On Thu, Sep 27, 2001 at 07:44:05AM +0200, David N. Welton wrote:
> > Maybe we should just use Debian English or Internet English, wich
> > means: produce something legible by other inhabitants of the Internet
> > and/or Debian, and who cares about the details.
> 
> Now there's a definition I can live with. 
> 
> English == Debian English == Legible English
> 
> As long as it's readable, it's fine.

Ah, that's a good one.

Let's just say Legible English == C locale.

So "English" could be linked to "Default locale set". Pretty much fits,
IMHO.

-- 
wouter dot verhelst at advalvas in Belgium

This is Linux world. On a quiet day, you can hear Windows reboot.

Re: an idea for next generation APT archive caching

[Wouter Verhelst]

On Sat, Oct 23, 2004 at 02:45:54PM +1000, Brian May wrote:
> > "Chris" == Chris Halls <[EMAIL PROTECTED]> writes:
> 
> Chris> Hmm, seems you are talking about version 1, which has been
> Chris> rewritten.  The new version isn't bug free yet but it does
> Chris> fix several problems.  It doesn't use wget.
> 
> It would appear apt-proxy v2 isn't in Debian (or that I can't find
> it).

It's not actually version 2 yet, but the current apt-proxy in unstable
is supposed to be apt-proxy v2.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Drop testing

[Wouter Verhelst]

On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
> Gergely Nagy <[EMAIL PROTECTED]> writes:
> 
> >> It may sound a bit radical, but core points have been mentioned in the
> >> thread already. I suggest to do it in a more radical way:
> >> 
> >>  - unstable lockdown in the freeze
> >>  - drop Testing and concentrate on work instead of wasting time on
> >>synching stuff. This eliminates the need for testing-security. See
> >>the last part of the paper for details.
> >
> > Doing this would result in many users who currently run testing fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.
> 
> Very few bug reports from testing users are of any value at all.

I respectfully disagree here.

With most of my packages, bugs get filed only when the transition to
testing has been complete for quite a while already, except when the bug
is a /really/ severe one (severity grave or critical).

When this is true, it doesn't matter whether the user is a testing one
or an unstable one -- both packages simply are of the same version.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Release-critical Bugreport for May 14, 2004

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote:
> On Sun, Oct 24, 2004 at 01:26:09AM +0200, Petter Reinholdtsen wrote:
> > [BugScan reporter]
> > > Bug stamp-out list for May 14 06:01 (CST)
> > >
> > > Total number of release-critical bugs: 565
> > > Number that will disappear after removing packages marked [REMOVE]: 1
> > > Number that have a patch: 79
> > > Number that have a fix prepared and waiting to upload: 22
> > > Number that are being ignored: 14
> > > Number on packages not in testing: 200
> > > Number concerning the next release (excluding ignored and 
> > > not-in-testing): 274
> > 
> > Did these reports stop, or is there something wrong with my email?
> > The last one I could find in my debian-devel-announce mail folder is
> > from 2004-05-14.
> > 
> > Anyone know what happened?
> 
> As far as I can tell, the reports are still being mailed as normal.
> Perhaps a listmaster could investigate why they're not reaching the
> debian-devel-announce readership.

They are; I received one just last week.

If they're not reaching you, I suggest you check your d-d-a subscription
and/or your spam filter.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Release-critical Bugreport for May 14, 2004

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 12:34:54PM +0200, Wouter Verhelst wrote:
> On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote:
> > On Sun, Oct 24, 2004 at 01:26:09AM +0200, Petter Reinholdtsen wrote:
> > > [BugScan reporter]
> > > > Bug stamp-out list for May 14 06:01 (CST)
> > > >
> > > > Total number of release-critical bugs: 565
> > > > Number that will disappear after removing packages marked [REMOVE]: 1
> > > > Number that have a patch: 79
> > > > Number that have a fix prepared and waiting to upload: 22
> > > > Number that are being ignored: 14
> > > > Number on packages not in testing: 200
> > > > Number concerning the next release (excluding ignored and 
> > > > not-in-testing): 274
> > > 
> > > Did these reports stop, or is there something wrong with my email?
> > > The last one I could find in my debian-devel-announce mail folder is
> > > from 2004-05-14.
> > > 
> > > Anyone know what happened?
> > 
> > As far as I can tell, the reports are still being mailed as normal.
> > Perhaps a listmaster could investigate why they're not reaching the
> > debian-devel-announce readership.
> 
> They are; I received one just last week.

... except that I didn't; I confused the bug stuff with the WNPP mail.
Please ignore.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:44:31PM +0200, Eduard Bloch wrote:
> > Remember, Debian is a volunteer project, you cannot force people to do
> > something they do not want to.
> 
> Motivation is the only factor to make them do things. Having to care
> about the release in order to continue the "fun work" leads to
> motivation.

Indeed.

Having the idea that the release takes ages, and that the "fun work"
will not come back in the near future, does not.

> > >Testing synchronisation are not of pure technical nature, they are
> > >social problem, and so they should be solved by people and not
> > >scripts.
> > 
> > Yes, testing synchronisation is not a purely technical matter. Nor is it
> > purely social, so the testing scripts, which automatically keep stuff in
> > sync, are a real help. On top of that, package maintainers coordinating
> 
> They are overhead.

They most certainly are not. It certainly is a help to be able to see
what packages are in a mostly-releasable state just by looking at those
that are in testing, and those that are not.

I have a simple question for you: have you actually talked to those
currently managing our releases before drafting this GR?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:51:47PM +0200, Eduard Bloch wrote:
> #include 
> * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
> > > not look appear as critical for maintainer, or not important enough to 
> > > touch
> > > package in the holy "frozzen" state). Such bugs are a disaster, they make
> > > our definition of a Stable release absurd. Yes, Debian Stable has become a
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's
> 
> a) The release time would be shorter

That remains to be seen.

> b) It would be up to humans (and not some obscure scripts) to decide
> whether the bugs deseves a fix or not

That is the case now, too. If the release managers deem it appropriate,
they can always override the testing scripts. However, the scripts
(which are far from obscure -- perhaps they are from your POV, but that
is not the same thing) generally do 'the right thing' by themselves,
which results in a massive reduction of manual work. That is a good
thing.

> Yes, some manpower would be required for this process.

Uh, I think that is a grave understatement.

> But fellow maintainers could be involved into process of evulation of
> the quality of a proposed upgrade.

That is the case now, too. You should try and have a look at
debian-release@lists.debian.org once.

> > currently frozen in testing, the situation is exactly what it is now;
> > the maintainer and RM have to decide whether putting this fix into
> > testing (or frozen) and possibly introducing new, more important bugs is
> > warrented by the ugliness of the bug. If the package is one of the large
> > majority of packages that are _not_ currently frozen in testing, then it
> 
> "not currently"? In my solution, the whole Sid archive would be frozen.

s/solution/proposal/

Even if dropping testing would be a good thing, then I still don't
believe it's a good idea to freeze the whole distribution in one go.
Freeze the base system first, freeze the rest when the base system is
good to go.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 05:57:05PM +0200, Eduard Bloch wrote:
> #include 
> * Marco d'Itri [Sat, Oct 23 2004, 10:06:24PM]:
> > On Oct 23, Eduard Bloch <[EMAIL PROTECTED]> wrote:
> > 
> > > ABSTRACT
> > You are trying to force developers to work on item x, which they dislike,
> > by forcing them to not work on item y, which they like more. You are
> > apparently oblivious to the fact that most developers will probably
> > spend their time on item w (which is probably not a Debian task), which
> 
> At least they won't poison Sid with fresh things that may others life
> more difficult. Eg. new library versions.
> 
> > they like less than x but still more than y. So this will at least fail,
> > and probably hurt debian too.
> 
> Maybe. What is the alternative? Continue with the current method and
> release Edge... 2009 or so?

Improve the way testing works. There are flaws, nobody is contesting
that; but just dropping the whole idea because of them flaws is akin to
throwing away the child with the bath water.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Drop testing

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 06:02:38PM +0200, Eduard Bloch wrote:
> #include 
> * Wouter Verhelst [Sun, Oct 24 2004, 11:41:33AM]:
> 
> > > Very few bug reports from testing users are of any value at all.
> > 
> > I respectfully disagree here.
> > 
> > With most of my packages, bugs get filed only when the transition to
> > testing has been complete for quite a while already, except when the bug
> > is a /really/ severe one (severity grave or critical).
> 
> Counter example: you fix a bug in Sid but insufficiently (and you do not
> know for sure). Few users continue reporting bugs in the Testing
> version. You ask them to test the Sid version. But Sid scares them

In that case, you build a package against the testing libraries, upload
that to your people.d.o webspace, and ask them to test that.

If they are not willing to test that either, then they are not helpful
and you cannot fix the bugs that bother them. This will stay the same
regardless of whether or not there is a testing.

> and they promise to wait for the update to be in Sid. Then, you will
> wait weeks for the acknoledgement and the bug may still be in Testing
> in this time. And it will take another two weeks for a real fix to
> slip into Testing.
> 
> That is not fun. That is overhead which creates confusion.

Because you're doing it wrong.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.

[Wouter Verhelst]

On Tue, Oct 26, 2004 at 10:52:58PM +0200, Oded Shimon wrote:
> On Tuesday 26 October 2004 22:37, Shaun Jackman wrote:
> > For your package to go in contrib, your dependency -- mplayer -- must
> > exist in non-free.
> Really? I didn't know this.

That's not true. There are many packages in contrib which do not have
all their dependencies in non-free. E.g., the bunch of java packages
which do not work with anything but a non-free java compiler -- a java
compiler which Debian itself cannot distribute (and therefor is not in
non-free).

A package in main must not depend on any software outside of main, and
must be DFSG-free; A package in contrib must be DFSG-free; A package in
non-free must be legally distributable by Debian.

There are no further restrictions than the above.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Comparing FHS 2.3 and 2.1

[Wouter Verhelst]

On Tue, Oct 26, 2004 at 03:02:02PM -0500, Manoj Srivastava wrote:
>  5)==
> 
> User specific configuration files for applications are stored in the user's
> home directory in a file that starts with the '.' character (a "dot file"). If
> an application needs to create more than one dot file then they should be
> placed in a subdirectory with a name starting with a '.' character, (a "dot
> directory"). In this case the configuration files should not start with the 
> '.'
> character. 
> 
>   I have no idea if we comply, but this is a new requirement.

I think we do. This is common sense anyway, most applications I've seen
do it that way.

>  6)== 
> 
>  Allows stuff like /lib64 or the like. /media is added as mount
>  points -- stuff that used to go under /mnt, which is still
>  retained. There a re a number of required subdirectories under
>  /media, which we don't have. Also, /srv should exist.
> 
>   NOT COMPLIANT*

Actually, we are (for new installations; not for upgrades from older
installations). For the /media part, anyway; not sure about /srv.

> 7)== 
> 
>  /usr/local/etc may be a link to /etc/local,
>  /var/lib/hwclock/adjtime has been moved here from /etc
> 
> 
>   So, we have a few minor things to tweak (/media, /srv, and the
>  XF86Config stuff, and then we should be OK to move to FHS 2.3 in
>  Etch.

I happen to think the XF86Config stuff is braindead. It's full of a
number of assumptions that happen to be correct at the time of writing,
but that may no longer be correct at some point in the future (to name
just one, the idea that XFree86 will be the X server of choice for all
unices trying to comply with FHS).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.

[Wouter Verhelst]

On Thu, Oct 28, 2004 at 05:10:04PM +0200, Frank Küster wrote:
> Shaun Jackman <[EMAIL PROTECTED]> wrote:
> 
> > Perhaps that's true -- I must do a little reading. However, if you
> > upload a package to contrib that build-depends on a package not in
> > contrib or non-free, you'll get a FTBFS RC bug filed against you
> > before you blink. 
> 
> Are there any (inofficial) buildds for contrib?

None that I am aware of, at least.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Waiting for unfinished jobs....

[Wouter Verhelst]

On Tue, Oct 26, 2004 at 10:06:48AM +1000, Anibal Monsalve Salazar wrote:
> Hello,
> 
> Package harbour is FTBFS on alpha, s390, m68k, powerpc and mips, as
> you can see at:
> 
> http://buildd.debian.org/build.php?pkg=harbour
>  
> Could someone shed some light on this problem?
> 
> A build log extract follows.
> 
> [...]
> gcc -I. -I../../../../include -Wall -g  -c ../../hbmlang.c -ohbmlang.o
> ../../../../source/compiler/linux/gcc/harbour ../../hbmake.prg  -n -q0 -w 
> -es2 -gc0 -I../../ -I../../../../include
> make[4]: *** wait: No child processes.  Stop.
> make[4]: *** Waiting for unfinished jobs
> make[4]: *** wait: No child processes.  Stop.
> make[3]: *** [descend] Error 2
> make[1]: *** [first] Terminated
> make[2]: *** [first] Terminated
> make: *** [build-stamp] Terminated
> Build killed with signal 15 after 150 minutes of inactivity
> [...]

This is usually an internal buildd issue, and shouldn't be your problem.
In an attempt to prevent builds from using up too much buildd resources,
sbuild (the program in the buildd suite which does the actual building)
keeps an internal timer for every build that is running; if no output
arrives in the log file within that time, the build is killed for fear
of a loop. The default time which is allocated to a build is 150
minutes; the messages you see originate from make receiving SIGTERM.

If it is indeed expected behaviour that the harbour build is silent for
more than 150 minutes in a row, then the timeout will have to be
increased (this can be done on a per-package, per-buildd basis), and the
build retried, but this is part of the routine maintenance of a buildd.

If your package is not in either 'building' of 'needs-build' on an
architectur after having been built with such a result, then please
contact the buildd admins of the architecture involved; they'll be able
to tell you why this was done.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: software updates file in /usr -- policy bug?

[Wouter Verhelst]

On Fri, Oct 29, 2004 at 08:49:54AM +0200, martin f krafft wrote:
> also sprach Chris Cheney <[EMAIL PROTECTED]> [2004.10.29.0823 +0200]:
> > dpkg should not put files in /usr when it extracts programs either if
> > /usr MUST NOT BE WRITTEN TO... ;)
   ^^
> Come on! The FHS regulates what normal software can/should do,
> partially so that package managers can work reliably. dpkg is the
> package manager, thus it is exempt from the FHS.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#292831: udev: udev prevents X from beeing started

[Wouter Verhelst]

Op ma, 31-01-2005 te 09:40 -0600, schreef Ron Johnson:
> On Mon, 2005-01-31 at 15:58 +0100, Christoph Hellwig wrote:
> > On Mon, Jan 31, 2005 at 12:45:42PM -0200, Henrique de Moraes Holschuh wrote:
> > > On Mon, 31 Jan 2005, Ron Johnson wrote:
> > > > Unfortunately, GNOME depends on hal, and hal depends on udev.
> > > 
> > > If it does indeed depend on udev, how does it work under kernel 2.4 at 
> > > all?
> > 
> > Because that statement is utter bullshit.  There's a single and optional
> > gnome component that wants to use hal.
> 
> A single and optional gnome component that is very, very useful.

apt-cache show magicdev

No, that does not just work on Linux 2.4.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GPL and command-line libraries

[Wouter Verhelst]

On Tue, Nov 02, 2004 at 09:53:21PM +0100, Wesley W. Terpstra wrote:
> 4. Writing to debian-legal and asking for advice.

Now that's a good idea. Why did you do that on debian-devel instead?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)

[Wouter Verhelst,,,]

On Thu, Nov 04, 2004 at 06:35:40PM +0100, Kurt Roeckx wrote:
> On Thu, Nov 04, 2004 at 05:46:55PM +0100, Otto Wyss wrote:
> > 
> > Now if you feel advantous, repack as many package on the source mirror
> > with gzip --rsyncable and notice the difference.
> 
> Exactly how is this going to help?  I can only see this as being
> useful when the files change.  Files should never change.  You
> get a completly new file.  Unless you can somehow tell to use the
> old file as base, this is not going to help.

He's talking about the Packages etc. files. Those do change.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: mozilla-firefox-locale package with all language translations

[Wouter Hanegraaff]

Hi,

On Thu, Nov 11, 2004 at 06:47:15AM +0100, Cesar Martinez Izquierdo wrote:
> 
> The "rules" file includes an "wget" rule that can download the available XPI 
> files with the translations.
> After download new XPI files, if you regenerate the package then you get all 
> the required files for these new XPIs.

This sounds like a very useful package! But why include all translations
in the package itself?

It should be possible to create an installer package that doesn't
include any translations, but instead downloads the translations you
selected after installation.  Something like the msttcorefonts package
does. It would be nice to have a similar package for installing
extensions, too.

Just a thought.

Best regards,

Wouter

Re: Bug#283717: hasciicam: enhance Description

[Wouter Verhelst]

Op wo, 01-12-2004 te 16:44 +0100, schreef jaromil:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, Dec 01, 2004 at 03:43:29PM +0100, Christoph Berg wrote:
> > Re: jaromil in <[EMAIL PROTECTED]>
> > > in case you are an arrogant person (i don't mean you are, i just don't
> > > know you at all) then consider that the GNU FDL license applied to the
> > > manual and documentation of hasciicam requires: the Invariant Sections
> > > being NAME, SYNOPSIS, DESCRIPTION, AUTHOR
> > 
> > May I suggest to move the package to non-free then?
> 
> may i suggest to move the package out of Debian then?

Well, non-free isn't part of Debian, so...

That said, the Debian project considers the GFDL to be non-free,
especially when invariant sections are being used (but still so if they
are not). It's just that for the Sarge release, we won't throw
GFDL-licensed works out yet.

[...]
> ok now please be careful:
> i'm talking about correctness and respect!

Good for you.

We, on the other hand, are talking about license freeness. Even though
the FSF considers the GFDL to be a Free license, Debian does not. It has
nothing to do with respect.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Wouter Verhelst]

Op wo, 01-12-2004 te 19:34 -0600, schreef John Goerzen:
> On Wed, Dec 01, 2004 at 05:53:08PM -0600, Manoj Srivastava wrote:
> > On Wed, 1 Dec 2004 23:32:18 +, Will Newton <[EMAIL PROTECTED]> said: 
> > And we have no time to set up i judgement over content --
> >  there is a clear criteria for inclusion of packages in Debian already.
> 
> We have no need to.  We can collectively make reasonable decisions
> without having to set up a constitional authority to do so.

rotfl. Most of the time, we cannot even make reasonable /with/ our
constitutional methods, let alone without them.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Wouter Verhelst]

Op zo, 05-12-2004 te 14:23 +0100, schreef Jonas Meurer:
> On 05/12/2004 James Foster wrote:
> > Pornography may be offensive to some. Is the package description for
> > hot-babe accurate? Are people who do not want it installed being
> > forced to install it?
> > 
> > People who may be offended by the package should read its description
> > and make up their own mind about whether or not they would like to
> > install it.
> > 
> > [...]
> > 
> > There's no excuse for censorship, ever.
> 
> so you would even accept nazi propaganda material in debian, just
> because you dislike censorship?

Yes, for the very same reason that many public libraries across the
world contain the book 'Mein Kampf', by Adolf Hitler.

> did you ever think about the issue, that discriminating
> positions/POVs themselves are censoring, as they eliminate the thoughts
> of suppressed individuals?

It is discriminating to censor other people's thoughts, even if those
thoughts themselves are discriminating and advocate censorship.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Wouter Verhelst]

Op zo, 05-12-2004 te 17:15 +0100, schreef Jonas Meurer:
> On 05/12/2004 Wouter Verhelst wrote:
> > > so you would even accept nazi propaganda material in debian, just
> > > because you dislike censorship?
> > 
> > Yes, for the very same reason that many public libraries across the
> > world contain the book 'Mein Kampf', by Adolf Hitler.
> 
> there's a big difference between documenting history and actively
> propagandizing historical backspins. at least there should be.

There's a big difference between accepting nazi propaganda in Debian and
actively propagating nazism. Besides, I fail to see how a library who
includes 'Mein Kampf' in its collection is merely 'documenting history'.
Documenting history would be to write a synthesis of Mein Kampf, perhaps
including historical context. Providing the book itself is more than
that.

> > > did you ever think about the issue, that discriminating
> > > positions/POVs themselves are censoring, as they eliminate the thoughts
> > > of suppressed individuals?
> > 
> > It is discriminating to censor other people's thoughts, even if those
> > thoughts themselves are discriminating and advocate censorship.
> 
> you may run into big troubles if you tolerate a violent ideology - it's
> no longer about thoughts but more about brutality.

Not if you're merely voicing those thoughts.

Apart from that, I wasn't talking about violent ideologies specifically.

> maybe we have different ideas about what freedom is, but at least in my
> eyes - freedom is always limited by other peoples freedom.

I couldn't agree more; in fact, I've made this claim myself in the past.
However, voicing your ideas does not limit the freedom of other people.
It may annoy them, but that is not the same thing.

> discriminating is mostly about retrenching other peoples freedom, isn't
> it?

Sure.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Wouter Verhelst]

On Sun, Dec 05, 2004 at 10:01:15PM -0800, Bruce Perens wrote:
> The U. would err on the side of caution given the potential danger. If 
> the "Hot Babe" package was being distributed from their facilities, 
> they'd pull the plug. In order to appear to be proactive regarding 
> harassing, offensive, or improper material, they'd take action against 
> the person involved.

Would they, then, complain to the person involved within the Debian
organisation, or would they rather act against their own people who
installed this "questionable" (haha) package?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Debian's status as a legal entity and how it could effect a potential defense.

[Wouter Verhelst]

On Mon, Dec 06, 2004 at 04:34:54PM +1100, Anibal Monsalve Salazar wrote:
> On Sun, Dec 05, 2004 at 09:06:23PM -0800, Thomas Bushnell BSG wrote:
> >Bruce Perens <[EMAIL PROTECTED]> writes:
> >
> >>It strikes me that some of the material in question would be in
> >>violation of the Internet policies of most institutions or companies
> >>that host our mirrors, as well as the applicable national laws.
> >
> >Can you please provide some concrete evidence of this claim, or else
> >stop making it?
> 
> For one, the Australian laws prohibite any web site in Australia to host
> pornographic material.

Have you taken a look at the material in question before this post?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Processed: Fixed in NMU of tetex-base 2.0.2c-2.1

[Wouter Verhelst]

Op vr, 10-12-2004 te 13:49 +0100, schreef Frank KÃster:
> I must admit that I didn't know that failed *removals* of
> build-dependencies would cause the buildd to fail. Nobody cared to
> indicate that to us.

It can happen. It doesn't happen always, but sometimes it does. In
extreme cases, a buildd host can become so FUBARed that no package will
build anymore (because *every* dpkg run will fail).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Linux Core Consortium

[Wouter Verhelst]

Op vr, 10-12-2004 te 12:50 +0100, schreef Michael Banck:
> *** The interested parties of the LCC should pick Debian as a base and
> Debian should make this possible. ***
> 
> Rather than everybody just throwing all their stuff in together and
> mixing it up. 
> 
> Of course, this would also mean for Debian to change. Debian is free
> and solid today, but not predictable. Thus:
> 
>  * We should commit to strict release cylces of a base system others
>(and Debian itself) can build value upon.

IOW, split off the release of the base system, and make it some entity
that stands by itself. Hmm, isn't that what LCC suggests we do?

>  * We should proabably also commit to a set of core architectures which
>*need* to be bug-free on release, while the rest *should* be, but
>would not delay the release.

This isn't necessary, unless you can show me one release which was
delayed because a certain architecture wasn't in shape.

>  * We should look into having a reality-check with respect to licensing
>and the way we treat each other.

You'll have to explain this one to me.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Wouter Verhelst]

Op vr, 10-12-2004 te 15:22 +, schreef Will Newton:
> On Friday 10 Dec 2004 15:13, Thomas Bushnell BSG wrote:
> > Ron Johnson <[EMAIL PROTECTED]> writes:
> > > It is. if we want people in Arabia to be able to possess Debian
> > > disks.
> >
> > The solution to censorious regimes is not to say, "well, ok, we'll
> > censor ourselves so you don't even have to bother".
> 
> Which is a fine point of view if you are making a political point. But as far 
> as I am aware we are trying to make an operating system.

Sure. So we should not censor ourselves.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor

[Wouter Verhelst]

Op vr, 10-12-2004 te 15:38 +, schreef Will Newton:
> On Friday 10 Dec 2004 15:24, Wouter Verhelst wrote:
> > > Which is a fine point of view if you are making a political point. But as
> > > far as I am aware we are trying to make an operating system.
> >
> > Sure. So we should not censor ourselves.
> 
> I don't see how that follows from what I said.

Censoring is done by people who try to make a political point. Creating
an operating system involves throwing a pile of software together,
integrate it, remove any and all bugs you find, and release that. It
does not involve censoring.

In Debian's case, we censor only based on the question whether a package
is DFSG-free, nothing else. It would be wrong to act otherwise.

> Here's a couple of examples:
> 
> We don't agree with censorship, so anything packageable goes in the 
> distribution.

That is currently not the case. There are four requirements for a
package to be in main, and these are clearly spelled out in policy: they
need to be DFSG-free, they must not depend on software out of main, they
need to be not so buggy that we refuse to support them, and they need to
be policy-compliant.

> This means we have a number of worthless and crufty packages 
> that no-one uses and our time to release is getting ever longer.

Packages that are worthless, crufty, unused, and unmaintained are
routinely being removed from the archive.

> We also end 
> up with packages that offend many people and may even cause legal problems 
> for our distributors.

Have you taken a look at what hot-babe actually looks like? I suspect
you haven't. I don't think it will "offend" anyone.

[...]
> Do you see why it seems like Debian is more of a political talking shop that 
> a 
> team trying to develop an operating system?

Debian has always been a political organization; if we weren't, we
wouldn't be anything called 'DFSG'.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: LCC and blobs

[Wouter Verhelst]

On Sun, Dec 12, 2004 at 12:25:53AM +0100, Goswin von Brederlow wrote:
> As a rule of thumb ask yourself: Can I take out the harddisk and
> sell it including contents?
> 
> With non-free firmware copied from a CD you can't. You have to remove
> the firmware first.

That assumes all non-free (as in speech) firmware is also non-free (as
in beer). This is simply not true; in fact, since they are in the
kernel, I'd think they are free (as in beer).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: LCC and blobs

[Wouter Verhelst]

On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
> Yes. Once you eliminate the dependency on the non-free file the driver
> becomes suitable for main.

The driver does not have /any/ dependency on a non-free file. It will
function perfectly without the non-free file.

The device, that's a different story; but Debian is not in the business
of distributing hardware, so there is no 'Depends:' header for that bit
of the problem.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


signature.asc
Description: Digital signature

Re: Bug#285234: ITP: unlzx -- unarchiver for *.lzx archives

[Wouter Verhelst]

Op za, 11-12-2004 te 16:37 -0600, schreef Graham Wilson:
> On Sat, Dec 11, 2004 at 10:53:10PM +0100, Marcin Orlowski wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: unlzx
> >   Version : x.y.z
> >   Upstream Author : Name <[EMAIL PROTECTED]>
> > * URL : http://ftp.uni-paderborn.de/aminetbin/find?unlzx 
> > * License : (GPL, LGPL, BSD, MIT/X, etc.)
> >   Description : unarchiver for *.lzx archives
> 
> How can so many people fail to fill in all of the fields in reportbug's
> ITP template? Is there some way to make it more clear, or are people
> just lazy?

Leave the fields empty, rather than filled in with foo-like data?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: LCC and blobs

[Wouter Verhelst]

Op za, 11-12-2004 te 16:59 +0100, schreef Goswin von Brederlow:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Dec 10, Matthew Palmer <[EMAIL PROTECTED]> wrote:
> >
> >> > You may want to take a look at debian-legal, because some people there
> >> > think that even free drivers for hardware devices which need an
> >> > externally loaded firmware are not acceptable for main.
> >> I presume you're referring to drivers which are useless without a non-free
> >> firmware blob.
> > I know about no drivers which are useless without a non-free firmware,
> > while I know about a huge number of hardware devices which are useless
> > without a non-free firmware.
> >
> > -- 
> > ciao, |
> > Marco | [9701 brFkyuAiot0mo]
> 
> So the drivers without the firmware are usefull (i.e. make the
> hardware work)

It is not the function of a driver to make the hardware work. It is the
function of the driver to talk to the hardware using a protocol as
defined by the engineers of the hardware.

The hardware will not function correctly (and, thus, will not talk back
or be useful) without the firmware blob, that is correct; but that does
not incapacitate the driver.

>  but the hardware doesn't work without firmware
> (i.e. make the driver fail)?

No, the driver will still function correctly, it will not fail. It will
not be able to get the hardware to do anything useful, but that is not
the driver's fault.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: On the freeness of a BLOB-containing driver

[Wouter Verhelst]

Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
> On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
> > What about the rest of the driver? I think that if you remove the BLOB, 
> > it's Free Software. It talks to a bus interface, which is a natural 
> > demarcation between our Free Software and the proprietary hardware 
> > design. It loads an arbitrary firmware file into the device. The device 
> > might not work without the BLOB, but the driver's still free as long as 
> > it does not incorporate the BLOB.
> 
> It's free, but it has a non-optional dependency on non-free software,

If it does, then Samba depends on non-free software as well.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: LCC and blobs

[Wouter Verhelst]

Op zo, 12-12-2004 te 04:52 +0100, schreef Goswin von Brederlow:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> 
> > On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
> >> Yes. Once you eliminate the dependency on the non-free file the driver
> >> becomes suitable for main.
> >
> > The driver does not have /any/ dependency on a non-free file. It will
> > function perfectly without the non-free file.
> >
> > The device, that's a different story; but Debian is not in the business
> > of distributing hardware, so there is no 'Depends:' header for that bit
> > of the problem.
> 
> We have to disagree on that then.
> 
> I think something like "Failure: firmware not loaded" or "Failure:
> path/firmware: No such file or directory" counts as a dependency.

On the device, yes. But not by the driver.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: If you really want Free firmware...

[Wouter Verhelst]

Op di, 14-12-2004 te 02:24 +, schreef Andrew Suffield:
> On Mon, Dec 13, 2004 at 03:57:19PM -0500, Brendan wrote:
> > On Monday 13 December 2004 14:50, Andrew Suffield wrote:
> > > On Mon, Dec 13, 2004 at 11:21:54AM -0800, Bruce Perens wrote:
> > > > My surmise is that we'd need an effort like that, raising $250K, to
> > > > design and go to full-custom fabrication of an FPLA with fully-open
> > > > design.
> > >
> > > Mine is that one can get useful things done without having to spend
> > > ridiculous amounts of money, or even any money at all. Yours is that
> > > you can't. Debian proves you wrong every day.
> > 
> > What does that have to do with hardware, please?
> > I mean, it's a lovely statement and all, but it's wrong.
> 
> Right back at you.

Not quite.

To design software, all you need is a fully functional computer.

To design hardware, you need to create and test a prototype every once
in a while. That'll cost you.

-- 
Wouter Verhelst
NixSys BVBA
Louizastraat 14, 2800 Mechelen
T:+32 15 27 69 50 / F:+32 15 27 60 51 / M:+32 486 836 198

Re: If you really want Free firmware...

[Wouter Verhelst]

Op di, 14-12-2004 te 07:48 -0500, schreef Chasecreek Systemhouse:
> > To design software, all you need is a fully functional computer.
> > 
> > To design hardware, you need to create and test a prototype every once
> > in a while. That'll cost you.
> 
> 
> Your logic doesnt follow.  
> Why, then, isn't Be (BeOS) still around ?

I don't see why that's relevant.

To design software, all you need is a fully functional computer.

To design software and make a profitable business out of that, you need
quite a bit more; but that's not what's being discussed here.

To design Open Source software (which BeOS never was, TTBOMK) and make
that successful, you need a slight bit more than 'just' a computer, too
(although not /that/ much more); but that's not being discussed here
either.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: dselect survey

[Wouter Verhelst]

Op wo, 15-12-2004 te 05:57 -0600, schreef Marcelo E. Magallon:
> On Wed, Dec 15, 2004 at 10:20:09AM +0900, Miles Bader wrote:
> 
>  > >  The other problem with aptitude is touted as a design feature: it
>  > >  tends to be all-or-nothing.  Either you use it always or you don't
>  > >  (automatic removal thingie).  This becomes a problem when multiple
>  > >  persons use different interfaces for adding and removing packages
>  > >  to the system.
>  > 
>  > You exaggerate.
> 
>  I do not.  I've seen aptitude remove "unwanted" packages more than a
>  couple of times because of this.
> 
>  It's a cool feature, yes.  It's also a design bug.

ACK. I very much prefer the way debfoster handles this: if there are
new, unknown packages on the system, it will ask, rather than assume,
whether a package is wanted or not. And will only do this for packages
that are not depended upon; so if you ever remove a package, it will ask
about its dependencies again.

This is far better than a program which tries to figure it all out
itself.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#285768: dselect survey

[Wouter Verhelst]

On Wed, Dec 15, 2004 at 01:53:20PM -0500, Daniel Burrows wrote:
> On Wednesday 15 December 2004 09:01 am, Simon Richter wrote:
> > aptitude could be taught to have "auto-installed" being Yes,No or
> > Unknown. Whenever a package that is in "Unknown" state could be removed
> > if it were only installed as a dependency, aptitude should list them in
> > the "actions to be performed" view as being still installed and unknown
> > whether they can be removed. Until I make a decision (which I am not
> > forced to do at this moment) the package would reappear in this list
> > everytime it could be deinstalled (i.e. until another package depending
> > on it is installed or a decision is made).
> 
>   It seems like "Unknown" would just be a synonym for "No", right?

Uh, yes. I think.

You may want to explain that a bit more.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bug#285768: dselect survey

[Wouter Verhelst]

On Wed, Dec 15, 2004 at 04:02:03PM -0500, Daniel Burrows wrote:
> On Wednesday 15 December 2004 03:37 pm, Wouter Verhelst wrote:
> > > ? It seems like "Unknown" would just be a synonym for "No", right?
> >
> > Uh, yes. I think.
> >
> > You may want to explain that a bit more.
> 
>   Well, from the bug report, it looks like the proposal is to maintain the 
> current behavior, but to set a different flag on packages that were 
> conservatively assumed to be manually installed, so they can be switched 
> later to automatic handling if desired.  Sounds useful.

Well, in that case, not entirely.

You may also want to set a flag on packages that are assumed to be
automatically installed, but of which you have no information.

Consider libgnome2-perl: people may want to install that, even if there
is no dependency, to allow for debconf to provide a gnome frontend;
however, I can imagine there are also packages that have a dependency on
libgnome2-perl.

Now consider a user who recently switched to aptitude after having used
a different frontend for a long while; this user had installed
libgnome2-perl manually (for the debconf frontend), but later on
installed just one package depending on libgnome2-perl to see what it
does. At that time, the switch to aptitude was made; but then the user
decided that the package using libgnome2-perl isn't useful enough, and
removes it again.

What debfoster will do in that case, is present the user with
libgnome2-perl (and all packages whom only libgnome2-perl depends on and
for which no preference is yet known), and ask whether they should be
removed.

I really think this is the right thing to do in such a situation.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Linux Core Consortium

[Wouter Verhelst]

Op do, 16-12-2004 te 14:46 -0500, schreef Ian Murdock:
> We've heard
> directly from the biggest ISVs that nothing short of a common
> binary core will be viable from their point of view.

Well, frankly, I don't care what they think is 'viable'.

'ISV' is just another name for 'Software Hoarder'. I thought Debian was
about Freedom, not about "how can we make the life of proprietary
software developers easy?"

As a distribution consisting only of Free Software, Debian has very good
reasons to not distribute third-party binaries. That's what the LCC
binaries will be: third-party. We should not compromise all that we have
and all that we stand for, for the benefit of some Enterprise Managers
and people advocating non-free software.

If the LSB doesn't work, the non-free hoarders are free to suggest
improvements where applicable; if it is impossible to create a single
binary that will run on all LSB-certified distributions, then that is a
bug in either the LSB process (by failing to provide a well enough
defined standard), the non-free software (by relying too much on a
single implementation of the standard), or the toolchain (by not being
able to correctly manage the ABI of built libraries). That bug may be
worked around by providing a common binary core; it will, however, not
actually be fixed by doing so.

One of the major benefits of Free Software is the ability to fix bugs
without having to rely on external factors. If, however, rebuilding your
C library will result in the loss of your support contract, you will
essentially have lost that benefit, and many more with it.

I refuse to accept that 'providing a common binary core' would be the
only way to fix the issue. It is probably the easiest way, and for lazy
people it may look as if it is the only one; but we should not dismiss
the idea that it is possible to fix the Free software or the standard so
that the LSB /will/ work.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues

[Wouter Verhelst]

I think we're looking at this from the wrong end.

Using Free Software, it's easy to produce more Free Software in such a
way that it will run on all Free platforms. This is normal; most, if not
all, Free Software is built by people who mainly (or only) use Free
Software, so they do not usually look at the specific needs that
developers of non-free software have.

At some point, developers of non-free software came along, and tried to
produce non-free software for the Free platforms. These non-free
developers had a background on non-free platforms, where "a platform" is
a bunch of binaries that were compiled at a single "vendor". Since
everyone running one of those platforms has the exact same compiled
form, it is easy to produce a standard so that one can compile software
that will run on /all/ versions of the same platform; after all, there
is only "one" version (not considering later or earlier iterations of
the same platform).

This is not true if you're running a free software platform, where
technically everyone can create his 'own' version. As a result, people
who write non-free software are having issues.

To address these issues, the Free Software people created the LSB: a
standard that defines what a binary form of the source "out there"
should look like. This way, non-free developers can theoretically write
against that standard, and distribute a compiled binary that will run
"everywhere".

Obviously, that hasn't worked. The non-free developers are having issues
with their software if they write against the standard, so that it does
not, in fact, run everywhere. They look at the non-free platforms and
say 'it works over there, so it should work here'. They look at the
differences between the non-free platforms and the Free platforms, and
see that the non-free platforms are bit-by-bit the same thing
everywhere whereas the Free platforms are not. Thus, they conclude that
to solve the issue, the Free platforms should be bit-by-bit the same
thing everywhere, too.  

That is, indeed, one way to solve it: throwing out the Freedom we, Free
Software developers, have, and slowly starting to move towards a
non-free platform. But is that really what we want? I would think it is
not.

Instead of pointing us towards the non-free platforms with their
binary-identicalness, I think the non-free software developers should
tell us why the LSB has failed. They should tell us where the standard
is not clear enough, or where the issues with the LSB are, so that they
can be solved. This will require them to exhibit a level of cooperation
that we are not used to see from non-free developers, but does that
matter? After all, they want to get Free Software modified for their
purposes. That is possible -- it is the very heart of Free Software that
it can be modified for your own purposes -- but they should do it by
using the rules of Free Software, not by trying to mold the Free
Software in something which approximates the (to them more familiar)
non-free software.

Thus, the answer to the failure of the LSB is not "the Free Software
people should be more helpful to the non-free people"; the correct
answer is "the non-free people should be more helpful to the Free
Software people".

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues

[Wouter Verhelst]

Op do, 16-12-2004 te 14:38 -0800, schreef Bruce Perens:
> Wouter Verhelst wrote:
> > To address these issues, the Free Software people created the LSB
> When I founded the LSB, the job I proposed for it was to do what the
> LCC is now proposing to do. I didn't believe that a paper standard
> alone would be effective at resolving cross-distribution compatibility
> issues, and it has proven not to be. A paper standard is certainly a
> helpful thing to have around, though, because it helps focus policy
> discussion and record the result.
> > That is, indeed, one way to solve it: throwing out the Freedom we, Free
> > Software developers, have, and slowly starting to move towards a
> > non-free platform.
> >   
> This is sophistry. LCC would be constructed of Free Software and would
> itself be no less free than Debian main.

Would it?

I don't know what the essense of Free Software is to you; I suppose it
is something different to each and everyone of us.

However, to me, the essense of Free Software is that it allows one to
modify the software as one sees fit. Remove that ability, and I don't
see the software as Free anymore.

By requiring software to be bit-by-bit identical to a given binary
compilation, we would (at least partially) lose the ability to modify
the software as we see fit, and thus, the software wouldn't be as Free
anymore.

This would be just a minor problem to us Distributors (who get to have a
say in the LCC); however, it would be a significant problem to people
interested in using now LSB, then LCC-certified software on platforms
with extra patches (say, they recompile the kernel to include a specific
feature that wasn't in the official LCC-certified kernel); they are at
risk of losing any and all support they get from the non-free developer
because of doing so.

This must not happen.

> > They should tell us where the standard is not clear enough, or where the 
> > issues with the LSB are, so that they can be solved.
> Here I can turn your own argument upon itself. Why do we create paper
> standards? One important reason is that in the world of proprietary
> software, vendors would not share their source code, so they had to
> define what the program would do in human language instead.
> A paper standard is a second-hand description of something that our
> community has the unique ability to share, bypassing the paper.

That is simply not true. Our community has the ability to share source;
that does not mean we should start sharing binaries, too.

> The essential technical problem with the LSB is that it is not
> sufficiently descriptive of every thing that a modern application must
> depend on,

I acknowledged that.

My point is that one can, indeed, solve this by providing common
binaries, but that doing so is the most ugly way to attack the issue.

If the paper standard is insufficient, it should be improved. If there
are issues with the toolchain that reduce the portability of the
produced binaries, then the toolchain should be improved. If the
non-free software wants to do things that are by its very nature not
portable, well, then it should not do that.

I do, however, not accept that the only way to improve the portability
of non-free software would be to make Free Software less Free.

> and is not within 10 years of being sufficiently descriptive at the
> rate that its development has been going. In addition, it is not the
> best possible technical solution to getting a bunch of Free
> Software-based distributions to be more compatibile with each other.

Then we will need to improve the compatibility in more ways than by just
providing a paper standard. There are many technically elegant ways to
do that. Using the same binary on all distributions is /not/ one of
them.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues

[Wouter Verhelst]

On Thu, Dec 16, 2004 at 11:01:16PM -0800, Bruce Perens wrote:
> You never lose the right to modify. You lose the right to claim that a 
> modified version is the certified one. I addressed this specifically in 
> DFSG section 4:/
> /
> 
>/The license may require derived works to carry a different name or
>version number from the original software./
> 
> At the time, there was an "Official" version of ABIWord sanctioned by 
> ABISource, and any modified version would be unofficial and had to bear 
> a different name, and DFSG #4 was written specifically to allow that 
> sort of uses. This is certainly a form of certification. Indeed, Debian 
> makes use of similar certification for its Official CD.

Indeed; however, IMO excerting the right to modify as defined by the
DFSG should never result in the loss of support, or other negative
consequences, because in that case you might as well not have it. This
type of certification does carry that kind of negative consequence.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Linux Core Consortium

[Wouter Verhelst]

Op do, 16-12-2004 te 17:07 -0800, schreef Adam McKenna:
> On Fri, Dec 17, 2004 at 01:13:11AM +0100, Bill Allombert wrote:
> > I think Wouter is only asking for reciprocity here. If they don't care
> > about his concerns why should he care about theirs ? Or alternatively
> > "not caring" is a freedom.
> 
> We care because our priorities are our users and free software.  Just because
> someone works for an ISV or develops on/for proprietary software does not 
> make them a second class user.
> 
> That said, I am not arguing for or against LCC, I just didn't like the tone
> of Wouter's e-mail, or the sentiment implied in it.

I did not intend that sentiment; I explained what I meant to say in a
new thread.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: The LCC is a bad idea, but that doesn't mean the LSB doesn't have any issues

[Wouter Verhelst]

Op vr, 17-12-2004 te 01:40 -0800, schreef Steve Langasek:
> On Fri, Dec 17, 2004 at 10:03:00AM +0100, Wouter Verhelst wrote:
> > Indeed; however, IMO excerting the right to modify as defined by the
> > DFSG should never result in the loss of support, or other negative
> > consequences, because in that case you might as well not have it. This
> > type of certification does carry that kind of negative consequence.
> 
> But this happens all the time in all kinds of situations 

Sure, but that doesn't suddenly make it a good idea.

My point is that there must be a better way to fix this. I would suggest
an alternative, but I do not know what, exactly, it is in the LSB that
makes proprietary developers decide it is not viable.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)

[Wouter Verhelst]

On Wed, Jan 05, 2005 at 09:42:52AM +0100, Ingo Juergensmann wrote:
> On Wed, Jan 05, 2005 at 12:06:53AM -0800, Steve Langasek wrote:
> > The "us versus them" pitting of volunteer contributions against each other
> > appears to be your game alone, and is precisely the sort of thing that led
> > me to killfile you in the first place.
> 
> Ohno, it's not my game, trust me. I've better things to do than playing such
> a game. Maybe I'm the one who complains most loudly, but there are DDs that
> agree with me in some (sometimes most or all) points,

Yes, there are always 'DDs' who agree with 'some' of your points. Yet,
you're the only one people consistently dislike.

I've tried to defend you for some time, because I thought your past help
to the m68k port should not have gone unnoticed. I stopped doing so when
I realised your conduct does not deserve defence.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: For people more knowledgeable about buildds...

[Wouter Verhelst]

On Tue, Jan 04, 2005 at 10:13:11PM +1100, Andrew Pollock wrote:
> Also, what is involved with putting a package back into the Needs-Build
> state (i.e. requeueing it)?

The buildd maintainer replying to a log or running 'wanna-build'
manually.

> With complaints about the lack of response/response times from emails
> to [EMAIL PROTECTED], I was just wondering if it was feasible to
> have an email gateway like db.debian.org has for rescheduling failed
> builds? I presume the majority of emails sent to [EMAIL PROTECTED] are
> requests for requeuing?

Mostly, yes (and many of them are either bogus or superfluous, but
that's a different matter).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Maintainer needed

[Wouter Verhelst]

On Tue, Jan 04, 2005 at 08:42:07PM +0100, Giuseppe Scrivano wrote:
> Hi,
> First of all I am not a debian developer, so I always need a sponsor
> to upload it, and I think that the package is not yet perfect. Maybe
> an expert person can handle it better.

The first role of a sponsor is to check the quality of your package,
discuss it with you, and to help you improve it. The uploading bit is
just a final stage.

If you are interested in having this in Debian, the best way to go at it
is to find a sponsor. An RFP might work, but chances that it will are
very slim.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Ignoring the truth or Hiding problems? (was: Are mails sent to xxxx buildd.debian.org sent to /dev/null ?)

[Wouter Verhelst]

On Wed, Jan 05, 2005 at 01:06:49PM +0100, Ingo Juergensmann wrote:
> On Wed, Jan 05, 2005 at 12:15:43PM +0100, Wouter Verhelst wrote:
> > I've tried to defend you for some time, because I thought your past help
> > to the m68k port should not have gone unnoticed. I stopped doing so when
> > I realised your conduct does not deserve defence.
> 
> And now you joined the other side? Attacking instead of defending? Does that
> help the m68k port better? I doubt that seriously. 

I'm not attacking anyone.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: New stable version after Sarge

[Wouter Verhelst]

On Wed, Jan 05, 2005 at 04:16:49AM -0800, Stephen Birch wrote:
> Perhaps a date based release mechanism could be built using a new
> distribution, call it prestable.
> 
> Packages qualify to be enter prestable after residing in testing for
> ten days and having NO RC BUGS. The idea is to keep prestable in a
> highly stable state at all times, a rolling stable if you will.

That's how testing started off. We stopped doing this because
a) it at one point stalled glibc; as a result, nothing moved to testing
   anymore, and when it finally did, the changes were so dramatic that
   testing was broken for quite some time.
b) Some RC bugs are only discovered when they migrate to testing. If the
   promise of 'prestable' would be that it would contain NO RC BUGS,
   then we would have to throw those out. That would likely result in
   prestable being a very incomplete system.

Also, adding yet another distribution that is even harder to update than
testing is doesn't seem like a good idea to me. We're already having
issues with testing and security; $DEITY forbid that we would make it
worse.

(not being a member of the release team, the above isn't guaranteed to
be right in all details; but I don't think I'm way off base here)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: New stable version after Sarge

[Wouter Verhelst]

On Wed, Jan 05, 2005 at 05:12:57AM -0800, Stephen Birch wrote:
> Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 13:46:
> > That's how testing started off. We stopped doing this because
> > a) it at one point stalled glibc; as a result, nothing moved to
> > testing
> >anymore, and when it finally did, the changes were so dramatic
> >that
> >testing was broken for quite some time.
> 
> Hmmm .. I didnt know that testing was originally a non-RC distribution
> although I have heard of the glibc pain.

Again, I'm not entirely sure this is exactly what happened; but I am
quite sure this is what /will/ happen if we go down that road.

> > b) Some RC bugs are only discovered when they migrate to testing. If
> > the
> >promise of 'prestable' would be that it would contain NO RC BUGS,
> >then we would have to throw those out. That would likely result
> > in
> >prestable being a very incomplete system.
> 
> ahh .. I take your point. What about the idea of identifying a list of
> release essential (RE) packages? Is that the mechanism actually used
> to determine the relase point when testing is frozen?

You should ask the release managers about that.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: New stable version after Sarge

[Wouter Verhelst]

On Wed, Jan 05, 2005 at 06:07:41AM -0800, Stephen Birch wrote:
> Wouter Verhelst([EMAIL PROTECTED])@2005-01-05 14:22:
> >
> > You should ask the release managers about that.
> >
> 
> Wow!! You mean the decision process is not made public? I would have
> thought it would be out in the open for all to see.

No, I mean 'I dunno, but these are the people who probably will' ;-)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Status of Kernel 2.4.28 packages?

[Wouter Verhelst]

On Thu, Jan 06, 2005 at 08:44:13AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 05, 2005 at 09:23:18PM -0800, Marc Wilson wrote:
> > On Sun, Jan 02, 2005 at 08:02:25PM -0600, Steve Greenland wrote:
> > > Converting to udev is an additional step, and caused me a lot more
> > > work than the basic 2.6 upgrade (mostly getting my head around it, and
> > > converting from usbmgr).
> > 
> > Converting to udev is in no way a part of converting to a 2.6 kernel.  Not
> > even if you're using devfs.  Only people unfortunate enough to be using
> > Gnome 2.8 are required to have udev running.
> 
> I'm running gnome 2.8 just fine without udev

AOL. magicdev works just fine to do essentially the same thing as
gnome-volume-manager.

udev. Just say no.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: Bad Sig (was: Re: Diversion of APT tools by dpkg-cross (apt-get,apt-cache,apt-config))

[Wouter Verhelst]

Op wo, 02-02-2005 te 13:53 +0100, schreef Bas Zoetekouw:
> Hi David!
> > Me too, but I noticed an escaped >From in the message and didn't 
> > investigate 
> > further.
> 
> AFAIK, gpg signs the body only.

Yes, but a leading 'From' on a line will be escaped to '>From' in
transit. This is because some software will otherwise interpret the
leading from to be the start of a new message (it's a bit too close to
the mbox format start)

-- 
Wouter Verhelst
NixSys BVBA
Louizastraat 14, 2800 Mechelen
T:+32 15 27 69 50 / F:+32 15 27 60 51 / M:+32 486 836 198


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: list what's in the NEW queue?

[Wouter Verhelst]

Op do, 03-02-2005 te 15:44 +0100, schreef Frederik Dannemare:
> On Thursday 03 February 2005 14:45, Steve Langasek wrote:
> > Increasing the rate at which new packages flow into unstable is NOT
> > something that should be a priority when we're trying to get the RC
> > bug count down in preparation of a release.  Show me that there are
> > enough people working on release-critical issues for sarge,
> 
> You're probably right there's not.

Parse error.

> > which 
> > requires no imprimatur from the DPL, before you start throwing
> > packages that have never even been tested by their maintainer at us
> > faster than we already get them.
> 
> I see your point if it is really the case that uploads are being done 
> without proper testing from the maintainer himself/herself.

His point is still valid even if all maintainers do proper testing. You
can't be expected as a maintainer to be able to test /every/ possible or
impossible situation in which a package could be used. And then I'm not
even talking about packages that should conflict with eachother but
don't, because the maintainer of the new package didn't know that a file
in his package happens to have the same name as a different file in a
completely unrelated package...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: execturing libc

[Wouter Verhelst]

On Thu, Feb 03, 2005 at 04:31:02PM +0100, Goswin von Brederlow wrote:
> [EMAIL PROTECTED]:~% /lib64/ld-linux-x86-64.so.2 /lib/libc-2.3.2.so 
> GNU C Library stable release version 2.3.2, by Roland McGrath et al.
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-6).
> Compiled on a Linux 2.6.0-test7 system on 2005-01-12.
> Available extensions:
> GNU libio by Per Bothner
> crypt add-on version 2.1 by Michael Glad and others
> NPTL 0.60 by Ulrich Drepper
> BIND-8.2.3-T5B
> NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
> Thread-local storage support included.
> Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>.
> 
> 
> And exactly that info is the reason why one may want to execute libc.

There's also the fact that an executable libc is a nice way to
circumvent a 'noexec' restriction on a mount point :-)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mkchroot scripts

[Wouter Verhelst]

On Thu, Feb 03, 2005 at 10:58:55PM +0300, Sergei I. Kononov wrote:
> On Thu, Feb 03 at 20:23:20 (+0100), Christoph Berg wrote:
>  
> > What's the difference to makejail and debootstrap?
> 
> 1. Created chroot enviroment use less disk space, and does not
> include not needed files/dirs (like: passwd,

Actually, that /is/ a needed file. Some programs look up the name of a
user before doing stuff (or look up the UID of a username), and without
that file they do very strange things

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: execturing libc

[Wouter Verhelst]

Op vr, 04-02-2005 te 15:54 +0100, schreef Goswin von Brederlow:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > There's also the fact that an executable libc is a nice way to
> > circumvent a 'noexec' restriction on a mount point :-)
> 
> How does libc help?
[...]
> Libc doesn't execute its arguments.
> 
> The way to circumvent a noexec is to call the dynamic linker like I
> did for libc:

Uh, yes, you're right. Sorry, I was confused.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what is /.udev for ?

[Wouter Verhelst]

On Thu, Feb 10, 2005 at 01:05:15PM -0500, Roberto C. Sanchez wrote:
> "carefully remove with appropriate tools."  Anyone who goes mucking
> around their filesystem removing potentially critical compenents
> without thinking about it and using the proper tools for the job,
> is not thinking straight.

'rm' is not a proper tool for file removal?

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#295328: general: Help messages to stderr should be banned

[Wouter Verhelst]

On Tue, Feb 15, 2005 at 03:06:19PM +0100, Francesco P. Lovergine wrote:
> On Tue, Feb 15, 2005 at 07:38:08AM -0600, John Hasler wrote:
> > Francesco P. Lovergine writes:
> > > It depends on programs, sometimes the same usage function is used for
> > > either --help or invalid options.
> > 
> > Sure, but the output should still be directed correctly.
> 
> Quite difficult if the function is the same. In both cases it uses stderr.

A computer can technically do anything; difficulty results from
(an) incorrect decision(s) by (a) programmer(s).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#286214: ITP: kwin-style-asteroid -- Pixel-for-pixel clone of Win2000 GUI style for KDE

[Wouter Verhelst]

On Fri, Feb 18, 2005 at 12:35:42PM +0100, Marcin Orlowski wrote:
> Wouter Verhelst wrote:
> > Merging all these into one package will not do much harm to the user
> > (who will be able to install a 2M package on top of his 250MB KDE
> > installation to get all the choice of GUI themes he would ever want to
> > have); OTOH, more packages do have a negative impact on everyone --
> > increased size of the Packages file (which isn't good for modem users
> > and people with slower hardware) and increased overall size of the
> > archive.
> 
> Why do you imitate you care modem users? You care a few bytes more in
> Packages (text file! gzipped!)

That has an impact on everyone, especially people with slower hardware.
I know what I'm talking about, I'm an m68k porter.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: problem of savelog

[Wouter Verhelst]

On Fri, Feb 18, 2005 at 01:53:20PM +0100, Frank Küster wrote:
> Atsuhito Kohda <[EMAIL PROTECTED]> schrieb:
> 
> > Thanks for your infomation.  I met the same problem today's morning
> > so I changed exim to exim4 ;-)
> 
> Fine to hear this can be done "today's morning".  Is the configuration
> migrated to the new version (mine is pretty simple), or does one have to
> start anew?

In all but the most complex cases, migrating exim v3 to exim v4 involves
running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te
resulting file to /etc/exim4/exim4.conf. In the cases where this is not
true (or, better said, in the cases where there is a slim chance that
this might not be true if you're unlucky), exim_convert4r4 will warn
you about that.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: problem of savelog

[Wouter Verhelst]

On Fri, Feb 18, 2005 at 03:07:49PM +0100, Marc Haber wrote:
> On Fri, 18 Feb 2005 14:51:39 +0100, Wouter Verhelst
> <[EMAIL PROTECTED]> wrote:
> >In all but the most complex cases, migrating exim v3 to exim v4 involves
> >running /usr/sbin/exim_convert4r4 on /etc/exim/exim.conf, and copying te
> >resulting file to /etc/exim4/exim4.conf.
> 
> Actually, this is deprecated. The Debian Exim 4 maintainers strongly
> recommend using the debconf-driven setup scheme.

Well, yes, but it works in many more cases, and it's what upstream
supports. And I personally prefer the one-file setup anyway -- if I
wanted many configuration files, I'd use Postfix.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote:
> Clint Byrum  spamaps.org> writes:
> > Now, can someone please tell me how messages like the one below, and
> > others, aren't indicative that debian should drop s390, mipsel, and
> > maybe hppa from the list of architectures? How about we release for
> > i386, sparc, and powerpc, and let the others release on their own
> > schedule? This business of supporting 11 architectures and making sure
> > they're all 100% right before releasing is just about the worst idea
> > ever.
> 
> Couldn't agree more.  
> 
> Our chances of actually releasing one day could only increase if we
> dropped arches such as mipsel, s390, m68k, ... and concentrated on
> those that actually mattered: i386, powerpc, amd64 -- and I'll gladly
> add a few more.

I'll believe that when you can point me to an actual occasion where
something not being built on /only/ one of those "less mattering"
architectures you want to drop (as opposed to the three latter ones)
effectively stalled the release.

As it is, architecture-specific problems occur on all architectures, not
just the "less important" ones. Claiming the contrary only proves you
don't know what you're talking about.

The problem being talked about (not enough disk space on the buildd
host) is serious, but can be fixed; and /nothing/ prevents it from
happening to other architectures in the future.

> But a total of eleven is insane.

It is sometimes hard to get them all to work, yes.

It also vastly increases the quality of the Free Software in our
archive, as we discover bugs that appear only on one architecture. It
also ensures that GNU/Linux still actually runs on the platforms we
support, which is often of great importance of embedded developers. It
also ensures that gcc remains working (what better way to test a
compiler than to compile 10G worth of software with it?), and so on.

[...]
> Still, the hours we maste on fixing, building, maintaining, ... code
> on unused platforms is hysterical waste of resources.

The only resource that is being wasted, is one of disk space (well, and
network traffic for mirror updates). How is that a major problem,
considering that mirrors will be allowed to pick their architecture in
the future?

> Resources we don't really have.

On porting, we usually have all the resources we really need.

> It would be better to concentrate on a core of packages, and
> platforms, and then get on with it.  One day it will break the
> infrastructure provision, at which point someone will fork our
> high-priority core packages.

You're welcome to do so, if you really must.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> Also, really huge stuff, like KDE, cannot be uploaded as frequently as
> perhaps the maintainers would like because it kills the slower buildd's
> for a few days.

Hypothetical daily KDE builds would also insanely increase the amount of
network traffic being used by the mirror pulse and people upgrading
their home boxes, so it isn't just a buildd problem.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 20 Feb 2005, Brian Nelson wrote:
> > Also, really huge stuff, like KDE, cannot be uploaded as frequently
> > as perhaps the maintainers would like because it kills the slower
> > buildd's for a few days.
> 
> The answer to that is to setup a dist-cc cluster for these archs,
> where only the master node is in the slow arch, and everything else is
> a fast arch.

That would require cross-compilers on the other hosts in the distcc
cluster, and (unless I don't understand how dist-cc works; never had a
look at it) a mechanism to install build-dependencies on those hosts in
addition to the one on the 'slow' node.

There are a few reasons why we usually avoid cross-compilers for buildd
purposes. For one, as one cannot as easily test a cross-compiler by
running a test suite, it may have been miscompiled -- but you wouldn't
notice; this would result in strange, hard to debug behaviour by the
resulting cross-compiled packages. For another, satisfying
build-dependencies for cross-compiling is pretty hard, as anyone using
dpkg-cross can tell you.

Our answer simply is (or at least, should be) to increase the number of
buildd hosts if we can't keep up, and to request the maintainers of
large packages that they don't do daily updates, which is a bad idea
anyway. If maintainers insist on doing daily updates, we stop building
their package. See mozilla-snapshot (even though it's no longer in the
archive these days).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 12:04:37PM +0100, Pierre Habouzit wrote:
> I know this raises practical problems (the worst of it not beeing able 
> to construct the same packages that are on the archive when starting 
> from source+diff). But if one day BW is critical, there is a path to 
> explore here.

Oh, absolutely; but let's not forget that we can't even correctly
specify how we only want to build arch-dep vs arch-indep packages
currently...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 11:49:46AM +0100, Thiemo Seufer wrote:
> Wouter Verhelst wrote:
> > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote:
> > > Also, really huge stuff, like KDE, cannot be uploaded as frequently as
> > > perhaps the maintainers would like because it kills the slower buildd's
> > > for a few days.
> >
> > Hypothetical daily KDE builds would also insanely increase the amount of
> > network traffic being used by the mirror pulse and people upgrading
> > their home boxes, so it isn't just a buildd problem.
> 
> Those would need to go into experimental, where no buildd problem
> exists by definition.

http://experimental.ftbfs.de/

(but I agree that the problem is much less important there; and I
personally don't really care about it as much as I do about unstable --
the latter contains packages that should at one point try to get
released, while the former does not)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Hypothetical daily KDE builds would also insanely increase the
> > amount of network traffic being used by the mirror pulse and people
> > upgrading their home boxes, so it isn't just a buildd problem.
> 
> Perhaps it helps, if the buildds for slow systems introduce some delay
> before startng the build, and not building if another architecture
> failed at all. That way if a package is often uploaded or hase obvious
> errors, the build for that is skipped.

We've considered that, but it hasn't happened yet.

> BTW: is s390 one of those slow architectures? I bet IBM dont want to hear
> that?

The problem with s390 is that you can't just go to eBay and buy yourself
an s390; or even if you could, that you would still require some hosting
for it (a fridge-sized machine isn't exactly cheap to host in a data
center, and I'd prefer your electricity bill to contain the machine's
power needs over mine), so we rely on s390 owners to donate us a virtual
machine on their box, which may or may not use the full CPU power of the
machine it's hosted on.

The same isn't true for (e.g.) m68k, which results in the latter being
better supported (in some ways, such as one of the m68k buildd hosts
(jt7) having 256M of RAM and 120G of disk space) than s390.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> 
> > In article <[EMAIL PROTECTED]> you wrote:
> >> Hypothetical daily KDE builds would also insanely increase the amount of
> >> network traffic being used by the mirror pulse and people upgrading
> >> their home boxes, so it isn't just a buildd problem.
> >
> > Perhaps it helps, if the buildds for slow systems introduce some delay
> > before startng the build, and not building if another architecture failed at
> > all. That way if a package is often uploaded or hase obvious errors, the
> > build for that is skipped.
> 
> What would help save many hours on slow systems is having a script
> automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources
> according to Build-Depends to prevent useless buildd attempts and
> failures and manual work to retry them.
> 
> An attempt to build something big can take 3-4 hours to install
> Build-Depends, see they aren't sufficient and to purge them again.

s/something big/something with lots of build-dependencies/

There are small KDE applications that require most of the KDE dependency
chain to be installed, while on the other hand XFree86's build
dependency list is (relatively) small.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 08:48:48PM +1300, Nick Phillips wrote:
> Running such a system in parallel with the current systems (and comparing
> the outputs) might be a good test for gcc-as-cross-compiler, then...

And a hell of a lot of work. You can't just create checksums of the
resulting binaries and compare those; it's not as if any difference
between the two compiled binaries would constitute an error...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 11:46:37PM -0500, Kevin Mark wrote:
> On Mon, Feb 21, 2005 at 04:30:27PM +0100, Wouter Verhelst wrote:
> > There are small KDE applications that require most of the KDE dependency
> > chain to be installed, while on the other hand XFree86's build
> > dependency list is (relatively) small.
> 
> would it make sense to examine the queue to see if any packages have
> similar build dependencies and then move them to the top of the queue so
> they build immediately after the current one?
> or to re-sequence the queue to group package with similar build
> dependencies.

That wouldn't necessary help; not all architectures (especially not the
slower ones) build all packages on the same host.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote:
> Is the problem that you use apt-get to install the current version, and 
> then check what you got? Because you can't tell apt-get to install
> at least version X else fail?

Yes, that's how it works currently.

Since this also makes autobuilding experimental harder, work is being
done to use ``apt-cache policy'' output to determine whether the right
version of a package is available and break off if not, but it's still
got some bugs (including situations where the build is broken off
because sbuild (incorrectly) thinks the right version of a package isn't
available).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> Maybe we should pick up on Petter's suggestion of stricter buildd 
> requirements. 
> Maybe we should only build base and essential packages for the minor 
> architectures [ after, apt-source is there for everybody to go further ].

Debian is not a source-based distribution. If people want to compile
their own packages, they usually go to one of the BSD's or Gentoo.

In the mean time, our users expect to be able to run 'apt-get install'
and be done with it. We should not break that expectation, because that
would not be in the interest of our users; we should ensure that all
software our users would want to run is available.

I agree that we should not continue to provide software for outdated
hardware platforms just for the sake of it; but as it is, there are
still people interested in m68k (some hobbyists, some embedded
developers, some who just use their old trusty hardware as their home
firewall, etc) and, I'm sure, other currently less-used hardware, so as
long as a port doesn't continually stall the release (which none
currently does; there are occasionally problems, but that happens in
every major undertaking), I see no reason to drop any port.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Mon, Feb 21, 2005 at 08:54:36PM -0800, Thomas Bushnell BSG wrote:
> Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
> > - cpu cycles (witness Wouter's request to compile big packages
> > rarely),
> 
> So you're saying that if we dropped the mips buildd's we'd have more
> cycles for other archs?

No, he's saying that if we dropped the slower architectures we'd be able
to do more frequent updates of large packages, such as KDE.

However, this is false. You'd get
* Angry mirror administrators that don't like the fact that users now
  have to download a *much* larger amount of data every day for their
  daily updates, thus eating a larger part of their bandwidth,
* Angry users who, like me, have a traffic quota on their Internet
  connection and who'd get problems staying within the quota if they
  want to keep up with unstable,
* Problems keeping track of all those versions, and the relation to when
  bugs were fixed (there are always users who do not have the latest
  version of a package installed and still file bugs).
* Problems with your own development pace, because you'd be spending
  more time on performing package builds and making sure they get
  updated correctly than you'd be spending on the improvement of those
  packages.

As I said before, this is not just a buildd problem, it's a sensible
approach to maintaining large packages in general; and if you as the
maintainer of a large package really made a stupid mistake and need to
upload a package within two hours after the previous one, then so be it.
We only request that you try to avoid it as much as possible.

> > - security response time (more builds to do)
> 
> Which DSAs came out later than they should have because of this
> supposed delay?  Nor could this possibly slow release.

In fairness, this is not just a fairy tale. DSA's are sent out for all
architectures at once; if a package requires two days to build on the
slower architectures (there are packages for which this is true), then
the DSA will take two days to be prepared. I should note that security
builds are given priority, however, and are done on the fastest machines
in the architecture's buildd pool.

That said, your statement that it could not slow release is, of course,
true.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 11:23:51PM +1100, Hamish Moffatt wrote:
> Thanks for the explanation Wouter. That sounds like a big improvement.
> 
> By the way, does this duplicate the functionality of 'apt-get build-dep'?

Possibly. Sbuild, however, predates the implementation of 'apt-get
build-dep', so it's always had its own build-depends parsing code. For
reference, sbuild is the component in buildd that fetches the source,
installs build-dependencies, and does the actual build.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 03:07:54PM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > Since this also makes autobuilding experimental harder, work is being
> > done to use ``apt-cache policy'' output to determine whether the right
> > version of a package is available and break off if not, but it's still
> > got some bugs (including situations where the build is broken off
> > because sbuild (incorrectly) thinks the right version of a package isn't
> > available).
> apt-get build-dep should be improved to be buildd useable
> instead.

If you don't have patches, don't tell me how to do things.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390, ...

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 05:43:43PM +0100, Goswin von Brederlow wrote:
> I can always tell you how to do things and you never have to
> listen. But my opinion stands that improving apt-get is the right
> thing to do, not having two divergent systems.

sbuild includes some centralized build-dependency override system which
would be a bad idea to use with apt-get, but which is part of its
build-dependency parsing code.

How you want to merge the two considering the above is a mystery to me
:-)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: amd64 is already the 2nd most important arch (WasRe: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])

[Wouter Verhelst]

On Tue, Feb 22, 2005 at 10:57:06PM -0600, Ron Johnson wrote:
> On Tue, 2005-02-22 at 22:25 -0500, Glenn Maynard wrote:
> > On Wed, Feb 23, 2005 at 03:08:11AM +, Dirk Eddelbuettel wrote:
> [snip]
> > Oops.  You jumped from "second most common" to "second most important", as
> > if they're synonymous.  Maybe they are to some people, but that's not at all
> > beyond debate: AMD64 will probably be supported by all serious 
> > distributions,
> > while Debian is, from what I recall, the *only* way to get a sensible Unix
> > installation on many of the less common systems.
> 
> NetBSD?

'sensible'



That said, NetBSD often is not a good option, because they are mainly a
source-based operating system whereas Debian is not. This is not to say
that Debian is better than NetBSD, but both source-based and
binary-based operating systems have their merits.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: the ongoing xfree86 buildd saga

[Wouter Verhelst]

On Wed, Feb 23, 2005 at 09:17:59PM +0100, Adeodato Simó wrote:
> * Thomas Bushnell BSG [Wed, 23 Feb 2005 12:13:42 -0800]:
> 
> > Do the buildd people read this list?  How do we get this cleaned up?
> 
>   That's not relevant, really. What matters is if they read their logs,
>   and they certainly do.

Indeed. The logs you see on buildd.debian.org arrive there by mail; they
are also sent to the buildd admin, because every build requires some
manual action to be performed (signing the .changes file for a
successful build, telling the autobuilder what to do with an
unsuccessful build).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: the ongoing xfree86 buildd saga

[Wouter Verhelst]

On Wed, Feb 23, 2005 at 12:22:59PM -0800, Thomas Bushnell BSG wrote:
> Moreover, because it seems to be extremely difficult to know who
> manages which buildd's and get responses from them,

Have you tried @buildd.debian.org?

> I suspect that once it's cleaned up the fastest way to get my package
> rebuilt with a non-corrupted chroot will not be to ask the buildd
> people to requeue it, but instead to just do another upload to trigger
> a recompile.

That won't help, especially not in this case. Those who manage the
autobuilder are best suited to know when the autobuilder will be fixed,
since they are the ones who have to clean up...

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: the ongoing xfree86 buildd saga

[Wouter Verhelst]

On Wed, Feb 23, 2005 at 12:41:46PM -0800, Thomas Bushnell BSG wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> > That won't help, especially not in this case. Those who manage the
> > autobuilder are best suited to know when the autobuilder will be fixed,
> > since they are the ones who have to clean up...
> 
> What I'm saying is that once it's cleaned up, I have two options:
> 
> * ask for my package to be requeued;
> * do another upload.
> 
> And I'm almost certain that the latter option is faster, and that the
> former option will have an unpredictable delay of up to a week.

What I'm saying is that the delay is likely in cleaning up, not
necessarily in requeueing. Hence, your upload will likely break again,
in exactly the same way it did before.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Tips wanted for debugging and testing Debian

[Wouter Verhelst]

On Thu, Feb 24, 2005 at 08:42:05PM +0100, Sascha Berkenkamp wrote:
> Hi,
> 
> I want to help the debian team and I also read  debian.org/devel ! So I
> think I would like to help testing and debugging the debian system in
> order to help to fix some bugs in some programs or debian sepcific
> stuff. I'm not sure if I'm able to do this with mit taks but I'll try
> and learn.
> I've never done something like this, and so I need some tips.
> I don't know how to start! Do I need a second Debian Linux for testing
> on my disk?

No. You can do that with your 'main' Debian installation. Helping out is
real simple: install the 'reportbug' package, and whenever you find
something that isn't quite right, use reportbug to report the bug.
Include as many information as you can in the bug, and be prepared to
answer any questions the maintainer may have. That's already a great
start.

If you want to take this one step further, actually trying to crash an
application in a reproducible way, or trying to narrow down a bug to a
specific set of actions can be really helpful as well; for instance, if
there's a bug that says something like 'If I run this application, it
sometimes segfaults when I close it', and you can narrow it down to 'if
you run it, and use this and this and that option and /then/ close it,
it will segfault', that's very nice.

You can browse our bug database at . A good way
to start is to search for any bugs in software you regularly use, and to
see if you can help out.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic building of (parts of) the archive

[Wouter Verhelst]

On Sat, Feb 26, 2005 at 10:00:32PM +0100, Goswin von Brederlow wrote:
> Its buildd specific. If its queue is empty it contacts wanna-build and
> puts the new packages into the queue. I can't remeber the filename but
> that should be easy to see from the source.

~buildd/build/REDO

Format:

_ 

If there's a file like that when buildd starts, it will call sbuild with
those packages. It is safe to edit the file when sbuild is running, or
to create it if buildd is running and the file isn't there (that's what
buildd-mail does if you send a failed reply with "retry", or a
should-build reply with "ok" as the command)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]µ

[Wouter Verhelst]

On Sun, Feb 27, 2005 at 11:08:14AM -0500, Rudy Godoy wrote:
> On 22/02/2005 at 10:11 Wouter Verhelst wrote...
>  
> > I agree that we should not continue to provide software for outdated
> > hardware platforms just for the sake of it; but as it is, there are
> > still people interested in m68k (some hobbyists, some embedded
> > developers, some who just use their old trusty hardware as their home
> > firewall, etc) and, I'm sure, other currently less-used hardware, so as
> > long as a port doesn't continually stall the release (which none
> > currently does; there are occasionally problems, but that happens in
> > every major undertaking), I see no reason to drop any port.
> 
> Regarding this issue I was thinking about it since I've faced in a
> situation where a package[0] I maintain does have "high" hardware
> requirements, which led me to think if it is really wise to have it
> with "arch: any" since probably in some arches it would not ever be
> installed/used, or even if case it will run really slow or even crash
> and the user will not enjoy the software as was intended by upstream,
[...]
> I don't know much about buildd infrastructure[1], if such thing was
> proposed or commented before (didn't check archives),

It has been brought up before a few times on the m68k mailinglists (and
perhaps others too, but I don't follow those). The answer is pretty
complex. In short: don't remove an architecture from your Architecture:
line unless it
* crashes,
* is something that requires so much CPU time that using it on hardware
  of which a >100Mhz variant does not exist /will/ make the system trash
  and be generally unusable until you hit the reset button,
or
* does not compile

I once wrote the long story in my blog; you can find it at
<http://www.livejournal.com/users/wouterverhelst/2742.html> (it being a
rant in reply to people shouting 'we should drop foo from Debian/m68k!',
it doesn't entirely fit into this thread, but apart from that, it
explains it).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 04:42:54AM -0600, Peter Samuelson wrote:
> 
> [Goswin von Brederlow]
> > Which also avoids that packages will be unavailable on every new
> > architecture debian introduces because the maintainer has to adjust
> > the Architecture: line.
> 
> I suppose it'd be nice to be able to use !foo in the Architecture: line
> for cases where something is known not to be supportable on a
> particular small subset of arches, through toolchain bugs or whatever.

Congratulations, you've just found #112325 :-)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian "Sarge" Support

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 01:47:18PM -0800, Hans Reiser wrote:
> Can you folks at Debian tell me whether we are supported in Sarge?

The stock kernels support Reiser3, but not Reiser4. Reiser4 support
packages are available, however.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> 
> > [Goswin von Brederlow]
> >> Which also avoids that packages will be unavailable on every new
> >> architecture debian introduces because the maintainer has to adjust
> >> the Architecture: line.
> >
> > I suppose it'd be nice to be able to use !foo in the Architecture: line
> > for cases where something is known not to be supportable on a
> > particular small subset of arches, through toolchain bugs or whatever.
> 
> As a sidenote, wanna-build and buildd completly ignore the
> architecture line (apart from arch:all) and build packages anyway.

Well, somewhat :-)

they /attempt/ the build. sbuild will detect that it is not actually a
package for this architecture, and will break it off right when the
source package is extracted.

> Anything in the control file is purely informative to the buildd admin
> at this point.

No, sbuild does check more things.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Tue, Mar 01, 2005 at 01:28:58AM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
> >> Peter Samuelson <[EMAIL PROTECTED]> writes:
> >> 
> >> > [Goswin von Brederlow]
> >> >> Which also avoids that packages will be unavailable on every new
> >> >> architecture debian introduces because the maintainer has to adjust
> >> >> the Architecture: line.
> >> >
> >> > I suppose it'd be nice to be able to use !foo in the Architecture: line
> >> > for cases where something is known not to be supportable on a
> >> > particular small subset of arches, through toolchain bugs or whatever.
> >> 
> >> As a sidenote, wanna-build and buildd completly ignore the
> >> architecture line (apart from arch:all) and build packages anyway.
> >
> > Well, somewhat :-)
> >
> > they /attempt/ the build. sbuild will detect that it is not actually a
> > package for this architecture, and will break it off right when the
> > source package is extracted.
> 
> It does? How does that work for packages with only a minimal control
> file that generate a full contol file during build?

Such packages need to make sure their initial control file contains
enough information about the architectures a package can be built on
anyway if they want dpkg-buildpackage to run successfully.

> I see the Arch check of the dsc file in line 742-484 but that is very
> unreliable. Anything I missed?

Haven't looked at the source, only know the behaviour when a
foreign architecture's package's build is attempted. Something like

Architecture not in control file: i386 -- skipped

or so.

> >> Anything in the control file is purely informative to the buildd admin
> >> at this point.
> >
> > No, sbuild does check more things.
> 
> Ok, slightly exagerated, but a lot of packages would get build by sbuild
> wrongfully if it weren't for packages-arch-specific in wanna-build.

'some', rather than 'a lot'; but apart from that, correct.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: combining fakeroot and distcc/SSH

[Wouter Verhelst]

Op za, 05-03-2005 te 18:55 +0100, schreef martin f krafft:
> also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.03.05.1840 +0100]:
> > ssh -i usualy helps.
> 
> not if you cannot influence how SSH is called.

TTBOMK, distcc is free software.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: grass and Packages-arch-specific

[Wouter Verhelst]

Op za, 05-03-2005 te 14:26 +0100, schreef Thiemo Seufer:
> Steve Halasz wrote:
> > Hi,
> > 
> > I've sent a few emails over the last month to [EMAIL PROTECTED] and
> > [EMAIL PROTECTED] requesting that grass be removed from
> > packages-arch-specific. But my pleas have fallen on deaf ears, or
> > perhaps overzealous spam filters. Are you guys out there? Is there
> > anyone else who can make this change for me?
> 
> File a bug against the ftp.debian.org pseudopackage.

Packages-arch-specific has nothing to do with ftp.d.o

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Key management using a USB key

[Wouter Verhelst]

Op di, 08-03-2005 te 14:58 +, schreef Ben Hill:
> On Tue, 2005-03-08 at 00:46 +0100, David HÃrdeman wrote:
> > first of all, this might be slightly off-topic for the debian-devel 
> > list, but I've got the impression that it's already been solved by some 
> > DD's and might prove interesting to others (including non-DD's such as 
> > me).
> 
> I use a very small USB key for my gnupg and ssh keys. I had created
> the .gnupg and .ssh directories in my home a long time ago, so I
> formatted the USB device as ext2, and copied the two directories to the
> USB device as ssh and gnupg.
> 
> In my home directory I create a symlink for /media/usbkey/ssh -> ~/.ssh
> and /media/usbkey/gnupg -> ~/.gnupg.
> 
> So, when I stick the dongle into the USB slot, the drive is
> automatically mounted, and the symlinks point to my real key
> directories.
> 
> When the key is out of the machine, my keys are safe offline.

This is also approximately how I manage this (or did, my key broke
yesterday and I haven't got a new one yet).

The only difference is that, rather than symlinking ~/.gnupg, I symlink
~/.gnupg/secring.gpg; that way, I can mount the USB key read-only, which
allows me to safely remove it while still mounted; my trustdb and public
keyring are synchronized in other ways.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

[Wouter Verhelst]

Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> How much would it help with the current problems if we just picked 3
> arches(mipsel, s390, ???) 

This argument has been brought up so many times by now that I'm amazed
people /still/ try it.

The answer is, simply, 'not'. Go learn to use google if you want to know
why.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

[Wouter Verhelst]

Op di, 08-03-2005 te 14:36 -0800, schreef Clint Byrum:
> On Tue, 2005-03-08 at 22:22 +0100, Wouter Verhelst wrote:
> > Op di, 08-03-2005 te 10:33 -0800, schreef Clint Byrum:
> > > How much would it help with the current problems if we just picked 3
> > > arches(mipsel, s390, ???) 
> > 
> > This argument has been brought up so many times by now that I'm amazed
> > people /still/ try it.
> > 
> > The answer is, simply, 'not'. Go learn to use google if you want to know
> > why.
> > 
> 
> Good idea.. google is a great tool for this sort of thing. I put this
> one in:
> 
> site:lists.debian.org architectures sarge debian-devel
> 
> Lets see what some of the best hits were...
> 
> http://lists.debian.org/debian-devel-announce/2004/08/msg00017.html
> 
> "- Toolchain fixes.  A misbuilt gcc-3.3 package on alpha left us with a
>broken compiler in sarge -- which aside from being release-critical,
>made it rather hard to build packages uploaded to the
>testing-proposed-updates queue.  This is being addressed as we speak,
>though with a little more pain than we'd like; by dinstall on the 29th,
>we should have a working gcc on all architectures in sarge."

So, alpha broke here. Which didn't stall the release -- the main problem
back then was testing-proposed-updates.

> http://lists.debian.org/debian-devel/2003/05/msg01368.html
> 
> "To fix the ptrace bug, the s390 and mips architectures rolled the ptrace
> security fix into kernel-patch-2.4.17-s390 and
> kernel-patch-2.4.{17,19}-mips.  This makes things even worse, because if
> kernel-source-2.4.{17,19} are patched to contain the fix, it will almost
> certainly make these architectures' kernel images fail to build because of
> patch conflicts, and require that the -patch packages be updated _again_ to
> undo this."

So, mips and s390 broke here. Which didn't stall the release -- we
weren't close to release yet, back then.

> http://lists.debian.org/debian-devel/2004/04/msg01623.html
> 
> "However, after fighting for months on an update for CAN-2004-0077 for
> all architectures and all kernels, it was a lot easier to provide
> updates for the CAN-2004-0109 vulnerability."

so, the way kernels were being maintained wasn't exactly optimal back
then.

> Nope.. nope.. there aren't too many architectures! You're right.

Shit happens. It's true that having more architectures require us to do
more work in some areas. It's not true that this has ever effectively
stalled our release, however, and it certainly does not do so now -- in
other words, it does not 'help with the current problems' to just pick a
few architectures and drop the rest.

This horse has been beaten to death and beyond. Please.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automatic building of (parts of) the archive

[Wouter Verhelst]

Op di, 08-03-2005 te 23:01 +0100, schreef Frank KÃster:
> Hi,
> 
> I am still struggling with the setup of a local buildd for testing
> purposes.  I was able to manually build a package, using the command
> 
> [EMAIL PROTECTED]:~$ sbuild -d unstable -v hello_2.1.1-4
> 
> However, after I put a package into build/REDO:
> 
> [EMAIL PROTECTED]:~$ cat build/REDO 
> acl2_2.9.1-1 unstable
> 
> and start buildd, I get:
> 
> [EMAIL PROTECTED]:~$ cat daemon.log 
> Mar  8 23:44:22 buildd: Daemon started. (pid=8002)
> Mar  8 23:44:31 buildd: Updated source-dependencies
> Mar  8 23:48:48 buildd: Updated apt sources for unstable
> Mar  8 23:48:49 buildd: Autocleaned apt cache directory for unstable
> Mar  8 23:48:49 buildd: Starting build (dist=unstable) of:
> Mar  8 23:48:49 buildd: acl2_2.9.1-1
> Bad distribution
> Mar  8 23:48:49 buildd: sbuild failed with status 2/0
> Mar  8 23:48:49 buildd: Assuming all packages unbuilt and adding to REDO:
> Mar  8 23:48:49 buildd: acl2_2.9.1-1
> Mar  8 23:48:49 buildd: Build finished.
> 
> This is repeated 3 times, then I get
> 
> Mar  8 23:49:06 buildd: sbuild now failed 3 times in a row; going to sleep
> Mar  8 23:49:06 buildd: sendmail failed (exit status 1/0)
> 
> (I guess I can find out the sendmail problem myself, didn't look at it
> yet).  Why does it say "bad distribution"?  I have chroots at 
> 
> $ ls -l ~buildd/chroot*
> lrwxrwxrwx  1 buildd buildd   12 Mar  8 22:57 /home/buildd/chroot-sid -> 
> chroots/sid/
> lrwxrwxrwx  1 buildd buildd   12 Mar  8 23:03 /home/buildd/chroot-unstable -> 
> chroots/sid/

These should be in ~buildd/build. Sbuild will find them if they're a
subdirectory of the current working directory, and buildd changes that
to that directory.

I'm not sure whether this is actually the cause of your problem, though.
If not, I'm sure I'll hear about it ;-)

> /home/buildd/chroots:
> total 4
> drwxr-xr-x  21 root root 4096 Mar  5 22:03 sid
> 
> The buildd is running as user buildd, not as root, but that is how it
> should be, isn't it?

Yes, but it needs passwordless sudo access.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune

Re: mipsel drop / buildd situation Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space]

[Wouter Verhelst]

Op di, 08-03-2005 te 17:58 -0500, schreef Joey Hess:
> Wouter Verhelst wrote:
> > This argument has been brought up so many times by now that I'm amazed
> > people /still/ try it.
> > 
> > The answer is, simply, 'not'. Go learn to use google if you want to know
> > why.
> 
> You're ignoring people arguing the other side of the issue.

No, I'm not.

> For example,
> in <[EMAIL PROTECTED]>, I give some very real examples
> of how having to support many architectures has redireted a lot of my
> time away from other activities that could have sped up or improved the
> release.

I very well remember that mail. The key word in Clint's mail that
prompted my reply was 'current' (problems). d-i has been ported to all
our architectures now, which required a lot of work, and doing a d-i
release still requires quite some work to synchronise that among all our
architectures, I presume. However, the point is that having many
architectures does not effectively stall our release today.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]