Re: Re: LCC and blobs

[Olaf van der Spek]

Goswin von Brederlow writes:
> Because the former works after installing the deb without the user
> ever doing anything about firmware. How do you even know there is
> firmware? Maybe it is all hardcoded into the chip? Without taking the
> hardware apart you can't know. Call me ignorant but what I don't see
> does not exist describes perfectly how it should be treated.
> In the later case the user actively has to download the firmware from
> somewhere and add it to his system. The extra files taints his
> filesystems and makes it less free. For example you can't just make a
> live CD out of it anymore because the non-free firmware file makes it
> not DFSG free.
Not free in what sense?
What can the user not do, that he can do if the firmware was already on 
the device?

Re: RFC: common database policy/infrastracture

[Olaf van der Spek]

On Thu, 16 Dec 2004 08:27:20 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> On Wed, 15 Dec 2004, sean finney wrote:
> Yes, but I do not want to store the password *anywhere* - it could even
> be removed from debconf database because it makes no sense to store it
> in case the local maintainer changes the database password the value
> is absolutely useless in any config file or debconf database.  Moreover
> it is even a security risk to store a password in an additional place.

If it's only readable by root, how much of a risk is it really?

Re: RFC: common database policy/infrastracture

[Olaf van der Spek]

On Thu, 16 Dec 2004 14:22:25 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
> 
> >> Yes, but I do not want to store the password *anywhere* - it could even
> >> be removed from debconf database because it makes no sense to store it
> >> in case the local maintainer changes the database password the value
> >> is absolutely useless in any config file or debconf database.  Moreover
> >> it is even a security risk to store a password in an additional place.
> >
> > If it's only readable by root, how much of a risk is it really?
> Why should I use md5 passwords if they are stored in /etc/shadow which
> is only readable by root?

Because system passwords aren't 'needed' by any applications to
authenticate themselves to the system, while database passwords are.

> IMHO, it is a good idea not to store passwords in clear text if there
> is no reason to do so.  If a temporary file at install time suffices
> I just prefer this over permanent storage.

True, but how many database apps work without storing the password?

Re: RFC: common database policy/infrastracture

[Olaf van der Spek]

On Thu, 16 Dec 2004 14:55:29 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
> 
> > Because system passwords aren't 'needed' by any applications to
> > authenticate themselves to the system, while database passwords are.
> No, they are not needed in the file system.  They are needed inside
> the database and they are save there (assumed that the database server

safe?
Yes, but that's the other side of the authentication end. This is
about the client, not the server.

> has no bugs).
> 
> > True, but how many database apps work without storing the password?
> At least these that do authentification directly against the database
> should not store their passwords in an extra file.  This is the case
> for the application I'm currently working on (GnuMed) where the
> client does the authentication via user interaction.

Is that the majority or the minority of applications?
Take for example a web application like a forum. It requires the
password so it can connect to the database. It can't/won't ask the
password from the user.

Re: RFC: common database policy/infrastracture

[Olaf van der Spek]

On Thu, 16 Dec 2004 15:34:35 +0100 (CET), Andreas Tille <[EMAIL PROTECTED]> 
wrote:
> On Thu, 16 Dec 2004, Olaf van der Spek wrote:
> 
> > Is that the majority or the minority of applications?
> > Take for example a web application like a forum. It requires the
> > password so it can connect to the database. It can't/won't ask the
> > password from the user.
> Can you tell me any reason why I should store a clear text password
> in a text file for *my* application only because *other* applications
> would require this?

Nope.
But for apps that do require that, it makes sense to do it so you can
avoid asking the password multiple times in the case of upgrades or
other things.

Re: RFC: common database policy/infrastracture

[Olaf van der Spek]

On Thu, 16 Dec 2004 08:51:32 -0600, Steve Greenland
<[EMAIL PROTECTED]> wrote:
> On 16-Dec-04, 08:04 (CST), Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > Take for example a web application like a forum. It requires the
> > password so it can connect to the database. It can't/won't ask the
> > password from the user.
> 
> But there is (or at least, should be) a specific user for that forum
> application, with the minimum of rights needed for that application
> (e.g. SELECT and UPDATE) in a single specific database. You're talking
> about a DB *admin* password.

Ah, k. It makes less/no sense to store that password.
But I wonder, is there no way to use the 'power' of the root account
to do such DB administration without password then?

Re: GPL and LGPL issues for LCC, or lack thereof

[Olaf van der Spek]

On Fri, 17 Dec 2004 12:26:01 -0800, Bruce Perens <[EMAIL PROTECTED]> wrote:
> The LGPL requires that the creator of a derivative work provide the object
> code for relinking, and not prohibit relinking and reverse engineering. It
> does not, however, require that creator to take other necessary steps to
> make relinking possible, such as providing a JPEG loading tool for the FLASH

Is that really JPEG? Or JTAG?

Whereabouts of missing maintainer shiju@infovillage.net (Shiju p. Nair)

[Olaf van der Spek]

Hi,
Does anyone know about the whereabouts of the mrtg maintainer, Shiju p. 
Nair?

The package has bugs that are multiple years old and no recent uploads 
by the maintainer.

http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=mrtg
--
Olaf van der Spek
http://xccu.sf.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Azureus magnet-link functionality

[Olaf van der Spek]

On 11/15/05, Ken Bloom <[EMAIL PROTECTED]> wrote:
> Shaun Jackman wrote:
> > In the following email Chris suggests that I add support for bit
> > torrent magnet:// URLs under Gnome2 in the Azureus package by setting
> > the gconftool-2 parameter /desktop/gnome/url-handlers/magnet/command
> > to call Azureus. This seems like a pretty reasonable thing to do, but
> > it must be done for each user that runs Azureus. Since Azureus is a
> > Java program, /usr/bin/azureus is already a shell script. Should I add
> > a couple lines here that call gconftool-2? Any other suggestions on
> > how to accomplish this same task?
>
> A configuration option would be nice so that you don't go stealing our
> favorite protocol handlers just because we decide to try one out.

I think the environment should handle such configuration and not each
individual app itself.
I'm not familiar with gnome internals, but I think command should be a
directory where each individual app can register (and unregister) it's
own handler.
It's then up to the environment to provide a means to choose the
prefered handler.

Re: dpkg-sig support wanted?

[Olaf van der Spek]

On 11/23/05, Marc Haber <[EMAIL PROTECTED]> wrote:
> >In the archive, 525 out of 283283 .deb's are dpkg-sig'd (0.19%). There
> >are 8 distinct keys used for those 525 .deb's, seven of which correspond
> >to DD's[1].
>
> So, most of the DD's do not care about security at all. Why does
> Debian have a reputation of being so secure?

Security is more than package signatures.

Re: dpkg-sig support wanted?

[Olaf van der Spek]

On 11/23/05, John Hasler <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek writes:
> > Security is more than package signatures.
>
> What is your specific proposal?

I don't have one. But I don't see how that's relevant.

Re: dpkg-sig support wanted?

[Olaf van der Spek]

On 11/25/05, Matthew Palmer <[EMAIL PROTECTED]> wrote:
> Of course, using the signature on the .changes to verify the .debs
> independent from the archive at some later date is a nice side-benefit, but
> one which suffers from the same key-lifetime issues as in-deb signatures,

What exactly is this key lifetime issue?
Is it a cryptographic issue?

> and since the .changes from autobuilt uploads aren't publically available
> (apparently d-d-$arch-changes isn't archived, from info previously posted in
> this thread) that method of package authentication isn't going to be 100%
> reliable anyway.

Re: net-tools maintenance status

[Olaf van der Spek]

On 8/2/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> Hi,
>
> What's the maintenance status of the net-tools package?
> It has 88 bugs:
> Serious policy violations - outstanding (1 bug)
> Important bugs - outstanding (8 bugs)
> Normal bugs - outstanding (38 bugs)
> Minor bugs - outstanding (9 bugs)
> Wishlist items - outstanding (32 bugs)
>
> A lot older than a year, 17 with patch a lot even without a single response.
>
> I emailed a patch to Bernd two months ago but I'm still waiting for a 
> response.

And nearly four months later, the package has 92 bugs, 16 with patch
and a lot even without a single response.

I still don't have any idea what Bernd, the maintainer, thinks
(himself) about my patch.

Olaf

Re: net-tools maintenance status

[Olaf van der Spek]

On 11/29/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 29, 2005 at 06:08:23PM +0100, Olaf van der Spek wrote:
> > And nearly four months later, the package has 92 bugs, 16 with patch
> > and a lot even without a single response.
>
> This is not true.

What part isn't?

> Stop bothering me.

Why?

> Most of the patches are not valid.

Shouldn't the patch tag be removed and an explanation given then?

> Please work on the bugs which are tagged as help needed.

Why would I do that while I'm waiting for the status of the patch I
already wrote?

Olaf

Re: sarge uninstallable !?!

[Olaf van der Spek]

On 12/4/05, A Mennucc <[EMAIL PROTECTED]> wrote:
> ops
>
> turns out that in both cases they where using a pre-release, namely,
> .disk/info contains
>
> Debian GNU/Linux testing "Sarge" - Official Snapshot i386 Binary-1
> (20041121)

Apparently that wasn't obvious.
Shouldn't it be made more clear what version is being used?

Re: apt PARALLELISM

[Olaf van der Spek]

On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote:
> Example: (/etc/apt/sources.list)
> deb http://ftp.en.debian.org/debian main stable contrib non-free
> deb http://ftp.de.debian.org/debian main stable contrib non-free
>
> in this case the stable packages will be ONLY downloaded from first server
> from the list ...

And what is the problem?

Re: apt PARALLELISM

[Olaf van der Spek]

On 12/5/05, Joe Smith <[EMAIL PROTECTED]> wrote:
>
> "Olaf van der Spek" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > On 12/5/05, Ivan Adams <[EMAIL PROTECTED]> wrote:
> >> Example: (/etc/apt/sources.list)
> >> deb http://ftp.en.debian.org/debian main stable contrib non-free
> >> deb http://ftp.de.debian.org/debian main stable contrib non-free
> >>
> >> in this case the stable packages will be ONLY downloaded from first
> >> server
> >> from the list ...
> >
> > And what is the problem?
>
> This person is requesting parallel downloads from multiple servers. So
> basicly during package download, if there are three full and up-to-date
> mirrors in sources.list, there should be simulatious downloads of different
> packages from all three different mirrors.
> The concept is that in some cases this can noticable improve performance,
> especially whith sites that bandwidth throtle, or have some other sort of
> bottleneck.

Do you mean throttling at the mirror site? Or between the mirror and
the end-user?
If the global (world) overhead of parallel downloads increases it may
not be a good idea to do it.

Re: apt PARALLELISM

[Olaf van der Spek]

On 12/12/05, Ivan Adams <[EMAIL PROTECTED]> wrote:
>
>
> > As far as I read the proposal, it is about downloading _different_
> > files from different mirrors - if you have 25 packages to get for your
> > 'apt-get update' operation, download 5 packages from each of 5
> > different servers, with one connection to each server active at a
> > time.
> >
>
> That is what I mean ...

But with HTTP pipelining you can download all 25 files with only a
single TCP connection.
Using 5 TCP connections (to different servers) instead of 1 simply
means you're using more resources for yourself.

Re: apt PARALLELISM

[Olaf van der Spek]

On 12/13/05, Henning Makholm <[EMAIL PROTECTED]> wrote:
> Assume a situation where mirror bandwidth is the limiting factor, and
> imagine a world with 3 mirrors.  Say that during a certain time of the
> day 600 users each minute start to download updated x.org packages.
> Either they can do their download sequentially, choosing a random
> server; then their download will be finished in 15 minutes, and each
> server has a more-or-less constant 600/3*15 = 3000 connections
> active. Alternatively each user can spread his load over all three
> servers; his download now takes 5 minutes, and each server _still_
> sees 600*5 = 3000 active connections at any time. Thus _all_ users get

That's not true. Suppose you've only got 3 users. If each user
connects to one (different) mirror, he gets 1/1 of that mirror's
bandwidth. If each user connects to each mirror, he only gets 1/3 of
that mirror's bandwidth.

Re: congratulations to our ftp-master team

[Olaf van der Spek]

On 12/14/05, Anand Kumria <[EMAIL PROTECTED]> wrote:
> [1]: As I write this 79 NEW packages, 85 total.

With only four entries more than a month old I think it's doing fine,
especially compared to other maintainers/teams that have bugs open
months or years.

Re: congratulations to our ftp-master team

[Olaf van der Spek]

On 12/14/05, Nathanael Nerode <[EMAIL PROTECTED]> wrote:

> Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1
> month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1
> month); if there's something wrong with each of these packages, the
> packager should know by now.  Maybe in some cases he does, but in others it
> appears clear that the packager doesn't know.

Shouldn't information like what's wrong be posted in public so others know too?

Re: apt PARALLELISM

[Olaf van der Spek]

On 13 Dec 2005 15:56:00 +0100, Claus Färber <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek <[EMAIL PROTECTED]> schrieb/wrote:
> > That's not true. Suppose you've only got 3 users. If each user
> > connects to one (different) mirror, he gets 1/1 of that mirror's
> > bandwidth. If each user connects to each mirror, he only gets 1/3 of
> > that mirror's bandwidth.
>
> They could get 1/1 of each server (total 3/1) if they connect at
> different times.

True if you assume the users have three times the bandwidth of a
mirror (on average). A 'bit' unlikely.

> With three users, this needs coordination (which makes
> the effect useless). With several hundred, it only needs statistics.

Again only if the bottleneck is the mirror's bandwidth.

Re: net-tools maintenance status

[Olaf van der Spek]

On 11/29/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> On 11/29/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 29, 2005 at 06:08:23PM +0100, Olaf van der Spek wrote:
> > > And nearly four months later, the package has 92 bugs, 16 with patch
> > > and a lot even without a single response.
> >
> > This is not true.
>
> What part isn't?
>
> > Stop bothering me.
>
> Why?
>
> > Most of the patches are not valid.
>
> Shouldn't the patch tag be removed and an explanation given then?
>
> > Please work on the bugs which are tagged as help needed.
>
> Why would I do that while I'm waiting for the status of the patch I
> already wrote?

Bernd?

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/18/05, Roberto Sanchez <[EMAIL PROTECTED]> wrote:
> I think that the biggest problem is really updates.  Packages like
> XFree86 (no X.org) and Openoffice.org are *huge*.  A simple security
> update to one of those packages causes all subordinate binary packages
> to get a version bump.  That means that if there was a bug in the
> XFree86 driver for video card foo and I use video card bar, I still get
> download a many dozens of MB update.  IIRC, something similar caused a
> major strain on security.debian.org shortly after the Sarge release.
>
> If we focus our energy on anything to reduce bandwidth, it should be
> making apt/dpkg smart enough to only need to grab the single changed
> binary package out of the 50 produced by source package foo, or maybe to
> employ and rsync-like approach.

It would be nice to make it even smarter and grab only the files that
actually changed instead of the entire package.

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 12:34:56PM +0100, Gürkan Sengün wrote:
> > I've run some scripts to find out the size of binary pakcages in debian
> > and how theycould be made smaller, here's the results:
>
> My comments are about the same as on IRC:
>
>  - Disk space is cheap, bandwidth is cheap.
>  - CPU doesn't grow nearly as fast as those three.
>  - Human power grows even slower.
>  - The administrative overhead of transitioning to a new .deb format
>would be huge.

Why would this be huge?
Why is it that hard to plugin another codec?

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 02:56:10PM +0100, Olaf van der Spek wrote:
> > Why would this be huge?
> > Why is it that hard to plugin another codec?
>
> You'd have to rewrite about every single tool in the world handling .debs,
> make up a transition plan and upgrade from that. Not to mention that you'd

Why is the knowledge of how to decode a .deb distributed over so many tools?

> have to make sure it works on all kinds of obscure platforms actually using
> the thing. (And yes, I have used ar and tar to extract debs, and consider it
> a quite useful feature.)

Why would that stop working if you switch compression schemes?
I guess tar is coded to use gzip with -z and bzip2 with -j, but why is
there no generic way to add coders/decoders (codecs) to tar (and other
applications that wish to use compression filters)?

> The .deb format is _fixed_ -- this isn't AVI where you just "plug in another
> codec" and hope it works.

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 08:23:56PM +0100, Olaf van der Spek wrote:
> > Why would that stop working if you switch compression schemes?
> > I guess tar is coded to use gzip with -z and bzip2 with -j, but why is
> > there no generic way to add coders/decoders (codecs) to tar (and other
> > applications that wish to use compression filters)?
>
> Get real. gzip is probably understood by 99.9% of all installed UNIX systems
> in the world, and you cannot possibly hope to get anywhere near that for a
> relatively obscure alternative. (The -j flag to tar is a Debian specific
> extension, BTW -- I'm not sure if the -z flag is a GNU-specific extension,
> but it wouldn't surprise me.)

I guess what I'm asking is, why are tar and other applications using
gzip instead of a generic library that handles all
compression/decompression and can be easily extended.

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/18/05, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 10:15:31PM +0100, Olaf van der Spek wrote:
> > I guess what I'm asking is, why are tar and other applications using
> > gzip instead of a generic library that handles all
> > compression/decompression and can be easily extended.
>
> General complexity, I'd guess. If you want "easily extended", you'll have to
> cope with dynamic, shared libraries -- look to NSS for a case on how evil
> that can get. (And tar is really something you'd like to stay small and
> simple.) Also, having to hunt down the right plug-in module for whatever
> format somebody had the bright idea to use at some point can be a real pain.
> (Ever had to use one of those "codec packs" for Micosoft Windows?)
>
> Besides, UNIX does this a different way, traditionally -- via separate
> programs. "gzip -d file.tar.gz ; tar xf file.tar" gives you most of the same
> functionality, with zero extra complexity. (Try --use-compress-program in GNU
> tar, but that probably doesn't exist in anything else.)

I guess that's even easier. Just use/write a filter that looks at the
header and invoke the right coder/decoder internally.

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/19/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 08:27:36PM +0100, Florian Weimer wrote:
> > * Steinar H. Gunderson:
> >
> > > My comments are about the same as on IRC:
> > >
> > >   - Disk space is cheap, bandwidth is cheap.
> >
> > Depends.  Decent IP service costs a few EUR per gigabyte in most parts
> > of the world.
>
> I wish we could get it that cheap for my day job. What we have to pay
> to get useful bandwidth has more zeros in it.

Are you paying > 10 $/gb?
Where is it that expensive?

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> uncompressor 

Re: apt PARALLELISM

[Olaf van der Spek]

On 12/21/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > Who need PARALELISM and who has a bandwidth of more then 8 MBit?
>
> I have 10240kBit downstream and get way less from security.debian.org.
> Especialy when there is a security release of X or latex.

But parallel downloads won't solve that.

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/21/05, Andrew Suffield <[EMAIL PROTECTED]> wrote:
> > Are you paying > 10 $/gb?
>
> Heck yes, you can't get it that cheap unless you have no SLA (or one
> of those insulting SLAs that come with residential service, claiming
> that it doesn't have to work at all). And you can't get that at all on
> a pipe of any significant size (unless you're big enough to work out a
> peering agreement). We pay per month though, not per byte.

That's unlimited traffic then I assume?
At 1 mbyte/s (average) you'd be paying > 25000 $/month.

But do you actually need very high uptime for very large transfers?

Re: Size matters. Debian binary package stats

[Olaf van der Spek]

On 12/27/05, Michelle Konzack <[EMAIL PROTECTED]> wrote:
> 57.000 US$/month / 10 US$/GB = 5700 GB/month
>
> 5700 GB/month / 30,4 days / 24 h / 3600 sec = 2,22 MByte/second
>
> 2,22 MByte/Second ~ 28 MBit

12.6 bit/byte?

> Because we do not get 34 MBit and we have not a netload
> of 100% 24/7 the price per GByte is around 50 US$/GByte.

True and I didn't know it was that expensive.

Re: net-tools maintenance status

[Olaf van der Spek]

On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote:
> > > > Bernd?
> > >
> > > I dont like the prposed solution, i am looking for a more generic one. The
> >
> > Thanks for the response.
> > In what way would you like it to be more generic?
> >
> > > pressing problem is to display IPV6 netstat on 80char widt correctly 
> > > without
> > > truncation (#254243).
> >
> > That's not possible without dropping entire columns.
> >
> > > I guess this will require some changes to the output formatter, anyway.
> > >
> > > I think i will add a non-formatting/non-truncating scritable output 
> > > instead
> > > of the wide switch, and make netstat on tty observ cols. The question is,
> > > what size to use on non-tty output.
>
> Bernd?

Bernd?

Re: Experimental or unstable.

[Olaf van der Spek]

On 1/5/06, Nicolas François <[EMAIL PROTECTED]> wrote:
> How Debian users can know there is a new version in experimental?
> There are some messages in debian-devel, or blogs on planet, but not all
> users or developers are reading them.
>
> Is there a command that can display the list of packages I'm using with a
> version on experimental higher than the current version on unstable?
>
> (I'm willing to test some experimental packages, but on a case by case
> basis, not by pinning up experimental)

I'd be nice if it's possible to easily install a package from
experimental or unstable (in testing or unstable) once or to track
that section for that package.

Re: net-tools maintenance status

[Olaf van der Spek]

On 12/30/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote:
> > > > > Bernd?
> > > >
> > > > I dont like the prposed solution, i am looking for a more generic one. 
> > > > The
> > >
> > > Thanks for the response.
> > > In what way would you like it to be more generic?
> > >
> > > > pressing problem is to display IPV6 netstat on 80char widt correctly 
> > > > without
> > > > truncation (#254243).
> > >
> > > That's not possible without dropping entire columns.
> > >
> > > > I guess this will require some changes to the output formatter, anyway.
> > > >
> > > > I think i will add a non-formatting/non-truncating scritable output 
> > > > instead
> > > > of the wide switch, and make netstat on tty observ cols. The question 
> > > > is,
> > > > what size to use on non-tty output.
> >
> > Bernd?
>
> Bernd?

Hi Bernd,

Could you please respond to this issue?

Thanks

Olaf

Re: net-tools maintenance status

[Olaf van der Spek]

On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 06, 2006 at 05:03:39PM +0100, Olaf van der Spek wrote:
> > On 12/30/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > > On 12/22/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > > > On 12/16/05, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> > > > > On 12/16/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> > > > > > On Fri, Dec 16, 2005 at 08:03:47PM +0100, Olaf van der Spek wrote:
> > > > > > > Bernd?
> > > > > >
> > > > > > I dont like the prposed solution, i am looking for a more generic 
> > > > > > one. The
> > > > >
> > > > > Thanks for the response.
> > > > > In what way would you like it to be more generic?
> > > > >
> > > > > > pressing problem is to display IPV6 netstat on 80char widt 
> > > > > > correctly without
> > > > > > truncation (#254243).
> > > > >
> > > > > That's not possible without dropping entire columns.
> > > > >
> > > > > > I guess this will require some changes to the output formatter, 
> > > > > > anyway.
> > > > > >
> > > > > > I think i will add a non-formatting/non-truncating scritable output 
> > > > > > instead
> > > > > > of the wide switch, and make netstat on tty observ cols. The 
> > > > > > question is,
> > > > > > what size to use on non-tty output.
> > > >
> > > > Bernd?
> > >
> > > Bernd?
> >
> > Hi Bernd,
> >
> > Could you please respond to this issue?
>
> the last question in this thread was from me.

Really?

> > > > > Thanks for the response.
> > > > > In what way would you like it to be more generic?

> > > > > That's not possible without dropping entire columns.

Re: net-tools maintenance status

[Olaf van der Spek]

On 1/6/06, Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> On Fri, January 6, 2006 17:03, Olaf van der Spek wrote:
> > Hi Bernd,
> >
> > Could you please respond to this issue?
>
> Hello Olaf,
>
> Could you please stop this? You've been asking about this for many times

I'd prefer to, but that doesn't look like a solution.

> now and appearently with no result, so it should occur to you that this
> stragegy does not work.

It does appear to result in some response, but with weeks/months
separation between each one it's a bit 'slow'.

> If you look at Bernd's packages overview
> (http://qa.debian.org/developer.php?login=ecki) you can see that many of

Which column shows that?

> his packages are NMU'ed very regularly. So appearently he doesn't mind
> that. You could prepare an NMU for the bugs you deem important and upload
> it to the delayed queue.

It's a significant change and I'd prefer the maintainer to support the change.
I also have no idea how to do an NMU and I think NMUs are not the
right solution to this problem.

Re: net-tools maintenance status

[Olaf van der Spek]

On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> > So I think you can tell pretty clearly that Bernd has no objection at all
> > to NMU's.
>
> yes, but please not for wishlist bugs. Again: there are bugs open for
> net-tools where help is requested, I would love to have patches for those.
> Generally I am not aware of time critical bugs.
>
> The wishlist bugs will get fixed in the next upstream version, however that

Some? All?
And when can that next upstream version be expected (as far as I know
the last one is more than four years old).

> needs some sorting out of the upstream cvs which is not in sync with redhat,
> suse and debian.

Re: Development standards for unstable

[Olaf van der Spek]

On 1/12/06, Andreas Tille <[EMAIL PROTECTED]> wrote:
> On Thu, 12 Jan 2006, Petter Reinholdtsen wrote:
>
> > [Florian Weimer]
> >> What about: stop threatening your fellow developers?
> >
> > Why is specifying the consequences of doing a bad job with maintaining
> > ones debian packages threatening?
>
> IMHO it isn't at all.
>
> > Personally I believe it is time we made clear and written down
> > explanations on what will happen to badly maintained packages, and
> > then implement it, to make sure the quality of the packages still in
> > Debian when this policy is implement is higher than the current level.
>
> In addition to the list of Anthony I might add:
> Require kind of a monthly status report of the maintainer.  There must be a
> reason if an RC bug is open longer than a month.  The maintainer should
> give reasons like "Need help", "Discussing with upstream", ...
> If the RC bug is two month old: "Sorry, got no help", "Upstream is ignorant",
> ...
> If a maintainer would not manage to respond to an RC bug for three months
> the package is obviousely not maintained and should be taken over by
> somebody else, IMHO.

I wish something like that applied to all bugs.
There are packages that have seen little updates for months/years with
lots of wishlist bugs.

Apache2 bugs status

[Olaf van der Spek]

Hi Debian developers,

Does any of you know about the status of Apache2?
I've send the message below to listed email address and I've asked at
IRC but I haven't received any response.



Hi Apache2 maintainers,

I've noticed there are a lot of bugs, see
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=apache2
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=apache2-common

A lot of those bugs are quite old and some appear to be trivial to
fix, but they don't have a single response from you.
Could you please tell why?

Greetings,

Olaf

Re: Apache2 bugs status

[Olaf van der Spek]

On 1/21/06, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek wrote:
> > Hi Debian developers,
> >
> > Does any of you know about the status of Apache2?
>
> It works flawlessly on several places where I have deployed it.
>
> > I've send the message below to listed email address and I've asked at
> > IRC but I haven't received any response.
> [..]
> > A lot of those bugs are quite old and some appear to be trivial to
> > fix, but they don't have a single response from you.
> > Could you please tell why?
>
> Most likely because the bugs are non-issues and should simply be closed.

Really? Interesting. Why do you think they are non-issues?

> Which bug report exactly seems to cause problems for you?

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341022
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267477
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289868
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291841
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325594
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338472
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349016

Re: Apache2 bugs status

[Olaf van der Spek]

On 1/21/06, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek wrote:
> > On 1/21/06, Jeroen Massar <[EMAIL PROTECTED]> wrote:
> >> Olaf van der Spek wrote:
> [..]
> >>> A lot of those bugs are quite old and some appear to be trivial to
> >>> fix, but they don't have a single response from you.
> >>> Could you please tell why?
> >> Most likely because the bugs are non-issues and should simply be closed.
> >
> > Really? Interesting. Why do you think they are non-issues?
>
> See below...
>
> >> Which bug report exactly seems to cause problems for you?
> >
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341022
>
> As stated in the bug report, a configerror that happens _after_ the
> 'administrator' has modified it.

Like I stated in the bug report, that still doesn't make the vhost
conf the right place for that directive.

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267477
>
> There is no 'simple' way of doing this, especially as people who want

And why is that?
Lots of additional steps can be automated.

> SSL either need to create a snakeoil certificate or want to use their
> own. It can't be automated, people should simply read the documentation,
> which is already included.
>
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=289868
>
> As marked by ASF: Invalid bug.

As the ASF said, the Debian conf is not the same as the upstream conf,
so the ASF's resolution doesn't apply to Debian.

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=291841
>
> Ever ran a log analysis program?

No, is that relevant?

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=325594
>
> Just kill the old one, start the new one.

That's a work around, not a solution.

> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338472
>
> Both /server-info and /server-status are commented out.
> If somebody wants to enable them they can also stick them
> directly in the virtualhost they want.
>
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349016
>
> Wishlist item.

And those don't reserve any response?

> Any bugs which are deadly and critical except for the fact that you
> don't want to read documentation a bit?

Why do bugs need to be deadly or critical?

Re: Problems found by piuparts

[Olaf van der Spek]

On 2/22/06, Frank Küster <[EMAIL PROTECTED]> wrote:
> Adeodato Simó <[EMAIL PROTECTED]> wrote:
>
> >   Correct, so one would put in foo.postrm:
> >
> > rmdir --ignore-fail-on-non-empty /usr/local/lib/foo
>
> That's not sufficient, because /usr/local may be mounted ro, and
> therefore the command may fail even if the directory is empty.
>
> rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true
>
> or maybe just
>
> rmdir /usr/local/lib/foo 2>/dev/null || true

Shouldn't logic like that be in one central place (dpkg or a library)
and not spread over dozens of packages?

Re: net-tools maintenance status

[Olaf van der Spek]

On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> > So I think you can tell pretty clearly that Bernd has no objection at all
> > to NMU's.
>
> yes, but please not for wishlist bugs. Again: there are bugs open for
> net-tools where help is requested, I would love to have patches for those.
> Generally I am not aware of time critical bugs.
>
> The wishlist bugs will get fixed in the next upstream version, however that
> needs some sorting out of the upstream cvs which is not in sync with redhat,
> suse and debian.

Hi Bernd,

What's the status of the next upstream version?
Do you think it'll be ready before Etch?

Re: Re: Re: Implicition declarations of functions and bugs

[Olaf van der Spek]

On 3/11/06, Samuel Thibault <[EMAIL PROTECTED]> wrote:
> This is a warning and not an error, because using one's own strdup()

Is there any reason not to add an explicit declaration (in any case)?

> function (that would take ints) is perfectly legal. gcc-4.0 emits the
> warning to let the programmer know that he should disambiguate this by
> either #including the usual C header, or by giving the prototype of his
> own strdup() function.
>
> Anyway, such warnings deserve grepping, since they are evidence of a
> potential binary break.

Re: NEW queue backing up again -- ftpmasters, any explanation or comment?

[Olaf van der Spek]

On 3/13/06, martin f krafft <[EMAIL PROTECTED]> wrote:
> also sprach Petter Reinholdtsen <[EMAIL PROTECTED]> [2006.03.13.0752 +0100]:
> > Could be, but I believe I heard that most NEW processing is done
> > by one of the assistants while the mirror split is done by someone
> > else.
>
> The mirror split is a complicated endeavour. From what I understood,
> the NEW queue was put on hold on purpose until the split is
> complete.

Has that not been announced in any public place?

Re: removal of svenl from the project

[Olaf van der Spek]

On 3/15/06, Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> Le Mer 15 Mars 2006 03:01, Andres Salomon a écrit :
> > Hi,
> >
> > I am going through the expulsion process to have Sven Luther removed
> > from the project.  The process is outlined here:
> > 
> >, and I have already completed step 1.
>
> I strongly oppose to such an expulsion.
>
> what is wrong with you ? are you gone completely insane or what ?
>
> I know Sven may sometimes be a bit overpresent in some trolls, he also
> may answer too quick, without having read the mail he answers to
> correctly enough. But AFAICT, I've always seen him apologies when he
> did so (I can provide links if you can't believe me…).

Is an apology a complete undo?

> If you want to expulse any DD that taunts a release manager, a

Where did he say he wanted to do that?

Re: And now for something completely different... etch!

[Olaf van der Spek]

Javier Fernández-Sanguino Peña wrote:

Ok, so sarge has been released! We should all thank the Release Team for
their hard work in putting this major release together. But... how about we
start discussing about what major release goals we want to set for Etch? 


I'd like to see:
The ability to easily run multiple independent copies of a daemon. At
the moment you'd have to manually edit init scripts and conf scripts but
it'd be nice to see this automatically supported.

The ability to have multiple versions of a package installed at the same
time.


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

Running daemons without root access?

[Olaf van der Spek]

Hi,

Is it possible for a user to ensure that a certain app is (always)
started after system start (and stopped before shutdown) without using
root access?
If so, how?


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

Re: And now for something completely different... etch!

[Olaf van der Spek]

Petri Latvala wrote:

On Tue, Jun 07, 2005 at 11:40:55AM +0200, Olaf van der Spek wrote:


The ability to have multiple versions of a package installed at the same
time.



(Sorry Olaf, for getting this twice, my fingers work too fast)

No, dear $DEITY. This "feature" is the major thing I hate about
rpms. It's so easy to get wrong and install a package's new version
side-by-side when you meant to update the old one. And don't say "just
be careful" when there are people in the world who are not seasoned
sysadmin veterans who audit every init.d script and whatnot.

Making installing another version on the side as a
--force-this-I-really-want-to-kick-myself option would not be as bad,
but still as bad. This just won't work. Both versions supply
$PATH/$FILE, and then what?


Supporting side-by-side file installation isn't (that) simple. But that 
doesn't mean it wouldn't be useful.
A mechanism would be needed to specify which version of an application 
should be run. Should this be system-wide, per-user, per-environment?



1) divert the other? what's the use of another package version then


That depends on system-wide vs per-user vs per-environment.


2) install to another dir / another name of the file? Again, what's
the use

3) this is a library so it only has a .so file with another soname so
no name clashes. Hey, oops, different library soname already means a
different package (this, I think, is the reason why rpm supports
multiple versions)


Does it?
I thought minor updates didn't change soname?


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

Re: And now for something completely different... etch!

[Olaf van der Spek]

Don Armstrong wrote:

On Tue, 07 Jun 2005, Olaf van der Spek wrote:


Petri Latvala wrote:


1) divert the other? what's the use of another package version then


That depends on system-wide vs per-user vs per-environment.



If you want something done per-user/per-environment, you can always
use dpkg-deb -x foo.deb .; or whatever to unpack the version you want
to run manually.


What if that package depends on a library that conflicts with a library 
you have installed but you also don't want to uninstall the already 
installed library?

What if you do not want to lose the automatic management of apt-get?


Alternatively, you can have a chroot with the strange versions that
you want.

Having multiple versions system wide when you haven't explicitly
planned for multple versions is just asking for madness. It's


Who said it should be possible without explicitly planning?


especially insane when there are already reasonable methods for having
multiple versions of things installed when that is a reasonable thing
to do. (Think libfoo2, autoconf2.13 or similar.)
 


Don Armstrong




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

Re: Re: kernel security bug #307900

[Olaf van der Spek]

> woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
condition.

Will this be fixed for Woody?
I thought the plan was to provide security support for Woody for another 
year?

--
Olaf van der Spek
http://xccu.sf.net/


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

Re: kernel security bug #307900

[Olaf van der Spek]

Adam Majer wrote:

Olaf van der Spek wrote:



woody's kernels are vulnerable to CAN-2004-1235, a uselib() race


condition.

Will this be fixed for Woody?
I thought the plan was to provide security support for Woody for
another year?




AFAIK, there is no security support for Woody kernels for some time now.
Use kernel.org and compile your kernels for security sensitive machines.


What's the reason for this lack of support?


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

Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path

[Olaf van der Spek]

On 6/10/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 09, 2005 at 02:58:21PM +0200, Olaf van der Spek wrote:
> > ifconfig is in /sbin and only in root's path. But ifconfig is runnable
> > and useful for normal users, so it'd be nice if it could be added to the
> > path of normal users too.
> 
> The problem here is that ifconfig must be in sbin by FHS and by history
> (would break too many scripts). So moving is not an option. I can however

Copying?

> put a symlink in /bin, however I am not sure how other DDs think about it,
> as this will set a bad precedence.

What's bad about a symlink?

Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path

[Olaf van der Spek]

Marco d'Itri wrote:

On Jun 10, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:



The problem here is that ifconfig must be in sbin by FHS and by history
(would break too many scripts). So moving is not an option. I can however
put a symlink in /bin, however I am not sure how other DDs think about it,
as this will set a bad precedence. 


Don't bother. This could be applied to most other programs in /sbin too...


Is that an argument?


And anyway ifconfig is deprecated, everybody should always use iproute
which *is* in /bin.


But it's not installed by default, is it?


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

Re: TODO for etch ?

[Olaf van der Spek]

Nikita V. Youshchenko wrote:

Since I can't find such a list, I'll try to write (a beginning of) one.


Shouldn't such a list be maintained in a Wiki or at least on a web page?
100+ different posts with a few entries don't make sense.


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

Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

Hi,

Many shell apps/scripts output data in tables, for example ls -l, ps 
aux, top, netstat, etc.
At the moment, most of these apps use fixed-width columns with a 
variable-width last-column.

This results in (unnecessary) truncation, for example:
Debian-  11918  0.0  0.1  4428 1464 ?Ss   Jun05   0:00 
/usr/sbin/exim4 -bd -q30m
tcp 0 0 TC218-187-80-45.2:35589 bananensaft.inline.:www ESTABLISHEDproxy 
153239


Also, because the output isn't structured (in way easily readable by 
machines), using the data in a script isn't (very) easy and is likely to 
break due to strict dependency on the syntax.


Are there already any plans to solve these issues?
I was thinking, using structured output (and maybe input) in an XML-like 
way would solve these and allow neat post-processing.
It also separates data generation and presentation, which would be an 
advantage if the presentation needs to be changed.


Any thoughts?

Greetings,

Olaf


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

Re: Bug#312669: /sbin/ifconfig: Add ifconfig to user path

[Olaf van der Spek]

On 13 Jun 2005 10:11:52 +0100, Richard Kettlewell <[EMAIL PROTECTED]> wrote:
> Miles Bader <[EMAIL PROTECTED]> writes:
> > astronut <[EMAIL PROTECTED]> writes:
> > Yes.  The great majority of users don't want to know about stuff
> > like ifconfig, and those that _do_ can either put /sbin in their
> > path themselves or just type the damn path when they run the
> > command.
> >
> > I've no clue why some people whine so much about this.

Probably because there's no solid reason against a symlink.
 
> It causes (at least) two types of trivial irritation:
>  1) on each new system I have to add sbin to my path, usually at the
>point where I'm involved in the already irritating exercise of
>debugging a network problem
>  2) when helping someone out, if you ask them to report what
>'ifconfig' says then the answer is:
>  -bash: ifconfig: command not found
> 
> If there was a clear benefit to having ifconfig in sbin then these
> might be less annoying.  But I've yet to hear of one.

I guess in situations where /sbin is available but /bin isn't (for
whatever reason).
 
> There is a small benefit to having a separate sbin at all, in that it
> takes a few things out of the namespace for tab completion.

On my system, if* matches only if as non-root user.
I doubt namespace 'pollution' is an issue.

> Personally I don't think that outweighs the inconvenience of people
> wrongly putting commands like ifconfig and (historically) traceroute
> in it.
> 
> --
> http://www.greenend.org.uk/rjk/
> 
> 
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 
>

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, GOMBAS Gabor <[EMAIL PROTECTED]> wrote:
> > Are there already any plans to solve these issues?
> 
> Yes. The commands you mention were designed for _human_ consumption. Do
> not use them in scripts without good reasons. There are a lot of

The maintainer of netstat didn't want to change the layout (by
default) because scripts might get broken.
What's the solution here?

> commands to get well-formatted output without truncation. For example,
> ls has a "-n" option for exactly this reason; stat(1) can be used
> instead of "ls -l" to avoid clipping; ps has a _lot_ of formatting
> options itself and all the data can be found under /proc in an easily
> parseable format etc. You just have to select the right tool for the job
> (that also includes using more powerful scripting languages if the task
> is complicated).
 
> > I was thinking, using structured output (and maybe input) in an XML-like
> > way would solve these and allow neat post-processing.
> 
> XML is just _terrible_ for human input/output.

It's not meant for human IO, it's meant for IO to the next chain. The
final chain would then process it to normal text output.

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote:
> What Olaf *really* seems to want is a resource like the new (vapor?)
> Monad shell from MS. Which can be a good thing, if done right, but
> is generally a waste of CPU and memory, if you ask me. As you said,
> there is not a lot of difference between
> 
> ls *.ab | fields name, size | table
> 
> in Monad and
> 
> printf "%-50.50s %d\n", $_, -s $_ for <*.ab>
> 
> in Perl. The domain is necessary anyway, ie, you have to know Monad
> to understand the first, you have to know perl to grok the second.

Except that in Perl you have hard-coded the size of the name field and
hard-coded sizes are almost never optimal (either too large or too
small in most of the cases).

> > > XML is just _terrible_ for human input/output.
> >
> > It's not meant for human IO, it's meant for IO to the next chain.
> > The final chain would then process it to normal text output.
> 
> Even so; imagine a long (6 links) chain of things. Each of them
> would have to unserialize the input and serialize the output (XML no
> less! big overhead!), besides trying to know if its input is xml or

Note that I said structured (XML-like) IO. I didn't say XML. I'm sure
an implementation without big overhead is possible.

> not, if its output should be xml or not. In the Monad case, it
> *seems* that what is passed around are (DCOM?) objects, lowering the
> overhead a litlle bit, but there is a lot of overhead nonetheless.
> And it's still easier to use a tool (like Perl, Python or Ruby for
> instance) that can do the job you want (look my example above)

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote:
> Not necessarily. Just as you have "tableout" as an external command
> (built-in or not) in Monad, you can have a Perl module to print
> things in a tabular manner, expanding the column sizes as needed
> (based on HTML::Format::Table or somesuch)

But I doubt that'd be as simple as things are now.

> Yes, and I withdraw :-) what I said about XML. But *any*
> serialization / deserialization necessary for this scheme to work
> would add (unnecessary) overhead. This and the fact that you would
> create incompatibilities with other Unices ... Those are indications
> that this won't be done.

What kind of incompatibilities?
 
> Obviously, some Monad clone can be done with its entire toolchain
> (monad-ls, monad-tableout) ...

Why not ls --monad?

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote:
> Yes, and I withdraw :-) what I said about XML. But *any*
> serialization / deserialization necessary for this scheme to work
> would add (unnecessary) overhead. This and the fact that you would

Well, if you can do it with Perl without overhead, you can of course
also do it without Perl without overhead.
In that case the 'structured' support would be included in the utility itself.

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote:
> > Well, if you can do it with Perl without overhead, you can of
> > course also do it without Perl without overhead.  In that case the
> > 'structured' support would be included
> 
> Not exactly. Don't get me wrong, object component technology is a
> great thing, standing just next to sliced bread in the list of great
> things, but (just like sliced bread) it does not cure cancer.
> 
> When I do my example inside of Perl, I am supposing whatever objects
> or handles the Perl interpreter has stay inside the interpreter's
> process; when you do a pipe like
> 
> monad-ls *.ab | monad-fields name, size | monad-tableout

If you do a pipe like that. But the functionality you showed in Perl
could also be done completely inside ls itself.

Re: Structured (XML-like) input/output for shell apps?

[Olaf van der Spek]

On 6/13/05, Humberto Massa Guimarães <[EMAIL PROTECTED]> wrote:
> There are a lot of scripts today in production use that use the
> output of ls, ps, in a text-way. If you want to put another command,
> or another switch to "ls", ok, but the fact that you *can* do it
> does not mean that you *should* do it. (see below)

Didn't you say (or someone else) say the output of these commands was
(only) for human consumption?
 
> > > Obviously, some Monad clone can be done with its entire
> > > toolchain (monad-ls, monad-tableout) ...
> >
> > Why not ls --monad?
> 
> If you want to fork and maintain forever util-linux, I have nothing
> to say about that.

Why fork and not just change the 'real' util-linux? ;->

> But I *will* leave you (I'm going home from work now) with Occam's
> razor:
> 
> Entia non sunt multiplicanda praeter necessitem.
> 
> (Things shouldn't be multiplied without necessity)
> IOW: if it's not broken, don't fix it.

If only it wasn't broken.
Netstat for example suffers from truncation.

Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)

[Olaf van der Spek]

On 6/13/05, Adam Heath <[EMAIL PROTECTED]> wrote:
> That's a stupid argument.

It's not that stupid.
If other files shouldn't be there, the specs should explicitly state that.

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/15/05, Ian Campbell <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-06-15 at 12:45 +0200, Wouter Verhelst wrote:
> > > Using prelink invalidates the md5sums of files belonging to Debian 
> > > packages.
> > > Has anyone done any work to address this?
> >
> > The only way to address that is to update the md5sum after prelinking is
> > done.
> 
> I might be talking out of my arse (99% probability ;-)) but I thought
> I'd heard that it was possible to store the pre-linking information
> separately to the binaries, under /var/cache or something for example.
> 
> Am/was I imagining things?

I was thinking about that solution too. If it doesn't exist, we'll
just have to create it. :)

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/15/05, Russ Allbery <[EMAIL PROTECTED]> wrote:
> Ian Campbell <[EMAIL PROTECTED]> writes:
> 
> > I might be talking out of my arse (99% probability ;-)) but I thought
> > I'd heard that it was possible to store the pre-linking information
> > separately to the binaries, under /var/cache or something for example.
> 
> > Am/was I imagining things?
> 
> One of the points of the md5sum verification is to ensure that the
> binaries haven't been tampered with.  If one can tamper with the binaries
> by modifying some file in /var/cache instead, doesn't that just
> reintroduce the same problem?

But it leaves the choice of using prelinking to the user instead of
'forcing' the entire system to use it.

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Russell Coker <[EMAIL PROTECTED]> wrote:
> But if someone can change the cache of data written by prelink then why
> couldn't they also change the program that does the md5 checks to make it
> always return a good result?

A long, long time ago, you were supposed to boot from a read-only
floppy and run the virus scanner from there. I guess the same applies
here, if you really wish to be sure.

Re: And now for something completely different... etch!

[Olaf van der Spek]

On 6/16/05, Joerg Friedrich <[EMAIL PROTECTED]> wrote:
> Steve Langasek schrieb am Dienstag, 14. Juni 2005 um 03:12:09 -0700:
> > Consistent LFS support - Steve Langasek <[EMAIL PROTECTED]>
> 
> Short question:
> What does LFS mean? The first thing which comes into my mind is Linux
> from Scratch. Seems not to fit in this context.

http://www.google.com/search?q=define:lfs

My guess: Large File Support, specifically files larger than 2Gb on
32-bit systems.

Re: Greylisting for @debian.org email, please

[Olaf van der Spek]

On 6/18/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> Steve Greenland <[EMAIL PROTECTED]> writes:
> 
> > So what? It's *e-mail*. If you need realtime, pick up a phone, or use
> > one of any of the innumerable chat systems.
> 
> Ok, from now on, I should report bugs to you by phone?

Is realtime a requirement for bug reporting?

Re: Debian concordance

[Olaf van der Spek]

On 6/19/05, Scott James Remnant <[EMAIL PROTECTED]> wrote:
> Let's use a popular example...  I make a package that
> requires /usr/bin/bzgrep.
> 
> In Debian, I would have to read the debian/changelog for bzip2 and
> discover that this wasn't introduced until 1.0.1-3, and thus
>Depends: bzip2 (>= 1.0.1-3)
> 
> But in a Debian-derivative with a different release schedule (perhaps a
> system used in Schools and sync'd on the start of a school year), that
> might have been backported and added in 0.9.5d-3school1
>Depends: bzip2 (>= 0.9.5d-3school1)
> 
> There's no way to express both of these relationships in the same binary
> (as 1.0.1-2 would satisfy the relationship for the Debian-derivative).
> 
> 
> In the RPM world, my package can simply depend on the
> file /usr/bin/bzgrep existing.

What if you need a specific feature in or version of bzgrep?

Re: TODO for etch ?

[Olaf van der Spek]

On 6/19/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Marc Haber:
> 
> > On Sun, 19 Jun 2005 08:20:49 -0500, Adam Majer
> > <[EMAIL PROTECTED]> wrote:
> >>That could "save" a grand total of about a second.
> >
> > It will save time in case of error when the bootup process stalls for
> > timeouts like DNS and NTP.
> 
> You should set the clock using NTP *before* starting any daemons.
> Most daemons don't use monotonic clocks (I'm not even sure if Linux
> supports them at the required level), and some of them fail in strange
> ways if the system clock warps.

Doesn't Linux or NTP support gradually changing the clock exactly to
avoid such warps?

Re: ftp-master, ftp and db .debian.org moving - hosting sought

[Olaf van der Spek]

On 6/22/05, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> James Troup <[EMAIL PROTECTED]> writes:
> 
> > If you think you could offer hosting under these conditions, please
> > send details to [EMAIL PROTECTED]
> 
> I can't offer hosting, but I do have a suggestion (though perhaps it's
> already been considered and rejected).  We could perhaps take
> advantage of the California Community Colocation Project, which offers
> free colocation for non-profits and individuals.
> 
> http://www.communitycolo.net/
> 
> We surely have Debian volunteers in the bay area who can do any
> necessary on-site help too.

I've been wondering, would it be an idea (for the long-term) to use
(more) distributed ... or p2p concepts to reduce the dependency and
load on central servers?

Re: ftp-master, ftp and db .debian.org moving - hosting sought

[Olaf van der Spek]

On 6/22/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Olaf van der Spek]
> > I've been wondering, would it be an idea (for the long-term) to use
> > (more) distributed ... or p2p concepts to reduce the dependency and
> > load on central servers?
> 
> Please give some specific examples of what you mean.

I'm not sure how exactly the current mirrors work, but syncing
(primary) mirrors between eachother instead of all from a master may
be an idea.

> I hope you aren't suggesting that the mirror network be replaced by
> bittorrent.  That would suck for just about everybody.

I'd not immediately suggest replacing it by BT, but using (or at least
looking at) BT-like concepts may certainly be an interesting idea.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/24/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Petri Latvala]
> > It is an abuse of the Depends field. foo-data doesn't *need* foo for
> > its own operations. Nothing in -data fails to execute without foo
> > (because there's just data, nothing to execute).
> 
> Depends does not just mean "executables will crash or fail to load".
> It actually means "it is pointless to install this package without this
> other package".  Having a package removed automatically because it no

I'd classify that as abuse.
A data package doesn't require another package to do it's duties
(since it has no duties of it's own) so there shouldn't be a depends.

> longer has any reason to be installed is a perfectly legitimate use for
> "Depends".
> 
> That does not solve the circular dependency problem, granted.  Perhaps
> there is need of a package flag that says "it is pointless to have this
> package installed by itself, so remove it if nothing depends on it".
> aptitude currently deduces this from its auto-install state flag, but
> perhaps a package itself ought to be allowed to express it.
> 
> > Or maybe we need a new field for that purpose that only has effect on
> > uninstalls, like Uninstall-with: foo
> 
> That's an alternative.

What if you introduce a new package (bar) that also depends on
foo-data? Then you're forced to also install foo, although you don't
need it at all?

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/24/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Bill Allombert]
> >   The `Depends' field should be used if the depended-on package is
> >   required for the depending package to provide a significant
> >   amount of functionality.
> 
> I'd say if a -data package is useless without its corresponding binary
> package, that fits this definition just fine.  Policy does not specify
> *why* a package might fail to provide significant functionality without
> the presence of something else.  (Unless you wish to argue that -data
> packages provide no functionality, which seems a pretty arbitrary
> definition of 'functionality'.)

I'd argue for exactly that.
What functionality would you say a data package provides?

It's the other package that provides the functionality, not the data
package. The data package shouldn't even have to know about the other
package.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/24/05, Ondrej Sury <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-06-24 at 22:59 +0200, Olaf van der Spek wrote:
> >
> > I'd argue for exactly that.
> > What functionality would you say a data package provides?
> >
> > It's the other package that provides the functionality, not the data
> > package. The data package shouldn't even have to know about the other
> > package.
> 
> If you want to play word games and not apply common sense, then I would

It's not a word game at all.

> say that foo-data package has functionality to provide data to foo and

But that 'functionality' doesn't break without foo.
Like I said before, what would you do if there also was a foo2 or bar
(independent of foo) that'd use foo-data?

Whatever you tried to achieve with the reverse dependency would not
work in that case.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/24/05, Ondrej Sury <[EMAIL PROTECTED]> wrote:
> so it's broken without foo package.  You must realize that 90% of these
> packages are games and only reason for foo + foo-data is to not split
> out arch independent data out of foo package so it doesn't get
> replicated for each arch.

Hmm, another way to nicely solve that would be to improve the
smartness of the archive software such that it deals with this
'replication' under the hood.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/25/05, John H. Robinson, IV <[EMAIL PROTECTED]> wrote:
> I can see where the game would be installed on the client system, and
> the data would live on the file server under /usr/share. Currently, the
> only way to do this is by having installed broken packages, and to copy
> the /etc/amphetamine files from the filer onto the client.

Why would you only install the data and not the binaries on the file
server (filer?)?
 
> vim and vim-common seem to suffer the same, except vim-common has
> nothing outside the /usr/share directory. In my case, though, I would
> likely have installed vim onto the filer, also.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/25/05, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> 
> [Olaf van der Spek]
> > Hmm, another way to nicely solve that would be to improve the
> > smartness of the archive software such that it deals with this
> > 'replication' under the hood.
> 
> Sounds like you want some sort of transparent jigdo on each mirror.
> That, or explicit support everywhere for multi-file debian packages,
> similar in spirit to .dsc source packages.  Neither sounds like much
> fun.

What's no fun about the transparent jigdo-like approach?

Re: ftp-master, ftp and db .debian.org moving - hosting sought

[Olaf van der Spek]

On 6/26/05, Joerg Jaspert <[EMAIL PROTECTED]> wrote:
> On 10332 March 1977, sean finney wrote:
> 
> >> I'm sorry to say that Debian's hosting of machines at Above.Net has
> >> come to an end.  Michael Shields and Steve Osborn have hosted critical
> > sorry to be a stick in the mud about this, but...
> > why wasn't this brought up *before* it was brought to an end?
> 
> It was sent right after the hosting died.
> Should he sent "The hosting may die somewhere in the future, please
> offer something just in case we need it"?

Shouldn't some redundancy (on all levels) be available for this kind of servers?

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/27/05, John H. Robinson, IV <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek wrote:
> > On 6/25/05, John H. Robinson, IV <[EMAIL PROTECTED]> wrote:
> > > I can see where the game would be installed on the client system, and
> > > the data would live on the file server under /usr/share. Currently, the
> > > only way to do this is by having installed broken packages, and to copy
> > > the /etc/amphetamine files from the filer onto the client.
> >
> > Why would you only install the data and not the binaries on the file
> > server (filer?)?
> 
> Because you are sharing /usr/share and not /usr ?
> 
> FHS 2.3:
> /usr/share : Architecture-independent data
> 
> One filer to rule all the architectures. Essentially, the same reason we

What is a filer?

> make -data packages to begin with. If you have a mixed environment (x86,
> amd64, sparc, ppc) then you can have one /usr/share for all of them.

I understand that part, but I'd expect binaries to be able to live on
a file servers too, even for multiple architectures.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/27/05, John H. Robinson, IV <[EMAIL PROTECTED]> wrote:
> > I understand that part, but I'd expect binaries to be able to live on
> > a file servers too, even for multiple architectures.
> 
> /usr/bin/vim is different on PPC than on i386. You cannot share /usr

Sure. 

> (and thusly /usr/bin) between architectures. You can with /usr/share, as
> it is architecture independent.

I guess the tools aren't capable of this, but AFAIK you could just do
(manually) something like /usr/i386/bin and /usr/ppc/bin

And then the client could map /usr/bin to either depending on it's architecture.

Re: Getting rid of circular dependencies

[Olaf van der Spek]

On 6/28/05, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> How would you treat the librsvg case? Currently, librsvg2-2 and
> librsvg2-common both depend on each other. The librsvg2-2 package
> contains the library, and librsvg2-common contains a loader that allows
> gdk_pixbuf to load SVG files.
> * librsvg2-common needs to depend on librsvg2-2 because it links to the
> library;
> * librsvg2-2 depends on librsvg2-common because most applications
> linking to librsvg2 also expect the SVG loader to be available.

So they expect something to be available without depending on a
package that provides it? Sounds like a bug.

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> What is the rationale for changing the default setting?
> I find it very annoying, and from a brief discussion on #debian-devel I
> see that I'm not alone.

I guess it went from off to on?
Wasn't there an issue with worms using the known hosts file to spread
further once one system containing private keys had been compromised?

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> What is the rationale for changing the default setting?
> I find it very annoying, and from a brief discussion on #debian-devel I
> see that I'm not alone.

What causes this annoyance?

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> On Jul 02, Olaf van der Spek <[EMAIL PROTECTED]> wrote:
> 
> > On 7/2/05, Marco d'Itri <[EMAIL PROTECTED]> wrote:
> > > What is the rationale for changing the default setting?
> > > I find it very annoying, and from a brief discussion on #debian-devel I
> > > see that I'm not alone.
> > What causes this annoyance?
> The need to edit the file to add/update/remove IP addresses, hostnames
> and whole keys.

What prevents you from turning the option off again?
And do you think more people need it off then on?

Re: HashKnownHosts

[Olaf van der Spek]

On 7/2/05, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
> > > -- and relying on other people's security to increase your own isn't
> > > pretty clever, actually.
> >
> > Currently, it's the foundation of Internet security, I'm afraid.
> 
> Well, then the 'foundation of Internet security' is very weak, I'm
> afraid. It's plain stupid to rely on someone else to get _your_ security
> working correctly. Think about it.

Did you check and compile the source code of every package you're
running yourself?

Re: ftp-master, ftp and db .debian.org moving - hosting sought

[Olaf van der Spek]

On 7/4/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Olaf van der Spek <[EMAIL PROTECTED]> writes:
> > I'm not sure how exactly the current mirrors work, but syncing
> > (primary) mirrors between eachother instead of all from a master may
> > be an idea.
> 
> Mirrors are stacked in a tree (and even graph for some that use
> fallbacks) and pushes travel along the mirror network down this
> tree. The Mirrors.masterlist (apt-get source base-config) file
> contains a line where a mirror updates from.

I assume there's a single root. How much children does that root have?
 
> But BT has limitations. Esspecialy with the number of files to

Sure.

> share. A tracker that coordinates a full debian mirror would have to
> be insanely huge. Also P2P tend to ignore the geography of the
> network. It is much better to download debs from one local mirror than
> connect all over the world to countless users.

True. But for example, is the current apt-get capable of contacting
another mirror if and only if the primary fails?

> One thing that might be intresting though is replacing mirrors with
> smart caches. Act like a proxy with prefetching for commonly used
> packages.

Another thing I was thinking about would be to easily and securly use
other systems on your LAN (or inside your ISP) as mirrors without it
costing extra storage or requiring extra trust.

Re: ftp-master, ftp and db .debian.org moving - hosting sought

[Olaf van der Spek]

On 7/4/05, Mark Brown <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 04, 2005 at 08:05:21PM +0200, Olaf van der Spek wrote:
> 
> > True. But for example, is the current apt-get capable of contacting
> > another mirror if and only if the primary fails?
> 
> For package downloads apt will try the sources in the order listed in
> sources.list, only trying subsequent ones if the first fails.  For
> Packages downloads all the mirrors are hit each time, which is needed
> anyway to handle the case where a mirror is serving files but not
> updating.

I don't think it's needed anyway. Especially if you increase the
number of mirrors to ensure always at least one is up.

Re: [Debian-uk] Sun have (probably) patented apt-get

[Olaf van der Spek]

On 7/6/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> Would that mean Debian gets ownership of the patent then and Sun would
> have to pay us?

No, as far as I understand it means the patent isn't valid.

How to tell user default random pass for daemon?

[Olaf van der Spek]

Hi,

Suppose you'd like to generate a random pass by default after your
daemon is installed. How should you get that pass to the user?
Is it allowed to write it to a file in root's home dir?

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Olaf van der Spek]

On 7/8/05, Santiago Vila <[EMAIL PROTECTED]> wrote:
> Sure, old bugs may be the symptom that the maintainer is MIA, that the
> upstream maintainer is MIA, and similar things that we should of
> course track as well, but it does not mean that an old bug is "worse"
> in any way than a new bug (eveything else being the same).

What's the proper way to deal with maintainers that kinda 'ignore'
bugs (in whatever way)?

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote:
> Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > > Keeping the question priority at 'low' make sure most users will not
> > > see the question, and that only reconfigure will present it.  I hope
> > > you are not setting the debconf priority limit to low. :)
> >
> > If we recommend against setting the priority to low, why bother with it?
> 
> Enabling debconf pre-seeding for customized installs is a good enough
> justification IMO.

Isn't debconf a bit 'expensive' just to allow pre-seeding?

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
> [Olaf van der Spek]
> > Isn't debconf a bit 'expensive' just to allow pre-seeding?
> 
> No, it is amazingly cheap and simple.  

Don't debconf questions need to be translated?

> Did you have any cheaper
> suggestions?

Nothing concrete at the moment.

> Having one consistent way to provide install time configuration is
> important to be able to share configuration settings across custom
> debian distributions, and also to reduce the complexity in the
> individual custom debian distributions.

Re: configure a program -- debconf abuse?

[Olaf van der Spek]

On 7/9/05, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 09, 2005 at 10:00:16AM +0300, Gustavo Noronha Silva wrote:
> > Em Ter, 2005-07-05 às 21:32 +1000, Hamish Moffatt escreveu:
> > > > Keeping the question priority at 'low' make sure most users will not
> > > > see the question, and that only reconfigure will present it.  I hope
> > > > you are not setting the debconf priority limit to low. :)
> > >
> > > If we recommend against setting the priority to low, why bother with it?
> >
> > Enabling debconf pre-seeding for customized installs is a good enough
> > justification IMO.
> 
> That sounds like a good use for hidden questions. But I think we ask way
> too many questions on the whole.
> 
> In the last two days I helped a friend with a sarge install who is new
> to linux. We installed the base system with the desktop task.
> 
> Does the new Debian user really care if their fonts are managed with
> defoma, a technology they have never heard of? (And when did defomized
> become a verb?) There should be a sensible default. Why shouldn't fonts
> always be managed with defoma?
> 
> Is it important at system install time to ask whether cdrecord should be
> installed SUID or not? There should be a sensible default there too.
> 
> The post-reboot (debootstrap) stage asks way too many questions.
> This is a pity because the pre-reboot (d-i) stage is excellent.

I've been wondering the same about questions on updates. Why are
(many) questions being asked on updates (first update after system
install)? Sounds like a weird time to me.

Re: "How to recognise different ETCH wishlists from quite a long way away" (revised)

[Olaf van der Spek]

On 7/9/05, Manoj Srivastava va, manoj <[EMAIL PROTECTED]> wrote:
> On Sat, 9 Jul 2005 22:47:45 +0200, Petter Reinholdtsen <[EMAIL PROTECTED]> 
> said:
> 
> > If these are good settings for dupload, why is it not included in
> > the package as the default configuration for dupload?
> 
>Good by whose criteria? Yours? Mine? Joe random Developer's?
>  What is more important -- speed, not seeing garbage on the screen
>  when uploading, or ensuring one always signs stuff? What if I use
>  pbuilder and it always signs stuff for me, so the check is just a
>  waste of time? What if I wanna upload even when linda crashes (as it
>  does periodically for me)?

Wouldn't it be better to have a 'safe' default then a fast one?

Re: GCC 4.0 as the default GCC / C++ ABI change

[Olaf van der Spek]

On 7/12/05, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Matthias Klose:
> 
> > With today's dinstall run, new gcc/g++ packages are entering the
> > archives and GCC 4.0 is the default gcc/g++. Starting from now, please
> > DON'T upload any C++ code, which build-depends on a library written in
> > C++ that is not yet converted to the new C++ ABI.  Details for the C++
> > ABI change are at the end of the message. How do we go on?
> 
> I don't know if it's related, but roughly since the GCC 4.0 upload, I
> get strange assembler warnings for perfectly valid C++ programs:

I got them too but it seems they're now 'fixed' in unstable.

Re: should etch be Debian 4.0 ?

[Olaf van der Spek]

On 7/12/05, Andrea Mennucc <[EMAIL PROTECTED]> wrote:
> Antti-Juhani Kaijanaho wrote:
> > On 20050708T181259-0400, Johan Kullstam wrote:
> >>What signal is meant by 3.1 versus 4.0?  Does your intended audience
> >>have any concept of the distinction?
> >
> > The usual distinction, when it is made, is that bumping the major number
> > indicates a disruptive upgrade (changing how things work, not just
> > adding new things).
> >
> 
> the change of gcc 3 to gcc 3 is disruptive (to c++ binaries)

4?
But not to users, which is what the version number is about.