Re: Failed build on mips target: need help

[Amit Shah]

On Monday 15 Dec 2003 07:21, Daniel Jacobowitz wrote:
> On Sun, Dec 14, 2003 at 08:43:53PM +0530, Amit Shah wrote:
> > Hi,
> >
> > I'm the maintainer of the libfilesys-smbclient-perl module. The mips
> > build fails with this error:
> >
> > dpkg-deb: building package `libfilesys-smbclient-perl' in
> > `../libfilesys-smbclient-perl_1.5-1_mipsel.deb'.
> >  dpkg-genchanges -B -mDebian/MIPSEL Build Daemon
> > <[EMAIL PROTECTED]> dpkg-genchanges: arch-specific upload - not
> > including arch-independent packages
> > dpkg-parsechangelog: error: cannot open debian/changelog to find format:
> > Permission denied
> > dpkg-genchanges: error: syntax error in parsed version of changelog at
> > line 0: empty file
> >
> > The entire log is here:
> > http://buildd.debian.org/fetch.php?&pkg=libfilesys-smbclient-perl&ver=1.5
> >-1&arch=mipsel&stamp=1071078382&file=log&as=raw
> >
> > What could be the error here? It seems to build fine on all other archs
> > other than mipsel and mips.
>
> This is normally a transient error; something got confused.

So will the buildd pick it up again, or something special needs to be done?

-- 
Amit Shah
http://amitshah.nav.to/

Re: Complaint

[Ingo Juergensmann]

On Mon, Dec 15, 2003 at 01:07:15AM +0100, Wouter Verhelst wrote:

> > Unless you are the local administrator of one of the build daemons, I
> > doubt you'd have seen any of his attempts at coordination.
> He is, and hasn't seen any such attempt. Nor have I, being the DD
> responsible for the buildd he's the local admin of.

Well, this shows one funny thing at least: some people start to argue (just
not to say "flame") even when they are knowing nothing about me, who I am,
what I´m doing or my knowledge at all. 

> (Not that I agree with Ingo that there's reason for complaints -at
> least, not yet- but that's a different matter entirely)

Yeah, I know that you´re a little more patient than me, but from the
response I got and the talks I´ve had after that post, I can state that I
can´t completely wrong with my complaint because I got quite as many "you´re
right, go ahead!" opinions as negative ones publicly in here. 
It´s even worse than I thought. Some DDs are thinking of retirement because
of these reasons (and others of course). And some NMs being in the queue to
become a DD are actually fearing negative effects on their application when
they would start to say their opinion publicly. :-(
But fear and angst are things that a dictorship is using to suppress their
people. Did I missed a turn around of Debian from being an open minded and
democratic effort to become some sort of dictatorshipment?
Being the only one who complains in public doesn´t mean that I´m wrong. It
shows only that noone else wants to have problems with the DAM, ftp-masters,
etc. or have already given up (frustrated).  

-- 
Ciao...  // 
  Ingo \X/

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Chris Cheney]

On Mon, Dec 15, 2003 at 01:54:13PM +0800, Cameron Patrick wrote:
> On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote:
> 
> | Only GNOME applications should be in the GNOME Applications menu.
> 
> Why?!

Yea, I thought that was somewhat odd. The only reason the non KDE items
are better integrated into the current KDE menu is due to technical
limitations. I expect to be able to do it better when KDE converts fully
to the standard (KDE 3.2) like Gnome currently has.

Chris


signature.asc
Description: Digital signature

Re: How to depend on Japanese fonts?

[Andrew Suffield]

On Sun, Dec 14, 2003 at 05:20:41PM -0800, Jim Gettys wrote:
> I'm afraid I have to educate you: the world has been changing
> out from under your feet.
> 
> Any current GTK+, Qt or Mozilla will typically use client side
> fonts, which make font servers moot; fonts must be installed in
> the file system visible to the application, not on a server someplace. 
> This is the Xft2/fontconfig stuff deploying.

I am so glad I don't use xft2 for anything.

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


signature.asc
Description: Digital signature

Re: Proposed change to debian release system

[Marc Haber]

On Sun, 14 Dec 2003 20:02:54 -0700, Joel Baker <[EMAIL PROTECTED]>
wrote:
>Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much
>more invasive than a dist-upgrade, every six months. This has largely to do
>with the fact that most upgrades are very smooth, and don't require, say, a
>complete reinstall.

Oddly enough, nobody at me ex-orkplace (having about 20 FreeBSD boxes
in productive use) dared to touch any of the BSD boxes. We had
productive Servers running FreeBSD 2.x, and I believe that this hasn't
changed.

>In this regard, Debian actually resembles the *BSDs much more closely than
>most other Linux distributions (and that isn't a bad thing).

NACK. Debian is much easier to upgrade since we keep older versions
around. Updating older FreeBSD base systems should work fine, but
compiling new ports is a nightmare if you can't step up one release at
a time. The only thing you can safely do is to build new systems and
slowly migrate. Debian is much better in that regard.

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: Services I'd like from auric

[Joerg Jaspert]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

>> There's the question of botched uploads.  I think we've all accidentally
>> botched an upload one time or another, and having access to auric means
>> we can fix it without having to call on the ftpmasters for help.
> It depends on whether the queue daemon allows overwriting existing files, I
> suppose.  There isn't much that you can't undo by overwriting or superseding
> an upload.

Just upload a signed .commands file to remove the broken upload. Doc is
in the README in the UploadQueue dir or maybe in Devel-Ref too.

-- 
bye Joerg
(13:24)  ist iptables eigentlich nur ein tool zum
verhindern von aussenkonnecti,erungen auf gewissen ports oder ist
iptables eine firewall?
(13:27)  ist ein packet filter
(13:27)  maxx: also der verhindert pings?

Re: Proposed change to debian release system

[Marc Haber]

On Sun, 14 Dec 2003 15:41:13 -0600, Chad Walstrom
<[EMAIL PROTECTED]> wrote:
>I like the "Debian is ready when it's ready" argument.  Two years
>between releases may be a bit long for my taste.  A year would be nice,
>and six months is highly optimistic.  Once debian-installer is polished,
>things should move quicker.

After taking a look at the RC bug count, I don't see debian-installer
holding up things at the moment.

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

[Ingo Juergensmann]

Ryan Murray said:
> On Sun, Dec 14, 2003 at 01:20:15PM +0100, Ingo Juergensmann wrote:
>> - James Troup wrote then (as a reply I think) on Thu, December 11, 2003
>> 19:34 a mail to m68k-build list to get a status about the m68k buildd
>> machines (new ssh key, kernel info, etc.). He then got answers he asked for.
> One person replied directly to me as was asked in the mail, others
> replied to the m68k-build list.  I was waiting for all of the
> responses before I started, and didn't check the list right away.

The mail said:
! For buildds, we're changing how that's handled on auric.  For now,
! please send Ryan and me the following info:

I don't want to nitpick, but the original mail doesn't imply for me sending
you both a *private* mail. You're both subscribed to the list and have asked
on the list. So, it's just obvious to answer via the list. Furthermore it's
quite common for m68k-build to answer with hitting the "g" key for a group
reply in mutt, which will result in a mail to the list and in a private mail.
Therefore I'm quite sure that James got more private answers than you, because
he was the author of the mail. Would you have contacted us directly on your
own, I'm sure you would have received all mails as well as a private copy

Re: Any Progress?

[Jamin W. Collins]

On Sun, Dec 14, 2003 at 10:43:02PM -0600, Chris Cheney wrote:
> 
> I haven't noticed it bouncing but it has yet to process the bug email
> I mentioned in my other post. Also, I have not heard back from anyone
> as to why that might have happened.  With the BTS being broken (or at
> least appears to be) working on packages becomes a lot more of a pita.
> You have to fix the bugs, close them, and then go back later and make
> sure they actually got closed, which isn't happening.

This seems to be hit and miss.  All the bugs I've recently update/closed
on my packages have processed fine.

-- 
Jamin W. Collins

Facts do not cease to exist because they are ignored. --Aldous Huxley,
"Proper Studies", 1927

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Thomas Viehmann]

>My point exactly, even though I tried to make it through irony.
Which enhances your point for those who understand but might get your voice 
ignored
for those who don't.
Maybe I'm just overcautious because I've just experienced a bad case of "vocal
minority (1.5%) get's their way because they're more vocal" this weekend.

Cheers

T.

Re: (last) Assurance measures: AMA (coping with the speed of OSS development)

[Javier Fernández-Sanguino Peña]

On Sun, Dec 14, 2003 at 11:21:20PM -0600, Graham Wilson wrote:
> On Sun, Dec 14, 2003 at 11:50:43PM +0100, Magosányi Árpád wrote:
> > I hope that at least some of you were listening. (First I thought
> > there would be some feedback, at least like "stop it, this is
> > boring!", or "why do you write to a mailing list which does not even
> > exists?".)
> 
> What was your intent in posting all of these messages?

He probably expects some discussion regarding Common Criteria requirements
and whether his assesment of Debian compliance is ok or not. I would 
appreciate such discussion too, btw, but I don't have time to contribute 
input to it atm.

Regards

Javi


signature.asc
Description: Digital signature

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Goswin von Brederlow]

David Weinehall <[EMAIL PROTECTED]> writes:

> On Sun, Dec 14, 2003 at 03:30:46PM +0100, Bernhard R. Link wrote:
> > * Bruno Rodrigues <[EMAIL PROTECTED]> [031213 19:50]:
> > > Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > > > Some packages have a useless and space wasting md5sums file inside the
> > > > package. Due to its uselessness the existance is rather a bug than its
> > > > omission.
> > > > 
> > > > Please close this bug, read the threads on debian-devel about this and
> > > > if you still want md5sum files help making actually usefull ones.
> > > 
> > > I guess he means md5sum for files inside package, as in:
> > 
> > I think Goswin knows what files are meant here. But I really do not
> > understand, why he is trolling against them. (Espcially with such
> > arguments, that I have an hard time to suppress my wish to use the 
> > same and requesting the removal of all .desktop files. ("I do not need
> > them, they are a waste of space and bandwidth and anyone using them is
> > stupid."))

The md5sum files inside the package as they are now can be generated
at install time by anyone who wishes to have them. Security wise they
are useless and for accidental corruption they are redundant (since
they can be generated at install time).

Thus they just waste space and bandwith.

MfG
Goswin

RE: Proposed change to debian release system

[Lucas Albers]

Sorry, you are correct.
I apologize for the error.

> Lucas, not only did you horribly misquote my statement as coming from
> Scott, but you also seem to not having read my mail thoroughly.  Nowhere
> did I suggest that installed packages stop working when "expired", did I?
> Please re-read my suggestion.

Re: Complaint

[Ryan Murray]

On Sun, Dec 14, 2003 at 01:20:15PM +0100, Ingo Juergensmann wrote:
> - James Troup wrote then (as a reply I think) on Thu, December 11, 2003
> 19:34 a mail to m68k-build list to get a status about the m68k buildd
> machines (new ssh key, kernel info, etc.). He then got answers he asked for. 

One person replied directly to me as was asked in the mail, others
replied to the m68k-build list.  I was waiting for all of the
responses before I started, and didn't check the list right away.

> - As http://buildd.debian.org/stats/graph-week-big.png shows, there are some
> archs already have a working wanna-build access since days, namely mips,
> mipsel and powerpc. 

Yes, these are the ones I was testing the new setup with.  I'm sorry if you
feel that this testing was some form of discrimination -- it's not.

I'm sorry for the delay in adding the keys to the new system as I
actually spent most of the weekend away from computers as a break.

-- 
Ryan Murray, Debian Developer ([EMAIL PROTECTED], [EMAIL PROTECTED])
The opinions expressed here are my own.


pgpQecpeVK33H.pgp
Description: PGP signature

Re: Complaint

[Ingo Juergensmann]

On Mon, Dec 15, 2003 at 10:00:22AM +0100, Sven Luther wrote:

> > Sure, people can be overloaded with work, being too busy to answer
> > immediatedly, but when this extends to a longer time or is the default
> Hell, when they have time to discuss the issue with third parties, then
> they also assuredly have time to send an explanatory mail to the
> concerned maintainer.

Well, what does it sound like to you when that´s not done? ;)

> And then, when the local root exploit was discovered, i was expected to
> let everything fall, and to have a fix and upload a powerpc kernel for
> stable, without much advance warning, which i did. I fear that the above
> will be the same. Months lost in passive boycott of the ftp-masters, and
> then it will be expected of me that i forgot everything, and pass all my
> time fixing what needs fixing a few days before the release or something
> such.

Yeah, funny situation, eh? When you want something they have no time, are
busy or just ignore you. When they want something from you, you have to
answer quick, polite and immediatedly. 

> And worse, because of this lousy behavior of the ftp-masters, i am not
> able to fix the local root exploit in the sid kernel, since they will
> anyway not be accepted in the archive if i upload them. So this
> inadmissible behavior is not only causing delay, but is also the cause
> of a security menace in debian.

Maybe the next compromise (on ppc then) will ring the bells on them? ;)

-- 
Ciao...  // 
  Ingo \X/

Re: Complaint

[Sven Luther]

On Sun, Dec 14, 2003 at 01:20:15PM +0100, Ingo Juergensmann wrote:
> This is an official complaint about the current buildd situation.
> 
> The situation:
> 
> - Wouter Verhelst wrote on Tue, December 9, 2003 18:40 to [EMAIL PROTECTED]
> and the m68k porters list at [EMAIL PROTECTED] to get information about
> the process of getting wanna-build access back. 
> 
> - James Troup wrote then (as a reply I think) on Thu, December 11, 2003
> 19:34 a mail to m68k-build list to get a status about the m68k buildd
> machines (new ssh key, kernel info, etc.). He then got answers he asked for. 
> 
> - As http://buildd.debian.org/stats/graph-week-big.png shows, there are some
> archs already have a working wanna-build access since days, namely mips,
> mipsel and powerpc. 
> 
> 
> I really feel discriminated by this situation. 
> It seems as if the archs that are managed by Ryan Murray are preferred in
> their restoring process whereas others doesn´t even get a status update when
> they don´t ask for information and even then, nothing really happens for
> days. 
> 
> I get the impression that there is some sort of a "Debian clan" that
> controls some important positions of the Debian project and that is
> protecting itself from being influence by the outside. This is my personal
> and subjective impression, although I know of other people who are sharing
> that impressions (in whole or in part). 
> I do hope that this is wrong.
> But I think that a better and more open way of communication between some
> Debian admins and users in a polite way would help. 
> 
> It´s simply impolite and embarrassing when you contact a person, who´s
> administrating some service, and you get *NO* reaction from that person. 

It is not impolite, it is rude. And also a hinderance to the proper
continued work of debian.

> Sure, people can be overloaded with work, being too busy to answer
> immediatedly, but when this extends to a longer time or is the default

Hell, when they have time to discuss the issue with third parties, then
they also assuredly have time to send an explanatory mail to the
concerned maintainer.

> behaviour they should consider to share his workload with other persons that
> would like to help. But when they refuses that help, something is seriously
> wrong and should be solved. 
> 
> This is not intended to be a flame or personal insult to anyone, but to be a
> complaint, because I´m really unsatisfied with the current (non-)information
> politic and the current buildd situation.  

Well, me to, i have a compliant.

I uploaded a new powerpc kernel package, with many new binary packages,
which allowed to boot on chrp, chrp-rs6k and prep, not only on pmac
hardware, and it has been sitting in limbo for 5  or 6 weeks now. Notice
that i am the powerpc kernel maintainer, but don't own a pmac, but only
a machine of chrp lineage. I have gotten no response to why my package
was still hold up in the NEW queue (for at least 2-3 weeks prior to the
intrusion, so the intrusion is no excuse), altough i know elmo commented
to joeyh about my package split negatively. I thus wrote a explanatory
mail to ftp-master, but got no response, also later other members of the
d-i powerpc team wrote to ftp-masters, but got no response, and i
personnally wrote to aj, in response to a letter concerning the release
schedule, and informed him that unless the ftp-master unblock the
powerpc kernel package, there is no way the powerpc arch can be ready
for release, but got no reply, and later, when i meet aj on irc, he
denied having had any knowledge of these mails i sent to him, which
makes me believe that ftp-masters forward all the incoming mail to
/dev/null or something such.

And then, when the local root exploit was discovered, i was expected to
let everything fall, and to have a fix and upload a powerpc kernel for
stable, without much advance warning, which i did. I fear that the above
will be the same. Months lost in passive boycott of the ftp-masters, and
then it will be expected of me that i forgot everything, and pass all my
time fixing what needs fixing a few days before the release or something
such.

And worse, because of this lousy behavior of the ftp-masters, i am not
able to fix the local root exploit in the sid kernel, since they will
anyway not be accepted in the archive if i upload them. So this
inadmissible behavior is not only causing delay, but is also the cause
of a security menace in debian.

Friendly,

Sven Luther

Re: Changes in formal naming for NetBSD porting effort(s)

[David Weinehall]

On Sun, Dec 14, 2003 at 08:47:28PM -0500, Jaldhar H. Vyas wrote:
> On Sun, 14 Dec 2003, Nathan Hawkins wrote:
> 
> > Your proposal would change that. I oppose it, and I would oppose it just
> > the same if you wanted to call them Loki, Kali or Hitler. (To pick a few
> > at random.) Using names of evil, real or imagined, is not something
> > that would be helpful to Debian. That kind of publicity we don't need.
> 
> Nathan,
> 
> I understand what you are trying to say but just fyi, there is nothing
> remotely evil about the Goddess Kali in Hinduism.

Loki isn't that evil either; he's just the god of mischief, hence more
of a prankster than anything else.  Anyway, the comparision of mythical
creatures with the frontal figure of one of the biggest mass murders of
all time is beyond absurd...

Of course, I don't really think we should merit religious nonsense with
the honour of giving name to the products of Debian labour anyway...
And if we do, let's choose one of the religions noone believes in...
Branden's second proposal of using something from Pratchett did have a
nice ring to it, and then there's always the valar.

Hmm, come to think of it, money is what most people worship nowadays, so
maybe Debian GNU/Pesetas, Debian GNU/Zloty, and Debian GNU/Yen?!  All
hail capitalism!  This would be quite fitting right now, since most of
the western world is celebrating capitalism's supremacy next week (of
course, some celebrate it religiously for historical reasons, but they
seem to be a minority nowadays...)


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

Re: Complaint

[Sven Luther]

On Sun, Dec 14, 2003 at 11:03:01AM -0500, Kyle McMartin wrote:
> On Sun, Dec 14, 2003 at 01:20:15PM +0100, Ingo Juergensmann wrote:
> > I get the impression that there is some sort of a "Debian clan" that
> > controls some important positions of the Debian project and that is
> > protecting itself from being influence by the outside. This is my personal
> 
> THERE IS NO CABAL!

Only people who show only contempt of their fellow debian devels.

Friendly,

Sven Luther

unsubscribe

[Nicolas Rueff]

-- 
  .,p**"*=b_   Nicolas Rueff
 ?P"  .__ `*b   Montbéliard  -  France
|P  .d?'`&, 9|   http://rueff.tuxfamily.org
M:  |}   |- H'   [EMAIL PROTECTED]
&|  `#?_._oH'   +33 6 77 64 44 80
`H.   "`"`'   GPG 0xDD44DAB4
 `#?.   ICQ 97700474
   `^~.

We are Penguin. Resistance is futile. You will be assimilated.


pgpYfjw4TFrAa.pgp
Description: PGP signature

Re: udev and /sys mounting [was: mounting tmpfs (and sysfs) defaultly in sarge?]

[Martin Pitt]

Hi!

On 2003-12-15 10:04 +0900, GOTO Masanori wrote:
> >From the view point of libc6 maintainer, it's no problem to merge /sys
> mount for /etc/init.d/devpts.sh.  The name of devpts.sh should be
> renamed to something, though.  And it can be also applied for /dev/shm
> tmpfs.

That sounds reasonable. I just don't wanted it in devpts.sh.

What about /etc/init.d/kernfs or mountkernfs?

> One remaining concern is: is it ok to create /sys and /dev/shm
> directory by glibc package?

I don't have neither the authority nor the experience to decide this
:-), but speaking as an user I would like that. Please just don't do
it when it already exists AND there are files in it (or sth different
than sysfs is mounted on it). Creating /dev/shm should be less
problematic.

Have a nice day!

Martin
-- 
Martin Pitt Debian GNU/Linux Developer
[EMAIL PROTECTED]  [EMAIL PROTECTED]
http://www.piware.de http://www.debian.org

Re: Any Progress?

[Dominique Devriese]

Jamin W Collins writes:

> On Sun, Dec 14, 2003 at 10:43:02PM -0600, Chris Cheney wrote:
>>
>> I haven't noticed it bouncing but it has yet to process the bug
>> email I mentioned in my other post. Also, I have not heard back
>> from anyone as to why that might have happened.  With the BTS being
>> broken (or at least appears to be) working on packages becomes a
>> lot more of a pita.  You have to fix the bugs, close them, and then
>> go back later and make sure they actually got closed, which isn't
>> happening.

> This seems to be hit and miss.  All the bugs I've recently
> update/closed on my packages have processed fine.

same here.

cheers
domi

Re: experimental codename

[Colin Watson]

On Mon, Dec 15, 2003 at 01:50:00AM +0100, Christoph Berg wrote:
> since we are discussing codenames for the Debian/*BSD OSs, I noticed
> that the "experimental" distribution doesn't have a codename yet, as
> unstable has with "Sid".

I think that's the way it should be. Experimental isn't a complete
distribution in the sense that the others are, so it doesn't really
deserve a codename.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Proposed change to debian release system

[Eric Dorland]

* Andrew Pollock ([EMAIL PROTECTED]) wrote:
> On Sat, Dec 13, 2003 at 03:20:27PM +, Scott Minns wrote:
> > Hiya all,
> > First of all let me introduce myself, my name is Scott Minns, i'm a 
> > debian user, not a developer.  That most likely makes you question why 
> > i'm using thins mailing list at all, let alone having the gall to 
> > propose altering a well established testing and release system.
> > 
> > Here is my proposal and I would like to hear your thoughts on it, In 
> > addition to the present releases- stable, testing and unstable. We add a 
> > release called current.
> 
> [snip]
> 
> What you propose is probably technically difficult to actually achieve, due
> to dependencies, and would, as has already been pointed out, effectively
> mean there are two "stable" distributions running around.
> 
> I've been musing over a proposal for a while, which your email makes me want
> to raise now...
> 
> I'd like to propose some changes to the stable release policy (ps it would
> be nice if the policy is linked from http://www.debian.org/releases/stable/).
> 
> I'd like for certain packages to be classed as "perishable", i.e. they
> become more or less useless with age. How packages should be classsed as
> such, I'm not 100% sure on yet (-devel+maintainer+SRM consenus, perhaps?),
> but to provide some examples:
> 
>   * spamassassin
>   * snort
> 
> could be considered perishable because their effectiveness is reduced over
> time. Such classed packages should be allowed to be updated in stable, I
> feel. Of course, it could be argued that any package is perishable, and thus
> this whole thing becomes a moot point...

We always have to be careful with things like that, since stable is
*stable*... it should not really change, except to address critical
issues. Not that I disagree with your proposal. I think that some
value in updating these packages, and for packages such as
spamassassin and snort the case could be made that updating them would
be security updates, particularly in the case of snort.

Also those two packages really contain rule sets that could be
packaged separately and updated, while leaving the core code
unchanged. That would probably be the least surprising thing, and the
least likely to cause bugs, but would still be a lot of work and 
testing.

Another package I think would be on the list might be gaim. If msn or
yahoo changes their protocol then it becomes rather broken. This one
would be very difficult to handle in most cases... new version could
introduce new bugs, and backports could be really tough.

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Re: Complaint

[Sven Luther]

On Mon, Dec 15, 2003 at 12:37:34AM +1100, Martin Michlmayr - Debian Project 
Leader wrote:
> * Ingo Juergensmann <[EMAIL PROTECTED]> [2003-12-14 13:20]:
> > - As http://buildd.debian.org/stats/graph-week-big.png shows, there
> > are some archs already have a working wanna-build access since days,
> > namely mips, mipsel and powerpc.
> 
> > I really feel discriminated by this situation.
> 
> And it's clearly an evil plot against you/m68k as can be seen in the
> graph above.  If I look at it, I see that most buildds are not
> working, with some exceptions.

A, ok, so the non acceptance of my new powerpc packages is an evil plot
to hinder the work on non pmac ppc support by debian :)))

Friendly,

Sven Luther

Re: Any Progress?

[Colin Watson]

On Sun, Dec 14, 2003 at 10:43:02PM -0600, Chris Cheney wrote:
> On Sun, Dec 14, 2003 at 12:12:29AM -0500, Clint Adams wrote:
> > > Can you supply some message-ids or subject lines or something so that we
> > > can investigate? master's e-mail doesn't appear to be generally broken.
> > > I wonder, though, if all five (!) MXs are doing the right thing.
> > 
> > I've had at least 5 BTS mails bounced back to me, and master continues
> > to reject with '451 rejected: temporarily unable to verify sender
> > address'.
> > 
> > I suspect that this message will never reach [EMAIL PROTECTED]
> 
> I haven't noticed it bouncing but it has yet to process the bug email I
> mentioned in my other post. Also, I have not heard back from anyone as
> to why that might have happened.

Clint's problem turned out to be due to an unreadable home directory on
master. Your case is different: it appears that the mail you reported
(<[EMAIL PROTECTED]>) was erroneously caught by our spam
filters. I've reinjected it by hand and the bugs are now closed.

Content analysis details:   (4.3 points, 4.0 required)

 pts rule name  description
 -- --
 4.3 SORTED_RECIPS  Recipient list is sorted by address

Note that this has nothing to do with the recent compromise. I've
dropped the SORTED_RECIPS score to 3.8 to try to reduce false positives
here; I hope that doesn't result in too much more mass spam.

> Add to that the fact that the developer.php summary page is still
> fubar, I think I'll take a vacation from Debian until things are back
> to normal.

I think things are fairly normal right now to be honest, but if you do
take a vacation at least please make sure somebody uploads kdebase. :)

I guess one of the QA group will have a look at developer.php soon.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: udev and /sys mounting [was: mounting tmpfs (and sysfs) defaultly in sarge?]

[Marco d'Itri]

On Dec 15, GOTO Masanori <[EMAIL PROTECTED]> wrote:

 >From the view point of libc6 maintainer, it's no problem to merge /sys
 >mount for /etc/init.d/devpts.sh.  The name of devpts.sh should be
 >renamed to something, though.  And it can be also applied for /dev/shm
 >tmpfs.
Another reason is that it may be needed to mount it much earlier than
devpts to allow udev and other programs to work.
OTOH, if an initramfs will be used sysfs will probably be mounted by the
early init script, so there are still open issues.
But I'd start with mounting sysfs at some early stage of the boot
process you consider appropriate, and deal later with possible changes.

 >One remaining concern is: is it ok to create /sys and /dev/shm
 >directory by glibc package?
Yes.

-- 
ciao, |
Marco | [3621 teZRSjrC8ZAgA]

Re: experimental codename

[Neil McGovern]

On Mon, Dec 15, 2003 at 02:46:27AM +0100, Rene Engelhard wrote:
> Christoph Berg wrote:
> > since we are discussing codenames for the Debian/*BSD OSs, I noticed
> > that the "experimental" distribution doesn't have a codename yet, as
> > unstable has with "Sid". I'd propose to call it "Scud", which is the
> > Name of Sid's dog (which broke toys even worse than Sid did ;-).
> 
> I think that although "Scud" looks nice in this context giving a
> codename to experimental is not something we have to do since
> experimental is not a full distribution -- it only contains packages and
> makes only sense with a "normal, codenamed" distro (sid) installed
> 

I like it too :)
Prehaps it could be used as a codename for the new unstable when Sarge
is released as stable?

Regards,
Neil McGovern
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?
gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5

Bug#224033: ITP: tamil-gtk2im -- Tamil input method for GTK-2

[Ganesan Rajagopal]

Package: wnpp
Severity: wishlist

* Package name: tamil-gtk2im
  Version : 06182003
  Upstream Author : Dinesh Nadarajah <[EMAIL PROTECTED]>
* URL : http://groups.yahoo.com/group/tamilinix/files/keyboard/
* License : BSD
  Description : Tamil input method for GTK-2

This package provides input methods for the Tamil Language for applications 
written with the GTK+ Graphical User Interface Library.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux andlx-anamika 2.6.0-test11 #1 Sat Nov 29 09:34:15 IST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Christoph Berg]

Re: Goswin von Brederlow in <[EMAIL PROTECTED]>
> The md5sum files inside the package as they are now can be generated
> at install time by anyone who wishes to have them. Security wise they
> are useless and for accidental corruption they are redundant (since
> they can be generated at install time).

They are not generated by apt/dpkg, so few people will actually build
them. Since accidental corruption only occurs accidentally, it would be
very convenient if the md5sums were already there if something crashes.
Besides that, if the md5sums are in the package, you can check whether
the installation went fine.

> Thus they just waste space and bandwith.

I don't see where a text file with one line per file installed wastes
more resources than {pick anything for a package you don't need, e.g.
95% of translated manpages, etc.}.

Christoph
-- 
Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/
Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944


signature.asc
Description: Digital signature

Re: Changes in formal naming for NetBSD porting effort(s)

[Steinar H. Gunderson]

[Whoops, didn't send to the list the first time :-)]

On Mon, Dec 15, 2003 at 03:03:48PM +1100, Russell Coker wrote:
> LSD is "lysergic acid diethylamide", that's three words and there are three 
> variants of BSD.  So the only question is which BSD gets which chemical term.

What about DragonflyBSD? :-) It's not given that there will be only three of
them forever.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: experimental codename

[Arnaud Vandyck]

Colin Watson <[EMAIL PROTECTED]> writes:

> On Mon, Dec 15, 2003 at 01:50:00AM +0100, Christoph Berg wrote:
>> since we are discussing codenames for the Debian/*BSD OSs, I noticed
>> that the "experimental" distribution doesn't have a codename yet, as
>> unstable has with "Sid".
>
> I think that's the way it should be. Experimental isn't a complete
> distribution in the sense that the others are, so it doesn't really
> deserve a codename.

Isn't it possible that `scud' (I like it too) or `experimental' to be a
complete distribution with exactly the same packages from unstable *but*
the experimental packages?

What I'm trying to explain is that I like the idea of an extra pool with
the buildd and bts but no automatic move to another pool. I think, DD
and people with chroot can point to this distribution to test things and
it could be a buffer for the new packages. You know, upload a package
and a library and have to wait because the library is not available and
so on... We put every new packages in `Scud' and when accepted, after
some test by others, we can safer move it to `Sid' with less delay.

I don't know if I'm clear, I don't know if I'm right... but I think a
(new) release organization is necessary... It's just a proposal ;)

Cheers,

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-



pgpRSU7H40AWi.pgp
Description: PGP signature

Re: Services I'd like from auric

[Josselin Mouette]

Le dim 14/12/2003 à 23:53, Brian May a écrit :
> Is it still possible to run madison to check what versions of a specific
> packages are available?
> 
> I am gussing this isn't possible, but I found it very useful.

This is the kind of services that should be available on the web. Making
the NEW queue available on the web just like incoming.d.o would also be
valuable.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: Changes in formal naming for NetBSD porting effort(s)

[David Palmer.]

On Mon, 2003-12-15 at 20:57, Steinar H. Gunderson wrote:
> [Whoops, didn't send to the list the first time :-)]
> 
> On Mon, Dec 15, 2003 at 03:03:48PM +1100, Russell Coker wrote:
> > LSD is "lysergic acid diethylamide", that's three words and there are three 
> > variants of BSD.  So the only question is which BSD gets which chemical 
> > term.
> 
> What about DragonflyBSD? :-) It's not given that there will be only three of
> them forever.
> 
Dragonfly is a developing fork of FreeBSD.
With the new development of Free, there has virtually been a fork of the
FreeBSD project. When Dragonfly matures, it will be a three way fork.
BSD land is getting to be quite complex these days.
Regards,

David.

Re: experimental codename

[Joel Baker]

On Mon, Dec 15, 2003 at 01:38:37PM +0100, Christoph Berg wrote:
> Re: Neil McGovern in <[EMAIL PROTECTED]>
> > I like it too :)
> 
> Thanks :)
> 
> > Prehaps it could be used as a codename for the new unstable when Sarge
> > is released as stable?
> 
> That's not the way it works; "Sid" is not "Sarge+1" but the never-to-be-
> released development version. Think of it as "version infinity".

"And Beyond!"

Sorry, it had to be said. I'll go back in my hole now.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/KLNetBSD(i386) porter : :' :
 `. `'
   `-


pgpm6og0gfCWW.pgp
Description: PGP signature

Re: Services I'd like from auric

[Josselin Mouette]

Le lun 15/12/2003 à 14:56, Colin Watson a écrit :
> > This is the kind of services that should be available on the web.
> > Making the NEW queue available on the web just like incoming.d.o would
> > also be valuable.
> 
> The NEW queue isn't exported for reasons of US crypto regulations. That
> said, I would have thought that a plain list of what's currently in NEW
> would be OK and useful.

As the files in queue/new already have permissions forbidding
unprivileged accounts to read anything but the .changes, exporting it as
is should be fine.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: [debian-devel] Re: (last) Assurance measures: AMA (coping with the speed of OSS development)

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Javier Fernández-Sanguino Pe?a a következőeket írta:
> On Sun, Dec 14, 2003 at 11:21:20PM -0600, Graham Wilson wrote:
> > On Sun, Dec 14, 2003 at 11:50:43PM +0100, Magosányi Árpád wrote:
> > What was your intent in posting all of these messages?
> 
> He probably expects some discussion regarding Common Criteria requirements
> and whether his assesment of Debian compliance is ok or not. I would 
> appreciate such discussion too, btw, but I don't have time to contribute 
> input to it atm.

Yes, that was it.

-- 
GNU GPL: csak tiszta forrásból

Re: Proposed change to debian release system

[Joel Baker]

On Mon, Dec 15, 2003 at 08:57:45AM +0100, Marc Haber wrote:
> On Sun, 14 Dec 2003 20:02:54 -0700, Joel Baker <[EMAIL PROTECTED]>
> wrote:
> >Oddly enough, most FreeBSD sysadmins don't appear to mind doing things much
> >more invasive than a dist-upgrade, every six months. This has largely to do
> >with the fact that most upgrades are very smooth, and don't require, say, a
> >complete reinstall.
> 
> Oddly enough, nobody at me ex-orkplace (having about 20 FreeBSD boxes
> in productive use) dared to touch any of the BSD boxes. We had
> productive Servers running FreeBSD 2.x, and I believe that this hasn't
> changed.

This isn't my experience, or that of any of the other FreeBSD admins I (yes,
know I do admin some FreeBSD boxes, for various reasons, even though n't my
it ispreferred platform in any sense).

> >In this regard, Debian actually resembles the *BSDs much more closely than
> >most other Linux distributions (and that isn't a bad thing).
> 
> NACK. Debian is much easier to upgrade since we keep older versions
> around. Updating older FreeBSD base systems should work fine, but
> compiling new ports is a nightmare if you can't step up one release at
> a time. The only thing you can safely do is to build new systems and
> slowly migrate. Debian is much better in that regard.

Mmmm. I rarely have problems with such, but I suppose I also don't, as a
rule, allow my systems to get terribly out of date. Though I have my doubts
as to how 'safe' trying to upgrade from Debian 1.0 (which I don't recall
the codename for, and I'm too lazy to go look it up) to Sarge would work
well, even with release-by-release upgrades.

Stipulated, it would be far more likely to work, because one can (at least,
in theory) find the entirety of the old releases, rather than just the
core. However, my point stands: most Linux releases - at least, those not
based on Debian's core - *don't support upgrading over a major version
change*. The BSDs do, and Debian does; thus, saying that Debian does so
better puts it on the far side of the BSDs from, say, RedHat.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/KLNetBSD(i386) porter : :' :
 `. `'
   `-


pgpCN0aWDtYW7.pgp
Description: PGP signature

Re: RFP: intellisense.vim - Intellisense for Vim

[Clement Hermann]

Martin Pitt wrote:
Hi Juhapekka, hi Debianers!
On 2003-12-05 19:34 +0200, Juhapekka Tolvanen wrote:
 

Package: wnpp
Severity: normal
   

I just corrected that to wishlist.
 

http://insenvim.sourceforge.net/front.php
   

I took at the sources. Did you try compiling them under Linux? Things
like '#include ', all these Win-looking base classes, the
dependency on MFC and the DLL stuff seem to make that pretty hard :-/.
There are not even Makefiles to give it a try.
Unless you managed to compile the stuff (it seems to be very
interesting), I suggest that you close this bug.
 

If I refer to the faq, They say they would be glad to port it for 
GNU/linux, but they need help for that.
I don't think it could even compile right now :
http://insenvim.sourceforge.net/vis_faq.htm#FAQ4

--
*Clément Hermann* - Administrateur systèmes et réseaux
*_Eolas _ : _Business & Decision 
_ à Grenoble.* tél 476 44 50 50, fax 
476 44 00 41
Business Intelligence, CRM et E-business (portails, hébergement, canal 
Internet)
/Maîtrisez vos campagnes e-mailing ? testez _Eolas. 
_*_Asp Mail II 
_ en ligne !*/

Re: experimental codename

[Christoph Berg]

Re: Neil McGovern in <[EMAIL PROTECTED]>
> I like it too :)

Thanks :)

> Prehaps it could be used as a codename for the new unstable when Sarge
> is released as stable?

That's not the way it works; "Sid" is not "Sarge+1" but the never-to-be-
released development version. Think of it as "version infinity".

Christoph
-- 
Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/
Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944


signature.asc
Description: Digital signature

Re: Proposed change to debian release system

[Chad Walstrom]

On Mon, Dec 15, 2003 at 08:55:03AM +0100, Marc Haber wrote:
> After taking a look at the RC bug count, I don't see debian-installer
> holding up things at the moment.

Never the less, it has been one of those "must do" items, one of the
milestones that needs to be reached before a release is even considered.

RC bugs continue to accumulate as long as people feel they have time to
fix them and as long as testing is unfrozen.  When the release manager
makes the announcement that a release is approaching, our attentions are
diverted from our own personal projects and packages to those that have
received less care.  The announcement for release preparation is made,
and the cry for help goes out.  Hopefully it is heard.

Organize some BSP's, people!  They are sorely needed.  We found out on
Saturday's Minneapolis BSP that many of the RC bugs were quick fixes.
The 0-day NMU is a blessing (personally, I think this should be a
365-day, full-time policy).  Let's take advantage of it.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgp0eyCRqtLk1.pgp
Description: PGP signature

Re: Services I'd like from auric

[Colin Watson]

On Mon, Dec 15, 2003 at 12:51:58PM +0100, Josselin Mouette wrote:
> Le dim 14/12/2003 à 23:53, Brian May a écrit :
> > Is it still possible to run madison to check what versions of a
> > specific packages are available?
> > 
> > I am gussing this isn't possible, but I found it very useful.
> 
> This is the kind of services that should be available on the web.
> Making the NEW queue available on the web just like incoming.d.o would
> also be valuable.

The NEW queue isn't exported for reasons of US crypto regulations. That
said, I would have thought that a plain list of what's currently in NEW
would be OK and useful.

-- 
Colin Watson  [EMAIL PROTECTED]

Bug#224047: general: The upgrade starts the postgresql even if runlevel settings say NO to postgresql

[Marko]

Package: general
Version: 20031213
Severity: critical

After running apt-get upgrade, here is what happens:


Setting up postgresql (7.2.1-2woody4) ...
Restarting PostgreSQL database: postmaster
No /usr/lib/postgresql/bin/postmaster found running; none killed.
Starting PostgreSQL postmaster.
pg_ctl: Another postmaster may be running.  Trying to start postmaster anyway.
postmaster successfully started
-END OF REPORT--

We have an additional runlevel /etc/rc7.d and there is postgresql script
marked as NO START, like: /etc/rc7.d/K20postgresql -> ../init.d/postgresql

Thus such daemons should not start. But the upgrade scripts of a daemon
forces it to start, which we consider not OK for our systems. I can immagine
that the same happens with other daemons as well.

We have additional runlevel, which is OK to have as far we know and runlevel 
says it is N 7.


-- System Information
Debian Release: 3.0
Kernel Version: Linux perlbroker.kosmos 2.2.19-udma100-ext3 #1 SMP Sat Oct 20 
18:53:37 CEST 2001 i486 unknown

Re: Changes in formal naming for NetBSD porting effort(s)

[Joel Baker]

As an aside, the questions that were sent to Mr. Mewburn have been
forwarded to the rest of TNF's Board, and scheduled for discussion on their
next conference call (in a couple of days). His personal reaction to the
thought of renaming the ports to 'codenames' was quite positive; in his
(personal) opinion, it would resolve pretty much the entire question.

We'll know in a few days whether the rest of the Board agrees with that
view, but for now, I would take it as a positive sign that this direction
is very likely to result in everyone (well, okay, as much of 'everyone' as
we can manage) being happy.

And now...

On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote:
> On Sun, Dec 14, 2003 at 08:47:28PM -0500, Jaldhar H. Vyas wrote:
> > On Sun, 14 Dec 2003, Nathan Hawkins wrote:
> > 
> > > Your proposal would change that. I oppose it, and I would oppose it just
> > > the same if you wanted to call them Loki, Kali or Hitler. (To pick a few
> > > at random.) Using names of evil, real or imagined, is not something
> > > that would be helpful to Debian. That kind of publicity we don't need.
> > 
> > Nathan,
> > 
> > I understand what you are trying to say but just fyi, there is nothing
> > remotely evil about the Goddess Kali in Hinduism.
> 
> Loki isn't that evil either; he's just the god of mischief, hence more
> of a prankster than anything else.  Anyway, the comparision of mythical
> creatures with the frontal figure of one of the biggest mass murders of
> all time is beyond absurd...

Debian Hitler, Debian Stalin, Debian Saddam (and, of course, Debian Bush,
Debian Clinton, Debian Blair, Debian Kohl... what, you thought I was naming
something other than political figures? :)

> Of course, I don't really think we should merit religious nonsense with
> the honour of giving name to the products of Debian labour anyway...
> And if we do, let's choose one of the religions noone believes in...
> Branden's second proposal of using something from Pratchett did have a
> nice ring to it, and then there's always the valar.

Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather
like the notion of using the Valar - they're fictional, and Tolkien's work
isn't yet out from under copyright, but they *are* reasonably well-known
(Okay, not as well as Pratchett, but better than Christian demonology),
and if we're liable to get in trouble over using just the names, we should
probably strongly reconsider our use of Toy Story character names for
tagging distributions...

Suppose it's time to dig out my reference books and see if I can come up
with a suitable set of names out of that mythos.

Besides, using Tolkien names is a long geek tradition.

> Hmm, come to think of it, money is what most people worship nowadays, so
> maybe Debian GNU/Pesetas, Debian GNU/Zloty, and Debian GNU/Yen?!  All
> hail capitalism!  This would be quite fitting right now, since most of
> the western world is celebrating capitalism's supremacy next week (of
> course, some celebrate it religiously for historical reasons, but they
> seem to be a minority nowadays...)

Amusing, but I don't think so. :)
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/KLNetBSD(i386) porter : :' :
 `. `'
   `-


pgpViLVUGLDbT.pgp
Description: PGP signature

Conflicting manpage for queue.3

[Matthew Wilcox]

[ As suggested by Policy 10.1 [1], I am forwarding this issue to
  debian-devel.  Please maintain the cc list in followups. ]

Recent versions of manpages-dev include a new manpage queue.3.  dqs has
been providing a manpage by this name for some time.  Therefore there
is a file conflict when attempting to install both.

manpages-dev is effectively a required package on any system where
people do development.  Its contents are part of every major Linux
distribution.  For us to rename the queue.3 manpage in manpages-dev would
be a negative user experience for people switching to Debian or using
a mixture of Debian and other non-Debian Linux systems.  Additionally,
dqs is non-free and therefore "not part of Debian".  It seems doubly
foolish for manpages-dev to rename its manpage.

I therefore submit that bugs #208294 and #211620 be reassigned to dqs
and merged with bug #213526.  In addition, I think dqs should probably
be added to the RFA: or O: list as it has had a release critical bug
open for 211 days as well as several easily-fixable bugs open for much
longer and no uploads since woody.


[1] 10.1 Binaries

Two different packages must not install programs with different
functionality but with the same filenames. (The case of two programs
having the same functionality but different implementations is handled via
"alternatives" or the "Conflicts" mechanism. See Maintainer Scripts,
Section 3.10 and Conflicting binary packages - Conflicts, Section
7.3 respectively.) If this case happens, one of the programs must be
renamed. The maintainers should report this to the debian-devel mailing
list and try to find a consensus about which program will have to be
renamed. If a consensus cannot be reached, both programs must be renamed.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: problem to unsubscribe

[Oliver Elphick]

On Sat, 2003-12-13 at 22:04, Arnaud Vandyck wrote:
> Hi all,
> 
> I read debian-devel via the newsgroup now (linux.debian.devel) and I'd
> like to unsubscribe to the list but I can't. I did receive the
> confirmation string and answer it but it seems that I still receive
> mails from the list (also for debian-mentors -
> linux.debian.devel.mentors).
> 
> I'd like to do it for every list but I can't unsubscribe. Is there a
> problem with the unsubscribe script?

Make sure you unsubscribe the correct email address; that is, the one to
which your list mails are addressed by the mailing list server.

It may sound obvious, but many people seem unable to understand it.

-- 
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "The fear of the LORD is the instruction of wisdom, and
  before honour is humility."  Proverbs 15:33 

Re: Conflicting manpage for queue.3

[Colin Watson]

On Mon, Dec 15, 2003 at 03:31:19PM +, Matthew Wilcox wrote:
> [ As suggested by Policy 10.1 [1], I am forwarding this issue to
>   debian-devel.  Please maintain the cc list in followups. ]
> 
> Recent versions of manpages-dev include a new manpage queue.3.  dqs has
> been providing a manpage by this name for some time.  Therefore there
> is a file conflict when attempting to install both.
> 
> manpages-dev is effectively a required package on any system where
> people do development.  Its contents are part of every major Linux
> distribution.  For us to rename the queue.3 manpage in manpages-dev would
> be a negative user experience for people switching to Debian or using
> a mixture of Debian and other non-Debian Linux systems.  Additionally,
> dqs is non-free and therefore "not part of Debian".  It seems doubly
> foolish for manpages-dev to rename its manpage.

I agree. There is a simple fix that can be applied to dqs with a minimum
of fuss: instead of calling its man page queue.3.gz, it can call it
queue.3dqs.gz (and similarly for the other overly-generally-named man
pages in that package, namely cache, list, and stack). 'man 3dqs queue'
or 'man -e dqs queue' will then show the version in dqs, and 'man -aw
queue' will list all pages with that name.

> [1] 10.1 Binaries
> 
> Two different packages must not install programs with different
> functionality but with the same filenames. (The case of two programs
> having the same functionality but different implementations is handled via
> "alternatives" or the "Conflicts" mechanism. See Maintainer Scripts,
> Section 3.10 and Conflicting binary packages - Conflicts, Section
> 7.3 respectively.) If this case happens, one of the programs must be
> renamed. The maintainers should report this to the debian-devel mailing
> list and try to find a consensus about which program will have to be
> renamed. If a consensus cannot be reached, both programs must be renamed.

Strictly this doesn't apply since 'queue' is not a binary, but obviously
file conflicts are bad anyway. Perhaps policy should have a similar
comment about manual pages containing a footnote documenting the
extension convention above.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: How to depend on Japanese fonts?

[Jim Gettys]

I'd quibble with both "new" and being associated with freedesktop.org;
the basic technology appeared in XFree86 4.2 and
before.

Xft2/fontconfig, the mature version of the technology that
will interoperate with all X servers, even those lacking
the Render extension, was first released something like 16 
months ago.

It does represent a major architectural shift in X; the reasons
for it are outlined in our Usenix paper.

- Jim

On Sun, 2003-12-14 at 19:52, Cameron Patrick wrote:
> On Sun, Dec 14, 2003 at 05:20:41PM -0800, Jim Gettys wrote:
> 
> | This is a fundamental change in X architecture, which has been
> | underway for over 18 months.
> 
> And it's strongly associated with freedesktop.org, which I'm sure will
> endear Andrew to the new method even more :-)
> 
> Cameron.
-- 
Jim Gettys <[EMAIL PROTECTED]>
HP Labs, Cambridge Research Laboratory

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Lucas Albers]

> Re: Goswin von Brederlow in <[EMAIL PROTECTED]>
Why not set it so they are generated when a package is created?
Am I understanding correctly?
And then they could b gpg signed by the developer???
This adds one more check to the security of the system.
I used debsums just a few days to determine if a package was corrupt,
quite useful.
Is this something that would require maintainers to rebuild their
packages, or could the build machines do it?
--Luke
>
> They are not generated by apt/dpkg, so few people will actually build
> them. Since accidental corruption only occurs accidentally, it would be
> very convenient if the md5sums were already there if something crashes.
> Besides that, if the md5sums are in the package, you can check whether
> the installation went fine.

>
> I don't see where a text file with one line per file installed wastes
> more resources than {pick anything for a package you don't need, e.g.
> 95% of translated manpages, etc.}.
>
> Christoph
> Christoph Berg <[EMAIL PROTECTED]>, http://www.df7cb.de/
> Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944
>

Re: experimental codename

[Graham Wilson]

On Mon, Dec 15, 2003 at 02:10:22PM +0100, Arnaud Vandyck wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > I think that's the way it should be. Experimental isn't a complete
> > distribution in the sense that the others are, so it doesn't really
> > deserve a codename.
> 
> Isn't it possible that `scud' (I like it too) or `experimental' to be a
> complete distribution with exactly the same packages from unstable *but*
> the experimental packages?
> 
> What I'm trying to explain is that I like the idea of an extra pool with
> the buildd and bts but no automatic move to another pool. I think, DD
> and people with chroot can point to this distribution to test things and
> it could be a buffer for the new packages.

If this would lead to more developers and beta-testers being able to use
experimental, then I think this would be a good idea. People might
upload there newer more in-development packages here first, instead of
to unstable.

Now that I think about it though, this is already possible. You can pin
all of experimental just as high as unstable in the APT preferences
file. I think the only difference now between your proposal and reality
is support from the buildd's (I believe experimental has fairly good
support in the BTS).

> We put every new packages in `Scud' and when accepted, after some test
> by others, we can safer move it to `Sid' with less delay.

Every new package, or every new upload? The former might be alright, but
the latter would make experimental to unstable what unstable is to
testing.

-- 
gram


signature.asc
Description: Digital signature

Re: experimental codename

[Michael Poole]

John Hasler writes:

> gram writes:
>> Every new package, or every new upload?
>
> Perhaps every upload to Unstable should go to Experimental as well unless
> Experimental already has a newer package (or the same one), but uploads to
> Experimental should go to Experimental only.  Nothing would ever move from
> Experimental to any other distribution automatically.

Why have this duplication?  At least for my limited use of the
experimental distribution, apt's normal preference behavior (prefer
unstable over experimental, but don't downgrade an installed package)
is useful and stays out of the way.  At least to me, "unstable" means
a set of generally useful packages and "experimental" means a set of
less stable packages useful if you want to beta-test future releases.

Michael Poole

Re: experimental codename

[John Hasler]

gram writes:
> Every new package, or every new upload?

Perhaps every upload to Unstable should go to Experimental as well unless
Experimental already has a newer package (or the same one), but uploads to
Experimental should go to Experimental only.  Nothing would ever move from
Experimental to any other distribution automatically.
-- 
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: experimental codename

[Arnaud Vandyck]

Michael Poole <[EMAIL PROTECTED]> writes:

> John Hasler writes:
>
>> gram writes:
>>> Every new package, or every new upload?
>>
>> Perhaps every upload to Unstable should go to Experimental as well unless
>> Experimental already has a newer package (or the same one), but uploads to
>> Experimental should go to Experimental only.  Nothing would ever move from
>> Experimental to any other distribution automatically.
>
> Why have this duplication?  At least for my limited use of the
> experimental distribution, apt's normal preference behavior (prefer
> unstable over experimental, but don't downgrade an installed package)
> is useful and stays out of the way.  At least to me, "unstable" means
> a set of generally useful packages and "experimental" means a set of
> less stable packages useful if you want to beta-test future releases.

Correct.

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-

Re: experimental codename

[Arnaud Vandyck]

Graham Wilson <[EMAIL PROTECTED]> writes:

> On Mon, Dec 15, 2003 at 02:10:22PM +0100, Arnaud Vandyck wrote:

[...]

>> What I'm trying to explain is that I like the idea of an extra pool
>> with the buildd and bts but no automatic move to another pool. I
>> think, DD and people with chroot can point to this distribution to
>> test things and it could be a buffer for the new packages.
>
> If this would lead to more developers and beta-testers being able to
> use experimental, then I think this would be a good idea. People might
> upload there newer more in-development packages here first, instead of
> to unstable.
>
> Now that I think about it though, this is already possible. You can
> pin all of experimental just as high as unstable in the APT
> preferences file. I think the only difference now between your
> proposal and reality is support from the buildd's (I believe
> experimental has fairly good support in the BTS).

Also, it's not the same url in the sources.list s/unstable/experimental/
it's a bit different and for different arches. What about the arches
`all'? Well, I'm maybe a particular case: powerpc + java ;) but it could
be the same with sparc + perl or else. Where can I have more information
about experimental?

>> We put every new packages in `Scud' and when accepted, after some
>> test by others, we can safer move it to `Sid' with less delay.
>
> Every new package, or every new upload? The former might be alright,
> but the latter would make experimental to unstable what unstable is to
> testing.

The first. As I explain in the begining of my mail, I don't want to
reproduce unstable -> testing because of the non automatic move from
`Scud' to `Sid'.

The main point for me is the buildd and experimental to be a copy *plus*
exception distribution (the plus exception are _the_ experimental
packages).

Hope to be clearer,

Cheers,

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-


pgpdGKAOGmMo1.pgp
Description: PGP signature

Re: Changes in formal naming for NetBSD porting effort(s)

[Joel Baker]

On Mon, Dec 15, 2003 at 08:15:04AM -0700, Joel Baker wrote:
> On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote:
> 
> > Of course, I don't really think we should merit religious nonsense with
> > the honour of giving name to the products of Debian labour anyway...
> > And if we do, let's choose one of the religions noone believes in...
> > Branden's second proposal of using something from Pratchett did have a
> > nice ring to it, and then there's always the valar.
> 
> Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather
> like the notion of using the Valar - they're fictional, and Tolkien's work
> isn't yet out from under copyright, but they *are* reasonably well-known
> (Okay, not as well as Pratchett, but better than Christian demonology),
> and if we're liable to get in trouble over using just the names, we should
> probably strongly reconsider our use of Toy Story character names for
> tagging distributions...
> 
> Suppose it's time to dig out my reference books and see if I can come up
> with a suitable set of names out of that mythos.
> 
> Besides, using Tolkien names is a long geek tradition.

Having cheated and grabbed an online resource for it from Google, the
following possibilities show up (my apologies for the lack of accents;
I can't easily input UTF-8 on this terminal):

FreeBSD:
  No primary Vala names begin with 'F', but many alternate names do, as do
  a great many other names of honor in the Tolkien mythos

NetBSD:
  Namo (Vala of destiny, prophecy, and the Halls of the Dead)
  Nessa (Valie of the woods)
  Nieliqui (daughter of Orome; see OpenBSD)
  Nienna (Valie of pity and lament; Gandalf/Mithrandir was one of her students)

OpenBSD:
  Omar (Vala of music)
  Orome (Vala of the hunt, teacher of elves)

This is by no means a complete list; it includes none of the Maiar, nor any
of the names of characters elevated from less powerful races. Personally,
while I can't speak for the FreeBSD or OpenBSD folks, I'd cast a vote for
Nienna, for the NetBSD port using kernel+libc; the name is one of the
better known ones, and is a far cry from anything remotely 'evil'.

It also leaves at least 3 other 'N' names available for the port currently
known as Debian GNU/KNetBSD.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/KLNetBSD(i386) porter : :' :
 `. `'
   `-


pgp2Vo5kv9oX4.pgp
Description: PGP signature

Re: Changes in formal naming for NetBSD porting effort(s)

[Nathan Hawkins]

On Mon, Dec 15, 2003 at 12:19:10PM -0700, Joel Baker wrote:
> On Mon, Dec 15, 2003 at 08:15:04AM -0700, Joel Baker wrote:
> > Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather
> > like the notion of using the Valar - they're fictional, and Tolkien's work
> > isn't yet out from under copyright, but they *are* reasonably well-known
> > (Okay, not as well as Pratchett, but better than Christian demonology),
> > and if we're liable to get in trouble over using just the names, we should
> > probably strongly reconsider our use of Toy Story character names for
> > tagging distributions...
> > 
> > Suppose it's time to dig out my reference books and see if I can come up
> > with a suitable set of names out of that mythos.
> > 
> > Besides, using Tolkien names is a long geek tradition.
> 
> Having cheated and grabbed an online resource for it from Google, the
> following possibilities show up (my apologies for the lack of accents;
> I can't easily input UTF-8 on this terminal):

You mean you had to look this up? ;-)

> FreeBSD:
>   No primary Vala names begin with 'F', but many alternate names do, as do
>   a great many other names of honor in the Tolkien mythos

There's no particular reason to stay with 'F'. We're already changing
the name beyond recognition. 'V' would be close enough, the phonetic
difference is small.

> NetBSD:
>   Namo (Vala of destiny, prophecy, and the Halls of the Dead)
>   Nessa (Valie of the woods)
>   Nieliqui (daughter of Orome; see OpenBSD)
>   Nienna (Valie of pity and lament; Gandalf/Mithrandir was one of her 
> students)
> 
> OpenBSD:
>   Omar (Vala of music)
>   Orome (Vala of the hunt, teacher of elves)

Last I heard there was no longer an OpenBSD port.

> This is by no means a complete list; it includes none of the Maiar, nor any
> of the names of characters elevated from less powerful races. Personally,
> while I can't speak for the FreeBSD or OpenBSD folks, I'd cast a vote for
> Nienna, for the NetBSD port using kernel+libc; the name is one of the
> better known ones, and is a far cry from anything remotely 'evil'.
> 
> It also leaves at least 3 other 'N' names available for the port currently
> known as Debian GNU/KNetBSD.

This is a solution I can live with. Just to clarify something, am I
correct in understanding that we're only being asked to change the
official name of the system, not what uname says or config.guess says?

Would TNF be ok with describing the system as "Debian GNU/Nienna, based
on the NetBSD(tm) kernel?" People will still need to know that the
system is based on NetBSD.

If we use different names for the libc vs glibc ports, we should
probably set the names for dpkg and apt to match. (i.e.  netbsd-i386 ->
nienna-i386.)

---Nathan

Re: Changes in formal naming for NetBSD porting effort(s)

[Joel Baker]

On Mon, Dec 15, 2003 at 03:09:07PM -0500, Nathan Hawkins wrote:
> On Mon, Dec 15, 2003 at 12:19:10PM -0700, Joel Baker wrote:
> > 
> > Having cheated and grabbed an online resource for it from Google, the
> > following possibilities show up (my apologies for the lack of accents;
> > I can't easily input UTF-8 on this terminal):
> 
> You mean you had to look this up? ;-)

I said I was a geek; I didn't say I had a good memory. :)

> > FreeBSD:
> >   No primary Vala names begin with 'F', but many alternate names do, as do
> >   a great many other names of honor in the Tolkien mythos
> 
> There's no particular reason to stay with 'F'. We're already changing
> the name beyond recognition. 'V' would be close enough, the phonetic
> difference is small.

True. I was mostly trying to stay along the lines of the origional
proposal, but I doubt that too many folks will object very heavily to
whatever the FreeBSD ports choose, since the primary mapping will be on a
webpage somewhere (like, the BSD ports page, I'd expect, at least once
the webpages are building again) anyway.

> > NetBSD:
> >   Namo (Vala of destiny, prophecy, and the Halls of the Dead)
> >   Nessa (Valie of the woods)
> >   Nieliqui (daughter of Orome; see OpenBSD)
> >   Nienna (Valie of pity and lament; Gandalf/Mithrandir was one of her 
> > students)
> > 
> > OpenBSD:
> >   Omar (Vala of music)
> >   Orome (Vala of the hunt, teacher of elves)
> 
> Last I heard there was no longer an OpenBSD port.

True; it was more for the sake of completeness.

> > This is by no means a complete list; it includes none of the Maiar, nor any
> > of the names of characters elevated from less powerful races. Personally,
> > while I can't speak for the FreeBSD or OpenBSD folks, I'd cast a vote for
> > Nienna, for the NetBSD port using kernel+libc; the name is one of the
> > better known ones, and is a far cry from anything remotely 'evil'.
> > 
> > It also leaves at least 3 other 'N' names available for the port currently
> > known as Debian GNU/KNetBSD.
> 
> This is a solution I can live with. Just to clarify something, am I
> correct in understanding that we're only being asked to change the
> official name of the system, not what uname says or config.guess says?

Correct, at least as far as I understand it. Certainly those fields are
a reflection of a technical statement roughly equivalent to "We use the
NetBSD kernel", which is a factual statement that wouldn't infringe on any
trademarks. I expect that they would expect them to be distinct, of course
(though the topic has never directly come up), but we already have that
(being a fundamental necessity).

It has been mentioned in the threads I pointed them at, so I expect that
if they care at all, we'll know about it by the end of the week. But the
*only* request they made was in regards to the official naming of the port
- not even the 'architecture' name. Though it might be vaguely entertaining
to have 'nienna-i386' someday. But I'll leave that for a later debate.

> Would TNF be ok with describing the system as "Debian GNU/Nienna, based
> on the NetBSD(tm) kernel?" People will still need to know that the
> system is based on NetBSD.

Except that that wouldn't be the correct statement, yes, every indication
is that it is fine to make factual statements such as this (the correct
statement would be "Debian Nienna, based on the NetBSD kernel and libc,
and a GNU userland").

This has the side effect of removing "GNU" from the name, just as "NetBSD"
is removed from it (and presumably, someday "Linux" may well be removed;
until then, of course, it would still be "Debian GNU/Linux"). Which isn't a
direct goal in any sense, but does allow us to also avoid the same question
of trademark issues with anyone else.

> If we use different names for the libc vs glibc ports, we should
> probably set the names for dpkg and apt to match. (i.e.  netbsd-i386 ->
> nienna-i386.)

As I noted above, this may not be unreasonable, but I'd like some feedback
from the general populance, the dpkg/apt maintainers, the ftpmasters, and
the leadership about whether this should be expected to eventually subsume
all port naming at some future point when it's reasonably convenient,
before we start asking for that. Even if the answer is "no", we should
spend some time figuring out just how far the name should extend, in
order to not completely confuse everyone.

(Disclaimer of ulterior motive: if it does subsume Linux naming, it would
mean that we'd have -i386 as the arch, and 'i386' would just be
a legacy pointer to it - something I'd like to see someday anyway :)
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/KLNetBSD(i386) porter : :' :
 `. `'
   `-


pgpT2CxhzkvMN.pgp
Description: PGP signature

Anon UploadQueue and command files

[Thorsten Sauter]

Hello all,

I have tried to upload a package with dupload to the anonymous ftp
uploadqueue on ftp-master. Unfortunately dupload fails to upload the
files.
ncftp /pub/UploadQueue > ls -l php*
-rw-r-S---1 2349 8020   Dez 15 18:24 
phpsysinfo_2.1-3.diff.gz

After this I have tried to remove the faulty file with a commands file
as described in the README file. The commands files is attached.

After processing the commands file I got the following error from katie:

katie> From: Archive Administrator <[EMAIL PROTECTED]>
katie> To: [EMAIL PROTECTED]
katie> Subject: Processing of phpsysinfo_2.1-3_i386.commands
katie> Delivery-date: Mon, 15 Dec 2003 19:06:48 +0100
katie> X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at resix.de
katie> 
katie> phpsysinfo_2.1-3_i386.commands isn't signed with PGP/GnuPG
katie> Removing phpsysinfo_2.1-3_i386.commands
katie> 
katie> Greetings,
katie> 
katie>  Your Debian queue daemon

As you can see, the commands file is signed with my gnupg key, which is
available in the debian keyring (no, the key is not one of the
compromised ones).

I have downloaded the debianqueued tarball from [1] and tried to
reproduce the problem localy. But the commands file will processed fine
here. I have found only those relevant lines in the tarball, which could
produce the error message above:
$ cat debianqueued
[...]
open( CHANGES, "<$changes" )
or die "Cannot open $changes: $!\n";
[...]
outer_loop: while(  ) {
if (/^---+(BEGIN|END) PGP .*---+$/) {
++$pgplines;
}
[...]
if ($pgplines < 3) {
msg( "log,mail", "$changes isn't signed with 
PGP/GnuPG\n" );
msg( "log", "(uploader $main::mail_addr)\n" );
goto remove_only_changes;
}
[...]


Is something wrong in my commands file? Or is this an known problem in
the uploadqueue on ftp-master?

Thanks for your help

Thorsten


p.s. Of course, I can also wait for the next regular 24h delete process


[1] ftp://ftp.debian.org/debian/project/misc/

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Uploader: Thorsten Sauter <[EMAIL PROTECTED]>
Commands:
 rm phpsysinfo_2.1-3.diff.gz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3OsVlJsl7AdEclIRAtqkAJ9Kv2wUFCAbyxgm1qTcqhUXwlEQIQCgg73b
pkOyUReo3y8hb2NBnraKVPA=
=4ngK
-END PGP SIGNATURE-


signature.asc
Description: Digital signature

Bug#223772: general: no md5sums for many packages (e.g. bc)

[werner . thoeni]

goswin,

> [EMAIL PROTECTED] writes:
> 
> > Subject: general: no md5sums for many packages (e.g. bc)
> > Package: general
> > Version: N/A; reported 2003-12-12
> > Severity: normal
> > Tags: security
> 
> Every package has a md5sum in the Package file.

the answer is not correct. pls see as an
example the package bc with version 1.06-8 or bzip2 version 1.0.2-1, 

> 
> Some packages have a useless and space wasting md5sums file inside
the
> package. Due to its uselessness the existance is rather a bug than
its
> omission.

i don't understand your comment above. why
is the md5sums file useless and space wasting especially in terms of security?
until now, I was of the opinion, that the md5sum gives me the guarantee
that a debian package is not penetrated before installation and further
- after having the packages installed on a machine - the md5sum files give
me the confidence that the debian binaries are correct and consistent.

> 
> Please close this bug, read the threads on debian-devel about this
and
> if you still want md5sum files help making actually usefull ones.
> 
> MfG
>         Goswin

expecting your answer.

Mit freundlichen Grüßen / Best regards 
Dipl.-Ing. Werner THÖNI 

Allgemeines Rechenzentrum GmbH 
Technischer Bereich 
Leiter Systemgruppe UNIX 

A-6020 Innsbruck, Tschamlerstraße 2 
Tel.: +43 / (0)50400-0 
Fax: +43 / (0)50400-1382 
e-Mail: [EMAIL PROTECTED]

http://www.arz.co.at

Re: experimental codename

[Graham Wilson]

On Mon, Dec 15, 2003 at 08:44:42PM +0100, Arnaud Vandyck wrote:
> Graham Wilson <[EMAIL PROTECTED]> writes:
> > If this would lead to more developers and beta-testers being able to
> > use experimental, then I think this would be a good idea. People might
> > upload there newer more in-development packages here first, instead of
> > to unstable.
> >
> > Now that I think about it though, this is already possible. You can
> > pin all of experimental just as high as unstable in the APT
> > preferences file. I think the only difference now between your
> > proposal and reality is support from the buildd's (I believe
> > experimental has fairly good support in the BTS).
> 
> Also, it's not the same url in the sources.list s/unstable/experimental/

Yes, I forgot this. But the potential users of experimental (developers)
will probably know how to handle there sources.list and preferences
files.

> it's a bit different and for different arches. What about the arches
> `all'? Well, I'm maybe a particular case: powerpc + java ;) but it could
> be the same with sparc + perl or else. Where can I have more information
> about experimental?

Hmm... I am not quite sure I understand you. Can you explain more?

> The main point for me is the buildd and experimental to be a copy *plus*
> exception distribution (the plus exception are _the_ experimental
> packages).

Yes, I think the buildd situation wrt experimental is a hindrance to
wider use of the experimental distribution.

However, I am not (nor do I believe a majority might be) that
experimental should duplicate unstable, with only a few packages (the
experimental ones) being newer. However, with the pool structure
archive, this might not actually mean a duplication of too much space.

But indeed, the same affect can be accomplished by using APT's
preferences file.

-- 
gram


signature.asc
Description: Digital signature

Re: Generating ~/.ssh/known_hosts from LDAP

[Clint Adams]

> I couldn't find any way to authenticate db.debian.org when using direct LDAP
> (TLS doesn't seem to be supported), but nonetheless this is damn convenient.
> 
> (requires python-ldap)

Or, for people who don't want python installed.
#!/bin/zsh
for i in ${(M)${(ps:\n\n:)${"$(ldapsearch -LLL -x -h db.debian.org -b 
dc=debian,dc=org -s sub objectClass=debianServer hostname 
sshRSAHostKey)"}}:#*sshRSAHostKey:*};
do
  for j in ${${(M)${(f)${i//
 /}}:#sshRSAHostKey: *}#sshRSAHostKey: };
  do
print ${(j:,:)${${(M)${(f)i}:#hostname: *}#hostname: }} $j
  done
done

Re: Changes in formal naming for NetBSD porting effort(s)

[Daniel Burrows]

On Sun, Dec 14, 2003 at 07:03:25PM -0500, Branden Robinson <[EMAIL PROTECTED]> 
was heard to say:
> [I am not subscribed to debian-bsd.]
> 
> On Sun, Dec 14, 2003 at 08:21:30PM +0100, Roland Mas wrote:
> >   I'll suggest Offler (or Om), Foorgol (I don't like Fate) and, um,
> > some other god coming out of Terry Pratchett's Discworld novels,
> > preferably whose name starts with an N.
> > 
> >   Or something like that.
> 
> Mr. Pratchett's attorneys might take exception to that.

  If that's a real concern, then Ogg Vorbis is in a lot of trouble. :)

  Daniel

-- 
/ Daniel Burrows <[EMAIL PROTECTED]> ---\
|Whom the gods would destroy, they first teach BASIC. |
\- Debian GNU/Linux http://www.debian.org -- Because. /

Bug#224081: ITP: ttf-tamil-fonts -- Free TrueType fonts for the Tamil language

[Ganesan Rajagopal]

Package: wnpp
Severity: wishlist

* Package name: ttf-tamil-fonts
  Version : 1.0.0
  Upstream Author : The Tamil Linux Project
* URL : http://www.tamilinux.org/
* License : GPL
  Description : Free TrueType fonts for the Tamil language

This is a set of OpenType fonts released under the GNU General Public 
License for the Tamil Language. 

For more information on the tamil language 
see http://en2.wikipedia.org/wiki/Tamil_language (This will not be 
in the long description, just a note for curious debian developers 
reading this ITP :-).

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux andlx-anamika 2.6.0-test11 #1 Sat Nov 29 09:34:15 IST 2003 i686
Locale: LANG=C, LC_CTYPE=C

Re: Proposed change to debian release system

[Andreas Rottmann]

Eric Dorland <[EMAIL PROTECTED]> writes:

>>  * spamassassin
>>  * snort
>> 
>> could be considered perishable because their effectiveness is reduced over
>> time. Such classed packages should be allowed to be updated in stable, I
>> feel. Of course, it could be argued that any package is perishable, and thus
>> this whole thing becomes a moot point...
>
> We always have to be careful with things like that, since stable is
> *stable*... it should not really change, except to address critical
> issues. Not that I disagree with your proposal. I think that some
> value in updating these packages, and for packages such as
> spamassassin and snort the case could be made that updating them would
> be security updates, particularly in the case of snort.
>
> Also those two packages really contain rule sets that could be
> packaged separately and updated, while leaving the core code
> unchanged. That would probably be the least surprising thing, and the
> least likely to cause bugs, but would still be a lot of work and 
> testing.
>
Perhaps the rule-sets could be handled outside of the debian package
system, like clamav does (clamav runs a daemon that fetches new
rulesets as they become availle on the Net).

Andy
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://yi.org/rotty  | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint  | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Packages should build-depend on what they should build-depend.

Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Scott James Remnant]

On Mon, 2003-12-15 at 05:54, Cameron Patrick wrote:

> On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote:
> 
> | Only GNOME applications should be in the GNOME Applications menu.
> 
> Why?!
> 
Rationale (and a real-world example):

Both KDE and GNOME are attempting to make a completely self-integrated
desktop environment, each have their own (often totally different)
interface guidelines as well as different look and feels.

Now, take a local library who have 20 machines all running Linux, with
user accounts available to all who want them.

The administrators can currently install both KDE and GNOME and allow
users to choose which they prefer, perhaps leaving GNOME as the default
due to its easier to use[0] interface.

When using GNOME they see only GNOME applications in the GNOME menu,
which is as it should be.  In fact, the GNOME menu is fairly tightly
controlled upstream to improve the ease of use.

When using KDE they only see KDE applications, again as it should be.

To cross-pollute the environments just creates a mess that won't buy you
any friends with the administrator or their users.  The applications
don't look the same and don't work the same, welcome to interface hell.

The current situation with "everything else" available on the Debian
menu works perfectly, each environment has their own menu with
everything else available if someone really wants to go looking for it. 
This can even be disabled.

By all means choose a different format for the menu entries, but don't
start sticking KDE applications in the GNOME menu, they aren't part of
that Desktop Environment.


Or a technical reason: starting a simple KDE application under GNOME
requires around 60MB of memory, as many of the KDE services need to be
started as well.  The reverse is (I imagine) equally true.


Don't cross-pollute the two desktop environments, they're fine as they
are.

Scott

[0] in the administrator's view, anyway
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?



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

Re: Any Progress?

[Chris Cheney]

On Mon, Dec 15, 2003 at 11:21:44AM +, Colin Watson wrote:
> On Sun, Dec 14, 2003 at 10:43:02PM -0600, Chris Cheney wrote:
> > On Sun, Dec 14, 2003 at 12:12:29AM -0500, Clint Adams wrote:
> > > > Can you supply some message-ids or subject lines or something so that we
> > > > can investigate? master's e-mail doesn't appear to be generally broken.
> > > > I wonder, though, if all five (!) MXs are doing the right thing.
> > > 
> > > I've had at least 5 BTS mails bounced back to me, and master continues
> > > to reject with '451 rejected: temporarily unable to verify sender
> > > address'.
> > > 
> > > I suspect that this message will never reach [EMAIL PROTECTED]
> > 
> > I haven't noticed it bouncing but it has yet to process the bug email I
> > mentioned in my other post. Also, I have not heard back from anyone as
> > to why that might have happened.
> 
> Clint's problem turned out to be due to an unreadable home directory on
> master. Your case is different: it appears that the mail you reported
> (<[EMAIL PROTECTED]>) was erroneously caught by our spam
> filters. I've reinjected it by hand and the bugs are now closed.
> 
> Content analysis details:   (4.3 points, 4.0 required)
> 
>  pts rule name  description
>  -- --
>  4.3 SORTED_RECIPS  Recipient list is sorted by address
> 
> Note that this has nothing to do with the recent compromise. I've
> dropped the SORTED_RECIPS score to 3.8 to try to reduce false positives
> here; I hope that doesn't result in too much more mass spam.

Thanks for the quick response and remedy.

> > Add to that the fact that the developer.php summary page is still
> > fubar, I think I'll take a vacation from Debian until things are back
> > to normal.
> 
> I think things are fairly normal right now to be honest, but if you do
> take a vacation at least please make sure somebody uploads kdebase. :)
> 
> I guess one of the QA group will have a look at developer.php soon.

I guess I can live without having up to date information on the qa page
for now, it does make life much easier though. Now that at the bug
reports aren't being lost anymore I can upload without having to
constantly double check myself. :)

Thanks!

Chris


signature.asc
Description: Digital signature

Re: experimental codename

[Arnaud Vandyck]

Graham Wilson <[EMAIL PROTECTED]> writes:

> On Mon, Dec 15, 2003 at 08:44:42PM +0100, Arnaud Vandyck wrote:

[...]

>> it's a bit different and for different arches. What about the arches
>> `all'? Well, I'm maybe a particular case: powerpc + java ;) but it
>> could be the same with sparc + perl or else. Where can I have more
>> information about experimental?
>
> Hmm... I am not quite sure I understand you. Can you explain more?

I don't know how to write a sources.list line for architecture `all'.

If I want to upload a java package in experimental (Architecture: all)
where and how do I do that? And if I want debian-java users to install
experimental packages, how do they have to write their apt/sources.list
line?

That was the 'question'.

>> The main point for me is the buildd and experimental to be a copy
>> *plus* exception distribution (the plus exception are _the_
>> experimental packages).
>
> Yes, I think the buildd situation wrt experimental is a hindrance to
> wider use of the experimental distribution.
>
> However, I am not (nor do I believe a majority might be) that
> experimental should duplicate unstable, with only a few packages (the
> experimental ones) being newer. However, with the pool structure
> archive, this might not actually mean a duplication of too much space.

Am I correct if I say that it will not take more place than now, but
only the Packages and Sources files will change?

> But indeed, the same affect can be accomplished by using APT's
> preferences file.

Yes, it's me not able to deal with the experimental apt/sources.list
configuration and not able to configure apt correctly. Is it only me or
maybe a better documentation about it could be a good thing?

Cheers,

-- 
  .''`. 
 : :' :rnaud
 `. `'  
   `-

Re: RFP: intellisense.vim - Intellisense for Vim

[Juhapekka Tolvanen]

On Mon, 15 Dec 2003, +00:45:17 EET (UTC +0200),
Martin Pitt <[EMAIL PROTECTED]> pressed some keys:

> On 2003-12-05 19:34 +0200, Juhapekka Tolvanen wrote:

> > Package: wnpp
> > Severity: normal

> > http://insenvim.sourceforge.net/front.php
> 
> I took at the sources. Did you try compiling them under Linux?

No. BTW their WWW-page has that link "Port to Linux":

http://insenvim.sourceforge.net/portlinux.htm

Behind that is just text: "We don't have for Linux, but want to port. It
may be tough, but any help is appreciated."


-- 
Juhapekka "naula" Tolvanen * http colon slash slash iki dot fi slash juhtolv
"Rakkaudesta ruikuttajat, halusta ulvojat kiertää kaupungin sydäntä vaanien
verta. Omiin synkkiin linnoihinsa vallitusten taa pelokkaammat piilee
hautomaan haamujaan."CMX

Re: Changes in formal naming for NetBSD porting effort(s)

[Roger Leigh]

Joel Baker <[EMAIL PROTECTED]> writes:

> On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote:
>> Branden's second proposal of using something from Pratchett did have a
>> nice ring to it, and then there's always the valar.
>
> Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather
> like the notion of using the Valar - they're fictional, and Tolkien's work
> isn't yet out from under copyright, but they *are* reasonably well-known
> (Okay, not as well as Pratchett, but better than Christian demonology),
> and if we're liable to get in trouble over using just the names, we should
> probably strongly reconsider our use of Toy Story character names for
> tagging distributions...
>
> Suppose it's time to dig out my reference books and see if I can come up
> with a suitable set of names out of that mythos.
>
> Besides, using Tolkien names is a long geek tradition.

Would "Debian AulÃ" be appropriate?

"Of the fabric of Earth had Aulà thought, to whom IlÃvatar had given
skill and knowledge scare less than to Melkor; but the delight and
pride of Aulà is in the deed of making, and in the thing made, and
neither in posession nor in his own mastery; wherefore he gives and
hoards not, and is free from care, passing ever on to some new work."

AinulindalÃ, J. R. R. Tolkien, /The Silmarillion/.


There are also important Elves, such as FÃanor that might also qualify.


However, there may well be copyright issues.  "Slink", "Woody",
"Potato" and "Bo" etc. aren't exactly unique, but you would be hard
pushed to find another book with "ManwÃ", "OromÃ", etc. in it.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: Changes in formal naming for NetBSD porting effort(s)

[Keegan Quinn]

On Mon, Dec 15, 2003 at 11:03:00PM +, Roger Leigh wrote:
> Demons are evil, and the BSD mascot is a demon (albeit a stylised
> one).  On the other hand, it's not /intended/ to be evil.  In this
> particular case, my personal thought on this is that the intent
> outweighs the fact that it's a demon (come on, the BSD daemon on the
> front of my FreeBSD Services box is holding a spanner and wearing
> trainers--that's not exactly evil, is it?).

What drives the assertion that "demons are evil?"  I'm neither religious
or highly educated on the matter, but I've never really thought of them
as such.  Other summaries in this thread have pointed out their
neutrality.  Can you provide some references?

I've no vested interest here, I just find this discussion interesting,
and I like the names offered by Branden.

Thanks; my apologies if this is considered OT...

 - Keegan

Re: mozilla 1.6b

[Adrian Bunk]

On Thu, Dec 11, 2003 at 12:06:28PM -0700, Thomas E. Vaughan wrote:
>...
> I downloaded the source code and compiled Mozilla 1.6b
> myself.  Unfortunately, the configure script required that I
> install libgtk1.2-dev, and no anti-aliasing joy whatsoever
> was apparent.  I have been assuming that mozilla-1.5 in
> Debian was using gtk2 for anti-aliased widget text, but now
> I'm just confused.
> 
> Any help appreciated.

Download the Mozilla 1.5 source package from Debian unstable and look at 
the configure options used in debian/rules .

E.g. Mozilla defaults to Gtk 1.2, you have to give an explicit configure
option to compile it with Gtk 2 .

> Thomas E. Vaughan <[EMAIL PROTECTED]>

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Changes in formal naming for NetBSD porting effort(s)

[Roger Leigh]

Branden Robinson <[EMAIL PROTECTED]> writes:

> [I am not subscribed to debian -bsd.]
>
> On Sun, Dec 14, 2003 at 08:30:48PM +, Roger Leigh wrote:
>> Nathan Hawkins <[EMAIL PROTECTED]> writes:
>> > I'm not opposed to anything else you've said. I do believe these
>> > particular names are a bad idea, however. One of the reasons the BSD
>> > mascot is considered "cute" is that it has no real connection with
>> > demons, in name, or otherwise. Which to people of several religions are
>> > _not_ cute.
>> 
>> Thanks for raising this point.  I'm very interested in the Debian
>> GNU/*BSD efforts, but if named as such I would never consider using
>> them (the BSD daemon is, to my mind, only borderline acceptable as it
>> is).
>
> What would be unacceptable about it, and why is it only a "borderline"
> case?  What would push it over the borderline?

Demons are evil, and the BSD mascot is a demon (albeit a stylised
one).  On the other hand, it's not /intended/ to be evil.  In this
particular case, my personal thought on this is that the intent
outweighs the fact that it's a demon (come on, the BSD daemon on the
front of my FreeBSD Services box is holding a spanner and wearing
trainers--that's not exactly evil, is it?).

>> I don't have any good ideas as or an alternative right now--it's worse
>> than a tiebreaker!
>
> This is revealing.

If you say so...

> The fundamentalist mind is much more practiced at identifying what
> it's opposed to, than at identifying what it supports.

Err, I disagree with choosing a name of evil meaning, but haven't got
a (good) alternative readily to hand, so suddenly I'm a
"fundamentalist"?!  That's quite amusing.


-- 
Roger Leigh

Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Re: mozilla 1.6b

[Hartmut Figge]

Adrian Bunk:

> E.g. Mozilla defaults to Gtk 1.2, you have to give an explicit configure
> option to compile it with Gtk 2 .

Because of http://bugzilla.mozilla.org/show_bug.cgi?id=186789 i don't
like gtk2.

Hartmut

Re: Changes in formal naming for NetBSD porting effort(s)

[Joel Baker]

On Mon, Dec 15, 2003 at 10:40:11PM +, Roger Leigh wrote:
> Joel Baker <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Dec 15, 2003 at 11:01:49AM +0100, David Weinehall wrote:
> >> Branden's second proposal of using something from Pratchett did have a
> >> nice ring to it, and then there's always the valar.
> >
> > Actually, given that I'm a long-time and deep-seated Tolkien geek, I rather
> > like the notion of using the Valar - they're fictional, and Tolkien's work
> > isn't yet out from under copyright, but they *are* reasonably well-known
> > (Okay, not as well as Pratchett, but better than Christian demonology),
> > and if we're liable to get in trouble over using just the names, we should
> > probably strongly reconsider our use of Toy Story character names for
> > tagging distributions...
> >
> > Suppose it's time to dig out my reference books and see if I can come up
> > with a suitable set of names out of that mythos.
> >
> > Besides, using Tolkien names is a long geek tradition.
> 
> Would "Debian Aulë" be appropriate?
> 
> "Of the fabric of Earth had Aulë thought, to whom Ilúvatar had given
> skill and knowledge scare less than to Melkor; but the delight and
> pride of Aulë is in the deed of making, and in the thing made, and
> neither in posession nor in his own mastery; wherefore he gives and
> hoards not, and is free from care, passing ever on to some new work."
> 
> Ainulindalë, J. R. R. Tolkien, /The Silmarillion/.

Appropriate? As much as any of the Valar would be; he's certainly on the
list. But since we know of at least 4 active ports, one name isn't going to
be enough...

> There are also important Elves, such as Fëanor that might also qualify.

See my followup, elsewhere in the thread.

> However, there may well be copyright issues.  "Slink", "Woody",
> "Potato" and "Bo" etc. aren't exactly unique, but you would be hard
> pushed to find another book with "Manwë", "Oromë", etc. in it.

Given that we say, on the webpages, that they're Toy Story characters,
that isn't much of a defense. We're equally in trouble, except that
Disney is far more lawsuit-happy than Tolkien's estate has ever shown
itself to be.

That, and let's face it - given the number of machines in the world with
hostnames based on LotR, if the *name* - all we're using - is really
copyrightable (and the only opinion expressed so far on debian-legal has
asserted that it doesn't appear to be, as opposed to a *character*), there
are a whole lot of people who're going to be in trouble.
-- 
Joel Baker <[EMAIL PROTECTED]>,''`.
Debian GNU/NetBSD(i386) porter   : :' :
 `. `'
   `-


pgpwDqTSMwOX1.pgp
Description: PGP signature

Bug#224099: ITP: snownews -- Text mode RSS newsreader

[Joe Nahmias]

Package: wnpp
Severity: wishlist

* Package name: snownews
  Version : 1.4.1
  Upstream Author : Oliver Feiler <[EMAIL PROTECTED]>
* URL : http://home.kcore.de/~kiza/software/snownews/
* License : GPL2
  Description : Text mode RSS newsreader

Snownews is a console-based RSS aggregator that's easy to set up, easy
to configure, and is available under the GPL. If you're comfortable
browsing with Lynx or w3m, Snownews is definitely the RSS aggregator for
you.  Can read Outline Processor Markup Language (OPML) files for easy
transferring of RSS subscriptions from other aggregators.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux laptop 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Re: Nice multilingual environment with Debian menu

[Osamu Aoki]

On Mon, Dec 15, 2003 at 10:24:54AM +0800, Arne Goetje wrote:
> I suffer from the same problem, too. I'm using chinese, english and 
> german. However, the problem does not get fixed by changing the locale 
> all the time... this should not be done anyways. 

Yes.

> IMHO the local setting should reflect in which country you are based, 
> and not which languages or input methods you are using.
> Unfortunately many program developers abuse the locales for exactly that 
> function... :(

I use C as default local unless I need otherwise. 

> If you choose en_US.UTF-8 as locale and you are using KDE for example, 
> you can still input other languages which use the western alphabet by 
> changing the keyboard settings on the fly.

Yes.

> However, this does not work for asian input methods. Especially the 
> asian IMs are the ones which depend on the locale. They shouldn't do 
> it.

That's why I suggest my way.  I have one UXTerm for English which to not
activate IM.  I can have another UXTerm running on the same X screen from
my menu for Japanese which activate IM upon SHIFT-SPACE.

Did you tried my way and talking?

  http://qref.sourceforge.net/Debian/reference/ch-tune.en.html#s-x-cjk

> So, instead of trying to work around the problem by changing your 
> individual system, we should convice the programmers of these 
> applications in question, not to depend on the locale setting, but use 
> a switch in the application configuration to choose the proper input 
> method.

Mlterm address this issue this way so does some other terminal programs.

But that beat some good thing about locale.  Menu actually fill in gap.

> Unfortunately openoffice.org goes in the same wrong direction, by 
> requiring the user to use a chinese locale setting to input chinese... 
> that's nuts! Obviously the developers didn't think of people who have 
> to deal with more than one language... :(

So why not set 2 openoffice menu (i.e., invocation commands) for
Chinese and English.  You can enen set up one system with basically 
chinese environment but also specify English messages.  Then program 
will be IM aware but easy on English reader.

I think compose key sequences overrap with IM key sequences.

Cheers to you.

> Arne Götje (高盛華) <[EMAIL PROTECTED]>
It looks like your name comes up OK in my ja_JP.eucJP locale :-)

Re: Bug#223772: general: no md5sums for many packages (e.g. bc)

[Henning Makholm]

Scripsit [EMAIL PROTECTED]

> why is the md5sums file useless and space wasting especially in
> terms of security? until now, I was of the opinion, that the md5sum
> gives me the guarantee that a debian package is not penetrated
> before installation

No, that's what the checksum of the entire .deb file in the Packages
file is there for.

An attacker who can tamper with /usr/bin/foo within the .deb can just
as easily tamper with the md5sums file within the .deb.

> and further - after having the packages installed on a machine - the
> md5sum files give me the confidence that the debian binaries are
> correct and consistent.

No. An attacker who changes the binaries can just as easily change the
md5sum files stored in /var/lib/dpkg/info.

If you go to a trusted copy of the .deb file for verifying your
binaries, you have the original binaries right there, and do not need
precomputed checksums for comparing them bit-for-bit with what's on
your disk.

It has been argued on debian-devel (read the thread!) that the md5sums
files can be handy to have for detection of non-malicious random acts
of God. But the sense of *security* gained by having the .deb install
a set of checksums on the same machine as the package itself is false.

-- 
Henning Makholm "Det er du nok fandens ene om at
 mene. For det ligger i Australien!"

Re: experimental codename

[Henning Makholm]

Scripsit Graham Wilson <[EMAIL PROTECTED]>

> However, I am not (nor do I believe a majority might be) that
> experimental should duplicate unstable, with only a few packages (the
> experimental ones) being newer. However, with the pool structure
> archive, this might not actually mean a duplication of too much space.

Well, experimental's Packages file itself would become as large as the
one for unstable.

Most people would still want to have unstable as well as experimental
in their sources.list, because the ride might get too rough if you
pulled _everything_ from experimental that there is to pull. For
example, one might be willing to help stress-test the packaging of
perl6, but not at the same time as stress-testing new glibc packages.

At least on my system, synchronizing the Packages file on a daily
basis accounts for a significant fraction of the total amortized
bandwith I use for tracking unstable, simply because I have to
download it in full every day. So inflating experimental/Packages to
full distribution size would probably have a measurable effect on
mirror load level.

-- 
Henning Makholm "I've been staying out of family
   conversations. Do I get credit for that?"

Re: Changes in formal naming for NetBSD porting effort(s)

[Russell Coker]

On Tue, 16 Dec 2003 10:03, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > What would be unacceptable about it, and why is it only a "borderline"
> > case?  What would push it over the borderline?
>
> Demons are evil, and the BSD mascot is a demon (albeit a stylised

Below is the first definition provided by the "dict daemon" command in Debian.

From The Collaborative International Dictionary of English v.0.48 [gcide]:

  Demon \De"mon\, n. [F. d['e]mon, L. daemon a spirit, an evil
 spirit, fr. Gr. dai`mwn a divinity; of uncertain origin.]
 1. (Gr. Antiq.) A spirit, or immaterial being, holding a
middle place between men and deities in pagan mythology.
[1913 Webster]

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

Re: Changes in formal naming for NetBSD porting effort(s)

[Colin Watson]

On Tue, Dec 16, 2003 at 02:19:58PM +1100, Russell Coker wrote:
> On Tue, 16 Dec 2003 10:03, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > Demons are evil, and the BSD mascot is a demon (albeit a stylised
> 
> Below is the first definition provided by the "dict daemon" command in Debian.
> 
> From The Collaborative International Dictionary of English v.0.48 [gcide]:
> 
>   Demon \De"mon\, n. [F. d['e]mon, L. daemon a spirit, an evil
>  spirit, fr. Gr. dai`mwn a divinity; of uncertain origin.]
>  1. (Gr. Antiq.) A spirit, or immaterial being, holding a
> middle place between men and deities in pagan mythology.
> [1913 Webster]

I wonder if people here object to the daemon() library call.

I have to say that this whole discussion is reminding me of Jesux
(http://www.geocities.com/ResearchTriangle/Node/4081/) ...

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Nice multilingual environment with Debian menu

[Arne Goetje]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> > However, this does not work for asian input methods. Especially the
> > asian IMs are the ones which depend on the locale. They shouldn't
> > do it.
>
> That's why I suggest my way.  I have one UXTerm for English which to
> not activate IM.  I can have another UXTerm running on the same X
> screen from my menu for Japanese which activate IM upon SHIFT-SPACE.
>
> Did you tried my way and talking?
>
>  
> http://qref.sourceforge.net/Debian/reference/ch-tune.en.html#s-x-cjk

I am still doing it and I'm not happy with it at all. If I have to input 
multiple languages in the same document / application - for example 
chinese, english, german -, i currently have to start it from a chinese 
terminal to get chinese input method, then save the document, close teh 
application, start the same application again from my normal english 
system, open the document again and type english (and if I change the 
keyboard settings on the fly - german).
This is crazy. I want to change my input method between western / asian 
or even between asian on the fly without the need of starting multiple 
instances and reopening / closing the document all the time.
It's even worse when I use ICQ to chat with my buddies. Some are 
chinese, some are german. If I want to input chinese, i cannot input 
german at the same time. very unconvenient if you are chatting with two 
budies at the same time and they use different languages.

The only solution for this is: use unicode (utf-8) and have an IM which 
can switch between different languages but uses unicode in the 
background. SCIM does that but is still lacking canna support for 
japanese and a few useful input methods.

>
> > So, instead of trying to work around the problem by changing your
> > individual system, we should convice the programmers of these
> > applications in question, not to depend on the locale setting, but
> > use a switch in the application configuration to choose the proper
> > input method.
>
> Mlterm address this issue this way so does some other terminal
> programs.

I know. But I'm not only using terminal based apps, but merely graphical 
apps.

> But that beat some good thing about locale.  Menu actually fill in
> gap.

only if you need terminal based apps and only want to use one charset at 
the time.

> > Unfortunately openoffice.org goes in the same wrong direction, by
> > requiring the user to use a chinese locale setting to input
> > chinese... that's nuts! Obviously the developers didn't think of
> > people who have to deal with more than one language... :(
>
> So why not set 2 openoffice menu (i.e., invocation commands) for
> Chinese and English.  You can enen set up one system with basically
> chinese environment but also specify English messages.  Then program
> will be IM aware but easy on English reader.

that's what I'm currently doing. but as said, when I start oo.o in 
chinese mode, I can type english and chinese, yes. But I cannot change 
to other western languages on the fly because the IM program occupies 
my keyboard and overrides the x-keyboard or - in my case - KDE.

(currently all IM programs I know are only usable with a native 
us-english keyboard layout - this is another thing to work on. The IM 
program should integrate with the xserver, so that you can use any 
keyboard layout as the base layout and switch to the IM when you need 
it.)

> I think compose key sequences overrap with IM key sequences.

in some apps yes.

> > Arne GÃtje (éçè) <[EMAIL PROTECTED]>
>
> It looks like your name comes up OK in my ja_JP.eucJP locale :-)

I'm using utf-8. if eucJP uses the same codepoints, there you go... ;)

Cheers
Arne
- -- 
Arne GÃtje (éçè) <[EMAIL PROTECTED]>
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F  1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/3nyHbp/QbmhdHowRAqLtAJ0cuz2pnxg2v7q1kYougS1vvppKcwCfUhUU
zCqVsOpp9wWTS7ykHNqM1xI=
=eAs6
-END PGP SIGNATURE-

Re: Changes in formal naming for NetBSD porting effort(s)

[Nunya]

On Tue, Dec 16, 2003 at 03:30:52AM +, Colin Watson wrote:
> On Tue, Dec 16, 2003 at 02:19:58PM +1100, Russell Coker wrote:
> > On Tue, 16 Dec 2003 10:03, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > > Demons are evil, and the BSD mascot is a demon (albeit a stylised
> > 
> > Below is the first definition provided by the "dict daemon" command in 
> > Debian.
> > 
> > From The Collaborative International Dictionary of English v.0.48 [gcide]:
> > 
> >   Demon \De"mon\, n. [F. d['e]mon, L. daemon a spirit, an evil
> >  spirit, fr. Gr. dai`mwn a divinity; of uncertain origin.]
> >  1. (Gr. Antiq.) A spirit, or immaterial being, holding a
> > middle place between men and deities in pagan mythology.
> > [1913 Webster]
> 
> I wonder if people here object to the daemon() library call.
> 
> I have to say that this whole discussion is reminding me of Jesux
> (http://www.geocities.com/ResearchTriangle/Node/4081/) ...

If you believe in paganism you should know that calling something by its 
truename is an attempt to control it, and is dangerous.

What makes you think those of us opposed to invoking evil believe 
ourselves to be good? 

The conversation has taken a lighter tone.  It's not offensive.  Knock 
yourselves out.

BTS and maintainer changes

[Henning Makholm]

How quickly is a change of maintainer supposed to propagate to the BTS?

I recently adopted autotrace, and had a package with an updated
control file uploaded; it has now been in the archive for several
days. I have checked that I am correctly listed as maintainer in
the unstable Sources file and in
http://ftp.debian.org/indices/Maintainers{,.gz}.

Nevertheless, the BTS persists in giving the QA group as the maintainer
at, say, . I am worried that
this might mean that I am not notified of bug activity by email.

 indicates that the Maintainer
field should suffice to make the listing change, but also hints that
there is a behind-the-scenes "override file" at work. Is that override
file publically available anywhere such that I can check whether an
old override entry for the QA team is stuck there?

Or is the BTS just not yet completely up after the compromise?

-- 
Henning Makholm  "We can build reactors, we can melt
 ice. Or engineers can be sent north for
   re-education until they *do* understand ice."

Re: BTS and maintainer changes

[Graham Wilson]

On Tue, Dec 16, 2003 at 01:05:44AM +, Henning Makholm wrote:
> I recently adopted autotrace, and had a package with an updated
> control file uploaded; it has now been in the archive for several
> days.

I am in the same situation with hostname.

> Nevertheless, the BTS persists in giving the QA group as the maintainer
> at, say, . I am worried that
> this might mean that I am not notified of bug activity by email.

I think that is the case. You might want to try subscribing to the
package via the PTS. Hmm... I tried that the other day though, and no
luck.

>  indicates that the Maintainer
> field should suffice to make the listing change, but also hints that
> there is a behind-the-scenes "override file" at work. Is that override
> file publically available anywhere such that I can check whether an
> old override entry for the QA team is stuck there?

I remember it being available on master [1]. I think it has probably not
been set up to update since the break-in.

[1] /org/bugs.debian.org/etc/Maintainers

-- 
gram


signature.asc
Description: Digital signature

Re: Changes in formal naming for NetBSD porting effort(s)

[Russ Allbery]

Keegan Quinn <[EMAIL PROTECTED]> writes:

> What drives the assertion that "demons are evil?"  I'm neither religious
> or highly educated on the matter, but I've never really thought of them
> as such.  Other summaries in this thread have pointed out their
> neutrality.  Can you provide some references?

Well, it depends on what mythology you're working from.  In the Christian
mythology, which is probably the dominant context for evaluating that sort
of question, demons are, by definition, fallen angels who rebelled against
God and were cast out of Heaven.  They are generally considered to have a
tempter role in this life and a punisher role in the afterlife
(cf. Dante's _Inferno_).  They're not uncommonly associated with an
attitude of pure selfishness, as opposed to angels who are purely
selfless.

It's certainly true that a lot of more modern mythology has made demons
more ambiguous, in part as backlash against Christianity, in part as just
exploration of a more nuanced view of spirituality, in part just out of
the standard human fascination with the bad guys in a stock story.  Many
demons originate as pagan gods and therefore originally had a much
different role before being pulled into Christian mythology and rewritten
(a process which is common for most all mythological construction in
history -- see, for example, the conflict between the Olympian gods and
the Titans in Greek mythology).  But within the mainstream, standard
Christian mythological system, demons are evil by definition.

For a fairly good portrayal of a Christian take on demons that isn't quite
so traditional as Dante's _Inferno_ but which captures the same basic
idea, see C.S. Lewis's _The Screwtape Letters_.  A more famous work of
literature on the topic is Milton's _Paradise Lost_, a quote of which
you've probably heard at one point or another:

Here at last
We shall be free; th' Almighty hath not built
Here for his envy, will not drive us hence:
Here we may reign secure, and in my choice
To reign is worth ambition though in Hell:
Better to reign in Hell, than serve in Heav'n.
-- Satan, Paradise Lost, Book 1, lines 258-263

For a different, somewhat postmodern take on angels and demons, see the
roleplaying game _In Nomine_, published by Steve Jackson Games, which can
be played as pure good angels vs. evil demons, with complete moral
ambiguity, with demons as heroic rebels against the repression of heaven,
or anything else inbetween.

-- 
Russ Allbery ([EMAIL PROTECTED])