Your message to Consume-thenet awaits moderator approval

[consume-thenet-bounces]

Your mail to 'Consume-thenet' with the subject

Re: Your application

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.consume.net/mailman/confirm/consume-thenet/1326fd42b88c751ef5720aed4caa3701f0758946

Re: python 2.2 -> python 2.3 transition

[Anthony Towns]

On Thu, Aug 21, 2003 at 12:34:12PM +1000, Donovan Baarda wrote:
> On Wed, 2003-08-20 at 15:49, Anthony Towns wrote:
> > On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote:
> > > The negative effect for the users is that you can't upgrade python
> > > while wxgtk-python is installed so you can't try out the
> > > latest-and-greatest python in the meantime.  This is the issue at
> > > hand.
> > Sure you can:
> > $ sudo apt-get install python2.3
> > The dependency stuff merely notes that upgrading python without also
> > upgrading wxgtk-python may break stuff.
> actually, if the dependencies are right, you cannot upgrade to python
> (2.3) without also upgrading to wxgtk-python (2.3) or de-installing
> wxgtk-python (2.2).

Sure you can. dpkg --force-depends -i python_*.deb will do it for you.

If you want something bad enough, and don't mind breaking things, anything's
possible.

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


pgphsIYHZSBPS.pgp
Description: PGP signature

Re: non-DD contributors and the debian keyring

[Peter van Rossum]

On Wed, Aug 20, 2003 at 11:29:52PM +0200, Martin Quinson wrote:
> But the point is that without the key, anyone can forge mails which seem to
> come from me, and thus abuse the trust my work gained me in the mind of some
> DDs.
> 
> I see this point as necessary even if not sufficient.

Ok, a valid key gives trust that your work is really made by you. But what
this key needs is signatures from trusted people (e.g. from other Debian
developers) and for that it doesn't have to be in Debian's keyring at all.

Just send the people you work with your public key with its signatures
- you don't even have to go via any keyserver at all.

Cheers, Peter
-- 
Peter van Rossum, <[EMAIL PROTECTED]>   |  Universal law of linearity: for all
Dept. of Mathematics, New Mexico   |   f : R -> R and for all x, y in R:
State University, Las Cruces, NM, USA. |f(x + y) = f(x) + f(y)

Re: Binaryless uploads

[Jaldhar H. Vyas]

On Wed, 20 Aug 2003, Manoj Srivastava wrote:

>   Since the source goes into Debian main, keeping the sources
>  together means that we are distributing non-free material in Debian
>  main, which not only violates the social contract, it may well be
>  illegal (or have people who distribute debnian CD's indulge in
>  illegal activity), depending on how non free the non free bits are.
>
>   This needs be corrected ASAP, and a bug needs be filed on
>  ftp.debian.org to have the old sources, containing the non-fee bits,
>  be removed from main.
>

Just to clarify, the current webmin.orig.tar.gz has the source to the
non-free modules but binary packages are not built from them.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Simplicity Pattern Co. AutoReply

[Simplicity_AutoReply]

Hello,

Thank you for contacting Simplicity Pattern Co.

This Auto-Reply message is being sent to you as a convenience to let you
know that we have received your email message.  We will attempt to reply to
your email as quickly as possible. 

EXTREMELY IMPORTANT WARNING:  We DO NOT send out any spam mail or mass email
mailings.  If you have received spam email from "SimpliCity" please
understand that this is not from us.  We regret the inconvenience and are
attempting to find a solution to this problem.

Please note that our Consumer Relations Department Summer hours are Monday
through Thursday 7:30 am to 4:45pm, and Friday 7:30 am to 12:00 pm.  Our
current waiting period for a reply is approximately 3-5 days.

DO NOT REPLY to this message or send email to the address in the FROM field
of this email.  This email is generated by an email address that is NOT
monitored.

All correspondence must go to:  [EMAIL PROTECTED]

Thank you for being a Simplicity Pattern Co. customer!

Consumer Relations Dept.
Simplicity Pattern Co.
http://www.simplicity.com

stack protection

[Russell Coker]

Who is interested in stack protection?

I think it would be good to have some experiments of stack protected packages 
for Debian.  Probably the best way to do this would be to start with 
ssh-stack and sysklogd-stack being uploaded to experimental.  I don't have 
time to do this, but I would like to help test it.

Also is there any interest in uploading a kernel-image package with the grsec 
PaX support built in?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Re: python 2.2 -> python 2.3 transition

[Donovan Baarda]

On Wed, 2003-08-20 at 15:49, Anthony Towns wrote:
> On Tue, Aug 19, 2003 at 11:44:22PM -0400, Derrick 'dman' Hudson wrote:
> > The negative effect for the users is that you can't upgrade python
> > while wxgtk-python is installed so you can't try out the
> > latest-and-greatest python in the meantime.  This is the issue at
> > hand.
> 
> Sure you can:
> 
>   $ sudo apt-get install python2.3
> 
> The dependency stuff merely notes that upgrading python without also
> upgrading wxgtk-python may break stuff.

actually, if the dependencies are right, you cannot upgrade to python
(2.3) without also upgrading to wxgtk-python (2.3) or de-installing
wxgtk-python (2.2).

There is a difference between "break stuff" and "not installable" :-)

When the dependencies are right, you can't "break stuff", because a
broken combination is "not installable".

if you can then the dependencies are wrong and you should file a
bug-report.

-- 
Donovan Baarda <[EMAIL PROTECTED]>

Re: Proposal: make kernel install easier

[Manoj Srivastava]

On 20 Aug 2003 16:04:50 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said: 

> On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
> On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV
> <[EMAIL PROTECTED]> said:

>> Greetings, Installing a new kernel package can be a bit of a pain,
>> especially for newbies, what with hand-editing lilo.conf or config

>   Why on earth are you hand editing the lilo.conf file for every
>  kernel image? The postinst already manages two symlinks for you
>  that can be in the lilo.conf file.

>   If you have to hand edit lilo.conf for every kernel image, you
>   are doing something wrong.

> See my reply to Josh Lauricha: kernel-image packages corrupt the
> vmlinuz(.old) symlinks when removing a kernel, and switching between
> kernels with and without initrd.img is not supported.

You can replace the symlink handling of kernel-image packages
 on the target machine, without modifying kerel-package. And yes, lilo
 conf files can be tricky with the default symlink handling --- but
 the example postinstall hook script demonstrates that all this canm
 be handled exernally to kernel-image packages. 

>   For the clever, you can manage any number of symlinks
>  automatically for yourselves; the latest kernel-package gives
>  an example of creating a set of symlinks for 2.4 kerels,
>  another set for 2.5 kernels, and so on.

>> files for other bootloaders, from grub

>   Another bad example. For grub you do not need to muck around
>  with symlinks at all, you have update-grub, and again, the
>  kernel-package package gives examples on how to use this
>  script.

> Then /usr/lib/bootloaders/grub would be very small and easy to
> write.  My proposed mechanism would add finer-grained control of
> boot options (e.g. "apm=on" for 2.2 kernels but not 2.4) and of menu
> entry names/labels, with little additional coding.

The apm=on for 2.2 kernels can already be handled (see the
 sample postinst hook script provided for hints). I suppose
 dynamically creating labels is desirable, but all this can be a light
 weight /usr/sbin/update-lilo-conf  script. 

> Please forgive me, I had not known that a newer version of quik had
> just been uploaded which supports such features, and that's what I
> use to boot my one fully-unstable machine (i.e. not just a chroot).

quik does not follow symlinks?

> Now that there are hook scripts, this makes some sense.  But if you
> think about it for a few seconds, the "bloat" and "creeping
> featurism" of the proposed bootloader scripts is no greater than
> that required for hook scripts -- in fact, that's what they are
> (inspired by e.g.  update-cluster).

I have no idea what update-cluster is, so I doubt if they were
 inspired by that (I am an emacs user, hooks are old hat to us). In
 any case, kernel-package alreasy impolements hooks.

The fact that you came in talking about patching
 kernel-package without even being aware of current capabilities is
 disheartening -- and leads one to suggest you look at what
 kernel-image postinst does before you create new solutions. 

>   It has not only been brought up, solutions have been found and
>  have been implemented.

> Again forgive me, I had not known these solutions had been applied
> to aboot, quik, palo, etc.

So do some research about what the postinst does already. If
 you want to create a third party set of scripts to handle updating
 various boot loaders, fine. But your use cases for such a change were
 ill chosen. 

> Thank you for the kind and courteous reply,

Thank you for the courtesy of researching the problemset
 before proposing solutions.

manoj
-- 
%DCL-MEM-BAD, bad memory VMS-F-PDGERS, pudding between the ears
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: non-DD contributors and the debian keyring

[Manoj Srivastava]

On Thu, 21 Aug 2003 00:16:47 +0200, Martin Quinson <[EMAIL PROTECTED]> said: 

> Mmm. If so, I really cannot understand the big deal with IDs when
> signing the key. Knowing my ID is not enough to prove that I won't
> upload a rootkit, and it is not even needed... I must be perticulary
> dumb.

It is retaliation ;-). If your key has been signed, and
 identity known, we would know where to send the black helicopters.

> Of course, I could (and have) uploaded my key on public servers,
> meaning that other Debian member could check than a given mail with
> my address desserve the trust they habitually give me. But those
> guys would have to configure their email specifically on people like
> me[*]. I was wondering if could be avoided, that's all.

Umm, my MUA can download the keys from a keyserver all by
 itself, and verify the signature; until needed my trust is given to
 the owner of the key (as I said, the real world id is only needed for
 the pilot of the black helicopter).

manoj
-- 
Blessed is he who expects no gratitude, for he shall not be
disappointed. W.C. Bennett
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: ftp.gnu.org cracked

[Matt Zimmerman]

On Wed, Aug 20, 2003 at 07:59:13PM -0400, Joey Hess wrote:

> Since "b" has no effect in Debian anyway, it's not worth thinking about
> anymore. :-)

...except to swear under our breath about upstreams who sneak in changes
without bumping the version number (I personally find this very annoying).

-- 
 - mdz

Re: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]

[Aaron M. Ucko]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> I do have the following four cases:
> 
> 
> 
> 

It should definitely allow package-upstreamver, since that's more or
less canonical.  However, generalizing a bit and simply checking that
the name of the directory starts with the name of the source package
would allow your other cases while still avoiding things like $HOME
(unless your username happens to match the package name, but that's
probably too much of a corner case to worry about).

BTW, no need to Cc: me.  (No big deal, though.)

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.

Re: Binaryless uploads

[Manoj Srivastava]

On Wed, 20 Aug 2003 15:03:15 -0400 (EDT), Jaldhar H Vyas <[EMAIL PROTECTED]> 
said: 

> It has source for all the modules including the non-free ones.
> However the binary packages for those modules are built from
> seperate source packages not this one.

> The only reason for having the webmin.orig.tar.gz as it is was to
> provide something approximating the upstream tarball. It sounds like
> I don't need to bother about that.

Since the source goes into Debian main, keeping the sources
 together means that we are distributing non-free material in Debian
 main, which not only violates the social contract, it may well be
 illegal (or have people who distribute debnian CD's indulge in
 illegal activity), depending on how non free the non free bits are. 

This needs be corrected ASAP, and a bug needs be filed on
 ftp.debian.org to have the old sources, containing the non-fee bits,
 be removed from main.

manoj
-- 
We don't really understand it, so we'll give it to the programmers.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Proposal: make kernel install easier

[Manoj Srivastava]

On 20 Aug 2003 15:39:18 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said: 

> On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote:
> Adam C Powell IV <[EMAIL PROTECTED]> writes:

>> Greetings,
>>
>> Installing a new kernel package can be a bit of a pain, especially
>> for newbies, what with hand-editing lilo.conf or config files for
>> other bootloaders, from grub to yaboot/quik, aboot, palo, you name
>> it.  Yes, the kernel-image postinst runs lilo, but lilo.conf is
>> invariably out of date, so this is relatively useless except for
>> upgrades.
>>
>> So why not (optionally) automate the process a bit?  Use a
>> directory e.g. /usr/lib/bootloaders/ to put scripts for managing
>> the .conf files and running the bootloaders.

> I believe lilo and grub already have that.

>> From /boot/grub/menu.lst

 BEGIN AUTOMAGIC KERNELS LIST
>>> lines between the AUTOMAGIC KERNELS LIST markers will be modified
>>> by the debian update-grub script except for the default optons
>>> below

> There is also a mechanism in dpkg to install hooks now which is
> hopefully already used to run update-grub.

> Cool, did not know.  I guess a "hooks" mechanism would be required
> for unmodified kernel-image packages...

*Sigh*. There already is one implemented.

> My proposed system would add user control of menu entry
> names/labels, and finer-grained control of boot options (without
> editing the .conf files), but these don't seem worth the overhead of
> such a system.

You can do this without needing to modify kernel-package
 itself. 

> Is this documented somewhere, or should I just look at the latest
> lilo and grub packages to see how to adapt this to other
> bootloaders?  It would be nice if this were somewhat uniform (at
> least to the user) across loaders and architectures.

If ti is feasible at all (and I have no idea if it would be),
 the hooks mechanism in kernel-package should enable you to do this as
 a third party package.

manoj

-- 
"To YOU I'm an atheist; to God, I'm the Loyal Opposition." Woody Allen
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: ftp.gnu.org cracked

[Scott James Remnant]

On Wed, 2003-08-20 at 20:16, Peter Karlsson wrote:

> Scott James Remnant:
> 
> > No problem, this is only a quick run -- others may find ways to improve 
> > this script somewhat.
> 
> What did you use to determine which packages to check? I notice that at 
> least my package for GNU jwhois is missing from your list (although I know 
> that the Debian version is correct since I post the versions to Debian and 
> ftp.gnu.org at the same time...).
> 
If you read the script, you'll see it just checks what it can find.  The
only MD5 sums that GNU have provided are for 2.4, 2.4.1 and 2.4.2

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Your message to Consume-thenet awaits moderator approval

[consume-thenet-bounces]

Your mail to 'Consume-thenet' with the subject

Re: Wicked screensaver

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.consume.net/mailman/confirm/consume-thenet/8dfc3e54932d47d26bdc95b2abf36989fd96f339

Re: non-DD contributors and the debian keyring

[Manoj Srivastava]

On Wed, 20 Aug 2003 23:29:52 +0200, Martin Quinson <[EMAIL PROTECTED]> said: 

> But the point is that without the key, anyone can forge mails which
> seem to come from me, and thus abuse the trust my work gained me in
> the mind of some DDs.

So start signing your email. I'll download the key in I need
 to check wo you are -- and if your key has a DD sig on it, it is in
 the web of trust, once removed.

manoj
-- 
Dyslexics of the world, untie!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Your message to Consume-thenet awaits moderator approval

[consume-thenet-bounces]

Your mail to 'Consume-thenet' with the subject

Re: Wicked screensaver

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post by non-member to a members-only list

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.  If you would like to cancel
this posting, please visit the following URL:


http://lists.consume.net/mailman/confirm/consume-thenet/a0ebfaa83c1a24e8eba7a5964deec76ef6882db6

Content violation

[STAL-Gateway]

Content violation found in email message.

From: debian-devel@lists.debian.org
To: [EMAIL PROTECTED]
Subject: Thank you!

Matching Subject: *thank you!*

Re: Bits from the RM

[Colin Watson]

On Wed, Aug 20, 2003 at 11:18:24AM -0600, Bruce Sass wrote:
> On Wed, 20 Aug 2003, cobaco wrote:
> > I'd agree if there had been a rewrite of kdelibs or something, but
> > kde 3.1 -> 3.2 is evolutionary without big changes to what was
> > already there.
> 
> It does not take a big change to break software...
> e.g., openssh changed a message and the sftp kioslave broke
> http://bugs.kde.org/show_bug.cgi?id=51359

Not that I disagree with you, but frankly, the sftp kioslave was already
broken. It should never have been written to depend on 'ssh -v' output.

CHeers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bits from the RM

[Chris Cheney]

On Wed, Aug 20, 2003 at 08:49:44PM +0200, Martin Quinson wrote:
> What recent change in the KDE releasing schema let you think that they will
> manage to get a really stable x.y.0 release [*] when it seems like it took 4
> minor releases in the 3.1 branch ?
> 
> Naturally, no offense intended to the kde guys. Needing only 4 minor releases
> to stabilize such an amount of code is really great.
> 
> 
> Bye, Mt.
> 
> [*] ie, suitable for debian stable release, ie a version with which you
> could live for a year on your desktop, maybe dreaming of new features (we
> always want more), but not pesting against the bugs.
> I speak of course of the ideal debian stable release ;)

KDE usually releases new point releases about every two months until the
next major release happens. Then they only update for security related
bugs. It doesn't magically become stable after 4 releases.

Chris

Packages-arch-specific

[Aurelien Jarno]

Hello,

One of my package (camstream) was removed from Packages-arch-specific more 
than one month ago in the CVS [1]. However, as the corresponding file on 
buildd.debian.org [2] is not updated, my package is still not built on 
architectures other than i386.

Could somebody with a root access on auric do a
cp /org/buildd.debian.org/web/quinn-diff/tmp/Packages-arch-specific 
/org/buildd.debian.org/web/quinn-diff
?

Thanks,
Aurelien

[1] http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak
[2] http://buildd.debian.org/quinn-diff/Packages-arch-specific


pgpcWfzc79PA9.pgp
Description: PGP signature

Re: Bits from the RM

[Branden Robinson]

On Wed, Aug 20, 2003 at 03:13:11AM -0500, Chris Cheney wrote:
> On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote:
> > Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, 
> > gnome versions will be in sarge?
> 
> An educated guess would produce:
[...]
> XFree 4.3.0   (Branden wants this to happen...)

If other people want it to happen as well, I need volunteers for the X
Strike Force.  I'm the only person doing significant commits lately.

Interested parties, please catch up on the last month's worth of traffic
to the debian-x mailing list to get a feel for the environment.

If you're not scared after that, please join the list and talk about
what you'd like to work on.

-- 
G. Branden Robinson|I must despise the world which does
Debian GNU/Linux   |not know that music is a higher
[EMAIL PROTECTED] |revelation than all wisdom and
http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven


pgpOkk6rvAf2U.pgp
Description: PGP signature

Re: Proposal: make kernel install easier

[Jamin W. Collins]

On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
> On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV said: 
> >
> > Greetings, Installing a new kernel package can be a bit of a pain,
> > especially for newbies, what with hand-editing lilo.conf or config
> 
> Why on earth are you hand editing the lilo.conf file for every kernel
> image?

Well, if they move from an installation kernel to a kernel-image
package, they have to add an entry for an initrd file.  After that, if
they upgrade to another kernel-image package and want to be able to use
both the new and the old they need to edit the old entry for an initrd
too.

-- 
Jamin W. Collins

Remember, root always has a loaded gun.  Don't run around with it unless
you absolutely need it. -- Vineet Kumar

Re: non-DD contributors and the debian keyring

[Stephen Frost]

* Goswin von Brederlow ([EMAIL PROTECTED]) wrote:
> Usually the sponsor looks everything over so signing is not realy
> neccessary. Of cause if you have the same sponsor repeatetly he might
> want to just check your signature and sponsor the changes blindly
> knowing you did good work in the past.

This should never, ever, ever happen.  We have the NM process for a
reason and sponsoring things blindly goes completely around it.  If
you're having to alot of sponsoring from someone then I think the
appropriate action would be to drop a mail to the appropriate people
informing them of this.  If you point out the sponsored uploads you've
had to do and the additional work you're having to do which will be
removed once the NM becomes a DD I expect things might move a little
faster towards that.

Stephen


pgpa1esOztUcB.pgp
Description: PGP signature

Re: [RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)

[Joe Wreschnig]

On Wed, 2003-08-20 at 12:53, Fumitoshi UKAI wrote:
> Joe Wreschnig <[EMAIL PROTECTED]>
>  libtest-unit-ruby1.8 (<- libtest-unit-ruby)

Actually, I now only maintain Test::Unit for Ruby 1.6. Since it became
included with 1.8, akira yamada maintains that version, and when 1.8 was
packaged I dropped support for 1.7 from my package.

I'll rename the 1.6 package appropriately, though, but I'll wait until
the Ruby/GTK packages are renamed (unless that's going to take a very
long time?)

> Currently, ruby upstream doesn't support such version independent module 
> path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later 
> to support this?

I think so, but I'm open to suggestions about it. It does IMO make
packaging modules without C code much simpler. The downside is when a
major incompatibility happens (i.e. code that works correctly on more
than one version is impossible), but I believe this is a rare enough
case to ignore (AFAIK it's never happened).
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


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

Re: non-DD contributors and the debian keyring

[Stephen Frost]

* Martin Quinson ([EMAIL PROTECTED]) wrote:
> On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> > keyring.debian.org has only DDs in it.  I think people were suggesting
> > using the public keyservers.  keyring.debian.org isn't a part of the
> > public key servers.
> 
> That's the part of the system I was criticizing :)

Not going to change.

> Nevertheless, should he trust the meaning of my translation blindly? I mean,
> it could contain offending material, and even unlegal material. I guess that
> there will be someone to engage pursuits if dpkg subtly displayed racial
> crime incitation, or so. 

To some extent "that's what unstable is for".  I doubt a poor
translation would make it into a released version.  Certainly not if we
actually start getting a sizable number of people using the translated
versions of things.  Unfortunately there really isn't a whole lot of
choice in the matter either.

> I dunno in the states, but such things can bring you in jail for a bunch of
> few months (if not years) in France. And it should be easy to insert illegal
> material for the US in displayed text, thanks to your wonderfull anti
> terrorist and digital right management acts...

I'm not sure it's as easy as you suggest but that's not really on the
topic anyway.

> Who will get sued in such situation? I guess Debian in first place, but if
> I understand well, the whole identification process of the NM is exactly
> about giving Debian the possibility to report the charges on the guilty
> developper when sued, isn't it?

Ehhh, I'm not sure I'd agree with that specifically, but whatever.

> So, I ask again, shouldn't Debian check the real identity of contributors
> when the maintainer is unable to check the material himself ?

Checking the identity doesn't really help in the situation you've
described.  If someone not in france submitted a translation patch that
had stuff which is illegal in france I doubt they'd be touched, even if
you could identify them.  Debian servers in France would be targeted and
the operators, not even the DDs, would be the ones who could get in 
trouble.

One could have similar concerns about the BTS due to the fact that it
displays emails sent to it.  This isn't really a new thing which makes
me not really worried about it in the end.

> If it's ok so, what is the big deal of asking the DD for having a trusted
> key and signing the packages, anyway ?

Honestly I see there being a very big difference between having rude
things done in a translation and, for example, having packages which
install rootkits.  Sorry, that's just life.

> I know about the public servers, but I was wondering why Debian make things
> harder for the DD while it has the infrastructure to simplify their work.

What is harder for the DD and how could the existing Debian
infrastructure fix that?  Nothing in what you've said would lead me to
believe that there's something we can change which would make things
easier for the DD with regard to 'poor' translations.

Stephen


pgpncY6hChw32.pgp
Description: PGP signature

Your message was rejected because it contained a virus

[web0002 . bjznet . com]

Your message was rejected because it contained the file your_details.zip which 
contains a virus.

For more information on this virus please see 
http://securityresponse.symantec.com

vacation mail

[vikasarora0011]

mail recived

Re: ftp.gnu.org cracked

[Joey Hess]

Scott James Remnant wrote:
> No problem, this is only a quick run -- others may find ways to improve
> this script somewhat.

> !! xaos: xaos_3.0.orig.tar.gz NOT OK (e0e66a873b6d5193a79bc89345992d6b != 
> 5a63c3b696821e5d5d566ad9da308117)

Diff shows the following differences:

[EMAIL PROTECTED]:~/tmp>diff -ur fsf/xaos-3.0 deb/XaoS-3.0
diff -ur fsf/xaos-3.0/src/include/xio.h deb/XaoS-3.0/src/include/xio.h
--- fsf/xaos-3.0/src/include/xio.h  1998-03-15 15:45:48.0 -0500
+++ deb/XaoS-3.0/src/include/xio.h  1998-03-04 16:49:12.0 -0500
@@ -10,8 +10,8 @@
   /*returns xio_file or XIO_FAILED in case it failed*/
 #define xio_ropen(fname) fopen(fname,"r")
 #define xio_wopen(fname) fopen(fname,"w")
-#define xio_rbopen(fname) fopen(fname,"rb")
-#define xio_wbopen(fname) fopen(fname,"wb")
+#define xio_rbopen(fname) fopen(fname,"r")
+#define xio_wbopen(fname) fopen(fname,"w")
   /*returns non zero in case of error*/
 #define xio_close(fname) fclose(fname)
 #define XIO_FAILED NULL

To complicate things, there is a third file, on sourceforge.net. This file,
XaoS-3.0.tar.gz, md5sums to fa26ce9805d4889174c891b334da6d09. Diff shows no
differences between it and the fsf version; inspection shows that they unpack
to different directories. Probably this tarball was repackaged to meet FSF
standards.

The original site I downloaded xaos from in 1998,
http://limax.paru.cas.cz/~hubicka/XaoS/ (and packaged as pristine source), is
no longer around. Probably the addition of the b's to the fopens happened
sometime after that, in a repackaged version of xaos. Since "b" has no effect
in Debian anyway, it's not worth thinking about anymore. :-)

-- 
see shy jo


pgpA1pU6JpwWQ.pgp
Description: PGP signature

Re: Bug#205927: ITP: eggdrop -- Advanced IRC Robot

[Ian Eure]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sunday August 17 2003 09:35 am, Peter Makholm wrote:
> "Guilherme de S. Pastore" <[EMAIL PROTECTED]> writes:
> > * Package name: eggdrop
> >   Version : 1.6.15
> >   Upstream Author : EggHeads <[EMAIL PROTECTED]>
> > * URL :
> > ftp://ftp.eggheads.org/pub/eggdrop/source/1.6/eggdrop1.6.15.tar.gz *
> > License : GPL
> >   Description : Advanced IRC Robot
> >
> >  Eggdrop is an IRC bot written in C. Eggdrop, being a bot, sits on a
> > channel
>
> Seems to be packaged allready.
>
He's taking it over from me.

Guilherme, I believe that all you need to do is upload your package with your 
name in the Maintainer field of debian/control.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/RAiYHJcvLJR6wWoRAk3mAKCOEnerAsFWI2SD065pI1bb7gInwACgoxuP
dPNJhspnj9j05ek0UsRoTYw=
=ICeZ
-END PGP SIGNATURE-

Bug#206477: ITP: libtunepimp -- MusicBrainz tagging library and simple tagger application

[Robert Jordens]

Package: wnpp
Version: unavailable; reported 2003-08-21
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libtunepimp
  Version : 0.2.1
  Upstream Author : Robert Kaye <[EMAIL PROTECTED]>
* URL : ftp://ftp.musicbrainz.org/pub/musicbrainz/
* License : GPL2
  Description : MusicBrainz tagging library and simple tagger application

 Libtunepimp simplifies tagging your audio files with the correct data
 about artist, album and track title using the MusicBrainz infrastrucure.
 It works on top of libmusicbrainz and libraries to read audio in mp3
 files and ogg files.
 Included is tp_tagger, a simple example tagger application.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Q/4ZHSjkv+Av7xERAq+8AJ9OvOJTwNINsfsfUzXxlxZAsBTN3wCfRea1
3ateDFz2qezmXTZZk8BK5S0=
=EONA
-END PGP SIGNATURE-

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 14:46, Manoj Srivastava wrote:
On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said: 

> Greetings, Installing a new kernel package can be a bit of a pain,
> especially for newbies, what with hand-editing lilo.conf or config

Why on earth are you hand editing the lilo.conf file for every
 kernel image? The postinst already manages two symlinks for you that
 can be in the lilo.conf file. 

If you have to hand edit lilo.conf for every kernel image, you
are doing something wrong.

See my reply to Josh Lauricha: kernel-image packages corrupt the
vmlinuz(.old) symlinks when removing a kernel, and switching between
kernels with and without initrd.img is not supported.

For the clever, you can manage any number of symlinks
 automatically for yourselves; the latest kernel-package gives
 an example of creating a set of symlinks for 2.4 kerels, another set
 for 2.5 kernels, and so on.

> files for other bootloaders, from grub

Another bad example. For grub you do not need to muck around
 with symlinks at all, you have update-grub, and again, the
 kernel-package package gives examples on how to use this script.

Then /usr/lib/bootloaders/grub would be very small and easy to write. 
My proposed mechanism would add finer-grained control of boot options
(e.g. "apm=on" for 2.2 kernels but not 2.4) and of menu entry
names/labels, with little additional coding.

> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf
> files and running the bootloaders.

> For example, quik could have debconf questions: "Manage quik.conf
> using debconf?" and "Install new kernels automatically?" and perhaps
> "Global kernel option defaults" (though perhaps this would be better
> outside of each individual bootloader).  Then each kernel package
> would have a low- to med-priority debconf question asking with what
> options to boot the kernel starting from global defaults.  It could
> also ask whether to make this image top priority in the .conf, and
> what name string to use for this image.  Also, quik could Provide
> virtual package bootloader which kernel-image packages could
> Suggest.

Bloat. You have not yet demonstrated a need that can't be met
 with the current infrastructure (your examples are fraught with an
 ignorance of current practice).

Please forgive me, I had not known that a newer version of quik had just
been uploaded which supports such features, and that's what I use to
boot my one fully-unstable machine (i.e. not just a chroot).

> If there's interest (and no show-stoppers anyone can think of), I'll

Well, too late. There are show stoppers galore (lack of need
 for such bloat being just one of them).

> start writing patches to kernel-package, lilo, maybe even quik :-) --
> that is, unless someone else wants to, e.g. their maintainers.

Secondly, most of this creeping featurism does not belong in
 kernel-package proper, but should be off loaded to the hook scripts.

Now that there are hook scripts, this makes some sense.  But if you
think about it for a few seconds, the "bloat" and "creeping featurism"
of the proposed bootloader scripts is no greater than that required for
hook scripts -- in fact, that's what they are (inspired by e.g.
update-cluster).

> [Please CC me in replies as I'm not subscribed.  And apologies if

In the old days, it was considered rude to ask questions on a
 forum when you were not subscribed.

Then I am glad I do not live "in the old days".

> this has been brought up before; searches on lists.debian.org didn't turn 
up
> anything.]

It has not only been brought up, solutions have been found and
 have been implemented.

Again forgive me, I had not known these solutions had been applied to
aboot, quik, palo, etc.

Thank you for the kind and courteous reply,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 15:02, Goswin von Brederlow wrote:
Adam C Powell IV <[EMAIL PROTECTED]> writes:

> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.
> 
> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files
> and running the bootloaders.

I believe lilo and grub already have that.

>From /boot/grub/menu.lst

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default optons below

There is also a mechanism in dpkg to install hooks now which is
hopefully already used to run update-grub.

Cool, did not know.  I guess a "hooks" mechanism would be required for
unmodified kernel-image packages...

My proposed system would add user control of menu entry names/labels,
and finer-grained control of boot options (without editing the .conf
files), but these don't seem worth the overhead of such a system.

Is this documented somewhere, or should I just look at the latest lilo
and grub packages to see how to adapt this to other bootloaders?  It
would be nice if this were somewhat uniform (at least to the user)
across loaders and architectures.

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Locales in display managers (Was: Re: Locales in init scripts (about gdm bug #147091))

[Daniel Ruoso]

Ok, but /etc/default/language is not created by the locales package
which does currently asks the system's default language, but saves it in
/etc/environment instead.

The question is:
Is it ok to a display manager source /etc/environment (at least until
another definition is made) into the init script?

Because that's the only way (except if init itself set the LANG
variable, or the locales package generate /etc/default/language) to get
the x login prompt using the system's default locale?

P.S.: This is an annoying bug that can be closed with a 1-line patch,
but it isn't because of this indefinition (See maintainer comments into
the bug history).

--daniel

Em Qua, 2003-08-20 às 07:53, Javier Fernández-Sanguino Peña escreveu:
> On Mon, Aug 18, 2003 at 12:19:03PM -0300, Daniel Ruoso wrote:
> > Hi.
> (...)
> > 
> > So, how to make the init scripts localized?
> > 
> > What do you think?
> > 
> 
> /etc/default/language? I believe this has been discussed previously, see 
> for example [1] and debian-boot [2]. 
> 
> From briefly looking at redhat's redhat-config-language program (a GUI to
> setup precisely this) it seem they use /etc/sysconfig/i18n for this (is
> there also an /etc/sysconfig/language?) which gets sourced from scripts
> (lang.sh, lang.csh) in /etc/profile.d to setup the user's environment and
> by /etc/rc.d/init.d/functions which is incorporated by init.d programs.
> 
> IMHO to get init scripts localized a similar (and policy mandated) set 
> of functions (including i18n/l10n) should be implemented. Locale 
> configuration (or boot-floopies/d-i for that matter) should then modify 
> those on admin's request.
> 
> Regards
> 
> Javi
> 
> [1] www.debian.org/News/weekly/1999/27/mail
> [2] lists.debian.org/debian-boot/2001/debian-boot-200105/msg00667.html 
> -

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Jaldhar H. Vyas]

On Wed, 20 Aug 2003, Goswin von Brederlow wrote:

> "Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:
>
> > On Wed, 20 Aug 2003, Goswin von Brederlow wrote:
> >
> > > The only problem with that is the current failure to comply to policy,
> > > i.e. build from source as they should.
> > >
> >
> > The question remains is simply removing all the extra source from
> > webmin-n.orig.tar.gz except that which is necessary to build the webmin
> > binary package (i.e not any of the modules which will have their own
> > source and binary packages) an aceptable solution to the problem or not?
>
> >From what I read in this thread webmin-n.orig.tar.gz also contains
> some non-free sources, right?
>

It has source for all the modules including the non-free ones.  However
the binary packages for those modules are built from seperate source
packages not this one.

> Then you have no choice but split it up to get the rest into main. And
> when you don't have a pristine upstream orig.tar.gz you can split it
> up as far as you like or need to.
>

The only reason for having the webmin.orig.tar.gz as it is was to provide
something approximating the upstream tarball. It sounds like I don't need
to bother about that.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: Bits from the RM

[Chris Cheney]

On Wed, Aug 20, 2003 at 04:34:18PM +0200, cobaco wrote:
> > KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by
> > almost two months:
> >
> > * October 15th
> >Final, last-minute, low-risk bug fixes only
> 
> Monday September 29th, 2003: Preparing Beta1
>   The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1]
> 
> is there any reason why stabilization of kde and stabilization of 
> kde-packaging can't be done in parallel?

Er you want the final version of KDE in stable to be a KDE 3.2 Beta 1
release? ;) It takes well more than 10 days on average for KDE to be
ready to migrate to sarge, esp with slow buildds such as m68k and mips.
And with KDE 3.2 Beta 1 releasing to packagers on Sept 29 it won't have
even finished building on the buildds much less waited the required 10
days by Oct 1.


Debian 3.1 Dates

Sept 1  Toolchain freeze.
Sept 15 Major package freeze.
Oct 1   Everything freezes(?)

Chris

Re: Proposal: make kernel install easier

[Adam C Powell IV]

On Wed, 2003-08-20 at 14:25, Josh Lauricha wrote:
On Wed  10:51, Adam C Powell IV wrote:
> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.

Don't know about your system, but /vmlinuz and /vmlinuz.old always point
to the correct images and lilo.conf is set to use those by default. So,
whenever I upgrade the kernel this is all taken care of.

Not necessarily.  Ever removed a kernel?  Or tried to switch between
kernels with and without initrd.imgs?  (Or perhaps you don't use the
stock Debian 2.4 kernels...)

Zeen,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

ALERT: You may have sent a Virus

[JARING E-Mail Virus Scanner]

Dear ,

JARING E-Mail Virus Scanner has detected virus(es) in your e-mail attachment(s)

Original Date: Aug 21 02:56:50
Original Sender: 
Original To: <[EMAIL PROTECTED]>
Original Subject: Re: Your application 


Virus info:-

Attachname: h7KIumso01649 was infected with [EMAIL PROTECTED], 
and deleted


Thank you,

JARING E-Mail Virus Scanner ( http://www.jaring.my )

Re: Proposal: make kernel install easier

[Manoj Srivastava]

On 20 Aug 2003 10:51:54 -0400, Adam C Powell IV <[EMAIL PROTECTED]> said: 

> Greetings, Installing a new kernel package can be a bit of a pain,
> especially for newbies, what with hand-editing lilo.conf or config

Why on earth are you hand editing the lilo.conf file for every
 kernel image? The postinst already manages two symlinks for you that
 can be in the lilo.conf file. 

If you have to hand edit lilo.conf for every kernel image, you
are doing something wrong.


For the clever, you can manage any number of symlinks
 automatically for yourselves; the latest kernel-package gives
 an example of creating a set of symlinks for 2.4 kerels, another set
 for 2.5 kernels, and so on.

> files for other bootloaders, from grub

Another bad example. For grub you do not need to muck around
 with symlinks at all, you have update-grub, and again, the
 kernel-package package gives examples on how to use this script.

> to yaboot/quik, aboot, palo,
> you name it.  Yes, the kernel-image postinst runs lilo, but
> lilo.conf is invariably out of date, so this is relatively useless
> except for upgrades.

Rubbish. It is not our of date at all, as long as you have
 written it corectly, and to be compatible with the image postinst.

> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf
> files and running the bootloaders.

> For example, quik could have debconf questions: "Manage quik.conf
> using debconf?" and "Install new kernels automatically?" and perhaps
> "Global kernel option defaults" (though perhaps this would be better
> outside of each individual bootloader).  Then each kernel package
> would have a low- to med-priority debconf question asking with what
> options to boot the kernel starting from global defaults.  It could
> also ask whether to make this image top priority in the .conf, and
> what name string to use for this image.  Also, quik could Provide
> virtual package bootloader which kernel-image packages could
> Suggest.

Bloat. You have not yet demonstrated a need that can't be met
 with the current infrastructure (your examples are fraught with an
 ignorance of current practice).

> If there's interest (and no show-stoppers anyone can think of), I'll

Well, too late. There are show stoppers galore (lack of need
 for such bloat being just one of them).

> start writing patches to kernel-package, lilo, maybe even quik :-) --
> that is, unless someone else wants to, e.g. their maintainers.

Secondly, most of this creeping featurism does not belong in
 kernel-package proper, but should be off loaded to the hook scripts.

> [Please CC me in replies as I'm not subscribed.  And apologies if

In the old days, it was considered rude to ask questions on a
 forum when you were not subscribed.

> this has been brought up before; searches on lists.debian.org didn't turn up
> anything.]

It has not only been brought up, solutions have been found and
 have been implemented.


manoj
-- 
We were so poor we couldn't afford a watchdog.  If we heard a noise at
night, we'd bark ourselves. Crazy Jimmy
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 05:03:17PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> > > keyring.debian.org has only DDs in it.  I think people were suggesting
> > > using the public keyservers.  keyring.debian.org isn't a part of the
> > > public key servers.
> > 
> > That's the part of the system I was criticizing :)
> 
> Not going to change.

Quite definitive answer.. Ok, I guess I got my answer and go back to work ;)
 
> > Nevertheless, should he trust the meaning of my translation blindly? I mean,
> > it could contain offending material, and even unlegal material. I guess that
> > there will be someone to engage pursuits if dpkg subtly displayed racial
> > crime incitation, or so. 
> 
> To some extent "that's what unstable is for".
Right

> I doubt a poor translation would make it into a released version.
A lot of poor translation get into stable, mainly by lack of manwork, but
you are right no offending translation gets into testing. At least in french.

> > Who will get sued in such situation? I guess Debian in first place, but if
> > I understand well, the whole identification process of the NM is exactly
> > about giving Debian the possibility to report the charges on the guilty
> > developper when sued, isn't it?
> 
> Ehhh, I'm not sure I'd agree with that specifically, but whatever.

Mmm. If so, I really cannot understand the big deal with IDs when signing
the key. Knowing my ID is not enough to prove that I won't upload a rootkit,
and it is not even needed... I must be perticulary dumb.

> Honestly I see there being a very big difference between having rude
> things done in a translation and, for example, having packages which
> install rootkits.  Sorry, that's just life.

Sure. Who said the contrary ? I said that really broken translation can lead
to issues, too ("type 'Y' to erase/list the content of your home dir" ;).  
I never said that it was the most important point in Debian. I'm not *that*
dumb ;)

> > I know about the public servers, but I was wondering why Debian make things
> > harder for the DD while it has the infrastructure to simplify their work.
> 
> What is harder for the DD and how could the existing Debian
> infrastructure fix that?  Nothing in what you've said would lead me to
> believe that there's something we can change which would make things
> easier for the DD with regard to 'poor' translations.

The whole story is about easing the technical issue in a trust relationship.

Of course, I could (and have) uploaded my key on public servers, meaning
that other Debian member could check than a given mail with my address
desserve the trust they habitually give me. But those guys would have to 
configure their email specifically on people like me[*]. I was wondering if
could be avoided, that's all.

A really great improvement of this situation would be to make easily
available the keys of people in the NM queue, since translators are supposed
to become debian "developer", too.


But, ok, if the majority here says that there would not be sufficient
benefit wrt the effort, I guess I'll have to deal with it. Easy :)


Thanks for your time, and sorry for preventing you fixing bugs.
Mt.

[*] Yeah, I use my personal example because of my borken non-native english,
to ease my sentences and have a little chance to get them right, But in
fact, we are a whole bunch in my situation.

-- 
Und auch jetzt ist ein Mensch mehr Affe als irgend ein Affe.
  --- F. Nietzsche

Re: FTBFS: architecture all packages

[Adam Heath]

On Wed, 20 Aug 2003, Matthias Urlichs wrote:

> Why not? Just block binary uploads completely, and let everything get
> built by the buildds. I certainly plan to do that with my own uploads.
> (I've already set up my own buildds).
>
> I'd go one step farther and schedule a low-priority rebuild of everything
> that build-depends on a package which gets updated.

How about this:

* Maintainer does normal build, doing -all and -arch debs.  Maintainer
  uploads.
* dak verifies upload as normal.
* dak adds new source to unstable, but not the debs.
* buildds then proceed to build new source.  one buildd is choosen to build
  the -all debs.

Re: Bits from the RM

[Teófilo Ruiz Suárez]

El 20-ago-2003 a las 09:49:03, Adrian von Bidder escribió:
Content-Description: signed data
> On Tuesday 19 August 2003 08:49, Anthony Towns wrote:
> 
> > I'm all for aggressive goals, let's aim for sometime in December -- how
> > about 2003-12-01 00:00:00 UTC?
> 
> Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, 
> gnome versions will be in sarge?

What about Apache? Should we change the apache2 package to apache?

This release will be a funny challenge, so, let's have fun :)

Regards,
-- 
Teófilo Ruiz Suárez  ||(teo)||  Sevilla, España 

  [EMAIL PROTECTED]   

GnuPG Key ID: 420718E6
FPR: 0280 862C 064B FA76 9A1C  EB64 5755 A66C 4207 18E6



pgpvE8A9WaZQn.pgp
Description: PGP signature

Re: non-DD contributors and the debian keyring

[Martin Quinson]

[answer to a private mail on the list with the permission of Christian]

On Wed, Aug 20, 2003 at 02:53:49PM +0200, Christian Kurz wrote:
> On [19/08/03 18:05], Martin Quinson wrote:
> > point is that currently, DD is very very strict about who can upload to the
> > source and the packages, but when I submit a translation to someone who do
> > not speak french, he have to trust me.
> 
> Well, but even if you are a DD, I would have to trust you and the
> translation that you provided. And for me that trust doesn't depend on
> the signature of the e-Mail that contained the translation. For me it
> doesn't matter if you send me a translation know, with your key signed
> or with your key in the debian-keyring. I will in both cases apply the
> same procedure before including the translation. 

Of course, the signature is not sufficient to get the needed trust. But I'm
coordinator of the french translation team since a few years, so my skills
should be trustable, I guess.

But the point is that without the key, anyone can forge mails which seem to
come from me, and thus abuse the trust my work gained me in the mind of some
DDs.

I see this point as necessary even if not sufficient.


That is to say that if I were DD, I would never trust any contribution I
cannot check myself and comming from someone I'm not confident in 1) the
identity 2) the skills. 

Judging from the amount of translation rotting in the BTS, I guess some of
you guys react the same way, and I want to change this by easing this trust
relationship, if possible.


Thanks for your time, Mt.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!

Re: #206298 spip: prerm script blindly removes directories

[Jamin W. Collins]

On Wed, Aug 20, 2003 at 07:53:41PM +0200, Gaetan Ryckeboer wrote:
>
> Not necessary. Web administrators may upload files via FTP, andspip
> users  never use them onto spip ? If so, the files will stay in place
> in upload, instead of beeing integrated onto the spip tree at the
> right place, and being logged in the sql database.

In which case should you be deleting them?  I would say no.  While they
are in that directory, they are not used by spip and thus not really a
part of spip.  The user(s) put them there, when in doubt, leave them
there.
 
> Yes it needs. I've still moves documentation to usr/share/doc, instead
> of spip/ecrire/doc, but it is rather different with the cache and
> other application managed files.
> 
> You may access the php files via apache, but php files may access to
> other php file, or static file. For instance, to modify the
> configuration, or read the cache.

Yes, symlinks are needed for direct file access (unless you patch the
source).  Sorry, when I stated symlinks weren't needed I meant on the
Apache side.  I've dealt with this exact problem in my packaging of
Media Mate (new name for Movie Mate).  I'm currently using symlinks to
allow the php script to access files by the paths they expect and Apache
Alias directives to allow http requests to get the files without
enabling symlink following.

> I accept. Please send me examples in private, if you found a way to
> move php files accessing each other (via "include") in another
> directory, without patching the application.

I'll forward Media Mate's packaging over to you.

-- 
Jamin W. Collins

Remember, root always has a loaded gun.  Don't run around with it unless
you absolutely need it. -- Vineet Kumar

Re: Non-free software on linex [was Re: Debian Weekly News - August 19th, 2003]

[Mike Hommey]

On Wednesday 20 August 2003 20:13, Hans Ekbrand wrote:
> There's more of it: http://www.linex.org/sources/linex/debian/linex/
> lists acroread_4.05-3, mplayer_0.90pre5-3
> flashplugin-nonfree_6.0.79-1, hsflinmodem-linex_0.5.2-1

... and j2re, yes, I saw that afterwards...
Some are quite badly packaged, by the way...

Mike

Re: what about ip's

[Alan Shutko]

"David Smith" <[EMAIL PROTECTED]> writes:

> my first assumption is that charter sells their users email addresses. does
> anyone on this list know how an unused email address that has never been
> used can have spam without the ip giving the address out?

Is it a fairly simple username, like dsmith?  Those can get caught by
spammers blindly sending to common usernames.

Now, if the username were something like hkja89ZJNhks8S12 and got
spammed, someone in the organization is probably selling usernames,
but it could just be a rogue employee.

-- 
Alan Shutko <[EMAIL PROTECTED]> - I am the rocks.
Women were made to be loved, not to be understood.

Re: Bits from the RM

[Gunnar Wolf]

cobaco dijo [Wed, Aug 20, 2003 at 11:08:28AM +0200]:
> > KDE 3.1.4   (KDE 2.2 _will not_ stay in sarge!)
> 
> kde 3.2  release is slated for 8th december[1], is there any chance we'll 
> wait 
> for it, just so the outdated kde label doesn't apply again immediately after 
> release?

...And then wait for some 4 months in order for KDE 3.2 not to have all
the bugs introduced by a freshly sent major version? And then, we would
not have an excuse for not including Gnome 2.4... But by the time we got
Gnome 2.4 in, we would have to include XFree 4.4 as well, and not
shipping with kernel 2.6 by default would seem odd. But by then, KDE 3.3
would be knocking the door...

Please, this is Debian. We do not need no shiny new versions of neither
${package} nor ${subsystem}.

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Debian Weekly News - August 19th, 2003

[Peter S Galbraith]

Jérôme Marant <[EMAIL PROTECTED]> wrote:

> Quoting Scott James Remnant <[EMAIL PROTECTED]>:
> 
> > > No he wouldn't. FDL is about free documentation. :-)
> > > 
> > Except it isn't :-)
> 
> According to you :-)

According to debian-legal consensus.

Re: Bits from the RM

[Jaldhar H. Vyas]

On Wed, 20 Aug 2003, Russell Coker wrote:

> Are there any big features you expect from KDE 3.2?
>

Well it will be built with Qt 3.2 which has proper support of Indian
languages.

But if a KDE 3.2 beta or 3.1 built against Qt 3.2 goes in, that is good
enough for me.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: Bits from the RM

[Steve Langasek]

On Wed, Aug 20, 2003 at 07:13:38PM +0200, Santiago Vila wrote:
> On Wed, 20 Aug 2003, Steve Langasek wrote:

> > On Wed, Aug 20, 2003 at 03:52:42PM +0200, Santiago Vila wrote:
> > > Will we some day consider seriously the idea of autobuilders compiling
> > > against testing those packages which do not need libraries from
> > > unstable to be built?

> > Do you foresee any reasons why using experimental for new library
> > uploads wouldn't serve the same purpose?

> Yes, autobuilders do not build stuff from experimental, so it will
> hardly serve the same purpose as the current unstable, even if you
> convince a lot of users so that experimental is tested as much as
> unstable.

There was, however, talk of providing an easy interface to allow
requests for building.

I think this is a design that could be made to work.

-- 
Steve Langasek
postmodern programmer


pgp1rKf75MNOB.pgp
Description: PGP signature

Re: ftp.gnu.org cracked

[Peter Karlsson]

Scott James Remnant:
No problem, this is only a quick run -- others may find ways to improve 
this script somewhat.
What did you use to determine which packages to check? I notice that at 
least my package for GNU jwhois is missing from your list (although I know 
that the Debian version is correct since I post the versions to Debian and 
ftp.gnu.org at the same time...).

--
\\//
Peter - http://www.softwolves.pp.se/
 I do not read or respond to mail with HTML attachments.

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Jaldhar H. Vyas]

On Wed, 20 Aug 2003, Goswin von Brederlow wrote:

> The only problem with that is the current failure to comply to policy,
> i.e. build from source as they should.
>

The question remains is simply removing all the extra source from
webmin-n.orig.tar.gz except that which is necessary to build the webmin
binary package (i.e not any of the modules which will have their own
source and binary packages) an aceptable solution to the problem or not?


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: Debian Weekly News - August 19th, 2003

[Jamin W. Collins]

On Wed, Aug 20, 2003 at 05:30:39PM +0200, J?r?me Marant wrote:
> Quoting Scott James Remnant <[EMAIL PROTECTED]>:
> 
> > > No he wouldn't. FDL is about free documentation. :-)
> > > 
> > Except it isn't :-)
> 
> According to you :-)

This has been covered to death already.  There are a sufficient number
of respondents that see it as non-free.  The RM's recent post indicates
that possibly the FSF has even come around to the idea that their
license is less than Free.  Can we please move along now?

-- 
Jamin W. Collins

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

Re: ftp.gnu.org cracked

[Matt Zimmerman]

On Wed, Aug 20, 2003 at 04:25:31PM +0100, Scott James Remnant wrote:

> [ Moved to debian-devel, I don't think this is relevant to private as
>   the GNU crack is well publicised ]

It is, in general, very poor taste to make this choice for others by
reposting their content from a private forum to a public forum.  While I
agree that this should have begun on -devel in the first place, it didn't,
and I respected the privacy of those I quoted by following up to -private.

-- 
 - mdz

Re: Proposal: make kernel install easier

[Goswin von Brederlow]

Adam C Powell IV <[EMAIL PROTECTED]> writes:

> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.
> 
> So why not (optionally) automate the process a bit?  Use a directory
> e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files
> and running the bootloaders.

I believe lilo and grub already have that.

>From /boot/grub/menu.lst

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default optons below

There is also a mechanism in dpkg to install hooks now which is
hopefully already used to run update-grub.

MfG
Goswin

Network Associates Webshield - e-mail Content Alert

[viruscheck]

Network Associates WebShield SMTP V4.5 MR1a on mailvwy01 intercepted a mail from
 which caused the Content Filter Block PIF 
Attachments to
be triggered.

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Goswin von Brederlow]

"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:

> On Wed, 20 Aug 2003, Goswin von Brederlow wrote:
> 
> > The only problem with that is the current failure to comply to policy,
> > i.e. build from source as they should.
> >
> 
> The question remains is simply removing all the extra source from
> webmin-n.orig.tar.gz except that which is necessary to build the webmin
> binary package (i.e not any of the modules which will have their own
> source and binary packages) an aceptable solution to the problem or not?

>From what I read in this thread webmin-n.orig.tar.gz also contains
some non-free sources, right?

Then you have no choice but split it up to get the rest into main. And
when you don't have a pristine upstream orig.tar.gz you can split it
up as far as you like or need to.

MfG
Goswin

Re: Bits from the RM

[Martin Quinson]

On Wed, Aug 20, 2003 at 11:08:28AM +0200, cobaco wrote:
> On 2003-08-20 10:13, Chris Cheney wrote:
> > On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote:
> 
> > > On Tuesday 19 August 2003 08:49, Anthony Towns wrote:
> > > > I'm all for aggressive goals, let's aim for sometime in December -- how
> > > > about 2003-12-01 00:00:00 UTC?
> 
> > > Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc,
> > > X, gnome versions will be in sarge?
> 
> > KDE 3.1.4   (KDE 2.2 _will not_ stay in sarge!)
> 
> kde 3.2  release is slated for 8th december[1], is there any chance we'll 
> wait 
> for it, just so the outdated kde label doesn't apply again immediately after 
> release?

What recent change in the KDE releasing schema let you think that they will
manage to get a really stable x.y.0 release [*] when it seems like it took 4
minor releases in the 3.1 branch ?

Naturally, no offense intended to the kde guys. Needing only 4 minor releases
to stabilize such an amount of code is really great.


Bye, Mt.

[*] ie, suitable for debian stable release, ie a version with which you
could live for a year on your desktop, maybe dreaming of new features (we
always want more), but not pesting against the bugs.
I speak of course of the ideal debian stable release ;)

-- 
Testing can only prove the presence of bugs. 
--- Dijkstra

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 11:03:32AM -0500, Steve Langasek wrote:
> On Wed, Aug 20, 2003 at 11:23:47AM +0200, Martin Quinson wrote:
> > On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
> > > * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-20 10:31]:
> > > > > Martin Quinson <[EMAIL PROTECTED]> wrote:
> > > > > > I just wondered if it would be possible for non-developper
> > > > > > contributors to Debian to get their GPG key in the Debian 
> > > > > > keyserver. 
> > > > 
> > > > You can also apply as a NM for translation work. You don't need to
> > > > maintaine a package or know much about the packaging system for
> > > > that. You get different task&skill tests.
> > > 
> > >V I P   Martin Quinson <[EMAIL PROTECTED]>
> 
> > Exact. I *did* apply. I'm even pretty well advanced in the process.
> 
> > $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> > gpg: no valid OpenPGP data found.
> > gpg: Total number processed: 0
> 
> > This is the ID of my key, available from www.keyserver.net and signed by 2
> > DD. Did I mess something up ?
> 
> > Shouldn't Debian make sure that work submition from non-DD contributor are
> > signed, just like it does for the work submition from DD ?
> 
> The keyring on keyring.debian.org is used directly as a means of
> authorizing people to a number of Debian resources, including the
> package upload queue and d-d-a.  Whether you agree with this design or
> not, it means that the Debian keyserver is not suitable for use as a
> general-purpose means of *authenticating* people.  For authenticating
> PGP users to one another, you should use the usual Web of Trust to
> achieve this.

I have to confess my ignorance here. Since it seems to be 4 keyrings on that
server (according to /usr/share/doc/debian-keyring/README.gz at least), I
was wondering if it would be possible to add a 5th for the trusted
contributors not being DD.

I can well imagine that the debian-keyring.{gpg,pgp} is used to allow people
to upload packages and such and want certainly not to get into that ring
(yet -- I'm in the NM process). But I was dreaming of such trust facility
for non DD contributors.


Another point is that it would constitute a strong signal to non DD
contributors: They would be trusted by Debian. According to the cathedral
and the bazzar, that's the way it should be if not too technically
difficult...


Thanks, Mt.

-- 
The unavoidable price of reliability is simplicity.
--Hoare

Re: Bits from the RM

[Steve Langasek]

On Wed, Aug 20, 2003 at 04:34:18PM +0200, cobaco wrote:
> > KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by
> > almost two months:

> > * October 15th
> >Final, last-minute, low-risk bug fixes only

> Monday September 29th, 2003: Preparing Beta1
>   The HEAD branch is tagged as Beta 1 and is frozen for nonurgent commits[1]

> is there any reason why stabilization of kde and stabilization of 
> kde-packaging can't be done in parallel?

Of course not; but you've missed the crucial difference between
stabilization of kde *packaging*, and stabilization of kde *packages*.
There is a great deal of testing that must be done with the packages /in
situ/ once they've been built, to ensure that they work well amid the
other software in Debian.  Moreover, Debian users exercise KDE packages
on a much wider range of hardware than KDE developers typically do
before release; there is simply some testing we can't do before packages
have been allowed to hit the archive, and the window between getting the
current KDE packages into testing (just in case), and getting KDE 3.2
pre packages into experimental/unstable, doesn't leave any margin for
error before the release.

-- 
Steve Langasek
postmodern programmer


pgpXIAMdhPg1V.pgp
Description: PGP signature

Re: Debian 10th birthday gear

[Manoj Srivastava]

Hi,

I would be interested in two of the steins, if I can make
 payment without jumping through too many hoops. What are my options?

manoj
-- 
A year spent in artificial intelligence is enough to make one believe
in God.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Proposal: make kernel install easier

[Josh Lauricha]

On Wed  10:51, Adam C Powell IV wrote:
> Greetings,
> 
> Installing a new kernel package can be a bit of a pain, especially for
> newbies, what with hand-editing lilo.conf or config files for other
> bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
> the kernel-image postinst runs lilo, but lilo.conf is invariably out of
> date, so this is relatively useless except for upgrades.

Don't know about your system, but /vmlinuz and /vmlinuz.old always point
to the correct images and lilo.conf is set to use those by default. So,
whenever I upgrade the kernel this is all taken care of.

-- 


| Josh Lauricha|
| [EMAIL PROTECTED] |
| Bioinformatics, UCR  |
|--|


pgp4eCwekoLsj.pgp
Description: PGP signature

Re: Binaryless uploads

[Manoj Srivastava]

On Wed, 20 Aug 2003 10:04:40 -0400 (EDT), Jaldhar H Vyas
<[EMAIL PROTECTED]> said:  

> Ok.  Lets leave aside for a moment the .debs which would go into
> contrib or non-free so would have to be built seperately.  What

Whoa there. Are you telling me that webmin's orig.tar.gz that
 is in main contains non free material?

manoj
-- 
"Football combines the worst elements of America: Mass violence
punctuated by committee meetings." Author Unknown
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian Installation Goals (was: Happy Birthday)

[Goswin von Brederlow]

cobaco <[EMAIL PROTECTED]> writes:

> On 2003-08-19 21:14, Goswin von Brederlow wrote:
> > cobaco <[EMAIL PROTECTED]> writes:
> > > On 2003-08-17 09:02, Goswin von Brederlow wrote:
> > > > As bad as it might be I would like to have a menu tree containing all
> > > > packages that can be configured and when you select one item a menu
> > > > would pop up with its configuration options.
> 
> > > Package: configure-debian
> 
> > When is that used? At what stage?
> post-installation
> 
> > I'm talking about the selection of udebs and I certainly had no
> > submenus with any images I managed to build.
> err, we were talking about package configuration, not package selection right?

Sort of both.

You select udebs for download, which should use tree menus and not a
flat list.

Then they add menu items to the main menu, which should be a tree too.

And thirdly after/during installing base you have the configure
options of the debs via debconf. A menu to change some values would be
nice there too. So you can answere only neccessary questions while
unpacking and then go and pocke some packages for more detailed
options.

> > Let me guess. You first have to install the configure-debian.udeb?
> > .oO( Which no newbie would ever find )
> true, you do need to install the package to use it, and yes the existence op 
> this package could(should?) be made clearer

Until your mail I had never heard of it. Gotta try it out.

MfG
Goswin

Re: non-DD contributors and the debian keyring

[Martin Quinson]

On Wed, Aug 20, 2003 at 09:40:02AM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> > gpg: no valid OpenPGP data found.
> > gpg: Total number processed: 0
> > 
> > This is the ID of my key, available from www.keyserver.net and signed by 2
> > DD. Did I mess something up ?
> 
> keyring.debian.org has only DDs in it.  I think people were suggesting
> using the public keyservers.  keyring.debian.org isn't a part of the
> public key servers.

That's the part of the system I was criticizing :)

> > Shouldn't Debian make sure that work submition from non-DD contributor are
> > signed, just like it does for the work submition from DD ?
> 
> Interesting question.  While it's not a bad idea I don't see it as
> entirely necessary either.  At least when sponsoring a package the DD
> performing the sponsor must check everything regardless of if it was
> sent to them signed or not. 
[...]

Hey, guys, I begun the thread stating that I was mainly a translator and not
a packager.


Let's say that the test case here is that I send a translation patch to
Wichert about dpkg, as I already did. I think that Wichert has no idea about
french, so he cannot review the meaning of my work. If he actually
understand some french, let's imagine I'm japaneese or whatever.


Of course, he can (and should) review the syntax of my po file (a badly
formated po file can easily let the application segfault by replacing %d by
%s in a printf format). msgfmt will warn him if I made such error.

Nevertheless, should he trust the meaning of my translation blindly? I mean,
it could contain offending material, and even unlegal material. I guess that
there will be someone to engage pursuits if dpkg subtly displayed racial
crime incitation, or so. 

I dunno in the states, but such things can bring you in jail for a bunch of
few months (if not years) in France. And it should be easy to insert illegal
material for the US in displayed text, thanks to your wonderfull anti
terrorist and digital right management acts...

Who will get sued in such situation? I guess Debian in first place, but if
I understand well, the whole identification process of the NM is exactly
about giving Debian the possibility to report the charges on the guilty
developper when sued, isn't it?


So, I ask again, shouldn't Debian check the real identity of contributors
when the maintainer is unable to check the material himself ?
If it's ok so, what is the big deal of asking the DD for having a trusted
key and signing the packages, anyway ?

I know about the public servers, but I was wondering why Debian make things
harder for the DD while it has the infrastructure to simplify their work.


Thanks for your time, Mt.

-- 
Failure is not an option.
It comes bundled with software.

Non-free software on linex [was Re: Debian Weekly News - August 19th, 2003]

[Hans Ekbrand]

On Tue, Aug 19, 2003 at 11:33:12PM +0200, Mike Hommey wrote:
> On Tuesday 19 August 2003 22:12, Martin Schulze wrote:

[...]

> > [2]Libranet 2.8, which is based on Debian. Richard Stallman [3]said
> > he now prefers the [4]GNU/LinEx distribution over Debian because of
> > non-free software on our FTP servers. 

[...]

> Let me see...
> I go to the linex home page. What do i see ?
> "GNU/LinEx y tarjetas NVIDIA".
> Oh well, seems interesting, so I go in the page and see that they seem to 
> provide some package for nvidia drivers. Maybe newer drivers (their distro is 
> based on woody, so...)
> Ok, let's google a bit, and shazaam !
> http://www.linex.org/sources/linex/debian/linex/nvidia-glx_1.0.4349-1_i386.deb
> Oh ! non-free software !
> 
> Thanks Richard for keeping me laughing.

There's more of it: http://www.linex.org/sources/linex/debian/linex/
lists acroread_4.05-3, mplayer_0.90pre5-3
flashplugin-nonfree_6.0.79-1, hsflinmodem-linex_0.5.2-1

-- 

Hans Ekbrand

pgp03pbgkbR6p.pgp
Description: PGP signature

Bug#206429: ITP: ruby-defaults: Debian default version of ruby, libruby

[Fumitoshi UKAI]

Package: wnpp
Version: unavailable; reported 2003-08-21
Severity: wishlist

* Package name: ruby-defaults
  Version : 1.6.8
  Upstream Author : Fumitoshi UKAI <[EMAIL PROTECTED]>, 
Akira Yamada <[EMAIL PROTECTED]>,
Akira Tagoh <[EMAIL PROTECTED]>
* URL : http://pkg-ruby.alioth.debian.org/
* License : GPL or Ruby's
  Description : Debian default version of ruby, libruby

 ruby-defaults provides ruby and libruby that depends on 
debian default version of rubyX.Y and librubyX.Y.
It also contains Debian ruby policy documents.

For now, we already have ruby package in debian archive that is 
packaged from ruby 1.6.8.  I also plan to rename these packages to 
ruby1.6, libruby1.6 and so on, with this ITP.

Regards,
Fumitoshi UKAI

Re: #206298 spip: prerm script blindly removes directories

[Gaetan Ryckeboer]

Le Wed, Aug 20, 2003 at 11:34:40AM -0600, Jamin W. Collins a écrit :
> > Mmm... yes and no. Some of them could be. But a user may upload files
> > without using them in the application.  So, the files are available,
> > but unused, and unreferenced.
> 
> That would appear to be a deficiency of the spip app and one that should
> probably be brought to the upstream developers attention.  The
> application should probably log all uploads.
Not necessary. Web administrators may upload files via FTP, andspip
users  never use them onto spip ? If so, the files will stay in place in
upload, instead of beeing integrated onto the spip tree at the right
place, and being logged in the sql database.

> > Of course, I understand. But I wonder they won't upload personal files
> > for another use than spip here...
> This falls into something of a grey area.  Can the data concievably be
> of value ot the user without spip?  If so, then it is probably user data
> and should not be removed without confirmation from the user (debconf
> prompt that defaults to no?)
You're right. I'll do such a dialog.

> > True. But due to the implemntation of the application, which is
> > written in php, datas are stored on the program dir. There is no real
> > separation between datas and functions.
> > 
> > And if i symlink some datas (for apache access AND direct file handler
> > access), i'll will setup another alarm... and it won't be accepted.
> 
> So, use Alias directives to relocate the directories that need changing
> data to /var/lib.  There is no need to use symlinks to accomplish this.
Yes it needs. I've still moves documentation to usr/share/doc, instead
of spip/ecrire/doc, but it is rather different with the cache and other
application managed files.

You may access the php files via apache, but php files may access to
other php file, or static file. For instance, to modify the
configuration, or read the cache.

The cache management will be patched to go to /var/cache, but I cannot
do more without symlinks... The application won't be changed to handle
FHS correctly without complete rewriting.

Just imagine that spip is a set of application datas for apache/php,
but is an complete application, with datas, procedures, and cache -- the
reason of the packaging.

> As a matter of fact, your current apache include enables the following
> of symlinks, which it doesn't need and probably shouldn't. I can provide
> examples of this if you need.
I accept. Please send me examples in private, if you found a way to
move php files accessing each other (via "include") in another directory, 
without patching the application.
 
-- 
Monsieur à qui on ne la fait pas cherche Dame à qui on ne l'a pas fait.

Gaétan RYCKEBOER  Société Virtual-Net
[Tous textes et propos tenus dans ce couriel sont sous license DMDZZ]


pgp6Zxum4rF0S.pgp
Description: PGP signature

[RFC] Debian ruby policy (Re: Fw: Re: Ruby 1.8 transition plan; debian-ruby)

[Fumitoshi UKAI]

Hi,

I've wrote initial draft of debian ruby policy
 http://pkg-ruby.alioth.debian.org/ruby-policy.html/index.html
Comments are welcome.

First, I'll intent to package ruby-defaults soon, which provides ruby and
libruby packages in which this ruby policy documents is included, and
rename current ruby package to ruby1.6 (and libruby to libruby1.6, ...).
After doing that, we'll start 1.6->1.8 transition as written in above 
ruby policy documents.

I'd also like to hear opinions about ruby 1.8 packaging, especially 
from ruby package maintainers who maintain ruby modules package that are
included in upstream ruby 1.8 distribution. As you know, ruby 1.8
includes the following packages in upstream distribution, and now
ruby1.8 make these packages from ruby1.8 source package. Is this ok?
I'm wondering these modules will be released independently from ruby 1.8.x 
release. If so, it may be a problem because we may want such modules
that are released separately from ruby 1.8, instead of ruby 1.8 bundled ones.
What do you think about it?

New
 liberb-ruby1.8
 libdl-ruby1.8
 libbigdecimal-ruby1.8
 libracc-runtime-ruby1.8 (-ruby1.7?)

akira yamada <[EMAIL PROTECTED]>
 libwebrick-ruby1.8 (<- libwebrick-ruby)
 libzlib-ruby1.8 (<- libzlib-ruby)
 libopenssl-ruby1.8 (<- libopenssl-ruby)
 libstrscan-ruby1.8 (<- libstrscan-ruby)
 libdrb-ruby1.8 (<- drb?)
 libiconv-ruby1.8 (<- libiconv-ruby)
 libxmlrpc-ruby1.8 (<- xmlrpc4r?)

Joe Wreschnig <[EMAIL PROTECTED]>
 libtest-unit-ruby1.8 (<- libtest-unit-ruby)

Dmitry Borodaenko <[EMAIL PROTECTED]>
 libyaml-ruby1.8 (<- libyaml-ruby)

Oliver M. Bolzer <[EMAIL PROTECTED]>
 librexml-ruby1.8 (<- librexml-ruby)


At 05 Aug 2003 17:49:16 -0500,
Joe Wreschnig wrote:
> On Tue, 2003-08-05 at 12:12, Fumitoshi UKAI wrote:
> > Since ruby 1.8.0 was released recently, ruby developers will go to 
> > ruby 1.8.x, so that we, ruby maintenance team (akira, tagoh, ukai), 
> > are discussing about how to deal with Ruby 1.8 transition and trying to make
> > debian ruby policy soon.
> > 
> > For now, ruby package provides /usr/bin/ruby of ruby 1.6.x, and
> > ruby1.8 package provides /usr/bin/ruby1.8 of ruby 1.8.x.  Someone
> > want to use /usr/bin/ruby of ruby 1.8.x, so we're considering to use 
> > alternatives for /usr/bin/ruby to choice either ruby1.6, ruby1.8 (or any
> > other version of ruby in future).
> 
> There was a bug about this at some point, which I can no longer find,
> where I suggested doing for Ruby what Python does. Which is essentially:
> - 'ruby' is a metapackage depending the current default version of Ruby
> for Debian.
> - 'rubyX.Y' is a specific version of Ruby. 'ruby' depends on one of
> these.
> 
> - 'libfoo-bar-ruby' is a metapacakge depending on libfoo-bar-rubyX.Y,
> where X.Y is the default version of Ruby (the same as the one 'ruby'
> depends on).
> - 'libfoo-bar-rubyX.Y' is foo-bar for a specific version of Ruby. The
> above depends on one of these. (These packages may be unncessary if the
> directory tree I outlined below is used, and the package is
> version-independent.)

Hmm, I agree that it would be good.

> As for module include paths, they're less important since most Ruby
> modules query Ruby for the right information at build-time anyway, but
> I'd like to see version-independent directories, and also preferrably a
> tree under /usr/share, too. Say,
> 
> These are arch-independent:
> - /usr/share/ruby for Ruby modules that work with any version.
> - /usr/share/ruby/X.Y for Ruby modules that depend on version X.Y.

Currently, ruby upstream doesn't support such version independent module 
path /usr/share/ruby in $LOAD_PATH. Should we modify ruby 1.8 or later 
to support this?
 
> These are arch-dependent:
> - /usr/lib/ruby/version/X.Y/#{arch}-#{os} for all arch-dependent
> modules. I believe most architecture-dependent modules need to be
> recompiled for each version of Ruby anyway, and so a version-independent
> architecture-dependent directory makes no sense.

Yes, I agree.

Regards,
Fumitoshi UKAI


pgpsmdcpVGl6X.pgp
Description: PGP signature

Bug#206421: ITP: gaim-encryption -- Gaim plugin that provides transparent RSA encryption

[Leo Costela]

Package: wnpp
Version: unavailable; reported 2003-08-20
Severity: wishlist

* Package name: gaim-encryption
  Version : 2.06
  Upstream Author : Bill Tompkins 
* URL : http://gaim-encryption.sourceforge.net
* License : GPL
  Description : Gaim plugin that provides transparent RSA encryption

Features include:

Re: what about ip's

[John Hasler]

David Smith writes:
> my first assumption is that charter sells their users email addresses.
> does anyone on this list know how an unused email address that has never
> been used can have spam without the ip giving the address out?

Did you use 'dsmith' as the user name for the charter.net account?  If so
the answer should be obvious.

Hint: 99% of my spam is addressed to non-existent users.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: #206298 spip: prerm script blindly removes directories

[Jamin W. Collins]

On Wed, Aug 20, 2003 at 05:38:42PM +0200, Gaetan Ryckeboer wrote:
> Le Wed, Aug 20, 2003 at 09:26:14AM -0600, Jamin W. Collins a ?crit :
> > 
> > Is this uploaded data recorded anywhere?  In the MySQL database
> > perhaps?  If so, the file names can be retrieved from there for
> > removal on purge.
>
> Mmm... yes and no. Some of them could be. But a user may upload files
> without using them in the application.  So, the files are available,
> but unused, and unreferenced.

That would appear to be a deficiency of the spip app and one that should
probably be brought to the upstream developers attention.  The
application should probably log all uploads.

> > Additionally, you may upset users by simply deleting their uploaded
> > files on purge.  Some may see this as deletion of user data, which
> > should not be done.
>
> Of course, I understand. But I wonder they won't upload personal files
> for another use than spip here...

This falls into something of a grey area.  Can the data concievably be
of value ot the user without spip?  If so, then it is probably user data
and should not be removed without confirmation from the user (debconf
prompt that defaults to no?)

> > As someone else has already pointed out, /usr/share should be
> > capable of being made read-only.  Any runtime changing data for an
> > application
>
> True. But due to the implemntation of the application, which is
> written in php, datas are stored on the program dir. There is no real
> separation between datas and functions.
> 
> And if i symlink some datas (for apache access AND direct file handler
> access), i'll will setup another alarm... and it won't be accepted.

So, use Alias directives to relocate the directories that need changing
data to /var/lib.  There is no need to use symlinks to accomplish this.
As a matter of fact, your current apache include enables the following
of symlinks, which it doesn't need and probably shouldn't. I can provide
examples of this if you need.

-- 
Jamin W. Collins

Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo

Re: FTBFS: architecture all packages

[Matthias Urlichs]

Hi, Andrew Suffield wrote:

>> If its hoop-jumping then it must be intentional. Point is it happens.
> 
> Who cares? We cannot build an automated system here that will be able
> to stop people doing things like that.

Why not? Just block binary uploads completely, and let everything get
built by the buildds. I certainly plan to do that with my own uploads.
(I've already set up my own buildds).

I'd go one step farther and schedule a low-priority rebuild of everything
that build-depends on a package which gets updated.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Is knowledge knowable?  If not, how do we know that?

Re: Bits from the RM

[Joel Baker]

Hi, I'm Troy McClure - you may remeber me from such threads as "How do we
get Debian to have a useful release timeframe", and... *er, wait*.

Okay, that sillyness aside...

On Wed, Aug 20, 2003 at 08:51:16AM -0400, Theodore Ts'o wrote:
> 
> Better to have a hard freeze schedule, and then try to turn out new
> stable releases every 6-9 months.  Then folks won't be so desperate to
> shove new things in and screw up the release.  The problem, though, is
> the first such attempt take release schedules seriously and
> agressively (a) a really hardass RM, and (b) a certain amount of faith
> by the developers that we really can get our act together about short,
> regular, predictable releases.

Much, much better. I'd love to see it manage to hit every six months (and
even I agree that more often that that probably isn't feasible; most of the
major projects I know of that do scheduled releases don't have cycles < 6
months, and generally don't have too many users screaming about out-of-date
software). The first time is going to be a lot of unfamiliar, a lot of
hectic, and frankly, probably a lot of things that we don't get quite as
right as we could with experience - since, of course, part of the need is
to gain that experience.

I'm glad to see, however, that an RM has decided that targeting an actual
date, with an actual and concrete timeline (to compare against and know if
we're slipping too far), and clear mileposts along the way, is a meaningful
way to attempt a release.

You already have (b) from this quarter - and my profound hope that we
can, in fact, pull this off. Because it would resolve about 80% of the
complaints I've ever heard from folks about Debian (another 19% being the
install setup, which is also being remedied, and 1% being it's focus on
Linux, which is a separate question entirely - and no, I do not forsee
trying to get netbsd-i386 into sarge. If we manage to achieve a six-month
turnaround, quite possibly not even into sarge+1; NetBSD hasn't announced a
release target for 2.0 yet).

Off to hunt some RC bugs, now... (yeah, yeah, I should have been doing
this all along, but frankly, porting work took priority when there was no
release goal :)
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU NetBSD/i386 porter: :' :
 `. `'
   `-


pgpmFdFGuvjMV.pgp
Description: PGP signature

Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]

[Goswin von Brederlow]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> On Tue, Aug 19, 2003 at 09:24:25PM +0200, Goswin von Brederlow wrote:
> > [EMAIL PROTECTED] (Aaron M. Ucko) writes:
> > 
> > > How about requiring the debian directory to have an appropriately
> > > named parent (as determined by debian/changelog and debian/control,
> > > which should probably also have to agree...), unless the user runs
> > > debuild with some sort of --force option?
> > 
> > But then its a question of what name to use?
> > 
> > I do have the following four cases:
> > 
> > 
> > 
> > 
> 
> I really like this idea, thank you!  I will accept directory names
> matching the regexp /^$package(-.*)?$/ - does that seem reasonable?

Fine with me.

MfG
Goswin

Re: Bits from the RM

[Bruce Sass]

On Wed, 20 Aug 2003, cobaco wrote:
> I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 ->
> 3.2 is evolutionary without big changes to what was already there.

It does not take a big change to break software...
e.g., openssh changed a message and the sftp kioslave broke
http://bugs.kde.org/show_bug.cgi?id=51359

I think you are missing the point of "stable", and Debian's users who
don't would be more disappointed with just released software in stable
than with somewhat out-dated software.

Keep in mind that if this experiment works, "testing" will end up
being what you wish "stable" was, at least that is how I see it.


- Bruce

Re: what about ip's

[Josh McKinney]

On approximately Wed, Aug 20, 2003 at 10:06:15AM -0400, David Smith wrote:
> i've had cable connectivity with charter.net for more than 1 year. until
> yesterday i've never had need of an email acct there. i planned on using the
> address at charter when the spam at my top-10 acct became unbearable. when i
> finally got my log-in info for the charter acct. i logged in and to my
> surprise there were already more than 200 spams waiting for me.
> 
> my first assumption is that charter sells their users email addresses. does
> anyone on this list know how an unused email address that has never been
> used can have spam without the ip giving the address out?
> 

>From a lot of the spam I get at my charter.net account it seems to be
that spammers just use some sort of dictionary and add that on the front
of popular domain names.  Somebody probably wrote a Perl script and sold
it on Ebay!

--  
Josh McKinney|  Webmaster: http://joshandangie.org
--
 | They that can give up essential liberty
Linux, the choice   -o)  | to obtain a little temporary safety deserve 
of the GNU generation/\  | neither liberty or safety. 
_\_v |  -Benjamin Franklin

Re: Bits from the RM

[Santiago Vila]

On Wed, 20 Aug 2003, Steve Langasek wrote:

> On Wed, Aug 20, 2003 at 03:52:42PM +0200, Santiago Vila wrote:
> > Will we some day consider seriously the idea of autobuilders compiling
> > against testing those packages which do not need libraries from
> > unstable to be built?
>
> Do you foresee any reasons why using experimental for new library
> uploads wouldn't serve the same purpose?

Yes, autobuilders do not build stuff from experimental, so it will
hardly serve the same purpose as the current unstable, even if you
convince a lot of users so that experimental is tested as much as
unstable.

Re: non-DD contributors and the debian keyring

[Goswin von Brederlow]

Martin Quinson <[EMAIL PROTECTED]> writes:

> On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
> > * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-20 10:31]:
> > > > Martin Quinson <[EMAIL PROTECTED]> wrote:
> > > > > I just wondered if it would be possible for non-developper
> > > > > contributors to Debian to get their GPG key in the Debian keyserver. 
> > > 
> > > You can also apply as a NM for translation work. You don't need to
> > > maintaine a package or know much about the packaging system for
> > > that. You get different task&skill tests.
> > 
> >V I P   Martin Quinson <[EMAIL PROTECTED]>
> 
> Exact. I *did* apply. I'm even pretty well advanced in the process.

There is the part before waiting for the DAM and while waiting for the
DAM. :)
 
> $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
> 
> This is the ID of my key, available from www.keyserver.net and signed by 2
> DD. Did I mess something up ?
> 
> Shouldn't Debian make sure that work submition from non-DD contributor are
> signed, just like it does for the work submition from DD ?

Usually the sponsor looks everything over so signing is not realy
neccessary. Of cause if you have the same sponsor repeatetly he might
want to just check your signature and sponsor the changes blindly
knowing you did good work in the past.

But he would replace your signature with his for uploading purposes so
its just for his sake so he knows it was you.

MfG
Goswin

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Goswin von Brederlow]

"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes:

> Ok.  Lets leave aside for a moment the .debs which would go into contrib
> or non-free so would have to be built seperately.  What happens if
> webmin-squid has an RC bug?  As Goswin said, all the webmin-* packages
> will be held back from testing.  What happens if webmin-squid is ok but
> squid itself is not in testing?  (or is removed from testing.  This could
> happen if it has an RC bug at freeze time,)  Again all the webmin packages
> would be affected.  What if webmin-squid has one or two upstream bugfix
> releases in between major webmin versions?  Every other webmin module
> would also have to be rebuilt too even though nothing changed.
> 
> What you are suggesting was the way things were done before 0.98 and it
> caused all sorts of annoyance for me and the users.  I'll make any changes
> necessary to be policy-compliant but I'm firm about the multiple-source
> package thing.

The only problem with that is the current failure to comply to policy,
i.e. build from source as they should.

But now that you have seen the light :) keep on working.

MfG
Goswin

Re: Bits from the RM

[Matthias Urlichs]

Hi, Steve Langasek wrote:
> KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by
> almost two months:
> 
Uh, you've got that turned around. October is not _missing_ the deadline,
that's _beating_ it.

> * October 15th
>Final, last-minute, low-risk bug fixes only

.. which means we have two+ months to fix any problems.

I do agree, however, that we shouldn't delay Sarge because of KDE.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
New York now leads the world's great cities in the number of people around
whom you shouldn't make a sudden move.
-- David Letterman

Re: Binaryless uploads

[Manoj Srivastava]

On Tue, 19 Aug 2003 16:16:10 -0400 (EDT), Jaldhar H Vyas
<[EMAIL PROTECTED]> said:  

> On Tue, 19 Aug 2003, Goswin von Brederlow wrote:
>> Then the source should be split in a way that the normal
>> debian/rules files work and common files (like headers) stuffed
>> into a -dev package you can build-depend on.
>>

> Have you actually bothered looking at the webmin tarball?  I repeat
> it is a set of independent modules only bundled together upstream
> for convenience.  (And btw, it is a set of perl scripts.)

As I understand it, there is an script that does the
 separation for you when you package the .debs. Is there a reason a
 similar script can't be invoked by debian/rules to create the
 multiple debs from the same source?

> debian/rules does work.  It just doesn't produce what people expect
> it to.  That's why barring any better ideas, I'm just going to
> reduce the size of the orig.tar.gz to the bits that actually make up
> the webmin binary package.

Well, it is your package, and your decision, but retaining
 upstream packaging is generally desirable; and if you already have an
 automated means of separating out the irig.tar.gz for each binary
 .deb, doing so in ./debian/rules may be a better solution.

manoj
-- 
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice. Kirk, "The Squire of Gothos",
stardate 2124.5
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Debian Weekly News - August 19th, 2003

[Jérôme Marant]

Quoting Scott James Remnant <[EMAIL PROTECTED]>:

> > No he wouldn't. FDL is about free documentation. :-)
> > 
> Except it isn't :-)

According to you :-)

-- 
Jérôme Marant <[EMAIL PROTECTED]>

Re: Debian Weekly News - August 19th, 2003

[Scott James Remnant]

On Wed, 2003-08-20 at 08:35, JÃrÃme Marant wrote:

> Quoting Josselin Mouette <[EMAIL PROTECTED]>:
> 
> > Le mar 19/08/2003 Ã 23:33, Mike Hommey a Ãcrit :
> > > Ok, let's google a bit, and shazaam !
> > >
> > http://www.linex.org/sources/linex/debian/linex/nvidia-glx_1.0.4349-1_i386.deb
> > > Oh ! non-free software !
> > > 
> > > Thanks Richard for keeping me laughing.
> > 
> > Bah, if RMS really didn't like non-free software, he would give up with
> > that FDL stuff...
> 
> No he wouldn't. FDL is about free documentation. :-)
> 
Except it isn't :-)

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?


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

Re: ftp.gnu.org cracked

[Scott James Remnant]

[ Moved to debian-devel, I don't think this is relevant to private as
  the GNU crack is well publicised ]

On Mon, 2003-08-18 at 14:58, Matt Zimmerman wrote:

> On Mon, Aug 18, 2003 at 12:35:44PM +1000, Russell Coker wrote:
> 
> > On Mon, 18 Aug 2003 12:51, Robert Millan wrote:
> > > What do you suggest to do? First, can this dicussion be disclosed? (e.g:
> > > into debian-security). Then how can we deal with these two problems? Would
> > > an alert message to -devel-announce suffice?
> > 
> > The hack of the GNU server is no secret, and neither is our reliance on GNU 
> > software.  I think that anyone who knows anything about Debian can work out 
> > the issues for themselves.  Therefore trying to keep this secret gains us 
> > nothing and only gives a risk of more concern.  I suggest publicising 
> > everything.
> 
> If we're going to make a statement about it, we should have some facts to
> release.  For example, if someone would like to verify the validity of the
> GNU source tarballs that we ship against the checksums published by GNU,
> that would be great.
> 
No problem, this is only a quick run -- others may find ways to improve
this script somewhat.

153 files were compared (out of 1624 available checksums), reasons for
missing comparisons probably include changes in source package name
compared to GNU tar name, or simply differing versions.

113 checked out OK.  This means that the .orig.tar.gz in Debian has the
same checksum as the equivalent GNU tar, and that the GNU checksum is
considered valid by GNU.

40 did not check out.  This doesn't mean we've got cracked versions, it
just means that our .orig.tar.gz isn't identical to the GNU .tar.gz.

Also note that I just checked what versions could be found in the pool,
not necessarily the latest unstable version.  Many of the latest
versions are missing a GNU-valid md5sum anyway.

The script I used is attached, it takes the before-2003-08-01.md5sums
file from the GNU ftp site (run through gpg to remove signature) as
either stdin or a command-line argument.

Here's the (sorted) results.

   adns: adns_1.0.orig.tar.gz OK.
   anubis: anubis_3.6.2.orig.tar.gz OK.
   aspell: aspell_0.50.3.orig.tar.gz OK.
   autoconf: autoconf_2.13.orig.tar.gz OK.
   autoconf: autoconf_2.53.orig.tar.gz OK.
   autoconf: autoconf_2.57.orig.tar.gz OK.
   autogen: autogen_5.3.5.orig.tar.gz OK.
   barcode: barcode_0.98.orig.tar.gz OK.
   bc: bc_1.06.orig.tar.gz OK.
   bison: bison_1.28.orig.tar.gz OK.
   bison: bison_1.35.orig.tar.gz OK.
!! cfengine: cfengine_1.5.3.orig.tar.gz NOT OK 
(2603cf1cd3225b06e5df725c866dc987 != b25c09e5d9ee55722771a3732c0b10ff)
!! cfengine: cfengine_1.6.4.orig.tar.gz NOT OK 
(f1b94557fe01869eee9764e613efa0ee != 5bc50dbeb87e6edbd68526cfacff6fb3)
!! clisp: clisp_2.28.orig.tar.gz NOT OK (d5f8acf2de0db2f5f53e7747d0d84503 != 
7d245c446dd5cdeb263b5648bfb4fb76)
   clisp: clisp_2.27.orig.tar.gz OK.
   clisp: clisp_2.30.orig.tar.gz OK.
!! coreutils: coreutils_5.0.orig.tar.gz NOT OK 
(d16b769d380a0492a4c5ee61d2619985 != a0ef2d8abd223aca757228590ded9e63)
!! cpio: cpio_2.4.2.orig.tar.gz NOT OK (e651ca1e1ac53aaebfa7ad256b0fe4fc != 
3e976db71229d52a8a135540698052df)
!! cpio: cpio_2.4.2.orig.tar.gz NOT OK (e651ca1e1ac53aaebfa7ad256b0fe4fc != 
3e976db71229d52a8a135540698052df)
   cpio: cpio_2.5.orig.tar.gz OK.
   ddd: ddd_3.3.1.orig.tar.gz OK.
!! dejagnu: dejagnu_1.4.2.orig.tar.gz NOT OK (f8d9f36ea74fd56ad4a68d5cc2a14bba 
!= a697e39c767a47aca9166fcd7420e4b8)
   dejagnu: dejagnu_1.4.3.orig.tar.gz OK.
   diction: diction_1.02.orig.tar.gz OK.
!! doschk: doschk_1.1.orig.tar.gz NOT OK (38b9613f471667573956f0e02b9ff091 != 
112565f30ef98595b363afb70cb6a835)
!! doschk: doschk_1.1.orig.tar.gz NOT OK (38b9613f471667573956f0e02b9ff091 != 
112565f30ef98595b363afb70cb6a835)
   ed: ed_0.2.orig.tar.gz OK.
   ed: ed_0.2.orig.tar.gz OK.
   electric: electric_6.05.orig.tar.gz OK.
   elib: elib_1.0.orig.tar.gz OK.
   emacs-lisp-intro: emacs-lisp-intro_2.04.orig.tar.gz OK.
   fileutils: fileutils_4.1.orig.tar.gz OK.
   gawk: gawk_3.1.0.orig.tar.gz OK.
   gawk: gawk_3.1.1.orig.tar.gz OK.
   gawk: gawk_3.1.3.orig.tar.gz OK.
!! gcal: gcal_2.40.orig.tar.gz NOT OK (0a17026a3950847bb42206cfa03c1c98 != 
6b6058fa80c2e95392ef1ca561e4800f)
!! gcc: gcc_2.95.2.orig.tar.gz NOT OK (0e36957d734286e242e9697fd2806c4f != 
110f1e5b3adfefc9d7be071e91c54f6a)
   gdb: gdb_5.3.orig.tar.gz OK.
   gdbm: gdbm_1.7.3.orig.tar.gz OK.
   gdbm: gdbm_1.8.3.orig.tar.gz OK.
   gengetopt: gengetopt_2.10.orig.tar.gz OK.
   gengetopt: gengetopt_2.6.orig.tar.gz OK.
   gengetopt: gengetopt_2.9.orig.tar.gz OK.
   gettext: gettext_0.10.35.orig.tar.gz OK.
   gettext: gettext_0.10.40.orig.tar.gz OK.
   gettext: gettext_0.11.5.orig.tar.gz OK.
   gettext: gettext_0.11.orig.tar.gz OK.
   gettext: gettext_0.12.1.orig.tar.gz OK.
   gfax: gfax_0.4.2.orig.tar.gz OK.
!! gforth: gforth_0.5.0.orig.tar.gz NOT OK (db16b64e9d63934bc4455e9b2aebbe13 != 
8aade0bf98bfc57d084beb3af3875c36)
   gforth: gforth_0.6.1.orig.tar.gz OK.
!! ggradebook: 

Does anyone use barrendero, or know of an equivalent?

[Steve Langasek]

Hello,

The package barrendero is a candidate for removal from testing.  It has
two RC bugs, no response from the maintainer, and the upstream website
seems to have vanished (the maintainer is also upstream).  It seems like
a useful tool:

Description: Deletes messages on the spool dir depending on their age.
 Barrendero is intended to limit the disk space wasted at the spool
 directory. It deletes mail messages depending on their age, and has
 the ability to send warnings and reports to the users, to make full
 and partial backups, and to have different allowed ages on a per-user
 basis.
 Warning and report messages are cusomizable and can be translated easely
 in order to make this package useful in any environment.
 This way of handling mail as an advantage over the traditional 'quota'
 system: quotas make the end user loose NEW mail, barrendero deletes
 OLD mail, so the new mail is always available.

But descriptions can be deceiving.  Does anyone use this package who
could comment on its reliability?  Does the lack of other bugs indicate
that the software is mature and stable, or unused?  Does anyone know of
another package that provides similar functionality?

Thanks,
-- 
Steve Langasek
postmodern programmer


pgpy7v2KoqL8F.pgp
Description: PGP signature

Proposal: make kernel install easier

[Adam C Powell IV]

Greetings,

Installing a new kernel package can be a bit of a pain, especially for
newbies, what with hand-editing lilo.conf or config files for other
bootloaders, from grub to yaboot/quik, aboot, palo, you name it.  Yes,
the kernel-image postinst runs lilo, but lilo.conf is invariably out of
date, so this is relatively useless except for upgrades.

So why not (optionally) automate the process a bit?  Use a directory
e.g. /usr/lib/bootloaders/ to put scripts for managing the .conf files
and running the bootloaders.

For example, quik could have debconf questions: "Manage quik.conf using
debconf?" and "Install new kernels automatically?" and perhaps "Global
kernel option defaults" (though perhaps this would be better outside of
each individual bootloader).  Then each kernel package would have a low-
to med-priority debconf question asking with what options to boot the
kernel starting from global defaults.  It could also ask whether to make
this image top priority in the .conf, and what name string to use for
this image.  Also, quik could Provide virtual package bootloader which
kernel-image packages could Suggest.

[A really fancy bootloader could also use debconf to prompt for info
about other OSes on other partitions for its .conf, e.g. "bye" for MacOS
in quik...]

The kernel-image's postinst would run all of the scripts in
/usr/lib/bootloaders/ with arguments like --add-index-entry --name
"2.4.20-2-powermac" --kernel /boot/vmlinuz-2.4.20-2-powermac --initrd
/boot/initrd.img-2.4.20-2-powermac (or --noinitrd) --boot-options
"root=/dev/hdb6 video=offb" --top-boot-priority .  If quik's "Manage
quik.conf automatically" answer is no, then /usr/lib/boot-loaders/quik
with these options does nothing.

Then the kernel-image's postinst runs the scripts with something like
--make-bootable and /usr/lib/bootloaders/quik goes off and makes the
first and second boot blocks, does its open firmware thing etc., and
reports back success (or not).  Again, if quik's "Install new kernels
automatically" answer is no, this does nothing.

The kernel prerms (or postrms?) would also have to run the scripts with
--remove-index-entry --name 2.4.20-2-powermac and again with
--make-bootable in order to clean up safely.

The only trouble I can think of is what to do with already-installed
kernels which don't have such postinst/prerm options.  The .conf files
can be generated automatically, but when a kernel is removed, they're
not cleaned up.  Any "/usr/lib/bootloaders/quik --regenerate-index" type
thing would have to be run manually on each kernel removal, though a
debconf info thing in the new quik package could let users know this.

Also, on Alphas running ARC/AlphaBIOS, Netwinders, etc. there would
still be manual configuration to do during the boot process, so this
wouldn't cure everybody's ills.

Aside from these bits of trouble, such a system would make a lot easier
the process of installing and removing what are now some of the most
annoying packages to deal with (for me at least), particularly given
quirks on different arches.

If there's interest (and no show-stoppers anyone can think of), I'll
start writing patches to kernel-package, lilo, maybe even quik :-) --
that is, unless someone else wants to, e.g. their maintainers.

[Please CC me in replies as I'm not subscribed.  And apologies if this
has been brought up before; searches on lists.debian.org didn't turn up
anything.]

Cheers,
-- 
-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://lyre.mit.edu/~powell/The_Best_Stuff_In_The_World_Today_Cafe.ogg

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Jaldhar H. Vyas]

On Tue, 19 Aug 2003, Steve Langasek wrote:

> Yep.  And given that upstream offers webmin as an all-in-one solution to
> web-based management needs, I don't really see any reason why they
> shouldn't be kept lock-step with one another.

As Debian developers our goal is to make an integrated OS which works
according to our own internal logic.  From that perspective some of the
choices made by upstream maintainers are not optimal.  For instance, one
of the reasons all the webmin modules are distributed together is because
there is no cross-platform dependency mechanism so the author doesn't know
what you've got.  So he just installs everything and its up to you to
switch off the stuff you don't need.  Thanks to dpkg, we don't need to do
that.  If e.g. I'm using postfix, there is absolutely no reason why I
should need to have the webmin sendmail module installed.


>   I particularly don't see
> why it's good that bugs in this group of packages themselves be ignored
> for testing processing of the others.
>
> Does webmin even provide any standard APIs that guarantee particular
> modules will work with particular versions of webmin?  Version slip here
> seems like it could pose a serious problem, even *beyond* the usual
> partial upgrades question.
>

No guarantee is given but so far backward compatability has been pretty
good fwiw.


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: non-DD contributors and the debian keyring

[Steve Langasek]

On Wed, Aug 20, 2003 at 11:23:47AM +0200, Martin Quinson wrote:
> On Wed, Aug 20, 2003 at 06:46:34PM +1000, Martin Michlmayr wrote:
> > * Goswin von Brederlow <[EMAIL PROTECTED]> [2003-08-20 10:31]:
> > > > Martin Quinson <[EMAIL PROTECTED]> wrote:
> > > > > I just wondered if it would be possible for non-developper
> > > > > contributors to Debian to get their GPG key in the Debian keyserver. 
> > > 
> > > You can also apply as a NM for translation work. You don't need to
> > > maintaine a package or know much about the packaging system for
> > > that. You get different task&skill tests.
> > 
> >V I P   Martin Quinson <[EMAIL PROTECTED]>

> Exact. I *did* apply. I'm even pretty well advanced in the process.

> $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0

> This is the ID of my key, available from www.keyserver.net and signed by 2
> DD. Did I mess something up ?

> Shouldn't Debian make sure that work submition from non-DD contributor are
> signed, just like it does for the work submition from DD ?

The keyring on keyring.debian.org is used directly as a means of
authorizing people to a number of Debian resources, including the
package upload queue and d-d-a.  Whether you agree with this design or
not, it means that the Debian keyserver is not suitable for use as a
general-purpose means of *authenticating* people.  For authenticating
PGP users to one another, you should use the usual Web of Trust to
achieve this.

-- 
Steve Langasek
postmodern programmer


pgpiZwGdLyHUr.pgp
Description: PGP signature

Re: What doing with an uncooperative maintainer ?

[Marcelo E. Magallon]

On Mon, Aug 18, 2003 at 04:32:03PM +0200, Thomas Hood wrote:

 > I don't see why it would be idiotic to fork the package.
 > If you can package this application better than the 
 > current maintainer then go ahead and do so.

 Forking packages outside of Debian might or might not achieve the goals
 you mention.  Forking packages inside Debian is not only problematic
 but idiotic.  Repeat after me: the package management system does not
 support package renames.  Upgrades across packages with different names
 simply doesn't work.  Going down that route for the little benefit of
 being elite^Wup to date for the sake of being up to date is not worth
 it.  Talk with the maintainer.  Or NMU.  Or make noise on -devel.  But
 don't "fork" packages.

 Marcelo

Re: #206298 spip: prerm script blindly removes directories

[Gaetan Ryckeboer]

Le Wed, Aug 20, 2003 at 09:26:14AM -0600, Jamin W. Collins a écrit :
> > All right. I understand the problem. But the directories removed by
> > the postrm/purge are normaly only used :
> > - by user, to upload datas related to his spip installation,
> Is this uploaded data recorded anywhere?  In the MySQL database perhaps?
> If so, the file names can be retrieved from there for removal on purge.
Mmm... yes and no. Some of them could be. But a user may upload files
without using them in the application.
So, the files are available, but unused, and unreferenced.

> Additionally, you may upset users by simply deleting their uploaded
> files on purge.  Some may see this as deletion of user data, which
> should not be done.
Of course, I understand. But I wonder they won't upload personal files
for another use than spip here...

> > - by spip himself, to store cache informations,
> Are the file names predictable in any way?  If so, you can look for
> files fitting the pattern.
True.

> > - by spip himself, for log or backups.
> The file names of the logs or backups should be predictable, right?
True.

> As someone else has already pointed out, /usr/share should be capable of
> being made read-only.  Any runtime changing data for an application
True. But due to the implemntation of the application, which is written
in php, datas are stored on the program dir. There is no real separation
between datas and functions.

And if i symlink some datas (for apache access AND direct file handler
access), i'll will setup another alarm... and it won't be accepted.

-- 
"Il n'y a qu'un décolleté pour pousser un homme à rechercher la 
 profondeur chez une femme." 
-- Zsa Zsa Gabor

Gaétan RYCKEBOER  Société Virtual-Net
[Tous textes et propos tenus dans ce couriel sont sous license DMDZZ]


pgpa40uOPwjAk.pgp
Description: PGP signature

what about ip's

[David Smith]

i've had cable 
connectivity with charter.net for more than 1 year. until yesterday i've never 
had need of an email acct there. i planned on using the address at charter when 
the spam at my top-10 acct became unbearable. when i finally got my log-in info 
for the charter acct. i logged in and to my surprise there were already more 
than 200 spams waiting for me. 
 
my first assumption 
is that charter sells their users email addresses. does anyone on this list know 
how an unused email address that has never been used can have spam without the 
ip giving the address out?
 
thanksDavid Smith
 
<>

Re: Binaryless uploads [Was: FTBFS: architecture all packages]

[Jaldhar H. Vyas]

On Wed, 20 Aug 2003, Brian May wrote:

> When Jaldhar takes about dependancies, I assume he means normal
> "Depends", not "Build-Depends"???
>

Correct.

[...]

> Source package has the following files (note: this is called a "source
> package" not a "binary package"):
>
> webmin_1.100.orig.tar.gz
> webmin_1.100-2.diff.gz
> webmin_1.100-2.dsc
>
> Extracting this source package and running debian/rules build would
> produce the following *binary packages*:
>
> webmin_1.100-2_all.deb
> webmin-core_1.100-2_all.deb
> webmin-apache_.100-2_all.deb
> webmin-squid_.100-2_all.deb
> [...list truncated...]
>
> Jaldhar, please tell me what the problem is with the above approach.
>

Ok.  Lets leave aside for a moment the .debs which would go into contrib
or non-free so would have to be built seperately.  What happens if
webmin-squid has an RC bug?  As Goswin said, all the webmin-* packages
will be held back from testing.  What happens if webmin-squid is ok but
squid itself is not in testing?  (or is removed from testing.  This could
happen if it has an RC bug at freeze time,)  Again all the webmin packages
would be affected.  What if webmin-squid has one or two upstream bugfix
releases in between major webmin versions?  Every other webmin module
would also have to be rebuilt too even though nothing changed.

What you are suggesting was the way things were done before 0.98 and it
caused all sorts of annoyance for me and the users.  I'll make any changes
necessary to be policy-compliant but I'm firm about the multiple-source
package thing.


-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>
La Salle Debain - http://www.braincells.com/debian/

Re: #206298 spip: prerm script blindly removes directories

[Jamin W. Collins]

On Wed, Aug 20, 2003 at 01:45:09PM +0200, Gaetan Ryckeboer wrote:
> > Package: spip
> > Version: 1.6.0-2
> > Severity: normal
> > 
> > The prerm script blindly deletes the following directories and all
> > subdirectories:
> > 
> >/var/cache/spip
> >/usr/share/spip/ecrire/upload
> >/usr/share/spip/ecrire/data
> > 
> > There is no guarantee that the files in these directories belong
> > only to this package.  While it is quite likely that they will, it
> > can not be guaranteed and care should be taken on package removal to
> > not remove any files that are not owned solely by the package.
> 
> All right. I understand the problem. But the directories removed by
> the postrm/purge are normaly only used :
> - by user, to upload datas related to his spip installation,

Is this uploaded data recorded anywhere?  In the MySQL database perhaps?
If so, the file names can be retrieved from there for removal on purge.

Additionally, you may upset users by simply deleting their uploaded
files on purge.  Some may see this as deletion of user data, which
should not be done.

> - by spip himself, to store cache informations,

Are the file names predictable in any way?  If so, you can look for
files fitting the pattern.

> - by spip himself, for log or backups.

The file names of the logs or backups should be predictable, right?

As someone else has already pointed out, /usr/share should be capable of
being made read-only.  Any runtime changing data for an application
should be under /var/lib.  For more information the following link may
help:

   http://www.debian.org/doc/packaging-manuals/fhs/fhs-toc.html
   
-- 
Jamin W. Collins

This is the typical unix way of doing things: you string together lots
of very specific tools to accomplish larger tasks. -- Vineet Kumar

UniteU's AntiVirus scan detected a virus in a message you sent to %2

[nortonsadmin]

Recipient of the infected attachment:  DC3, UniteU\Mailbox Store (DC3), Paige 
Obrien/Inbox
Subject of the message:  Re: Details
One or more attachments were intercepted and deleted
  Attachment document_9446.pif was Deleted for the following reasons:
Virus [EMAIL PROTECTED] was found.

Re: Bits from the RM

[cobaco]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2003-08-20 15:17, Wouter Verhelst wrote:

> You're trying to say that it's impossible for an organization to install
> some thousands of X terminals that all run KDE (which, of course, is
> installed on the server)? 
not what I'm trying to say

>Or do you just mean that in such a situation,
> the users' desktops aren't mission critical?
>
> > Besides major bugs would've been filtered out by the kde release proces,
> > and minor bugs would not interfere with functioning of a server.
>
> You can't know that. If the primary function of that server is 'to
> support X terminals or diskless clients that run KDE', then KDE probably
> is "quite" mission critical.

KDE is not mission critical in the sense that when a user's KDE-instance 
crashes the KDE-instances of the other users will continue to run. Just like 
when -in that same organization with some thousands of X terminals- 1 X 
terminal has a hardware problem this is not a mission critical problem (for 
the organization, it may be considered a mission critical problem for the 
user of that particular terminal).
The mission critical software in this example would be the 
ltsp-server-software.

> > >And I don't mind Debian stable being marked as "always
> > > having an outdated KDE".  It is supposed to work that way.
> >
> > While I agree it wouldn't be the end of the world, and it has certainly
> > been that way sofar, I most definately do _NOT_ agree that "it is
> > supposed to work that way".
>
> Then I suggest you start maintaining KDE backports for stable, because
> it most certainly is supposed to work that way. We don't provide updates
> for stable; as such, the logical result is that stable becomes outdated.

I wasn't implying we should provide updates to stable, all I was saying is 
that at the moment a release becomes stable, then -if at all possible- this 
software should be up-to-date. 
I don't agree that 'software in stable is supposed to be out-dated', I do 
agree with 'software in stable tends to become outdated'.

> > Stable having outdated software is an (undesired) side-effect from
> > keeping the stable release stable.  If we can have up-to-date software
> > that is also reasonably stable (again this is end-user software, not
> > server-software) this is better no?
>
> It depends on what you find most important. If stability is most
> important, then no, it isn't. If being up-to-date is most important,
> we'd be wasting our time with all this freezing anyway.
It's not a question of either stability or either up-to-dateness but of the 
right balance between the two. IMHO that balance lies differently for 
server-sofware then for end-user software 

NOTE: by server-software I mean software providing some service to the 
network, not just software running on a server-machine.

- -- 
Cheers, cobaco

/"\  ASCII Ribbon Campaign
\ /  No proprietary formats in attachments without request
 X   i.e. *NO* WORD, POWERPOINT or EXCEL documents
/ \  Respect Open Standards
  http://www.fsf.org/philosophy/no-word-attachments.html
  http://www.goldmark.org/netrants/no-word/attach.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Q4/s5ihPJ4ZiSrsRAq93AKCIHusZiafUHssWxE5t5KzNK3BdVQCfQkSv
VHbpDTmGpH+eGTkb2Vj1acY=
=mmjd
-END PGP SIGNATURE-

Re: Bits from the RM

[Anthony Towns]

On Wed, Aug 20, 2003 at 06:48:51PM +0800, Cameron Patrick wrote:
> There were pretty major changes between KDE 3 and KDE 3.1.  As a Debian
> user, I'd be rather miffed if a new version of KDE came out within a
> week of sarge being released ... on the other hand, if sarge is to be
> frozen in a couple of months' time, it seems unlikely that KDE 3.2 will
> be able to make it in.   *grumble* :(

You are, of course, welcome to feel whatever you like. But if you're
particularly interested in running the latest software, you shouldn't
be remotely interested in running Debian stable releases. That's not
what they're there for.

You should expect any software in a Debian stable release to be somewhere
between two months and two years out of date at any given time; with a
bias towards less out of date just after a release, and more out of date
just before a release. As a simple example, if we have releases on the
1st of December each year from now on, sarge's KDE should be between four
and sixteen months old, during sarge's run as stable. By contrast, if we
lived in a magical world where such things were feasible, and delayed
sarge by a week to include KDE 3.2, during sarge's life, KDE would be
between zero and twelve months old. [0]

Now perhaps this really is the difference you're hoping for, but it
sounds to me more like you're a bit disappointed that the version of
KDE in stable will be even a few months out of date, ever. Which is fair
enough: if you're not happy with running a version of KDE that's twelve
months older than the current release, stable's not what you should be
looking at; testing or unstable is.

You should, of course, then be massively disappointed that testing's
version of KDE is some 21-months old. But hey, win some, lose some.

Cheers,
aj

[0] Maths break! The average out-of-dateness over the life of stable in
the two cases is 10 months and 6 months respectively. The difference
is noticable, but not particularly extreme. If you want to make it
look a bit more extreme, you can start counting from major releases
instead of minor releases: that gives you 16 and 6 months averages
instead. For comparison, woody has KDE 2.2.2 which was out at the
end of November, so was eight months out of date when woody released
by that measure; and should we release Dec 1st, will have an average
out of dateness of 16 months counting minor releases, or 19 months
counting major releases.

In general, the average out of dateness is "u + p/2", where u is
how out of date the package is when we release, and p is the period
between releases. u is bounded below by however long it takes us
to become confident with a new release, c, and has an upper limit
of "p_u + c + l_m + l_r", where p_u is the time between upstream
releases, and l_m and l_r are "lag factors" -- l_m is the maximum
amount of time after a package could've been included in Debian (p_u +
c since the last new upstream version), that the maintainer can put
up with user requests and general guilt, before doing an upload,
and l_r is the "release lag" involved in getting the package settled
into testing.

  c <= u   < p_u + c + l_m + l_r

c + p/2 <= u + p/2 < p_u + c + l_m + l_r + p/2

c + p/2 <= oldness < p_u + c + l_m + l_r + p/2

We probably can't do anything about p_u, and there are definite lower
limits on p -- probably somewhere around six months. In any event, we
have:

general delays:

c -- how long it takes us to be confident a new upstream release
 is good, after it's released
p -- release length

variable delays:

p_u -- how often upstream releases
l_m -- how slack the maintainer can be
l_r -- how broken the testing scripts are and/or how broken
   the rest of Debian is

Plausible values for KDE core components at the moment are probably
something like:

c = 0.4
p_u = ~10 months for major releases, 2 months for minor releases
l_m = 0
l_r = 10 months

If we released right now, eg, we'd be releasing with the same version
of KDE that's in woody -- that's the impact of the l_r factor. Given
that we've been trying to get KDE into testing for literally twelve
months, it's reasonably safe to say that general breakage in Debian is
the biggest factor in out-of-dateness in stable. We've had numerous
breakages in glibc and other libraries KDE depend on for extended
periods.

Adjusting the release date to be after KDE 3.2's release still needs
to take in these other factors, in particular reducing l_r massively.
It might be possible to do that by saying "everything but KDE has to
be ready for release on 1st December, KDE has to be ready for release
by 31st December", however I'm not willing to make that much of a
special case. Moving the

Re: Bits from the RM

[Anthony Towns]

On Wed, Aug 20, 2003 at 08:49:33AM -0400, Matt Zimmerman wrote:
> On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote:
> > Also make sure to include some leg room if you depend on packages that
> > have a tendency to be buggy (glibc, for example).
> The new glibc has already stalled the progress into testing of a large
> number of packages, and the number of RC bugs still seems to be going up.
> How are we going to manage to produce a release in 6 months the face of this
> obstacle?  The last time there was this sort of breakage, it took many
> months just to get glibc itself it sorted out.

Yup. The difference is that this time we have a Glibc maintenance team
that's able to work together effectively, has some experience with the
package, and has a better understanding how important it is to get it
fixed quickly.

It's certainly similar to other disasters of the past twelve months,
and it's something to keep an eye on, and to randomly submit useful
patches for, but we're in a substantially better position to handle it
this time around.

Besides, what fun would a release be if we didn't have key machines
crashing, and chaos in important packages?

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


pgptEGDrU3foY.pgp
Description: PGP signature

Re: non-DD contributors and the debian keyring

[Stephen Frost]

* Martin Quinson ([EMAIL PROTECTED]) wrote:
> $ LC_ALL=C gpg --keyserver keyring.debian.org --recv-keys E145F334 
> gpg: no valid OpenPGP data found.
> gpg: Total number processed: 0
> 
> This is the ID of my key, available from www.keyserver.net and signed by 2
> DD. Did I mess something up ?

keyring.debian.org has only DDs in it.  I think people were suggesting
using the public keyservers.  keyring.debian.org isn't a part of the
public key servers.

> Shouldn't Debian make sure that work submition from non-DD contributor are
> signed, just like it does for the work submition from DD ?

Interesting question.  While it's not a bad idea I don't see it as
entirely necessary either.  At least when sponsoring a package the DD
performing the sponsor must check everything regardless of if it was
sent to them signed or not.  They have to check that the tarball given
matches that on the official site (or verify that it's clean and
correct some other way), they have to very carefully look through the
diff, they have to build the package themselves, they should compare
the diff to the prior versions diff if there was one, etc, etc.  It'
s not as much work as doing the packaging themselves but it still is a 
fair bit of work.  Once complete the sponsor should be completely
confident with the package.

DD's are expected to do this work for themselves too but there's no one
who's going to double-check it before it's put into the system so there
has to be a way to verify that it's been done- that's why DD's sign
their packages before uploading (at least one reason anyway).  DD's are
trusted to have checked over their packages and whatnot and signing the
packages basically says "I've checked over it and it should be
included."  Since, at least at one point not sure if it's still true,
packages could be uploaded via anonymous ftp so long as it was signed.

I don't know much about the translation work.  I would expect that this
work is checked by some DD before being incorporated too, even if it's
just to ensure the package builds correctly with it since we don't all
know every language..  The same is kind of true for patches which change
code the DD's might not be extremely familiar with, though there at
least they could consult with upstream if they were unsure.  I'm not
sure what kind of double-check could be done on the translation work
that's submitted, for example, via the BTS.  I'm also not sure it's
entirely necessary, I would find it pretty unlikely for someone to mount
an attack by submitting patches which translate debconf questions to ask
other things or something..

Stephen


pgpocKWMMln0k.pgp
Description: PGP signature

Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]

[Aaron M. Ucko]

Julian Gilbey <[EMAIL PROTECTED]> writes:

> I really like this idea, thank you!  I will accept directory names

Thanks. :-)

> matching the regexp /^$package(-.*)?$/ - does that seem reasonable?

Yep, though I might change the * to a +.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.