Re: non-DD contributors and the debian keyring

[Jamin W. Collins]

On Tue, Aug 26, 2003 at 10:36:07AM +1000, Glenn McGrath wrote:
> 
> If there was a keyring where peoples keys would only be accepted if it
> were signed by someone in the developer keyring, then it would
> 
> 1) Extend debians web of trust.
> 
> 2) Debian would be taking more responsability for itself.
> 
> 3) Debian would be supporting non DD who are contributing to the the
> project.
> 
> 4) Create a staging area for future DD's keys, where they can get somee
> experience managing their key.
> 
> What are the reasons not to do it (keeping in mind my point 2) ?

Items 1-3 are already addressed with DD signatures on other individuals
keys on public key servers.  Item 4 can be addressed with public key
servers too.  

I'm not against Debian having another key ring, I simply don't see a
specific need for one, although Goswin did bring up some good points.

-- 
Jamin W. Collins

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

Re: ViewCVS perpetually busted with Subversion repositories

[Takuo KITAME]

> Thank you, but I'm afraid I don't have the time to maintain my own fork
> of ViewCVS.

> In my opinion:
> * Debian's ViewCVS package should be hijacked, or the maintainer
>   should get more serious about dealing with the problems his
>   packaging of a CVS snapshot causes;
> * A new upload should be made to unstable, adding an epoch and
>   reverting to the last version sanctioned by the upstream
>   developers; this way we won't release a snapshot in sarge
> * A viewcvs(-snapshot?) package can be maintained in Debian
>   experimental if anyone has the patience to deal with it
> * The package's debconfage needs to be fixed or removed:
>   1) removed, if ViewCVS has a directory browser that can choose
>  between repositories (i.e., if ViewCVS can look at
>  /var/lib/cvs and/or /var/lib/svn when they don't directly
>  ccontain repos, the debconfage can be nuked entirely)
>   2) fixed; scan /var/lib/{cvs,svn} at configuration time and
>  use the first repository found as the default_root by
>  default (letting the user change it if we're in an
>  interactive frontend, of course)
> * The viewcvs CGI script needs to run with its umask set to 0002
>   so it doesn't fuck up Subversion repositories.  I've attached
>   a patch for this.

Sorry, I'm currently working on new viewcvs package.
But I'm waiting for subversion_0.27-0.1 package for i386 to build and
test.
 
Thanks.
-- 
Takuo KITAME.

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Anthony Towns]

On Mon, Aug 25, 2003 at 03:15:25PM +0200, Christian Perrier wrote:
> Quoting Anthony Towns (aj@azure.humbug.org.au):
> > It's the NMUer's responsibility to fix these bugs too.
> 
> > (One possible way of handling this, might be to have translation people
> > support each other by having random non-coders do the l10n NMUs and
> > having a couple of bad-ass hax0rs on hand to leap to their aid should
> > they trigger some unexpected serious breakage.)
> 
> Though this is not formalized, I'm very confident that if this happens
> some day, I would without any problem find someone for helping in
> either debian-devel-french (asking there first because this would be
> easier for mutual comprehension)of here (and using the "help"
> tag on a RC bug I would raise myself for "not building from sources").

Tagging the bug help is a good idea, but if it doesn't work the
responsibility is *still* the NMUer's to find some way that does. Not
the community's, not the list's, not the release manager's: the NMUer's.

Don't stress too much over the mechanics in extreme cases -- we can
work that out when or if they ever happen. Just make sure you've got
the mindset right when the usual cases appear.

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


pgp7U83vSGVQ3.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Anthony Towns]

On Mon, Aug 25, 2003 at 04:58:31PM +0300, Richard Braakman wrote:
> On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> > Just about everyone else appears to feel all they should care about is
> > the changes they make in their NMU instead of actually caring about the
> > package and the distribution.  There's this feeling of "not my problem".
> You are berating people who are working to improve the distribution
> because they're not doing as much volunteer work as you think they
> should be doing.  That's rude.

Or, alternatively, he's working to mitigate a real, forseeable risk of
a new process we'd like to adopt, that we don't have a huge amount of
recent experience with, in as forthright a manner as he's able. This is
a perfectly reasonable and professional attitude.

Take it easy.

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


pgpS1bfkttYuo.pgp
Description: PGP signature

Bug#206187: apt-get update fails to get index package list and therefore does nothing

[Sasha Volkoff]

OK, here is a complete transcription of a session, where I ran "perl -w -e 
""" before and after "apt-get upgrade":

mafalda:~# perl -w -e ""
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "es_ES",
LC_MESSAGES = "spanish",
LANG = "spanish"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
mafalda:~# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
66 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Need to get 0B/25.1MB of archives. After unpacking 535kB will be used.
Do you want to continue? [Y/n] y
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "es_ES",
LC_MESSAGES = "spanish",
LANG = "spanish"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Can't ignore signal CHLD, forcing to default.
Preconfiguring packages ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "es_ES",
LC_MESSAGES = "spanish",
LANG = "spanish"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
E: Sub-process /usr/bin/dpkg received a segmentation fault.
mafalda:~# perl -w -e ""
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "es_ES",
LC_MESSAGES = "spanish",
LANG = "spanish"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
All this was ran in the same remote session through SSH using putty in a 
Windows 2000 client.

Thanks.
Regards, Sasha
There was no line like "Can't ignore signal CHLD, forcing to default"?  I
see it happen below when perl is invoked; I would expect it to be here as
well.  did you run perl in the same shell where you ran apt, or a different
one?  If so, what was the difference?
--
 - mdz
**
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://sextocontinente.org
Humanizar la Tierra!
**

Re: User Based Init

[Russell Coker]

On Tue, 26 Aug 2003 10:00, Jerry Haltom wrote:
> I'm curious how many "wtf are you thinking?" reactions can be gathered
> for the idea of a per-user init.d system?

Actually I think that the @reboot option for cron should be extended.

There are many situations in which you may want to run per-user scripts, some 
examples I can think of include:
APM events
eth0 events (IE PCMCIA insertion/removal or DHCP lease negotiation)
libc6 upgrade
Arbitary other things as determined by the administrator.

I think that we could have cron support @whatever type events, and then when a 
system program writes "whatever" to a named pipe that cron maintains it could 
launch the appropriate jobs.

Of course hacking your own scripts to do the same things via sudo is quite 
possible.  However cron has some advantages.  Cron already supports mailing 
the output (and doing it in a secure fashion).  Cron supports properly 
changing the security context (and can easily support doing whatever is 
necessary for SE Linux and other systems which is better than multiple 
patches for multiple applications).  This also allows the user to edit one 
file to control everything.

-- 
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: stack protection

[Russell Coker]

On Tue, 26 Aug 2003 00:26, Milan P. Stanic wrote:
> [ OK, I'm going to think that we never will have secure system because
> absolute security is against nature. ]

True, so let's just get what we can.

> > Why?  I've used OpenWall and PaX and not found any programs that fail to
> > work correctly with them.
>
> I'm sure You know how easy to write one. If I and You don't know for
> such program, that doesn't mean that there isn't some in the wild.

Which is why there are methods of configuring programs to not have OpenWall 
and PaX apply to them.  So if you suddenly have to support a program that 
does not work with your stack protection scheme then you just flip a bit in 
the ELF header and it'll work fine!

The only problem you might have is users on a multi-user system putting their 
own binaries in their home directories, having such a problem and not knowing 
how to solve it.  However this will be much less common than the following 
problems:

User installs binary in their home directory and it breaks when you upgrade 
shared objects in a system upgrade.

User installs binary that relies on certain data files being in fixed 
locations and breaks when you upgrade to the latest FHS.

User installs binary that has their UID, home directory, or other data 
hard-coded.  When you migrate users to a new system and change these their 
program breaks.

I've seen all of these in production environments.  But I've never seen a 
program not work with OpenWall and default settings.  I conclude that for the 
majority of real administrators those issues will cause more problems and 
effort than OpenWall or PaX.

-- 
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: where to install additional kernel modules?

[Manoj Srivastava]

On Mon, 25 Aug 2003 21:51:57 +0200, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2003.08.25.1652
> +0200]:
>> If there is a single sane approach,

> Well, what's the single sane approach then? So far I've heard four,
> and they are all possible.

A) I said "if".

 B)
> also sprach David Schleef <[EMAIL PROTECTED]> [2003.08.25.0330 +0200]:
>> In reality, it doesn't matter what directory you put modules in,
>> since they all share the same namespace.  You can't have two module
>> files called module_x.o and expect it to work.  Users, however,
>> appreciate the separation.

So /lib/modules/$kvers/$package/ is as good as anything we
 have seen. It is not as it any single machine is likely to have
 hundreds of third party modules to so clutter up /lib/modules/$kvers/
 that finer grained subdirs would be required.

manoj
-- 
The sun never sets on those who ride into it. RKO
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: Your details

[Daily Pennsylvanian Webmaster]

>This is a multipart message in MIME format
>
>--_NextPart_000_05CF6427
>Content-Type: text/plain;
>   charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>Please see the attached file for details.
>--_NextPart_000_05CF6427
>Content-Type: application/octet-stream;
>   name="details.pif"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment;
>   filename="details.pif"
>
>TVqQAAME//8AALgAQA
AA
>4A4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG
1v
>ZGUuDQ0KJADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8
Em
>nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnABQRQ
AA
>TAEEAF2zPz8AAOAADwELAQYAAABw1usBAAAQYAEAAABQAA
AA
>AgAABAAEAgAAEAAAF/EBAAIAABAAABAAEAAAEB
AA
>AOLrAQCcfuwBAAgAAA
AA
>AA
AA
>AAAgAC5zaHJpbmsAAFABAAAQxBAAAEAAAM
Au
>c2hyaW5rAAAwYAEAABIAAADUAABAAADALnNocmluawAAQJABAA
AS
>5gAAQAAAwC5zaHJpbmsAADDQAQAAIgAAAPgAAA
AA
>AEAAAM
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA
>AA
AA

Your message could not be delivered to [EMAIL PROTECTED] 
because the message seemed to contain an attachment or enclosure. We use 
this method to help block spam from this account. Please remove the 
attachment from your message or make sure you are sending it as plain text 
and try again.

For more information, please contact the e-mail administrator at:
 
[EMAIL PROTECTED]

Re: Snort: Mass Bug Closing

[Colin Watson]

On Tue, Aug 26, 2003 at 12:46:45AM +0200, Sander Smeenk wrote:
> Quoting Drew Scott Daniels ([EMAIL PROTECTED]):
> > Imho it's ok to close non-rc bugs on stable (main Debian developers do).
> > My rational is that we only fix RC bugs on stable.
> 
> It also has an 'archival' kind of function where people can see what's
> wrong with a package if they experience weirdness. The thing is that the
> stable snort package is nothing but weirdness, and I can't fix it, but I
> do have this huge pile of bugs on my sheet that i'd like to rid of cause
> it really interferes with bug handling the unstable packages.

If they're being repeatedly reported, you can tag them woody and then
add '&exclude=woody' to the URL you use to view your bugs. Would that
help?

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: User Based Init

[Sam Hocevar]

On Mon, Aug 25, 2003, Jerry Haltom wrote:

> [per-user init scripts]
>
> (yes I realize fetchmail could be started from cron, which notably also
> has a similar per user idea)

   And it also has a similar "at startup" idea, see crontab(5).

-- 
Sam.

Re: User Based Init

[Colin Watson]

On Mon, Aug 25, 2003 at 07:00:03PM -0500, Jerry Haltom wrote:
> I'm curious how many "wtf are you thinking?" reactions can be gathered
> for the idea of a per-user init.d system?
> 
> I see this need a bit, for users who do development with various
> services, but admin's not wanting to give them root for one reason or
> another. Such as, apache or other web servers. Fetchmail?
> 
> (yes I realize fetchmail could be started from cron, which notably also
> has a similar per user idea)
> 
> /var/lib/user-init/${uid}/init.d
> /var/lib/user-init/%{uid}/rc${runlevel}.d
> 
> Would be started from /etc/init.d/user-init. Script would run in each
> runlevel and run each user's various scripts just like a normal init
> sequence, except chuid'd.

How about using @reboot lines in users' crontabs instead?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Colin Watson]

On Tue, Aug 26, 2003 at 12:18:54AM +0200, Goswin von Brederlow wrote:
> Mark Howard <[EMAIL PROTECTED]> writes:
> > BTS Support for tracking when bugs were changed
> > - AFAIK, already been worked on
> > This will be more important when there are a large number of
> > users/testers using different distributions - sid and experimental. 
> 
> changed? The time since the last message was send to that bug?
> patch for debbugs in BTS. (see rfc822 feature)

That's a *completely* separate issue from anything to do with
experimental, and isn't what Mark's talking about.

HTH,

-- 
Colin Watson  [EMAIL PROTECTED]

Bits from the RM

[Neil Roeth]

On Aug 19, Anthony Towns (aj@azure.humbug.org.au) wrote:
 >  * September 15th
 >  Last major changes to major packages uploaded to unstable
 >  * October 1st
 >  1st test cycle, public request for comments
 >  Last minute fixes and changes to the installer
 >  * October 15th
 >  Final, last minute, low-risk bug fixes only

I have a few packages for which a new upstream release appears imminent (minor
version change, not major).  The packages all have optional priority.

Is there a date after which package changes of this magnitude will be
rejected?

They are not major packages, so September 15 does not apply.  A new upstream
release hardly guarantees there will be only final, last minute, low risk bug
fixes required, so it would need to be uploaded well before October 15.  If
there is no set date, then I will just make sure they meet the relevant
criteria by October 15.

-- 
Neil Roeth

Re: User Based Init

[Jerry Haltom]

Oh. :D

My bad. :D

That definatly counts as a "wtf are you thinking!"

Thanks!

On Mon, 2003-08-25 at 19:33, Sam Hocevar wrote:
> On Mon, Aug 25, 2003, Jerry Haltom wrote:
> 
> > [per-user init scripts]
> >
> > (yes I realize fetchmail could be started from cron, which notably also
> > has a similar per user idea)
> 
>And it also has a similar "at startup" idea, see crontab(5).

Re: Updating packages' l10n without risk (~unrelated to previous)

[Andrew Suffield]

On Mon, Aug 25, 2003 at 10:27:44PM +0200, Martin Quinson wrote:
> On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> > On Fri, 22 Aug 2003, Christian Perrier wrote:
> > 
> > > And, as Steve pointed out, translation stuff is minimalistically
> > > invasive so this does not require an enormous amount of attention
> > > after the NMU.
> > 
> > Yes, but there are new libraries that get linked to, new compilers, etc.
> 
> It should be possible to get the source, rebuild to needed mo files
> (containing the translation in a compiled form), unpack the binary package,
> add the mo file and repack the binary package, shoudn't it ?

It might be better to ask why we are shipping translations in the
package at all, and figure out how to make it work with them split
out. Our current infrastructure can't handle it, but it's probably
possible to figure out something which can.

I don't have an interest in doing this, but somebody might.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


pgpcDNL1Y6nTf.pgp
Description: PGP signature

Re: non-DD contributors and the debian keyring

[Glenn McGrath]

On Mon, 25 Aug 2003 12:03:43 -0600
"Jamin W. Collins" <[EMAIL PROTECTED]> wrote:

> What is the goal?  To indicate that the e-mail signed came from
> someone in possession of person X's private key.  X's public key can
> be put up on existing public key servers.  There are already numerous
> public key servers functioning and no need for keyring.debian.org to
> be another.

If there was a keyring where peoples keys would only be accepted if it
were signed by someone in the developer keyring, then it would

1) Extend debians web of trust.

2) Debian would be taking more responsability for itself.

3) Debian would be supporting non DD who are contributing to the the
project.

4) Create a staging area for future DD's keys, where they can get somee
experience managing their key.

What are the reasons not to do it (keeping in mind my point 2) ?




Glenn

Re: 0 RC bugs == releasable quality?

[Richard Braakman]

On Mon, Aug 25, 2003 at 08:22:34PM +0100, Mark Howard wrote:
> I know the default answer is that it's the package maintainer's decision
> - but I don't know what to decide!

I suggest you go with gut feeling :)

Imagine a year from now.  You're at a geekly convention.  Someone
walks up to you and says, "Hey, you're Mark Howard!  I've been using
your package in stable, and..."

At this point, do you go "Uh-oh"?  Does your gut start churning?
Sweaty palms?  Fight-or-flight response? 

Then it's best not to release the package.

If, on the other hand, you lean back in preparation for the accolades
and gratitude that you expect will follow, and you're already trying
to decide what kind of beer to accept, then your package is probably
ready for stable.

Richard Braakman

Re: Snort: Mass Bug Closing

[Sander Smeenk]

Quoting Drew Scott Daniels ([EMAIL PROTECTED]):

> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 and bug 189267
> say:
>   DSA 297 closes these bugs. It may be worth noting that potato was not
>   affected.
> What other security issues are there?

Let's first start by telling that my backported packages never made it
to security updates that every good stable user should have in their apt
sources. The DSA just pointed users who actually read it to my p.d.o.
site.

There was a total of 3 advisories against snort. Two of them related to
RPC, another to reconstructing fragmented packets IIRC(!).

> Imho it's ok to close non-rc bugs on stable (main Debian developers do).
> My rational is that we only fix RC bugs on stable.

It also has an 'archival' kind of function where people can see what's
wrong with a package if they experience weirdness. The thing is that the
stable snort package is nothing but weirdness, and I can't fix it, but I
do have this huge pile of bugs on my sheet that i'd like to rid of cause
it really interferes with bug handling the unstable packages.

> 95153 may not even be applicable to snort in stable but should be RC.
[ .. ]
> 158040 doesn't have your automated message. It means that snort is
> unusable. This is likely the problem that was mentioned to you about your
> backport. Merge 16, 176223 with it (also no automated message)? Is
> this an upgrade problem?

The first automated message thing only went to submitters of critical,
grave, important etc. bugs. 158040 is indeed similar to what Joy
'discovered' in my backported packages: a slip of the fingers of the
maintainer who forgot to change the 'factory default' configuration file
to point to the debian rule-path. It's not an upgrade problem, as long
as I don't forget to set the path correctly, which most of the times I
am quite capable of remembering ;)

> 161659 talks about how a new config file doesn't get generated on even a
> fresh install. Perhaps this is the issue in 158040 et al?

No. The old stable package was incapable of filling in the debconf
generated 'snort.debian.conf' that is sourced to start snort later on.
This was one of the first problems I fixed when I took over the package.
It has nothing to do with 158040.

> 165107 suggests that the config file/rule file problem is in sid sarge and
> woody? Tagging this correctly may help the testing script...

This is (was) an upgrading problem. Because of the move of rule files
from /etc/snort to /etc/snort/rules/. And I forgot to move some files in
the postinst. Something like that. It has been fixed in later versions.

> 135603 is an upgrade problem... rules are incompatible. Is this a stable
> to stable upgrade?

It's not a real upgrade problem. It's that someone has a combination of
Debian releases in his aptsources, and both have versions of the snort
packages, and snort did not depend on a specific version of the rule
files, so apt thinks 'ah! snort-rules-default! already got that! no need
to upgrade!' or something like that.

> 170580 looks like a problem with the debconf script. A simple, obvious
> workaround is mentioned. This sounds like an upgrade problem.

What exacly do you mean with 'upgrade problem' ?  The debconf scripts
(or templates, iirc) in that release of the package were broken for some
reason.

> 165135 is a policy violation, which versions are affected? Reported well
> after woody was released... A quick check of the source code could reveal
> the answer.

It is a policy violation. Leftover, I guess. Stable doesn't have
invoke-rc.d, I discovered that when I built and 'tested' the backported
packages.

> I don't know if you should close the upgrade bugs as I've heard the
> argument "users should only be using stable releases of packages" and I
> don't know about snort in potato (is it there? does it upgrade
> correctly?).

I haven't tried upgrading from 1.8.4 to any of my backported packages
myself. Upgrading should go quite pain free, the only annoyance would be
dpkg asking to overwrite each seperate rule file, as Joy also mentioned. 
I don't know what I can do about that, other dan grossly violating the
policies to fix it.

> I'm getting a bit frustrated going through these myself. It seems that
> there's a lot of duplication, and (without testing) it looks like many of
> these bugs are still in sid.

Ehm. Some of them are, but not the ones I mentioned in my original post.
They are all fixed in the current backported release available at p.d.o.

> If you would like help going through these bugs, tagging them correctly,
> merging them, closing some, etc. I'd be happy to look even closer.

Snort has a spot on alioth since a while and is now being co-maintained
by Pascal Hakim (pasc@). The buildtrees for both the backported packages
aswell as the unstable packages are in cvs.

Any help is welcome. I just want to have a clean sheet and get a bit of
overview of real problems that exist with snort. Like the BUS errors on
sparc, for which work

Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)

[Sander Smeenk]

Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]):
> > Thus, it can't detect potentially harmful traffic.
> That's not correct, it cannot detected _new_ potentially harmful traffic. 
> There's quite a lot of potentially harmful traffic (stable) snort can
> detect. The fact that it's not up-to-date does not mean that it's useless,
> it means that it won't detect new attacks (but it will detect old attacks).
> Depending on your security policy that might, or might not, be enough.

If you don't care that much about security, snort isn't the right tool
anyhow. Snort starts raising hell when a large ping packet comes across
your interface, someone with such a low security interrest as you
described would go nuts with snort. But, that aside, cause it's not what
this is all about ;)

> Really, the way to fix this package X needs data Y to be up-to-date is to:
> a) separate data from the package (Nessus plugins are available in the 
> 'nessus-plugins' package and can be updated separately, for example)

snort has that. snort-rules-default is the default set of rules found on
snort.org for the release that is in debian, almost always updated when a 
new debian-release of the package is done. People can start packaging
their own rulesets, maybe even local rulesets or something.

> b) provide some way to retrieve new data (signatures, attacks, whatever)
> either: downloading them from the main site directly (as
> nessus-update-plugins does) or providing backported packages (and have them
> included in stable revisiones.

This problem only exists for snort packages that aren't going to be
updated, like the ones that reach stable. The unstable package is up to
date enough to have all correct rules, imho.

The other thing is, snort.org's people quickly start to drop old rule
formats when newer formats are used.  Should I be the one that has to
convert every rule back to the old format to have stable users of snort
safe and sound? It'll take alot of time. And I believe it is not always
scriptable.

So, although it sounds nice to have scripts to update rulefiles, I don't
really see it happening, because of the problems amentioned above.

> c) have a way to determine properly when new data needs a new engine and 
> won't work with older versions and warn the user about it. This means that 
> the engine needs to be programmed beforehand to understand a given dataset 
> version and complain when the dataset is of a newer (and potentially 
> worthless) version.

Well. Snort just fails to start if it can't parse the rule files. And
usually that is with every major upstream release. :(

Sander.
-- 
| Ik zit met een dilemma en ik heb geen flauw idee wat ik ermee moet doen
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

Re: Bits from the RM

[Adam Heath]

On Fri, 22 Aug 2003, GOTO Masanori wrote:

> It was reported by joshk on IRC, but I'm not still clear where this
> problem come from.  Example:
>
>   ultra30:~> dpkg -s libc6 | grep Version
>   Version: 2.3.2-3
>   ultra30:~> dpkg -s dpkg | grep Version
>   Version: 1.10.10
>   ultra30:~> dpkg
>   Bus error
>
> dpkg works well with some options, but only typing `dpkg' breaks with
> bus error.  It's not related with the existence of libc6-sparc64.
> From tracking with gdb, dpkg breaks setjmp()/longjmp().  The
> mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3
> without -O2 optimization.  It's also ok with glibc 2.3.1-17, IIRC.

Hmm.  I'm reminded of a problem on s390x.  64-bit arch, but when dpkg was
initializing some variable, it only did it to the lower(or upper, can't
recall) 32 bits.  Later, it blew up.

It's too bad valgrind doesn't work on non-i386.

Is there a debian machine I can access that has this problem?  The last 2
times some odd issue came up like this, one turned out to be a dpkg
bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at
the end of the buffer, when using mmap, on alpha).  In both cases, it didn't
take me long to track down(not more than half a day).

User Based Init

[Jerry Haltom]

I'm curious how many "wtf are you thinking?" reactions can be gathered
for the idea of a per-user init.d system?

I see this need a bit, for users who do development with various
services, but admin's not wanting to give them root for one reason or
another. Such as, apache or other web servers. Fetchmail?

(yes I realize fetchmail could be started from cron, which notably also
has a similar per user idea)

/var/lib/user-init/${uid}/init.d
/var/lib/user-init/%{uid}/rc${runlevel}.d

Would be started from /etc/init.d/user-init. Script would run in each
runlevel and run each user's various scripts just like a normal init
sequence, except chuid'd.

So, how insane am I?

This entire idea would consist of essentially one file and a empty
directory. :D

Jerry Haltom
Feedback Plus, Inc.

Re: 0 RC bugs == releasable quality?

[Josselin Mouette]

Le lun 25/08/2003 à 21:22, Mark Howard a écrit :
> Should we have another measure for when packages are releasable in
> addition to RC bugs. For example, does having >100 minor bugs means that a
> package is unsuitable for stable?
> I know the default answer is that it's the package maintainer's decision
> - but I don't know what to decide! Also, saying <200 non-RC bugs might
> be a useful QA metric.

That doesn't mean much. A small package may have large usability
problems with 2 or 3 normal bugs, while 200 bugs in XFree won't make it
unsuitable for stable. I guess that's why it's up to the maintainer.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)

[Javier Fernández-Sanguino Peña]

On Tue, Aug 26, 2003 at 12:24:11AM +0200, Sander Smeenk wrote:
> > Really, the way to fix this package X needs data Y to be up-to-date is to:
> > a) separate data from the package (Nessus plugins are available in the 
> > 'nessus-plugins' package and can be updated separately, for example)
> 
> snort has that. snort-rules-default is the default set of rules found on
> snort.org for the release that is in debian, almost always updated when a 
> new debian-release of the package is done. People can start packaging
> their own rulesets, maybe even local rulesets or something.

Sure, I'm not saying that snort does not have it. I'm just saying that 
maybe you should consider upgrading the one in stable. The differences in 
format are known and you should be able to find a way to convert older 
rules set. 

> 
> > b) provide some way to retrieve new data (signatures, attacks, whatever)
> > either: downloading them from the main site directly (as
> > nessus-update-plugins does) or providing backported packages (and have them
> > included in stable revisiones.
> 
> This problem only exists for snort packages that aren't going to be
> updated, like the ones that reach stable. The unstable package is up to
> date enough to have all correct rules, imho.

You can convince the stable release manager to put a new 
snort-rules-default package into sarge, for example, 6 months after it is 
released. It's easier to do that than to try to push a new upstream version 
into sarge, and you will be providing the new rules users might want.

In any case, I was thinking on the lines of a separate (not packaged) 
method to download rules directly from snort.org. Please take a look at the 
'nessus-update-plugins' to see what I mean.

> The other thing is, snort.org's people quickly start to drop old rule
> formats when newer formats are used.  Should I be the one that has to
> convert every rule back to the old format to have stable users of snort
> safe and sound? It'll take alot of time. And I believe it is not always
> scriptable.

You are, after all, the snort package maintainer. If you don't want to do 
this you can try to find people who might volunteer to do the work for 
stable and provide a new snort-rules-default package for stable maybe 
converting some of the new rules which are no longer valid. Granted, some 
information might be lost in the conversion and some rules might not be 
converted, but still, better than no updates.

> So, although it sounds nice to have scripts to update rulefiles, I don't
> really see it happening, because of the problems amentioned above.

If no one works to see that happen it will never be.

> 
> > c) have a way to determine properly when new data needs a new engine and 
> > won't work with older versions and warn the user about it. This means that 
> > the engine needs to be programmed beforehand to understand a given dataset 
> > version and complain when the dataset is of a newer (and potentially 
> > worthless) version.
> 
> Well. Snort just fails to start if it can't parse the rule files. And
> usually that is with every major upstream release. :(

[Short version: see the patch below.]

[Long version: follows]
That's obviously, suboptimal, snort should be able to determine in some way
from a rules file if the format is a version it knows or it isn't. C'mon
version headers are not unheard of, just take a look at the header of any
HTML file in www.debian.org, it will tell you precisely which DTD to use to
be able to "understand" it. 

It wouldn't be so difficult [1] to have snort analyse the rules file before
including and determine if its rules can, or cannot, be added. Of course,
that would be mean improving the way rules files are parsed currently.

There is currently no distinction between snort's configuration and the
rules files themselves (pv.config_file in snort.c) but if they were
separated the ParseRulesFile in snort's parser.c could be rewritten to
verify the call to ParseRule and not proceed if there is an indication that
the rules belong to a new version. 

The adjointed patch (probably very ugly, untested and maybe broken) 
provides that functionality. If the snort parser encounters a place of the 
file which has 'version X' with X > SNORT_MAJOR_VERSION then it will not go 
on reading the rest of the rules file. That way you can have rules in one 
file which are read by older snort versions and rules that cannot (maybe 
because the Parser has been enhanced to included new formats).

Regards

Javi
--- parser.c.old2003-08-26 01:04:50.0 +0200
+++ parser.c2003-08-26 01:20:40.0 +0200
@@ -55,6 +55,8 @@
 #include "threshold.h"
 
 #include "snort.h"
+#define SNORT_MAJOR_VERSION 2
+/* SNORT_VERSION should probably be defined in the snort generic headers */
 
 ListHead Alert; /* Alert Block Header */
 ListHead Log;   /* Log Block Header */
@@ -128,6 +130,7 @@
 int stored_file_line = file_line;
 char *saved_line = NULL;
 int co

Re: A possible GFDL compromise

[Andrew Suffield]

On Mon, Aug 25, 2003 at 11:33:28PM +0900, Fedor Zuev wrote:
> On Sun, 24 Aug 2003, Nathanael Nerode wrote:
> 
> >Fedor Zuev, missing the point AGAIN, said:
> >>I cannot see any connection between disagreement with anyone
> >>opinion, and the right to censor somebody else's opinion, so
> >>angrily demanded by you.
> 
> >There's no censorship involved. *sigh* The GNU Manifesto would
> >still be freely available from the FSF website.
> 
> >Lack of forced distribution is not "censorship".  Get a clue, or a
> >dictionary.
> 
>   Heh.
> 
>   "Why that ugly, non-free GPL license demand from me to
> distribute source code? Source would still be freely available from
> the FSF website! Lack of forced distribution do not harm a
> freedom!" Agree?

What the fuck has that got to do with censorship?

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


pgpBi94VlxeoB.pgp
Description: PGP signature

Re: Building kernel modules for stock kernels is a hell of a job!

[Manoj Srivastava]

On Mon, 25 Aug 2003 20:26:29 +0200, horrorvacui  <[EMAIL PROTECTED]> said: 

> On Sun, 24 Aug 2003 19:50:18 -0500
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:

>> On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui
>> <[EMAIL PROTECTED]> said:
>>
>> > This is my view: the kernel headers and the configuration used
>> > when compiling a stock kernel are to be viewed as an *integral
>> > part of that kernel*. The headers should be installed by default,
>>
>> Heh. You are describing how things used to be, with the
>> kernel-headers always installed by kerel-image, and the symlink
>> kept in place. Looking at the CVS, you could have any number of
>> headers or sources in place, and the /usr/src/linux symlink was
>> kept pointing to the latest version, as determined by the most
>> recent kernel-image isntalled.

> Yes. The symlink is more or less unnecessary topping, but this is
> how it should be.

Unfortunately, several people disagree with that conclusion.

>>
>> Of course, it all used to fall apart for user who had multiple
>> kernels installed, and woh used to swithc in between, people who
>> had limited amount of space in /usr, and people who wanted to
>> compile for a different machine than the current one.

> Of course, but aren't those people (except for those with limited
> space) usually the ones that can cope with that? If you're
> knowledgeable enough to use multiple kernels, it can be assumed that
> you can be burdened with the responsibility of having /usr/src/linux
> pointed at the right direction, depending on the currently running
> kernel. I'm no newbie, mind you - I've been compiling my kernels,
> installing modules and making it all work together for years, yet
> getting the headers/source was too cryptic for me. Remember that
> most unexperienced users won't even know that they need a kernel in
> the source form, or the headers, nor will they understand why.

There are two constituencies here. One set wants to just have
 the minimal install, and another wants both headers and the kernel
 image. The obvious solution is to give people a choice, which is what
 we do now. 

The headers and sources are provided by debian in precisely
 the same place that the kernel images are.Any one who chooses to have
 headers installed can get them from the same place they got the
 image, and all the package management tools are there to help them do
 so. 

> I don't see how the flexibility might benefit from this (except for
> reducing the size of kernel packages). After all, if the situation
> still were as you described above, deleting a directory and a
> symlink would be all you needed to do to make it as it is
> currently. The other way around it's much more difficult, and if
> it's only about finding out what you need to do.

Difficult?

__> apt-cache search kernel-image-2.4.21 | grep ^kernel
kernel-image-2.4.21-4-386 - Linux kernel image for version 2.4.21 on 386.
kernel-image-2.4.21-4-586tsc - Linux kernel image for version 2.4.21 on 
Pentium-Classic.
kernel-image-2.4.21-4-686 - Linux kernel image for version 2.4.21 on 
PPro/Celeron/PII/PIII/PIV.
kernel-image-2.4.21-4-686-smp - Linux kernel image for version 2.4.21 on 
PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.4.21-4-k6 - Linux kernel image for version 2.4.21 on AMD 
K6/K6-II/K6-III.
kernel-image-2.4.21-4-k7 - Linux kernel image for version 2.4.21 on AMD K7.
kernel-image-2.4.21-4-k7-smp - Linux kernel image for version 2.4.21 on AMD K7 
SMP.
kernel-tree-2.4.21 - Linux kernel tree for building prepackaged Debian kernel 
images
kernel-image-2.4.21-dm - Linux kernel binary image for version 2.4.21-dm.
kernel-image-2.4.21 - Linux kernel binary image for version 2.4.21.
__> apt-cache search kernel-headers-2.4.21 | grep ^kernel
kernel-headers-2.4.21-4 - Header files related to Linux kernel version 2.4.21
kernel-headers-2.4.21-4-386 - Linux kernel headers 2.4.21 on 386
kernel-headers-2.4.21-4-586tsc - Linux kernel headers 2.4.21 on Pentium-Classic
kernel-headers-2.4.21-4-686 - Linux kernel headers 2.4.21 on 
PPro/Celeron/PII/PIII/PIV
kernel-headers-2.4.21-4-686-smp - Linux kernel headers 2.4.21 on 
PPro/Celeron/PII/PIII/PIV SMP
kernel-headers-2.4.21-4-k6 - Linux kernel headers 2.4.21 on AMD K6/K6-II/K6-III
kernel-headers-2.4.21-4-k7 - Linux kernel headers 2.4.21 on AMD K7
kernel-headers-2.4.21-4-k7-smp - Linux kernel headers 2.4.21 on AMD K7 SMP
kernel-headers-2.4.21-sparc - Kernel header files for all sparc sub 
architectures
__> apt-cache search kernel-source-2.4.21 | grep ^kernel
kernel-patch-debian-2.4.21 - Debian patches to Linux 2.4.21
kernel-source-2.4.21 - Linux kernel source for version 2.4.21 with Debian 
patches


I am not a proponent of reducing choices (and chosing not to
 have kernel headers installed is a choice) for the sake of dumbing
 down Debian so we get rank novices who probably have no business
 compiling modules in the first place -- if you cant figure out which
 kernel image goes with which hea

Re: A possible GFDL compromise

[Manoj Srivastava]

On Mon, 25 Aug 2003 23:33:28 +0900 (IRKST), Fedor Zuev <[EMAIL PROTECTED]> 
said: 


>   "Why that ugly, non-free GPL license demand from me to
> distribute source code? Source would still be freely available from
> the FSF website! Lack of forced distribution do not harm a freedom!"
> Agree?

If you do not like free software, you do not have to install
 Debian, or any other free software -- the world is full of MS Windows
 users and developers, and I am sure they shall welcome you into their
 ranks. 

manoj
-- 
Real computer scientists only write specs for languages that might run
on future hardware.  Nobody trusts them to write specs for anything
homo sapiens will ever be able to fit on a single planet.
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 Mon, Aug 25, 2003 at 03:15:07PM -0400, Stephen Frost wrote:
>
> I'm not against translations.

I did the same error than Sven when reading your first definitive statement.
Apologies again.

> Perhaps even have a system where
> translations can be done without NMU's and have a seperate system for
> them which would make it easier for maintainers and translators alike.
> 
> On the other hand, I have strong feelings about NMUs.

For sure. I'm happy that after 1452353532 mails, we are about to reach a
point on which we could both agree. :)

Be sure that the people NMUing for translation (ie, Christian) are not
feeling comfortable with this situation. We know that it's a risky game to
play, and that if something goes wrong, we will get the flames we deserve
here...

But even if I though really hard about that issue, I cannot see any solution
to dormant bugs in otherwise bug free packages.

I dream every day of a centralization system allowing the developer and
translators to work hand in hand and not more or less despite of each other
as the current system often implies. But I still miss some pieces of the
puzzle (conceptually) and do not have time to implement the others for now.

(BTW, #206363 waits for someone with (very) basic python abilities having
 one or two days free)

Until now, we did deal with this and waited for better days. But the RM
explicitly stated that the only solution to get a given point fixed before
sarge may be to NMU it in the next few weeks. With this new deal, we have to
play another game to fulfill our goals.

> NMUs should not be used to update packages of maintainers who are MIA.
> They should not be used as a blunt instrument.  If a maintainer is MIA
> then their packages should be orphaned to QA, hijacked, or removed.
> Blunt instruments should be avoided, they don't work all that well.

Well, I guess that Christian is able to put QA as maintainer for packages he
uploads for l10n bug in dormance since more than N months, but I've the
feeling that it would raise even more issues and flames than it solves...



But I should stop writting long mails to d-d, let you guys work on the RC
bugs and other issues implied by sarge release, and become more studious on
redacting this damn PhD thesis. I'll try from now. I promise. Don't worry,
I'll be back after sarge comes out. You guys won't get ride of me that
easily. And there is many of me. :)

Bye, Mt.

-- 
Finally it's Poland's turn to invade someone else's country.
We have to understand them, as they have been deprived from
that pleasure for such a long time.

Re: Objections to #156161?

[Thomas Hood]

tags 156161 wontfix
thanks

On Mon, 2003-08-25 at 17:43, Goswin von Brederlow wrote:
> The existence of starts scripts alone is sufficient to get the right
> behaviour:
> 
> old level | new level | affect
> --+---+
>   |   | no change (if it runs don't kill it)
> has start |   | stop service
>   | has start | start service
> has start | has start | no change (if it doesn't run, don't start it)

It doesn't actually suffice because the K symlinks also control
the order in which services are stopped.  But I get your point.
You have shown that one can put a service into "manually controlled"
mode simply by setting all its symlinks to K.  Then switching among
runlevels never starts or stops the service.  The presence of a K
symlink really signifies the disjunction: either the service is not
running or it was started manually. Implementing "manually controlled"
mode this way works fine until you do something (such as a package
restart on upgrade) that resets the service to the state corresponding
to the symlink.  If we had try-restart implemented everywhere then
we wouldn't need a third state (besides S and K) to inhibit
inappropriate restarts.  And even if we have the third state, we
still need try-restart in order to restart services that have been
started manually.  So you have convinced me that we don't need this
third state and invoke-rc.d doesn't need to be changed; we should
simply try to get try-restart implemented.

--
Thomas

Re: 0 RC bugs == releasable quality?

[Goswin von Brederlow]

Mark Howard <[EMAIL PROTECTED]> writes:

> My initial thoughts were that many minor bugs and wishlist items as well
> as a general unpolished feel should stop a package getting into stable.
> There are many reasons, however for including galeon. 
> 
> Should we have another measure for when packages are releasable in
> addition to RC bugs. For example, does having >100 minor bugs means that a
> package is unsuitable for stable?
> I know the default answer is that it's the package maintainer's decision
> - but I don't know what to decide! Also, saying <200 non-RC bugs might
> be a useful QA metric.

Have you counted bug on some packages? dpkg, glibc, xemacs, gnome, kde
come to mind.

Should we delay the release till dpkg2 is ready?

I don't think the criterium would be very usefull. Most packages are
small, they never get 100 bugs without getting a RC bug or (should be)
orphaned.

Others are huge complicated beasts and get tons of bugs no matter how
much work you put into ot how good they work.

If you feal a package has too many bugs you should offer
co-maintainership, find someone to co-maintainer, hijack the package
or get it orphaned/removed. Even adding a RC bugs "too many bugs, keep
out of testing" might be a good idea if testing has a reasonable
working version.

MfG
Goswin

Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Goswin von Brederlow]

Mark Howard <[EMAIL PROTECTED]> writes:

> BTS Support for tracking when bugs were changed
> - AFAIK, already been worked on
> This will be more important when there are a large number of
> users/testers using different distributions - sid and experimental. 

changed? The time since the last message was send to that bug?
patch for debbugs in BTS. (see rfc822 feature)

> Automatic builds
> - I want galeon to be built on all architectures automatically. 
> Having a simple email interface would be nice, but automatic for every
> upload would be better. The changes I'm proposing here would move
> packages from sid to experimental - they are automatically built
> for sid already, so this won't incurr much build time. 
> We would need more disk space than currently used - e.g. so that the
> exp.-gnome section could be built in a chroot with sid and exp.-gnome;
> exp-.gnome-woody could be built with woody and exp-gnome-woody.
> Obviously it would require some more processor time, but IMHO
> this is well worth it. 
> If buildd machines are falling behind, why don't we spend some of the
> money Debian has? Is there any real data as to which buildds are
> struggling?
> One other useful idea to reduce load would be to have some option on the
> buildds for don't attempt a rebuild (of any version) until bug x has
> been fixed.

You would have to provide different apt sources.list per build or make
a dedicated buildd per section. The later of cause is not feasable.

It shouldn't be to hard to have the normal sid chroot and add a line
for the experimental-whatever section on each build. The chroot would
have to be purged whenever the section is changed but that shouldn't
be too much of a strain.

Also you could add priorities to packages. wanna-build would choose
the highes priority first. Aging would raise the priority and packages
outside experimental get a big bonus. That way anything important (sid
) gets build first but expermintal packages won't starve eigther. For
archs that fall behind a package might skip several versions till it
gets build. Oh, skipping a version should raise the priority so
packages get build once in a while even if they do a daily release.

> In summary, changes like these would mean:
> - more people use experimental
> - sid has fewer experimental packages
>   + it is broken less often (perhaps the 'unstable' name should be
>   changed?)
>   + testing is kept recent more often
> - It would make it possible to have official support for things like
>   gnome backports

Where does that come from?

> - It may make it easier to experiment with things like having separate
>   server and desktop releases. (In terms of applying the separate
>   sections idea to the whole of Debian) 

I would like to have sections for stable/testing/unstable too. Many
users have testing but want the more uptodate desktops. Setting pins
for anything desktop related isn't easy. Setting a pin for
testing-desktops is trivial.

Also a core section would be nice for building/developing
boot-floppies and debian-installer. A local mirror of just core
packages could be setup in a minute. At the moment its a constant
struggle to keep the right set of files current.

> Does anybody have any additions for thses ideas, or any ideas for other
> changes to aid sarge+1 development?

A remark to the implementation of sections. We already had that before
pools remember, sort of, till it broke down.

Now, instead of having packages in different directories, we would
make subdirs with Packages/Sources files. Also the current full files
could be kept in its place (keeping everything old working) and
sectionized Packages files generated from the full files by filtering
for Sections. Alternatively the full files could be made by merging
the section files, doesn't realy matter.

Should be a small impact to the mirrors to add sections. Just the
buildd changes for experimental look like needing work.

MfG
Goswin

Re: Bits from the RM

[Sven Luther]

On Wed, Aug 20, 2003 at 08:11:55PM -0500, Branden Robinson wrote:
> 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.

Maybe you could split the debian-x list some, it would make reading it
easier. The signal to noise ratio has rather much degraded there these
last month, especially with all the control.bugs.debian processed mails
going to it.

Friendly,

Sven Luther

Re: where to install additional kernel modules?

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2003.08.25.1652 +0200]:
>   If there is a single sane approach,

Well, what's the single sane approach then? So far I've heard four,
and they are all possible.

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgpjjrbjHVg4r.pgp
Description: PGP signature

Re: Objections to #156161?

[Thomas Hood]

On Mon, 2003-08-25 at 16:24, Henrique de Moraes Holschuh wrote:
> It is up to the administrator to understand that this will break upgrades
> in weird ways if a service absolutely HAS to be restarted, since that
> restart will simply not happen.

Yes, restart will not happen if the current runlevel lacks rc
symlinks for the service.  (Currently the restart _will_ happen
if thre are no such symlinks.)

There are two kinds of services that may lack rc symlinks in the
current runlevel: (1) services that have an rc symlink in runlevel
S and (2) services that _don't_ have an rc symlink in runlevel S.

In case #1 one generally doesn't want the "service" to be restarted
anyway because it is an initscript that is meant to run only at boot
time.  It was to work around the current invoke-rc.d behavior that
a "--no-start" option was added to dh_installinit -- it keeps the
debhelper-created postinst from doing "invoke-rc.d foo start".
If in the future invoke-rc.d doesn't start services in runlevels
that lack start symlinks then the --no-start kludge won't be
necessary.  On the other hand, there will a problem with any
package that relies on the current behavior of invoke-rc.d to
run an initscript on install that is configured to run only in
runlevel S.  The solution for such a package would be to do
"invoke-rc.d --force foo start" in the postinst on non-upgrade.

In case #2 the maintainer or the admin is relying on behavior
that isn't currently defined.

>   There is no clean fix until we get all
> initcripts to properly support the new LSB-introduced (and many times
> requested within Debian)
(Yes, see #203239)
>  equivalent to "restart only if it is already
> running".  At that time, it is very simple to fix invoke-rc.d to be
> a bit more intelligent.

Yes, if initscripts supported try-restart then it could become
standard practice to do try-restart instead of restart on package
upgrade.  Upgrading a package shouldn't change the state of any
services (running versus stopped).

In the meantime, however, "invoke-rc.d foo restart" will still
restart all services that don't fall into one of the cases
described above, and of those above only a small number will be
adversely affected, and even then the worst that will happen is
that the service won't be restarted right away.

Nevertheless, this is something that should be implemented
post-sarge.
--
Thomas

0 RC bugs == releasable quality?

[Mark Howard]

Hi,
  I've started a discussion on debian-gtk-gnome (galeon not in Debian
stable) about not shipping a package because a stable upstream release
has not been made. There are no major problems with the package, just
minor issues and feature requests. There have been some interesting
responses to this - please take a look at them if you have time.

My initial thoughts were that many minor bugs and wishlist items as well
as a general unpolished feel should stop a package getting into stable.
There are many reasons, however for including galeon. 

Should we have another measure for when packages are releasable in
addition to RC bugs. For example, does having >100 minor bugs means that a
package is unsuitable for stable?
I know the default answer is that it's the package maintainer's decision
- but I don't know what to decide! Also, saying <200 non-RC bugs might
be a useful QA metric.

Please keep galeon specific replies to debian-gtk-gnome, generic replies
here.
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: non-DD contributors and the debian keyring

[Stephen Frost]

* Sven Luther ([EMAIL PROTECTED]) wrote:
> On Mon, Aug 25, 2003 at 12:03:43PM -0600, Jamin W. Collins wrote:
> > I've never indicated in any way that the Debian project doesn't need
> > translators.  Please reread my statements.
> 
> No, but stephen has hinted at such, and my original mail was addressed
> at him.

No, I didn't.  The constant claims that I'm against translations are
getting old, which increases my lack of interest in this thread.  I'll
try one last time here:

I'm not against translations.  I think it's very cool that people are
working on translations, I've incorporated every translation I've been
given, etc, etc.  I think we could use *more* translators and that if we
eventually got enough we could have more things trnaslated and have
better support for translations.  Perhaps even have a system where
translations can be done without NMU's and have a seperate system for
them which would make it easier for maintainers and translators alike.

On the other hand, I have strong feelings about NMUs.  NMUs should 
only be used when the official maintainer is away or unable to upload 
packages.  I do not feel it is appropriate to use them to add things 
to the package.  It requires a change to the source and a rebuild of 
the package.  People doing NMUs should be doing them for the purpose of
maintaining the package while the maintainer is unavailable, thus they
should assume the responsibilies of the maintainer for those packages
which they NMU until the maintainer has come back and done an upload.

NMUs should not be used to update packages of maintainers who are MIA.
They should not be used as a blunt instrument.  If a maintainer is MIA
then their packages should be orphaned to QA, hijacked, or removed.
Blunt instruments should be avoided, they don't work all that well.

Hopefully that's clearer.

Stephen


pgpRjkBBqgq5q.pgp
Description: PGP signature

Re: stack protection

[Don Armstrong]

On Mon, 25 Aug 2003, Milan P. Stanic wrote:
> So, I think I'm not slandering them or at least that isn't my
> intention. I apologize if I did.

Slander wasn't the correct word. It's just not a good idea to malign a
whole set of coders and programs without solid reasoning behind it.

>> As far as I can remember, the last exploit in dhcpd3-server happened
>> well over 2 years ago.
>
> Do you follow DSA?
>
> Debian Security Advisory DSA 231-1 [EMAIL PROTECTED]
> http://www.debian.org/security/ Martin Schulze
> January 17th, 2003  http://www.debian.org/security/faq

This exploit is in minires, not dhcp3-server itself. [minires is a
library used by dhcp3-server to provide NSUPDATE used in Dynamic DNS.]

It also was found during an internal audit by ISC itself...

> Debian Security Advisory DSA 245-1 [EMAIL PROTECTED]
> http://www.debian.org/security/ Martin Schulze
> January 28th, 2003  http://www.debian.org/security/faq

This is a DOS in dhcp3-relay, not in dhcp3-server itself.

> I'm using ISC's dhcp to. But this doesn't mean I must praise it and 
> I can't see bugs.

Heh. There are bugs in it, but many of them have been characterized,
and they are typically fixed fairly rapidly. I can only remember a few
really nasty ones, but you'd only run into them in rather strange
setups.[1]


Don Armstrong
1: Before the pool system got rewritten, the abandoned leases where
not reclaimed in the proper order [eg, oldest abandoned lease to
newest abandoned lease.] I only ran into it because I was operating on
a large network with pools at near capacity.
-- 
Of course Pacman didn't influence us as kids. If it did, we'd be
running around in darkened rooms, popping pills and listening to
repetitive music.

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


pgpOheK2BtqXU.pgp
Description: PGP signature

Re: Transition: new PAM config file handling in unstable

[Sam Hartman]

> "Joey" == Joey Hess <[EMAIL PROTECTED]> writes:

Joey> Steve Langasek wrote:
>> - It will now be possible to choose md5 vs. crypt passwords at
>> install time without violating policy.  (Currently, a number of
>> conffiles are being modified by maintainer scripts in order to
>> enable md5 passwords.)  Actually making this process
>> policy-compliant will require changes to a number of other
>> packages prior to release.

Joey> It's great to finally have this. Have you considered doing
Joey> something to ease upgrades of systems whose admins chose to
Joey> enable md5 passwords via passwd's debconf questions?

Unfortunately I have some bad news for you.

Karl (login maintainer) and I have decided that there will be no
question for sarge and that md5 passwords will be used by default.


Once there are tools for automated manipulation of the pam config
files, then it will be a configuration decision of libpam-modules what
the default passwd configuration for pam_unix is.

If debconf is available then the user will be asked; otherwise the
default will not be changed.

But I don't have time to review a design or to do the design myself
for sarge.

Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)

[Mark Howard]

Hello,
   I'm glad to hear so many people agreeing with the RM's plans and even
more glad to see so many things being done to make this seem plausible!

I'm one of those developers who has cvs and other unrealeasable packages
in sid. I agree with the comments about moving these to experimental,
keeping sid for just releases considered stable, but think changes need
to be made to experimental so that people do this by default and so sid
will be even more stable:

Split experimental into sections:
- I don't like having an experimental base system, but would like to try
  out the latest gnome desktop.
experimental-core - new major upstream releases of core packages
experimental-gnome - gnome 2.3, galeon2.3, epiphany...
experimental-kde
experimental-gnome-woody - backport of gnome2 to woody
experimental-all - includes all of the above (well, almost)
...
sid - candidates for future Debian stable. All considered stable
releases upstream.
Ideally, creating new sections should be as simple as sending a message
to the ftp-masters.

'Full' Distributions
Each section should be have full Packages and Release files including
packages from sid and that experimental section. Hopefully this would
encourage more people to use experimental all the time. Having more
people use experimental would make developers more willing to upload
things to experimental.

BTS Support for tracking when bugs were changed
- AFAIK, already been worked on
This will be more important when there are a large number of
users/testers using different distributions - sid and experimental. 

Automatic builds
- I want galeon to be built on all architectures automatically. 
Having a simple email interface would be nice, but automatic for every
upload would be better. The changes I'm proposing here would move
packages from sid to experimental - they are automatically built
for sid already, so this won't incurr much build time. 
We would need more disk space than currently used - e.g. so that the
exp.-gnome section could be built in a chroot with sid and exp.-gnome;
exp-.gnome-woody could be built with woody and exp-gnome-woody.
Obviously it would require some more processor time, but IMHO
this is well worth it. 
If buildd machines are falling behind, why don't we spend some of the
money Debian has? Is there any real data as to which buildds are
struggling?
One other useful idea to reduce load would be to have some option on the
buildds for don't attempt a rebuild (of any version) until bug x has
been fixed.

In summary, changes like these would mean:
- more people use experimental
- sid has fewer experimental packages
  + it is broken less often (perhaps the 'unstable' name should be
  changed?)
  + testing is kept recent more often
- It would make it possible to have official support for things like
  gnome backports
- It may make it easier to experiment with things like having separate
  server and desktop releases. (In terms of applying the separate
  sections idea to the whole of Debian) 
 
Does anybody have any additions for thses ideas, or any ideas for other
changes to aid sarge+1 development?

-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Updating packages' l10n without risk (~unrelated to previous)

[Martin Quinson]

On Mon, Aug 25, 2003 at 11:10:06AM -0500, Adam Heath wrote:
> On Fri, 22 Aug 2003, Christian Perrier wrote:
> 
> > And, as Steve pointed out, translation stuff is minimalistically
> > invasive so this does not require an enormous amount of attention
> > after the NMU.
> 
> Yes, but there are new libraries that get linked to, new compilers, etc.

It should be possible to get the source, rebuild to needed mo files
(containing the translation in a compiled form), unpack the binary package,
add the mo file and repack the binary package, shoudn't it ?

Of course, you have to bump the package number when doing so,

Of course, this is useless if the maintainer does not integrate the
translation since it has to be done each time.

Of course, this is only possible for the program translations, and not the
translation of material used by debconf (at least I'm less confident) or
others.


I do not plan to do so anytime soon (or later), I merely ask about
feasability.

Proper l10n in debian is a big puzzle, and I don't even know the pieces
yet :)


Thanks, Mt.

-- 
Finally it's Poland's turn to invade someone else's country.
We have to understand them, as they have been deprived from
that pleasure for such a long time.

Re: stack protection

[Milan P. Stanic]

On Mon, Aug 25, 2003 at 10:56:38AM -0700, Don Armstrong wrote:
> I'm personally only really familiar with ISC's dhcpd3-server, but have
> you even read the code written by Ted Lemon? Just randomly slandering
> programmers when you are not intimately familiar with their code isn't
> something that should be done lightly.

In my original post you could read: (You quote it, see bellow)
-
[ I don't like to offend  Paul Vixie or ISC programmers. They do good
job in the beginnings of the Internet and probably in these days they
didn't anticipate how hostile will become network for collaboration,
sharing ideas and knowledge, extending freedom ... ]
-
So, I think I'm not slandering them or at least that isn't my
intention. I apologize if I did.

> As far as I can remember, the last exploit in dhcpd3-server happened
> well over 2 years ago. While I've never heard of an exploit in udhcp,
> I'm relatively sure it's not as widely scrutinized as dhcpd3-server.
 
Do you follow DSA?
--
Debian Security Advisory DSA 231-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 17th, 2003  http://www.debian.org/security/faq

Debian Security Advisory DSA 245-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
January 28th, 2003  http://www.debian.org/security/faq
--

> > [ I don't like to offend Paul Vixie or ISC programmers. They do good
> > job in the beginnings of the Internet and probably in these days they
> > didn't anticipate how hostile will become network for collaboration,
> > sharing ideas and knowledge, extending freedom ... ]
> 
> Many of ISC's programs (bind, dhcp) current versions have been
> completely rewritten from scratch, or nearly from scratch. The people
> who wrote them are quite well aware of the current state of hostile
> networks.

AFAIK only bind is "rewritten", but Dan J. Bernstein explained how they
rewrote it. Some of the bugs were the same in version 8 (old code) and 9
(new "rewritten" code). ;-) Document could be found somewhere on DJB
site: http://cr.yp.to/
[ I don't like to refer to DJB, but can't remember anything better ]
 
> > [ BTW, a good measure for security is: don't use ISC software! :-) ]
> 
> In many cases, there isn't an alternative for ISC's software. I have
> yet to find a dhcp server that is as featureful and robust as ISC's
> dhcp server. If you're serving a network of 5 computers, udhcpd might
> work for you, but some people use debian to run dhcpd for networks of
> thousands of nodes with hundreds of subnets.

I'm using ISC's dhcp to. But this doesn't mean I must praise it and 
I can't see bugs.

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Mon, Aug 25, 2003 at 01:19:57PM +0100, Mark Brown wrote:
> On Mon, Aug 25, 2003 at 01:22:03PM +0200, Christian Perrier wrote:
> 
> > With the former (and still widely used) method for translating debconf
> 
> Is anyone maintaining statistics on how widely used the original Debconf
> scheme is?

Greping around in (I love grep-dctrl)
http://ftp-master.debian.org/~barbier/l10n/material/data/unstable.gz
(used to generate w.d.o/intl/l10n) 

shows me that there is 2122 strings using old debconf and
http://www.debian.org/intl/l10n/po-debconf/rank
says that there is 3421 strings using po-debconf.

I have no historic on that data; these are the files integrated in the
packages, not counting the opened bugs not yet integrated, neither the
switches underway and not yet submitted.

So, I guess that the transition will be achieved for sarge + 1, at least.

Earlier if the french team reachs its goal of completely translated package
install in sarge, since we only translate po-debconf files, and do (read
submit as patch) the switch if needed. ;)

Bye, Mt.

-- 
Never trust someone who only codes in CAML... because the way things are
done matters more to him than the result.

Re: non-DD contributors and the debian keyring

[Goswin von Brederlow]

"Jamin W. Collins" <[EMAIL PROTECTED]> writes:

> On Mon, Aug 25, 2003 at 07:16:31PM +0200, Sven Luther wrote:
> > On Mon, Aug 25, 2003 at 10:35:17AM -0600, Jamin W. Collins wrote:
> > > 
> > > Because there is no need for it to change.
> > 
> > Err, why not, 
> 
> What is the goal?  To indicate that the e-mail signed came from someone
> in possession of person X's private key.  X's public key can be put up
> on existing public key servers.  There are already numerous public key
> servers functioning and no need for keyring.debian.org to be another.

Other reasons come to mind:

1. Packages index on the NM list. Matching by names or email is not
realy working and I was told that would only be fixed once Debian had
a keyring of NMs.

2. Requesting nm.debian.org to send the applicants logfile to said
applicant. The requestmail could be signed or the log could be send
encrpyted with the NMs key. (For privacy reasons the log isn't public)

MfG
Goswin

Re: non-DD contributors and the debian keyring

[Sven Luther]

On Mon, Aug 25, 2003 at 12:03:43PM -0600, Jamin W. Collins wrote:
> On Mon, Aug 25, 2003 at 07:16:31PM +0200, Sven Luther wrote:
> > On Mon, Aug 25, 2003 at 10:35:17AM -0600, Jamin W. Collins wrote:
> > > 
> > > Because there is no need for it to change.
> > 
> > Err, why not, 
> 
> What is the goal?  To indicate that the e-mail signed came from someone
> in possession of person X's private key.  X's public key can be put up
> on existing public key servers.  There are already numerous public key
> servers functioning and no need for keyring.debian.org to be another.
> 
> > What would be the problem to adding another 'official' debian keyring
> > for those people in the project who don't need to upload packages, but
> > may be otherwise active in the project.
> 
> The lack of need.  Why is such a keyring needed?  What purpose would it
> serve that public key servers don't already?
> 
> > We already have, if i am not mistaken, an emeritus keyring and other
> > such, is the idea of adding a contributor, or translator, or whatever
> > keyring such a big issue ? 
> 
> Don't know if it's an issue (wouldn't think it was), but rather a
> question of need, see above.
> 
> > If it is not possible for technical reasons, then explain, if you feel
> > the project don't need translator or other documentation writers, then
> > say it and explain your position, but this "no and it is not going to
> > change" is not acceptable as a response.
> 
> I've never indicated in any way that the Debian project doesn't need
> translators.  Please reread my statements.

No, but stephen has hinted at such, and my original mail was addressed
at him.

I personally think that the thread started in a wrong way, the real
reason not being the keyring or whatever, but the place of non package
maintainer DDs in the project.

Friendly,

Sven Luther

Re: Snort: Mass Bug Closing

[Drew Scott Daniels]

In response to several issues raised...

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191105
  Not having updated signatures is not an issue that should keep snort out
  of stable as administrators may write their own signatures for snort.

  Perhaps however a wishlist bug asking for a comment (to be put in the
  description) about signature updating and snort's value without updated
  signatures should be filed...
I would even go so far to say that perhaps this is more than a wishlist
issue, but as it's likely not RC then this false sense of security should
be documented before snort gets frozen in sarge.

The security updates can usually be backported when applicable.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=183719 and bug 189267
say:
  DSA 297 closes these bugs. It may be worth noting that potato was not
  affected.
What other security issues are there? I made that statement given
information from another party, was I incorrect? I'll look up my
correspondence and even do some testing if you believe that I was wrong.

The ssh precedent of updating non-rc issues in stable was due to no other
clear way to resolve the rc issues and political pressure. As Colin Watson
said, this is also not a good example as there were many bugs caused by
this upgrade.

Imho it's ok to close non-rc bugs on stable (main Debian developers do).
My rational is that we only fix RC bugs on stable.

I like your automated message to some of the bugs, it could probably be
done to most of the bugs. I looked through some of the bugs and saw that:

95153 may not even be applicable to snort in stable but should be RC.

133049 seems to indicate to me that this old snort should probably be
removed from a few archs.

158040 doesn't have your automated message. It means that snort is
unusable. This is likely the problem that was mentioned to you about your
backport. Merge 16, 176223 with it (also no automated message)? Is
this an upgrade problem?

161659 talks about how a new config file doesn't get generated on even a
fresh install. Perhaps this is the issue in 158040 et al?

165107 suggests that the config file/rule file problem is in sid sarge and
woody? Tagging this correctly may help the testing script...

135603 is an upgrade problem... rules are incompatible. Is this a stable
to stable upgrade?

173331 seems to be related to 158040 (missing config), but talks about how
the cron script fails, patch included.

170580 looks like a problem with the debconf script. A simple, obvious
workaround is mentioned. This sounds like an upgrade problem.

165135 is a policy violation, which versions are affected? Reported well
after woody was released... A quick check of the source code could reveal
the answer.

I don't know if you should close the upgrade bugs as I've heard the
argument "users should only be using stable releases of packages" and I
don't know about snort in potato (is it there? does it upgrade
correctly?).

I'm getting a bit frustrated going through these myself. It seems that
there's a lot of duplication, and (without testing) it looks like many of
these bugs are still in sid.

If you would like help going through these bugs, tagging them correctly,
merging them, closing some, etc. I'd be happy to look even closer.

 Drew Daniels

Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)

[Javier Fernández-Sanguino Peña]

On Mon, Aug 25, 2003 at 12:11:07PM -0400, Noah L. Meyerhans wrote:
> 
> If you have a specific policy that allows you to only be interested in
> ancient attacks, good for you.  We cannot expect our users to be in such
> a position.

Maybe you are not interested in new attacks (say, about a year old) for
vulnerability assesment since your systems are quite old anyway and no new
attacks have been found for your are either unknown (no one is doing
security research on them) or rock-solid systems. Show me a bug less than a
year old for VMS (not OpenVMS), or Ultrix, please. 

In either case, you can still have your Nessus 1.x and Snort 1.8 engines up
and running as soon as you feed them with data, since both are open enough
for the administrator to write new plugins and/or rules for them admins can
still rely on them. Might I remind you that there rules or plugins can be
easily backported? (whileas software cannot) That's the whole point of my 
proposal for separating engines and data. Could you please make useful 
comments to _that_?

Regards

Javi


pgppyEIo00jPz.pgp
Description: PGP signature

Re: Building kernel modules for stock kernels is a hell of a job!

[horrorvacui]

On Sun, 24 Aug 2003 19:50:18 -0500
Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui  <[EMAIL PROTECTED]>
> said: 
>
> > This is my view: the kernel headers and the configuration used when
> > compiling a stock kernel are to be viewed as an *integral part of
> > that kernel*. The headers should be installed by default, 
> 
>   Heh. You are describing how things used to be, with the
>  kernel-headers always installed by kerel-image, and the symlink kept
>  in place. Looking at the CVS, you could have any number of headers or
>  sources in place, and the /usr/src/linux symlink was kept pointing to
>  the latest version, as determined by the most recent kernel-image
>  isntalled. 

Yes. The symlink is more or less unnecessary topping, but this is how it
should be.

> 
>   Of course, it all used to fall apart for user who had multiple
>  kernels installed, and woh used to swithc in between, people who had
>  limited amount of space in /usr, and people who wanted to compile for
>  a different machine than the current one. 

Of course, but aren't those people (except for those with limited space)
usually the ones that can cope with that? If you're knowledgeable enough
to use multiple kernels, it can be assumed that you can be burdened with
the responsibility of having /usr/src/linux pointed at the right
direction, depending on the currently running kernel. I'm no newbie, mind
you - I've been compiling my kernels, installing modules and making it all
work together for years, yet getting the headers/source was too cryptic
for me. Remember that most unexperienced users won't even know that they
need a kernel in the source form, or the headers, nor will they understand
why.

I'll maintain that it would be a great help for users if every kernel came
with headers packaged. The nice install-routine-dialogs-thingy (was that
debconf? dselect? dpkg-whatever?) can ask "Do you want to skip installing
kernel headers" and have "No" selected as default. Or perhaps one could
make the headers a dependancy of the kernel, so the kernel packages are
small and those who know how may override this.

> 
>   The current behaviour was introduced to allow for increased
>  flexibility. 
> 

I don't see how the flexibility might benefit from this (except for
reducing the size of kernel packages). After all, if the situation still
were as you described above, deleting a directory and a symlink would be
all you needed to do to make it as it is currently. The other way around
it's much more difficult, and if it's only about finding out what you need
to do.

Sorry about my insisting on this, but I see myelf in a way as the
advocatus newbii (pun intended). It's a thing that might turn off many new
users off Free Software.

-- 
Horror Vacui

Registered Linux user #257714

Go get yourself... counted: http://counter.li.org/
- and keep following the GNU.

Re: non-DD contributors and the debian keyring

[Jamin W. Collins]

On Mon, Aug 25, 2003 at 07:16:31PM +0200, Sven Luther wrote:
> On Mon, Aug 25, 2003 at 10:35:17AM -0600, Jamin W. Collins wrote:
> > 
> > Because there is no need for it to change.
> 
> Err, why not, 

What is the goal?  To indicate that the e-mail signed came from someone
in possession of person X's private key.  X's public key can be put up
on existing public key servers.  There are already numerous public key
servers functioning and no need for keyring.debian.org to be another.

> What would be the problem to adding another 'official' debian keyring
> for those people in the project who don't need to upload packages, but
> may be otherwise active in the project.

The lack of need.  Why is such a keyring needed?  What purpose would it
serve that public key servers don't already?

> We already have, if i am not mistaken, an emeritus keyring and other
> such, is the idea of adding a contributor, or translator, or whatever
> keyring such a big issue ? 

Don't know if it's an issue (wouldn't think it was), but rather a
question of need, see above.

> If it is not possible for technical reasons, then explain, if you feel
> the project don't need translator or other documentation writers, then
> say it and explain your position, but this "no and it is not going to
> change" is not acceptable as a response.

I've never indicated in any way that the Debian project doesn't need
translators.  Please reread my statements.

-- 
Jamin W. Collins

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

Re: stack protection

[Don Armstrong]

On Mon, 25 Aug 2003, Milan P. Stanic wrote:
> There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to
> note just some. They are not 100% secure, but they are more secure
> than software written by ISC.

I'm personally only really familiar with ISC's dhcpd3-server, but have
you even read the code written by Ted Lemon? Just randomly slandering
programmers when you are not intimately familiar with their code isn't
something that should be done lightly.

As far as I can remember, the last exploit in dhcpd3-server happened
well over 2 years ago. While I've never heard of an exploit in udhcp,
I'm relatively sure it's not as widely scrutinized as dhcpd3-server.

> [ I don't like to offend Paul Vixie or ISC programmers. They do good
> job in the beginnings of the Internet and probably in these days they
> didn't anticipate how hostile will become network for collaboration,
> sharing ideas and knowledge, extending freedom ... ]

Many of ISC's programs (bind, dhcp) current versions have been
completely rewritten from scratch, or nearly from scratch. The people
who wrote them are quite well aware of the current state of hostile
networks.

> [ BTW, a good measure for security is: don't use ISC software! :-) ]

In many cases, there isn't an alternative for ISC's software. I have
yet to find a dhcp server that is as featureful and robust as ISC's
dhcp server. If you're serving a network of 5 computers, udhcpd might
work for you, but some people use debian to run dhcpd for networks of
thousands of nodes with hundreds of subnets.


Don Armstrong

-- 
When I was a kid I used to pray every night for a new bicycle. Then I 
realised that the Lord doesn't work that way so I stole one and asked
Him to forgive me.
 -- Emo Philips.

http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu


pgpvYPTl8Re3A.pgp
Description: PGP signature

unsubscribe

[Britton]

__
GNU GPL: "The Source will be with you... always."

Britton Kerin

Re: non-DD contributors and the debian keyring

[Sven Luther]

On Mon, Aug 25, 2003 at 10:35:17AM -0600, Jamin W. Collins wrote:
> On Mon, Aug 25, 2003 at 05:18:45PM +0200, Sven Luther wrote:
> > 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.
> > 
> > Why ?
> 
> Because there is no need for it to change.

Err, why not, this has such a ring of finality without explanation to
it. What would be the problem to adding another 'official' debian
keyring for those people in the project who don't need to upload
packages, but may be otherwise active in the project. We already have,
if i am not mistaken, an emeritus keyring and other such, is the idea of
adding a contributor, or translator, or whatever keyring such a big
issue ? 

And this kind of answer (no, because we don't like it, we speak only
english anyway, and don't need translation, or other such crap) is not
an excuse to an answer.

If it is not possible for technical reasons, then explain, if you feel
the project don't need translator or other documentation writers, then
say it and explain your position, but this "no and it is not going to
change" is not acceptable as a response.

Friendly,

Sven Luther

Bug#207203: ITP: python-geoip -- python bindings for the GeoIP IP-to-country resolver library

[Josselin Mouette]

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

* Package name: python-geoip
  Version : 0.2.0
  Upstream Author : MaxMind LLC (http://www.maxmind.com/)
* URL : http://www.maxmind.com/app/python
* License : MIT/X like
  Description : python bindings for the GeoIP IP-to-country resolver library

 GeoIP is a library that enables the user to find the country that any
 IP address or hostname originates from, using a database instead of 
 DNS.
 .
 This package contains the python bindings for GeoIP, allowing to use 
 this library within a python program.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom

Re: A possible GFDL compromise

[Fedor Zuev]

On Sun, 24 Aug 2003, Nathanael Nerode wrote:

>Fedor Zuev, missing the point AGAIN, said:
>>I cannot see any connection between disagreement with anyone
>>opinion, and the right to censor somebody else's opinion, so
>>angrily demanded by you.

>There's no censorship involved. *sigh* The GNU Manifesto would
>still be freely available from the FSF website.

>Lack of forced distribution is not "censorship".  Get a clue, or a
>dictionary.

Heh.

"Why that ugly, non-free GPL license demand from me to
distribute source code? Source would still be freely available from
the FSF website! Lack of forced distribution do not harm a
freedom!"   Agree?

Re: non-DD contributors and the debian keyring

[Jamin W. Collins]

On Mon, Aug 25, 2003 at 05:18:45PM +0200, Sven Luther wrote:
> 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.
> 
> Why ?

Because there is no need for it to change.

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

Update: Patch needs Sponsor - List of easily NMUed RC bugs

[Goswin von Brederlow]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> Hi,
> 
> I went through the RC bug list and collected Bugs with trivial patches
> and sorted them a bit. They realy don't need much work so if you have
> a minute pick one. If you want to NMU any of them check the
> then currently claimed bugs (url under claimed bugs).

Changes (~24h): fixed +6

> g++-3.3 fixes:
> --
> The same problem comes up again and again, allways the same fix.

#195527 mysql++: FTBFS with g++-3.3: Missing  include
#202032 rumba-manifold: FTBFS with g++-3.3: Missing #include 
#197762 nte: FTBFS with gcc-3.3: Uses multiline strings
#193067 rust: FTBFS: g++ 3.2 errors
#190942 tcl-sql: FTBFS: g++ 3.2 errors

> Perl touched:
> -
> One involves perl and the other patch is for pelr code, knowing a bit
> perl might be good.

#204859 FTBFS (unstable/m68k): perl makes abiword fails to build, bad C++

> Other easy stuff:
> -
> Bits and pieces

#190260 Segmentation fault on alpha
#184885 LSB 1.3 test suite failures
#196149 mkswap creates invalid swap files
#196850 wall is being distributed under wrong license
#102675 libggi2-dev: should provide static archives
#204456 libjdom-java: Wrong build-dep: does not need xalan2 nor saxon
#203750 log4cpp: FTBFS: `long long' error
#203823 gnuyahoo: FTBFS: automake error

> Stuff that should be looked over and tested first:
> --
> Those patches have some impact on the packages or arent so clear cut

#192545 pcb: Fails to build with current flex
#194168 preferences: FTBFS with gobjc-3.3: #import is obsolete
#194164 preferences-app: FTBFS with gobjc-3.3: #import is obsolete
#191197 rats: Fails to build with current flex
#166737 snmpkit: FTBFS with gcc 3.2
#173762 FTBFS: Build failure of haddock on i386
#167054 FTBFS: Build failure of xview on i386

> M68k related:
> -
#201903 xt: (m68k/unstable) FTBFS

> Upload MIA:
> ---
> An upload was promised but the promised time has passed since

#191199 savant: FTBFS: g++ 3.2 errors

> Claimed and Pending Bugs:
> -
> Claimed bugs as on http://bugs.debian.org/cgi-bin/claims.cgi
> Also look at master:/org/bugs.debian.org/bugsquash/claims/

#198333 legos: FTBFS with gcc-3.3: Uses multiline strings
#195157 mps: FTBFS with gcc-3.3: Invalid preprocessor pasting
#195546 poppassd: FTBFS with gcc-3.3: Uses obsolete varargs.h
#200071 zhcon: FTBFS with g++-3.3: Missing #include 


Fixed:
--
#198317 pimppa: FTBFS with gcc-3.3: Uses multiline strings
#198113 stardict: FTBFS with g++-3.3
#197214 libggi: FTBFS with gcc-3.3: Uses multiline strings
#196450 simplecdrx: FTBFS with g++-3.3: Missing  include
#196324 xosview: FTBFS with g++-3.3: strstream.h is gone
#195577 libnids: FTBFS with gcc-3.3: Uses multiline strings (wrong pending tag)

MfG
Goswin

PS: might be time for another run throught the RC
Seen any bug that happens repeadetly or a group of bugs related to the
same general topic?

Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)

[Noah L. Meyerhans]

On Mon, Aug 25, 2003 at 01:56:40PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> That's not correct, it cannot detected _new_ potentially harmful traffic. 
> There's quite a lot of potentially harmful traffic (stable) snort can
> detect. The fact that it's not up-to-date does not mean that it's useless,
> it means that it won't detect new attacks (but it will detect old attacks).
> Depending on your security policy that might, or might not, be enough.

No.  New attacks represent security threats.  Old attacks represent
curiosities, at best (i.e. have you seen any Redhat 6.2 rpc.statd
attacks lately?)

An intrusion detection system that can not detect known intrusions is
not useful.  It's dangerous in the same way that turning syslog off is
dangerous: "Well, there's nothing in the logs, so the system must be
fine"

If you have a specific policy that allows you to only be interested in
ancient attacks, good for you.  We cannot expect our users to be in such
a position.

noah



pgpXVAqht4O5f.pgp
Description: PGP signature

Re: Translations sleeping in the BTS (was: Re: non-DD contributors and the debian keyring)

[Adam Heath]

On Fri, 22 Aug 2003, Christian Perrier wrote:

> And, as Steve pointed out, translation stuff is minimalistically
> invasive so this does not require an enormous amount of attention
> after the NMU.

Yes, but there are new libraries that get linked to, new compilers, etc.

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Sven Luther]

On Mon, Aug 25, 2003 at 07:10:19PM +1000, Anthony Towns wrote:
> On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> > Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > > binary-only uploads are clearly not the same.
> > > Ah ? And why ? Translation changes do not interfer with the source code of
> > > the package neither.
> > Hummm. Technically speaking, it does..?:-). With the source code of
> > the packagenot with the upstream source code.
> 
> New uploads will often trigger dormant bugs due to changes in the
> toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> current, a new upload built with gcc-3.3 will often not work even if the
> only source changes were some grammar corrections in a README file, eg.
> 
> It's the NMUer's responsibility to fix these bugs too.

Err, FTBFS are RC bugs, most probably not of the responsability of the
NMUer. Especially if the NMUer just did some translation work or
something.

What would you say if instead of doing the NMU, the potential uploader
would will a FTBFS RC bug, and then make an NMU which fixes the
translation problem. Would it then still be his responsability to fix
the FTBFS bug ?

And it is always better to fix those FTBFS bugs, than to silently ignore
them and hoping that another RC bug doesn't force us to rebuild anyway.

Friendly,

Sven Luther

Re: Snort: Mass Bug Closing

[Adam Heath]

On Mon, 25 Aug 2003, Josip Rodin wrote:

> On Mon, Aug 25, 2003 at 10:25:28AM +0200, Sander Smeenk wrote:
> > > I've upgraded to this version and it has required me to press y to replace
> > > modified conffiles in /etc/snort/rules/ about two dozen times, while I'm
> > > pretty sure I never touched any of them. That's an pretty impressive 
> > > amount
> > > of annoyance you managed to cause there.
> >
> > I wish I knew what I could do about that.
>
> It's some sort of a corner case situation in which actually unchanged files
> appear changed and dpkg prompts for them. Did the packages ever modify the
> files? Did they move them around?

You know, I don't think that's the case, really.

Re: packages mucking in /usr/local/?

[Adam Heath]

On Mon, 25 Aug 2003, Dan Jacobson wrote:

> >  However, the package may create empty directories below `/usr/local'
> >  so that the system administrator knows where to place site-specific
> >  files.  These directories should be removed on package removal if they
> >  are empty.
>
> OK, but then those packages should list them so dlocate will show that
> they are intentionally placed there, no?

That's not possible.  dlocate only lists files that come from debs.

Re: non-DD contributors and the debian keyring

[Sven Luther]

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.

Why ?

Friendly,

Sven Luther

Re: stack protection

[Goswin von Brederlow]

"Milan P. Stanic" <[EMAIL PROTECTED]> writes:

> On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote:
> > On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote:
> > > > Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd,
> > > > cron,
> > >
> > > Maybe someone else should do that, I hope at least.
> > 
> > What should be done for the few years that we probably have to wait for 
> > such 
> > programs to be written?
> 
> There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note

vsftp can't do fxp.

MfG
Goswin

Re: Objections to #156161?

[Goswin von Brederlow]

Thomas Hood <[EMAIL PROTECTED]> writes:

> This is a second call for objections to #156161 as restated
> in my recent posting to this list.
> http://marc.theaimsgroup.com/?l=debian-devel&m=106150585805521&w=2
> 
> To recap, the idea is that invoke-rc.d be modified such that
> it _not_change_ the state of a service (i.e., neither start it
> nor stop it) on entering a runlevel if there is neither a start
> link nor a stop link for the service in that runlevel.  This

The jobs running after entering a runlevel should allways be the same
irrelevant from where one comes.

Say runlevel 1 starts foo.
Change to runlevel 2 which has no foo scripts, foo keeps running.
Change to runlevel 3 which has a kill script, foo is stoped.
Change to runlevel 2, foo is not running.

The existence of starts scripts alone is sufficient to get the right
behaviour:

old level | new level | affect
--+---+
  |   | no change (if it runs don't kill it)
has start |   | stop service
  | has start | start service
has start | has start | no change (if it doesn't run, don't start it)

For scripts that just run once like rcS.d/checkroot.sh all runlevels
would need a start script or a new prefix "R" for just run on enter
would be needed.

But I think that behaviour would be most consistent. Note that it
includes yours.

MfG
Goswin

Re: Snort: Mass Bug Closing

[Javier Fernández-Sanguino Peña]

On Mon, Aug 25, 2003 at 12:46:27PM +0100, Colin Watson wrote:
> 
> Considering the disaster that the openssh update to potato was, and the
> bugs it caused, I'm not sure that that's a good example to bring up if
> you're *advocating* upgrading a package to a new upstream version ...

Well, I was really giving a counter-example on the policy of "do not upload 
new version", however that's up to the Release Manager and the Snort 
maintainer, of course.

Regards

Javi


pgpl87U2h8077.pgp
Description: PGP signature

Re: Snort: Mass Bug Closing

[Martin Schulze]

Sander Smeenk wrote:
> I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223,
> 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506,
> 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280,
> and 189780 with a nice message telling that the bug was reported on a
> really old package-version and the bug is really old too, including a
> URL to an up to date version of the package, where most probably all
> these bugs are fixed.

It would probably be better if you would send the information you
prepared to nnn-submitter and tag those bugs `stable' and `wontfix'
and close them after sarge is released and woody removed from
ftp.debian.org.

Regards,

Joey

-- 
GNU does not eliminate all the world's problems, only some of them.
-- The GNU Manifesto

Please always Cc to me when replying to me on the lists.

Re: where to install additional kernel modules?

[Manoj Srivastava]

On Mon, 25 Aug 2003 10:30:18 +0200, martin f krafft
<[EMAIL PROTECTED]> said:

> also sprach David Schleef <[EMAIL PROTECTED]> [2003.08.25.0330 +0200]:
>> In reality, it doesn't matter what directory you put modules in,
>> since they all share the same namespace.  You can't have two module
>> files called module_x.o and expect it to work.  Users, however,
>> appreciate the separation.

> I am aware of that, and I favour the approach taken by comedi.
> However, I simply wanted to know if this is guided by policy or just
> sane decision.

> Should there be a policy entry about it?

If there is a single sane approach, policy should not enter
 into it. Policy is not here to tell people not to create bugs -- we
 should know that all by our own selves.

manoj
-- 
The world wants to be deceived. Sebastian Brant
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: stack protection

[Andreas Barth]

* Milan P. Stanic ([EMAIL PROTECTED]) [030825 16:50]:
> On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote:
> > On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote:
> > > > Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd,
> > > > cron,
> > >
> > > Maybe someone else should do that, I hope at least.
> > 
> > What should be done for the few years that we probably have to wait for 
> > such 
> > programs to be written?

> There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note
> just some. They are not 100% secure, but they are more secure than
> software written by ISC.

ftp is deprecated.

(I do usually recommend WebDAV as non-anon-ftp-replacement and http as
anon-replacement.)



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

Re: Snort: Mass Bug Closing

[Jamin W. Collins]

On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote:
> 
> The problem is that the buglist i'm having on snort now, consists of
> mainly bugs filed on the stable package of snort, which has been long
> solved in the later releases of snort that didn't make it in the
> release of Debian.

So, tag them as such.  If you close them, they will just be reopened by
the next individual to find it in the stable package.  Tagging it with
the release effected.

> We've been over this in debian-security before. I fixed the 1.8.4
> package once, it got rejected, and I tried to have 2.0.x installed in
> Stable, but ofcourse, you can't put a new upstream version in a
> released stable Debian.

Actually that's not true, as an example I refer you to SSH.

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

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Steve Langasek]

On Mon, Aug 25, 2003 at 11:56:33AM +0100, Mark Brown wrote:
> On Sun, Aug 24, 2003 at 11:08:52PM +0200, Martin Quinson wrote:

> > Well, either you were lucky, or you use good and well configurated mail
> > tools. But if my language did need a funky encoding, I would not let my work
> > depend of such conditions. Don't get me wrong. I mean that in such
> > condition, uuencoding prevents the DD from shouting himself in the foot, and
> > I've the feeling that it helps anyone, including the developer.

> As a data point all the translations I've been sent since I can remember
> (certainly since I converted my packages to use po-debconf) have arrived
> as MIME attachments to bugs.  If there are any problems with their
> encoding they certainly haven't been reported to me.  If this is a
> problem it doesn't seem to be bothering many people.

> I'd certainly much rather get translations as MIME attachments since
> MIME is actually supported by mail tools and I'm not convinced there is
> actually a problem with it.

I have had the experience in the past where my MUA (mutt) running in
UTF-8 mode would *autoconvert* plaintext MIME attachments when saving
them, such that an attachment received in ISO8859-1 would be saved to
disk as UTF-8.  Given that the .po files contain embedded information
about the document's encoding, this doesn't work all that well.

The translator in question has taken to gzipping his translations when
sending them, which seems a reasonable workaround until the whole world
is running UTF8. :)

-- 
Steve Langasek
postmodern programmer


pgpj8nQpkTi3D.pgp
Description: PGP signature

Re: stack protection

[Milan P. Stanic]

On Mon, Aug 25, 2003 at 04:14:12PM +1000, Russell Coker wrote:
> On Mon, 25 Aug 2003 07:48, Milan P. Stanic wrote:
> > > Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd,
> > > cron,
> >
> > Maybe someone else should do that, I hope at least.
> 
> What should be done for the few years that we probably have to wait for such 
> programs to be written?

There are some of them: vsftpd, pure-ftpd, udhcp, uschedule ... to note
just some. They are not 100% secure, but they are more secure than
software written by ISC.

[ I don't like to offend  Paul Vixie or ISC programmers. They do good
job in the beginnings of the Internet and probably in these days they
didn't anticipate how hostile will become network for collaboration,
sharing ideas and knowledge, extending freedom ... ]

[ BTW, a good measure for security is: don't use ISC software! :-) ]

[...]
> > If attacker can poison DNS cache or fake DHCP server to do something
> > nasty then the problem with SE Linux is just mitigated, not solved.
> 
> Mitigating a problem so that it only allows DOS attacks or attacks of limited 
> means (such as making a DNS or DHCP server return bogus data) rather than 
> having it allow full administrative access is more than a little mitigation!

I don't like to argue, but that is mitigation and not solution. With
SE Linux problem can be mitigated a lot I agree, and I really like we
have it now in Debian (due to Your effort), but this isn't solution.

[ OK, I'm going to think that we never will have secure system because
absolute security is against nature. ]

[...]
> > I'm not against choice, I just don't like idea that that stack
> > protection and similar code could become "mainstream" one day.
> 
> Why?  I've used OpenWall and PaX and not found any programs that fail to work 
> correctly with them.

I'm sure You know how easy to write one. If I and You don't know for
such program, that doesn't mean that there isn't some in the wild.

Re: Objections to #156161?

[Henrique de Moraes Holschuh]

On Mon, 25 Aug 2003, Thomas Hood wrote:
> This is a second call for objections to #156161 as restated

No objections.  I am fine with the idea that we define, within Debian,
that for sysv-rc no S or K symlink means "leave it alone", which in 
turn means "deny all requests" for invoke-rc.d.

It is up to the administrator to understand that this will break upgrades
in weird ways if a service absolutely HAS to be restarted, since that
restart will simply not happen.  There is no clean fix until we get all
initcripts to properly support the new LSB-introduced (and many times
requested within Debian) equivalent to "restart only if it is already
running".  At that time, it is very simple to fix invoke-rc.d to be
a bit more intelligent.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Richard Braakman]

On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

Someone who has a feeling of "not my problem" won't be thinking of
doing an NMU in the first place.  I present myself as Exhibit A.

Translators have an area of interest that doesn't fit neatly into
a few packages.   They're not alone in this -- porters, and people
who manage transitions, are in the same boat.  That doesn't mean
they care less, it just means they care about specific aspects
of all packages, rather than all aspects of specific packages.

You are berating people who are working to improve the distribution
because they're not doing as much volunteer work as you think they
should be doing.  That's rude.

Richard Braakman

Objections to #156161?

[Thomas Hood]

This is a second call for objections to #156161 as restated
in my recent posting to this list.
http://marc.theaimsgroup.com/?l=debian-devel&m=106150585805521&w=2

To recap, the idea is that invoke-rc.d be modified such that
it _not_change_ the state of a service (i.e., neither start it
nor stop it) on entering a runlevel if there is neither a start
link nor a stop link for the service in that runlevel.  This
would allow a service to be removed from the control of the
runlevel system by deleting its rc symlinks; the service would
then be entirely under manual control -- the admin would start
and stop the service by running the initscript.  This would be
consistent with invoke-rc.d's documentation:

   invoke-rc.d itself will [...] block any tries to start
   an init script in a runlevel it is not configured to
   be started at.

Currently one can delete the rc symlinks for a service but
invoke-rc.d interprets the absence of the stop symlink as
permission to start the service.  This can't be called a bug
because the invoke-rc.d(8) passage above is ambiguous.

--
Thomas Hood

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Richard Braakman]

On Sun, Aug 24, 2003 at 06:56:00PM -0400, Stephen Frost wrote:
> You've obviously not been paying very much attention at all then.
> You should have a pretty good idea if the package is unmaintained or
> not prior to doing an NMU.  If it's not then you're uploading a package
> which fixes some specific bug but leaves the package unmaintained.
> That's irresponsible.

That just doesn't make sense.  Is it somehow more responsible to
skip the NMU and leave the package with an extra bug that you
could have fixed?

Richard Braakman

Africa Online Virus Check - Virus Detected in your Sent Message

[Norton_AntiVirus_Gateways]

Africa Online Virus Screening Security Check:
The file attached to your email to recipient(s) was scanned because it was 
infected with a virus. Please check your computer and screen for viruses. 
Please note the email you sent was processed and virus removed. Africa Online; 
my world, my provider.


--- Scan information follows ---

Result: Virus Detected
Virus Name: [EMAIL PROTECTED]
File Attachment: thank_you.pif
Attachment Status: deleted

--- Original message information follows ---

From: 
To: <[EMAIL PROTECTED]>
Date: Mon, 25 Aug 2003 22:29:54 +0900
Subject: Re: That movie
Message-Id: <[EMAIL PROTECTED]>
Received: from mx01.africaonline.com.na ([196.44.140.166])
 by nav1.africaonline.com.na (NAVGW 2.5.1.19) with SMTP id M2003082514070916369
 for <[EMAIL PROTECTED]>; Mon, 25 Aug 2003 14:07:09 +0100

Virus Found in message "Details"

[Sergio Gonzalez]

Norton AntiVirus found a virus in an attachment you
(debian-devel@lists.debian.org) sent to [EMAIL PROTECTED]

To ensure the recipient(s) are able to use the files you sent, perform a
virus scan on your computer, clean any infected files, then resend this
attachment.


Attachment:  details.pif
Virus name: [EMAIL PROTECTED]
Action taken:  Clean failed : Quarantine succeeded : 
File status:  Infected


<>

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Anthony Towns (aj@azure.humbug.org.au):

> New uploads will often trigger dormant bugs due to changes in the
> toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
> current, a new upload built with gcc-3.3 will often not work even if the
> only source changes were some grammar corrections in a README file, eg.
> 
> It's the NMUer's responsibility to fix these bugs too.

I agree with that, sure. In fact I fear this to appen to me some
day.. :-). But in that case :

> 
> (One possible way of handling this, might be to have translation people
> support each other by having random non-coders do the l10n NMUs and
> having a couple of bad-ass hax0rs on hand to leap to their aid should
> they trigger some unexpected serious breakage.)

Though this is not formalized, I'm very confident that if this happens
some day, I would without any problem find someone for helping in
either debian-devel-french (asking there first because this would be
easier for mutual comprehension)of here (and using the "help"
tag on a RC bug I would raise myself for "not building from sources").

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Anthony Towns]

On Mon, Aug 25, 2003 at 07:22:16AM +0200, Christian Perrier wrote:
> Quoting Martin Quinson ([EMAIL PROTECTED]):
> > > binary-only uploads are clearly not the same.
> > Ah ? And why ? Translation changes do not interfer with the source code of
> > the package neither.
> Hummm. Technically speaking, it does..?:-). With the source code of
> the packagenot with the upstream source code.

New uploads will often trigger dormant bugs due to changes in the
toolchain, too. If a package hasn't been uploaded since gcc-2.95 was
current, a new upload built with gcc-3.3 will often not work even if the
only source changes were some grammar corrections in a README file, eg.

It's the NMUer's responsibility to fix these bugs too.

(One possible way of handling this, might be to have translation people
support each other by having random non-coders do the l10n NMUs and
having a couple of bad-ass hax0rs on hand to leap to their aid should
they trigger some unexpected serious breakage.)

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


pgp836iJdKwEb.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Mark Brown ([EMAIL PROTECTED]):

> > With the former (and still widely used) method for translating debconf
> 
> Is anyone maintaining statistics on how widely used the original Debconf
> scheme is?

I'm not aware of such statistics.

We have the total number of strings in the new schemes. It was 3423
yesterday evening. See
http://www.debian.org/international/l10n/po-debconf/rank

Unfortunately, for old-style debconf templates, Denis Barbier (who
wrote the scripts which generate several l10n pages) did not include
the count of total strings
(http://www.debian.org/international/l10n/templates/rank). I've asked
him for such count a few days ago...but Denis is currently VAC so this
will have to wait until he comes back.


I expect to be still much more strings in old-style debconf than in
new-style.

On the other hand, the majority of key packages has already switched
to po-debconf

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Mark Brown]

On Mon, Aug 25, 2003 at 01:22:03PM +0200, Christian Perrier wrote:

> With the former (and still widely used) method for translating debconf

Is anyone maintaining statistics on how widely used the original Debconf
scheme is?

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Snort: Mass Bug Closing

[Colin Watson]

On Mon, Aug 25, 2003 at 01:37:03PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote:
> > We've been over this in debian-security before. I fixed the 1.8.4
> > package once, it got rejected, and I tried to have 2.0.x installed in
> > Stable, but ofcourse, you can't put a new upstream version in a released
> > stable Debian.
> 
> Why did it get rejected? I'm surprised about that. As of putting a new 
> upstream version in a released stable Debian it did happen in some ocasion 
> (openssh anyone?)

Considering the disaster that the openssh update to potato was, and the
bugs it caused, I'm not sure that that's a good example to bring up if
you're *advocating* upgrading a package to a new upstream version ...

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)

[Javier Fernández-Sanguino Peña]

On Sun, Aug 24, 2003 at 07:32:10PM -0400, Noah L. Meyerhans wrote:
> 
> Snort depends on a set of rules to detect potentially malicious traffic.
> Obviously this set of rules needs to be updates on a regular basis in
> order to keep up with new security issues.  The problem is that the
> version of snort in stable is old enough that the upstream maintainers
> are no longer releasing new rulesets for it.  Thus, it can't detect
> potentially harmful traffic.
> 

That's not correct, it cannot detected _new_ potentially harmful traffic. 
There's quite a lot of potentially harmful traffic (stable) snort can
detect. The fact that it's not up-to-date does not mean that it's useless,
it means that it won't detect new attacks (but it will detect old attacks).
Depending on your security policy that might, or might not, be enough.

Really, the way to fix this package X needs data Y to be up-to-date is to:

a) separate data from the package (Nessus plugins are available in the 
'nessus-plugins' package and can be updated separately, for example)

b) provide some way to retrieve new data (signatures, attacks, whatever)
either: downloading them from the main site directly (as
nessus-update-plugins does) or providing backported packages (and have them
included in stable revisiones. Since in most cases there is no code
involved, it's just data, maybe the Release Manager could be convinced 
to include new versions in revisions of the stable release.

c) have a way to determine properly when new data needs a new engine and 
won't work with older versions and warn the user about it. This means that 
the engine needs to be programmed beforehand to understand a given dataset 
version and complain when the dataset is of a newer (and potentially 
worthless) version. 

That's the approach that all packages that depend on up-to-date data should
take, and is sometimes something that should be coordinated with upstream. 
The fact that security-related software is more prone to this problem is
just related to the way attacks are constantly appearing for vulnerable
software. Unless a package providing a security tool does not implement the
above there is no way (save for backports) that security software will be
100% useful and up-to-date (giving our release process) in a Debian stable 
release. That includes:

- vulnerability assesment scanners (nessus, nikto, since new checks depend
on new signatures)

- anti-virus tools (clamav...)

- intrusion detection systems if based on signatures (such as snort, but 
others, for example Tiger, might but not completely dependant on them)

- spam-filter tools based on rules (spamassasin comes to mind)

But keep in midn that's not just related to security tools (think of
lintian, for example). That doesn't mean that it's worthless, however, it's
just that it's usefulness decreases as time goes by and the tool's _data_
is not updated.

Regards

Javi

Bug#207146: ITP: abul-bcd -- Abul-BCD is a system to maintain a library, mainly designed for french uses.

[Gaetan RYCKEBOER]

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

* Package name: abul-bcd
  Version : 1.2.0
  Upstream Author : ABUL-BCD <[EMAIL PROTECTED]>
* URL : 
http://www.abuledu.org/modules/vitrine/index.php/telecharger-abulbcd
* License : GPL
  Description : Abul-BCD is a system to maintain a library, mainly designed 
for french uses.

ABUL-BCD isi a french application, written in PHP, to provide tools to
maintain a library, school oriented.

Actually, it is only available in french.

AbulBCD est le module de gestion de la BCD d'AbulÉdu.

La partie publique de la BCD permet de trouver un ouvrage par thème
(selon kla classification Dewey), par auteur, ou par le biais du moteur
de recherche interne.

Une fois trouvé, vous êtes en mesure d'emprunter l'ouvrage -- si votre
compte vous le permet -- ou de le réserver s'il n'est pas disponible.

La partie privée d'abul-bcd permet de gérer la base documentaire, les
utilisateurs, et d'importer nue base de documents à partir d'un fichier
DBF (DBase).

Démonstration en ligne: http://bcd.abuledu.org

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux asr-sarge 2.4.20ctx-16 #1 Tue Feb 25 13:58:02 CET 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: Snort: Mass Bug Closing

[Javier Fernández-Sanguino Peña]

On Sun, Aug 24, 2003 at 10:02:02PM -0400, Noah L. Meyerhans wrote:
> 
> I can think off-hand of at least one other security related tool that
> needs frequent updating of a ruleset: nessus.  It is an active probing
> tool that scans a network for vulnerable systems.  If it doesn't have a
> current set of rules, it may fail to identify vulnerable systems,
> leading to the same issues that snort has.

But nessus does provide a tool to download latest plugins 
(nessus-update-plugins) which provides a way to update regardless of your 
version (although some plugins might not work in older releases). Snort 
does not provide anything similar.

Regards

Javi


pgp7bNn614zHm.pgp
Description: PGP signature

Re: Snort: Mass Bug Closing

[Javier Fernández-Sanguino Peña]

On Mon, Aug 25, 2003 at 10:19:55AM +0200, Sander Smeenk wrote:
> Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]):
> 
(...)
> It's annoying now, to see what bugs really are bugs, and what are  bugs

You mean "are bugs related to the latest version" instead of "really are 
bugs".

> filed against stable. Some submitters didn't even specify
> versionnumbers.

Why don't you tag the bugs as such? (i.e. pertaining to 'stable')

> 
> > > Before you object to this rather 'rude' bughandling, please keep in mind
> > > that version 1.8.4 of snort
> > Then you should work towards fixing them in stable or having ftp-masters 
> > agreeing with including a new (backported) version at proposed-updates.
> 
> We've been over this in debian-security before. I fixed the 1.8.4
> package once, it got rejected, and I tried to have 2.0.x installed in
> Stable, but ofcourse, you can't put a new upstream version in a released
> stable Debian.

Why did it get rejected? I'm surprised about that. As of putting a new 
upstream version in a released stable Debian it did happen in some ocasion 
(openssh anyone?)

> That's why i'm doing backports on p.d.o, and that's why i want the bugs
> closed if I can't fix them.

But you have to agree with me that that's completely useless. It does not 
help users at all and it's even against their best interest (since they 
cannot see that the package is buggy!) The only thing that it helps is your 
'karma' wrt to Debian-bug count :-)

> 
> > > It's for the users best interrest that I tell them to use the new version.
> > It is for the best interest of the users that you provide a proper 
> > snort version in proposed-updates.
> 
> THEN LET ME! 

Do it, and maybe discuss here why it got rejected. 

> ffs!  I know the way i'm going now isn't the correct way, but the tight
> rules about updating stable prevent me from doing it any better. Staying
> with 1.8.4 in Stable is useless, it is out dated, which is bad for a
> security tool. Going with 2.0.1 is impossible, because it might (and
> probably will...) introduce new bugs to stable.

So open a bug in ftp.debian.org, like it was done with Nessus, and have the 
security team or the Release Manager agree with you in including a new 
version instead of backporting. Those tight rules are not that tight, 
remember OpenSSH.

> 
> > This is a similar situation to #183524. We have to determine a way to
> > remove packages completely out of stable (due to unfixable security bugs,
> > for example) in a way that do not leave users exposed to these and their
> > bugs.
> 
> A pseudo-package. But then what. 
> Have people not run snort while using stable?
> 

That is, as a matter of fact, what it has been proposing in some of the bug 
reports. You said so yourself in bug 173254 which, BTW, should be 
re-openened. And maybe re-assigned to the the release manager or the 
security team? Or tagged security, or whatever. Bugs should be handled, not 
closed.

> I'm sorry if i sound harsh, i don't mean to. That's because of the rest
> of the replies in this thread. don't take it personal okay ;)

I won't.

Regards

Javi

PS: Please don't CC me, I'm in the list.


pgpNd2Eryd6uu.pgp
Description: PGP signature

Re: Snort: Mass Bug Closing

[Christian Perrier]

Quoting Sander Smeenk ([EMAIL PROTECTED]):
> Hi,
> 
> I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223,
> 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506,
> 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280,
> and 189780 with a nice message telling that the bug was reported on a

Why not just tag these bugs as "woody" ?

Then close them when sarge is released.

This would prevent further bug reports on the exact same subject, at
the minimum.

You may then put the exact same message you proposed to send when
closing the bugs, but with the control message you will send for
tagging the bugs as "woody".

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Mark Brown ([EMAIL PROTECTED]):

> As a data point all the translations I've been sent since I can remember
> (certainly since I converted my packages to use po-debconf) have arrived
> as MIME attachments to bugs.  If there are any problems with their
> encoding they certainly haven't been reported to me.  If this is a
> problem it doesn't seem to be bothering many people.

po-debconf helps a lot there, because all you have to do is drop the
xx.po file in debian/po.

With the former (and still widely used) method for translating debconf
stuff, with templates.xx files along with the master templates files
or, even less easier, all translations in the same file, it was quite
easy for maintainers to mess up translations.

This is why, for instance, Ilgiz Kalmetev sent his old russian
translations for templates uuencoded. He does not do so anymore when
sending ru.po files because that isn't needed.

In this matter, for sure, po-debconfhas been a major
enhancement. Thanks to Denis Barbier and Joey Hess who made this
possible.

Re: packages mucking in /usr/local/?

[Colin Watson]

On Mon, Aug 25, 2003 at 07:06:19AM +0800, Dan Jacobson wrote:
> Colin Watson wrote:
> >  However, the package may create empty directories below `/usr/local'
> >  so that the system administrator knows where to place site-specific
> >  files.  These directories should be removed on package removal if they
> >  are empty.
> 
> OK, but then those packages should list them so dlocate will show that
> they are intentionally placed there, no?

Nope.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> Thanks for your time. I do really appreciate the time you're investing in a
> discussion which is vital for my presonal goals inside Debian, but clearly
> not for yours.

I think we cannot say this from Stephen's mail. We clearly disagree on
NMU/reponsibility stuff but, so far, Stephen has never mentioned that he
has no interest in translation stuffat least from what I've interpreted... 

Re: Bug#207139: ITP: aspell-pl -- The alternative Polish dictionary for aspell

[Krzysztof Krzyzaniak]

W liście z pon, 25-08-2003, godz. 12:27, Krzysztof Krzyzaniak (eloy)
pisze: 
> Package: wnpp
> Version: unavailable; reported 2003-08-25
> Severity: wishlist
> 
> * Package name: aspell-pl
>   Version : N/A; reported 2003-08-25

Version : 20030825 (upstream package is generated daily)

>   Upstream Author : [EMAIL PROTECTED]
> * URL : http://www.kurnik.pl/slownik/
> * License : CREATIVE COMMONS PUBLIC LICENSE
>   Description : The Polish dictionary for aspell

  eloy
-- 
[EMAIL PROTECTED]

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Mark Brown]

On Sun, Aug 24, 2003 at 11:08:52PM +0200, Martin Quinson wrote:

> Well, either you were lucky, or you use good and well configurated mail
> tools. But if my language did need a funky encoding, I would not let my work
> depend of such conditions. Don't get me wrong. I mean that in such
> condition, uuencoding prevents the DD from shouting himself in the foot, and
> I've the feeling that it helps anyone, including the developer.

As a data point all the translations I've been sent since I can remember
(certainly since I converted my packages to use po-debconf) have arrived
as MIME attachments to bugs.  If there are any problems with their
encoding they certainly haven't been reported to me.  If this is a
problem it doesn't seem to be bothering many people.

I'd certainly much rather get translations as MIME attachments since
MIME is actually supported by mail tools and I'm not convinced there is
actually a problem with it.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Bug#207139: ITP: aspell-pl -- The alternative Polish dictionary for aspell

[Krzysztof Krzyzaniak (eloy)]

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

* Package name: aspell-pl
  Version : N/A; reported 2003-08-25
  Upstream Author : [EMAIL PROTECTED]
* URL : http://www.kurnik.pl/slownik/
* License : CREATIVE COMMONS PUBLIC LICENSE
  Description : The Polish dictionary for aspell

(Include the long description here.)
A alternative Polish spelling dictionary for the spelling checker aspell.

It is taken from project http://www.kurnik.pl/slownik/

Initial package is available:

deb http://www.kofeina.net/eloy/debian/ ./


BTW, please take look at licence. For me (IANAL) is DFSG compatible:

Copyright:

This dictionary is covered by CREATIVE COMMONS PUBLIC LICENSE:

ShareAlike 1.0
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL 
SERVICES. DISTRIBUTION OF THIS DRAFT LICENSE DOES NOT CREATE AN 
ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN
"AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION 
PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE.

License

THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE 
COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY 
COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS 
AUTHORIZED UNDER THIS LICENSE IS PROHIBITED.

BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE
BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS 
CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND 
CONDITIONS.

1. Definitions

   1. "Collective Work" means a work, such as a periodical issue, anthology or
  encyclopedia, in which the Work in its entirety in unmodified form, 
  along with a number of other contributions, constituting separate and 
  independent works in themselves, are assembled into a collective whole. 
  A work that constitutes a Collective Work will not be considered a 
  Derivative Work (as defined below) for the purposes of this License.
   2. "Derivative Work" means a work based upon the Work or upon the Work and 
  other pre-existing works, such as a translation, musical arrangement, 
  dramatization, fictionalization, motion picture version, sound recording,
  art reproduction, abridgment, condensation, or any other form in which 
  the Work may be recast, transformed, or adapted, except that a work that
  constitutes a Collective Work will not be considered a Derivative Work 
  for the purpose of this License.
   3. "Licensor" means the individual or entity that offers the Work under the
  terms of this License.
   4. "Original Author" means the individual or entity who created the Work.
   5. "Work" means the copyrightable work of authorship offered under the 
  terms of this License.
   6. "You" means an individual or entity exercising rights under this License 
  who has not previously violated the terms of this License with respect 
  to the Work, or who has received express permission from the Licensor to
  exercise rights under this License despite a previous violation.

2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or 
   restrict any rights arising from fair use, first sale or other limitations 
   on the exclusive rights of the copyright owner under copyright law or other
   applicable laws.

3. License Grant. Subject to the terms and conditions of this License, 
   Licensor hereby grants You a worldwide, royalty-free, non-exclusive, 
   perpetual (for the duration of the applicable copyright) license to 
   exercise the rights in the Work as stated below:

   1. to reproduce the Work, to incorporate the Work into one or more 
  Collective Works, and to reproduce the Work as incorporated in the 
  Collective Works;
   2. to create and reproduce Derivative Works;
   3. to distribute copies or phonorecords of, display publicly, perform 
  publicly, and perform publicly by means of a digital audio transmission 
  the Work including as incorporated in Collective Works;
   4. to distribute copies or phonorecords of, display publicly, perform 
  publicly, and perform publicly by means of a digital audio transmission 
  Derivative Works;

The above rights may be exercised in all media and formats whether now known 
or hereafter devised. The above rights include the right to make such 
modifications as are technically necessary to exercise the rights in other 
media and formats. All rights not expressly granted by Licensor are hereby 
reserved.

4. Restrictions. The license granted in Section 3 above is expressly made 
   subject to and limited by the following restrictions:

   1. You may distribute, publicly display, publicly perform, or publicly 
  digitally perform the Work only under the terms of this License, and You 
  must include a copy of, or the Uniform Resour

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Christian Perrier]

Quoting Stephen Frost ([EMAIL PROTECTED]):

> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

I have to correct here : when considering a NMU (or even doing it), I
nearly always look at the BTS just to see whether this particular
package doesn't have any other bugs which I could easily fix, with my
(limited) knowledge.

I wouldn't call this "not my problem"... :-)

BUT, of course, as I'm not Superman, I most often cannot deal with all
already opened bugs. I would rather call this "I cannot endorse all
world problems"


> > So, once again, nobody here is threating to open RC bugs against all
> > packages not translated in a given language. Nobody even spoke of opening
> > bugs because a given program is not translated.
> 
> You, again, didn't read the thread.  No one said anything about
> threating to open RC bugs, etc, etc.  There was, however, a discussion
> about the possibility of changing the severity level at some point in
> the future to where translations would be considered RC-level bugs.  You
> might read the thread to see our opinions on that.

We probably had a misunderstanding there. I certainly do not want and
did not write, that translation bugs should become RC stuff.

I wanted to mention that having stuff translated, especially when it
interacts with users is a major consideration for me.

So, the software *and the package* should use methods for making this
possible.

More precisely speaking, and just for giving an example, I hope that
someday using po-debconf will become mandatory in the distribution
(see #206684 for the first step).

So, yes, if this is adopted (206684 is just the first step-->make
debconf mandatory and recommend to use the gettexted variant), a
package prompting the user without (po-)debconf (or a similar tool but
there isn't another one) might have a RC bug raised against him.

But, of course, I absolutely do not want to have my 1292th BR for
"French debconf templates translation" be something else than tagged
as "i18n" when this tag will exist and certainly not RC

(time for boosting #114221, I think...)

This was for clearing up my pointI still think that the discussion
more or less lead nowhere unless we manage to continue it with a few
beers for tempering our feelings... ;-)

-- 

Re: Snort: Mass Bug Closing

[Josip Rodin]

On Sun, Aug 24, 2003 at 10:02:02PM -0400, Noah L. Meyerhans wrote:
> I can think off-hand of at least one other security related tool that
> needs frequent updating of a ruleset: nessus.  It is an active probing
> tool that scans a network for vulnerable systems.  If it doesn't have a
> current set of rules, it may fail to identify vulnerable systems,
> leading to the same issues that snort has.

Yes, and the upstream and Debian maintainers are requesting the removal of
the very old version from woody, see bug #183524. :|

-- 
 2. That which causes joy or happiness.

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[Martin Quinson]

On Sun, Aug 24, 2003 at 09:30:19PM -0400, Stephen Frost wrote:
> * Martin Quinson ([EMAIL PROTECTED]) wrote:
> > On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote:
> 
> > > This hasn't got anything to do with NMU's.
> > 
> > With NMU in general, maybe not. But I see this as rather relevant to the
> > kind of NMU we are talking about. If we add such tag, translators could
> > follow the result of their work. Same thing for NMUer of translations.
> 
> As I said above, which you apparently missed, I'm referring to NMU's in
> general.

No, I did not miss your point, but we (ie, almost everybody in the thread
beside you) are speaking of the special case of translation bug NMUing. I
also understood that you feel that such thing is a bad thing. 

What I still wait for is another solution around that particular problem.

If I understand correctly, you seem to say that packages with dormant
translation bugs should be orphaned or removed from the distribution. If so,
then *you* think that translation bugs are RC, don't you? On which other
argument do you want to orphan packages with dormant translation bugs when
other kinds of bugs are not sufficient to orphan the package? 

I do not think that translation is a sufficient issue to orphan the package,
even if the fact that having such simple fix not applied shows that the
maintainer either 1) does not know what to do with the patch 2) does not
trust the patch since he cannot check it 3) have so few interest in
translations that he does not bother dealing with the bug 4) is MIA, at
least temporarily.

I don't belive in 1. If you cannot handle a patch, then you shouldn't
maintain a package. No matter if it's uuencoded or not. It was said earlier
in the thread that the dormance of translation bugs was not a trust issue,
discarding 2. Moreover, that's what the debian-l10n-* lists are made for.

I have no problem with people falling in the 3rd category. Everybody has his
own center of interest. That's fine as long as translators can do their part
of the job. But if we cannot NMU such package, what can we do? 

Contrary to you, I have no problem either with MIA maintainers. We all have a
real life, and not tuning every day packages which are free of issues
(beside whishlist ones) is also ok for me.

I guess that most of the packages Christian NMUs are somewhere between 3 and
4. What do you propose to get these bugs integrated beside of NMUing and
raising the gravity of the bug, which we do not want to do?

> I'm starting to tire of this.  If you can't maintain the package you
> shouldn't be NMU'ing it.  It's really that simple.

Maybe you're tired of typing the same sentences with no argument in it?

Quoting the RM bits: "You should consider this perhaps your one and only
chance to get some fix you desperately need into sarge, whether it be to a
release-critical bug, an important bug, a normal bug, a minor bug, or in
many cases even a wishlist bug." 

The french translation team aims at providing a fully translated
installation, *including the package installations*. That's the sub-release
goal of our sub debian team. We only speak of using the opportunity offered
by the RM to do so.

> > > I've pointed out numerous times in this thread already why it's wrong to
> > > believe that you can NMU a package without having any responsibility to
> > > it afterwards, except maybe for the bits you changed.  Having that kind
> > > of an attitude is detrimental to the distribution as a whole.
> > 
> > Fully agreed. Who behave so badly ?
> 
> Just about everyone else appears to feel all they should care about is
> the changes they make in their NMU instead of actually caring about the
> package and the distribution.  There's this feeling of "not my problem".

So, what do you think of people currently going through the RC bugs and mass
NMUing packages they do not intend to maintain afterward, just to fix
compilation bugs? I've the feeling that you strongly disagree with this
behaviour too, but I may be wrong.

> > So, once again, nobody here is threating to open RC bugs against all
> > packages not translated in a given language. Nobody even spoke of opening
> > bugs because a given program is not translated.
> 
> You, again, didn't read the thread. 

Your attitude is kind of arrogant on that point. My broken english does not
prevent me to read the thread, which I did.

> No one said anything about
> threating to open RC bugs, etc, etc.  There was, however, a discussion
> about the possibility of changing the severity level at some point in
> the future to where translations would be considered RC-level bugs. 

And I did clearly state that it was not the case. 

The only explanation I have for you thinking that it was said is the
language barrier. Maybe Christian wrote a sentence in english which may
imply so under some native speaker analysis, *but it was not intended*.

Christian and I (and bunch of others) have the feeling that bugs providing a
translation should be trea

Re: Snort: Mass Bug Closing

[Sander Smeenk]

Quoting Josip Rodin ([EMAIL PROTECTED]):
> > > I've upgraded to this version and it has required me to press y to replace
> > > modified conffiles in /etc/snort/rules/ about two dozen times, while I'm
> > > pretty sure I never touched any of them. That's an pretty impressive 
> > > amount
> > > of annoyance you managed to cause there.
> > I wish I knew what I could do about that.
> It's some sort of a corner case situation in which actually unchanged files
> appear changed and dpkg prompts for them. Did the packages ever modify the
> files? Did they move them around?

I believe that in the real 1.8.4 release that is in woody, the rules
files were all places in /etc/snort/ amongst the configuration files
etc. In later releases the files moved to /etc/snort/rules/. I believe
this change was introduced even before I adopted the package.

-- 
| A conscience is what hurts when all of your other parts feel so good.
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

Bug#207129: ITP: mbot -- Generic purpose mail robot

[Julien Danjou]

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

* Package name: mbot
  Version : 0.1 
  Upstream Author : Dimitri Fontaine <[EMAIL PROTECTED]> 
* URL : http://mbot.tuxfamily.org
* License : GPL
  Description : Generic purpose mail robot

mbot is intended to be a generic purpose mail robot, and it is written in 
python. At first, we want it to provide simple internet access via mail,
for people having only mail and wanting to get updated online docs !

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux abydos 2.4.21 #1 SMP Sun Aug 10 18:23:02 CEST 2003 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR

Re: where to install additional kernel modules?

[martin f krafft]

also sprach David Schleef <[EMAIL PROTECTED]> [2003.08.25.0330 +0200]:
> In reality, it doesn't matter what directory you put modules in,
> since they all share the same namespace.  You can't have two
> module files called module_x.o and expect it to work.  Users,
> however, appreciate the separation.

I am aware of that, and I favour the approach taken by comedi.
However, I simply wanted to know if this is guided by policy or just
sane decision.

Should there be a policy entry about it?

-- 
Please do not CC me when replying to lists; I read them!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer, admin, and user
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!


pgp6e2SNoCxWp.pgp
Description: PGP signature

Re: NMUs applying sleeping wishlist bugs about translation (was something else)

[David Weinehall]

On Mon, Aug 25, 2003 at 08:43:55AM +0200, Andreas Metzler wrote:
> Stephen Frost <[EMAIL PROTECTED]> wrote:
> > * Andreas Metzler ([EMAIL PROTECTED]) wrote:
> >> Parse error. I cannot see a connection between answer and question.
> 
> > Life's a beach.  There's all of one line in the developer's reference
> > which talks about your responsibilities when doing an NMU:
> > "Follow what happens, you're responsible for any bug that you introduced
> > with your NMU."  Now, this works fine when the official maintainer is
> > going to follow up; it doesn't work worth a damn if the official
> > maintainer isn't taking care of the package at all anymore.
> 
> Why? Neither the package, nor its quality nor its state of
> unmaintainedness has changed, it just has one (wishlist) bug less.

[snip]

Pah, let's require all maintainers to be able to fix all
translation-bugs on their own.  It should be a requirement to be fluent
in all nuances of all languages to be a maintainer.  Right?  I mean, you
must be able to fix any bug in the package just because you NMU
a new translation, so you better be able to fix any translation-bug if
you fix a memory-leak, right?


Regards: David Weinehall
-- 
 /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander  (\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\)  http://www.acc.umu.se/~tao/(/   Full colour fire   (/

Re: Snort: Mass Bug Closing

[Sander Smeenk]

Quoting Jamin W. Collins ([EMAIL PROTECTED]):

> > Before you object to this rather 'rude' bughandling, please keep in
> > mind that version 1.8.4 of snort, which is in stable, has 3 severe
> > security exploits, 
> So, why hasn't a security update been released for it?

There has been a DSA about Snort. That pointed to my previous backported
packages. Neither me, nor the security team were able to backport the
security fixes to 1.8.4, so this was the best approach, they thought.

-- 
| How can there be self-help "groups"?
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D