Re: Reopening bug closed due to SPAM

[Brian May]

> "Javier" == Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:

Javier> If spam e-mail is going to start closing our Bugs in the
Javier> BTS then we should start thinking about implementing
Javier> authentication checks in the BTS...  like for example: do
Javier> not allow control messages or -close messages with no
Javier> attached (valid) GPG/PGP signatures (from a valid
Javier> developer?)"

Would a GPG signature help in the long run?

The BTS closes bugs based on the address in the SMTP recipient field.

This is not GPG protected.

So a Spammer could copy an existing email from an existing developer
from mailing list archives, forge his email address, and resend
it. The signature remains valid, and the bug will still be closed.

GPG signatures don't protect data that isn't protected (such as mail
headers or SMTP session), and it doesn't protect against replay
attacks (unless you add some other mechanism, e.g. include the date
and time in the protected part of the message).
-- 
Brian May <[EMAIL PROTECTED]>

Re: Mass-filing bugs based on piuparts?

[Marc 'HE' Brockschmidt]

Lars Wirzenius <[EMAIL PROTECTED]> writes:
> I'm running piuparts, my package installation, upgrading, and removal
> tester, against etch. It takes a while, and produces a fairly large
> number of error logs that need to be investigated manually. This
> sometimes reveals a bug in piuparts, and sometimes in the package, or a
> depency of the package.
[...bug filing...]
> Is this acceptable to everyone? Suggestions on how to do this better?

Yes, please do so. These are clearly bugs and need to be documented in
the BTS to ensure that all of them are fixed (or at least not released
with etch).

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
190: Cisco
   Protokolhure. (unbekannt)


pgpfbiChxJKCj.pgp
Description: PGP signature

Re: Mass-filing bugs based on piuparts?

[Petter Reinholdtsen]

[Lars Wirzenius]
> The way I'm running it now, it installs and purges each package
> (plus dependencies), and then compares the state of the filesystem
> (the chroot) before and after and reports files that have been
> modified, removed, or created.

Can you do upgrade testing as well.  It would be great to know what
packages fail to upgrade properly from woody to sarge, and from sarge
to etch.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aspell upgrade woes

[Martin v. Löwis]

Brian Nelson wrote:
> OK, very well then, I'll undo the GCC 4 transition for libaspell15.

Isn't there still a binary-compatibility issue here? I thought that
in an application, there must only be one version of libstdc++,
directly or indirectly. Otherwise, during runtime, symbols may resolve
from the "wrong" libstdc++, causing crashes.

So if libaspell is linked with libstdc++.so.6, and some application
links to both libaspell (through the C API), and libstdc++.so.5 (because
it is a C++ application), this application may crash, as it might pick
up symbol definitions from libstdc++.so.6 - or libaspell might crash
as it picks up some symbols from libstdc++.so.5, and some from
libstdc++.so.6.

Regards,
Martin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mass-filing bugs based on piuparts?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Is this acceptable to everyone? Suggestions on how to do this better?

This would be real great QA work, would you mind to also send a final or
intermediate report with the most common errors you encountered. In my
experience somebody who audits a particular aspect of a larger system is
well suited to give trend analysis. Hopefully we find common errors which
can be included in lintian or detected otherwise. I wonder if you already
can report on common problems?

Thans for your work

Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aspell upgrade woes

[Steve Langasek]

On Fri, Jul 22, 2005 at 09:13:00AM +0200, "Martin v. Löwis" wrote:
> Brian Nelson wrote:
> > OK, very well then, I'll undo the GCC 4 transition for libaspell15.

> Isn't there still a binary-compatibility issue here? I thought that
> in an application, there must only be one version of libstdc++,
> directly or indirectly. Otherwise, during runtime, symbols may resolve
> from the "wrong" libstdc++, causing crashes.

> So if libaspell is linked with libstdc++.so.6, and some application
> links to both libaspell (through the C API), and libstdc++.so.5 (because
> it is a C++ application), this application may crash, as it might pick
> up symbol definitions from libstdc++.so.6 - or libaspell might crash
> as it picks up some symbols from libstdc++.so.5, and some from
> libstdc++.so.6.

All of the symbols provided by both libstdc++.so.6 and libstdc++.so.5 are
versioned; I don't think there's any real risk here of crashes due to
picking the wrong symbols at runtime.

-- 
Steve Langasek
postmodern programmer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aspell upgrade woes

[Brian Nelson]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Brian Nelson wrote:
>> OK, very well then, I'll undo the GCC 4 transition for libaspell15.
>
> Isn't there still a binary-compatibility issue here? I thought that
> in an application, there must only be one version of libstdc++,
> directly or indirectly. Otherwise, during runtime, symbols may resolve
> from the "wrong" libstdc++, causing crashes.
>
> So if libaspell is linked with libstdc++.so.6, and some application
> links to both libaspell (through the C API), and libstdc++.so.5 (because
> it is a C++ application), this application may crash, as it might pick
> up symbol definitions from libstdc++.so.6 - or libaspell might crash
> as it picks up some symbols from libstdc++.so.5, and some from
> libstdc++.so.6.

AFAIK, libstdc++ uses versioned symbols to prevent these problems...

-- 
Society is never going to make any progress until we all learn to
pretend to like each other.

Bug#38116: about voting for bugs

[Martin Samuelsson]

Adeodato Simó @ 2005-07-20 (Wednesday), 13:30 (+0200)
>   Debian Bug Subscription Feature, by Joachim Breitner:
> 
> http://lists.debian.org/debian-devel/2005/07/msg00490.html

I'm quoting that mail to feed it to the bug report regarding the issue.

"
Hi,

Something that I have been missing for along time is the posibility to
subscribe to single bugs in our bugtracking system. Two years ago, at
Oslo, I created a patch to debbugs that would add that feature, but due
to slow communication with the debbugs team and probably not enough
persistence on my side, this never made in into the debbugs package.

Today, I started this again, this time as an independant service, thus
enabling easier development and no risk for the crucial debbugs
infrastructure. It is currenlty in "first usable state with minimum
features". To use it, send a mail to [EMAIL PROTECTED]
with the bugnumer (and only the bug number, nothing else, not even a #)
in the Subject. From then on, you should get any mail on
[EMAIL PROTECTED] that concerns that bug.

There is currently no way to unsubscribe. Not too bad, since bugs tend
to be fixed someday, but certainly a TODO. Also, there is no
confirmation question, nothing to prevent you from recieving the same
mail twice. There is a Anti-Mailloop-Feature, I hope it works. Debian
Developers can have a look at the code on
gluck.debian.org:~nomeata/debsub/, comments and patches welcome. 

Greetings from Helsinki,

Joachim
"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mass-filing bugs based on piuparts?

[Tore Anderson]

* Petter Reinholdtsen

> Can you do upgrade testing as well.  It would be great to know what
> packages fail to upgrade properly from woody to sarge, and from sarge
> to etch.

  Indeed.  And if you can, Lars, please include a test to see which
 packages which modify their own conffiles so the user is presented with
 a dpkg conffile changed dialogue during the upgrade.  It would also be
 very interesting to see how many packages leave behind orphaned
 conffiles after purging a newer version which does not contain the
 files anymore.

Regards
-- 
Tore Anderson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#38116: about voting for bugs

[Adeodato Simó]

* Martin Samuelsson [Fri, 22 Jul 2005 10:01:04 +0200]:

> Adeodato Simó @ 2005-07-20 (Wednesday), 13:30 (+0200)
> >   Debian Bug Subscription Feature, by Joachim Breitner:

> > http://lists.debian.org/debian-devel/2005/07/msg00490.html

> I'm quoting that mail to feed it to the bug report regarding the issue.

  Well, this has gone "official" now:

http://lists.debian.org/debian-devel-announce/2005/07/msg00014.html

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
And don't get me wrong - I don't mind getting proven wrong. I change my
opinions the way some people change underwear. And I think that's ok.
-- Linus Torvalds


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#38116: about voting for bugs

[Pascal Hakim]

On Fri, Jul 22, 2005 at 10:35:40AM +0200, Adeodato Simó wrote:
> * Martin Samuelsson [Fri, 22 Jul 2005 10:01:04 +0200]:
> 
> > Adeodato Simó @ 2005-07-20 (Wednesday), 13:30 (+0200)
> > >   Debian Bug Subscription Feature, by Joachim Breitner:
> 
> > > http://lists.debian.org/debian-devel/2005/07/msg00490.html
> 
> > I'm quoting that mail to feed it to the bug report regarding the issue.
> 
>   Well, this has gone "official" now:
> 
> http://lists.debian.org/debian-devel-announce/2005/07/msg00014.html
> 

It's not the same system, but it's a similar idea. Joachim was strongly
involved in getting that to work.

Cheers,

Pasc
-- 
Pascal Hakim  0403 411 672
Do Not Bend


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Removal of transitional dummy packages

[Steve Langasek]

On Tue, Jul 19, 2005 at 12:54:56PM +0200, Santiago Vila wrote:
> On Tue, 19 Jul 2005, Don Armstrong wrote:

> > On Mon, 18 Jul 2005, Santiago Vila wrote:
> > > On Mon, 18 Jul 2005, Steve Langasek wrote:
> > > > In this context, woody->sarge transition packages are just one
> > > > form of useless cruft that we should strive to get rid of before
> > > > the etch release. They're not the biggest source of cruft, but on
> > > > the other hand they are (IMHO) one of the sources for which the
> > > > proper course of action is clearest.

> > > In such case, could we please codify that in policy?

> > Surely the release manager's decision on the matter when properly
> > publisized is information enough?

> Do you think having this in policy may be harmful? If so, why?

> We supported upgrades that skip releases in the past, and now we do
> not (I suppose the fact that our release cycles are much longer have
> something to do with this). Isn't this the kind of thing that we
> usually document in policy?

IMHO, not really, no; I think this is more like "this is the set of
architectures that your package must not regress on" than it is like "these
are the arguments that your maintainer scripts must support".  I.e., this is
a temporal release team recommendation owing to the size of our deltas
between releases right now, not a permanent policy that should be enshrined
in the Policy document.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Mass-filing bugs based on piuparts?

[Lars Wirzenius]

pe, 2005-07-22 kello 09:38 +0200, Petter Reinholdtsen kirjoitti:
> [Lars Wirzenius]
> > The way I'm running it now, it installs and purges each package
> > (plus dependencies), and then compares the state of the filesystem
> > (the chroot) before and after and reports files that have been
> > modified, removed, or created.
> 
> Can you do upgrade testing as well.  It would be great to know what
> packages fail to upgrade properly from woody to sarge, and from sarge
> to etch.

Not in this run, I'm afraid. Just the simple test takes a while, and I'd
prefer to wait for upgrade testing over the entire archive until there's
more machines to run the tests one. piuparts can do the testing,
however, and they will be run, later.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Peter Samuelson]

[Pascal Hakim]
> It is now possible to subscribe and unsubscribe from individual bugs in
> the Bug Tracking System. To do so, simply send an email to
> [EMAIL PROTECTED], or [EMAIL PROTECTED]

THANK YOU, those of you who coded and deployed this!  This is something
I've wanted as long as I can remember.  It's right up there between
versioned provides and sliced bread.

Now ... how hard would it be to add 'submit-subscribe@' support?  Most
of the time, when I submit a bug report, I'd like to subscribe to it.
Would this be a straightforward hack?

Thanks,
Peter


signature.asc
Description: Digital signature

Re: The BTS and bug subscriptions

[Goswin von Brederlow]

Pascal Hakim <[EMAIL PROTECTED]> writes:

> Hi everyone,
>
> One of the oft-requested features for the BTS had been the ability to
> subscribe to bugs.
>
> It is now possible to subscribe and unsubscribe from individual bugs in
> the Bug Tracking System.
...
> Many thanks to Joachim Breitner and Don Armstrong who provided most of
> the code, Anthony Towns and Colin Watson for their advice, and everyone
> at Debconf who piped in with suggestions along the way.

You rock.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Thomas Hood]

I have a couple of initscripts that print progress messages and I do
not want to be too hasty in eliminating them so I am thinking of
doing the following for now:

...

if [ -r /lib/lsb/init-functions ] ; then
. /lib/lsb/init-functions
print_warning_msg() { log_warning_msg "$*" ; }
print_begin_msg() { log_begin_msg "$*" ; }
print_progress_msg() { : ; }
print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }
else
print_warning_msg() { echo -n "$*" >&2 ; }
print_begin_msg() { echo -n "$*" ; }
print_progress_msg() { echo -n " $*" ; }
print_end_msg_and_exit() { case "$1" in (0) echo "${2}." ;; (*) echo 
"${3}." ;; esac ; exit $1 ; }
fi

...

case "$1" in
  start)
print_begin_msg "Doing foo..."
foo
print_progress_msg "and now bar..."
bar
print_end_msg_and_exit "$?" "done" "failed"
;;

...


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: lsb-base

[Pierre Habouzit]

Le Ven 22 Juillet 2005 11:14, Thomas Hood a écrit :
> I have a couple of initscripts that print progress messages and I do
> not want to be too hasty in eliminating them so I am thinking of
> doing the following for now:
>
> ...
>
> if [ -r /lib/lsb/init-functions ] ; then
>   . /lib/lsb/init-functions
>   print_warning_msg() { log_warning_msg "$*" ; }
>   print_begin_msg() { log_begin_msg "$*" ; }
>   print_progress_msg() { : ; }
>   print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }
> else
>   print_warning_msg() { echo -n "$*" >&2 ; }
>   print_begin_msg() { echo -n "$*" ; }
>   print_progress_msg() { echo -n " $*" ; }
>   print_end_msg_and_exit() { case "$1" in (0) echo "${2}." ;; (*) echo
> "${3}." ;; esac ; exit $1 ; } fi
>
> ...

well, it seems complicated, why don't you fake the lsb-base names ? like 
it :

###
### fake lsb
###

if [ -r /lib/lsb/init-functions ] ; then
. /lib/lsb/init-functions
else
log_warning_msg () { echo -n "$*" &>2; }
log_begin_msg ()   { echo -n "$*"; }
log_progress_msg() { echo -n "$*"; }
// put here what you need
fi

###
### my functions
###

print_end_msg_and_exit() { log_end_msg "$1" ; exit $1 ; }


it seems simple, does it ?

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBaUJERgHk5.pgp
Description: PGP signature

Re: lsb-base

[Marco d'Itri]

On Jul 22, Thomas Hood <[EMAIL PROTECTED]> wrote:

> I have a couple of initscripts that print progress messages and I do
> not want to be too hasty in eliminating them so I am thinking of
> doing the following for now:
Please don't. lsb-base is a tiny package, either use it or don't.
It will have standard priority soon anyway.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Reopening bug closed due to SPAM

[Javier Fernandez-Sanguino Pen~a]

Goswin von Brederlow escribió:

Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes:



If spam e-mail is going to start closing our Bugs in the BTS then we
should
start thinking about implementing authentication checks in the BTS...
like
for example: do not allow control messages or -close messages with no
attached (valid) GPG/PGP signatures (from a valid developer?)"

NMs and most submitters aren't in the keyring so they would have a
hard time managing bugs if a DD signature is required.


The requirement for a valid signature might not be 'valid signature = DD 
signature' but something more liberal like 'valid signature = signature 
in the web of trust' (i.e. either a DD or signed by a DD) or even more 
liberal like 'valid signature = signature in known keyservers'. In the 
later, spammers could get keys generated and submitted there but they 
are not really targetting our BTS, it's backscatter from their spam tricks.



And don't forget the DAK closing bugs on uploads. The archive key
would have to be allowed to sign too.


Or the BTS mail interface could approve messages coming in directly from 
the ftp-master system, in any case, adding the archive key would not be 
an issue, probably.


I don't know if the BTS admins are going to go forward with any of these 
but IMHO it doesn't make any sense to allow administrative access 
(managing, retitling, tagging, etc.) to the BTS without any kind of 
authentication attempts (even if "simple") of the end user when in most 
situations it's somebody the project knows about, not Random Joe.


Maybe the BTS admins are tracking abuse somehow, I haven't digged into 
the BTS code at all but I do remember some abuse in the past and people 
being shunted off. However, with the current state of affairs, is there 
anything that prevents somebody from sending fake e-mails (maybe using 
relay proxies) to the BTS using random mail To's to (1-close to 
319400-close _AT_ bugs.debian.org ? Just wondering...


Regards

Javier


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt 0.6 downloads from second archive?

[Graham Williams]

Received Fri 22 Jul 2005  9:27am +1000 from Matthew Palmer:
> On Thu, Jul 21, 2005 at 07:12:29AM +1000, Graham Williams wrote:
> > Since installing apt 0.6 on an otherwise up-to-date unstable (except
> > for anything depending on the aspell libraries...) packages on my
> > local archive are being overlooked even though this archive is listed
> > before others in my apt/sources.list. Downgrading to apt 0.5 and
> > things work again as expected (i.e., most is downloaded from
> > localhost).
> 
> Huge (uninformed) guess, but apt may be preferring packages from
> repositories it can verify the contents of.  Besides, if the versions are
> the same, then the contents should be the the same too, and (modulo
> bandwidth charges) which one you get from shouldn't matter.  BTW, the new
> (twisted-based) apt-proxy rocks hard, if it's your traffic allowances you're
> worried about (and who wouldn't be in Australia, given what we get charged).
> 
> - Matt

Thanks for the guess Matt. I've added a Releases.gpg and it did not
make any difference. Traffic's not the issue - I download all new
upgrades early each morning automatically and they go into this local
archive so that when I get up, a distupgrade used to flash by - not now
since it has to grab them all again :-(

I'll have a look at apt-proxy.

Thanks,
Graham


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Removal of transitional dummy packages

[Santiago Vila]

On Fri, 22 Jul 2005, Steve Langasek wrote:

> > > On Mon, 18 Jul 2005, Santiago Vila wrote:
> > Do you think having this in policy may be harmful? If so, why?
> 
> > We supported upgrades that skip releases in the past, and now we do
> > not (I suppose the fact that our release cycles are much longer have
> > something to do with this). Isn't this the kind of thing that we
> > usually document in policy?
> 
> IMHO, not really, no; I think this is more like "this is the set of
> architectures that your package must not regress on" than it is like "these
> are the arguments that your maintainer scripts must support".  I.e., this is
> a temporal release team recommendation owing to the size of our deltas
> between releases right now, not a permanent policy that should be enshrined
> in the Policy document.

I see your point, but policy has never been a "permanent" thing. For some
time we have had a policy which mandated symlinks in /usr/doc. Later we had
exactly the "opposite" policy, one that does not mandate symlinks in /usr/doc.

Sometimes there is a policy which recommends something which is later
changed to a "should", then to a "must". In this case, however, we are
switching from "dummy packages for upgrades which skip releases are allowed"
to "somebody is going to file bugs on them without asking the maintainer first
and ftp.debian.org will honor the reports".

I think this is more like "things we do to support upgrades from oldstable
are considered cruft and it's ok and even desirable to remove them".
This is not limited to dummy packages, but it also includes versioned
dependencies on essential packages which everybody has now installed,
and special hacking in maintainer scripts. If we are going to remove
things because they are considered cruft, it would be very good to
have a common and consistent definition of "cruft".

There was a tentative policy regarding upgrades in Bug #34672 (you can
skip all the flames and go directly to the last message...), but it diverges
significatively from current practice. What I would like to see in
policy is our current practice, whatever it is.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jon Dowland]

On Fri, Jul 22, 2005 at 12:20:45AM +0200, Alexander Fieroch wrote:
> Package: wnpp
> Severity: wishlist
> 
> URL: http://www.doomsdayhq.com/index.php
> License: GPL (see http://sourceforge.net/projects/deng)
> 
> Description:
> 
> About The Doomsday Engine
> The Doomsday Engine is an enhanced and extended version of DOOM, 
> Heretic, and Hexen. It was originally based on the Hexen source code but 
> parts of it have later been completely rewritten. Doomsday is only an 
> engine; you will need a Game DLL if you want to play anything. Three 
> such DLLs are being developed alongside the engine: jDoom, jHeretic and 
> jHexen.

I object to doomsday being packaged. The heretic/hexen source code
licence is utterly incompatible with the GPL, making this package
technically illegal. It is also very much against the DFSG. See
 for a similar bug against the existing
package for doom legacy.

You could arguably only package the engine + doom library portions, but
I don't know how much of the heretic/hexen code has made its way into
those components (if any).

I am currently trying to start negotiations with the publisher of
heretic/hexen to relicence under the GPL; this would be the ideal
solution to this problem (which applies to doomlegacy as alreay
mentioned, doomsday, the derivative risen3d, another port called vavoom:
unfortunately, virtually all the doom ports have disregarded the GPL
in one way or another :( ) anyone interested in progress updates
should mail me.

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mass-filing bugs based on piuparts?

[Helmut Wollmersdorfer]

Lars Wirzenius wrote:


The way I'm running it now, it installs and purges each package (plus
dependencies), and then compares the state of the filesystem (the
chroot) before and after and reports files that have been modified,
removed, or created. Quite simplistic, really, but good enough to find a
number of problems already.


Sounds interesting as I had the same idea. Is the source available?

My plan was to write a tool which does such checks for a package 
installation on the most popular distries. But I too much to do with my 
'wording' package, which aims to find wording problems in documentation 
and program messages. At the moment it can parse d-i templates, po and 
messages out of a PHP-suite; docbook.xml, HTML, POD and man coming soon.


As with your tool I will have the same problem of mass-filing bugs. I 
hope to support this semi-automatically for my own convenience.


Helmut Wollmersdorfer


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Mass-filing bugs based on piuparts?

[Lars Wirzenius]

pe, 2005-07-22 kello 13:19 +0200, Helmut Wollmersdorfer kirjoitti:
> Lars Wirzenius wrote:
> 
> > The way I'm running it now, it installs and purges each package (plus
> > dependencies), and then compares the state of the filesystem (the
> > chroot) before and after and reports files that have been modified,
> > removed, or created. Quite simplistic, really, but good enough to find a
> > number of problems already.
> 
> Sounds interesting as I had the same idea. Is the source available?

See the piuparts package.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

A new system log

[psycheye]

Hi all,

I think a new system log:

A daemon control for the transfer from cdrom (cdr) and usb device. 

/var/log/cdrom
/var/log/usb
etc.

This is very useful for a administrator many user account.

What do u think?

Thanks :-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: apt 0.6 downloads from second archive?

[Goswin von Brederlow]

Graham Williams <[EMAIL PROTECTED]> writes:

> Received Fri 22 Jul 2005  9:27am +1000 from Matthew Palmer:
>> On Thu, Jul 21, 2005 at 07:12:29AM +1000, Graham Williams wrote:
>> > Since installing apt 0.6 on an otherwise up-to-date unstable (except
>> > for anything depending on the aspell libraries...) packages on my
>> > local archive are being overlooked even though this archive is listed
>> > before others in my apt/sources.list. Downgrading to apt 0.5 and
>> > things work again as expected (i.e., most is downloaded from
>> > localhost).
>> 
>> Huge (uninformed) guess, but apt may be preferring packages from
>> repositories it can verify the contents of.  Besides, if the versions are
>> the same, then the contents should be the the same too, and (modulo
>> bandwidth charges) which one you get from shouldn't matter.  BTW, the new
>> (twisted-based) apt-proxy rocks hard, if it's your traffic allowances you're
>> worried about (and who wouldn't be in Australia, given what we get charged).
>> 
>> - Matt
>
> Thanks for the guess Matt. I've added a Releases.gpg and it did not
> make any difference. Traffic's not the issue - I download all new
> upgrades early each morning automatically and they go into this local
> archive so that when I get up, a distupgrade used to flash by - not now
> since it has to grab them all again :-(
>
> I'll have a look at apt-proxy.
>
> Thanks,
> Graham

What does your sources.list look like?

It seems like file:// and copy:// urls behave differently with the new
secure apt. E.g. they don't get md5sum checked.

Try looping them through ftp or http.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Nigel Jones]

On 22/07/05, Pascal Hakim <[EMAIL PROTECTED]> wrote:
> Hi everyone,
> 
> One of the oft-requested features for the BTS had been the ability to
> subscribe to bugs.
> 
> It is now possible to subscribe and unsubscribe from individual bugs in
> the Bug Tracking System. To do so, simply send an email to
> [EMAIL PROTECTED], or [EMAIL PROTECTED], where
now, how about [EMAIL PROTECTED] because I have a
feeling that co-maintainers/uploaders get bug reports for a project.
> nnn is the bug number you wish to {,un}subscribe to. You will then need to
> reply to the confirmation email for the action to take effect.
> 
> You will then receive any emails sent to the bug number, as well as
> related messages such as bug closing messages.
> 
> This can be pretty useful to:
> -Keep track of bugs that affect you
> -Know when bug 400,000 gets filed
> -Monitor your NMs
> -Do many other things...
> 
> Many thanks to Joachim Breitner and Don Armstrong who provided most of
> the code, Anthony Towns and Colin Watson for their advice, and everyone
> at Debconf who piped in with suggestions along the way.
> 
> Cheers,
> 
> Pasc
> --
> Pascal Hakim+61 403 411 672
> Do Not Bend
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFC4Koh3+27IiW81b8RAgt6AKDcJiiY1Utq1veaj4C8UwFkaM/uvwCcC3Tg
> JEI8xPZ/4tGql0bQvpVCxJQ=
> =nt+a
> -END PGP SIGNATURE-
> 
> 
> 


-- 
N Jones
Blogging @ http://nigelj.blogspot.com
Proud Debian & FOSS User
Debian Maintainer of: html2ps & ipkungfu

Re: The BTS and bug subscriptions

[Philipp Kern]

On Sat, 2005-07-23 at 00:33 +1200, Nigel Jones wrote:
> now, how about [EMAIL PROTECTED] because I have a
> feeling that co-maintainers/uploaders get bug reports for a project.

Use the package tracking system[1] for this.

Kind regards,
Philipp Kern

[1] http://packages.qa.debian.org



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Benita Hsueh/Toronto/IBM is out of Office @ IBM Mexico

[Benita Hsueh]

I will be out of the office starting  07/17/2005 and will not return until
07/23/2005.

I will have limited connectivity.
If you need immediate assistance, please contact Melody Ng.

Benita.

For NextWave Issues or questions, please contact Paul Rodriguez


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Who needs libcurl3? (was libcurl3-dev: A development package linked again gnutls needed)

[Elimar Riesebieter]

On Mon, 18 Jul 2005 the mental interface of
Domenico Andreoli told:

[...]
> i doubt seriously a new package like libcurl3-gnutls is appropriate,
> but let me know your opinion.
> 
> is this stuff urgent?
Yes!

Elimar

-- 
  Learned men are the cisterns of knowledge, 
  not the fountainheads ;-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Please confirm (conf#1ce969f7398dbe523f2f81436bb3412d)

[Adrian von Bidder]

On Thursday 21 July 2005 20.32, Kirk Reiser wrote:
> << IMPORTANT INFORMATION! >>
>
> This is an automated message.
>
> The message you sent (attached below) requires confirmation
> before it can be delivered. To confirm that you sent the
> message below, just hit the "R"eply button and send this
> message back (you don't need to edit anything). Once this is
> done, no more confirmations will be necessary.
>
> << INFORMAÇÃO IMPORTANTE >>
>
> Esta é uma mensagem automática
>
> A mensagem que você enviou (em anexo) requer confirmação
> antes de ser entregue. Para confirmar o envio basta
> pressionar o botão de "Reply" e enviar esta mensagem de
> volta (não é necessário editar). Uma vez que isto seja
> feito, novas confirmações não serão necessárias.
>
> This email account is protected by:
> Active Spam Killer (ASK) V2.5.0 - (C) 2001-2002 by Marco Paganini
> For more information visit http://www.paganini.net/ask
>
> --- Original Message Follows ---
>
> From: debian-devel@lists.debian.org
> To: [EMAIL PROTECTED]
> Subject: omuxucutbpmajzge
> Date: Thu, 21 Jul 2005 13:35:29 -0500
>
> This is a multi-part message in MIME format.
>
> --=_NextPart_000_0011_3B59FAAF.40318ED4
> Content-Type: text/plain;
>   charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> RЗG8Ëaù¿Ú\{h/nJ#ƒàÇ —„º&
> /³W°eóØ¢KÙ#Ò;êbHG…ÑWB®Zètì”Ü`cm•oƒsW-‘R¦Üðt¼ƒB
>
> :ރsæh­ðFêÚ|
>
> ~´ƒ|Қõ(lÔi]׺¬<[ˆU<ÐÕÇÐBbß«ï†CC×ÔGއi#ú¿à–/üq
> tîÅn/Ú9à/gWî5应ߛ›ÊpНåÆ8xLk9-›ÄN”uƒÁZðn“‡éÜcOڗLµR­¶-3p{bíÃîåD“n] ž‡
>1Sn8YEeeœ1•°.HÒ ýàViЧ¥eò½»ûw¯Þ"K‹®^DSNÁ¡ûÑÚMôþ1”-3¡å[¨ÎæÂ>ÃRö“t#(Ó¬“z.I»Š
> Á¥
> Ÿ†×ù].
> š˜Îœž#f‘Ðû¦•äiRÐñò‰•C`ßJÄÁf‹ƒzÅg,8…¶“rŒE®ÌÚ%`|ù?(è
> 3lJ›ÅŒùþzHkAxXNUúÛåõtÚ9Fu Û
> [—ÓQÓyElµAy’é¢gLÅ/»Ëò8[廾ãZÓ#ö¥EDvS
> ±/‰cÐÏ
> æz¿‰BÁîHë`%iWh?o2O7}!þø;&%OTJN””Ö#3‹Ë‡gÄ©‰¯ÑÕ·õ0UQ¡UBÁg¯*»}Ÿ0?ø£·Xý
>’›±«Õ)pDJ!ÓиXY”Áî.öOä†u^ñöF!Z¨[h›QŸ»ßÎïßàž[®Á*0Â.ìgY£íP$$©-%cŽ„›Ùé¾[¢wmæ
>,H¨Ì˜þNå2;/Sµ²ôcZ P©J»„hÊ"Á¼£ú}p‹M
> ªxÞ/ȞZz؉ úEp“›ÁyíHWSÍLvÞI–•ÃÇىr支2¦ºXߎ½9‡JÑZªÉ^N­«CÀ[ÛIô×ùÖÎe:9
>`ܤçý³.¾KPy^õ®X<—øê²
> à"¬ŠLCÍ؏LH §š7Ň¹ˆœ6ézpOŸ%Í8—ËÐ9ƒŠVô/Æ8ؚ>¸$siÍ%[óë²á[cŠBaâ±Ãv0ÁÉÝXo¶
> v´ EœªÕÇȾE‡
> °8_„D‚Ì°þÖ}JŠÈT÷NMAƒj}]Ø ó¢t¢ïé᝴H³ç
> ;;ì3™¯Ò¤Åƒg
> ZîÀo¦¶×}sŽ7'þ¢ˆU{¸§ÅŽ¥$ˆÓÕƒWÆûï4ÓÒ½Q¢9Ëü¸ÒO¡-—_S¥¨MŽÖlå‡ü¸B†W%æޚì è›|
>mž¸ûéä° )¢2}¾ž“ÈÚòJ]¨-\ÉqjûMwè'kHòDä¢ý¤-Z
> œÂì4¾ýwKDI[Š„«Ø4ÉÀc^Ò6#pOQu§ghh–4
> eA EIøÃ]ÏvˆƒdFäûwr}B±Ž¯
>  
> ^#T"X.œ^”ž©ÃpàJ«R-ñ%0Ìef­¢9ÓÌ"2ä)XBk¶~‹z"F—/¼ùN.¹3AQh” kô~ÄÂʙøŠWÁžG
> ìŽ"âîŸtæ#Èy>Ò>vßÖ½ŸÀWéêTñøFèù‹ï^·s
> ?žäÇëíVmmn6
> ø$좛Þl™H¯Ñr^YõžÔ`ø‰5Ë.Uef.C/®àp4C¨5­™´©Ém,t¼Wí£kJ9 Ò?kÙñh¿Ìh¶°ÆÛðƪĿ·g
>©¼ðþV Ò箺•Àò`ÌN"…Üòcûvœª/½¼3ŠJæ—6Ô5ìç,;ùí~Pšõ¿£øiÏٕ¶{:Øf
>
> >Яû?v9ˆÊ>ulԇÅ6S,Îü¾‹}ƍáI»ÀŒÙq VܤH¦¾hý;£s
>
> 8¶±‚fX.÷¤z‹U‘Å뒻6–ÌÊ0BÀYÉìöOÐ5/Bô“ñ›úAÝÒjßç õHÕPãÉdþ;hµ{©sÆ¡¨XüGC‘Ï(Sˆ.Q
>ìöZ%ð¬â½Ä.ûL;ÝR›gƒêû'h´ò™mò7îvùœ!s}âR…-[.¿§šæÖNá0ɪ<¦‚Q}(f.ïå?s7ô÷hÄóvf
>-ÁòŽjY±²Ú-à?ô.^ýP‰¹c¼Û`]‰§]­žÅ×A˜UÃó·~N2i8*(ç{ëd
> ‘2¦XÜC&”%ö™)[áïè:»—{c7Cu„vî_¡SòÅSd­$–dy
> °‘bDœË¤²Šµ]æV9¦uš£¥SnÙ8²‡2O¸hצ[X5Ì°˜dìTÉ2¨þ ™NLr}fXoîB„ó•Ç^Væ§ã>
> ˆïÆóC&9\iŒšÒìeiÉÝFç˜QèûàªÔ’(h"™™¤’›Nsûc5ÌàÈD³Ù÷‚w* »¼ìg[BÛë‘é(1iÑ)îj6Ýø
>ª^Î^“:ی¨ô:]w‚°âÍ&,ý7Ó&P–¾ž`®]S¹Â„µQuê8B®«×I«ÝHŸ¡
> ÙÅù}.²„÷¿ä‘n1ÑݤOÐOýqû—`·sÞIu.ÄG´uÙ{¯d$iמ‡I¦
> iMò4ÔvÈùŽ
> }ö'¸çÔ9Ïñ8,8†kîvº0õôŠ$?þ©ËaŽ*‘'Ø8sŸÊ3US&QøŽ#WÙæ̧ûàÎÕS±©'ÂZgú}°
> †½kÞxr¨Þ#1¹a¥†t4Y(msûî¹jjЇ]øÂ]ê;zßt‘Õö­Ì°Š]'Fé8­Þ,8Ã|õh…æԄø$¼m±jȉ®µ0â
>ýA¬³UÝ ¶‰To–ÚÉ
> i®ˆL‹›W
> Þ_3Óitn1a†>0Ng
> *ST{ž#ŊÊ:ŸÚZIçîúIHÎ÷ôS‰ÂHú­qŠ1‹m1üD„ûuèØõ”è4CêhÔÚ³q¨LXØi¿r6ð;`Ò¤•©kG˜höm
>Í ÇÁ‹¼F¨R³a`º
> ÊãBe:Ïbý?~©N宩Hì g#ü:iš¨«qŸ
>
>
>
> (Original message truncated)

-- 
All wiyht. Rho sritched mg kegtops awound?


pgpgLJeooaWVe.pgp
Description: PGP signature

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jamie Jones]

On Fri, 2005-07-22 at 12:12 +0100, Jon Dowland wrote:
> On Fri, Jul 22, 2005 at 12:20:45AM +0200, Alexander Fieroch wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > URL: http://www.doomsdayhq.com/index.php
> > License: GPL (see http://sourceforge.net/projects/deng)
> > 
> > Description:
> > 
> > About The Doomsday Engine
> > The Doomsday Engine is an enhanced and extended version of DOOM, 
> > Heretic, and Hexen. It was originally based on the Hexen source code but 
> > parts of it have later been completely rewritten. Doomsday is only an 
> > engine; you will need a Game DLL if you want to play anything. Three 
> > such DLLs are being developed alongside the engine: jDoom, jHeretic and 
> > jHexen.
> 
> I object to doomsday being packaged. The heretic/hexen source code
> licence is utterly incompatible with the GPL, making this package
> technically illegal. It is also very much against the DFSG. See
>  for a similar bug against the existing
> package for doom legacy.
> 
> You could arguably only package the engine + doom library portions, but
> I don't know how much of the heretic/hexen code has made its way into
> those components (if any).
> 
> I am currently trying to start negotiations with the publisher of
> heretic/hexen to relicence under the GPL; this would be the ideal
> solution to this problem (which applies to doomlegacy as alreay
> mentioned, doomsday, the derivative risen3d, another port called vavoom:
> unfortunately, virtually all the doom ports have disregarded the GPL
> in one way or another :( ) anyone interested in progress updates
> should mail me.
> 
G'day Jon,

As the unofficial maintainer for the past 6 months, I'd like to chime in
here. The current version can be built without raven code rather easily
so it could be made DFSG free with no major loss of functionality.

The fact that no attempt has been made to contact me, when I'm listed in
the official wiki, and present in the official forums announcing new
release is disturbing. Us non-DD's don't like having our packages
hijacked either, especially when we are preparing a new release.

In this case no raven code is in the engine, and the doom or heretic
plugins, only the hexen plugin is affected.

Regards
Jamie

Please CC me for a prompt reply, as I read this list as a digest.
-- 
GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments
PGP Key ID 0x4B6E7209
Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209


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

Re: aspell upgrade woes

[Denis Barbier]

[Steve Langasek]
> The best heuristic I can come up with so far is
> 
> dpkg -x $package tmpdir && \
> grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' 
> tmpdir/usr/include
> 
> That may turn up false positives due to the use of common English words, but
> I can't think of a way it could turn up false negatives.

Here is one ;)
  $ export LC_ALL=et_EE.UTF-8
  $ echo '#include ' | grep -E 
'\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>'
  $

When bracket expressions are used within regular expressions of commands
which are influenced by LC_COLLATE (like grep, sed, ...), LC_ALL must be
set to C before running this command.
An alternative way is to replace [a-zA-Z_/] by [[:alpha:]_/] though I am
not 100% sure whether it is mandated that any locale has all ASCII letters
in its alpha character class.
 
Denis


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jon Dowland]

On Sat, Jul 23, 2005 at 04:13:30AM +1000, Jamie Jones wrote:
> G'day Jon,
> 
> As the unofficial maintainer for the past 6 months, I'd like to chime in
> here. The current version can be built without raven code rather easily
> so it could be made DFSG free with no major loss of functionality.

Glad to hear it. In the case of legacy, it's not so clear - and with
their re-write to C++ code, will be nigh-on impossible, so GPLed
heretic/hexen code is the only way out.

> The fact that no attempt has been made to contact me, when I'm listed in
> the official wiki, and present in the official forums announcing new
> release is disturbing. Us non-DD's don't like having our packages
> hijacked either, especially when we are preparing a new release.

I gather you mean the wiki/forum for the doomsday project and not
Debian. I'm suitably out of touch that I wasn't aware doomsday was
available for GNU/Linux natively, yet - I suppose this is what the ITP
process is for. 

'Hijack' seems a bit strong - I can't find an ITP from you - do you ever
intend to submit your package to debian officially?

> In this case no raven code is in the engine, and the doom or heretic
> plugins, only the hexen plugin is affected.

I'll have to take your word for it on the engine, but surely raven code
is in the heretic plugin?

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jon Dowland]

On Fri, Jul 22, 2005 at 10:00:21PM +0100, Jon Dowland wrote:
> I gather you mean the wiki/forum for the doomsday project and not
> Debian. I'm suitably out of touch that I wasn't aware doomsday was
> available for GNU/Linux natively, yet - I suppose this is what the ITP
> process is for. 
> 
> 'Hijack' seems a bit strong - I can't find an ITP from you - do you
> ever intend to submit your package to debian officially?

Reading the wnpp bug
 has answered
these points for me :-)

-- 
Jon Dowland
http://jon.dowland.name/
PGP fingerprint: 7032F238


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: aspell upgrade woes

[Goswin von Brederlow]

Denis Barbier <[EMAIL PROTECTED]> writes:

> [Steve Langasek]
>> The best heuristic I can come up with so far is
>> 
>> dpkg -x $package tmpdir && \
>> grep -rE '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>' 
>> tmpdir/usr/include
>> 
>> That may turn up false positives due to the use of common English words, but
>> I can't think of a way it could turn up false negatives.
>
> Here is one ;)
>   $ export LC_ALL=et_EE.UTF-8
>   $ echo '#include ' | grep -E 
> '\b(use|class|template)\b|::|#include[[:space:]]+<[a-zA-Z_/]+>'
>   $
>
> When bracket expressions are used within regular expressions of commands
> which are influenced by LC_COLLATE (like grep, sed, ...), LC_ALL must be
> set to C before running this command.
> An alternative way is to replace [a-zA-Z_/] by [[:alpha:]_/] though I am
> not 100% sure whether it is mandated that any locale has all ASCII letters
> in its alpha character class.
>  
> Denis

I think he ment something like:

/*
 * This is the C interface to the c++ template class the library is
 * using internaly.
 */

void* get_obj(obj* class_obj);

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

LinuxWorld in San Francisco

[Michael Meskes]

I got no answer on my mail to events-na, does that mean we do not have a
booth there? I will come to attend the show and of course it would be
nice to meet some fellow developers while being in California.

Michael
-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Keyboard lockup after X startup; possible cause

[Nikita V. Youshchenko]

Hello.

Several people probably faced the problem that after initial system bootup, 
and startup of *dm, keyboard does not work.
Suggested workaround was to add implicit 'vtX' parameter to X server 
command line in Xservers file.

I've never seen an explanation of what is actually hapenning, and why that 
workaround helps.

Recently I've installed kde 3.4 packages from experimental on one of my 
systems, and faced that keyboard problem again. And the suggested 
workaround was not possible, because it seems that newer kdm does not use 
Xservers file. After logging into system remotely, I found that X was 
started with 'vt2' parameter.

While trying to fix the situation, I probably guessed what is causing 
lockups.

Unlike some other distributions, Debian treats *dm similar to other 
services, and starts it from /etc/init.d script while syste, startup. So 
*dm is started *before* getty's start for consoles.

Then *dm starts X server which may scan for a free vt (or, in case of 
recent kdm, it scans for a free vt itself).

At this point, there is a race. Either getty's fo vt2-vt6 are already 
started, and search result into "really free" vt, and everything goes ok. 
Or getty is not yet started, and X is started on vt on which later getty 
is started. In this case, getty "initializes" vt *after* X, and into some 
state incompatable with X, and keyboard no longer works.

I don't know which is the correct way to fix it.
Possible ways:

*) ensure that X is never started on vt on which getty is going to be 
started - in this case, having default Xservers files to set explicit vtN 
is enough, and kdm 3.4 should provide some way to ensure that it will not 
choose vt on which getty will be started later,

*) debian should not treat *dm like other services, and start it after 
getty's, not before them

*) some other way?

Nikita


pgpOaeZ4n8Cz7.pgp
Description: PGP signature

Re: The BTS and bug subscriptions

[Don Armstrong]

On Fri, 22 Jul 2005, Peter Samuelson wrote:
> Now ... how hard would it be to add 'submit-subscribe@' support?
> Most of the time, when I submit a bug report, I'd like to subscribe
> to it. Would this be a straightforward hack?

What has actually been discussed is automatically subscribing
submitters to the bug report unless some special header/pseudo-header
is added to prevent that. [It's possible that this subscription would
happen without even needing to confirm the subscription... but that's
still undecided.]


Don Armstrong

-- 
My spelling ability, or rather the lack thereof, is one of the wonders
of the modern world.

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: LinuxWorld in San Francisco

[Don Armstrong]

On Fri, 22 Jul 2005, Michael Meskes wrote:
> I got no answer on my mail to events-na, does that mean we do not
> have a booth there?

No, it merely means that everyone was too lazy to respond.

The booth exists,[1] is being organized,[2] and there will actually be
people there.[3]

> I will come to attend the show and of course it would be nice to
> meet some fellow developers while being in California.

Sure. I think there will be a whole host of us there.


Don Armstrong

1: 
http://www.linuxworldexpo.com/live/12/events/12SFO05A/exposition/exhibitorinfo//QMONYA04NYHY
2: http://lists.debian.org/debian-events-na/2005/07/msg0.html
3: http://wiki.debian.net/?lwe2005
-- 
Democracy means simply the bludgeoning of the people by the people for
the people.
 -- Oscar Wilde

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Goswin von Brederlow]

Don Armstrong <[EMAIL PROTECTED]> writes:

> On Fri, 22 Jul 2005, Peter Samuelson wrote:
>> Now ... how hard would it be to add 'submit-subscribe@' support?
>> Most of the time, when I submit a bug report, I'd like to subscribe
>> to it. Would this be a straightforward hack?
>
> What has actually been discussed is automatically subscribing
> submitters to the bug report unless some special header/pseudo-header
> is added to prevent that. [It's possible that this subscription would
> happen without even needing to confirm the subscription... but that's
> still undecided.]
>
>
> Don Armstrong

That would subscribe every spam the BTS recieves. Very bad I think.

I would rather add a pseudo-header to subscribe and have reportbug ask
if it should add it (or always add it before the editor is forked).

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Florian Weimer]

* Goswin von Brederlow:

>> What has actually been discussed is automatically subscribing
>> submitters to the bug report unless some special header/pseudo-header
>> is added to prevent that. [It's possible that this subscription would
>> happen without even needing to confirm the subscription... but that's
>> still undecided.]

> That would subscribe every spam the BTS recieves. Very bad I think.

Even if we restrict it to initial submitters?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reopening bug close due to SPAM

[Javier Fernández-Sanguino Peña]

reopen 209891
thanks

If spam e-mail is going to start closing our Bugs in the BTS then we should
start thinking about implementing authentication checks in the BTS... like 
for example: do not allow control messages or -close messages with no 
attached (valid) GPG/PGP signatures (from a valid developer?)"


Regards

Javier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)

[Jens Peter Secher]

Steve Langasek <[EMAIL PROTECTED]> writes:

> Below is a list of libraries which appear to be blocking other packages that
> need to go through the C++ transition[1] and which are themselves ready to
> go through the ABI transition.
[...]
> libcrypto++

I am fighting with libcrypto++ but so far I am loosing.  

GCC4 does definitely not like a mix of templates and anonymous enums
[1,2] but there are easy fixes for this.

What is worse, it seems that GCC4 silently refuses to generate code for
some template instantiations, which results in undefined symbols in the
library, as others have experienced [3].  It might however be the case
that GCC4, being more C++ standards compliant, has simply revealed a
problem in the Crypto++ template code.

In any case, the fact is that the non-debian, clean upstream library
code (5.2.1) compiles and links fine with GCC3, but fails to do so with
GCC4.  I am still investigating...
-- 
Jens Peter Secher
_DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20589
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318518
[3] http://www.mail-archive.com/cryptopp-list@eskimo.com/msg02236.html


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Goswin von Brederlow]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow:
>
>>> What has actually been discussed is automatically subscribing
>>> submitters to the bug report unless some special header/pseudo-header
>>> is added to prevent that. [It's possible that this subscription would
>>> happen without even needing to confirm the subscription... but that's
>>> still undecided.]
>
>> That would subscribe every spam the BTS recieves. Very bad I think.
>
> Even if we restrict it to initial submitters?

Not subscribing the initial submitter would be insane and subscribing
him is already the current way. So there would be no change to
discuss.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Don Armstrong]

On Sat, 23 Jul 2005, Goswin von Brederlow wrote:
> Don Armstrong <[EMAIL PROTECTED]> writes:
> > On Fri, 22 Jul 2005, Peter Samuelson wrote:
> >> Now ... how hard would it be to add 'submit-subscribe@' support?
> >> Most of the time, when I submit a bug report, I'd like to subscribe
> >> to it. Would this be a straightforward hack?
> >
> > What has actually been discussed is automatically subscribing
> > submitters to the bug report unless some special header/pseudo-header
> > is added to prevent that. [It's possible that this subscription would
> > happen without even needing to confirm the subscription... but that's
> > still undecided.]
> 
> That would subscribe every spam the BTS recieves. Very bad I think.

No, it wouldn't. The messages are only sent to people after they have
made it through the spam filters, and for sumitter, it's even more
difficult, because the message must be formatted properly to actually
generate a new bug instead of an error.

The idea was for the submitter,[1] not random commenters to the bug,
to receive this special treatment. Everyone else can just send two
messages, one to [EMAIL PROTECTED], the other to
[EMAIL PROTECTED]



Don Armstrong

1: Mainly because the submitter doesn't know yet what the bug number
is that they're supposed to subscribe to.
-- 
Build a fire for a man, an he'll be warm for a day.  Set a man on   
fire, and he'll be warm for the rest of his life.
 -- Jules Bean

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: libcrypto++ (Was: NMUs wanted: C++ library packages in need of uploading)

[Brian M. Carlson]

On Sat, 2005-07-23 at 01:33 +0200, Jens Peter Secher wrote:
> I am fighting with libcrypto++ but so far I am loosing.  
> 
> GCC4 does definitely not like a mix of templates and anonymous enums
> [1,2] but there are easy fixes for this.
> 
> What is worse, it seems that GCC4 silently refuses to generate code for
> some template instantiations, which results in undefined symbols in the
> library, as others have experienced [3].  It might however be the case
> that GCC4, being more C++ standards compliant, has simply revealed a
> problem in the Crypto++ template code.
> 
> In any case, the fact is that the non-debian, clean upstream library
> code (5.2.1) compiles and links fine with GCC3, but fails to do so with
> GCC4.  I am still investigating...

I have experience with porting it to 3.3 or 3.4, I don't remember which.
Some minor restructuring of the code is necessary, but I'll look at it.
Feel free to mail me off-list if you want.

I'll be working on the Debian code, since that likely has fewer problems
(missing some patent-encumbered parts, like IDEA).
-- 
($_,$a)=split/\t/,join'',map{unpack'u',$_};eval$a;print;__DATA__
M961H<[EMAIL PROTECTED];"!U2QA8F-D969G:&EJ:VQM;F]P<7)S='5V=WAY>BQN=V]R8FMC
5:75Q96AT9V1Y>F%L=G-P;6IX9BP)



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

Re: Reopening bug closed due to SPAM

[Anthony DeRobertis]

Javier Fernández-Sanguino Peña wrote:

> If spam e-mail is going to start closing our Bugs in the BTS then we
> should
> start thinking about implementing authentication checks in the BTS...
> like
> for example: do not allow control messages or -close messages with no
> attached (valid) GPG/PGP signatures (from a valid developer?)"

Spammers aren't targeting the BTS on purpose; they're doing it by mistake.

We could just use something simple, like a phrase that must occur in the
message for the BTS to act on the message sent to
[EMAIL PROTECTED] This is also probably far more trivial to
implement than GPG. And compatible with any mailer, unlike additional
headers.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: The BTS and bug subscriptions

[Jochen Voss]

Hi Goswin,

On Sat, Jul 23, 2005 at 01:55:19AM +0200, Goswin von Brederlow wrote:
> subscribing [the initial submitter] is already the current way.
Really?  Since when is this the case?

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

(no subject)

[Shorty550]

can u please remove the call waves from my computer please Thnk you very 
much
 

 

Re: (no subject)

[Ryan Schultz]

On Saturday 23 July 2005 12:07 am, [EMAIL PROTECTED] wrote:
> can u please remove the call waves from my computer please Thnk you very 
> much
Hello Shorty550,
This is debian-devel, a mailing list for developers of the Debian GNU/Linux 
system, which doesn't relate to the Windows program Callwave in any way.
Please see:

http://www.mail-archive.com/debian-devel%40lists.debian.org/msg10770.html

for instructions on removing Callwave from your computer

---
For -devel... does anyone know why this list receives so many questions about 
Callwave? A sample:

http://lists.debian.org/debian-devel/2005/06/msg01421.html
http://lists.debian.org/debian-devel/2004/08/msg00724.html
http://lists.debian.org/debian-devel/2004/08/msg00864.html
http://lists.debian.org/debian-devel/2004/08/msg01826.html
http://lists.debian.org/debian-devel/2004/08/msg00467.html
http://www.mail-archive.com/debian-devel%40lists.debian.org/msg07400.html

I mean, a -devel post is the first answer for a Google search for 'howto 
uninstall callwave'...

-- 
Ryan Schultz
-> floating point exception: divide by cucumber


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: doomsday not DFSG (was Re: ITP: doomsday - greatly improved engine to play doom, doom2, heretic and hexen)

[Jamie Jones]

On Fri, 2005-07-22 at 22:00 +0100, Jon Dowland wrote:
> On Sat, Jul 23, 2005 at 04:13:30AM +1000, Jamie Jones wrote:
> > G'day Jon,
> > 
> > As the unofficial maintainer for the past 6 months, I'd like to chime in
> > here. The current version can be built without raven code rather easily
> > so it could be made DFSG free with no major loss of functionality.
> 
> Glad to hear it. In the case of legacy, it's not so clear - and with
> their re-write to C++ code, will be nigh-on impossible, so GPLed
> heretic/hexen code is the only way out.
> 
> > The fact that no attempt has been made to contact me, when I'm listed in
> > the official wiki, and present in the official forums announcing new
> > release is disturbing. Us non-DD's don't like having our packages
> > hijacked either, especially when we are preparing a new release.
> 
> I gather you mean the wiki/forum for the doomsday project and not
> Debian. I'm suitably out of touch that I wasn't aware doomsday was
> available for GNU/Linux natively, yet - I suppose this is what the ITP
> process is for. 
> 
> 'Hijack' seems a bit strong - I can't find an ITP from you - do you ever
> intend to submit your package to debian officially?

After sleeping on it, yes hijack does seem a bit strong, but after a bad
day, then downloading my mail to see an ITP on a package that has been
kept out for a reason, I felt rather unhappy.

> 
> > In this case no raven code is in the engine, and the doom or heretic
> > plugins, only the hexen plugin is affected.
> 
> I'll have to take your word for it on the engine, but surely raven code
> is in the heretic plugin?
> 

See for yourself, grab my package or upstreams tarball and grep for
Raven. Most of the Raven code is from Heretic 2 and Hexen 2 anyway.

Doomsday (or Deng as upstream and I refer to it) is the cleanest
implementation in regards separation of the different game logic and
features. The plugins are basically .so files, so if you want to play
doom, you load the jdoom plugin, you want hexen, you load the jhexen
plugin.

The problem with legacy and the other ports mentioned is that this logic
wasn't separated so that they could function without the raven code. The
biggest problem is that many new wads (game levels) support hexen
features in a doom wad (I believe that they call this zdoom format). By
supporting zdoom format and not using a plugin they then fail the DFSG
test with regards to the raven code. Deng doesn't even support Boom
format (an extension to the GPL Doom wad format) that was the cause for
a fork some time ago.

Regards
Jamie

For anyone wanting to actually try the game to see what all the fuss is
about, http://eyagi.bpa.nu/~jamie/doomsday.html has details on just
exactly what is packaged and how to get it.
-- 
GPG/PGP signed mail preferred. No HTML mail. No MS Word attachments
PGP Key ID 0x4B6E7209
Fingerprint E1FD 9D7E 6BB4 1BD4 AEB9 3091 0027 CEFA 4B6E 7209


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

Re: Keyboard lockup after X startup; possible cause

[Finn-Arne Johansen]

Nikita V. Youshchenko wrote:
> Hello.
> 
> Several people probably faced the problem that after initial system bootup, 
> and startup of *dm, keyboard does not work.
> Suggested workaround was to add implicit 'vtX' parameter to X server 
> command line in Xservers file.

I had a similar problem, using lessdisks as a diskless workstation,
where kdm left the keyboard unresponsive, but gdm worked. The fix was to
tell kdm to use /dev/urandom as randomDevice.

Dont remember the bug number, not sure if I filed it against Debian BTS,
but at least I filed it against kdm in KDE BTS, and the problem should
be gone in upstream KDE.


-- 
Finn-Arne Johansen
Debian-edu maintainer


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Thu, 21 Jul 2005 16:02:21 +0200, Olaf van der Spek <[EMAIL PROTECTED]> said: 

> On 7/21/05, Thaddeus H. Black <[EMAIL PROTECTED]> wrote:
>> I see another side to it, however.  At least seven reasons occur to
>> me why a user might care what language a program is written in.

> A 'normal' user doesn't know what C, C++ and Perl are.

The "user" I am creating packages for does.  I am not really
 that interested in working for user who do not know the distinction,
 personally speaking.

manoj
-- 
Meade's Maxim: Always remember that you are absolutely unique, just
like everyone else.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Removal of transitional dummy packages

[Manoj Srivastava]

On Fri, 22 Jul 2005 12:57:14 +0200 (CEST), Santiago Vila <[EMAIL PROTECTED]> 
said: 

> I see your point, but policy has never been a "permanent" thing.

I have no idea where you get this impression.

> For some time we have had a policy which mandated symlinks in
> /usr/doc. Later we had exactly the "opposite" policy, one that does
> not mandate symlinks in /usr/doc.

There was a transition plan in progress, in which had
 compatibility links in place for an extended period, and which every
 developer had to follow, or else.

> Sometimes there is a policy which recommends something which is
> later changed to a "should", then to a "must". In this case,
> however, we are switching from "dummy packages for upgrades which
> skip releases are allowed" to "somebody is going to file bugs on
> them without asking the maintainer first and ftp.debian.org will
> honor the reports".

No. The practice has always been to mandate smooth upgrades
 between revisions, and support for upgrades skipping a release being
 a desirable feature, but not a hard requirement. What is happening
 here is saying that woody to etch is not feasible, due to the
 large delta, so the dummy packages re cruft this time around.

This is a far cry from a policy that says that support for
 upgrades skipping versions should be dropped for the future.

> I think this is more like "things we do to support upgrades from
> oldstable are considered cruft and it's ok and even desirable to
> remove them".  This is not limited to dummy packages, but it also
> includes versioned dependencies on essential packages which
> everybody has now installed, and special hacking in maintainer
> scripts. If we are going to remove things because they are
> considered cruft, it would be very good to have a common and
> consistent definition of "cruft".

The definition of cruft is packages kept around for an upgrade
 path that does not ecist; in this case, woody -> etch upgrades
 can't be done. Not that the upgrade was deprecated, by policy or
 otherwise, but the changes made the upgrade path disappear,
 unfortunately.

So woody _> etch dummy packages are cruft; Sarge -> Etch +1
 may or may not be.

> There was a tentative policy regarding upgrades in Bug #34672 (you
> can skip all the flames and go directly to the last message...), but
> it diverges significatively from current practice. What I would like
> to see in policy is our current practice, whatever it is.

Yeah, raul kinda proposed that maintianrs must support
 upgrades from oldstable, but the release team has said that this is
 not feasible. I think the release team has the final words here.

manoj
-- 
It's time to boot, do your boot ROMs know where your disk controllers
are?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Thu, 21 Jul 2005 15:08:43 -0300, Ben Armstrong <[EMAIL PROTECTED]> said: 

> On Thu, 2005-07-21 at 19:58 +0200, Thijs Kinkhorst wrote:
>> nstead of putting it in the first sentence, the second paragraph
>> would be a fine place to mention details like this, satisfying both
>> novice and advanced users.

> But why bother, when debtags does "implemented-in" does the job
> better?

Because that information is not presented to me in aptitude,
 one of the preferred front ends to package management.  Once the deb
 tags system gets integrated into the front ends, the long description
 can stop shouldering some of the load of presenting all the
 useful/relevant infdormation to the user interested in making an
 informed decision.

manoj
-- 
I want to dress you up as TALLULAH BANKHEAD and cover you with
VASELINE and WHEAT THINS ...
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Usability: Technical details in package descriptions?

[Andreas Tille]

On Sat, 23 Jul 2005, Manoj Srivastava wrote:


A 'normal' user doesn't know what C, C++ and Perl are.


   The "user" I am creating packages for does.  I am not really
that interested in working for user who do not know the distinction,
personally speaking.

So your "personal" target user might be able to find out the programming
language himself and mentioning it in the description is also redundant.
--> We found another reason to leave the language out of the description.

Thanks

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Usability: Technical details in package descriptions?

[Manoj Srivastava]

On Thu, 21 Jul 2005 12:33:32 -0300, Ben Armstrong <[EMAIL PROTECTED]> said: 

>> 2.  Programs written in obscure languages may prove unmaintainable
>> if
>> the original developer disappears.  Besides threatening
>> obsolescence, this can be a security issue.

> You've furnished a reason *not* to put the language in the
> description (if I wrote a package in an "obscure" language and took
> your point to heart, I'd not want to advertise the fact).  Besides,
> what is obscure?  Ruby?  Ocaml?  Snobol?  Fortran?  Scheme?  How is
> a user to assess whether these are up-and-coming languages, less
> popular but still well supported, or completely obsolete?  I doubt
> if most users know the difference.

   BZZZT. The idea is not to con the user into using the package willy
   nilly, the idea is to provide him enough information to make an
   informed choice.

If providing you with information about the implementation
 language causes you to change your decision, then delibrately
 withholding that information is akin to fraud and underhanded dealing
 we should steer clear off.

> Now we're *really* getting touchy-feely.  I think we're losing sight
> of the goal: the user, reading the description, should get a sense
> of what the package does, whether it is likely to meet their needs,
> and whether it offers distinct advantages over any of the
> alternatives.  While I can appreciate that some small minority of
> users out their are aware of the "mindset", "aesthetic" and
> "development culture" of an implementation language, and therefore
> have some mild bias towards packages implemented in it, it certainly
> isn't a primary indicator of whether the package is suitable for a
> particular use or not.

I also select a program based on languages I know; since it
 makes it more likely that I can tweak the program rto my needs, or
 help with stalled development. Given a choice, I would invest in the
 learning curve of programs I can help modify, develop, and contribute
 to. 

Since I find the information useful, I am not going to pretend
 my suers are idiots who couldn't possibly make use of such
 iformation, because, you see, I am so special, and only I can use the
 information, not the oh so dumb users.

So, I am going to continue to provide information in the
 descriptions of my packages that I would find useful, in the hopes
 that it is useful to the users of my packages as well.

manoj
-- 
Encyclopedia for sale by father.  Son knows everything.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]