Re: 0 RC bugs == releasable quality?

[Anthony Towns]

On Tue, Aug 26, 2003 at 01:48:20AM +0300, Richard Braakman wrote:
> 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.

Hrm. I guess that theory doesn't scale up beyond the package level...

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


pgpgDgYAKasuW.pgp
Description: PGP signature

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

[Anthony Towns]

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

No. They're most probably not through any *fault* of the NMUer. Nevertheless
they are *still* the *responsibility* of the NMUer.

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

I don't understand what you're saying. "would will a FTBFS RC bug" ?

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


pgpadjh4whPQH.pgp
Description: PGP signature

Re: Bits from the RM

[Anthony Towns]

On Mon, Aug 25, 2003 at 07:36:05PM -0400, Neil Roeth wrote:
> 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
> 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.

Note that the layout is:

start date
activity
end date

So you should start doing any "last major changes to major packages for
upload to unstable" by sept 15th, and make sure you're finished doing
them by oct 1st. (Although, if you're going to misinterpret it, far better
to misinterpret the deadlines as two weeks earlier...)

Otherwise, the best way to ensure that upstream changes are low-risk is
to do a line by line review of the changes, and test it yourself. For
minor updates to relatively small packages, this is generally feasible.
Other ways are to do copious testing of it, upstream and down; and if
there *is* copious upstream testing, to try to keep your .diff.gz as
small as possible, so you get the most value you can from that testing.

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


pgpIoaABMuATL.pgp
Description: PGP signature

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Mon, Aug 25, 2003 at 02:17:51AM +1000, Anthony Towns wrote:

> That's for Martin Schulze (Joey - Stable Release Manager) and/or the security
> team to decide; not ftpmaster.

A quick scan of those bugs doesn't reveal anything which looks like a
security vulnerability, so this would seem to be purely an
SRM/proposed-updates issue.

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Sun, Aug 24, 2003 at 03:57:45PM +0200, 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.

Did you check whether any of these bugs are fixed?  I reported at least one
of them, and it is definitely not fixed.  You should not close bugs simply
because they are old.

> 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, and is completely outdated in catching crooks (rulefiles) and
> detection mechanisms. Not to speak of package stability ;)

I think it is quite "rude" to knowingly distribute a package with severe
security problems without fixing the bugs or even informing other
developers.  What are these bugs exactly?  How long have you been aware of
them?

Or are you perhaps not aware of DSA-297?

-- 
 - mdz

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

[Christian Perrier]

Quoting Martin Quinson ([EMAIL PROTECTED]):

> 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

We won't.. :-)

For po-debconf switch bug reports, Michel Grentzinger is at letter "p"
going up in the alphabet. But he's a college teacher and will soon be
back to work :-)

I'm at letter "d", going down.but I go quite slowly as I also deal
with old translations sleeping in the BTS...and thus have to prepare
NMU's, subscribe to many many PTS and deal with all opened bugs of all
NMU'ed packages, including future bugs (grin).

Andre Luis Lopes, from Brazil, is also working on po-debconf switch
but I don't know how he does choose packages for which he submits
patches.

Re: User Based Init

[Wouter Verhelst]

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.
> 
> So, how insane am I?

Quite :-)

One can't start or stop anything that requires a port under 1024 (such
as apache) without root permissions. You'll have to give them those, no
other option.

You do have the option to go with sudo, however. Sudo allows you to
specify exactly which commands a user may or may not restart; you could
say that a user might run commands of this type:

/etc/init.d/apache .*
 /etc/apache/httpd.conf

Watch out for editors, though. Most editors allow you to start shells,
open other files, etc. You'll have to look for one who doesn't.

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
  -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.


pgpsnnNZDgtDs.pgp
Description: PGP signature

中医治牛皮癣

[hmpfmz]

尊敬的收件人:您好!

   牛皮癣的良药"祛癣灵"胶囊
   纯中草药剂.清血热.血燥.祛瘀.祛毒.对牛皮癣等皮肤病有效率100%.痊愈率98%.治愈
后不易复发.详情请进--中医治牛皮癣--www.pifu120.com   [EMAIL PROTECTED]   
联系电话--0543-5366728  

致
礼!
  　　 

Bug#207283: katoob -- katoob, A Gtk2 light weight multilingual BiDi aware text editor

[Mohammed Sameer]

Package: wnpp
Version: N/A; reported 2003-08-26
Severity: wishlist

* Package name: katoob
  Version : 0.3.5
  Upstream Author : Mohammed Sameer <[EMAIL PROTECTED]>
* URL : http://www.arabeyes.org/project.php?proj=Katoob
* License : GPL
  Description : katoob, A Gtk2 light weight multilingual BiDi aware text 
editor
 katoob is a light weight, multi lingual, BIDI-aware text editor.
 It support opening and saving files in multiple encodings.
 The main support was for Arabic language,
 But more languages are currently supported.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux debian 2.4.21-splash #1 Sat Jul 19 03:15:10 EEST 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US

Re: User Based Init

[Peter Makholm]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> One can't start or stop anything that requires a port under 1024 (such
> as apache) without root permissions. You'll have to give them those, no
> other option.

Apache doesn't require a port under 1024. By default it is set up to
use port 80 på it is quite common to have Apaches bound to some other
ports (8000, 8080,  being often used). 

I have often done this as normal user.

-- 
 Peter Makholm |One thing you do is prevent good software from
 [EMAIL PROTECTED] |  being written. Who can afford to do professional
 http://hacking.dk | work for nothing?
   | -- Bill Gates

[MAPS #60827] (rbl) Subject: Your details

[rbl]

Thank you for writing to the MAPS Realtime Blackhole List (RBL) Team.
This email address is used to submit RBL nominations, for RBL removal
requests, and for other communication regarding the MAPS RBL.
 
If you are writing in regards to an issue relating to the MAPS Relay
Spam Stopper (RSS), MAPS Dial-up User List (DUL), Subscription requests,
Client Support, information about changes to our zones, or other MAPS
services, please be aware that those projects are not under the control of RBL
staff.  Instead, please review:
 
Relay Spam Stopper  http://mail-abuse.org/rss/
Dial-up User List   http://mail-abuse.org/dul/
Subscriptions   http://mail-abuse.org/subscription.html
Fee Structure   http://mail-abuse.org/feestructure.html 

Many providers do use MAPS lists but also employ more restrictive lists
which they maintain themselves.  If you have been blocked by those, you'll
need to contact them directly.
 
Your message has been assigned the ticket number shown in the Subject: 
header above.  Please include that string in the Subject: header of any
future correspondance with RBL staff about this issue.
   
--
Mail Abuse Prevention System  http://mail-abuse.org/
Realtime Blackhole List   <[EMAIL PROTECTED]>

Re: Translations sleeping in the BTS

[Tollef Fog Heen]

* Steve Langasek 

| Er.  You're going to hold NMUers responsible for the general crappy
| state of a package before they got to it?

No, but a package might be broken in other subtle ways because of the
NMU, like broken build-environment.  If you upload a package which
doesn't work (even though the only thing you did was to change a
translation), then it's your responsibility to fix that breakage.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

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

[Christian Perrier]

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


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

I undoubtly agree with that pointNot with Stephen Frost's point,
however.

If my NMU raises a portability issue (previously hidden), I *am*
responsible for dealing with it.

Re: Bits from the RM

[Philip Blundell]

On Tue, 2003-08-26 at 01:01, Adam Heath wrote:
> Is there a debian machine I can access that has this problem? 

Yes.  You can use vore, unstable chroot.

p.

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

[Goswin von Brederlow]

Colin Watson <[EMAIL PROTECTED]> writes:

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

"when bugs were changed"

If he means the mtime of the bugs logfile the patch adds support for
the webpages to display that and provides a parsable interface for
tracker programms.

Depending on what he means with changed that sound very relevant.

So speak up Mark, what do you mean with changed?

MfG
Goswin

Re: maintaining upstream snapshot package (was: Bits from the RM)

[Sven Luther]

On Sun, Aug 24, 2003 at 02:25:18PM +1000, Anthony Towns wrote:
> On Sun, Aug 24, 2003 at 07:45:26AM +0900, Tatsuya Kinoshita wrote:
> > > In order to ease some of the pressure on unstable, we're encouraging
> > > greater usage of experimental. [...]
> > I'm a maintainer of Debian wl/wl-beta packages (Wanderlust:
> > mail/news reader for Emacsen).
> > 
> > Debian wl package provides the upstream stable version (latest
> > version is 2.10.1-2).  Debian wl-beta package provides the
> > upstream CVS snapshot which reaches Debian release-quality
> > (latest version is 2.11.7+0.20030814-1).
> > 
> > I intended to include both wl and wl-beta in Debian unstable/
> > testing/stable.
> 
> Why? If wl-beta is Debian release-quality, why would anyone want to
> use wl? Are you doing this for the benefit of users, or because you're
> worried you might be guessing wrong, or because it's what upstream
> prefers, or what?

Hah, and Mark Howard wants to remove galeon 1.3 from unstable since it
is only a cvs snapshot because of what you said. I think maybe you want
to clarify a bit more the experimental use and cvs snapshot thingy.

Friendly,

Sven Luther

Re: Translations sleeping in the BTS

[Goswin von Brederlow]

Tollef Fog Heen <[EMAIL PROTECTED]> writes:

> * Steve Langasek 
> 
> | Er.  You're going to hold NMUers responsible for the general crappy
> | state of a package before they got to it?
> 
> No, but a package might be broken in other subtle ways because of the
> NMU, like broken build-environment.  If you upload a package which
> doesn't work (even though the only thing you did was to change a
> translation), then it's your responsibility to fix that breakage.

If you break it you fix it.

But broken build-environment is a bug of the ftp maintainance
scripts. The problems are known and completly avoidable.

Packages entering sid should be checked for uninstallability (caused by
depends on outdated libs) and a rebuild should probabily triggered in
some sane way (i.e. wait for the arch to get uptodate on the failed
lib and then rebuild against that).

Also source-only uploads spring to mind. We know the autobuilders do a
fine job of having a reasonable build-environment. We know uploaders
overall don't (everyone who does don't be angry).


What doesn't get caught is packages being rebuild with a newer
toolschain or newer libs then they where ready for, but then the
source is broken given the current sid even if the old binary was
fine. Better catch that before something gets released by breaking the
package.

MfG
Goswin

Re: A possible GFDL compromise

[John Galt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 25 Aug 2003, 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?
>

GPL, section 3c, says exactly that

>
>
>

- -- 
A computer without windoze is like a fish without a bicycle.
Who is John galt?  [EMAIL PROTECTED], that's who.  Finger me for PGP
public key.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE/Sx14+ZSKG3nWr3ARAnVKAJ4lRg0pupSAQyTG4f8i5rIH9IHIsACg4Gsp
5jahoMmGjxxEWdADOKntN4U=
=zFjP
-END PGP SIGNATURE-

Re: Translations sleeping in the BTS

[Sven Luther]

On Tue, Aug 26, 2003 at 09:47:16AM +0200, Tollef Fog Heen wrote:
> * Steve Langasek 
> 
> | Er.  You're going to hold NMUers responsible for the general crappy
> | state of a package before they got to it?
> 
> No, but a package might be broken in other subtle ways because of the
> NMU, like broken build-environment.  If you upload a package which
> doesn't work (even though the only thing you did was to change a
> translation), then it's your responsibility to fix that breakage.

To solve that, we really need fully automated autobuilding, even on the
arch the maintainer is using.

The only thing really missing for that now, is to have one of the
autobuilder build the arch:all stuff, or have an arch:all specific
autobuilders, altough maybe not all packages are upto that yet.

People still would need to build the packages fully to make sure it
works before it would be accepted, but after that, it will be fully
autobuilt for all arches.

I guess the changes file would need to contain a flag or something to
make sure that it finished the build on the home box.

Also this would be good for developper with small bandwith on their
devel box.

Friendly,

Sven Luther

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

[Sven Luther]

On Tue, Aug 26, 2003 at 02:53:50PM +1000, Anthony Towns wrote:
> On Mon, Aug 25, 2003 at 05:34:54PM +0200, Sven Luther wrote:
> > 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. 
> 
> No. They're most probably not through any *fault* of the NMUer. Nevertheless
> they are *still* the *responsibility* of the NMUer.
> 
> > 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 ?
> 
> I don't understand what you're saying. "would will a FTBFS RC bug" ?

Ok, i explain more in detail.

Let's say i do translataion work, for that i have to build the package,
and notice that it FTBFS (at least on some obscure arch or something). I
then fill a FTBFS bug report, thus liberating me of the responsability
you want to trust on me, and then NMU the translation improved package.

How can then the responsability be on the NMUer, if it was already
present before ?

And then, how can the NMUer in this case be responsible for some poorly
maintained package to FTBFS ? just because he happened to do some
translation work for it ?

Or are we going to get afraid of making bugfixes or something because a
given unmaintained package possibly might FTBFS, and we will not trigger
it. For that matter, i guess people are now afraid to build packages,
because of the new glibc being broken and holding everything.

Disclaimer : i never did translation work, and probably never will, my
written french being not much better than my english one.

Friendly,

Sven Luther

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

[Sven Luther]

On Tue, Aug 26, 2003 at 10:10:31AM +0200, Christian Perrier wrote:
> Quoting Anthony Towns (aj@azure.humbug.org.au):
> 
> 
> > 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.
> 
> I undoubtly agree with that pointNot with Stephen Frost's point,
> however.
> 
> If my NMU raises a portability issue (previously hidden), I *am*
> responsible for dealing with it.

And i i try to build a random package from source, and it FTBFS, am i
going to be responsible for fixing it if i fill the FTBFS bug report ?

Friendly,

Sven Luther

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

[Christian Perrier]

Quoting Sven Luther ([EMAIL PROTECTED]):

> And i i try to build a random package from source, and it FTBFS, am i
> going to be responsible for fixing it if i fill the FTBFS bug report ?

For sure, no. In the example previously given, I did generate the
FTBFS myself by uploading a NMU. I indirectly made the package having
the RC bug. And it's probably impossible to go back...

This is for sure too bad for me, no luck

In your example, I am just the bug reporter and the package in the
distribution is still "working". 

The difference is very subtile, anyway...and in both cases, because I
am a responsible DD who cares about the distribution, I will make by
best for fixing the bug or help fixing it.

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

[Sven Luther]

On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > 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.

Nice thing, i am in favour of it also. But as i understood it, the
infrastructure is not upto it yet.

I even think that each sub-part of debian should have a separate
autobuilt experimental pool, and would be responsible for release
management to unstable issues for it, with the possibility for the RM to
veto it, or possibly to easily revert a experimental->unstable
migration.

Furthermore i feel than major library changes should build as much other
stuff as it can in their experimental pool shortly before migrating to
unstable. This would result in double work, but is the only way that
things like libc6 would get enough testing and ensure that it does not
break anything when it moves to unstable (and thus properly moves to
experimental afterward).

If we don't rebuild every dependant package in the experimental pool,
we need then to have a way to eventually retrigger the build of every
dependant package once it reaches unstable.

That said, ideally all packages would be rebuilt in the experimental
pool with in an automatic triggered way and then only can the library
component migrate to unstable, in the same way as stuff migrate from
unstable to testing in this way.

Special care would need to be taken for uploads of new stuff when one of
the library pools is waiting to move to unstable.

Friendly,

Sven Luther

Re: Bits from the RM

[GOTO Masanori]

At Mon, 25 Aug 2003 19:01:14 -0500 (CDT),
Adam Heath wrote:
> 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.

dpkg works fine with trex.debian.org dchroot unstable + my self built
2.3.2-1 (2003-07-08 cvs) using LD_LIBRARY_PATH, so it seems other
issue.

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

Yes, you can check on vore.debian.org dchroot unstable.

vore:~> dpkg
Bus error

Regards,
-- gotom

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

[Colin Watson]

On Tue, Aug 26, 2003 at 10:25:24AM +0200, Goswin von Brederlow wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > 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.
> 
> "when bugs were changed"
> 
> If he means the mtime of the bugs logfile the patch adds support for
> the webpages to display that and provides a parsable interface for
> tracker programms.
> 
> Depending on what he means with changed that sound very relevant.

I'm quite sure he's talking about version tracking.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: User Based Init

[Colin Watson]

On Tue, Aug 26, 2003 at 08:24:10AM +0200, Wouter Verhelst wrote:
> One can't start or stop anything that requires a port under 1024 (such
> as apache) without root permissions. You'll have to give them those, no
> other option.
> 
> You do have the option to go with sudo, however. Sudo allows you to
> specify exactly which commands a user may or may not restart; you could
> say that a user might run commands of this type:
> 
> /etc/init.d/apache .*
>  /etc/apache/httpd.conf

You could use authbind in order to require less privilege for this.

-- 
Colin Watson  [EMAIL PROTECTED]

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

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > Hello,
> If we don't rebuild every dependant package in the experimental pool,
> we need then to have a way to eventually retrigger the build of every
> dependant package once it reaches unstable.

Binaries from experimental should not move into sid but be rebuild for
it. That can happen automatically by the buildds if source-only
uploads could be handled. Move the source to sid killing all binaries
and let the autobuilder crunch away.

> That said, ideally all packages would be rebuilt in the experimental
> pool with in an automatic triggered way and then only can the library
> component migrate to unstable, in the same way as stuff migrate from
> unstable to testing in this way.
> 
> Special care would need to be taken for uploads of new stuff when one of
> the library pools is waiting to move to unstable.

Maybe experimental could be a source only section with a proper
build-experimental package thats preconfigured to build on a local
maschine and install.

apt-get upgrade for experimental should then fetch the source, run an
autobuild and install the debs.

Of cause that would be too much for some people so they wouldn't use
experimental. But are they using it now?

MfG
Goswin

Re: Translations sleeping in the BTS

[Mark Brown]

On Tue, Aug 26, 2003 at 10:35:59AM +0200, Goswin von Brederlow wrote:

> Packages entering sid should be checked for uninstallability (caused by
> depends on outdated libs) and a rebuild should probabily triggered in
> some sane way (i.e. wait for the arch to get uptodate on the failed
> lib and then rebuild against that).

A rebuild won't always fix the problem - for example, uninstallability
is sometimes the result of an upload of a new revision of a library
that's sitting in incoming waiting for manual processing.  In that case
the package ought to have build deps on the new version which would give
the scripts something to guess with.  In general I'd guess it would be
better to just hold the upload rather than automatically do rebuilds and
make sure that the action taken to deal with the uninstallability is
sensible.

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

$B!ZL$>5Bz9-9p![K\F|Cf$K(B100$BK|1_Kx(B

[$B%"%$%(!<%+!<%I(B]

$B"#5^$0$"$J$?$N6/$$L#J}!*%"%$%(!<%+!<%I$N%b%P%$%k%-%c%C%7%s%0(B
$B"#$*?=$79~$_$+$i?69~$_$^$G:GB.(B20$BJ,!#5^$J=PHq$G$*:$$j$NJ}92$F$kA0$K$^$:Ev\:Y$*$h$S%a!<%k$G$N$*?=$79~$_$O%"%$%(!<%+!<%I(BHP$B!!(Bhttp://www.i-a-ai.com/aiei/index.html
$B"#$*EEOC$G$N$*?=$79~$_$O%U%j!<[EMAIL 
(BPROTECTED]"%k(B0120$B!](B61$B!](B8484$B!J7HBS!&(BPHS$B2D!K(B
$B"#El5~ETCN;v!J(B1$B!KBh(B22962$B9f(B

Re: Translations sleeping in the BTS

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> People still would need to build the packages fully to make sure it
> works before it would be accepted, but after that, it will be fully
> autobuilt for all arches.
> 
> I guess the changes file would need to contain a flag or something to
> make sure that it finished the build on the home box.

Then you could just togglethe flag before uploading. Well, it would
prevent accidental uploads of non build sources.

We also already have that flag, the changes file contains the md5sum
for the debs. Check for the existence of a deb in the changes file and
then ignore any such line (and any uploaded deb files or not uploaded
deb files).

> Also this would be good for developper with small bandwith on their
> devel box.

MfG
Goswin

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

[Mark Howard]

On Tue, Aug 26, 2003 at 10:25:24AM +0200, Goswin von Brederlow wrote:
> So speak up Mark, what do you mean with changed?

I meant identifying that bug X was fixed in version Y; packages in
experimental contain the fix but sid and testing packages do not (yet).
I think this feature would be even more useful when developers are
fixing bugs reported by sid users and uploading to experimental.

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

Re: Snort: Mass Bug Closing

[Sander Smeenk]

Quoting Matt Zimmerman ([EMAIL PROTECTED]):

> > That's for Martin Schulze (Joey - Stable Release Manager) and/or the 
> > security
> > team to decide; not ftpmaster.
> A quick scan of those bugs doesn't reveal anything which looks like a
> security vulnerability, so this would seem to be purely an
> SRM/proposed-updates issue.

The package in stable was never replaced. An advisory was given out
containing links to my stable packages. It never hit stable's security
updates, so the package in stable still is vulnerable, if one installs
it.

The bugs were probably closed by uploading the fixed versions of the
package to unstable.

Sander.
-- 
| How do you write zero in Roman numerals?
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

$B7HBSCe%a%m40A4L5NA%W%l%<%s%H(B

[tanoshimu]

$BD69b2;$b%U%j!<%a%m!*(B
$B:G?7%R%C%H6J$,40A4L5NA$G$"$J$?$N7HBS$K!#(B
(B[EMAIL PROTECTED]&%s%m!<%I$K$O!"DL?.Hq0J30!"[EMAIL PROTECTED];$s!#(B
$B$*5$7Z$K$I$&$>!#(B
(Bhttp://free.melo.ph/m2
$BI,$:!"7HBSEEOC$G%"%/%;%9$7$F$/[EMAIL PROTECTED](B
(B[EMAIL PROTECTED]&%s%m!<%I$O$G$-$^$;$s!#(B 

Re: Snort: Mass Bug Closing

[Sander Smeenk]

Quoting Matt Zimmerman ([EMAIL PROTECTED]):
> > 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
> Did you check whether any of these bugs are fixed?  I reported at least one
> of them, and it is definitely not fixed.  You should not close bugs simply
> because they are old.

Yes. IMHO all these bugs are fixed in the new packages I provided for
stable users on p.d.o/~ssmeenk/

> > 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, and is completely outdated in catching crooks (rulefiles) and
> > detection mechanisms. Not to speak of package stability ;)
> I think it is quite "rude" to knowingly distribute a package with severe
> security problems without fixing the bugs or even informing other
> developers.

FFS don't act like i'm the bad guy here.

I reported the advisories the minute i heard of them, and that was maybe
a couple of hours after they have been released to the public. A nice
mail went to the security team, and they told me what to do: fix the
package in unstable, and try if i was capable of fixing the stable
version without using new upstream source.

I then told security team I was not capable of doing such a thing. Time
passed and I got a request to create stable packages of new upstream
source and provide them on p.d.o. So i did.

But for as far as I know, those packages went in the advisory, and the
stable archive & stable security updates-apt-source where never updated
with a fixed version of the package. 

> What are these bugs exactly?

If i recall correctly, it was two memory allocation faults in the RPC
code, and one in the fragmented packet reassambly code.

> How long have you been aware of them?

As long as the security team was.

> Or are you perhaps not aware of DSA-297?

I knew it was released, but I probably looked over the fact that indeed
the stable version of the snort-package /has/ been fixed. That was
stupid of me.

Sander.
-- 
| Amnesia used to be my favorite word, but then I forgot it.
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D

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

[Sven Luther]

On Tue, Aug 26, 2003 at 11:17:48AM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > Hello,
> > If we don't rebuild every dependant package in the experimental pool,
> > we need then to have a way to eventually retrigger the build of every
> > dependant package once it reaches unstable.
> 
> Binaries from experimental should not move into sid but be rebuild for
> it. That can happen automatically by the buildds if source-only
> uploads could be handled. Move the source to sid killing all binaries
> and let the autobuilder crunch away.

Well, but you need to build all the dependant packages (and use them) to
catch bugs caused by it.

> > That said, ideally all packages would be rebuilt in the experimental
> > pool with in an automatic triggered way and then only can the library
> > component migrate to unstable, in the same way as stuff migrate from
> > unstable to testing in this way.
> > 
> > Special care would need to be taken for uploads of new stuff when one of
> > the library pools is waiting to move to unstable.
> 
> Maybe experimental could be a source only section with a proper
> build-experimental package thats preconfigured to build on a local
> maschine and install.

No, you loose the benefit of the autobuilder, and would result in
experimenting only on x86 this way.

Friendly,

Svne Luther

Re: Translations sleeping in the BTS

[Sven Luther]

On Tue, Aug 26, 2003 at 11:22:01AM +0200, Goswin von Brederlow wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
> 
> > People still would need to build the packages fully to make sure it
> > works before it would be accepted, but after that, it will be fully
> > autobuilt for all arches.
> > 
> > I guess the changes file would need to contain a flag or something to
> > make sure that it finished the build on the home box.
> 
> Then you could just togglethe flag before uploading. Well, it would
> prevent accidental uploads of non build sources.

Sure, but we already thrust the uploader not to break everything. Way
not do it there also.

> We also already have that flag, the changes file contains the md5sum
> for the debs. Check for the existence of a deb in the changes file and
> then ignore any such line (and any uploaded deb files or not uploaded
> deb files).

Yes, that would be a solution.

Friendly,

Sven Luther

Software Patents in Europe

[Daniel K. Gebhart]

Hi fellows,

What do you think about setting a sign [1]against Software Patents on 
our website? I think the time has come to get more active against software
patents. Due to the directive validating Software Patents that will be 
voted this 1st September at the European Parliament, we have to protest
IMHO.

[1] http://swpat.ffii.org/

fight for your rights,
 Daniel ;-)

-- 
(___)   Daniel K. Gebhart  | 
(  oo   Key fingerprint = 10A6 A760 2635 6184 981A  B19E 03AC D8F6 F412 9574
 \_ |
   \O   "Have you mooed today?"...


pgpaSlv8WifwH.pgp
Description: PGP signature

Re: Accepted gdesklets-data 0.13.1 (all source)

[christophe barbe]

On Mon, Aug 25, 2003 at 08:32:10PM -0400, Sebastien Bacher wrote:
> Source: gdesklets-data
> Binary: gdesklets-data
> Architecture: source all
> Version: 0.13.1
> Distribution: unstable
> Urgency: low
> Maintainer: Sebastien Bacher <[EMAIL PROTECTED]>
> Changed-By: Sebastien Bacher <[EMAIL PROTECTED]>
> Description: 
>  gdesklets-data - displays and sensors for gdesklets
> Closes: 207088
> Changes: 
>  gdesklets-data (0.13.1) unstable; urgency=low
>  .
>* Fixed the wrong directory in README.Debian (Closes: #207088).
> Files: 
>  85b18c208186cbe6a86b48c23e78b9d3 526 x11 optional gdesklets-data_0.13.1.dsc
>  5b5c46862fbb651b34ef1c090cbcd776 344185 x11 optional 
> gdesklets-data_0.13.1.tar.gz
>  c18e378be01cbdb68d8121b464eada4b 319230 x11 optional 
> gdesklets-data_0.13.1_all.deb

Is it a common practice to use this kind of numbering (without a second part 
after 
a dash) for what I presume is a debian-made tarball (multiple upstream tarballs
put together).

   gdesklets-data_0.13.1_all.deb

Also (related) why not use a orig.tar.gz file?
My understanding is that the difference between 0.13.1 and 0.13, because
only the README.Debian has changed, it would have been a good thing to
base it on the previous tarball.

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

There is no snooze button on a cat who wants breakfast.

Re: Software Patents in Europe

[Daniel K. Gebhart]

On Tue, Aug 26, 2003 at 01:58:10PM +0200, Andreas Barth <[EMAIL PROTECTED]> 
wrote:
> SPAM doesn't get better if done for a "good thing".

Funny declaration to SPAM. ;-)

> (That doesn't stop me of writing letters to Members of European
> Parliament e.g., but your mail is absolutly misdirected at d-d.)

So, who else should decide if there will be something done against
software patents at the Debian website if not the DDs themselves?

against software patents _and_ spam,
 Daniel

-- 
(___)   Daniel K. Gebhart  | 
(  oo   Key fingerprint = 10A6 A760 2635 6184 981A  B19E 03AC D8F6 F412 9574
 \_ |
   \O   "Have you mooed today?"...


pgpDlfwAocSa9.pgp
Description: PGP signature

Re: Software Patents in Europe

[Andreas Barth]

* Daniel K. Gebhart ([EMAIL PROTECTED]) [030826 13:50]:
> What do you think about setting a sign [1]against Software Patents on 
> our website? I think the time has come to get more active against software
> patents. Due to the directive validating Software Patents that will be 
> voted this 1st September at the European Parliament, we have to protest
> IMHO.

SPAM doesn't get better if done for a "good thing".

(That doesn't stop me of writing letters to Members of European
Parliament e.g., but your mail is absolutly misdirected at d-d.)



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: Software Patents in Europe

[Glenn McGrath]

On Tue, 26 Aug 2003 13:58:10 +0200
Andreas Barth <[EMAIL PROTECTED]> wrote:

> SPAM doesn't get better if done for a "good thing".
> 
> (That doesn't stop me of writing letters to Members of European
> Parliament e.g., but your mail is absolutly misdirected at d-d.)

Software patents do restrict what debian can distribute, this list is
for people interested in developing and distributing software.

The mail is relavent to the members of the list, and non-commercial in
nature, i dont see how you can consider it to be spam.



Glenn

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

[Goswin von Brederlow]

Sven Luther <[EMAIL PROTECTED]> writes:

> On Tue, Aug 26, 2003 at 11:17:48AM +0200, Goswin von Brederlow wrote:
> > Sven Luther <[EMAIL PROTECTED]> writes:
> > 
> > > On Mon, Aug 25, 2003 at 07:42:13PM +0100, Mark Howard wrote: > Hello,
> > > If we don't rebuild every dependant package in the experimental pool,
> > > we need then to have a way to eventually retrigger the build of every
> > > dependant package once it reaches unstable.
> > 
> > Binaries from experimental should not move into sid but be rebuild for
> > it. That can happen automatically by the buildds if source-only
> > uploads could be handled. Move the source to sid killing all binaries
> > and let the autobuilder crunch away.
> 
> Well, but you need to build all the dependant packages (and use them) to
> catch bugs caused by it.

Only those contained in the sections enabled on the users system. If
you have experimental-core and experimental-gnome all gnome debs
should be comnpiled against the experimental glibc for example.

Having all combinations on the mirrors would overflow them.

> > > That said, ideally all packages would be rebuilt in the experimental
> > > pool with in an automatic triggered way and then only can the library
> > > component migrate to unstable, in the same way as stuff migrate from
> > > unstable to testing in this way.
> > > 
> > > Special care would need to be taken for uploads of new stuff when one of
> > > the library pools is waiting to move to unstable.
> > 
> > Maybe experimental could be a source only section with a proper
> > build-experimental package thats preconfigured to build on a local
> > maschine and install.
> 
> No, you loose the benefit of the autobuilder, and would result in
> experimenting only on x86 this way.

Some base set, like experimental-core + experimental-, could be autobuild and any other combinations build on the
clients side.

MfG
Goswin

Re: Accepted gdesklets-data 0.13.1 (all source)

[Sebastien Bacher]

christophe barbe <[EMAIL PROTECTED]> writes:

> Is it a common practice to use this kind of numbering (without a second part 
> after 
> a dash) for what I presume is a debian-made tarball (multiple upstream 
> tarballs
> put together).
>
>gdesklets-data_0.13.1_all.deb
>
> Also (related) why not use a orig.tar.gz file?
> My understanding is that the difference between 0.13.1 and 0.13, because
> only the README.Debian has changed, it would have been a good thing to
> base it on the previous tarball.

Yes, gdesklets-data is a debian native package (ie: there is no upstream
tarball corresponding to this archive).

-n version are revision on a same upstream tarball, but in this case we
 don't have any .orig.tar.gz 


Cheers,

Sebastien Bacher

Re: Snort: Mass Bug Closing

[Marc Haber]

On Mon, 25 Aug 2003 09:24:41 +0200, Magnus Ekdahl <[EMAIL PROTECTED]>
wrote:
>For users without an internet connection Marc Haber maintains the 
>clamav-data package which includes a static database. As well as the 
>clamav-getfiles package to update it from a computer with internet access.

And daily, untested packages are built automatically on gluck and are
aptable from

deb http://people.debian.org/~zugschlus/clamav-data/ /

Greetings
Marc

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

Re: Accepted gdesklets-data 0.13.1 (all source)

[christophe barbe]

On Tue, Aug 26, 2003 at 02:23:56PM +0200, Sebastien Bacher wrote:
> Yes, gdesklets-data is a debian native package (ie: there is no upstream
> tarball corresponding to this archive).

Thanks for the explaination.

> -n version are revision on a same upstream tarball, but in this case we
>  don't have any .orig.tar.gz 

Is there something preventing the use of a .orig.tar.gz tarball. It
would be nice to see a .orig.tar.gz containing only upstream bits and
the debian stuff in the diff, for review purpose and for bandwith
saving.

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

There's no sense in being precise when you don't even know what you're
talking about. -- John von Neumann

Re: Software Patents in Europe

[Andreas Barth]

* Glenn McGrath ([EMAIL PROTECTED]) [030826 15:05]:
> On Tue, 26 Aug 2003 13:58:10 +0200
> Andreas Barth <[EMAIL PROTECTED]> wrote:

> > SPAM doesn't get better if done for a "good thing".
> > 
> > (That doesn't stop me of writing letters to Members of European
> > Parliament e.g., but your mail is absolutly misdirected at d-d.)

> Software patents do restrict what debian can distribute, this list is

I know, I'm just massivly fighting with them in one package. It's
definitly no fun.

> for people interested in developing and distributing software.
> 
> The mail is relavent to the members of the list, and non-commercial in
> nature, i dont see how you can consider it to be spam.

Sorry, but there a multiple messages about the very same thing on
different lists sent by activists. I for myself consider this as
inproper use. There was e.g. a message on August 22 here. If messages
about one topic are unreleated to each other, that certainly not the
way the references-functions are made to work, and it's showing that
the persons are not discussing but just announcing their action here.

And: -devel is just the wrong list, -project would be far more
adaequate.

That something is "non-commercial" or "for a good purpose" isn't it
make much better. There are right tools and ways for something.
Misusing other tools is bad. Always.

(Trying to stop misinterpreting: I think that sw-patents are a bad
thing, and that the campaign again is a very good thing. But even for
very good things there are borders not to be crossed.)


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: non-DD contributors and the debian keyring

[Hamish Moffatt]

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 an entry in the Debian keyring gives you voting rights, and so is
limited to developers.

Maybe there's an argument for other classes of voting project member
other than just developer (typically package maintainer) such as a
translator or documentor. Those roles might have voting rights (ie be in
the keyring) but not machine access or something, and a different (less
rigorous?) NM process. I suggest you start a thread on debian-project if
you think so.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Accepted gdesklets-data 0.13.1 (all source)

[Javier Fernández-Sanguino Peña]

On Tue, Aug 26, 2003 at 10:08:51AM -0400, christophe barbe wrote:
> On Tue, Aug 26, 2003 at 02:23:56PM +0200, Sebastien Bacher wrote:
> > Yes, gdesklets-data is a debian native package (ie: there is no upstream
> > tarball corresponding to this archive).
> 
> Thanks for the explaination.
> 
> > -n version are revision on a same upstream tarball, but in this case we
> >  don't have any .orig.tar.gz 
> 
> Is there something preventing the use of a .orig.tar.gz tarball. It
> would be nice to see a .orig.tar.gz containing only upstream bits and
> the debian stuff in the diff, for review purpose and for bandwith
> saving.

Again. It's a debian _native_ package, there is no such thing as "upstream" 
in native packages.

Regards

Javi

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

[Andreas Barth]

* Goswin von Brederlow ([EMAIL PROTECTED]) [030826 15:20]:
> Only those contained in the sections enabled on the users system. If
> you have experimental-core and experimental-gnome all gnome debs
> should be comnpiled against the experimental glibc for example.

This mass-introduces bugs reports of glibc-bugs to other packages. No,
glibc (and the other core parts) must be the most conservative part of
the system. (And, I don't believe that a proposal with so many changes
to the pool and mirror system has a real chance to be implemented.)


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

[Matt Zimmerman]

On Mon, Aug 25, 2003 at 09:04:08AM -0600, Jamin W. Collins 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.
> 
> Actually that's not true, as an example I refer you to SSH.

A stunning example of what a terrible idea it is to do this.  That update
was forced due to conditions created by upstream, and caused a great deal of
problems, created a lot of work for the security team, and caused downtime
on many user systems.

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Mon, Aug 25, 2003 at 10:28:18AM +0200, Sander Smeenk wrote:

> Quoting Josip Rodin ([EMAIL PROTECTED]):
> 
> > Oh and it didn't even want to start properly -- and the init script wasn't
> > even so kind to tell me, I had to learn from syslog that
> > Aug 24 16:57:23 hostname snort: FATAL ERROR: Unable to open rules file: 
> > ../rules/bad-traffic.rules or /etc/snort/../rules/bad-traffic.rules
> > All it took to make it work was to change RULE_PATH from ../rules to
> > /etc/snort/rules, but it's still broken that it didn't detect this properly.
> 
> I'm terribly sorry. I made the packages, and since i'm not
> running stable myself, i couldn't extensively test them.
> 
> I'll fix this.

And you wanted this to go into stable?

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote:

> On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote:
> > 
> > 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?

It has?

-- 
 - mdz

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

[Matt Zimmerman]

On Mon, Aug 25, 2003 at 12:11:07PM -0400, Noah L. Meyerhans wrote:

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

The snort in stable _can_ detect known intrusions.  It cannot detect _all_
known intrusions, but if an IDS which cannot detect _all_ known intrusions
is not useful, then no version of snort is useful.

Once snort gets to the point where new rules are usually compatible with the
old engine, I think this problem can be addressed by a process to update the
rules.

-- 
 - mdz

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

[Matt Zimmerman]

On Tue, Aug 26, 2003 at 12:24:11AM +0200, Sander Smeenk wrote:

> 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.
> [...]
> Well. Snort just fails to start if it can't parse the rule files. And
> usually that is with every major upstream release. :(

You might consider talking with upstream about stability.  What about users
who have written their own rules?  These simply break when a new version
comes out?  Why does the format need to change so frequently?

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Mon, Aug 25, 2003 at 10:29:30AM +0200, Sander Smeenk wrote:

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

???

snort (1.8.4beta1-3.1) stable-security; urgency=high

  * Non-maintainer upload by the Security Team
  * Applied upstream fix against integer overflow in the stream4
preprocessor code (VU#139129, CAN-2003-0209, Bugtraq 7178,
spp_stream4.c)
  * Applied upstream fix against buffer overflow in the RPC preprocessor
(VU#916785, CAN-2003-0033, Bugtraq 6963, spp_rpc_decode.c)

 -- Martin Schulze <[EMAIL PROTECTED]>  Fri, 18 Apr 2003 06:13:43 +0200

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Tue, Aug 26, 2003 at 12:46:45AM +0200, Sander Smeenk wrote:

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

Would you stop saying that?  You apparently didn't even read this advisory,
which was about your own package.

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Matt Zimmerman]

On Tue, Aug 26, 2003 at 11:40:10AM +0200, Sander Smeenk wrote:

> Quoting Matt Zimmerman ([EMAIL PROTECTED]):
> > What are these bugs exactly?
> 
> If i recall correctly, it was two memory allocation faults in the RPC
> code, and one in the fragmented packet reassambly code.

I assumed that you were talking about some new bugs, since these old bugs
were fixed several months ago, and yet you still said that stable has these
bugs.

-- 
 - mdz

Re: Snort: Mass Bug Closing

[Jamin W. Collins]

On Tue, Aug 26, 2003 at 11:07:00AM -0400, Matt Zimmerman wrote:
> On Mon, Aug 25, 2003 at 09:04:08AM -0600, Jamin W. Collins wrote:
> > 
> > Actually that's not true, as an example I refer you to SSH.
> 
> A stunning example of what a terrible idea it is to do this.

Never said it was a good idea, just that it did and has happened.

-- 
Jamin W. Collins

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

Re: Snort: Mass Bug Closing

[Andreas Barth]

* Marc Haber ([EMAIL PROTECTED]) [030826 16:05]:
> On Mon, 25 Aug 2003 09:24:41 +0200, Magnus Ekdahl <[EMAIL PROTECTED]>
> wrote:
> >For users without an internet connection Marc Haber maintains the 
> >clamav-data package which includes a static database. As well as the 
> >clamav-getfiles package to update it from a computer with internet access.
> 
> And daily, untested packages are built automatically on gluck and are
> aptable from
> 
> deb http://people.debian.org/~zugschlus/clamav-data/ /

Add a debconf-question about adding this to sources.list?

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: Your details

[Daily Pennsylvanian Webmaster]

>This is a multipart message in MIME format
>
>--_NextPart_000_08A9738A
>Content-Type: text/plain;
>   charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>See the attached file for details
>--_NextPart_000_08A9738A
>Content-Type: application/octet-stream;
>   name="document_all.pif"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment;
>   filename="document_all.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: Accepted gdesklets-data 0.13.1 (all source)

[Colin Watson]

On Tue, Aug 26, 2003 at 04:38:51PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> On Tue, Aug 26, 2003 at 10:08:51AM -0400, christophe barbe wrote:
> > On Tue, Aug 26, 2003 at 02:23:56PM +0200, Sebastien Bacher wrote:
> > > Yes, gdesklets-data is a debian native package (ie: there is no upstream
> > > tarball corresponding to this archive).
> > 
> > Thanks for the explaination.
> > 
> > > -n version are revision on a same upstream tarball, but in this case we
> > >  don't have any .orig.tar.gz 
> > 
> > Is there something preventing the use of a .orig.tar.gz tarball. It
> > would be nice to see a .orig.tar.gz containing only upstream bits and
> > the debian stuff in the diff, for review purpose and for bandwith
> > saving.
> 
> Again. It's a debian _native_ package, there is no such thing as
> "upstream" in native packages.

That's an obviously circular argument. Why is it native if it wasn't
"written especially for Debian" (policy 3.2.1)?

-- 
Colin Watson  [EMAIL PROTECTED]

Re: galeon (not) in Debian stable

[Joe Drew]

On Tue, 2003-08-26 at 10:56, Jeff Waugh wrote:
> > Yes, perhaps you're right ... it's a different vision, but perhaps not
> > so bad ;-)
> 
> It's just a matter of grokking the direction, making sure you know what it
> means, and why we're doing it.

For those who don't quite agree with GNOME's direction, waiting is. Time
will bring fullness.

Thanks,

Joe, who drinks deeply of GNOME's direction

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. i 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Messenger : discutez en direct avec vos amis ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Search, le moteur de recherche qui pense comme vous ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Search, le moteur de recherche qui pense comme vous ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Messenger : discutez en direct avec vos amis ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any project to 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Messenger : discutez en direct avec vos amis ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any project to work in 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Search, le moteur de recherche qui pense comme vous ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Messenger : discutez en direct avec vos amis ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any project to work in class with my 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Messenger : discutez en direct avec vos amis ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any project to work in class with my students. 
>From: gleu <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] 
>Subject: Bienvenue sur traduc.lfs !! 
>Date: Tue, 26 Aug 2003 17:19:33 +0200 
> 
MSN Search, le moteur de recherche qui pense comme vous ! Cliquez-ici 

localisation français-espagnol

[Beatriz Sanchez]

Hi!
I am going to be teaching a class on localisation from FRENCH to SPANISH. I would like to know if you could assign me any little project to work in class with my students. If you don't work with French to Spanish localisation, could you please tell me where could I find proyects?.
Sincerely,
Beatriz Sánchez. MSN Search, le moteur de recherche qui pense comme vous ! Cliquez-ici 

binaries provided by multiple source packages

[Glenn McGrath]

The following is a list of packages whose names are inconsistent with
accepted behaviour (plz correct me if im wrong)

To my knowledge if a package is provided by multiple sources, then a
virtual package should be used.

Some packages only conflict on one architecture, im not sure if thats
acceptable or not. Some cases are just old source package that should
have been removed from the archive.


Binary  (source1 [arch], source2 [arch], )
==  ==
cupsomatic-ppd  (cupsomatic-ppd, foomatic-filters-ppds)
gtk2-engines-mist   (gnome-themes, gtk-mist-engine)
python-qt-dev   (python-qt2, python-qt3)
python-doc  (python1.5-doc, python2.3)

flydraw (wims, flydraw)
texgd   (wims, texgd)

apache-perl (apache, apache-perl)
libapache-mod-perl  (apache, libapache-mod-perl)

protoize(gcc-3.0, gcc-3.2, gcc-3.3)
libgcc1 (gcc-3.0, gcc-3.2, gcc-3.3)
fastjar (gcc-3.0, gcc-3.2, gcc-3.3)
libffi-dev  (gcc-3.0, gcc-3.2, gcc-3.3)
libobjc1(gcc-3.0, gcc-3.2, gcc-3.3)
libffi  (gcc-3.0, gcc-3.2, gcc-3.3)
fixincludes (gcc-3.0, gcc-3.2, gcc-3.3)
libg2c0 (gcc-3.2, gcc-3.3)
libstdc++5  (gcc-3.2, gcc-3.3)
libgcj-common   (gcc-3.2, gcc-3.3)

gimp1.2 (gimp, gimp1.2)
libgimp1.2  (gimp, gimp1.2)
libgimp1.2-dev  (gimp, gimp1.2)
gimp1.2-perl(gimp, gimp1.2)

libstdc++2.10-glibc2.2  (gcc-2.95 arch=any, gcc-2.96 arch=ia64)
libstdc++2.10-dbg   (gcc-2.95 arch=any, gcc-2.96 arch=ia64)
libstdc++2.10-dev   (gcc-2.95 arch=any, gcc-2.96 arch=ia64)

kernel-headers-2.2.20   (kernel-patch-2.2.20-powerpc arch=any,
kernel-headers-2.2.20-m68k arch=m68k)
kernel-headers-2.2.25   (kernel-image-2.2.25-i386 arch=any,
kernel-image-2.2.25-alpha arch=alpha)
kernel-headers-2.4.19   (kernel-patch-2.4.19-mips arch=any,
kernel-patch-2.4.19-powerpc arch=any, 
kernel-image-2.4.19-arm
arch=arm, kernel-image-2.4.19-s390 arch=s390)

Re: Snort: Mass Bug Closing

[Marc Haber]

On Tue, 26 Aug 2003 16:10:36 +0200, Andreas Barth
<[EMAIL PROTECTED]> wrote:
>* Marc Haber ([EMAIL PROTECTED]) [030826 16:05]:
>> And daily, untested packages are built automatically on gluck and are
>> aptable from
>> 
>> deb http://people.debian.org/~zugschlus/clamav-data/ /
>
>Add a debconf-question about adding this to sources.list?

NACK. That would be interfering with somebody else's conffiles, and if
packages can that easily be apted, people should use freshclam.

Greetings
Marc

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

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

[Anthony Towns]

On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> Let's say i do translataion work, for that i have to build the package,
> and notice that it FTBFS (at least on some obscure arch or something). I
> then fill a FTBFS bug report, thus liberating me of the responsability
> you want to trust on me, and then NMU the translation improved package.

Uh, no. If it liberates you of anything, it'll likely be your ability to
do any more NMUs.

If the package is less useful to people after you do the NMU than before
you started looking at it, that's a problem. If it was formerly able
to be run by everyone no matter which architecture, and now no longer
works on alpha, that's a problem.

> And then, how can the NMUer in this case be responsible for some poorly
> maintained package to FTBFS ? just because he happened to do some
> translation work for it ?

If you NMU a package you need to take responsibility for making that
package work. If you don't want to do that, don't NMU, just submit a patch
instead. If the patch doesn't go in for weeks or years, that's too bad;
that's the difference between doing QA work -- making NMUs and taking
responsibility for your uploads -- and submitting useful feature requests.

> Or are we going to get afraid of making bugfixes or something because a
> given unmaintained package possibly might FTBFS, and we will not trigger
> it. 

You shouldn't be afraid of bugs, you should fix them.

It's really that simple.

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


pgp9pTek4jDgu.pgp
Description: PGP signature

Re: maintaining upstream snapshot package (was: Bits from the RM)

[Anthony Towns]

On Tue, Aug 26, 2003 at 10:14:51AM +0200, Sven Luther wrote:
> Hah, and Mark Howard wants to remove galeon 1.3 from unstable since it
> is only a cvs snapshot because of what you said. I think maybe you want
> to clarify a bit more the experimental use and cvs snapshot thingy.

It's entirely appropriate for the maintainer to be making these decisions.

(Although downgrading galeon.deb from 1.3 to 1.2 or similar in unstable
would be awkward to manage well, involving epochs and probably some
dependency nastiness.)

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


pgpcSBliJ4d9K.pgp
Description: PGP signature

Re: Approved

[support]

Please visit http://www.razorsearch.com/help.html for our online
support center. We are open 24 hrs a day to serve you.

Thank you,

Razor Search Team

---
*** AUTOMATIC RESPONSE ***
  You will receive this message every time you send mail to this address.
---

Re: Snort: Mass Bug Closing

[Thomas Viehmann]

Andreas Barth wrote:
> * Marc Haber ([EMAIL PROTECTED]) [030826 16:05]:
>>deb http://people.debian.org/~zugschlus/clamav-data/ /
> Add a debconf-question about adding this to sources.list?
Maybe README.Debian is better. In addition one might add a reference to
README.Debian to error messages complaining about missing / outdated data.

IMHO, having random packages tinker with the apt sources is a very bad idea.

Cheers

T.


pgpsrgqajmtf8.pgp
Description: PGP signature

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

[Mark Howard]

On Tue, Aug 26, 2003 at 03:46:33PM +0200, Andreas Barth wrote:
> the system. (And, I don't believe that a proposal with so many changes
> to the pool and mirror system has a real chance to be implemented.)

Why do you need many changes?
All the packages could go in the pool and you'd just need a few extra
Packages and Release files for the new experimental sections.

The difficult bit would be creating new upload areas and autobuilds. 
The autobuilds should not be a complicated as some people on this list
seem to think - all that is needed is another chroot for each
experimental section. 
Automatic builds are essential for two reasons:
- making sure the package works on all architectures (otherwise it may
  be in sid for a long time holding up testing)
- encouraging testers (aka developers) to use experimental. If people
  don't use it then it isn't all that useful.

I don't think I like the idea of automatic propagation from experimental
to sid as suggested in some replies - it's easy enough for package
maintainers to upload/copy to sid when the time is right. They are the
people who can judge this timing the best.

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

Re: 0 RC bugs == releasable quality?

[Branden Robinson]

On Tue, Aug 26, 2003 at 02:57:10PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 01:48:20AM +0300, Richard Braakman wrote:
> > 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.
> 
> Hrm. I guess that theory doesn't scale up beyond the package level...

It doesn't even scale up to XFree86.  *Every time* someone talks to me
in person about XFree86, I expect they want my help with a problem, or
they want to complain.

The exceptions, comprising about 10% of personal feedback, are:
1) "Why isn't XFree86 4.3.0 in woody?"
2) questions about what I think about the flamewar of the day (Keith
   Packard, Xouvert, etc.)
3) "Good job!" (okay, okay, I admit, this only about 0.0001% of all
   feedback)

-- 
G. Branden Robinson| There's nothing an agnostic can't
Debian GNU/Linux   | do if he doesn't know whether he
[EMAIL PROTECTED] | believes in it or not.
http://people.debian.org/~branden/ | -- Graham Chapman


pgpscZ4pkAxBz.pgp
Description: PGP signature

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

[Goswin von Brederlow]

Mark Howard <[EMAIL PROTECTED]> writes:

> On Tue, Aug 26, 2003 at 10:25:24AM +0200, Goswin von Brederlow wrote:
> > So speak up Mark, what do you mean with changed?
> 
> I meant identifying that bug X was fixed in version Y; packages in
> experimental contain the fix but sid and testing packages do not (yet).
> I think this feature would be even more useful when developers are
> fixing bugs reported by sid users and uploading to experimental.

A Tag "min-version=" and "fixed-version=" as extensions to
potato/woody/sarge/sid and have those 4 autochanged as versions move
around.

yep. would be nice. finer grained than just the tags.

MfG
Goswin

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

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow ([EMAIL PROTECTED]) [030826 15:20]:
> > Only those contained in the sections enabled on the users system. If
> > you have experimental-core and experimental-gnome all gnome debs
> > should be comnpiled against the experimental glibc for example.
> 
> This mass-introduces bugs reports of glibc-bugs to other packages. No,
> glibc (and the other core parts) must be the most conservative part of

If you are not able to test experimental-core packages properly (like
glibc) then don't have experimental-core activated on your client.

What I'm suposing is to use just those experimental sections activated
on the client.

> the system. (And, I don't believe that a proposal with so many changes
> to the pool and mirror system has a real chance to be implemented.)

The pool doesn't change at all. Its a change of the script generating
the Packages/Sources files (adding a few lines for the new files) and
a long needed fix for source-only uploads to the mirror maintanace
scripts.

Thats if you keep with building eperimental packages on the fly on the
client. If not you have a bunch of changes to the autobuilders.

Moving debs from experimental to sid can be done by uploading anew
package to sid instead of experimental just as it is now. No changed
needed there.

MfG
Goswin

learning to quote (was: NMUs applying sleeping ...)

[martin f krafft]

also sprach Sven Luther <[EMAIL PROTECTED]> [2003.08.26.1026 +0200]:
> On Tue, Aug 26, 2003 at 02:53:50PM +1000, Anthony Towns wrote:
> > On Mon, Aug 25, 2003 at 05:34:54PM +0200, Sven Luther wrote:
> > > 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.

http://www.uwasa.fi/~ts/http/quote.html

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


pgpzjCJm0myHS.pgp
Description: PGP signature

Re: localisation français-espagnol

[Simon Richter]

Hi,

first of all: Please don't post HTML to mailing lists. Apart from using
more bandwidth, your mail are more likely to be filtered by some
anti-spam or anti-virus software.

> I am going to be teaching a class on localisation from FRENCH to SPANISH. I
> would like to know if you could assign me any little project to work in class
> with my students. If you don't work with French to Spanish localisation, could
> you please tell me where could I find proyects?.

This is difficult, since most well-known projects use English as the
base language, as it has no accented characters and can thus be
displayed on about any system without problems. You may be lucky on
Freshmeat[0], but I think you might be better off using a fictional
project that shows the corner cases like exchanging two strings in a
translation, leading to better output in one case but ignoring others
(example is what I suspect in the German translation of gnupg):

"if no command was given, decrypt file","(default)"

became

"if no command was given", "decrypt file (default)"

because the German translation was longer than the original string and
the translator tried to keep the line length of all output below 80
chars. However, in a different menu, it now asks

"which trust level do you wish to assign?"
" 0 - i don't want to answer. " "decrypt file (default)"

which is obviously nonsensical.

If you don't find a French project on freshmeat, then I suggest you talk
to the French and Spanish language teams, which can be reached through
Linux International[1]'s web site and ask them for common pitfalls they
have encountered. Also, Kubota Tomohiro's guide[2] to i18n is definitely
worth reading.

HTH,
   Simon

[0] http://www.freshmeat.net/
[1] http://www.li.org/
[2] http://www.debian.org/doc/manuals/intro-i18n/

-- 
GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4


pgpa54qj6tPAL.pgp
Description: PGP signature

Re: binaries provided by multiple source packages

[Fabio Massimo Di Nitto]

On Wed, 27 Aug 2003, Glenn McGrath wrote:

> The following is a list of packages whose names are inconsistent with
> accepted behaviour (plz correct me if im wrong)

Sorry for my ignorance but which is the accepted behaviour? i couldn't
find anything in the policies and in devel-reference (just had a fast look
trough them)

> To my knowledge if a package is provided by multiple sources, then a
> virtual package should be used.

Why do i need a virtual package? and which one should be considering the
apache-perl case?

> apache-perl   (apache, apache-perl)
> libapache-mod-perl(apache, libapache-mod-perl)

wearing my apache maintainer hat, apache-perl needs libapache-mod-perl to
build and vice versa... shipping them togheter solves a lot of troubles..

Thanks
Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html

Re: maintaining upstream snapshot package (was: Bits from the RM)

[Sven Luther]

On Tue, Aug 26, 2003 at 07:22:14PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:14:51AM +0200, Sven Luther wrote:
> > Hah, and Mark Howard wants to remove galeon 1.3 from unstable since it
> > is only a cvs snapshot because of what you said. I think maybe you want
> > to clarify a bit more the experimental use and cvs snapshot thingy.
> 
> It's entirely appropriate for the maintainer to be making these decisions.

Sure, sure, if there is reason for it, but saying that :

  My next upload of galeon will be to the experimental branch of Debian
  as per the requests of the release manager. I will then request the
  removal of galeon packages from sarge and sid.

Seems to be overkill.

Also, as i understand it, uploading to experimental instead of stable
only really makes sense for a package that has a somewhat stable and
functional version in unstable, not to upload a package that people have
been using for ages from the archive entirely to keep only the
experimental version. I am sure this was not your intention as well, no ?

Friendly,

Sven Luther

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

[Sven Luther]

On Tue, Aug 26, 2003 at 07:28:03PM +1000, Anthony Towns wrote:
> On Tue, Aug 26, 2003 at 10:26:32AM +0200, Sven Luther wrote:
> > Let's say i do translataion work, for that i have to build the package,
> > and notice that it FTBFS (at least on some obscure arch or something). I
> > then fill a FTBFS bug report, thus liberating me of the responsability
> > you want to trust on me, and then NMU the translation improved package.
> 
> Uh, no. If it liberates you of anything, it'll likely be your ability to
> do any more NMUs.
> 
> If the package is less useful to people after you do the NMU than before
> you started looking at it, that's a problem. If it was formerly able
> to be run by everyone no matter which architecture, and now no longer
> works on alpha, that's a problem.

And you don't care that it FTBFS ? If it FTBFS, then the package is
broken, and knowing this is better than not knowing this. and how in
hell can this be the responsability of the NMUer, if it FTBFS even
before he touched the package.

I agree if the FTBFS comes from something the NMUer did, then yes, it is
broken, but if it comes from general bad shape of the packages, then the
responsability is to the package maintainer, and failing that (if he is
MIA or otherwise unresponsive) the responsability of the QA team or the
debian devels in general, not particularly the translators.

Friendly,

Sven Luther

DebToo: Debian, Gentoo-style

[Chris de Vidal]

Volunteers needed!
http://debtoo.org


=
/dev/idal
"GNU/Linux is free freedom" --Me

__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: Accepted gdesklets-data 0.13.1 (all source)

[christophe barbe]

On Tue, Aug 26, 2003 at 04:38:51PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote:
> > Is there something preventing the use of a .orig.tar.gz tarball. It
> > would be nice to see a .orig.tar.gz containing only upstream bits and
> > the debian stuff in the diff, for review purpose and for bandwith
> > saving.
> 
> Again. It's a debian _native_ package, there is no such thing as "upstream" 
> in native packages.

What makes it a native package? Or if you prefer, what prevent it of not
being a native package?

One of the inconvenient of the 'native' format used for a package made
of upstream tarballs is that it makes it difficult to review (and also
waste some bandwith). 
In this particular case, the diff.gz could certainly contains only the
debian directory. But I agree that the tarball will be custom made for
debian.

Christophe

-- 
Christophe Barbé <[EMAIL PROTECTED]>
GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8  F67A 8F45 2F1E D72C B41E

In theory there is no difference between theory and practice. In
practice there is. -- Yogi Berra 

Urgent coreutils/libc6? problem

[Jørgen Hermanrud Fjeld]

Hi.
I really need some help to solve this, and I'm writing to devel because i
hope some developer have might have a good idea how to solve it.

On one of my Debian servers, commands using gid hangs forever:
##
touch /tmp/aFile
chgrp 100 /tmp/aFile
# Typed ctrl-c to abort

However using group name seems to work fine
#
chgrp users /tmp/aFile
# 

The machine have same version as other servers that work correctly
ii  coreutils  5.0.90-2   The GNU core utilities
ii  libc6  2.3.2-3GNU C Library: Shared libraries and Timezone

Doing a strace of chgrp it seems the file "/etc/group" is read over and over
again, thus the following is repeated until i ctl-c the program.
#
open("/etc/group", O_RDONLY)= 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=4060, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x40014000
read(3, "root:x:0:\ndaemon:x:1:\nbin:x:2:\ns"..., 4096) = 4060
read(3, "", 4096)   = 0
close(3)= 0
munmap(0x40014000, 4096)= 0
open("/etc/group", O_RDONLY)= 3
fcntl64(3, F_GETFD) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
_llseek(3, 0, [0], SEEK_CUR)= 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=4060, ...}) = 0
mmap2(NULL, 4060, PROT_READ, MAP_SHARED, 3, 0) = 0x40014000
_llseek(3, 4060, [4060], SEEK_SET)  = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=4060, ...}) = 0
munmap(0x40014000, 4060)= 0
close(3) 
#

I have checked /etc/group with grpck, without any complaints.

I have looked at the BTS on both libc6 and coreutils, without finding
anything relevant.

I have googled, but my keywords may not have been the best, as I can't
pinpoint the error.

I wrote a c test program that uses the "getgrgid" and "getgrent", and it
runs perfectly.

Thus it seems that libc6 is not to blame, and coreutils is the same version
as on other machines where it works.

Now I don't really know how to proceed, any suggestions would be very
welcome. 

This is quite important, as webmin uses chown with uid:gid argument, and
when this hangs webmin no longer allow user modification.

Thank you very much for any help.
Sincerely 
Jørgen

Re: ITA freedict

[Bob Hilliard]

Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
> the name of the locale you generate, you should get what you want
> without being root.  Something like this (mostly cut-n-paste from d-i
> build system):
>
>   # The variables
>   LOCALE_PATH=/tmp/usr/lib/locale
>   LOCALE_NAME=en_IN
>   LOCALE_CHARSET=UTF-8
>
>   # Generating the locale
>   mkdir -p $LOCALE_PATH
>   localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \
>  "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"
>
>   # Using the locale
>   LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

Steve Langasek <[EMAIL PROTECTED]> added:

> Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET"
> instead, but otherwise, I've confirmed that this works.

 I need to use this locale as a command line argument to dictfmt
--locale.  dictfmt calls this locale with setlocale(3).  I have tried
--locale $(LOCALE_NAME).$(LOCALE_CHARSET) and --locale
$(LOCPATH)/$(LOCALE_NAME).$(LOCALE_CHARSET).  Both return invalid
locale, which is the error message dictfmt emits when it cannot open
the specified locale file.  The locale _is_ generated in
$LOCALE_PATH.

 Is the environment variable LOCPATH used by setlocale(3)?

 Can anyone suggest what I need to try to make this work?

Regards,

Bob
-- 
   _
  |_)  _  |_Robert D. Hilliard<[EMAIL PROTECTED]>
  |_) (_) |_)   1294 S.W. Seagull Way <[EMAIL PROTECTED]>
Palm City, FL 34990 USA   GPG Key ID: 390D6559 

Bug#207415: apt-listbugs usage against master

[Adam Heath]

Package: apt-listbugs
Severity: critical

On Tue, 26 Aug 2003, Adam Heath wrote:

> I was noticing increased load on master.  While trying to track that down, I
> noticed a large percentage of requests(48k of 116k) from something called
> apt-listbugs.
>
> It appears the maintainer has exported the entire spool/db-h, as
> ~taru/public_html/apt-listbugs/db-h.  I'm only seeing requests for .status,
> and a few index files, but I was rather surprised to see such a high
> percentage.
>
> Is it possible we can come up with a better way of doing this?
>
> ps: I don't think apt-listbugs is causing increased cpu load, unless by
> allowing users to see bugs, it lets them launch their browser, to see the
> actual page.

Ok, I was wrong.  It is causing increased load.  The 48k lines above is *just*
for *.status, and a few index files.  It does *not* include any cgi requests,
as those are done by way of querybts.

Because of the way the actual bug reports are queried, it's not possible to
block the requests for the cgis.  However, I am going to be blocking requests
for the .status files, which should solve the problem.

This increased load(both bw and cpu) started a week ago.  It is even heavier
today, most likely because it may have recently entered testing.

ps: this bug is critical, as it is causing a minor DoS against master.

Re: DebToo: Debian, Gentoo-style

[Diego Calleja García]

El Tue, 26 Aug 2003 13:14:41 -0700 (PDT) Chris de Vidal <[EMAIL PROTECTED]> 
escribió:

> Volunteers needed!
> http://debtoo.org

are you going to implement a USE flag equivalent?
(note: I don't like USE a lot)

ITP: hypre high performance preconditioners

[Adam C Powell IV]

Package: wnpp
Severity: wishlist

I intend to package hypre, which is "scalable software for solving
large, sparse linear systems of equations on massively parallel
computers".  It provides high-performance matrix preconditioners toward
that end, and can be linked with other software such as PETSc and
Illuminator for parallel computation of the linear equations, solution,
visualization, etc.  It is written by a team at Lawrence Livermore
National Laboratories.

Unfortunately, the license includes a "No commercialization" clause,
which makes it very much non-free.  I have contacted the upstream
authors to request explicit permission to redistribute it, and also to
ask that they consider relicensing under a free license.  (Incidentally,
the Babel project, also written at LLNL, switched from a similar "no
commercialization" license to LGPL, and my request to them for free
licensing apparently carried some weight in their case to management.)

When I receive this permission, I will upload hypre packaging, with the
contents of both the COPYRIGHT_and_DISCLAIMER file below and their
authorization email in the debian/copyright file.

Upstream COPYRIGHT_and_DISCLAIMER:

NOTICE

This work was produced at the University of California, Lawrence
Livermore National Laboratory (UC LLNL) under contract
no. W-7405-ENG-48 (Contract 48) between the U.S. Department of Energy
(DOE) and The Regents of the University of California (University) for
the operation of UC LLNL. The rights of the Federal Government are
reserved under Contract 48 subject to the restrictions agreed upon by
the DOE and University as allowed under DOE Acquisition Letter 97-1.

DISCLAIMER

This work was prepared as an account of work sponsored by an agency of
the United States Government. Neither the United States Government nor
the University of California nor any of their employees, makes any
warranty, express or implied, or assumes any liability or
responsibility for the accuracy, completeness, or usefulness of any
information, apparatus, product, or process disclosed, or represents
that its use would not infringe privately-owned rights.  Reference
herein to any specific commercial products, process, or service by
trade name, trademark, manufacturer or otherwise does not necessarily
constitute or imply its endorsement, recommendation, or favoring by
the United States Government or the University of California. The
views and opinions of authors expressed herein do not necessarily
state or reflect those of the United States Government or the
University of California, and shall not be used for advertising or
product endorsement purposes.

NOTIFICATION OF COMMERCIAL USE

Commercialization of this product is prohibited without notifying the
Department of Energy (DOE) or Lawrence Livermore National Laboratory
(LLNL).

Regards,
-- 
-Adam P.

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

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

Re: binaries provided by multiple source packages

[Brian May]

On Tue, Aug 26, 2003 at 08:38:12PM +0200, Fabio Massimo Di Nitto wrote:
> > apache-perl (apache, apache-perl)
> > libapache-mod-perl  (apache, libapache-mod-perl)
> 
> wearing my apache maintainer hat, apache-perl needs libapache-mod-perl to
> build and vice versa... shipping them togheter solves a lot of troubles..

If I got this correct:

Why do you need to have apache-perl getting built by both the
apache and apache-perl source code?

If it is meant to be getting built by the apache source code, then
there is no need for the apache-perl source package?

If is is meant to be getting built by the apache-perl source code, then
there is no need to build it again in the apache source package?

I am not sure if this breaks anything in policy, it would
just seem kind of weird having two source packages where only
one would seem to be appropriate.
-- 
Brian May <[EMAIL PROTECTED]>

Re: Accepted galeon 1.3.7.20030825-1 (i386 source)

[Joey Hess]

Mark Howard wrote:
>  galeon - GNOME web browser for advanced users
> Changes: 
>  galeon (1.3.7.20030825-1) experimental; urgency=low
>  .
>* New CVS Checkout
>* Moved to experimental - galeon is not yet stable enough for a Debian
>  stable release. Packages in sid and sarge will be removed soon.

Are you planning to not ship a galeon in sarge at all? Not even one of
the older, fairly stable ones?

The galeon shipped with woody was a complete POS WRT stability, but
surely there has been at least one release since then that is worth
shipping.

-- 
see shy jo


pgpdMoGPAN2p7.pgp
Description: PGP signature

Bug#207433: ITP: spinner -- Sends small packets over a idle link to keep it open

[Jesus Climent]

Package: wnpp
Version: N/A; reported 2003-08-27
Severity: wishlist

* Package name: spinner
  Version : 1.2.4
  Upstream Author : Joe Laffey <[EMAIL PROTECTED]>
* URL : http://www.laffeycomputer.com/spinner.html
* License : GPL
  Description : Sends small packets over a idle link to keep it open

 spinner sends small packets (null packets or a fancy ASCII spin
 fan with motion) to keep a link up.
 .
 It is the perfect application to keep alive a connection over
 routers which disconnect a link after some idle time.


-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux reypastor 2.4.21 #1 vie jun 13 22:28:10 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

-- 
Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69
--
 Registered Linux user #66350 proudly using Debian Sid & Linux 2.4.21

I say you are Lord, and I should know. I've followed a few.
--Arthur (Life of Brian)

Re: binaries provided by multiple source packages

[Glenn McGrath]

On Tue, 26 Aug 2003 20:38:12 +0200 (CEST)
Fabio Massimo Di Nitto <[EMAIL PROTECTED]> wrote:

> On Wed, 27 Aug 2003, Glenn McGrath wrote:
> 
> > The following is a list of packages whose names are inconsistent
> > with accepted behaviour (plz correct me if im wrong)
> 
> Sorry for my ignorance but which is the accepted behaviour? i couldn't
> find anything in the policies and in devel-reference (just had a fast
> look trough them)

Section 3.1
Every package must have a name that's unique within the Debian archive.
The package name is included in the control field Package, 

It is open to interpretation a little bit i guess, but as i see it

Every Package field in the Sources file must be unique to that file, and
every Package field in the Packages file must be unique to that file.

As it stands the apache-perl binary package (to pick on your case) could
be generated from two different source packages, only one binary will
ever be accepted as part of the binary release, if you try and insert a
second one the old binary will be thrown out.

Its hard for machines (autobuilders etc) to know which source the binary
really should be generated from.

Im not sure what should be done with regard to bootstapping apache.



Glenn

cpu usage, consideration of others, apt-listbugs

[Adam Heath]

I was looking at the various stats programs(http://master/mrtg/), and noticed
that for the last week, master's incoming bw, outgoing bw, and load, have been
unusually high.

After some digging, I found 2 main causes.

1: The apt-listbugs author has seemed it nescessary to export all debbugs
   data, by way of a symlink, and then to allow admins to request bug reports
   when packages get updated.  This was not done with any consultation with
   any BTS admin, nor any admin that is invovled in the machine that would be
   handling this increased load.

   A quick grep thru the access.log for the bts, shows 116k total lines, and
   48k lines are for apt-listbugs, requesting .status files, or the index
   files.

   What is not shown, is the requests for the actual bug reports.  These can't
   be easily tracked, as apt-listbugs uses querybts(from reportbug), and a few
   other fallbacks, so it's not easy to match up those lines.

   As such, I have used mod-rewrite to capture all requests that contain
   'apt-listbugs' in the User-Agent setting, and redirected them to a
   placeholder page, explaining the issue.

2: unrestricted, unlocked, cpu hogs

   I noticed at least one person on master running a spamassassin in his
   .procmailrc.  There was no lock file, which means multiple instances
   might(and actually did) run at once.  spamd/spamc wasn't being used, so
   there was even increased load.

   The BTS has run a local spamassassin for 6+ months now, but it was done
   correctly from the beginning: a spamd, running as the debbugs user, and a
   spamc that talked to it.  The spamc call was actually done in a shell
   script wrapper, that checked to see if spamd was running, and if not,
   restarted it.

   The BTS also serialized all spamc calls, so at most only one would ever be
   running.

master runs the bugs.debian.org, cgi.debian.org, and lists.debian.org(the web
archive, not the mail software).  The former are cpu intensive.  The latter
sometimes is, when a search is done.

Because of the above usage(not only the web pages, but the backend
scripts(index updaters, etc)), it is not best to run high-demand cpu
applications on that machine.

Please, be considerate of others who use the resources that are donated.
Please don't abuse.

Re: ITA freedict

[Steve Langasek]

On Tue, Aug 26, 2003 at 06:48:07PM -0400, Bob Hilliard wrote:
> Petter Reinholdtsen <[EMAIL PROTECTED]> writes:

> > If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to
> > the name of the locale you generate, you should get what you want
> > without being root.  Something like this (mostly cut-n-paste from d-i
> > build system):

> >   # The variables
> >   LOCALE_PATH=/tmp/usr/lib/locale
> >   LOCALE_NAME=en_IN
> >   LOCALE_CHARSET=UTF-8

> >   # Generating the locale
> >   mkdir -p $LOCALE_PATH
> >   localedef -i "$LOCALE_NAME.$LOCALE_CHARSET" -f "$LOCALE_CHARSET" \
> >  "$LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET"

> >   # Using the locale
> >   LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

> Steve Langasek <[EMAIL PROTECTED]> added:

> > Looks like this needs to be localedef -i "$LOCALE_NAME" -f "$LOCALE_CHARSET"
> > instead, but otherwise, I've confirmed that this works.

>  I need to use this locale as a command line argument to dictfmt
> --locale.  dictfmt calls this locale with setlocale(3).  I have tried
> --locale $(LOCALE_NAME).$(LOCALE_CHARSET) and --locale
> $(LOCPATH)/$(LOCALE_NAME).$(LOCALE_CHARSET).  Both return invalid
> locale, which is the error message dictfmt emits when it cannot open
> the specified locale file.  The locale _is_ generated in
> $LOCALE_PATH.

>  Is the environment variable LOCPATH used by setlocale(3)?

>  Can anyone suggest what I need to try to make this work?

LOCPATH=/tmp/usr/lib/locale dictfmt --locale ($LOCALE_NAME).$(LOCALE_CHARSET)
ought to have the desired effect.  All locale-related glibc functions
should respect the value of LOCPATH.

-- 
Steve Langasek
postmodern programmer


pgp7hEo6aPWUK.pgp
Description: PGP signature