Re: Please don't misuse the debian/changelog to close bugs!

[John H. Robinson, IV]

Herbert Xu wrote:
> Gerfried Fuchs <[EMAIL PROTECTED]> wrote:
> 
> > * New upstream release (closes: #123) which includes:
> >   - tmpfile race condition fix (closes: #124)
> >   - manual page included (closes: #125)
> > 
> > The thing is: It helps the users and the person who reported the bug to
> > see what bug exactly was closed without the need for them to dig in the
> > BTS. This is no must but it is something your users would be greatful if
> > you could do it.
> 
> As I have said before, this is incomplete: only bugs that were reported
> and identified are listed, and redundant: these changes should be in
> the upstream changelog already.

in that case you can do this:

* New upstream release

and then use [EMAIL PROTECTED] to close the bugs, and everyone has a
wonderful day.


you say ``should be in the upstream changelog already.'' what about
those cases when they are not listed?

either case, you can still use control or 123-done.

-john

Re: Bug#198682: ITP: kernel-patch-2.4-low-latency -- Reduces the latency of the Linux kernel

[Tollef Fog Heen]

* Aurelien Jarno 

It's already packaged:

[...]

| * Package name: kernel-patch-2.4-low-latency
|   Upstream Author : Andrew Morton <[EMAIL PROTECTED]> 
| * URL : http://www.zip.com.au/~akpm/linux/schedlat.html
| * License : GPL
|   Description : Reduces the latency of the Linux kernel

[...]

: [EMAIL PROTECTED] ~ > apt-cache show kernel-patch-lowlatency-2.4 
Package: kernel-patch-lowlatency-2.4
[...]

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

Re: Bug#198158: architecture i386 isn't i386 anymore

[Tollef Fog Heen]

* GOTO Masanori 

|   - NPTL/TLS support.  NPTL currently supports i486 and later because
| pthread_spin_trylock uses cmpxchgl instruction (well, it's not
| difficult to support i386, but imagine pthread on i386 with the
| max clock (I recall it was 20MHz?) speed and memory...)

33MHz, and ISTR that AMD made a 40MHz version as well.

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

Re: Packages: an average 66321 bytes per line of description

[Thomas Viehmann]

Daniel Burrows wrote:
> On Tue, Jun 24, 2003 at 04:15:29PM -0500, Steve Langasek <[EMAIL PROTECTED]> 
> was heard to say:
> 
>>>Not all of it, but you can't object to duplicating a single sentence saying
>>>what it is.
>>
>>When the sentence in question is the one that goes in the short
>>description, and already fills the available space without prepending
>>"runtime files for foo "?  Is the concern here with the short descs (I
>>don't expect much from short descs of affiliate packages), or with the
>>long descs?
>   Long descriptions.  See, eg,
>   libchipcard20-dev
So this should read like:
 libchipcard20 provides an API for accessing smartcards. Examples are memory
 cards, as well as HBCI (home banking), German GeldKarte (electronic
 small change), and KVK (health insurance) cards. This package contains
 all you need to develop for libchipcard20, namely includes etc.
 Upstream homepage is .
?

I'll update the description, but I don't know what get's said there that hasn't
been said before.

Cheers

T.


pgpE3wa7ipwlT.pgp
Description: PGP signature

Re: no freshness dating inside Packages.gz

[Andrew Pollock]

On Mon, Jun 23, 2003 at 03:14:26PM +0200, Martin Schulze wrote:
> > 
> > It is unfortunate, that there is no easy access to the changelog, I know of,
> > but all other infos can be seen on the package tracking system:
> 
> I guess that you've never heard of
> 

Any reason this functionality can't be incorporated into 
packages.debian.org?

Andrew

Re: maildirmake

[Andreas Metzler]

Brian May <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 24, 2003 at 08:19:35AM +0200, Andreas Metzler wrote:
>> You could start by telling us what maildirmake is supposed to do. Why
>> do we need it? Any program I know of which can handle Maildir is not
>> only capable of storing messages in Maildir folders but also of
>> generating them. This includes e.g. the exim(4) MTA, MDAs like
>> procmail or maildrop, and the MUA mutt.

> As far as I am aware, maildrop does *not* support creating Maildirs.

> Even if it does support creating top level Maildir (last I tested it
> didn't seem to), it doesn't support creating a maildir within a maildir
> (this apparently is a bit different, and it used by courier-imap). You
> do with with maildirmake (or at least the version I have installed) with
> the -f option.

> See bug #68685 for details.

Thanks for clarification. BTW iirc support for maildir within a maildir
(i.e. a mailfolder containing both messages and subfolders) is a
little bit more limited than basic maildir support, some clients
support basic maildir but not maildir within a maildir. I just cannot
remember which ones, perhaps Debians patched versions of pine/UW-IMAP?

I agree that debianutils could be the correct package.
  cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Andreas Metzler]

Marek Habersack <[EMAIL PROTECTED]> wrote:
>  Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> actually setting the file ownership to root (or any other uid/gid for that
> matter).
[...]

Either there is a big misunderstanding or a big bug in 2.5.73+.
Are you saying that using fakeroot I can actually do this?

touch /tmp/breaking.alice.quota
chmod 666 /tmp/breaking.alice.quota
fakeroot chown alice /tmp/breaking.alice.quota
cat < /dev/zero  > /tmp/breaking.alice.quota

 cu andreas
-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/

Re: Please don't misuse the debian/changelog to close bugs!

[Andreas Metzler]

Herbert Xu <[EMAIL PROTECTED]> wrote:
> Gerfried Fuchs <[EMAIL PROTECTED]> wrote:
 
>> During some of the discussions lately on debian-devel another usage of
>> the changelog has risen interest:
 
>> * New upstream release (closes: #123, #124, #125)
 
>> This has also raised some discussions. The thing is this: If #123,
>> #124 and #125 aren't just "New upstream version available" bugreports
>> then quite some people dislike this behavior. It shouldn't be too much
>> hazzle for the maintainer to rewrite this as follows:

> I strongly disagree with your view.  Please respond to my points
> that have been raised previously rather than repeating this dogma.
[...]

Hello,
Could we pretty please let this rest? Both side's arguments have
already been reiterated a thousand times in the Bug#193497-thread.

 cu and- it was difficult to keep myself from really responding and
  restarting the thread, I hope it pays off. - dreas

Re: maildirmake

[Wouter Verhelst]

On Tue, Jun 24, 2003 at 02:34:39AM +0200, [EMAIL PROTECTED] wrote:
> Hello Debian-Developers,
> 
> first, many thanks all of you for your great work.  As I am not a pro, I am
> very glad that most of Debian works out-of-the-box.
> 
> But, I was looking around and wondering about that I couldn't find any
> `maildirmake' for Debian, excluding qmail-src, courier and maildrop, which I 
> don't
> want/don't need to use.  Furthermore I'd like to stay with a very small and
> clean and free system (only usage of apt-get, don't install any unnecessary
> packages).
> 
> After searching the web and the debian-pages (for a _long_ time vs. prior
> problems) I found this:
> 
> http://lists.debian.org/debian-devel/2000/debian-devel-21/msg01717.html
> http://lists.debian.org/debian-devel/2000/debian-devel-21/msg01719.html
> 
> http://lists.debian.org/debian-user/2002/debian-user-200206/msg02259.html
> http://lists.debian.org/debian-user/2002/debian-user-200206/msg02261.html
> http://lists.debian.org/debian-user/2002/debian-user-200206/msg02278.html
> 
> Now I'm wondering about it even more.  IMHO `maildirmake' is _very_
> necessary for any mail and as it seems to be only a 2-line-shell-script why 
> it isn't
> included anywhere and anyway in the base-system?

Sorry about hopping in on this so late...

if you're using exim with maildirs, and the maildir doesn't exist yet
when a mail arrives, exim will create the maildir on the fly.

Which means that this could also be achieved by sending a standard
'welcome' mail to new users when you create them (which is good practice
anyway :-)

-- 
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts." 
  -- National Geographic Channel, in a documentary about large African beasts.

Re: Bug #193271: galeon: should register in /etc/alternatives/x-www-browser

[Mark Howard]

Hi,
  I've been unable to find documentation about how we're supposed to
choose a priority for alternatives. It seems like every web browser
maintainer likes their browser the most, so wants it to be the highest.
I'm CC'ing debian-devel in the hope that somebody will be able to point
me in the direction of some useful documentation, or at least help
resolve the problem with web browsers.
  The comment below seems valid - the most common browsers should have
the lowest number, but what should this be (in general)?

On Mon, 2003-06-23 at 20:37, Soeren Sonnenburg wrote:
> On Mon, 2003-06-23 at 18:57, Mark Howard wrote:
> > Followup-For: Bug #193271
> > Package: galeon
> > Why?
> 
> well ok, you will probably argue that I could use update-alternatives 
> --config x-www-browser
> and thus select galeon manually...
> 
> However *IMO* mozilla and friends are the defacto standard and thus if one 
> indeed installs
> a browser like galeon it should get higher priority than those standard 
> browsers...
> 
> well definitely not as high as the kde guys did with konqueror... 
> 
> x-www-browser - status is manual.
>  link currently points to /usr/bin/galeon
> /usr/bin/epiphany - priority 75
> /usr/bin/mozilla - priority 80
>  slave x-www-browser.1.gz: /usr/share/man/man1/mozilla.1.gz
> /usr/bin/galeon - priority 10
>  slave x-www-browser.1.gz: /usr/share/man/man1/galeon.1.gz
> /usr/bin/MozillaFirebird - priority 70
> /usr/bin/konqueror - priority 100
> /usr/bin/mozilla-snapshot - priority 1
>  slave x-www-browser.1.gz: /usr/share/man/man1/mozilla-snapshot.1.gz
> Current `best' version is /usr/bin/konqueror.
> 
> 
-- 
  .''`. Mark Howard
 : :' :
 `. `'  http://www.tildemh.com 
   `-   [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] 

Re: Bug#198682: ITP: kernel-patch-2.4-low-latency -- Reduces the latency of the Linux kernel

[Aurelien Jarno]

On Wed, Jun 25, 2003 at 07:43:34AM +0200, Tollef Fog Heen wrote:
> It's already packaged:
[...]

> : [EMAIL PROTECTED] ~ > apt-cache show kernel-patch-lowlatency-2.4 
> Package: kernel-patch-lowlatency-2.4

Oops ! Sorry, closing the bug...

I searched with apt-cache for low-latency and it didn't give me this
package. However, lowlatency give this package in the results...

Re: Bug#198158: architecture i386 isn't i386 anymore

[Branden Robinson]

On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote:
> * GOTO Masanori 
> 
> |   - NPTL/TLS support.  NPTL currently supports i486 and later because
> | pthread_spin_trylock uses cmpxchgl instruction (well, it's not
> | difficult to support i386, but imagine pthread on i386 with the
> | max clock (I recall it was 20MHz?) speed and memory...)
> 
> 33MHz, and ISTR that AMD made a 40MHz version as well.

Yup.  AMD also made the fastest 486 ever[1], clocked at 133MHz.  My
first Linux box (also my first Debian box) ran on that chip.

[1] to my knowledge

-- 
G. Branden Robinson|  It doesn't matter what you are
Debian GNU/Linux   |  doing, emacs is always overkill.
[EMAIL PROTECTED] |  -- Stephen J. Carpenter
http://people.debian.org/~branden/ |


pgpeKA09VOTK2.pgp
Description: PGP signature

Bug#198158: architecture i386 isn't i386 anymore

[Branden Robinson]

On Fri, Jun 20, 2003 at 09:51:07AM +0200, Matthias Klose wrote:
> The solution I would favour would be:
> 
> - drop the i386 support
> 
> - keep the i386 architecture name
> 
> - let dpkg-architecture output the new configuration string
>   (i.e. i486-linux)
> 
> - if anybody wants to start the mini-i386 architecture, we have to
>   find an architecture name for it.
> 
> changing the dpkg-architecture's ARCH string to i.e. i486 would break
> a lot of build scripts ...
> 
> comments welcome.
[...]
> Hmm... I'm not sure about this as the last time I used assembler was 
> in the times of real mode DOS, but there is a yet another option:
> we can patch the kernel so when an invalid opcode occurs, whatever 
> instruction was at CS:EIP gets emulated in software, similar to the
> way i387 emulation is done.
> (arch/i386/kernel/entry.S)
> Of course, this would further slow down the speed demon known as 80386,
> but since (AFAIK) the 486-specific opcodes get used pretty rarely in 
> non-kernel code, the performance hit wouldn't be crippling.  And, there
> is no performance hit at all for >386 machines, as no legitimate process
> ever triggers the invalid opcode fault.

If this indeed feasible, then this is the solution that appeals most to
me personally.

* It seems the least intrusive.  80386 users are probably going to want
  and use an 80386-specific kernel, if they don't already *have* to.
* Our hand is forced by the fact that the rest of the Linux distributors
  in the world, and apparently the GCC folks, don't care about C++ ABI
  portability to 80386 processors.
* This doesn't require recompiling anything except the kernel.

The drawbacks:
* Someone actually has to write this kernel patch.

Also, Herbert Xu, the 80386 kernel-flavor maintainer, would have to be
agreeable, and I don't believe I saw him offer an opinion on this
approach in this discussion.

I believe it would be a mistake to kill off support for the 80386 chip.

-- 
G. Branden Robinson|  "There is no gravity in space."
Debian GNU/Linux   |  "Then how could astronauts walk
[EMAIL PROTECTED] |   around on the Moon?"
http://people.debian.org/~branden/ |  "Because they wore heavy boots."


pgpLuaK3S5tNT.pgp
Description: PGP signature

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Branden Robinson]

On Fri, Jun 20, 2003 at 05:53:09PM +0200, Javier Fernández-Sanguino Peña wrote:
> I was wondering, should I make a mass filing of bugs for those packages 
> who fail to produce a proper description? 

Go for it.  I'm tired of people who care about our users so little that
they will not properly describe the package.

It also makes me wonder, sometimes, if they actually understand their
package well enough to coherently describe what it does to someone else.

-- 
G. Branden Robinson|   The software said it required
Debian GNU/Linux   |   Windows 3.1 or better, so I
[EMAIL PROTECTED] |   installed Linux.
http://people.debian.org/~branden/ |


pgpW8Dw2btEk2.pgp
Description: PGP signature

Re: ITP: libtext-charwidth-perl, libtext-wrapi18n-perl

[Branden Robinson]

On Sat, Jun 21, 2003 at 11:18:56AM -0400, Joey Hess wrote:
> > License: perl
> 
> Be careful of the tough new perl licensing policy of the ftp master.
> :-/

It's not the archive admins' fault that some Perl geeks have a reckless
approach to licensing.

-- 
G. Branden Robinson|Somebody once asked me if I thought
Debian GNU/Linux   |sex was dirty.  I said, "It is if
[EMAIL PROTECTED] |you're doing it right."
http://people.debian.org/~branden/ |-- Woody Allen


pgp6gBjU73mka.pgp
Description: PGP signature

Re: Packages: an average 66321 bytes per line of description

[Branden Robinson]

On Tue, Jun 24, 2003 at 03:17:27PM +0800, Dan Jacobson wrote:
> I was hoping large package developers would write longer descriptions.

Read mine sometime.  (You'd be one of the first to do so!)

-- 
G. Branden Robinson| You are not angry with people when
Debian GNU/Linux   | you laugh at them.  Humor teaches
[EMAIL PROTECTED] | them tolerance.
http://people.debian.org/~branden/ | -- W. Somerset Maugham


pgpYEVRzVMAqe.pgp
Description: PGP signature

Re: Packages: an average 66321 bytes per line of description

[Branden Robinson]

On Tue, Jun 24, 2003 at 09:12:06AM -0400, Stephen Frost wrote:
> * Dan Jacobson ([EMAIL PROTECTED]) wrote:
> > I was hoping large package developers would write longer descriptions.
> 
> Too bad.  The two are not, should not, and should never be related.

I wouldn't say they're strictly decorrelated.  File count should be more
closely correlated with description length, though.

(Still, both are going to be pretty loose.)

-- 
G. Branden Robinson|
Debian GNU/Linux   |   Extra territorium jus dicenti
[EMAIL PROTECTED] |   impune non paretur.
http://people.debian.org/~branden/ |


pgpQ1foV1j8rl.pgp
Description: PGP signature

Re: ITP: libtext-charwidth-perl, libtext-wrapi18n-perl

[Tomohiro KUBOTA]

Hi,

Joey Hess wrote:
> s/Get/get/;
> s/softwares/software/;
> s/width of characters (and strings)? on terminal/
>   display width of characters and strings on the terminal/x;
> (or at least, s/on terminal/on the terminal/)
> s/in C/from libc/;
(etc, etc)

I see.  I will prepare new packages.


>> License: perl
>
> Be careful of the tough new perl licensing policy of the ftp master.
> :-/

You mean the problem written in the following mail?
http://lists.debian.org/debian-legal/2003/debian-legal-200302/msg00039.html

For example, is it OK to write like following?

--
Copyright (C) 2003 Tomohiro KUBOTA <[EMAIL PROTECTED]>

This library is free software; you can redistribute it and/or modify
it under the terms of either:

a) the GNU General Public License as published by the Free Software
   Foundation; either version 1, or (at your option) any later
   version, or

b) the "Artistic License" which comes with Perl.

On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in `/usr/share/common-licenses/GPL' and
the Artistic Licence in `/usr/share/common-licenses/Artistic'.
--


---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Branden Robinson]

On Tue, Jun 24, 2003 at 02:44:17PM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Tue, Jun 24, 2003 at 09:30:31PM +0200, Marek Habersack wrote:
> [...]
> >   Description : The pmk project aims to be an alternative to 
> > GNU/autoconf (configure scripts).
> 
> Description field is inappropriate, use something like:
> 
> Description: A GNU/autoconf alternative.

You mean something like:

Description: alternative to GNU autoconf source code configuration system

* lose the article
* lose the full stop
* do not capitalize the beginning of the description unless a proper
  noun, proper adjective, abbreviation, or acronym requires it
* I don't know what GNU/autoconf is.  Is that like GNU/Linux?
* short description still doesn't help people who don't know what
  autoconf is

-- 
G. Branden Robinson|Somewhere, there is a .sig so funny
Debian GNU/Linux   |that reading it will cause an
[EMAIL PROTECTED] |aneurysm.  This is not that .sig.
http://people.debian.org/~branden/ |


pgpzjoUqs9F7A.pgp
Description: PGP signature

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Sven Luther]

On Tue, Jun 24, 2003 at 05:09:24PM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Tue, Jun 24, 2003 at 10:59:19PM +0200, Marek Habersack wrote:
> > It's not quite a substitute, as it won't reuse autoconf's configs etc. How
> > about "A tool for configuring software source similar to GNU Autoconf"?
> 
> I see your point, but your suggestion is still too long: it should be
> rephrased to stay within 60-65 characters.

I though the limit was 60 chars, as stated in one of the debian
documents.

Friendly,

Sven Luther

Re: Old bugs related to translated debconf templates

[Branden Robinson]

On Wed, Jun 25, 2003 at 12:04:29AM +0200, Denis Barbier wrote:
> 135965 (27 Feb 2002) xfree86v3   Branden Robinson

I've been asking for someone to co-maintain this package.

I'm still asking.

-- 
G. Branden Robinson| Reality is what refuses to go away
Debian GNU/Linux   | when I stop believing in it.
[EMAIL PROTECTED] | -- Philip K. Dick
http://people.debian.org/~branden/ |


pgpgvLAW1oedI.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Colin Walters]

On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:

> I believe it would be a mistake to kill off support for the 80386 chip.

Well, we're limited by what we can sanely support.  After all, we don't
support running Debian on a 286.  The 386 is really in the same class
nowadays, in my opinion anyways.  

We should foist the job of supporting i386 onto some specialized Debian
port for it.  If they don't come into existence, that just is another
nail in the i386 coffin.

Re: Bug#198158: architecture i386 isn't i386 anymore

[David Goodenough]

On Wednesday 25 June 2003 08:40, Branden Robinson wrote:
> On Wed, Jun 25, 2003 at 07:47:42AM +0200, Tollef Fog Heen wrote:
> > * GOTO Masanori
> >
> > |   - NPTL/TLS support.  NPTL currently supports i486 and later because
> > | pthread_spin_trylock uses cmpxchgl instruction (well, it's not
> > | difficult to support i386, but imagine pthread on i386 with the
> > | max clock (I recall it was 20MHz?) speed and memory...)
> >
> > 33MHz, and ISTR that AMD made a 40MHz version as well.
>
> Yup.  AMD also made the fastest 486 ever[1], clocked at 133MHz.  My
> first Linux box (also my first Debian box) ran on that chip.
>
> [1] to my knowledge

and remember that many embedded processors still use 486 and 586
based chips, and some 386.  Lossing 386 might be acceptable in the
embedded market (many 386 based systems have too little memory
to run Debian) but loosing 486 and 586 would mean that Debian was
no longer an option for embedded systems which would be a great
loss.

David

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Luca - De Whiskey's - De Vitis]

On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote:
> * lose the article

Why?

> * do not capitalize the beginning of the description unless a proper
>   noun, proper adjective, abbreviation, or acronym requires it

Why?

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.


pgpwos4bClfF7.pgp
Description: PGP signature

Retirement, etc

[Joseph Carter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

With work, school, and taking part to some extent in my local community, I
have had virtually no free time to devote to Debian for many months now.
Having just received my approval of my application to transfer to the
University of Oregon, I know that I will need to focus even more on my
education, and therefore it's a safe bet that nobody would hear from me
for at least another couple of years.

I've only got a couple of packages at this point.  xfonts-jmk requires
virtually no maintenance except when X11 font policies change or that
distant time when the UTF truetype jmk font gets released.  (I'll believe
it when I see it..)  yadex I packaged years ago for someone else who was
going through NM and gave up on it.  I've never really been able to use
the program myself, so it has been essentially non-maintained for years.
Either package is up to the first bidder.  I'm sure you'll all figure it
out - I'm busy with a few quick summer credits before I transfer.


Take care everyone!  =)

- -- 
Joseph Carter <[EMAIL PROTECTED]> This sentence no verb.
 
 my computer was once one of the building blocks of a great
  pyramid
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: 1024D/20F62261F1857A3E79FC44F98FF7D7A3DCF9DAB3

iEYEARECAAYFAj75Zp0ACgkQj/fXo9z52rNJuACcDra68XQ9ixkQibUsl/gBxIaz
ED0An1R8/eidYzzICts3x8lYQZ2S2cG8
=0USh
-END PGP SIGNATURE-

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Luca - De Whiskey's - De Vitis]

On Wed, Jun 25, 2003 at 10:20:06AM +0200, Sven Luther wrote:
> I though the limit was 60 chars, as stated in one of the debian
> documents.
> 
> Friendly,

Beside the fact that is was to hurry in sending that mail (synopsis was short
enough), as i can read from Policy (I've 3.5.10), it must be less then 80
characters for sure (5.7.1).

"Description: " should be shorter then 80 characters
(reasonably), so the "" should be about 60-65
characters.

ciao,
-- 
Luca - De Whiskey's - De Vitis  | Elegant or ugly code as well
aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have
Luca, a wannabe ``Good guy''.   | something in common: they
local LANG="[EMAIL PROTECTED]" | don't depend on the 
language.

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Marek Habersack]

On Tue, Jun 24, 2003 at 10:57:36PM -0400, Aaron M. Ucko scribbled:
> Marek Habersack <[EMAIL PROTECTED]> writes:
> 
> >   2. Modify fakeroot to check the kernel version, the type of fs on which it
> >  is currently working and have it issue a sysctl to enable
> >  restricted_chown. It looks better than #1 but it might incurr
> 
> Er, is this even possible as an ordinary user?
Of course not. fakeroot would have to actually be suid root - as I said,
none of the solutions were perfect.

> >   5. Influence the XFS/kernel maintainers to change the default value of
> >  restrict_chown to enabled.
> 
> I agree that this is the best solution.
I'm beginning to think than it really is.

marek


pgphQaH7vxrVE.pgp
Description: PGP signature

Re: Please don't misuse the debian/changelog to close bugs!

[Herbert Xu]

John H. Robinson, IV <[EMAIL PROTECTED]> wrote:
> 
> in that case you can do this:
> 
> * New upstream release
> 
> and then use [EMAIL PROTECTED] to close the bugs, and everyone has a
> wonderful day.

Really? For the two groups of people affected by this change:

1. BTS readers -- No change.  The information they've received is
identical, i.e., that the bug has been fixed by a new upstream release.

2. debian/changelog readers -- No change.  They have lost a slight bit
information that is irrelevant for the purpose of documenting Debian
changes.

It is in fact detrimental for a third group, people who are trying to
extract the version in which a given bug was fixed.

So who is having a wonderful day because of this?

> you say ``should be in the upstream changelog already.'' what about
> those cases when they are not listed?

If you want to be pedantic, mostly redundant then.  I don't know about
your upstream, but as far as the Linux kernel goes, most changes have
reasonable log messages in the BitKeeper system.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Marek Habersack]

On Wed, Jun 25, 2003 at 08:42:03AM +0200, Andreas Metzler scribbled:
> Marek Habersack <[EMAIL PROTECTED]> wrote:
> >  Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> > actually setting the file ownership to root (or any other uid/gid for that
> > matter).
> [...]
> 
> Either there is a big misunderstanding or a big bug in 2.5.73+.
> Are you saying that using fakeroot I can actually do this?
I haven't tested it as I don't use quotas, but look at the relevant XFS
code:

if (restricted_chown &&
(iuid != uid || (igid != gid &&
 !in_group_p((gid_t)gid))) &&
!capable(CAP_CHOWN)) {
code = XFS_ERROR(EPERM);
goto error_return;
}
/*
 * Do a quota reservation only if uid or gid is actually
 * going to change.
 */
if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) ||
(XFS_IS_GQUOTA_ON(mp) && igid != gid)) {
ASSERT(tp);
code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp,
capable(CAP_FOWNER) ?
XFS_QMOPT_FORCE_RES : 0);
if (code)   /* out of quota */
goto error_return;
}

So if restricted_chown is not in effect and the uid/gid change, the quota
ownership will be shifted to the new uid/gid.

> touch /tmp/breaking.alice.quota
> chmod 666 /tmp/breaking.alice.quota
> fakeroot chown alice /tmp/breaking.alice.quota
> cat < /dev/zero  > /tmp/breaking.alice.quota
it would seem it really is possible. Just as is:

$ whoami
grendel
$ ls -ld .
drwxr-xr-x2 grendel  grendel 6 2003-06-25 11:28 .
$ mkdir test
$ ls -ld test
drwxr-xr-x2 grendel  grendel 6 2003-06-25 11:29 test
$ chown root:root test
$ ls -ld test
drwxr-xr-x2 root root6 2003-06-25 11:29 test
$ rm -r test
rm: remove write-protected directory test'? y
$ ls -ld test
ls: test: No such file or directory

regards,

marek


pgpZkGbNAiA9c.pgp
Description: PGP signature

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Marek Habersack]

On Wed, Jun 25, 2003 at 04:03:26AM -0500, Luca - De Whiskey's - De Vitis 
scribbled:
> On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote:
> > * lose the article
> 
> Why?
> 
> > * do not capitalize the beginning of the description unless a proper
> >   noun, proper adjective, abbreviation, or acronym requires it
> 
> Why?
How about just dropping that autoconf reference from the short description?
After all it's not an advertisement but a description of functionality. The
full description may refer to autoconf and somewhat compare the two in one
or two sentences. So, how about:

 a tool to configure software sources

That would actually sound better than the current autoconf description:

 automatic configure script builder

That assumes the reader knows what the configure scripts are used for.

regards,

marek


pgpcqpeY0tJA0.pgp
Description: PGP signature

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Sven Luther]

On Wed, Jun 25, 2003 at 04:14:05AM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Jun 25, 2003 at 10:20:06AM +0200, Sven Luther wrote:
> > I though the limit was 60 chars, as stated in one of the debian
> > documents.
> > 
> > Friendly,
> 
> Beside the fact that is was to hurry in sending that mail (synopsis was short
> enough), as i can read from Policy (I've 3.5.10), it must be less then 80
> characters for sure (5.7.1).
> 
> "Description: " should be shorter then 80 characters
> (reasonably), so the "" should be about 60-65
> characters.

Mmm, dh_make create a template saying :

Description: 

And the new maintainer guide documents this.

Friendly,

Sven Luther

Re: favicon resource

[Mathieu Roy]

Henning Moll <[EMAIL PROTECTED]> a tapoté :

> Hi!
> 
> I was just looking for a 'open use' debian favicon. But i can't find it on 
> http://www.debian.org/logos/index.en.html
> 
> Is it ok to use the resource from http://www.debian.org/favicon.ico ?
> Shouldn't it also be published on the logo page?

A favicon is a usual image, you can simply take and resize
openlogo-nd-25.png a little (to 48*48 for instance).

Regards,


-- 
Mathieu Roy
 
  Homepage:
http://yeupou.coleumes.org
  Not a native english speaker: 
http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english

Re: Bug#198158: architecture i386 isn't i386 anymore

[Colin Watson]

On Wed, Jun 25, 2003 at 04:55:56AM -0400, Colin Walters wrote:
> On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
> > I believe it would be a mistake to kill off support for the 80386 chip.
> 
> Well, we're limited by what we can sanely support.  After all, we don't
> support running Debian on a 286.  The 386 is really in the same class
> nowadays, in my opinion anyways.  

I disagree. Unlike 286, we've got the kernel, the libc, and *almost*
everything else. The only thing missing is part of the C++ ABI, which as
described can be handled by a small kernel patch (at least this has been
claimed and nobody has immediately said "it's impossible" ...).

I don't think this one lack puts it straight into the 286 camp just yet.

> We should foist the job of supporting i386 onto some specialized Debian
> port for it.

The problem is that we really don't have sensible support for
subarchitectures at all. This makes the job of creating such a
specialized port much greater than just "I have some hardware and need
to make a small tweak to support it"; you need to patch dpkg and make
substantial changes in the archive organization to share packages
between architectures, or else take a multi-gigabyte hit in disk space
and a huge amount of pointless effort rebuilding packages for some new
'i386only' architecture. 386 people would be quite entitled to look at
all this mess and say "well, why don't you just leave everything as it
is and let us make this small kernel change, until we can standardize on
gcc-3.3 with a fixed ABI"?

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Bug#198158: architecture i386 isn't i386 anymore

[Tollef Fog Heen]

* Colin Walters 

| On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
| 
| > I believe it would be a mistake to kill off support for the 80386 chip.
| 
| Well, we're limited by what we can sanely support.  After all, we don't
| support running Debian on a 286.  The 386 is really in the same class
| nowadays, in my opinion anyways.  

386 has protected mode, 286 doesn't.  That makes a bit of a
difference.

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

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Benj. Mako Hill]

On Tue, Jun 24, 2003 at 10:49:13PM +0200, Thomas Viehmann wrote:
> My argument was based on a matrix lintian error tags <->
> maintainers.  There's lintian tags practically "owned" by
> maintainers. That's what I meant with patterns. In those cases,
> pointing things out directly will help more.  In some cases,
> description deficiencies may be related to English skills (I'm not a
> native speaker myself). In those cases patches can achieve much more
> than bugs without patches.

I don't think anyone here is arguing that attaching a full description
would be equally or less helpful than simply pointing out the
problem. We're just saying that it would be useful in and off itself.

For those of us that don't have time to write scores of descriptions
for packages they are unfamiliar with, mass-filing in some sort of
automated or semi-automated fashion is a reasonable way to point out
the problem and, in the normal way bugs are fixed, eventually fix the
problem as well.

Writing and maintaining a package description seems to clearly be the
package maintainers job. In reference to Branden's message in this
thread, one would hope that the maintainers are also particularly well
suited to writing this (i.e., better suited than someone that doesn't
know the package).

Regards,
Mako


-- 
Benj. Mako Hill
[EMAIL PROTECTED]
http://mako.yukidoke.org/



pgp6oRWBFfJgp.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Emile van Bergen]

Hi,

On Wed, Jun 25, 2003 at 01:07:12PM +0200, Tollef Fog Heen wrote:

> * Colin Walters 
> 
> | On Wed, 2003-06-25 at 03:52, Branden Robinson wrote:
> | 
> | > I believe it would be a mistake to kill off support for the 80386 chip.
> | 
> | Well, we're limited by what we can sanely support.  After all, we don't
> | support running Debian on a 286.  The 386 is really in the same class
> | nowadays, in my opinion anyways.  
> 
> 386 has protected mode, 286 doesn't.  That makes a bit of a
> difference.

It does. It's just that the 286 is a 16-bit CPU and its protected mode
MMU mode offers only segmentation, no paging.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen   [EMAIL PROTECTED]  
tel. +31 (0)70 3906153   http://www.e-advies.nl

Bug#198158: architecture i386 isn't i386 anymore

[Herbert Xu]

Branden Robinson <[EMAIL PROTECTED]> wrote:
> 
> If this indeed feasible, then this is the solution that appeals most to
> me personally.

It certainly is feasible.  In fact, such a patch has been in existence
for at least a year.

> Also, Herbert Xu, the 80386 kernel-flavor maintainer, would have to be
> agreeable, and I don't believe I saw him offer an opinion on this
> approach in this discussion.

I have no problems with integrating such a patch.  I will look at it
right now.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#198158: architecture i386 isn't i386 anymore

[Marcelo E. Magallon]

On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote:

 > and remember that many embedded processors still use 486 and 586
 > based chips, and some 386.  Lossing 386 might be acceptable in the
 > embedded market (many 386 based systems have too little memory to run
 > Debian) but loosing 486 and 586 would mean that Debian was no longer
 > an option for embedded systems which would be a great loss.

 Do these people really use what we put out the door, or do they prune
 the distribution and recompile with different settings and things like
 that?  In the later case I don't see why our decision should affect
 them.

 -m.

Re: Please don't misuse the debian/changelog to close bugs!

[Matthew Palmer]

On Wed, 25 Jun 2003, Herbert Xu wrote:

> It is in fact detrimental for a third group, people who are trying to
> extract the version in which a given bug was fixed.

Aah, but if the bug wasn't fixed due to a change in the package, then it is
misleading to say that the bug was somehow "fixed" in that version of the
package.  It implies that versions less than the one in which the changelog
entry appear have the bug - which they do not.


-- 
---
#include 
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Herbert Xu]

Marek Habersack <[EMAIL PROTECTED]> wrote:
> 
>  Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> actually setting the file ownership to root (or any other uid/gid for that
> matter). The result is that the parts which don't run under fakeroot - 

Why is fakeroot calling the real chown(2)?
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#198158: architecture i386 isn't i386 anymore

[Adam Borowski]

On Wed, 25 Jun 2003, Branden Robinson wrote:
> > Hmm... I'm not sure about this as the last time I used assembler was 
> > in the times of real mode DOS, but there is a yet another option:
> > we can patch the kernel so when an invalid opcode occurs, whatever 
> > instruction was at CS:EIP gets emulated in software, similar to the
> > way i387 emulation is done.
> > (arch/i386/kernel/entry.S)
> > Of course, this would further slow down the speed demon known as 80386,
> > but since (AFAIK) the 486-specific opcodes get used pretty rarely in 
> > non-kernel code, the performance hit wouldn't be crippling.  And, there
> > is no performance hit at all for >386 machines, as no legitimate process
> > ever triggers the invalid opcode fault.
> 
> If this indeed feasible, then this is the solution that appeals most to
> me personally.
> 
> * It seems the least intrusive.  80386 users are probably going to want
>   and use an 80386-specific kernel, if they don't already *have* to.
> * Our hand is forced by the fact that the rest of the Linux distributors
>   in the world, and apparently the GCC folks, don't care about C++ ABI
>   portability to 80386 processors.
> * This doesn't require recompiling anything except the kernel.
> 
> The drawbacks:
> * Someone actually has to write this kernel patch.
As the person who originally submitted this idea, I'm probably the one
who is morally obliged to write it, even though:
* I'm not a kernel hacker,
* I was once good at _8086_ assembly, but the times of real mode are
  long gone, and I have no recent assembler experience,
* I'm moving home later this week, and won't be able to write this
  while my desktop machine is in transit (all the other boxes I got
  root access to are production servers),
* my skills are probably no match for most of you.

The pros and cons for the idea:
Pro:
  this kernel patch would make the 486 ABI transition flawless for all
  80386 users who have it applied, and (optionally) it can be used to
  make other software built for i486, i586 and i686 work on lesser CPUs.
Con:
  those on 80386 who don't have this patch applied will be screwed


I've made some proof-of-concept patches, and I'm ready for actually
emulating the opcodes.  However, you would need to answer the following
questions:
* what opcodes need to be emulated?
* just those needed for C++ ABI
* all 386->486 opcodes (there's just a few of them, right?)
* most 386->586 opcodes (it's impossible to emulate at least RDTSC,
  but the majority of code doesn't use it)
* 386->686?
* do you need SMP on 80386?  Is there even such thing as 80386 SMP
  machines?  Not requiring SMP support would make the ABI change 
  trivial...
* would you want some other emulation, like 486->586, 586->686?  MMX?
  Once the infrastructure for emulation is done, adding new opcodes
  is a simple task.


And, some patches for you to play with:
1. just reporting the invalid opcodes encountered
--- arch/i386/kernel/traps.c.0  2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 12:09:16.0 +0200
@@ -388,7 +388,6 @@
 DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
 DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
 DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
-DO_ERROR_INFO( 6, SIGILL,  "invalid operand", invalid_op, ILL_ILLOPN, 
regs->eip)
 DO_VM86_ERROR( 7, SIGSEGV, "device not available", device_not_available)
 DO_ERROR( 8, SIGSEGV, "double fault", double_fault)
 DO_ERROR( 9, SIGFPE,  "coprocessor segment overrun", 
coprocessor_segment_overrun)
@@ -397,6 +396,32 @@
 DO_ERROR(12, SIGBUS,  "stack segment", stack_segment)
 DO_ERROR_INFO(17, SIGBUS, "alignment check", alignment_check, BUS_ADRALN, 
get_cr2())
 
+
+asmlinkage void do_invalid_op(struct pt_regs * regs, long error_code)
+{
+   siginfo_t info;
+   int i;
+   
+   printk("Invalid opcode: ");
+   for(i=0;i<20;i++)
+   {
+   unsigned char c;
+   if(__get_user(c, &((unsigned char*)regs->eip)[i]))
+   {
+   printk(" Bad EIP value.");
+   break;
+   }
+   printk("%02x ", c);
+   }
+   printk("\n");
+   
+   info.si_signo = SIGILL;
+   info.si_errno = 0;
+   info.si_code = ILL_ILLOPN;
+   info.si_addr = regs->eip;
+   do_trap(6, SIGILL, "invalid operand", 1, regs, error_code, &info);
+}
+
 asmlinkage void do_general_protection(struct pt_regs * regs, long error_code)
 {
if (regs->eflags & VM_MASK)





2. an ugly hack that proves that the emulation can be done.  I took some
   random opcode that just happened to be not present on my machine (you
   would probably need to choose something else), and "emulated" it by
   a token operation: swapping eax and ebx.  I didn't even bother with
   making it nice, readable or anything -- it's just a test code.
--- arch/i386/kernel/traps.c.0  2003-06-25 11:19:53.0 +0200
+++ arch/i386/kernel/traps.c2003-06-25 13:09:5

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Cédric Delfosse]

Le mer 25/06/2003 à 00:34, Marek Habersack a écrit :
> Hey list,
> 
>   Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> actually setting the file ownership to root (or any other uid/gid for that
> matter). The result is that the parts which don't run under fakeroot - 
> e.g. debian/rules won't be able to write to the debian/packagename/ subdirs 
> sometimes. 
> It happens only when the filesystem on which the build is taking place is 
> XFS. 
> This is due to the restrict_chown sysctl which was present in XFS before but 
> never 
> actually implemented. Starting with 2.5.73 XFS does use the setting which 
> works in
> the way that allows the owner of the directory to give away its
> subdirectories/files to other users. If restrict_chown is enabled then the
> old behavior is back, however it defaults to disabled.

This problem exists with kernel 2.4.21 + XFS 1.3.0pre2 too.

-- 
Cédric Delfosse
http://cedric.freezope.org


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

Re: maildirmake

[Josip Rodin]

On Wed, Jun 25, 2003 at 09:36:17AM +1000, Brian May wrote:
> > You could start by telling us what maildirmake is supposed to do. Why
> > do we need it? Any program I know of which can handle Maildir is not
> > only capable of storing messages in Maildir folders but also of
> > generating them. This includes e.g. the exim(4) MTA, MDAs like
> > procmail or maildrop, and the MUA mutt.
> 
> As far as I am aware, maildrop does *not* support creating Maildirs.

Not intrinsically, but it's trivial to hack it,

DUMMY=`[ -d mail/maildir ] || maildirmake mail/maildir`

> Even if it does support creating top level Maildir (last I tested it
> didn't seem to), it doesn't support creating a maildir within a maildir
> (this apparently is a bit different, and it used by courier-imap). You
> do with with maildirmake (or at least the version I have installed) with
> the -f option.

DUMMY=`[ -d mail/maildir/.folder ] || maildirmake -f folder mail/maildir`

-- 
 2. That which causes joy or happiness.

Bug#198158: architecture i386 isn't i386 anymore

[Christoph Hellwig]

On Wed, Jun 25, 2003 at 02:52:31AM -0500, Branden Robinson wrote:
> The drawbacks:
> * Someone actually has to write this kernel patch.

http://miaif.lip6.fr/~tarreau/linux-patches/486emulation/

Re: Developer Accessible Hurd Machine

[Mario Lang]

Michael Banck <[EMAIL PROTECTED]> writes:

> Anyway, you can still try to install the Hurd yourself on a free
> partition, for example using the crosshurd package. Most people have an
> i386, so it's just a matter of perhaps freeing some disk-space and
> reading the docs. If it doesn't work with your hardware or you run into
> big problems, you will not have lost a lot of time.

I'd need to port brltty first, before being able to boot a native Hurd.
I could rpobably get it up and running using bochs, but I did not try this yet.

OTOH, the whole port seems miles away from releaseable state,
so I wonder why I should bother.  If there is no permanent buildd running,
I think most developers will not be able to identify
hurd specific problems, even if they were very minor.

-- 
CYa,
  Mario

Re: Bug#198158: architecture i386 isn't i386 anymore

[David Goodenough]

On Wednesday 25 June 2003 12:00, Marcelo E. Magallon wrote:
> On Wed, Jun 25, 2003 at 09:57:57AM +0100, David Goodenough wrote:
>  > and remember that many embedded processors still use 486 and 586
>  > based chips, and some 386.  Lossing 386 might be acceptable in the
>  > embedded market (many 386 based systems have too little memory to run
>  > Debian) but loosing 486 and 586 would mean that Debian was no longer
>  > an option for embedded systems which would be a great loss.
>
>  Do these people really use what we put out the door, or do they prune
>  the distribution and recompile with different settings and things like
>  that?  In the later case I don't see why our decision should affect
>  them.
>
>  -m.

For simple, short run projects why do a whole lot of work when the standard 
off the shelf component will do it for you.  Yes I go around deleting
a whole bunch of documentation and the like, or rather I only copy
the bits I really need to the CF disk, but wherever possible I use
what gets shipped.

The kernel and associated modules I will rebuild, but I would rather
not rebuild everything else, otherwise I would use Gentoo rather
than Debian.

David

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Marek Habersack]

On Wed, Jun 25, 2003 at 09:30:32PM +1000, Herbert Xu scribbled:
> Marek Habersack <[EMAIL PROTECTED]> wrote:
> > 
> >  Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> > actually setting the file ownership to root (or any other uid/gid for that
> > matter). The result is that the parts which don't run under fakeroot - 
> 
> Why is fakeroot calling the real chown(2)?
No idea. Anyhow, I posted to lkml and it seems that the default value for
the sysctl was a mistake. It will be corrected in the next Linus' release.
But the sysctl itself won't go away.

marek


pgpviSF0cuA9H.pgp
Description: PGP signature

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Stefano Zacchiroli]

On Wed, Jun 25, 2003 at 04:03:26AM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote:
> > * lose the article
> Why?

Because

  
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis

states that (as a "general guideline")

> > * do not capitalize the beginning of the description unless a proper
> >   noun, proper adjective, abbreviation, or acronym requires it
> Why?

Idem

Just to nitpick :-)

Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney


pgpege2YhlKAQ.pgp
Description: PGP signature

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Hamish Moffatt]

On Sun, Jun 22, 2003 at 10:49:54AM +0200, Bernd Eckenfels wrote:
> On Sun, Jun 22, 2003 at 10:23:01AM +0200, Sven Luther wrote:
> > Tell me, you seriously think that there is a libc5 program still around
> > that uses DRI ? Hell, libc5 was abandoned well before DRI even existed.
> 
> the only libc5 program I do use is netscape 4.77 because it is compatible to
> some pages where mozilla/opera/konquerror fails. I would hate to reboot, to
> just open that page.

Tried mozilla recently? It's a thousand times better than Netscape 4.7x
was... Although I've still had it vanish a couple of times recently. It
doesn't hang like NS though.


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

Re: Developer Accessible Hurd Machine

[Michael Banck]

On Wed, Jun 25, 2003 at 02:46:24PM +0200, Mario Lang wrote:
> If there is no permanent buildd running, I think most developers will
> not be able to identify hurd specific problems, even if they were very
> minor.

Well, there is a buildd, it's just not running at the moment (and it
dies frequently). Its maintainer (Jeff Bailey) is waiting for the next
glibc I think.


Michael

ITP: libtext-charwidth-perl

[Tomohiro KUBOTA]

Package: wnpp
Severity: wishlist

libtext-charwidthp-perl: get display widths of characters on the terminal

downloaded from: CPAN
(http://www.cpan.org/modules/by-module/Text/Text-CharWidth-.tar.gz)

License: dual license of Artistic and GPL1.

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/

ITP: libtext-wrapi18n-perl

[Tomohiro KUBOTA]

Package: wnpp
Severity: wishlist

libtext-wrapi18n-perl: internationalized substitute of Text::Wrap

Downloaded from: CPAN
( http://www.cpan.org/modules/by-module/Text/Text-WrapI18n-.tar.gz )

License: dual license of Artistic and GPL1.

---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Steve Langasek]

On Wed, Jun 25, 2003 at 04:03:26AM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote:
> > * lose the article

> Why?

Because Branden is agent sent by Russians to demoralize our English
grammarians, and removing article advances his agenda.

> > * do not capitalize the beginning of the description unless a proper
> >   noun, proper adjective, abbreviation, or acronym requires it

> Why?

Because it's not the start of a sentence (it's the start of a noun
clause), and should therefore not be capitalized.

-- 
Steve Langasek
postmodern programmer


pgpv1E2Ud5Ecd.pgp
Description: PGP signature

Re: Bug#197049: ITP: conglomerate -- an XML editor for GNOME

[Sven Luther]

On Sun, Jun 15, 2003 at 08:14:57AM -0500, Manoj Srivastava wrote:
> On Sat, 14 Jun 2003 09:33:02 +0200, Sven Luther <[EMAIL PROTECTED]> said: 
> 
> > On Fri, Jun 13, 2003 at 04:54:23PM -0500, Manoj Srivastava wrote:
> >> On Fri, 13 Jun 2003 16:49:15 +0200, Sven Luther
> >> <[EMAIL PROTECTED]> said:
> >>
> >> > On Thu, Jun 12, 2003 at 11:48:10AM -0500, Manoj Srivastava wrote:
> >> >> On Thu, 12 Jun 2003 18:12:03 +0200, Sven Luther
> >> >>
> >> >> > So it should be ok if i upload the package to unstable, even
> >> >> > if the package crashes often, and thus, since it is an XML
> >> >> > editor, the user can loose part of its work ?
> >> >>
> >> >>
> >> >> *Sigh*. Rules of thumb are no subst=itute for common sense or
> >> >> thinking.
> >> >>
> >> >> Did I not say data loss is reason enough for experimental?
> >> >>
> >> >> > At least i should add a warning in the long description then
> >> >> > or something such ?
> >> >>
> >> >> If it causes data loss, you should use experimental.
> >>
> >> > Well, the difference is between data loss on the disk and loss of
> >> > currently editing stuff.
> >>
> >> Is it your contention that it is useful for us to make that
> >> distinction? Why?
> 
> > Because if it crashes before you have had time to enter any
> > meaningfull data, as it was doing, it is less grave as when it
> > crashed after hours of work. Also, i think you can distinguish
> > between an app causing random data loss of other data and an app
> > causing loss of his own data.
> 
>   I beg to differ. In geberal, after I spend 12 hours
>  painstakingly entering data, and it is all lost, I am more likely to
>  be annoyed than if it corrupted some data on the disk and I had to
>  just restore from the nightly backup.

Ah, but the current problem would happen in the first minute, always, so
unless you type/click/whatever exceptionnaly fast, you don't loose much.

0.5.3 closed this problem though, will test the now release 0.5.4 also.
I am of two minds about this, on one side, conglomerate is now in
experimental, but maybe it could also go into unstable, now that it does
not crash anymore.

Friendly,

Sven Luther

Re: Bug#198602: ITP: debbackup -- Backup and restore Debian specifics (package status, conffiles)

[Adam Heath]

On Tue, 24 Jun 2003, Drew Scott Daniels wrote:

> I have also been thinking about creating a complimentary program that
> would help "cleanup" the system by finding unused packages, seldom used
> packages, cruft, unnessisary files... As with debbackup, there are things
> to do some of the functons already.

deborphan, cruft.

Bug#198158: architecture i386 isn't i386 anymore

[Marcelo E. Magallon]

On Wed, Jun 25, 2003 at 01:42:04PM +0200, Adam Borowski wrote:

 > As the person who originally submitted this idea, I'm probably the
 > one who is morally obliged to write it, even though:

 The patch has been already written:  http://lwn.net/Articles/8634/  I'm
 sure theere's a better link, but that's the best I could extract out of
 google without resorting to bribery :-)

 -m.

Bug#198771: ITP: gnome-network -- Network tools suite for the GNOME desktop

[Andrew Lau]

Package: wnpp
Version: unavailable; reported 2003-06-26
Severity: wishlist

* Package name: gnome-network
  Version : 1.99.0
  Upstream Author : German Poo-Caamano
Rodrigo Moya
* URL : ftp.gnome.org/pub/GNOME/sources/gnome-network/
* License : GPL
  Description : Network tools suite for the GNOME desktop

gnome-network is back from the dead (GU4DEC)
http://lagun.gnome-db.org/documentation/talk-gnome-network/

### VERY rought DRAFT description ###

The GNOME 2 port of gnome-network is still a work in progress, but the
following tools are available now.

 * backup: sets of files including My Documents, Evolution files,
   Bookmarks to file, tape, CD, .mac, Amanda targets.
 * remote shell: (SSH/Telnet/RSH/rlogin) client
   To be integrated with network:// virtual folder
 * remote desktop: (vnc, x11, rdesktop)
 * netinfo: ping, traceroute, ifconfig, netstat, route, & portmap
   frontend.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux espresso 2.4.21 #1 Thu Jun 19 17:23:17 EST 2003 i686
Locale: LANG=C, LC_CTYPE=C


-- 
--
* Andrew "Netsnipe" Lau Computer Science & Student Rep, UNSW *
*   # apt-get into itDebian GNU/Linux Package Maintainer *
*   *
* 1024D/2E8B68BD: 0B77 73D0 4F3B F286 63F1  9F4A 9B24 C07D 2E8B 68BD *
--


pgpK88z1MnkNH.pgp
Description: PGP signature

Open questions of package descriptions (Was: Bug#198665: ITP: pmk...)

[Jarno Elonen]

> > > * lose the article
> > Why?
> >
> > > * do not capitalize the beginning of the description unless a proper
> > >   noun, proper adjective, abbreviation, or acronym requires it
> > Why?

Argh, we really should decide these two points now and for good. Just today I 
received through DDTP a description correction that only consisted of 
capitalization of the first letter. I don't care one bit about which way 
should become official but we need the consistency.

- Jarno

Bug#198775: ITP: libgnomecups -- GNOME library for CUPS interaction

[Ross Burton]

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

* Package name: libgnomecups
  Version : 0.1.4
  Upstream Author : Dave Camp <[EMAIL PROTECTED]>
* URL : http://www.ximian.com/
* License : LPGL
  Description : GNOME library for CUPS interaction

This library wraps the CUPS API in a GLib fashion, so CUPS code can be
cleanly integrated with GLib code.

Although called libgnomecups, this library only depends on GLib.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux hactar 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686
Locale: LANG=en_GB, LC_CTYPE=en_GB (ignored: LC_ALL set)

Bug#198158: architecture i386 isn't i386 anymore

[Branden Robinson]

On Wed, Jun 25, 2003 at 08:51:12PM +1000, Herbert Xu wrote:
> It certainly is feasible.  In fact, such a patch has been in existence
> for at least a year.

Cool.

> I have no problems with integrating such a patch.  I will look at it
> right now.

Excellent.  Thanks!

-- 
G. Branden Robinson|I am sorry, but what you have
Debian GNU/Linux   |mistaken for malicious intent is
[EMAIL PROTECTED] |nothing more than sheer
http://people.debian.org/~branden/ |incompetence! -- J. L. Rizzo II


pgpkPCNTJaCM3.pgp
Description: PGP signature

Re: Bug#198158: architecture i386 isn't i386 anymore

[Colin Walters]

On Wed, 2003-06-25 at 06:05, Colin Watson wrote:

> I disagree. Unlike 286, we've got the kernel, the libc, and *almost*
> everything else. The only thing missing is part of the C++ ABI, which as
> described can be handled by a small kernel patch (at least this has been
> claimed and nobody has immediately said "it's impossible" ...).

The problem isn't just the C++ ABI; it's any application that uses an
insn like cmpxchg.  Basically any application that wants to have atomic
integers or similar will be using this insn.  Of software I'm familiar
with, this includes gstreamer and dbus right now.  And glib will soon
have atomic integers too (for refcounting).

I'm surprised that pthreads apparently doesn't use it.

> I don't think this one lack puts it straight into the 286 camp just yet.

Maybe.

> The problem is that we really don't have sensible support for
> subarchitectures at all. 

Yes, I agree, that is by far the biggest bug.

> [...] 386 people would be quite entitled to look at
> all this mess and say "well, why don't you just leave everything as it
> is and let us make this small kernel change, until we can standardize on
> gcc-3.3 with a fixed ABI"?

Note that the current situation is that we don't run on i386, unless
they emulate opcodes.  In which case, we really can still say we don't
run on i386.

Re: Bug#198665: ITP: pmk -- The pmk project aims to be an alternative to GNU/autoconf (configure scripts).

[Branden Robinson]

On Wed, Jun 25, 2003 at 04:03:26AM -0500, Luca - De Whiskey's - De Vitis wrote:
> On Wed, Jun 25, 2003 at 03:18:28AM -0500, Branden Robinson wrote:
> > * lose the article
> 
> Why?

* it wastes space that is precious in the short description
* it's implicit
* see the archives of this list

> > * do not capitalize the beginning of the description unless a proper
> >   noun, proper adjective, abbreviation, or acronym requires it
> 
> Why?

* the short description is neither a sentence nor a title, and thus
  requires no initial capitalization
* if interfaces to the packaging system want to invoke toupper() on the
  first character of the short description, they are free to do so
* asking interfaces to the packaging system to invoke tolower() on the
  first character of the short description is stupid, because you'll end
  up with short descriptions like this:

xlibs - x Window System client libraries

-- 
G. Branden Robinson| One doesn't have a sense of humor.
Debian GNU/Linux   | It has you.
[EMAIL PROTECTED] | -- Larry Gelbart
http://people.debian.org/~branden/ |


pgpuUisXhJESz.pgp
Description: PGP signature

subarchitectures? (was: Bug#198158: architecture i386 isn't i386 anymore)

[Andreas Barth]

* Colin Watson ([EMAIL PROTECTED]) [030625 12:35]:
> The problem is that we really don't have sensible support for
> subarchitectures at all. This makes the job of creating such a
> specialized port much greater than just "I have some hardware and need
> to make a small tweak to support it"; you need to patch dpkg and make
> substantial changes in the archive organization to share packages
> between architectures,

What does oppose us to make subarchitectures quite more easy than now?
(That would also be useful for the AMD Opteron and the like that could
use normal i386-code, but can profit from optimized code.)


Of course, that doesn't resolve the actual bug right now, but ...
> all this mess and say "well, why don't you just leave everything as it
> is and let us make this small kernel change, until we can standardize on
> gcc-3.3 with a fixed ABI"?
... this is the right thing to do that.


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

Application files in $HOME

[Daniel Ruoso]

Hi,

I had an idea and I would like to hear you about it.

Recently I had a problem of exceeded quota in my home directory, so I
went cleaning it, and I saw many and many files and directories with
configurations for applications that I've runned in the past, but that 
packages were purged from my system a long time ago, so what is the idea
(that can be a proposal)?

What if the packages tells to dpkg which files or directories it will
create on the user's home directory and when a package is purged the
user could run a program to purge the files of packages that no longer
exists. This will also help to know what these files means after all, I
thought about a browser to inspect application's files in my home, so it
will be easier to decide which files I don't want anymore...

What is needed?

The packages should have a control file (like conffiles) that tells
which files this package will create.

A repository to store this information so the user can browse it.

A userconfpurge program that the user runs to remove purged packages
configuration files

A browser to associate the files with the packages and manage them (so
the user can tell: I don't use icewm anymore, please remove it's
configuration files).

Is there risk involved?

I don't know if different packages create conf files with the same name,
if it does so, it would be necessary to avoid this practice.


So,

what do you think?

[]'s 


daniel

Re: Please don't misuse the debian/changelog to close bugs!

[Matt Zimmerman]

On Wed, Jun 25, 2003 at 07:34:23PM +1000, Herbert Xu wrote:

> 2. debian/changelog readers -- No change.  They have lost a slight bit
> information that is irrelevant for the purpose of documenting Debian
> changes.

I am one of these readers.  I do this.  A lot.  Every day.  And I am telling
you that the method that I have suggested in previous threads is VERY
HELPFUL to me.  So, while you may disagree, do not misrepresent my
situation.

-- 
 - mdz

Re: subarchitectures? (was: Bug#198158: architecture i386 isn't i386 anymore)

[Michael Banck]

On Wed, Jun 25, 2003 at 06:50:54PM +0200, Andreas Barth wrote:
> What does oppose us to make subarchitectures quite more easy than now?
> (That would also be useful for the AMD Opteron and the like that could
> use normal i386-code, but can profit from optimized code.)

Nothing opposes it, we're just missing something: The correct patch.


Michael

Re: Please don't misuse the debian/changelog to close bugs!

[Brian Nelson]

Herbert Xu <[EMAIL PROTECTED]> writes:

> Gerfried Fuchs <[EMAIL PROTECTED]> wrote:
>> 
>> During some of the discussions lately on debian-devel another usage of
>> the changelog has risen interest:
>> 
>> * New upstream release (closes: #123, #124, #125)
>> 
>> This has also raised some discussions. The thing is this: If #123,
>> #124 and #125 aren't just "New upstream version available" bugreports
>> then quite some people dislike this behavior. It shouldn't be too much
>> hazzle for the maintainer to rewrite this as follows:
>
> I strongly disagree with your view.  Please respond to my points
> that have been raised previously rather than repeating this dogma.

It's pointless to go through this again.  Instead, I'll offer a concrete
example of the confusion this can create (the original submitter asks
for clarification of how the bug was fixed):

http://bugs.debian.org/188740

>> * New upstream release (closes: #123) which includes:
>>   - tmpfile race condition fix (closes: #124)
>>   - manual page included (closes: #125)
>> 
>> The thing is: It helps the users and the person who reported the bug to
>> see what bug exactly was closed without the need for them to dig in the
>> BTS. This is no must but it is something your users would be greatful if
>> you could do it.
>
> As I have said before, this is incomplete: only bugs that were reported
> and identified are listed, and redundant: these changes should be in
> the upstream changelog already.

I don't see anything particularly helpful in the upstream changelog for
the above example.

-- 
Poems... always a sign of pretentious inner turmoil.


pgp49SrhX4bqQ.pgp
Description: PGP signature

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Torsten Landschoff]

On Wed, Jun 25, 2003 at 09:30:32PM +1000, Herbert Xu wrote:
> >  Running debuild as normal user under the 2.5.73+ kernel results in fakeroot
> > actually setting the file ownership to root (or any other uid/gid for that
> > matter). The result is that the parts which don't run under fakeroot - 
> 
> Why is fakeroot calling the real chown(2)?

Indeed a good question I would like to have answered. fakeroot should
replace chown, shouldn't it?

Greetings

Torsten

Re: Bug#198158: architecture i386 isn't i386 anymore

[Gunnar Wolf]

Colin Watson dijo [Wed, Jun 25, 2003 at 11:05:56AM +0100]:
> > We should foist the job of supporting i386 onto some specialized Debian
> > port for it.
> 
> The problem is that we really don't have sensible support for
> subarchitectures at all. This makes the job of creating such a
> specialized port much greater than just "I have some hardware and need
> to make a small tweak to support it"; you need to patch dpkg and make
> substantial changes in the archive organization to share packages
> between architectures, or else take a multi-gigabyte hit in disk space
> and a huge amount of pointless effort rebuilding packages for some new
> 'i386only' architecture. 386 people would be quite entitled to look at
> all this mess and say "well, why don't you just leave everything as it
> is and let us make this small kernel change, until we can standardize on
> gcc-3.3 with a fixed ABI"?

And not only 80386 needs this - There is the Sparc64 port which would
also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we
had support for subarchtectures, not only would the ix86 mess be able to
be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever
you fancy). And I am sure this can somehow help maintain the non-Linux
ports - NetBSD gives us the potential to bring Debian to _many_ new
platforms. 

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

Re: Bug#198158: architecture i386 isn't i386 anymore

[Matt Zimmerman]

On Wed, Jun 25, 2003 at 01:26:38PM +0900, GOTO Masanori wrote:

> Performance improvement is _not_ my primary intention.At least it needs to
> support libc6-686:
> 
>   - LinuxThreads floating stack support.  It's ready for i686 and later.
> 
>   - NPTL/TLS support.  NPTL currently supports i486 and later because
> pthread_spin_trylock uses cmpxchgl instruction (well, it's not
> difficult to support i386, but imagine pthread on i386 with the
> max clock (I recall it was 20MHz?) speed and memory...)
> 
> and so on. 

Ah, I was not aware of this.  I am very interested in both of these
features.

> BTW, I also think that 5% performance improvement with optimization is
> valuable.  It's not easy to accelerate 5% performance without any source
> code modification and hardware improvement.  In addition, it reduces the
> user responce time, I think it's more important than increasing throughput
> (= computational speed).

5% may or may not be valuable depending on the cost.  Where did this
particular figure come from (5%)?

> IMHO, the problem is the lack of real data which compares non- optimized
> vs optimized binary performance on the actual environment.  I often heard
> the perfomance improvement issue using gcc optimization like Gentoo, but I
> merely saw the real perfomance comparison graph.  So, supporting optimized
> library is not primary issue for at least libc.

I see a lot of handwaving from gentoo users and the like, but no convincing
concrete measurements.  Most of what I see is:

- "I switched from  to  and now  is much
  faster!"

- "I run  on one PC, and  on the other, and
  the optimized one is way faster!  They're exactly the same hardware except
  [they're not]"

- "I compared an un-optimized build of  (no -O at all) to one compiled
  with -O27 -pipe -fomit-frame-pointer -funroll-all-loops -march=pentium3
  -mcpu=pentium3 -mfpmath=sse -mmmx -msse
  -mother-options-i-dont-even-understand -mi-didnt-read-the-manual"

These claims are usually subjective, but sometimes they come with numbers,
which are meaningless because there are so many variables involved.

-- 
 - mdz

Re: kernel 2.5.73+, fakeroot, debuild - a small problem

[Richard Braakman]

On Wed, Jun 25, 2003 at 09:30:32PM +1000, Herbert Xu wrote:
> Why is fakeroot calling the real chown(2)?

I think it's to be able to report errors like ENOENT.  You can turn 
it off by setting FAKEROOTDONTTRYCHOWN in the environment.
It should be possible to replace this chown with something harmless
that reports the same errors.

Richard Braakman

Re: Developer Accessible Hurd Machine

[Robert Millan]

 (please don't remove the CC to debian-hurd)

Hi Benj,

Jeff commented me he had plans for a developer accessible GNU/Hurd
machine, so he might have something to say (CCing him..)

As for the hosting, what are the requisites for placing a public debian
machine at home? I'd be willing to help but probably someone else has
better resources (eg, bandwidth, or even physical space) than me.

On Sat, Jun 21, 2003 at 01:27:41PM +0200, Benj. Mako Hill wrote:
> Greetings,
> 
> Some time ago, Martin Schulze pointed out that there is no developer
> accessible Hurd machine available.
> 
> I am happy to coordinate the donation of hardware for this if it is
> this something that you (developers, Hurd and otherwise) feel would be
> useful and possible? However, I've heard that Hurd is still unstable
> enough that we will probably need to place the machine at a Hurd
> developer's home or work.
> 
> -devel: Is this something developers would like?
> 
> -hurd: If consensus says we proceed, are there any volunteers for
> hosting this?
> 
> Please include me to replies to -hurd since I am not on that list.

-- 
Robert Millan

Re: Accepted devfsd 1.3.25-14 (i386 source)

[Thierry Vignaud]

Russell Coker <[EMAIL PROTECTED]> writes:

> Description: 
>  devfsd - Daemon for the device filesystem
> Changes: 
>  devfsd (1.3.25-14) unstable; urgency=medium
>  .
>* Fixed a bug in creating compatability links for DAC960 devices.

you did:

diff -u devfsd-1.3.25/devfsd.c devfsd-1.3.25/devfsd.c
--- devfsd-1.3.25/devfsd.c
+++ devfsd-1.3.25/devfsd.c
@@ -1504,8 +1504,7 @@
   case AC_RMOLDCOMPAT:
compat_name = get_old_name (info->devname, info->namelen, compat_buf,
info->major, info->minor);
-   if ( (strncmp (info->devname, "rd/", 3) == 0) &&
- (strncmp (ptr = (strrchr (info->devname, '/') +1), "part", 4) == 0) )
+   if ( strncmp (info->devname, "rd/", 3) == 0 )
dest_name = info->devname+3;
if ( (strncmp (info->devname, "ida/", 4) == 0) &&
  (strncmp (ptr = (strrchr (info->devname, '/') +1), "part

tested fix i uploaded on april 24 was:

--- ./devfsd.c.cdrom2002-03-25 07:59:40.0 +0100
+++ ./devfsd.c  2002-08-17 18:06:17.0 +0200
@@ -1462,5 +1462,9 @@
   case AC_RMOLDCOMPAT:
compat_name = get_old_name (info->devname, info->namelen, compat_buf,
info->major, info->minor);
+   if ( (strncmp (info->devname, "rd/", 3) == 0) &&
+ ((strncmp (ptr = (strrchr (info->devname, '/') +1), "part", 4) == 0) 
||
+  (strncmp (ptr = (strrchr (info->devname, '/') +1), "disc", 4) == 0)))
+   dest_name = info->devname+3;
if ( strncmp (info->devname, "ida/", 4) == 0) {
ptr = (strrchr (info->devname, '/') +1);
if ( (strncmp (ptr, "part", 4) == 0) || (strncmp (ptr, "disc", 4) == 0) 
) {


dac9660 driver is not supposed to create other entries but who know...

btw, you really should resync with us as for devfsd patches (see
http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/devfsd/)


since you took some of our patches (mid september 2002), we fix some
more bugs here:

- minilogd/devfsd races

- /dev/hd* managment (immediate effect is that root cannot access IDE
  cdrom under /dev/hdc if logging in on the console immediately after
  startup before any other user has yet log in. Obviously, for normal
  users pam_console_apply triggers ide-cd loading but for root it is
  never loaded)

- more support for cciss compatibility links

- no spurious ida/ in ida device paths

- ...

Re: Proposal: removing libc5, altgcc and all their old-days dependencies

[Bernd Eckenfels]

On Thu, Jun 26, 2003 at 12:21:22AM +1000, Hamish Moffatt wrote:
> me wrote:
> > some pages where mozilla/opera/konquerror fails. I would hate to reboot, to

> Tried mozilla recently? It's a thousand times better than Netscape 4.7x

navigator is much faster on my 128mb system than anything else, 
and it still displays some pages which mozilla does not. in my case 
this are pages with cross frame scripting of java applets and some
refreshing pages.

But thanks anyway :)

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/
  o--o *plush*  2048/93600EFD  [EMAIL PROTECTED]  +497257930613  BE5-RIPE
(OO)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: [mass bug filing?] Short descriptions being used as long descriptions and other policy violations

[Thomas Viehmann]

Benj. Mako Hill wrote:
> On Tue, Jun 24, 2003 at 10:49:13PM +0200, Thomas Viehmann wrote:
> Writing and maintaining a package description seems to clearly be the
> package maintainers job. In reference to Branden's message in this
> thread, one would hope that the maintainers are also particularly well
> suited to writing this (i.e., better suited than someone that doesn't
> know the package).
As I'm one of the bad examples in the other current thread on the subject, my
assumptions are thoroughly disproven, so I'll just shut up and fix my 
description.

Cheers

T.


pgpMaIZbY4JEz.pgp
Description: PGP signature

New list (was Re: Old bugs related to translated debconf templates)

[Denis Barbier]

On Wed, Jun 25, 2003 at 12:04:29AM +0200, Denis Barbier wrote:
> Hi,
> 
> Here is a list of bugs older than a year; most of them are related to
> translated debconf templates, so fixing them is trivial and I might
> NMU some of these packages soon.

Many bugreports were missing, here is a more accurate list.  The longest
delay is now more than 2 years, hurrah!
If you feel frustrated because I missed BR about some of your packages,
please drop me a mail and I will update this list.

  #BRDate Package   Maintainer
 93586 (10 Apr 2001) phpgroupware  Luca - De Whiskey's - De Vitis
 94138 (16 Apr 2001) passwdKarl Ramm
103202 (02 Jul 2001) fujiplay  Roland Bauerschmidt
103324 (03 Jul 2001) diald Jeff Licquia
105214 (14 Jul 2001) dotfile-fvwm1 Michael Moerz
105216 (14 Jul 2001) dotfile-fvwm1-ja  Michael Moerz
105217 (14 Jul 2001) dotfile-fvwm2 Michael Moerz
105218 (14 Jul 2001) dotfile-fvwm2-ja  Michael Moerz
106022 (20 Jul 2001) dotfile-fvwm1 Michael Moerz
106023 (20 Jul 2001) dotfile-fvwm1-ja  Michael Moerz
106024 (20 Jul 2001) dotfile-fvwm2-ja  Michael Moerz
106025 (20 Jul 2001) dotfile-fvwm2 Michael Moerz
106150 (21 Jul 2001) nis   Miquel van Smoorenburg
107023 (29 Jul 2001) kdm   Christopher L Cheney
107730 (06 Aug 2001) diald Jeff Licquia
110178 (26 Aug 2001) postfix   LaMont Jones
112355 (15 Sep 2001) zhcon Yu Guanghui
113152 (22 Sep 2001) adduser   Roland Bauerschmidt
114308 (03 Oct 2001) gsTorsten Landschoff
114309 (03 Oct 2001) gs-aladdinTorsten Landschoff
116433 (21 Oct 2001) gnapster  Debian QA Group
117198 (26 Oct 2001) ntop  Ola Lundqvist
118245 (04 Nov 2001) passwdKarl Ramm
126052 (21 Dec 2002) hwtools   Christoph Lameter
128933 (12 Jan 2002) kdm   Christopher L Cheney
132615 (06 Feb 2002) kdm   Christopher L Cheney
133411 (11 Feb 2002) colormake Roland Bauerschmidt
133413 (11 Feb 2002) irm   Sergio Talens-Oliag
133792 (13 Feb 2002) xfree86v3 Branden Robinson
134460 (17 Feb 2002) arla-modules-source   Mikael Andersson
134506 (18 Feb 2002) fcron Russell Coker
135833 (26 Feb 2002) courier-base  Stefan Hornburg
135834 (26 Feb 2002) courier-imap  Stefan Hornburg
135835 (26 Feb 2002) courier-mta   Stefan Hornburg
135836 (26 Feb 2002) courier-ssl   Stefan Hornburg
135837 (26 Feb 2002) courier-webadmin  Stefan Hornburg
135847 (26 Feb 2002) postfix   LaMont Jones
135848 (26 Feb 2002) postfix-tls   LaMont Jones
135849 (26 Feb 2002) postfix-snap  LaMont Jones
135965 (27 Feb 2002) xfree86v3 Branden Robinson
136138 (28 Feb 2002) xfree86v3 Branden Robinson
136444 (02 Mar 2002) scsitools Eric Delaunay
136582 (03 Mar 2002) colormake Roland Bauerschmidt
136586 (03 Mar 2002) dotfile-fvwm1-ja  Michael Moerz
136588 (03 Mar 2002) dotfile-fvwm2-ja  Michael Moerz
136589 (03 Mar 2002) dotfile-fvwm2 Michael Moerz
136590 (03 Mar 2002) dotfile   Michael Moerz
136591 (03 Mar 2002) dotfile-fvwm1 Michael Moerz
136592 (03 Mar 2002) fujiplay  Roland Bauerschmidt
136594 (03 Mar 2002) klisa Christopher L. Cheney
136600 (03 Mar 2002) nvidia-glx-srcRandall Donald
136606 (03 Mar 2002) scsitools Eric Delaunay
136609 (03 Mar 2002) zhcon Yu Guanghui
136919 (05 Mar 2002) arla-modules-source   Mikael Andersson
137057 (06 Mar 2002) kdm   Christopher L Cheney
137613 (10 Mar 2002) arla-modules-source   Mikael Andersson
137637 (10 Mar 2002) diffmon   Jeff Bailey
137648 (10 Mar 2002) fonty Piotr Roszatycki
137652 (10 Mar 2002) gnapster  Debian QA Group
137655 (10 Mar 2002) gnome-pilot   Mike Markley
137658 (10 Mar 2002) htdig Robert Ribnitz
137662 (10 Mar 2002) hwtools   Christoph Lameter
137663 (10 Mar 2002) interchange-uiStefan Hornburg
137690 (10 Mar 2002) taper Piotr Roszatycki
137698 (10 Mar 2002) vflib2Masato Taruishi
137707 (10 Mar 2002) xtel  Eric Delaunay
137940 (12 Mar 2002) kdm   Christopher L Cheney
138127 (13 Mar 2002) xserver-common-v3 Branden Robinson
138321 (14 Mar 2002) aeromail  Jim Studt
138597 (16 Mar 2002) smsclient Michael Holzt
138601 (16 Mar 2002) linuxlogo Steve Kostecke
139733 (24 Mar 2002) kdebase   Christopher L Cheney
139738 (24 Mar 2002) portsentryGuido Guenther
139739 (24 Mar 2002) kdegraphics   Christopher L Cheney
139750 (24 Mar 2002) adduser   Roland Bauerschmidt
139751 (24 Mar 

[Stefano =)] Bug#198619: Could not perform configuration on libpam0g

[Sam Hartman]

[Please cc me; I'm very behind on -devel]


I'm very confused by this bug and am sufficiently busy this week that
I'm not going to be able to diagnose it right now.

Could anyone who has a chance to do so please look at exactly what is
failing from a dependency standpoint?  
I get the feeling I'm missing
something about the interactions between pre-dependencies and
dependencies and apt.



--- Begin Message ---
Subject: Could not perform configuration on libpam0g
Package: libpam0g
Version: 0.76-12
Severity: normal
Tags: sid


I have tried to install Debian. Then i 've upraded it to SID. The same thing 
happens if I try to install Debian directly from SID. Apt-get says "Could 
not perform immediate configuration on libpam0g". On installations done 1 
month ago all the apt-get upgrade things works fine. This bug appears only 
on installations done in this week. This kind of bug then doesnt allow the 
installation and the configuration of dozens of packets as kdm, gcc and so 
on...


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux Lan1-700 2.4.20date27.5 #1 SMP Mon May 26 02:37:37 CEST 2003 
i686
Locale: LANG=C, LC_CTYPE=C

Versions of packages libpam0g depends on:
ii  libc6 2.3.1-17   GNU C Library: Shared libraries 
an
ii  libpam-modules0.76-11Pluggable Authentication 
Modules f
ii  libpam-runtime0.76-11Runtime support for the PAM 
librar

_
MSN Foto: condividi, ritocca e stampa le tue foto online  
http://photos.msn.it



--- End Message ---

Re: Please don't misuse the debian/changelog to close bugs!

[Herbert Xu]

Matthew Palmer <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2003, Herbert Xu wrote:
> 
>> It is in fact detrimental for a third group, people who are trying to
>> extract the version in which a given bug was fixed.
> 
> Aah, but if the bug wasn't fixed due to a change in the package, then it is
> misleading to say that the bug was somehow "fixed" in that version of the
> package.  It implies that versions less than the one in which the changelog
> entry appear have the bug - which they do not.

They were fixed by a change upstream and presumably this is the first
Debian release of that upstream release.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Please don't misuse the debian/changelog to close bugs!

[Herbert Xu]

Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 25, 2003 at 07:34:23PM +1000, Herbert Xu wrote:
> 
>> 2. debian/changelog readers -- No change.  They have lost a slight bit
>> information that is irrelevant for the purpose of documenting Debian
>> changes.
> 
> I am one of these readers.  I do this.  A lot.  Every day.  And I am telling
> you that the method that I have suggested in previous threads is VERY
> HELPFUL to me.  So, while you may disagree, do not misrepresent my
> situation.

Please pay more attention to the context.  I was responding to
John Robinson's suggestion to send a message to [EMAIL PROTECTED]
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Please don't misuse the debian/changelog to close bugs!

[Herbert Xu]

Brian Nelson <[EMAIL PROTECTED]> wrote:
> 
> It's pointless to go through this again.  Instead, I'll offer a concrete
> example of the confusion this can create (the original submitter asks
> for clarification of how the bug was fixed):
> 
> http://bugs.debian.org/188740

That's a documentation issue.  debian/changelog is not the place for
documenting random features.

>> As I have said before, this is incomplete: only bugs that were reported
>> and identified are listed, and redundant: these changes should be in
>> the upstream changelog already.
> 
> I don't see anything particularly helpful in the upstream changelog for
> the above example.

Please do not generalise the practice of individual upstream authors.
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Bug#198682: ITP: kernel-patch-2.4-low-latency -- Reduces the latency of the Linux kernel

[Simon Law]

On Wed, Jun 25, 2003 at 09:43:06AM +0200, Aurelien Jarno wrote:
> On Wed, Jun 25, 2003 at 07:43:34AM +0200, Tollef Fog Heen wrote:
> > It's already packaged:
> [...]
> 
> > : [EMAIL PROTECTED] ~ > apt-cache show kernel-patch-lowlatency-2.4 
> > Package: kernel-patch-lowlatency-2.4
> 
> Oops ! Sorry, closing the bug...
> 
> I searched with apt-cache for low-latency and it didn't give me this
> package. However, lowlatency give this package in the results...

Hmmm, I'm going to file bugs against this.

Simon