Re: Woody KDE 3 packages

[Shaun Jackman]

Yes! Thanks. I didn't know of the apt-cache policy command. Because 
the Release file was broken upstream, apt assigned it a priority of 
-1. I added the following lines to apt/preferences:

Package: *
Pin: origin download.kde.org
Pin-Priority: 951

Thanks,
Shaun


> Blind shot:
>
> $ apt-cache policy
> $ man apt_preferences
>
> And doesn't this question belong to users?
>
> -towo

Re: Debconf or not debconf : Conclusion

[Craig Sanders]

On Thu, Jul 03, 2003 at 04:49:19PM -0400, Joey Hess wrote:
> If I ever add filtering to the notes debconf allows to be displayed,
> notes that refer the user to README.Debian will be at the top of the
> list to never be displayed.
> 
> Of course, I am much more likely to bow to the pressure of notes like
> the one you're apparently adding, and completly disable all notes at
> some point, rather than adding filtering. I don't like arms races.

how about a configuration option so that debconf notes get sent to
an email address rather than to the screen?

craig

Re: Debconf or not debconf : Conclusion

[Craig Sanders]

On Thu, Jul 03, 2003 at 02:36:24PM -0500, Steve Langasek wrote:
> [...]
> This upstream change makes no sense from a usability standpoint; this new
> stunnel package would be pretty useless to me, and I wouldn't want to have it
> automatically installed on my systems if I were using the previous, working
> version.  By the time a debconf note is sent, it's too late.

the new version of stunnel is much better than the old one.

i got bitten by the upgrade to 4.0-4 (when the init.d script didn't start
stunnel unless ENABLED=1 in /etc/default/stunnel).

big deal.  i noticed it quickly enough and it took me less than a minute to
scan the docs and discover that i should edit /etc/default/stunnel.  the worst
that happened was that my uucp-over-tcp clients weren't able to connect for a
while.


IMO, anyone who does an upgrade without bothering to check that important
services are still running correctly afterwards is just plain sloppy and
deserves whatever their negligence causes.  

the same applies to anyone who doesn't test upgrades of critical services on
another, unimportant machine first...and for really important packages, it's a
good idea to make sure you have a backup copy of the old version of the package
before upgrading (dpkg-repack is useful here if it has been cleaned out of your
local /var/cache/apt/archives)if the new version proves to be broken,
revert to the old version.

debian packages aren't a substitute for a competent and careful system admin,
they're just a tool to make the sysadmin's job easier.

craig

Re: A success story with apt and rsync

[Theodore Ts'o]

On Mon, Jul 07, 2003 at 01:01:34AM +0100, Andrew Suffield wrote:
> > 
> > I believe htree == dir_index, so tune2fs(8) and mke2fs(8) have the answer.
> 
> My /home has that enabled and readdir() returns files in creation order.
> 

Then you don't have a htree-capable kernel or the directory isn't
indexed.  Directories that fit in a block are not indexed, as are
directories larger than a block that were created before directory
indexing was enabled, or if they were modified by a non-htree capable
kernel.

You can use the lsattr command to see if the indexed (I) flag is set
on a particular directory:

% lsattr -d /home/tytso
--I-- /home/tytso

- Ted

Re: A success story with apt and rsync

[Theodore Ts'o]

On Sun, Jul 06, 2003 at 11:36:34PM +0100, Andrew Suffield wrote:
> 
> I can only presume this is new or obscure, since everything I tried
> had the traditional behaviour. Can't see how to turn it on, either.
> 

It's new for 2.5.  Backports to 2.4 are available here:

http://thunk.org/tytso/linux/extfs-2.4-update/extfs-update-2.4.21

For those who are interested, the broken out patches can be found here:

http://thunk.org/tytso/linux/extfs-2.4-update/broken-out-2.4.21/to-apply

Once you have a htree-enabled kernel, you enable a filesystem to use
the feature by using the following command:

tune2fs -O dir_index /dev/hdXX

Optionally, you can reorganize all of the directories to use btrees by
using the command "e2fsck -fD /dev/hdXX".  Otherwise, only directories
that are expanded beyond a single block after you set the dir_index
flag will use htrees.  The dir_index is a fully compatible extension,
so it's perfectly safe to mount a filesystem with htrees on a
non-htree kernel.  A non-htree kernel will just ignore the b-tree
information, and if it attempts to modify a hash-tree directory, it
will just invalidate the htree interior node information, so that the
directory becomes unindexed until e2fsck -fD is run over the
filesystem to which optmizes all of the directories by reindexing them
all.

Why would you want to use htrees?  Because they speed up large
directories.  A lot.  Try creating 400,000 zero-length files in a
single directory.  It will take under 30 seconds with htree enabled,
and well over an hour without.

> > The good news is that this particular optimization of sorting by inode
> > number should work for all filesystems, and should speed up xfs as
> > well as ext2/3 with HTREE.
> 
> What about ext[23] without htree? Mucking with the order returned by
> readdir() has historically caused problems there...

It'll be fine; in fact, in some cases you'll see a slight speed up.
The key is that you'll get the best performance by reading/modifying
the inode data structures in sorted order by inode number.  This way,
you make a single sweep through the inode table, without needing any
extraneous seeks.  Using the natural sort order of readdir() on
non-htree ext2/3 systems mostly approximated this --- although if
files are deleted and created from the directory, this is not
guaranteed.  So sorting by inode number will never hurt, and may help.

- Ted

Re: NEWS.Debian support is here

[Matt Zimmerman]

On Sun, Jul 06, 2003 at 08:01:38PM -0400, Joey Hess wrote:

> Scott James Remnant wrote:
> > Is there any particular reason to keep the "unstable; urgency=low"
> > there?  It's duplication of information in the changelog, and nearly
> > every developer will probably forget to change the information in
> > NEWS.Debian when they change the urgency or distribution in changelog.
> 
> It may be that apt-listchanges could use the info in the future to sort
> news items. It doesn't have to match the value in the changelog.

When merging Joe Drew's patch, I started to add support for sorting the news
items by urgency.  That much, at least, would be useful.  The distribution
is pretty unimportant in the NEWS context, though.

> One nice thing about using standard changelog format is that if someone
> wants to they could add another format, specialised for news
> information, and another parser in /usr/lib/dpkg/parsechangelog/. Of
> course apt-listchanges does its own parsing, so anyone who does that
> would probably be well served by redesigning the parser interface to
> something that apt-listchanges can use. Anyway, it's nice to keep that
> option open.

I filed a wishlist bug about this quite a long time ago (#95579), but got no
response.

-- 
 - mdz

Re: A success story with apt and rsync

[Andrew Suffield]

On Sun, Jul 06, 2003 at 07:28:09PM -0400, Matt Zimmerman wrote:
> On Sun, Jul 06, 2003 at 11:36:34PM +0100, Andrew Suffield wrote:
> 
> > On Sun, Jul 06, 2003 at 05:48:24PM -0400, Theodore Ts'o wrote:
> > > Err, no.  If the htree (hash tree) indexing feature is turned on for
> > > ext2 or ext3 filesystems, they will returned sorted by the hash of the
> > > filename --- effectively a random order.  (Since the hash also
> > > includes a secret, random, per-filesystem secret in order to avoid
> > > denial of service attacks by malicious users who might otherwise try
> > > to create huge numbers of files containing hash collisions.)
> > 
> > I can only presume this is new or obscure, since everything I tried
> > had the traditional behaviour. Can't see how to turn it on, either.
> 
> I believe htree == dir_index, so tune2fs(8) and mke2fs(8) have the answer.

My /home has that enabled and readdir() returns files in creation order.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpNA07l53T5F.pgp
Description: PGP signature

Re: NEWS.Debian support is here

[Joey Hess]

Scott James Remnant wrote:
> Is there any particular reason to keep the "unstable; urgency=low"
> there?  It's duplication of information in the changelog, and nearly
> every developer will probably forget to change the information in
> NEWS.Debian when they change the urgency or distribution in changelog.

It may be that apt-listchanges could use the info in the future to sort
news items. It doesn't have to match the value in the changelog.

One nice thing about using standard changelog format is that if someone
wants to they could add another format, specialised for news
information, and another parser in /usr/lib/dpkg/parsechangelog/. Of
course apt-listchanges does its own parsing, so anyone who does that
would probably be well served by redesigning the parser interface to
something that apt-listchanges can use. Anyway, it's nice to keep that
option open.

-- 
see shy jo


pgpn3oMnK1I7e.pgp
Description: PGP signature

Re: A success story with apt and rsync

[Matt Zimmerman]

On Sun, Jul 06, 2003 at 11:36:34PM +0100, Andrew Suffield wrote:

> On Sun, Jul 06, 2003 at 05:48:24PM -0400, Theodore Ts'o wrote:
> > Err, no.  If the htree (hash tree) indexing feature is turned on for
> > ext2 or ext3 filesystems, they will returned sorted by the hash of the
> > filename --- effectively a random order.  (Since the hash also
> > includes a secret, random, per-filesystem secret in order to avoid
> > denial of service attacks by malicious users who might otherwise try
> > to create huge numbers of files containing hash collisions.)
> 
> I can only presume this is new or obscure, since everything I tried
> had the traditional behaviour. Can't see how to turn it on, either.

I believe htree == dir_index, so tune2fs(8) and mke2fs(8) have the answer.

-- 
 - mdz

Re: Close old RFP/ITPs?

[Petter Reinholdtsen]

[Andreas Barth]
> So I think this is fair enough and if neither the original requester
> nor any reader of debian-wnpp sees need for a package it really
> doesn't need to be packaged any more.

I have several packages which I am interested in getting packaged, but
I am neither the requester nor a reader of debian-wnpp.  Your
assertion is thus wrong in at least one case.  I believe it would be a
bad idea to close RFPs just because no one responds when you ask for
it.  I use a script to keep track of the progress of the packages I am
missing, and it will not detect new comments in the BTS entry.

So, please do not in general close old RFPs unless the package is
uploaded into Debian.  Some of them should probably be closed as the
package is dead upstream and there are better alternatives available,
but that is independent of the age of the RFP.

Re: Juridical prosecution

[Stefano Zacchiroli]

Please, please, please: mention this post on debian weekly news.
Is really worth the effort!

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


pgpmHIcLeXVtP.pgp
Description: PGP signature

Re: A success story with apt and rsync

[Andrew Suffield]

On Sun, Jul 06, 2003 at 05:48:24PM -0400, Theodore Ts'o wrote:
> On Sun, Jul 06, 2003 at 10:12:03PM +0100, Andrew Suffield wrote:
> > On Sun, Jul 06, 2003 at 10:28:07PM +0200, Koblinger Egmont wrote:
> > > Yes, when saying "random order" I obviously ment "in the order readdir()
> > > returns them". It's random for me.  :-)))
> > > 
> > > It can easily be different on different filesystems, or even on same
> > > type of filesystems with different parameters (e.g. blocksize).
> > 
> > I can't think of any reason why changing the blocksize would affect
> > this. Most filesystems return files in the sequence in which they were
> > added to the directory. ext2, ext3, and reiser all do this; xfs is the
> > only one likely to be used on a Debian system which doesn't.
> 
> Err, no.  If the htree (hash tree) indexing feature is turned on for
> ext2 or ext3 filesystems, they will returned sorted by the hash of the
> filename --- effectively a random order.  (Since the hash also
> includes a secret, random, per-filesystem secret in order to avoid
> denial of service attacks by malicious users who might otherwise try
> to create huge numbers of files containing hash collisions.)

I can only presume this is new or obscure, since everything I tried
had the traditional behaviour. Can't see how to turn it on, either.

> I would be very, very surprised if reiserfs returned files in creation
> order.

Some trivial testing indicates that it does. Heck if I know how or why.

> It is really, really bad assumption to assume that files will be
> returned in the same order as they were created.

However, there's no real need to - that was just an example. As long
as the sequence is more or less stable (which it should be, for
btrees; don't know about htree) then rsync won't be perturbed.

> > On ext2, as an example, stat()ting or open()ing a directory of 1
> > files in the order returned by readdir() will be vastly quicker than
> > in some other sequence (like, say, bytewise lexicographic) due to the
> > way in which the filesystem looks up inodes. This has caused
> > significant performance issues for bugs.debian.org in the past.
> 
> If you are using HTREE, and want to do a readdir() scan followed by
> something which opens or stat's all of the files, you very badly will
> want to sort the returned directory inodes by the inode number
> (de->d_inode).  Otherwise, the order returned by readdir() will be
> effectively random, with the resulting loss of performance which you
> alluded to because the filesystem needs to randomly seek and ready all
> around the inode table.

Hmm, that's going to cause some trouble if htree becomes common. Is
there any way to test for this at runtime?

> The good news is that this particular optimization of sorting by inode
> number should work for all filesystems, and should speed up xfs as
> well as ext2/3 with HTREE.

What about ext[23] without htree? Mucking with the order returned by
readdir() has historically caused problems there...

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgpbFXtT67wbT.pgp
Description: PGP signature

Re: A success story with apt and rsync

[Koblinger Egmont]

On Sun, 6 Jul 2003, Andrew Suffield wrote:

> On ext2, as an example, stat()ting or open()ing a directory of 1
> files in the order returned by readdir() will be vastly quicker than
> in some other sequence (like, say, bytewise lexicographic) due to the
> way in which the filesystem looks up inodes. This has caused
> significant performance issues for bugs.debian.org in the past.

You're right, I didn't get the point in the story when I simply ran find
using the sortdir wrapper, but now I understand the problem.

However I'm still unsure if this good to keep files unsorted, especially
if we consider effective syncing of packages. On my home computer I've
never heard the sound of my disk at package creating phase (even though
we've beein using sortdir for more than a half year, and I've compiled
hundreds of packages), but I hear it when e.g. the source is decompressed.
At the 'dpkg-deb --build' phase only the processor is the bottleneck.

This might vary under different circumstances. I'm unaware of them in case
of Debian, e.g. I have no information about what hardware your packages
are created on, whether there are any other cpu-intensive or
disk-intensive applications running on these machines etc. I can easily
imagine that using sortdir can drastically decrease performance if another
disk-intensive process is running. However my experiences didn't show a
noticeable performance decrease if this was the only process accessing the
disk...

But hey, let's stop for a minute :-) Building the package only uses the
memory cache for most of the packages, doesn't it? The files it packs
together have just recently been created and there are not so many
packages whose uncompressed size is close to or bigger than the amount of
RAM in today's machines...

And for the large packages the build itself might take thousands as much
time as reading the files in sorted order.

Does anyone know what RPM does? I know that listing the contents of a
package always produces alphabetical order but I don't know whether the
filelist is sorted on the fly or the files really appear alphabetically in
the cpio archive.


So I guess we've already seen pros and cons of sorting the files. (One
thing is missing: we still don't know how efficient rsync is if two
rsyncable tar.gz files contain the same files but in different order.)
The decision is clearly not mine but the Debian developers'. However, if
you ask me, I still vote for sorting the files :-))




bye,

Egmont

Re: Please remove RFCs from the documentation in Debian packages

[Javier Fernández-Sanguino Peña]

On Sun, Jul 06, 2003 at 02:07:14PM -0500, Branden Robinson wrote:
> > b) people at debian-legal do not keep people at debian-doc up-to-date to
> > latest consensus wrt to documentation licensing (yes, until somebody who is
> > at -doc says "please RTFM" and somebody at -legal says "TFM is worthless")
> 
> Perhaps debian-legal needs its own document, to which the DDP document
> can merely refer.

Fine by me. I don't like too much digging into debian-legal :-)
It would be very nice to have a document in the DDP detailing which 
licenses have been analised by the debian-legal mailing list and what the 
results have been (DFSG-free or otherwise). 

Regards

Javi


pgpA02IqnJNSY.pgp
Description: PGP signature

Bug#200268: general: .dpkg-dist and .dpkg-old files in cron.* and modutils dirs

[Csillag Tamas]

Package: general
Version: unavailable; reported 2003-07-06
Severity: normal

Hi!

Problem:

I have a laptop system, I recently upgraded to sarge (from woody)
and I noticed the following problem:
I moved some script from /etc/cron.daily to /etc/cron.weekly (to save
power)
But when dpkg asked me whether I want to install the new version of it's
config file I answered no. Now a new file package.dpkg-dist appears and
if i answered yes the old one will be renamed to package.dpkg-old
(This is fine for normal dirs but not for these which are parsed by
*simple* scripts)

This is not the expected behaviour because now I have scripts which I
already removed, and the same applies to /etc/modutils, if a new package
makes an upgrade here, there can be duplicated entries in
/etc/modules.conf

How to solve:

If you move a new config file to a new directory it will be harder find
those files.
So dpkg should explicitly tell the user that this directory must be
checked after the upgrade or you should tell that the original/new files will
be moved to this and this directory.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux notebook 2.4.21-rc2-laptopmode2 #2 2003. máj. 23., péntek, 
12.20.04 CEST i586
Locale: LANG=hu_HU, LC_CTYPE=hu_HU

Re: A success story with apt and rsync

[Theodore Ts'o]

On Sun, Jul 06, 2003 at 10:12:03PM +0100, Andrew Suffield wrote:
> On Sun, Jul 06, 2003 at 10:28:07PM +0200, Koblinger Egmont wrote:
> > Yes, when saying "random order" I obviously ment "in the order readdir()
> > returns them". It's random for me.  :-)))
> > 
> > It can easily be different on different filesystems, or even on same
> > type of filesystems with different parameters (e.g. blocksize).
> 
> I can't think of any reason why changing the blocksize would affect
> this. Most filesystems return files in the sequence in which they were
> added to the directory. ext2, ext3, and reiser all do this; xfs is the
> only one likely to be used on a Debian system which doesn't.

Err, no.  If the htree (hash tree) indexing feature is turned on for
ext2 or ext3 filesystems, they will returned sorted by the hash of the
filename --- effectively a random order.  (Since the hash also
includes a secret, random, per-filesystem secret in order to avoid
denial of service attacks by malicious users who might otherwise try
to create huge numbers of files containing hash collisions.)

I would be very, very surprised if reiserfs returned files in creation
order.  The fundamental problem is that the
readdir()/telldir()/seekdir() API is fundamentally busted.  Yes,
Dennis Ritchie and Ken Thompson do make mistakes, and have made many;
in this particular case, they made a whopper.  

Seekdir()/telldir() assumes a linear directory structure which you can
seek into, such that the results of readdir() are repeatable.  Posix
only allows files which are created or deleted in the interval to be
undefined; all other files must be returned in the same order as the
original readdir() stream, even if days or weeks elapse between the
readdir(), telldir(), and seekdir() calls.

Any filesystem which tries to use a B-tree like system, where leaf
nodes can be split, is going to have extreme problems trying to keep
these guarantees.  For this reason, most filesystem designers choose
to return files in b-tree order, and *not* the order in which files
were added to the directory.

It is really, really bad assumption to assume that files will be
returned in the same order as they were created.

> On ext2, as an example, stat()ting or open()ing a directory of 1
> files in the order returned by readdir() will be vastly quicker than
> in some other sequence (like, say, bytewise lexicographic) due to the
> way in which the filesystem looks up inodes. This has caused
> significant performance issues for bugs.debian.org in the past.

If you are using HTREE, and want to do a readdir() scan followed by
something which opens or stat's all of the files, you very badly will
want to sort the returned directory inodes by the inode number
(de->d_inode).  Otherwise, the order returned by readdir() will be
effectively random, with the resulting loss of performance which you
alluded to because the filesystem needs to randomly seek and ready all
around the inode table.

Why can't this be done in the kernel?  Because if the directory is 200
megabytes, then kernel would need to allocate and hold on to 200
megabytes until the userspace called closedir().  There is simply no
lightweight way to work around the problems caused by the broken API
which Ken Thompson and Dennis Ritchie designed.

The good news is that this particular optimization of sorting by inode
number should work for all filesystems, and should speed up xfs as
well as ext2/3 with HTREE.

- Ted

Re: A success story with apt and rsync

[Koblinger Egmont]

Hi,

On 6 Jul 2003, Goswin Brederlow wrote:

> 2. most of the time you have no old file to rsync against. Only
> mirrors will have an old file and they already use rsync.

This is definitely true if you install your system from CD's and then
upgrade it. However, if you keep on upgrading from testing/unstable then
you'll have more and more packages under /var/cache/apt/archives so it
will have more and more chance that an older version is found there. Or,
alternatively, if you are sitting behind a slow modem and "apt-get
upgrade" says it will upgrade "extremely-huge-package", then you can still
easily insert your CD and copy the old version of "extremely-huge-package"
to /var/cache/apt/archives and hit ENTER to apt-get afterwards.

> 3. rsyncing against the previous version is only possible via some
> dirty hack as apt module. apt would have to be changed to provide
> modules access to its cache structure or at least pass any previous
> version as argument. Some mirror scripts alreday use older versions as
> templaes for new versions.

Yes, this is what I've hacked together based on other people's great work.
It is (as I've said too) a dirty hack. If a more experienced apt-coder can
replace my hard-coded path with a mechanism that tells this path to the
module, then this hack won't even be dirty.

> 4. (and this is the knockout) rsync support for apt-get is NO
> WANTED. rsync uses too much resources (cpu and more relevant IO) on
> the server side and a widespread use of rsync for apt-get would choke
> the rsync mirrors and do more harm than good.

It might be no wanted for administrators, however, I guess it is wanted to
many of the users (at least for me :-)) I don't see the huge load of the
server (since I'm the only one rsyncing from it), but I see the huge
difference in the download time. If my download wasn't faster because of
an overloaded server, I would switch back to FTP or anything which is
better to me as an end user.

I understand that rsync causes a high load on the server when several
users are connected, and so it is not suitable as a general replacement
for ftp, however I think it is suitable as an alternative. I also don't
expect the Debian team itself to set up a public rsync server for the
packages. However, some mirrors might want to set up an rsync server
either for the public or for example a university for its students.

Similar hack could be simply used by people who have account to a machine
with high bandwidth. For example if I used Debian and Debian had rsyncable
packages, but no public rsync server was available, I'd personally mirror
Debian to a machine at the university using FTP and would use rsync from
that server to my home machine to save traffic where the bandwidth is a
bottleneck.

So I don't think it's a bad idea to set up some public rsync servers
worldwide. The maximum number of connections can be set up so that cpu
usage is limited somehow. It's obvious that if a user often gets the
connection refused then he will switch back to ftp or http. Hence I guess
that the power of the public rsync servers and the users using rsync would
somehow be automatically balanced, it doesn't have to be coordinated
centrally. So IMHO let anybody set up an rsync server if he wants to, and
let the users use rsync if they want to (but don't put an rsync:// line
in the default sources.list).


> All together I think a extended bittorrent module for apt-get is by
> far the better sollution but it will take some more time and designing
> before it can be implemented.

It is very promising and I really hope that it will be a good protocol
with a good implementation and integration to apt. But until this is
realized, we still could have rsync as an alternative, if Debian packages
were packed in a slightly different way.



bye,

Egmont

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Theodore Ts'o]

On Sat, Jul 05, 2003 at 11:57:35PM +0200, Falk Hueffner wrote:
> Ralf Treinen <[EMAIL PROTECTED]> writes:
> > > E2tools is a simple set of GPL'ed utilities to read, write, and
> > > manipulate files in an ext2/ext3 filesystem.
> > 
> > please excuse my ignorance - what would be the advantage of these
> > tools over the core file utilities which use the VFS layer?
> 
> You don't need root. Useful for example to build rescue floppy images.

Actually, you can do this with debugfs.  That's how Real Men (tm)
build their initial bootstrap images.  (i.e., Linus Torvalds, when he
was first bootstrapping the Alpha port.)

That being said, the e2tools does have an easier to use user interface
than debugfs, and reduces the chance that user will harm himself; sort
of like the difference between using an Exacto knife and one of those
scissors with rounded ends that gets handed out to pre-schoolers.  :-)
That's not a bad thing, and certainly I'm not saying it shouldn't be
packaged.  In fact, I think it's a good thing, just as like the mtools
suite is useful even though we have the msdos filesystem in the
kernel.

However, I've taken a quick look at it, and I do have some
warnings:

*) It looks like upstream hasn't released a new version since July or
August 2002.  Before that, releases were happening regularly.  Is the
author Keith Sheffield (cc'ed on this note), still maintaining the
package?  

*) It badly needs to be autoconfiscated.  

*) Currently it hardcodes the path to static libraries in
../e2fsprogs-1.27/lib/...; it should use the shared version of the
libraries.

*) It's missing man pages

*) It needs testing against a variety of newer versions of ext2fs to
make sure the code actually works well with filesystems with htree
filesystems and extended attributes.  Upon brief inspection, I can see
that it's not dropping the refcount on the extended attribute block
when deleting a file, and freeing the extended attribute block when
the refcount goes to zero.

This is no shame; it merely shows the age of the code, and to be
honest, the rm function in debugfs doesn't do this correctly either
--- I'll put that on my "to fix" list.  However, there is the implicit
promise thatuserland packages such as e2tools will work correctly,
whereas debugfs sets a much lower level of expectations, since it's
assumed to be a wizard-level tool, with sharp pointy edges upon which
naive users can hurt themselves if they are not careful.

What it *does* show is that e2tools badly needs a test suite, which
takes a bunch of filesystems, does various e2tools operations on it,
and then runs e2fsck on the filesystem to make sure the resulting
filesystem is still valid.  I have not run any tests on it, so I can't
be sure the extended attribute block handling is the only issue.  I
*think* it should be just fine with htree directories, since the
libext2fs library handles a lot of the issues automatically.  But
until you run tests --- preferably automated test suites --- you can
never be sure.


The bottom-line is that e2tools shows a lot of promise, but there's
also a lot of work that could be put into it in order to improve its
quality.  Perhaps upstream could be convinced to tackle some of the
work, or at the very least, accept patches that you feed back to him.

- Ted

Re: NEWS.Debian support is here

[David B Harris]

On Sun Jul 06, 04:58pm -0400, Matt Zimmerman wrote:
> On Sun, Jul 06, 2003 at 04:31:22PM -0400, Matt Zimmerman wrote:
> 
> > On Sun, Jul 06, 2003 at 07:13:23PM +0100, Scott James Remnant wrote:
> > > Would this work just as well?
> > > [example without distribution and urgency]
> > 
> > It would work just as well.  The changelog format was used unmodified for
> > purposes of simplicity.  Tools already know how to parse it, and its format
> > is already reasonably specified in the documentation.
> 
> To clarify, I meant that such a format would meet the need of NEWS.Debian.
> However, the existing tools would not understand it.
> 
> I do not see the extra unused information as a problem, and it lets us use
> existing tools for creating and editing NEWS.Debian (debchange, dpkg-dev-el,
> etc.)

If you can make apt-listchanges understand the pared-down format,
perhaps the others will support it eventually too.

I don't care a whole lot about it myself, but it *does* look a lot nicer
:)

Re: A success story with apt and rsync

[Andrew Suffield]

On Sun, Jul 06, 2003 at 10:28:07PM +0200, Koblinger Egmont wrote:
> 
> On Sun, 6 Jul 2003, Andrew Suffield wrote:
> 
> > It should put them in the package in the order they came from
> > readdir(), which will depend on the filesystem. This is normally the
> > order in which they were created, and should not vary when
> > rebuilding. As such, sorting the list probably doesn't change the
> > network traffic, but will slow dpkg-deb down on packages with large
> > directories in them.
> 
> Yes, when saying "random order" I obviously ment "in the order readdir()
> returns them". It's random for me.  :-)))
> 
> It can easily be different on different filesystems, or even on same
> type of filesystems with different parameters (e.g. blocksize).

I can't think of any reason why changing the blocksize would affect
this. Most filesystems return files in the sequence in which they were
added to the directory. ext2, ext3, and reiser all do this; xfs is the
only one likely to be used on a Debian system which doesn't.

> I even think it can be different after a simple rebuild on exactly the
> same environment. For example configure and libtool like to create files
> with the PID in their name, which can take from 3 to 5 digits. If you
> create the file X and then Y, remove X and then create Z then it is most
> likely that if Z's name is shorter than or equal to the length of filename
> X, then it will be returned first by readdir(), while if its name is
> longer, then Y will be returned first and Z afterwards. So I can imagine
> situations where the order of the files depend on the PIDs of the build
> processes.

This lengthly bit of handwaving has no connection with reality.

> However, I think sorting the files costs really nothing. My system is not
> a very new one, 375MHz Celeron, IDE disks, 384MB RAM etc... However:
> 
> /usr/lib$ du -s .
> 1,1G.
> /usr/lib$ find . -type f | wc -l  # okay, it's now in memory cache
>   18598
> /usr/lib$ time find . >/dev/null 2>&1
> 
> real0m0.285s
> user0m0.100s
> sys 0m0.150s
> [EMAIL PROTECTED]:/usr/lib$ time sortdir find . >/dev/null 2>&1
> 
> real0m1.683s
> user0m1.390s
> sys 0m0.250s
> 
> 
> IMHO a step which takes one and a half seconds before compressing 18000
> files of more than 1 gigabytes shouldn't be a problem.

This test only shows that you don't understand what is going on; it
has no relation to the problems that can occur.

On ext2, as an example, stat()ting or open()ing a directory of 1
files in the order returned by readdir() will be vastly quicker than
in some other sequence (like, say, bytewise lexicographic) due to the
way in which the filesystem looks up inodes. This has caused
significant performance issues for bugs.debian.org in the past.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ | Dept. of Computing,
 `. `'  | Imperial College,
   `- -><-  | London, UK


pgp5SqrSYg0gQ.pgp
Description: PGP signature

Re: NEWS.Debian support is here

[Matt Zimmerman]

On Sun, Jul 06, 2003 at 04:31:22PM -0400, Matt Zimmerman wrote:

> On Sun, Jul 06, 2003 at 07:13:23PM +0100, Scott James Remnant wrote:
> > Would this work just as well?
> > [example without distribution and urgency]
> 
> It would work just as well.  The changelog format was used unmodified for
> purposes of simplicity.  Tools already know how to parse it, and its format
> is already reasonably specified in the documentation.

To clarify, I meant that such a format would meet the need of NEWS.Debian.
However, the existing tools would not understand it.

I do not see the extra unused information as a problem, and it lets us use
existing tools for creating and editing NEWS.Debian (debchange, dpkg-dev-el,
etc.)

-- 
 - mdz

Re: A success story with apt and rsync

[Koblinger Egmont]

On Sun, 6 Jul 2003, Andrew Suffield wrote:

> It should put them in the package in the order they came from
> readdir(), which will depend on the filesystem. This is normally the
> order in which they were created, and should not vary when
> rebuilding. As such, sorting the list probably doesn't change the
> network traffic, but will slow dpkg-deb down on packages with large
> directories in them.

Yes, when saying "random order" I obviously ment "in the order readdir()
returns them". It's random for me.  :-)))

It can easily be different on different filesystems, or even on same
type of filesystems with different parameters (e.g. blocksize).

I even think it can be different after a simple rebuild on exactly the
same environment. For example configure and libtool like to create files
with the PID in their name, which can take from 3 to 5 digits. If you
create the file X and then Y, remove X and then create Z then it is most
likely that if Z's name is shorter than or equal to the length of filename
X, then it will be returned first by readdir(), while if its name is
longer, then Y will be returned first and Z afterwards. So I can imagine
situations where the order of the files depend on the PIDs of the build
processes.

However, I guess or goal is not only to produce similar packages from
exactly the same source. It's quite important to produce similar package
even after a version upgrade. For example you have a foobar-0.9 package,
and now upgrade to foobar-1.0. The author may have completely rewritten
Makefile which yields in nearly the same executable, the same data files,
but completely different "random" order.


However, I think sorting the files costs really nothing. My system is not
a very new one, 375MHz Celeron, IDE disks, 384MB RAM etc... However:

/usr/lib$ du -s .
1,1G.
/usr/lib$ find . -type f | wc -l  # okay, it's now in memory cache
  18598
/usr/lib$ time find . >/dev/null 2>&1

real0m0.285s
user0m0.100s
sys 0m0.150s
[EMAIL PROTECTED]:/usr/lib$ time sortdir find . >/dev/null 2>&1

real0m1.683s
user0m1.390s
sys 0m0.250s


IMHO a step which takes one and a half seconds before compressing 18000
files of more than 1 gigabytes shouldn't be a problem.




cheers,
Egmont

Re: NEWS.Debian support is here

[Matt Zimmerman]

On Sun, Jul 06, 2003 at 07:13:23PM +0100, Scott James Remnant wrote:

> On Fri, 2003-07-04 at 06:01, Joey Hess wrote:
> 
> > The file format is the same as a debian changelog file, but we leave off the
> > asterisks generally, and use bigger paragraphs explaining news items when
> > necessary. It might be a good idea to run your file through
> > dpkg-parsechangelog to check its formatting as it will not be automatically
> > checked during build as the changelog is. I expect there will be a lintian
> > check eventually. Here's a real life example of a NEWS.Debian file:
> > 
> > libinline-perl (0.43-5) unstable; urgency=low
> 
> Is there any particular reason to keep the "unstable; urgency=low"
> there?  It's duplication of information in the changelog, and nearly
> every developer will probably forget to change the information in
> NEWS.Debian when they change the urgency or distribution in changelog.
> 
> Would this work just as well?
> [example without distribution and urgency]

It would work just as well.  The changelog format was used unmodified for
purposes of simplicity.  Tools already know how to parse it, and its format
is already reasonably specified in the documentation.

> Scott
> -- 
> Who would forget every time :-)

You don't type changelog headers by hand, do you?

-- 
 - mdz

Re: Juridical prosecution

[Thomas Viehmann]

Leandro GuimarÃes Faria Corsetti Dutra wrote:
> On Sat, 05 Jul 2003 17:57:07 +0200, Martin Sobek wrote:
>>You place your page on address www.sobek-sobek.com unlawfully! Remove it
>>immediately or you risk juridical prosecution.
>   And the cluelessness Oscar this year goes too... Mr Sobek!

Oh, that's why sun always has this indemnification thing in their licenses.
Maybe Debian should...

Cheers

T.


pgpyyKTs2ZUYq.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Marc Haber wrote:
> On Sun, 06 Jul 2003 15:00:18 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
> wrote:
> 
>>As far as the eicar license is concerned: Is it really that difficult to 
>>obtain
>>a statement from eicar on whether or not they believe that the test file is
>>copyrightable and maybe a general permission to distribute the file? From your
>>comment I guess you tried,
> Actually, I tried three times. Once via the official contacts listed
> on the eicar web page, and once via the domain contacts for eicar.com.
> In both cases, my e-mail was completely ignored.

How about phoning them? [0]
There's a German phone number for the executive secretary. If nothing else, he
might be able to point you in the correct directions. You could also try phoning
Urs Gattiker...
(I've had bad experiences with phoning via 01024 to Denmark though.)

Cheers

T.

0. http://www.eicar.org/inside.htm#office


pgpKpZ7BkTdTV.pgp
Description: PGP signature

Re: Juridical prosecution

[Branden Robinson]

On Sat, Jul 05, 2003 at 09:52:06PM +0200, Leandro Guimarães Faria Corsetti 
Dutra wrote:
> On Sat, 05 Jul 2003 17:57:07 +0200, Martin Sobek wrote:
> 
> > You place your page on address www.sobek-sobek.com unlawfully! Remove it
> > immediately or you risk juridical prosecution.
> 
>   And the cluelessness Oscar this year goes too... Mr Sobek!

But the competition is always so fierce, and the year isn't over yet...

-- 
G. Branden Robinson| It just seems to me that you are
Debian GNU/Linux   | willfully entering an arse-kicking
[EMAIL PROTECTED] | contest with a monstrous entity
http://people.debian.org/~branden/ | that has sixteen legs and no arse.


pgpBryv81Muln.pgp
Description: PGP signature

Re: Debconf and XFree86 X servers

[Branden Robinson]

On Sun, Jul 06, 2003 at 01:09:21AM +0200, Goswin Brederlow wrote:
> Branden Robinson <[EMAIL PROTECTED]> writes:
> 
> > [Please direct any XFree86-specific followup to debian-x.]
> > 
> > On Sat, Jul 05, 2003 at 08:46:00AM -0400, Theodore Ts'o wrote:
> > > Yet another reasons for wanting to decouple installation and
> > > configuration is if some hardware company (such as VA^H^H Emperor
> > > Linux) wishes to ship Debian pre-installed on the system.  In that
> > > case, installation happens at the factory, and not when the user
> > > receives it in his/her hot little hands.
> 
> So they should just provide a "setup.sh" script that calls
> dpkg-reconfigure for relevant packages again.
> 
> Otherwise just type in "dpkg-reconfigure --all" and spend hours
> configuring your system as much as you like.

1) Why did you follow-up to a message of mine, but not include *any* of
   my quoted text?
2) Why did you follow-up with a non-XFree86-specific message to
   debian-x?

Please be more judicious in your use of your MUA.

-- 
G. Branden Robinson| I suspect Linus wrote that in a
Debian GNU/Linux   | complicated way only to be able to
[EMAIL PROTECTED] | have that comment in there.
http://people.debian.org/~branden/ | -- Lars Wirzenius


pgpOavO8WHD4D.pgp
Description: PGP signature

Re: Please remove RFCs from the documentation in Debian packages

[Branden Robinson]

On Sun, Jul 06, 2003 at 12:23:16PM +0200, Javier Fernández-Sanguino Peña wrote:
> Could you please point to the discussion you mention that makes that
> content out of date? I thought I pretty much cover all the -legal
> discussions to date at
> http://www.debian.org/doc/manuals/ddp-policy/footnotes.en.html#f3. But
> maybe the status from december to current date has changed. Branden said
> back then:
> 
> "The GNU FDL, version 1.2, is not necessarily DFSG-non-free when applied
> to a work, but it can be employed in ways that are DFSG-non-free."
> (http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00285.html)

I've changed my mind about that, thanks in no small measure to the
observations of a lot of other people.

> However, you (as well as any other DD), of course, know you have CVS r/w
> access to the DDP Policy document to update it as needed. Don't you? That
> would be _much_ more useful than saying "so it's worse than useless", mind
> you. It's hard to make a proper document regarding documentation licensing
> if
> 
> a) debian-legal "consensus" switches mindset every other day

We don't change mindset "every other day".  We've changed it after six
months.

> b) people at debian-legal do not keep people at debian-doc up-to-date to
> latest consensus wrt to documentation licensing (yes, until somebody who is
> at -doc says "please RTFM" and somebody at -legal says "TFM is worthless")

Perhaps debian-legal needs its own document, to which the DDP document
can merely refer.

> PS: Notice that, as far as I see, Aj's post on debian-legal (is that the
> current "consensus"?) implies that GFDL documents _can_ be DFSG-free
> http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00246.html

That summary is correct as far as it goes, but it does not enumerate all
of the problems that have been found with the GNU FDL.

If and only if:

1) there are no Invariant Sections
2) there are no Cover Texts
3) there are no Acknowledgements
4) there are no Dedications
5) the restrictions on copying in quantity are waived

...and that's not even a complete list.

-- 
G. Branden Robinson|I must confess to being surprised
Debian GNU/Linux   |by the magnitude of incompatibility
[EMAIL PROTECTED] |with such a minor version bump.
http://people.debian.org/~branden/ |-- Manoj Srivastava


pgpP4aqnYcyDI.pgp
Description: PGP signature

Re: NEWS.Debian support is here

[Scott James Remnant]

On Fri, 2003-07-04 at 06:01, Joey Hess wrote:

> The file format is the same as a debian changelog file, but we leave off the
> asterisks generally, and use bigger paragraphs explaining news items when
> necessary. It might be a good idea to run your file through
> dpkg-parsechangelog to check its formatting as it will not be automatically
> checked during build as the changelog is. I expect there will be a lintian
> check eventually. Here's a real life example of a NEWS.Debian file:
> 
> libinline-perl (0.43-5) unstable; urgency=low

Is there any particular reason to keep the "unstable; urgency=low"
there?  It's duplication of information in the changelog, and nearly
every developer will probably forget to change the information in
NEWS.Debian when they change the urgency or distribution in changelog.

Would this work just as well?

libinline-perl (0.43-5)

  Note that when you upgrade from perl 5.6 to 5.8, binaries built with
  libinline (this may include compiled objects cached in .Inline/_Inline
  directories) will fail to work with the new version of perl. This is
  because perl's ABI for binaries changed between perl 5.6 and 5.8.

  The solution is the delete and regenerate any such binaries you might have.
  I have not tried to automate this in the Debian package.

 -- Joey Hess <[EMAIL PROTECTED]>  Wed, 11 Sep 2002 21:37:56 -0400

?

Scott
-- 
Who would forget every time :-)


signature.asc
Description: This is a digitally signed message part

Re: Bug#200153: ITP: e2tools -- utilities for manipulating files in an ext2/ext3 filesystem

[Robert Millan]

On Sat, Jul 05, 2003 at 11:35:29PM +0200, Ralf Treinen wrote:
> On Sat, Jul 05, 2003 at 05:24:21PM +0200, Robert Millan wrote:
> > 
> > E2tools is a simple set of GPL'ed utilities to read, write, and manipulate
> > files in an ext2/ext3 filesystem.
> 
> please excuse my ignorance - what would be the advantage of these
> tools over the core file utilities which use the VFS layer?

The problem is that for monolithic kernels the filesystem code lies in
kernelspace, hence for security reasons filesystems can only be attached
(via mount) by root. (This isn't applicable to the GNU system, though,
since Hurd's ext2fs is implemented as a userspace server that normal users
can run)

With this utils, normal users still can't use standard filesystem C library
calls over their custom ext2fs image, but may use commands like e2cp or
e2mkdir for basic manipulation.

Btw, I need this to integrate grub-disk into the grub package (see #190392).

-- 
Robert Millan

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Marc Haber]

On Sun, 06 Jul 2003 15:00:18 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
wrote:
>As far as the eicar license is concerned: Is it really that difficult to obtain
>a statement from eicar on whether or not they believe that the test file is
>copyrightable and maybe a general permission to distribute the file? >From your
>comment I guess you tried,

Actually, I tried three times. Once via the official contacts listed
on the eicar web page, and once via the domain contacts for eicar.com.
In both cases, my e-mail was completely ignored.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

On Sun, 2003-07-06 at 01:52, Nick Phillips wrote:
> Actually I think the simplest form would be to have /etc/resolvconf/notify.d
> and run all scripts in there at the relevant times, with any necessary
> arguments (which would be standard).

Please take a look at how resolvconf runs the scripts in 
/etc/resolvconf/update.d/ and let me know if you think
anything else is needed.

Alioth was down for a while but I just checked and the deb
is once again available (in the "resolvconf" section of the
update-resolv project).
  http://alioth.debian.org/project/showfiles.php?group_id=1227

--
Thomas

Re: A success story with apt and rsync

[Martijn van Oosterhout]

On Sun, Jul 06, 2003 at 12:37:00PM +1200, Corrin Lakeland wrote:
> > 4. (and this is the knockout) rsync support for apt-get is NO
> > WANTED. rsync uses too much resources (cpu and more relevant IO) on
> > the server side and a widespread use of rsync for apt-get would choke
> > the rsync mirrors and do more harm than good.
> 
> When I was looking into this I heard about some work into caching the rolling 
> checksums to eliminate server load. I didn't find any code.

That would be because the checksums would take at least 8 times the space of
the original files. You need the backward-rsync which was patented last I
heard.

-- 
Martijn van Oosterhout  http://svana.org/kleptog/
> "the West won the world not by the superiority of its ideas or values or
> religion but rather by its superiority in applying organized violence.
> Westerners often forget this fact, non-Westerners never do."
>   - Samuel P. Huntington


pgpMZ4tlXA1It.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Marc Haber wrote:
> On Sun, 06 Jul 2003 11:03:37 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
> wrote:
>>*Look* at #198311 and search for debian-devel and then ask yourself why Marc
>>thinks that -devel should only be used as a forum to discredit ftpmasters 
>>work,
>>and not as a place where ITPs should be reviewed.
> That was indeed an omission, caused by the fact that I filed an RFP
> first and later retitled the bug to ITP. Surely you never make any
> mistakes.
I make a lot of mistakes. (That's why I prefer working on computers/math over
things like medicine.)

In fact, I made a similar mistake with the ITP of libchipcard (IIRC) because the
X-Debbugs-CC got lost because I usually call reportbug -p and copy stuff into my
mailclient when reporting bugs. (And it might be a reasonable idea to
investigate posting ITPs on debian-devel by other means than the
X-Debbug-CC-Header so such obmissions are impossible).

However, I sincerely believe that without this obmission, the ITP might have
been shot down (or held reasonable) before the upload (and possibly before the
creation) of the package. Thus (leaving the style issue that upset you aside) I
think that the (technical) merit of your complaint is somewhat limited.

As far as the eicar license is concerned: Is it really that difficult to obtain
a statement from eicar on whether or not they believe that the test file is
copyrightable and maybe a general permission to distribute the file? From your
comment I guess you tried, but quite possibly they understand better Debian's
concern about licensing with all the publicity the SCO lawsuit has.

That said, I see additional issues with the inclusion of the eicar file (aside
from the obvious point that probably it'd rest just as well in another package
containing a virus scanner): Debian mirrors and CDs will be quite possibly be
identified as carrying virii.
Quite possibly, it's reasonable to "obfuscate" (in a documented way) the file
(e.g. xor it and provide a program for decryption) or include a script or
download instructions rather than the file itself. Possibly, even the original
installer package looks a lot less silly on second thought.

Cheers

T.


pgpIIa5GHxRAZ.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Marc Haber]

On Sun, 06 Jul 2003 11:03:37 +0200, Thomas Viehmann <[EMAIL PROTECTED]>
wrote:
>*Look* at #198311 and search for debian-devel and then ask yourself why Marc
>thinks that -devel should only be used as a forum to discredit ftpmasters work,
>and not as a place where ITPs should be reviewed.

That was indeed an omission, caused by the fact that I filed an RFP
first and later retitled the bug to ITP. Surely you never make any
mistakes.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber  |   " Questions are the | Mailadresse im Header
Karlsruhe, Germany  | Beginning of Wisdom " | Fon: *49 721 966 32 15
Nordisch by Nature  | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

On Sun, 2003-07-06 at 12:42, Eduard Bloch wrote:
> Please, would you consider to add another feature: priorising some
> entries depending on the source.  That means:
>
> pppoeconf's and pppconfig's script run the tool with parameter "--class
> dialup", dhcp clients with "--class dynamic" and the default class would
> be static. In some config file, the user defines that "dialup" gets
> priority one, "dynamic" two and static three (for example), and
> resolvconf merges the existing dns entries in the appropriate order.

Let me start by saying that resolv.conf is generated by
/etc/resolvconf/update.d/libc , which, being a conffile,
can be customized by the admin.

Your idea strikes me as a good one.  It would add some
complexity to the system, but it would provide more
information for /etc/resolvconf/update.d/libc to use when
it generates the resolv.conf file.  Currently the script
discriminates only on the basis of interface type (i.e.,
lo, ppp or eth).

However, I would only want to add this feature if we were
certain that it was needed.

--
Thomas Hood

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

> On Sun, 2003-07-06 at 12:13, Thomas Hood wrote:
> > No, I meant that before entering the Debian archive it would
> > be nice if resolvconf were supported by all packages that
> > currently futz with /etc/resolv.conf, including pump and bind.
> Which other packages?

I guess I need to explain more clearly.  First.  Currently,
making certain packages work with resolvconf requires some
manual changes to configuration files.  The changes are not
large: just adding a couple of lines to initscripts and such.
Still, I think it would be nice if such packages worked with
resolvconf -- if resolvconf happens to be installed -- without
requiring any manual changes.  I won't explain here how this
can be done; please see the announcement and bug reports
#194204 and #199255 for details.

At the moment, the only packages I know of that need some
adaptation are pump and bind.  There are probably others.
Someone has mentioned squid, so I will investigate squid
later today, but at first glance it looks as if no changes
to squid will be required.

Second, resolvconf's usefulness in allowing the relocation of
variable files out of /etc/ will be greatest if packages that
currently write resolver information into files in /etc/ , such
as pump, are changed so that when resolvconf is installed they
send that information to resolvconf instead.  Again, please see
#194204.

My aim is not to make resolvconf mandatory; it is to have
packages work properly with resolvconf *if* resolvconf is
installed.  When resolvconf is not installed, other packages
should continue to do what they did before.

--
Thomas Hood

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Eduard Bloch]

#include 
* Thomas Hood [Sat, Jul 05 2003, 09:51:56PM]:
> Summary
> ~~~
> Resolvconf is a proposed standard framework for updating the
> system's information about currently available nameservers.
> 
> Most importantly, it manages /etc/resolv.conf , but it does 
> a bit more than that.

The Idea is great, it would solve the long outstanding dispute between
me (pppoeconf) and pppconfig maintainer. Please, would you consider to
add another feature: priorising some entries depending on the source.
That means: 

pppoeconf's and pppconfig's script run the tool with parameter "--class
dialup", dhcp clients with "--class dynamic" and the default class would
be static. In some config file, the user defines that "dialup" gets
priority one, "dynamic" two and static three (for example), and
resolvconf merges the existing dns entries in the appropriate order.

Please also note that it would (IMHO) be a good idea to manage the
"search" list with a similar priority table, so the provider's domain is
appended or prepended (as user wishes it).

MfG,
Eduard.
-- 
 isga: versuch mal 'apt-cache search girl friend'  :-) du wirst
überrascht sein

Re: A success story with apt and rsync

[Jonathan Oxer]

On Sun, 2003-07-06 at 09:27, Goswin Brederlow wrote:
> 4. (and this is the knockout) rsync support for apt-get is NO
> WANTED. rsync uses too much resources (cpu and more relevant IO) on
> the server side and a widespread use of rsync for apt-get would choke
> the rsync mirrors and do more harm than good.

One way to alleviate this would be to only generate the deltas once on
server-side when first requested, then cache them on disk to be served
out like any other static file for reconstruction of the new package on
the client-side using rsync.

I've been thinking for a while about trying to build this into
Apt-cacher.

Jonathan

Re: Please remove RFCs from the documentation in Debian packages

[Javier Fernández-Sanguino Peña]

On Fri, Jul 04, 2003 at 07:30:56PM +0100, Andrew Suffield wrote:
> On Fri, Jul 04, 2003 at 07:47:32PM +0200, Thomas Viehmann wrote:
> > Andrew Suffield wrote:
> > >>people to  
> > >>http://www.debian.org/doc/manuals/ddp-policy/ch-common.en.html. 
> > > This claims the GNU FDL is acceptable, so it's worse than useless.
> > It claims that GNU FDL sans cover texts and invariant sections is 
> > acceptable.
> 
> Which is grossly out of date (read: wrong). This has been discussed to
> death on -legal.

Could you please point to the discussion you mention that makes that
content out of date? I thought I pretty much cover all the -legal
discussions to date at
http://www.debian.org/doc/manuals/ddp-policy/footnotes.en.html#f3. But
maybe the status from december to current date has changed. Branden said
back then:

"The GNU FDL, version 1.2, is not necessarily DFSG-non-free when applied
to a work, but it can be employed in ways that are DFSG-non-free."
(http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00285.html)

However, you (as well as any other DD), of course, know you have CVS r/w
access to the DDP Policy document to update it as needed. Don't you? That
would be _much_ more useful than saying "so it's worse than useless", mind
you. It's hard to make a proper document regarding documentation licensing
if

a) debian-legal "consensus" switches mindset every other day

b) people at debian-legal do not keep people at debian-doc up-to-date to
latest consensus wrt to documentation licensing (yes, until somebody who is
at -doc says "please RTFM" and somebody at -legal says "TFM is worthless")

Regards

Javi

PS: Notice that, as far as I see, Aj's post on debian-legal (is that the 
current "consensus"?) implies that GFDL documents _can_ be DFSG-free
http://lists.debian.org/debian-legal/2003/debian-legal-200304/msg00246.html


pgpEdfyVYzwme.pgp
Description: PGP signature

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

On Sun, 2003-07-06 at 01:32, Marco d'Itri wrote:
> On Jul 05, Thomas Hood <[EMAIL PROTECTED]> wrote:
>  >* Before entering the Debian archive it would be nice if resolvconf
>  >  were supported by all packages that currently futz with
>  >  /etc/resolv.conf, including pump and bind.
> If you mean that if should be mandatory to install this package on every
> name server, then it would not be nice at all.

No, I meant that before entering the Debian archive it would
be nice if resolvconf were supported by all packages that
currently futz with /etc/resolv.conf, including pump and bind.

--
Thomas Hood

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

On Sun, 2003-07-06 at 01:00, Goswin Brederlow wrote:
> You should think of a mechanism for daemons to get notified about
> changes in resolv.conf.

There is already such a mechanism.  See below.

> Like providing a function to register a script
> and a list of arguments (like the PID of the program to
> notify). Whenever the resolv.conf changes all currently registered
> scripts would be called with their respective arguments.
> 
> The simplest form would be:
> 
> resolv.conf-register /etc/init.d/squid reload
> 
> That would make squid to reload its config each time a nameserver is
> added or removed.

Currently, scripts in /etc/resolvconf/update.d/ get run when
resolver information changes.  So, would it suffice to create
/etc/resolvconf/update.d/squid containing the following?
#!/bin/sh
/etc/init.d/squid reload

--
Thomas Hood

Re: Resolvconf -- a package to manage /etc/resolv.conf

[Thomas Hood]

On Sat, 2003-07-05 at 22:40, Simon Hürlimann wrote:
> I'd prefer update-resolv like
>  update-alternatives update-initrd
>  update-catalog  update-ispell-dictionary
>  update-default-aspell   update-menus
>  update-default-ispell   update-mime
> to name just a few.

Resolvconf isn't really comparable to the update-* utilities.
Unlike them, resolvconf takes information on its standard input.
And unlike them, it run during "normal" use of the machine, not
at administration time.  The update-* programs usually modify
files in /etc/, whereas one of the reasons for creating
resolvconf is to avoid modifying files in /etc/.

--
Thomas Hood

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Thomas Viehmann]

Andreas Barth wrote:
> * Thomas Viehmann ([EMAIL PROTECTED]) [030705 23:50]:
> 
>>So why is the recommendation against skipping the ITP to aviod problems in
>>ftpmaster review "not right"?
> A (strong) recommendation for doing ITPs right is right and usefull.
> But - all foreseeable problems should be handeled at ITP-time, and
> that's not the case. So the recommendation is right, but it doesn't
> solve the problem Marc spoke of.

I doubt that an eicar-installer ITP would have survived the scrutiny of devel.
So it may not solve the general problem Marc about but it solves a very good
share of it, most likely *including* the very specific instance he had problems
with.

If you can't come up with a case where the ITP review was positive and ftpmaster
rejected the package in itself with a unforseeable reason (regarding a problem
that cannot be fixed), I fail to see any merit in your argument.
There's no point in establishing VIP review for people who are think they are
too important for  undergoing peer review.

*Look* at #198311 and search for debian-devel and then ask yourself why Marc
thinks that -devel should only be used as a forum to discredit ftpmasters work,
and not as a place where ITPs should be reviewed.

Cheers

T.


pgp0n7r2FptNY.pgp
Description: PGP signature

Re: eicar.com installer in Debian, and pre-upload interface to ftpmaster

[Andreas Barth]

* Thomas Viehmann ([EMAIL PROTECTED]) [030705 23:50]:
> So why is the recommendation against skipping the ITP to aviod problems in
> ftpmaster review "not right"?

A (strong) recommendation for doing ITPs right is right and usefull.
But - all foreseeable problems should be handeled at ITP-time, and
that's not the case. So the recommendation is right, but it doesn't
solve the problem Marc spoke of.


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Juridical prosecution

[Leandro Guimarães Faria Corsetti Dutra]

On Sat, 05 Jul 2003 17:57:07 +0200, Martin Sobek wrote:

> You place your page on address www.sobek-sobek.com unlawfully! Remove it
> immediately or you risk juridical prosecution.

And the cluelessness Oscar this year goes too... Mr Sobek!


-- 
 _
/ \  Leandro GuimarÃes Faria Corsetti Dutra +41 (21) 648 11 34
\ /  http://br.geocities.com./lgcdutra/ +41 (78) 778 11 34
/ \  Answer to the list, not to me directly!+55 (11) 5686 2219
Rate this post if helpful: http://svcs.affero.net/rm.php?r=leandro

VIRUS EN SU CORREO

[webmaster]

   A L E R T  V I R U S  

Nuestro antivirus ha encontrado 

W32/Sobig.E 

virus(es) en su correo dirigido a los siguientes destinatario(s):

-> [EMAIL PROTECTED]

La entrega del mensaje ha sido detenida!

Por favor, compruebe la presencia de virus en sus sistema o pida a su 
administrador
que lo haga.

Para su referencia estas son las cabeceras de su mensaje:

- BEGIN HEADERS -
Received: from MAT (185.Red-80-37-98.pooles.rima-tde.net [80.37.98.185])
by artemisa.servinetred.com (Postfix) with ESMTP id AB9E252143
for <[EMAIL PROTECTED]>; Sun,  6 Jul 2003 07:21:55 +0200 (CEST)
From: 
To: <[EMAIL PROTECTED]>
Subject: Re: Movie
Date: Sun, 6 Jul 2003 7:22:34 +0200
Importance: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.
X-MSMail-Priority: Normal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="CSmtpMsgPart123X456_000_01C78799"
Message-Id: <[EMAIL PROTECTED]>
-- END HEADERS --

Re: Debconf or not debconf : Conclusion

[Steve Langasek]

On Sun, Jul 06, 2003 at 03:24:57PM +1000, Anthony Towns wrote:
> On Sat, Jul 05, 2003 at 02:28:33PM -0500, Steve Langasek wrote:
> > > Yet another reasons for wanting to decouple installation and
> > > configuration is if some hardware company (such as VA^H^H Emperor
> > > Linux) wishes to ship Debian pre-installed on the system.  In that
> > > case, installation happens at the factory, and not when the user
> > > receives it in his/her hot little hands.
> > Given the number of config questions today that have to do with
> > available hardware, I have a hard time believing that a strict split
> > between installation and configuration tasks really addresses the needs
> > of such vendors.  It also seems that all of the above are achievable
> > within the framework debconf currently provides 

> You've just contradicted yourself.

> If it's possible to achieve all of the above within the framework debconf
> currently provides, then a strict split between installation (preinst,
> unpack and postinst) and configuratin (config and templates) really
> addresses the needs of such vendors. If, on the other hand, it doesn't,
> then it's not.

Sorry, "all of the above" was meant to refer to the three different
modes of invoking the dpkg-configure command.  I believe it's possible
to provide such a split today using debconf, but I don't believe this
split addresses the needs of vendors trying to provide pre-installed
systems.


-- 
Steve Langasek
postmodern programmer


pgp6ByR9Pyttt.pgp
Description: PGP signature

Re: Debconf or not debconf : Conclusion

[Anthony Towns]

On Sat, Jul 05, 2003 at 02:28:33PM -0500, Steve Langasek wrote:
> > Yet another reasons for wanting to decouple installation and
> > configuration is if some hardware company (such as VA^H^H Emperor
> > Linux) wishes to ship Debian pre-installed on the system.  In that
> > case, installation happens at the factory, and not when the user
> > receives it in his/her hot little hands.
> Given the number of config questions today that have to do with
> available hardware, I have a hard time believing that a strict split
> between installation and configuration tasks really addresses the needs
> of such vendors.  It also seems that all of the above are achievable
> within the framework debconf currently provides 

You've just contradicted yourself.

If it's possible to achieve all of the above within the framework debconf
currently provides, then a strict split between installation (preinst,
unpack and postinst) and configuratin (config and templates) really
addresses the needs of such vendors. If, on the other hand, it doesn't,
then it's not.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

   ``Is this some kind of psych test?
  Am I getting paid for this?''


pgpF56X8iIXPj.pgp
Description: PGP signature