Re: gcc 4.1 or not

[Lionel Elie Mamane]

On Thu, May 11, 2006 at 08:15:21AM +0200, Martin Wuertele wrote:
> * Andreas Barth <[EMAIL PROTECTED]> [2006-05-10 23:11]:

>> there were some requests, e.g. by Martin Michlmayr to the release
>> team whether we could switch gcc to 4.1 or not for etch.

> I'm in favour of gcc 4.1 as it would provide our etch users with a
> fairly recent default gcc at the time of the release and avoids the
> rumor that debian releases badly outdated stuff as well.

I'd certainly prefer we shipped with the least bugs, rather than with
"fairly recent" software; I don't know if these goals contradict or
concur in this particular case.

-- 
Lionel


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

Re: Bits from the 2IC

[Sven Luther]

On Thu, May 11, 2006 at 01:10:16AM +0100, Steve McIntyre wrote:
> Unfortunately, other mailing list discussions have been less
> happy. A somewhat acrimonious argument between Sven Luther and members
> of the d-i team spread out across various lists, starting at
> [3]. There has been quite lot of public discussion and more private
> attempts to repair the situation, but at this point things are not
> looking too hopeful.

The situation is indeed not hopeful. The mediation attempt of the DPL failed,
as he ranged himself basically with the opinion of the d-i team, and acted
more like a judge delivering a sentence, than a mediator, sending his sentence
to a public list, without even forewarning me. I guess Anthony doesn't know
what mediation means.

I am thankful for the effort Steve made to try a true mediation, altough there
was absolutely no visibility and transparence of what discussions where going
on with the other side of this argument, which i believe only foreshadowed the
final sentence. It was more important to not hurt the feeling of the d-i team
and to let them have their pride, than to search a real solution to this issue.

Also, i do believe it sets a bad precedent, in that the DPL affirmed by this
actions, that it is ok for people inside debian to chose moment of personal
distress of other DDs to get revenge on them, and have no respect for the
person behind the DD. This is i belive a failure of the electronic media we
use for communication, people would generally not behave such in real life,
and if they did, they would be scorned upon by their entourage, and not 
justified
like it happens here.

I guess this means that i will take a less active role in debian in the
future, and to all those who are now saying good riddance, shame on you, you
are not worthy of what debian represents, altough that sure seems to have
changed since i first joined 8 years ago.

Hurt,

Sven Luther


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

Re: multiarch status update

[Gabor Gombas]

On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:

> Why would that not fly?
> Both versions of the arch-independent package could be installed at
> the same time.

/usr/share/foo/bar can't point to two different files at the same time,
so you can't install multiple package versions containing
incompatible /usr/share/foo/bar files.

The only way to support your proposal would be to kill the concept of
arch-independent packages and make everything arch-dependent. But that
would be a _HUGE_ waste of resources (/usr/share takes about half the
size of the /usr partition here). It's not worth it.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: gcc 4.1 or not

[Andreas Barth]

* Wouter Verhelst ([EMAIL PROTECTED]) [060511 08:59]:
> On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> > there were some requests, e.g. by Martin Michlmayr to the release team
> > whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> > freeze etch rather soon and also the RC bug count doesn't look too good,
> > and we want to be on time this time :), we think the switch to gcc 4.1
> > as default should only be made if not more than 20 packages become RC
> > buggy by it.  Also, the switch should happen latest 1.5 months prior to
> > freeze, that is Jun 15th.
> 
> Additional data point: GCC 4.0 on m68k is mostly crap, and probably the
> reason why we haven't been able to make it back as a release candidate
> architecture yet.

Yes, known. However, we have to consider what is worse - adding more RC
bugginess on all arches, or being bad to one arch already having some
(other) issues. And I think the number of 20 new RC bugs is fair to both
sides (or that's at least what we thought when we discussed about the
numbers).

> GCC 4.1 fixes a _lot_ of the GCC 4.0 bugs on m68k, and we'd really,
> _really_ love to see it become the default, at the very least on our
> architecture. So, I guess that means we'll have to help out there,
> doesn't it? ;-)

Definitly. :)

> 
> One: What's the easiest way to extract the list of gcc-4.1 related bugs
> from the BTS?

There is none I know - I asked Martin already yesterday on IRC to
provide such a way.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: gcc 4.1 or not

[Wouter Verhelst]

On Thu, May 11, 2006 at 10:00:46AM +0200, Andreas Barth wrote:
> * Wouter Verhelst ([EMAIL PROTECTED]) [060511 08:59]:
> > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> > > there were some requests, e.g. by Martin Michlmayr to the release team
> > > whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> > > freeze etch rather soon and also the RC bug count doesn't look too good,
> > > and we want to be on time this time :), we think the switch to gcc 4.1
> > > as default should only be made if not more than 20 packages become RC
> > > buggy by it.  Also, the switch should happen latest 1.5 months prior to
> > > freeze, that is Jun 15th.
> > 
> > Additional data point: GCC 4.0 on m68k is mostly crap, and probably the
> > reason why we haven't been able to make it back as a release candidate
> > architecture yet.
> 
> Yes, known. However, we have to consider what is worse - adding more RC
> bugginess on all arches, or being bad to one arch already having some
> (other) issues.

Yes, I understand that; I just wanted to explain for people not familiar
with the issues, that's all.

> And I think the number of 20 new RC bugs is fair to both
> sides (or that's at least what we thought when we discussed about the
> numbers).

Sure. Which is mostly why I'm suggesting to help out.

> > One: What's the easiest way to extract the list of gcc-4.1 related bugs
> > from the BTS?
> 
> There is none I know - I asked Martin already yesterday on IRC to
> provide such a way.

Right. For now, I'll start off with suggesting upstream to have a look
at #361396 :-)

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: multiarch status update

[Olaf van der Spek]

On 5/11/06, Gabor Gombas <[EMAIL PROTECTED]> wrote:

On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:

> Why would that not fly?
> Both versions of the arch-independent package could be installed at
> the same time.

/usr/share/foo/bar can't point to two different files at the same time,
so you can't install multiple package versions containing
incompatible /usr/share/foo/bar files.

The only way to support your proposal would be to kill the concept of


I think there are much more ways to implement it. :)
But indeed, having all packages put files in a single directory won't work.
But that approach is resulting in some problems already today.


arch-independent packages and make everything arch-dependent. But that
would be a _HUGE_ waste of resources (/usr/share takes about half the
size of the /usr partition here). It's not worth it.

Re: gcc 4.1 or not

[Domenico Andreoli]

On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> Hi,

hi,

> there were some requests, e.g. by Martin Michlmayr to the release team
> whether we could switch gcc to 4.1 or not for etch.  As we're heading to

what about the transition to python 2.4? is it going to start or etch
is going to ship with 2.3?

cheers
domenico

-[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50


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

Re: Bits from the 2IC

[Marc 'HE' Brockschmidt]

Sven Luther <[EMAIL PROTECTED]> writes:
> On Thu, May 11, 2006 at 01:10:16AM +0100, Steve McIntyre wrote:
>> Unfortunately, other mailing list discussions have been less
>> happy. A somewhat acrimonious argument between Sven Luther and members
>> of the d-i team spread out across various lists, starting at
>> [3]. There has been quite lot of public discussion and more private
>> attempts to repair the situation, but at this point things are not
>> looking too hopeful.
> The situation is indeed not hopeful. The mediation attempt of the DPL failed,
> as he ranged himself basically with the opinion of the d-i team, and acted
> more like a judge delivering a sentence, than a mediator, sending his sentence
> to a public list, without even forewarning me. I guess Anthony doesn't know
> what mediation means.

A reason for the failing of mediation is that you seem to have no
interest to work together with the people who have (not in a very nice
way) removed your commit rights. You have kept flaming on public lists
in the last few days, which is normally not a good way to get people to
calm down. 

What you seem to want is some sort of decision that forces other
developers to work together with you, not a mediation. Working together
is not only based on technical stuff, but has also a social level. Your
recent actions have shown that you do not understand about this, and I
have to admit that it's probably better for the d-i team if they don't
have to fight with you on a regular basis. The time and motivation lost
in flamewars is more valuable than anything a single developer could
contribute.

Marc
-- 
BOFH #448:
vi needs to be upgraded to vii


pgpm9RVGbvoGW.pgp
Description: PGP signature

libgnutls (was: gcc 4.1 or not)

[Andreas Barth]

* Mike Hommey ([EMAIL PROTECTED]) [060511 11:00]:
> On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL 
> PROTECTED]> wrote:
> > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> > > Hi,
> > 
> > hi,
> > 
> > > there were some requests, e.g. by Martin Michlmayr to the release team
> > > whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> > 
> > what about the transition to python 2.4? is it going to start or etch
> > is going to ship with 2.3?
> 
> what about the transition to libgnutls13 ? I noticed yesterday when
> debootstraping that we get libgnutls11, 12 AND 13 installed by default.
> Do we really need that many libgnutls ?

Please see e.g. bug #363294, there are some discussions about that. Of
course, as in all that issues, feel free to help with packages moving
away from gnutls11, but that is as of now not an RC bug (and we speak of
68 packages in testing currently using libgnutls11, which are not too
few).

However, it would be quite more helpful to reduce the number of real RC
bugs - we need to get down from the number of 400.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: gcc 4.1 or not

[Josselin Mouette]

Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit :
> what about the transition to python 2.4? is it going to start or etch
> is going to ship with 2.3?

An upload of python-defaults switching to 2.4 has been repeatedly asked
during the last months, and it was ignored by the maintainer. I'm not
aware of anything preventing this upload currently.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

python version? (was: gcc 4.1 or not)

[Andreas Barth]

* Josselin Mouette ([EMAIL PROTECTED]) [060511 10:48]:
> Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit :
> > what about the transition to python 2.4? is it going to start or etch
> > is going to ship with 2.3?
> 
> An upload of python-defaults switching to 2.4 has been repeatedly asked
> during the last months, and it was ignored by the maintainer. I'm not
> aware of anything preventing this upload currently.

The maintainer is not ignoring it, but the transition needs to have some
issues fixed first. (And if you want to discuss aboutt hat, please leave
-release out of the discussion. :)


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: gcc 4.1 or not

[Mike Hommey]

On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL PROTECTED]> 
wrote:
> On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> > Hi,
> 
> hi,
> 
> > there were some requests, e.g. by Martin Michlmayr to the release team
> > whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> 
> what about the transition to python 2.4? is it going to start or etch
> is going to ship with 2.3?

what about the transition to libgnutls13 ? I noticed yesterday when
debootstraping that we get libgnutls11, 12 AND 13 installed by default.
Do we really need that many libgnutls ?

Mike


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

Re: Bug#366780: ITP: summain -- compute and verify file checksums

[Thijs Kinkhorst]

Hello Lars,

On Thu, 2006-05-11 at 03:35 +0300, Lars Wirzenius wrote:
>  A checksum is a number that identifies the contents of a file: if the
>  contents change, so does the checksum. If you create a checksum before
>  you burn a CD, when you know the files are correct, you can easily
>  check the CD at any time: just compute the checksum again and see if
>  they have changed.
>  .
>  summain computes and checks files against such checksums. It supports
>  both MD5 and SHA-1 checksums, using formats compatible with the md5sum
>  and sha1sum utilities, both for reading and writing. In addition, it
>  can read and verify checksums from Debian .dsc, .changes, and Sources
>  files.
> 
> (This ITP is for a program not quite released yet. I hope to get some
> feedback on the description. The release and package upload to NEW will
> happen once Debcamp6 Internet access gets more usable, or when I return
> home.)

I like the description, but I'd switch the two paragraphs. People
reading the details for this package would in most cases already be
familiar with what a checksum is. It's good to explain it for those not
yet "in the know", but it might be better to demote that information.


Thijs


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

Intent to hijack Bacula

[Roberto Lumbreras]

On Tue, 9 May 2006 11:07:27, John Goerzen wrote:
: Hello,
: 
: I intend to take over the Bacula package.  I would first like to say
: thanks to Jose Luis Tallon for initially packaging it for Debian and
: maintaining it for these years.
: 
: A brief history of why I intend to do this:
: 
:  * Bacula has had RC bugs open for more than a year.  It was removed
:from testing several months ago because of this.
: 
:  * Bacula's current maintainer is not a Debian Developer and has been
:in NM since 2003.
: 
:  * Bacula as it currently exists in sid is unbuildable and
:uninstallable.  Bacula will not be present in etch unless significant
:problems are fixed.
: 
:  * The last upload for Bacula was almost a year ago.
: 
:  * The maintainer has repeatedly, over the last year, said he's working
:on this but hasn't made much real progress, and has made no upload to
:Debian.
: 
:  * Several additional critical-level or grave-level unreported bugs
:exist in the bacula Debian source tree (such as stopping database servers
:without permission and deleting files un-owned by a particular
:package)
: 
:  * There are various policy compliance issues with the current packages.
: 
:  * The current maintainer does respond to pings, but has a long record
:of problems getting bugs (even RC bugs) fixed in a timely fashion.

I don't agree, all those things are not in my opinion enough for the
hijacking.

The package has bugs, lots of them, and for that reason has been removed
from testing, well done, unstable it is here for that.

The lots of bugs had not been solved, and several upstream versions had
delayed again and again the uploads Jose Luis has been working on. A lot of
work have to be done to package a new version, and a new upstream version
when the last one is not yet finished doesn't help to get the things done.

Ok, the maintainer has not fixed the bugs, has not packaged the last
version of it in time, etc, but he has done a great job anyway, and I
still don't see the point of hijacking the package.

If the maintainer still wants to maintain it, help him, do NMUs, whatever,
but I'm still looking for one reason you can take over the package against
the maintainer opinion.

Regards,
rover, Jose Luis's sponsor and uploader of many of his packages including
bacula, you can blame me also if you want

Salud,
-- 
Roberto Lumbreras   .''`.

Debian Developer   `. `' 
 `-  


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

Re: System users and valid shells...

[Jari Aalto]

Uwe Hermann <[EMAIL PROTECTED]> writes:
> On Fri, May 05, 2006 at 11:12:35AM +0300, Jari Aalto wrote:
>> > The rest of the system accounts are happily running with /bin/false
>> 
>> There is now /bin/nologin which is more secure
>
> I think you mean /usr/sbin/nologin, right? Please define "more secure"
> in this context.

The /bin/nologin records the user who tried to log in. This helps
auditing the system and provides more secure approach to system
monitoring.

/bin/nologin is straight replacement of /bin/false. It originates
from BSD systems.

Jari



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

Re: gcc 4.1 or not

[Martin Michlmayr]

> I didn't hit this problem myself yet, but it has been mentioned on
> sparclinux list that 4.1 currently miscompiles the sparc kernel.

Do you know if this still happens, and if so, whether someone has
tracked it down?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: gcc 4.1 or not

[Martin Michlmayr]

* Lionel Elie Mamane <[EMAIL PROTECTED]> [2006-05-11 09:13]:
> I'd certainly prefer we shipped with the least bugs, rather than with
> "fairly recent" software; I don't know if these goals contradict or
> concur in this particular case.

FWIW, the GCC 4.0.3 Status Report (2006-01-15) says, "It's interesting
to note that there are 95 serious regressions against 4.0.3 and only
63 against 4.1.0; although 4.0.3 has surely had more usage, this does
suggest that 4.1.0 is in reasonably good shape".  Obviously, GCC 4.1
is not free of bugs though.  A more recent report, GCC 4.1 Status
Report (2006-04-16), says that there "are 101 "serious" (P3 or higher)
regressions against GCC 4.1, the vast majority of which also apply to
4.2" and moves the release date of 4.1.1 from April 28 to May 15.

References:
http://gcc.gnu.org/ml/gcc/2006-01/msg00477.html
http://gcc.gnu.org/ml/gcc/2006-04/msg00269.html
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Intent to hijack Bacula

[Marc 'HE' Brockschmidt]

Roberto Lumbreras <[EMAIL PROTECTED]> writes:
[...]
> Ok, the maintainer has not fixed the bugs, has not packaged the last
> version of it in time, etc, but he has done a great job anyway, and I
> still don't see the point of hijacking the package.

So he has done not one of the things expected of a good package
maintainer. *What* of that is a "great job"?

Marc
-- 
BOFH #337:
the butane lighter causes the pincushioning


pgpf9mE1B0VfX.pgp
Description: PGP signature

Re: Intent to hijack Bacula

[Stephen Frost]

* Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
> I don't agree, all those things are not in my opinion enough for the
> hijacking.

Thankfully, you're wrong.

> The package has bugs, lots of them, and for that reason has been removed
> from testing, well done, unstable it is here for that.

It's *not* ok for the package to have been removed from testing.  It
also had no real hope getting back into testing at the rate with which
the bugs were being resolved by Jose.

> The lots of bugs had not been solved, and several upstream versions had
> delayed again and again the uploads Jose Luis has been working on. A lot of
> work have to be done to package a new version, and a new upstream version
> when the last one is not yet finished doesn't help to get the things done.

That's not an excuse.  At all.

> Ok, the maintainer has not fixed the bugs, has not packaged the last
> version of it in time, etc, but he has done a great job anyway, and I
> still don't see the point of hijacking the package.

He *hasn't* done a great job..  That would be basically the *point*.

> If the maintainer still wants to maintain it, help him, do NMUs, whatever,
> but I'm still looking for one reason you can take over the package against
> the maintainer opinion.

He wants to have his name on the package w/o doing the work
(apparently).  That's not maintaining it, regardless of what he'd like
to claim.

> rover, Jose Luis's sponsor and uploader of many of his packages including
> bacula, you can blame me also if you want

We do.

Enjoy,

Stephen


signature.asc
Description: Digital signature

Re: gcc 4.1 or not

[Martin Zobel-Helas]

Hi Andi,

On Wednesday, 10 May 2006, you wrote:
> there were some requests, e.g. by Martin Michlmayr to the release team
> whether we could switch gcc to 4.1 or not for etch.  As we're heading to

I know, tbm tried to build all packages on mips*. It would be intersting
to know, how other architectures behave. Also i have not seen any
comments from doko yet.

Greetings
Martin


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

Re: PDF files and dh_compress

[Juliusz Chroboczek]

> I am strongly against compressing PDFs

To add insult to injury, PDF 1.5 introduces ``object streams'' which
allow compressing arbitrarily long chunks of a PDF file without giving
up the random-access properties of PDF.  All current Free PDF readers
grok PDF 1.5, although as far as I know no Free software can produce
PDF 1.5 object streams.

Hence the right solution is to fix gs and pdftex to produce object
streams, not to work around the limitations of current Free software
by gzipping PDF files and thus giving up the (quite amazing) efficiency
of the format.

Juliusz



pgpSAcwT7EVY5.pgp
Description: PGP signature

Bug#366820: Transition to GCC 4.1 for etch

[Martin Michlmayr]

Package: general
Severity: wishlist

It would be great if we could move to GCC 4.1 for etch.  The release
managers have now given us a concrete target we have to achieve before
this can happen: the majority of outstanding 4.1 specific bugs in
packages have to be fixed by mid of June [1].  The RC bug NMU policy
applies to such bugs as of now.  This bug report will be used as a
meta bug to track outstsanding GCC 4.1 bugs in packages.

Some background information:

In March, I built the whole archive with GCC 4.1 on several
architectures and filed about 280 bugs related to the new compiler
(mostly in package using C++) [2].  Many of those bugs had patches and
now, roughly two months later, about half of them have been fixed.
However, we need to get rid of the remaining bugs.  Most of them
should be trivial to fix anyway.  Some information about common C++
errors can be found in [3].


[1] http://lists.debian.org/debian-devel/2006/05/msg00355.html
[2] http://lists.debian.org/debian-gcc/2006/03/msg00405.html
[3] http://womble.decadentplace.org.uk/c++/syntax-errors.html
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: net-tools maintenance status

[Olaf van der Spek]

On 3/9/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote:

On 1/6/06, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> Thijs Kinkhorst <[EMAIL PROTECTED]> wrote:
> > So I think you can tell pretty clearly that Bernd has no objection at all
> > to NMU's.
>
> yes, but please not for wishlist bugs. Again: there are bugs open for
> net-tools where help is requested, I would love to have patches for those.
> Generally I am not aware of time critical bugs.
>
> The wishlist bugs will get fixed in the next upstream version, however that
> needs some sorting out of the upstream cvs which is not in sync with redhat,
> suse and debian.

Hi Bernd,

What's the status of the next upstream version?
Do you think it'll be ready before Etch?


Hi again, Bernd,

Could you answer the question, please?
I'd like netstat to have proper IPv4 support.

Greetings,

Olaf

Re: Intent to hijack Bacula

[Riku Voipio]

On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote:
> The package has bugs, lots of them, and for that reason has been removed
> from testing, well done, unstable it is here for that.

Uh no. I find it scary that you share this same idea as the original
bacula maintainer. Unstable is NOT a graveyard for packages with RC 
bugs years old!

While it is not uncommon to people to upload broken packages unstable,
it's still not something unstable is meant for. And it certainly isn't
ok just leave broken packages there.. 


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

Re: Intent to hijack Bacula

[Frank Küster]

Roberto Lumbreras <[EMAIL PROTECTED]> wrote:

> The package has bugs, lots of them, and for that reason has been removed
> from testing, well done, unstable it is here for that.

No, it isn't.  Maybe experimental is for that; but unstable is for
software that is targetted to be moved to etch and to be released.

> The lots of bugs had not been solved, and several upstream versions had
> delayed again and again the uploads Jose Luis has been working on. A lot of
> work have to be done to package a new version, and a new upstream version
> when the last one is not yet finished doesn't help to get the things done.

If upstream versions come in too fast, that's no reason for not
uploading a version that is better than the current one, even if it is
still not the newest upstream version.

If upstream versions change that much that each time the packaging needs
to be rewritten, either the software is not stable enough for a release
(which doesn't seem to be the case with bacula) or the packaging
approaches are bad.

> Ok, the maintainer [...] has done a great job anyway,

You don't give any reasons for this claim.  John has given several
against it.

> rover, Jose Luis's sponsor and uploader of many of his packages including
> bacula, you can blame me also if you want

Indeed, if a package that a DD has sponsored into unstable has RC bugs,
they should care about it and make sure those bugs are fixed in time.
If you think you won't have time for this, don't sponsor the package.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: python version?

[Ganesan Rajagopal]

> Andreas Barth <[EMAIL PROTECTED]> writes:

>> An upload of python-defaults switching to 2.4 has been repeatedly asked
>> during the last months, and it was ignored by the maintainer. I'm not
>> aware of anything preventing this upload currently.

> The maintainer is not ignoring it, but the transition needs to have some
> issues fixed first. (And if you want to discuss aboutt hat, please leave
> -release out of the discussion. :)

The last time this came up in, the majority view was to transition to 2.4 as
default the "old way" rather than keeping it pending for so long. 

Ganesan

-- 
Ganesan Rajagopal


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

Re: Intent to hijack Bacula

[John Goerzen]

On Thu, May 11, 2006 at 01:09:11PM +0200, Roberto Lumbreras wrote:
> rover, Jose Luis's sponsor and uploader of many of his packages including
> bacula, you can blame me also if you want

Others have pretty well addressed the rest of your message already.  I'd
like to expand on this point.

I've been aware that it was you that uploaded at least some of the
bacula packages for a couple of days now.  I didn't mention it, since it
wasn't directly related to getting Bacula's problems fixed.  Since you
bring it up, though, I think there is an important lesson in this.

The Bacula packages should never have been uploaded.

As sponsor, it is your duty to make sure that they meet a certain
minimum level of quality.  That they don't install a trojan on
somebody's machine, delete files from other packages, mess up other
services, etc.  Except for the trojan, Bacula actually does all of that
(including messing with DB server configs **by keying off a comment!**
and restarting a DB server without permission).

Bacula should probably never have been accepted into unstable in the
first place, and you are the person that should have prevented that.  (I
admit I haven't looked at the 2004 packages, but certainly the more
recent ones that you uploaded had serious flaws.)

DDs that sponsor uploads must ensure that the code they upload is
decent.

And no, unstable is not a dumping ground for everything that is crappy
and broken.  Unstable is for code that should eventually make it into
stable but hasn't been proven with the wider community yet.  If you
believe code wouldn't be suitable for a stable release, you shouldn't
upload it into unstable.

-- John


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

Re: python version?

[Andreas Barth]

* Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]:
> > Andreas Barth <[EMAIL PROTECTED]> writes:
> 
> >> An upload of python-defaults switching to 2.4 has been repeatedly asked
> >> during the last months, and it was ignored by the maintainer. I'm not
> >> aware of anything preventing this upload currently.
> 
> > The maintainer is not ignoring it, but the transition needs to have some
> > issues fixed first. (And if you want to discuss aboutt hat, please leave
> > -release out of the discussion. :)
> 
> The last time this came up in, the majority view was to transition to 2.4 as
> default the "old way" rather than keeping it pending for so long. 

I'm not really aware of the python issues. Are there enough python
people on Debconf to make an ad-hoc BoF about python?


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: gcc 4.1 or not

[Martin Michlmayr]

* Martin Zobel-Helas <[EMAIL PROTECTED]> [2006-05-11 13:38]:
> I know, tbm tried to build all packages on mips*. It would be intersting
> to know, how other architectures behave. Also i have not seen any
> comments from doko yet.

I built mips and amd64, and in the mean time also powerpc and most of
sparc.

Apparently hppa has some problems but I don't know any details:

22:10 < vorlon> also, do you know about the hppa ABI skew issues?
22:12 < vorlon> libstdc++6 from gcc-4.1 source doesn't work with gcc-4.0 as
a compiler, because of a libgcc_s soname change

-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Intent to hijack Bacula

[Roberto Lumbreras]

On Thu, May 11, 2006 at 07:46:33AM -0400, Stephen Frost wrote:
: 
: Roberto,
: 
:   Your mailer is busted.  You might want to fix it- it's setting an
:   invalid Reply-To address.  Below is the bounce (including my reply, if
:   you don't see it on d-d).

My fault, I misplaced the msgid of the mail from John Gorzen in Reply-to
instead of In-Reply-to, argh.

Speaking about your mail, I think it's your opinion, mine is different.

Jose Luis doesn't want just his name in some place, he has worked a lot
in bacula in the past, and I don't know why he can't remain as
maintainer or co-maitainer if he is going to work on it again.

Obviuosly if he is unable to maitain it or work on it, it should orphan
the package, but it seems that things are different.

Regards,
rover

:   Enjoy,
:   
:   Stephen
: 
: Content-Description: Undelivered Message
: Date: Thu, 11 May 2006 07:44:19 -0400
: From: Stephen Frost <[EMAIL PROTECTED]>
: To: [EMAIL PROTECTED],
:   John Goerzen <[EMAIL PROTECTED]>, debian-devel@lists.debian.org,
:   José Luis Tallón <[EMAIL PROTECTED]>
: User-Agent: Mutt/1.5.11+cvs20060403
: Subject: Re: Intent to hijack Bacula
: 
: * Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
: > I don't agree, all those things are not in my opinion enough for the
: > hijacking.
: 
: Thankfully, you're wrong.
: 
: > The package has bugs, lots of them, and for that reason has been removed
: > from testing, well done, unstable it is here for that.
: 
: It's *not* ok for the package to have been removed from testing.  It
: also had no real hope getting back into testing at the rate with which
: the bugs were being resolved by Jose.
: 
: > The lots of bugs had not been solved, and several upstream versions had
: > delayed again and again the uploads Jose Luis has been working on. A lot of
: > work have to be done to package a new version, and a new upstream version
: > when the last one is not yet finished doesn't help to get the things done.
: 
: That's not an excuse.  At all.
: 
: > Ok, the maintainer has not fixed the bugs, has not packaged the last
: > version of it in time, etc, but he has done a great job anyway, and I
: > still don't see the point of hijacking the package.
: 
: He *hasn't* done a great job..  That would be basically the *point*.
: 
: > If the maintainer still wants to maintain it, help him, do NMUs, whatever,
: > but I'm still looking for one reason you can take over the package against
: > the maintainer opinion.
: 
: He wants to have his name on the package w/o doing the work
: (apparently).  That's not maintaining it, regardless of what he'd like
: to claim.
: 
: > rover, Jose Luis's sponsor and uploader of many of his packages including
: > bacula, you can blame me also if you want
: 
: We do.
: 
:   Enjoy,
: 
:   Stephen
: 
: 
: 
: 
: - End forwarded message -


Salud,
-- 
Roberto Lumbreras   .''`.

Debian Developer   `. `' 
 `-  


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

Re: gcc 4.1 or not

[Martin Michlmayr]

* Martin Michlmayr <[EMAIL PROTECTED]> [2006-05-11 14:20]:
> > I know, tbm tried to build all packages on mips*. It would be intersting
> > to know, how other architectures behave. Also i have not seen any
> > comments from doko yet.
> I built mips and amd64, and in the mean time also powerpc and most of
> sparc.

What still needs to be done (on all architectures) is to find packages
that build-depend on a specifc version of GCC, find out why they do
this and see if GCC 4.1 works.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Intent to hijack Bacula

[Stephen Frost]

* Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
> Speaking about your mail, I think it's your opinion, mine is different.

Sure, but you're looking through some very rosy glasses.

> Jose Luis doesn't want just his name in some place, he has worked a lot
> in bacula in the past, and I don't know why he can't remain as
> maintainer or co-maitainer if he is going to work on it again.

You don't get to rest on your laurels in Debian.  Especially when it's
been over a year.

> Obviuosly if he is unable to maitain it or work on it, it should orphan
> the package, but it seems that things are different.

That would be exactly the problem- he wants to remain as maintainer or
co-maintainer yet has shown nothing to indicate that he's going to work
on it again.  Not only that but he's trying to refuse work done by others 
(John) which is clearly in the best interest of Debian and its users
(like, I dunno, getting bacula into a state where it can get back into
testing...).

Besides, Jose Luis will still be able to help with bacula, if he really
wants to, by doing bug triage, submitting patches, etc.  I fully agree
with John's statement though- based on the state which bacula was in and
the things which were done in it that were *clearly* policy violations,
Jose Luis' contributions need to be checked before being committed.

This is something that anyone sponsoring anyone's packages *should* have
been doing already.  Unfortunately, that part seems to have been
forgotten by some.

Enjoy,

Stephen


signature.asc
Description: Digital signature

Processed: track GCC 4.1 bugs; part 2/4

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 366820 by 357961
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 361766
Blocking bugs added: 357961

> block 366820 by 357962
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 361766
Blocking bugs added: 357962

> block 366820 by 357964
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 357962 361766
Blocking bugs added: 357964

> block 366820 by 357996
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 357962 357964 361766
Blocking bugs added: 357996

> block 366820 by 358075
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 357962 357964 357996 361766
Blocking bugs added: 358075

> block 366820 by 358207
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 357962 357964 357996 358075 361766
Blocking bugs added: 358207

> block 366820 by 358212
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687 357720 357748 357774 357863 357961 357962 357964 357996 358075 358207 
361766
Blocking bugs added: 358212

> block 366820 by 358277
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 356436 356439 356444 356455 356517 356522 356540 356564 
356583 356597 356598 356636 356646 356679 356691 356878 356892 356968 356970 
356971 356980 357056 357057 357084 357182 357317 357334 357339 357359 357380 
357401 357408 357447 357455 357490 357552 357557 357566 357644 357656 357659 
357687

Processed: track GCC 4.1 bugs; part 1/4

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 366820 by 355163
Bug#366820: Transition to GCC 4.1 for etch
Was not blocked by any bugs.
Blocking bugs added: 355163

> block 366820 by 355352
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163
Blocking bugs added: 355352

> block 366820 by 355396
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352
Blocking bugs added: 355396

> block 366820 by 355598
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396
Blocking bugs added: 355598

> block 366820 by 355841
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598
Blocking bugs added: 355841

> block 366820 by 355983
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841
Blocking bugs added: 355983

> block 366820 by 355989
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983
Blocking bugs added: 355989

> block 366820 by 355997
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989
Blocking bugs added: 355997

> block 366820 by 356004
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997
Blocking bugs added: 356004

> block 366820 by 356093
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004
Blocking bugs added: 356093

> block 366820 by 356109
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093
Blocking bugs added: 356109

> block 366820 by 361766
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109
Blocking bugs added: 361766

> block 366820 by 356110
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 361766
Blocking bugs added: 356110

> block 366820 by 356116
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 361766
Blocking bugs added: 356116

> block 366820 by 356160
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 361766
Blocking bugs added: 356160

> block 366820 by 356228
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 361766
Blocking bugs added: 356228

> block 366820 by 356232
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 361766
Blocking bugs added: 356232

> block 366820 by 356238
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 361766
Blocking bugs added: 356238

> block 366820 by 356246
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 361766
Blocking bugs added: 356246

> block 366820 by 356248
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 361766
Blocking bugs added: 356248

> block 366820 by 356303
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 361766
Blocking bugs added: 356303

> block 366820 by 356304
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
361766
Blocking bugs added: 356304

> block 366820 by 356366
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 361766
Blocking bugs added: 356366

> block 366820 by 356370
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 361766
Blocking bugs added: 356370

> block 366820 by 356436
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 355163 355352 355396 355598 355841 355983 355989 355997 356004 
356093 356109 356110 356116 356160 356228 356232 356238 356246 356248 356303 
356304 356366 356370 361766
Blocking bugs added: 356436

Processed: gcc 4.1

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> block 366820 by 366821
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 275774 355163 355165 355189 355325 355326 355352 355396 355463 
355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 
355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 
356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 
356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 
356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 
356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 
356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 
356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 
356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 
356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 
356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 
356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 
357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 
357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 
357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 
357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 
357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 
357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 
357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 
357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 
357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 
358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 
358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 
358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 
358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 
361331 361333 361334 361335 361336 361389 361396 361766 364814
Blocking bugs added: 366821

> block 366820 by 366753
Bug#366820: Transition to GCC 4.1 for etch
Was blocked by: 275774 355163 355165 355189 355325 355326 355352 355396 355463 
355598 355599 355663 355738 355739 355741 355744 355841 355980 355983 355986 
355988 355989 355990 355992 355993 355996 355997 355998 356003 356004 356093 
356098 356100 356109 356110 356111 356113 356115 356116 356121 356153 356155 
356156 356157 356159 356160 356161 356163 356168 356169 356170 356171 356173 
356174 356175 356176 356228 356229 356232 356233 356234 356238 356240 356241 
356242 356244 356245 356246 356248 356303 356304 356305 356321 356322 356323 
356324 356361 356362 356366 356367 356370 356374 356405 356422 356423 356424 
356425 356428 356436 356439 356440 356442 356444 356445 356453 356455 356516 
356517 356522 356540 356546 356549 356564 356570 356574 356579 356582 356583 
356585 356590 356592 356597 356598 356601 356606 356611 356620 356634 356636 
356646 356679 356684 356691 356767 356875 356878 356881 356892 356893 356964 
356965 356967 356968 356970 356971 356972 356979 356980 357056 357057 357059 
357061 357064 357070 357084 357096 357111 357112 357113 357117 357119 357182 
357184 357186 357189 357190 357316 357317 357322 357324 357325 357328 357334 
357335 357339 357340 357357 357358 357359 357360 357376 357380 357382 357383 
357401 357402 357403 357404 357408 357447 357455 357467 357476 357478 357479 
357481 357483 357490 357513 357552 357555 357556 357557 357558 357565 357566 
357600 357601 357614 357640 357644 357648 357651 357656 357659 357687 357710 
357711 357717 357720 357748 357750 357770 357774 357789 357810 357825 357849 
357861 357863 357864 357866 357897 357901 357959 357960 357961 357962 357964 
357967 357995 357996 358053 358062 358068 358069 358074 358075 358077 358087 
358090 358096 358206 358207 358208 358212 358214 358218 358219 358221 358228 
358240 358243 358259 358261 358263 358271 358277 358280 358281 358282 358284 
358285 358286 358287 358289 358290 358291 358292 358293 358294 358298 358300 
358301 358449 358542 358582 358591 358643 358644 358650 358881 358884 358886 
361331 361333 361334 361335 361336 361389 361396 361766 364814 366821
Blocking bugs added: 366753

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Auto-trace

[lee . s . isbell]

Martin,
Is this auto-trace program available for public use?
Thanks,
Stan


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

Re: gcc 4.1 or not

[Martin Michlmayr]

* Andreas Barth <[EMAIL PROTECTED]> [2006-05-11 10:00]:
> > One: What's the easiest way to extract the list of gcc-4.1 related bugs
> > from the BTS?
> 
> There is none I know - I asked Martin already yesterday on IRC to
> provide such a way.

I've created the following meta bug: 366820

-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Bug#366780: ITP: summain -- compute and verify file checksums

[Ben Pfaff]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

>  A checksum is a number that identifies the contents of a file: if the
>  contents change, so does the checksum. If you create a checksum before
>  you burn a CD, when you know the files are correct, you can easily
>  check the CD at any time: just compute the checksum again and see if
>  they have changed.
>  .
>  summain computes and checks files against such checksums. It supports
>  both MD5 and SHA-1 checksums, using formats compatible with the md5sum
>  and sha1sum utilities, both for reading and writing. In addition, it
>  can read and verify checksums from Debian .dsc, .changes, and Sources
>  files.

It's not clear to me, from the description, what the program does
that the md5sum and sha1sum utilities do not.
-- 
"If a person keeps faithfully busy each hour of the working day, he
 can count on waking up some morning to find himself one of the
 competent ones of his generation."
--William James


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

Re: gcc 4.1 or not

[Gustavo Franco]

On 5/11/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

* Andreas Barth <[EMAIL PROTECTED]> [2006-05-11 10:00]:
> > One: What's the easiest way to extract the list of gcc-4.1 related bugs
> > from the BTS?
>
> There is none I know - I asked Martin already yesterday on IRC to
> provide such a way.

I've created the following meta bug: 366820



Hi Martin,

Why you did this metabug thing, and not just usertagged the bugs ? The
results seems to be similar, but i don't think that a metabug can be
managed by email, usertags are.

regards,
-- stratus

Re: gcc 4.1 or not

[Martin Michlmayr]

* Gustavo Franco <[EMAIL PROTECTED]> [2006-05-11 11:20]:
> Why you did this metabug thing, and not just usertagged the bugs ? The
> results seems to be similar, but i don't think that a metabug can be
> managed by email, usertags are.

What can not be managed by email?
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Kari Pahula]

Package: wnpp
Severity: wishlist
Owner: Kari Pahula <[EMAIL PROTECTED]>


* Package name: cxxtools
  Version : 1.4.1pre2
  Upstream Author : Tommi Mäkitalo <[EMAIL PROTECTED]>
* URL : http://www.tntnet.org/
* License : GPL v2 or later
  Programming Lang: C++
  Description : library of unrelated but useful C++ classes

 cxxtools contains an argument-parser, a base-64 encoder/decoder, a
 C++ interface to iconv, md5-stream for easy MD5 calculation,
 threading classes, socket classes, a dynamic exception-safe buffer, a
 wrapper for dlopen/dlsym, a pool template (e.g., for a connection
 pool in a multi-threaded application), query_params, and a class for
 easy parsing of CGI parameters (GET and POST) in a CGI program.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[martin f krafft]

also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
> * License : GPL v2 or later

That will make it pretty useless for non-GPL applications. Why don't
you choose (if possible) a less "viral" licence?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
"women love us for our defects.
 if we have enough of them,
 they will forgive us everything,
 even our gigantic intellects."
-- oscar wilde


signature.asc
Description: Digital signature (GPG/PGP)

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Michael Banck]

On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
> > * License : GPL v2 or later
> 
> That will make it pretty useless for non-GPL applications. 

Non-GPL compatible applications, you mean?

> Why don't you choose (if possible) a less "viral" licence?

Wow.  First off, Kari does not appear to be upstream, so who are you
addressing?  Seconds, since when do we consider the GPL to be viral?


Michael


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Frank Küster]

Michael Banck <[EMAIL PROTECTED]> wrote:

> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
>> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
>> > * License : GPL v2 or later
>> 
>> That will make it pretty useless for non-GPL applications. 
>
> Non-GPL compatible applications, you mean?

Which non-GPL license can I choose for a software that uses this
library? 

> Seconds, since when do we consider the GPL to be viral?

Don't know about you, but the FSF does - it has created the LGPL because
of this.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Thiemo Seufer]

Frank Küster wrote:
> Michael Banck <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
> >> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
> >> > * License : GPL v2 or later
> >> 
> >> That will make it pretty useless for non-GPL applications. 
> >
> > Non-GPL compatible applications, you mean?
> 
> Which non-GPL license can I choose for a software that uses this
> library? 

BSD should be fine, for example.

> > Seconds, since when do we consider the GPL to be viral?
> 
> Don't know about you, but the FSF does - it has created the LGPL because
> of this.

http://www.gnu.org/licenses/why-not-lgpl.html


Thiemo

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Frank Küster]

Simon Josefsson <[EMAIL PROTECTED]> wrote:

> Frank Küster <[EMAIL PROTECTED]> writes:
>
>> Michael Banck <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
 also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
 > * License : GPL v2 or later
 
 That will make it pretty useless for non-GPL applications. 
>>>
>>> Non-GPL compatible applications, you mean?
>>
>> Which non-GPL license can I choose for a software that uses this
>> library? 
>
> Any license that is compatible with the GPL, such as the revised BSD
> license.

But the software is a derivative work of the GPL.  Doesn't it need to be
licensed under the GPL, too?

I  thought the question of GPL compatibility is the other way round: the
BSD license is GPL-compatible because I can use BSD-licensed code in a
GPL project.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Simon Josefsson]

Frank Küster <[EMAIL PROTECTED]> writes:

> Michael Banck <[EMAIL PROTECTED]> wrote:
>
>> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
>>> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
>>> > * License : GPL v2 or later
>>> 
>>> That will make it pretty useless for non-GPL applications. 
>>
>> Non-GPL compatible applications, you mean?
>
> Which non-GPL license can I choose for a software that uses this
> library? 

Any license that is compatible with the GPL, such as the revised BSD
license.

>> Seconds, since when do we consider the GPL to be viral?
>
> Don't know about you, but the FSF does - it has created the LGPL because
> of this.

That doesn't mean libraries shouldn't be licensed under the GPL, see
.

/Simon


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Frank Küster]

Simon Josefsson <[EMAIL PROTECTED]> wrote:

>> That will make it pretty useless for non-GPL applications. 
[...]
> As a derived work of a GPL'd work, the aggregate is covered by the GPL
> license.

So the aggregate, in other words the *application* would be a
GPL-application, right?  Which makes the above sentence correct.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Thiemo Seufer]

Frank Küster wrote:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> 
> > Frank Küster <[EMAIL PROTECTED]> writes:
> >
> >> Michael Banck <[EMAIL PROTECTED]> wrote:
> >>
> >>> On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
>  also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
>  > * License : GPL v2 or later
>  
>  That will make it pretty useless for non-GPL applications. 
> >>>
> >>> Non-GPL compatible applications, you mean?
> >>
> >> Which non-GPL license can I choose for a software that uses this
> >> library? 
> >
> > Any license that is compatible with the GPL, such as the revised BSD
> > license.
> 
> But the software is a derivative work of the GPL.  Doesn't it need to be
> licensed under the GPL, too?

It likely is an aggregation of works. Distributing the whole will
need to adhere to all licenses of all parts involved, and the license
for the aggregate will need to be compatible to them as well (for
example public domain).


IANAL,
Thiemo

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Simon Josefsson]

Frank Küster <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>
>> Frank Küster <[EMAIL PROTECTED]> writes:
>>
>>> Michael Banck <[EMAIL PROTECTED]> wrote:
>>>
 On Thu, May 11, 2006 at 04:46:22PM +0200, martin f krafft wrote:
> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
> > * License : GPL v2 or later
> 
> That will make it pretty useless for non-GPL applications. 

 Non-GPL compatible applications, you mean?
>>>
>>> Which non-GPL license can I choose for a software that uses this
>>> library? 
>>
>> Any license that is compatible with the GPL, such as the revised BSD
>> license.
>
> But the software is a derivative work of the GPL.  Doesn't it need to be
> licensed under the GPL, too?

As a derived work of a GPL'd work, the aggregate is covered by the GPL
license.  But the source code files doesn't have to be licensed under
the GPL.  If someone replace the calls to the GPL'd library in the BSD
code with calls to a BSD library, they don't have to distribute the
new package under the GPL.

/Simon


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

Re: screenshot with package description

[Michelle Konzack]

Sorry for the late answer...

> 3) How would synaptic (for instance) know which packages have which
> images? I suppose you would need a Packages-like file with this
> information... (This will not be incorporated in the main Packages
> file... not before this idea being proved as possible and usefull)...

I am coding since around 4 years a "X-ControllCenter" (without the
need of KDE or GNOME, ist better then Yast2  :-) ) and the integrated
Package installer (using apt-get) use the same directory structure as
the packages but while the packages are using for example

ftp://ftp.debian.org/debian  stable main

this pics are using

ftp://ftp.debian.org/debian-pics stable main

Insteed of the DEB, there is a configfile with all required infos like

1)  Larger description
2)  link to logo
3)  link to screenshoot1 + short description1
link to screenshoot2 + short description2
...

Which mean, no one need to download the whole stuff, only the files
someone is interested.  On the other hand, I have DEB's from each
Debian Package, which can be installed seperatly in /var/lib/apt-pics/
and it create the Directory structure...
Its like
apt-get install -aptpics

And the idea to have 29 TAR-Archives with the PICS of immense size is
not acceptable for me.

Better to create 15.000 additional DEB's with pics and additonal
descriptoons (per screenshoot) and make Meta packages to instal with

apt-get install aptpics-all (for installing the
 whole pics-archive)
or
apt-get install aptpics-x   (for installing per
 LETTER archive)

Think about it...
For this time it is just an idea.

Greetings
Michelle Konzack


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: PDF files and dh_compress

[Lionel Elie Mamane]

On Thu, May 11, 2006 at 02:21:37AM +0200, Juliusz Chroboczek wrote:
>> I am strongly against compressing PDFs

> To add insult to injury, PDF 1.5 introduces ``object streams'' which
> allow compressing arbitrarily long chunks of a PDF file without
> giving up the random-access properties of PDF.  All current Free PDF
> readers grok PDF 1.5, although as far as I know no Free software can
> produce PDF 1.5 object streams.

Usually, when I get problems with xpdf on a PDF, it is a PDF
1.5. Either it simply doesn't work, or very slowly, or text search
doesn't work in the PDF.

-- 
Lionel


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

Re: gcc 4.1 or not

[Gustavo Franco]

On 5/11/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

* Gustavo Franco <[EMAIL PROTECTED]> [2006-05-11 11:20]:
> Why you did this metabug thing, and not just usertagged the bugs ? The
> results seems to be similar, but i don't think that a metabug can be
> managed by email, usertags are.

What can not be managed by email?


The metabug itself, AFAIK just individual bugs can be managed, no?

Thanks,
-- stratus

Re: gcc 4.1 or not

[Martin Michlmayr]

* Gustavo Franco <[EMAIL PROTECTED]> [2006-05-11 14:39]:
> >> Why you did this metabug thing, and not just usertagged the bugs ? The
> >> results seems to be similar, but i don't think that a metabug can be
> >> managed by email, usertags are.
> >What can not be managed by email?
> The metabug itself, AFAIK just individual bugs can be managed, no?

Well, I've no idea what you mean by "manage".  You can add new
blockers to the meta bug and remove them, which is all I want to
do.
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Bug#366859: ITP: libwiki-toolkit-perl -- A toolkit for building Wikis

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libwiki-toolkit-perl
  Version : 0.70
  Upstream Author : The Wiki::Toolkit team <[EMAIL PROTECTED]>
* URL : http://www.wiki-toolkit.org/
* License : Dual GPL/Artistic
  Description : A toolkit for building Wikis

Helps you develop Wikis quickly by taking care of the boring bits for
you.  You will still need to write some code - this isn't an instant
Wiki.

This was previously CGI::Wiki and referred to in wnpp bug #280318.
0.70 hasn't yet been released but will be the next stable release.


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

Bug#366862: ITP: libwiki-toolkit-formatter-usemod-perl -- UseModWiki-style formatting for Wiki::Toolkit

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves <[EMAIL PROTECTED]>

* Package name: libwiki-toolkit-formatter-usemod-perl
  Version : 0.19
  Upstream Author : The Wiki::Toolkit project <[EMAIL PROTECTED]>
* URL : http://www.wiki-toolkit.org/
* License : Dual GPL/Artistic
  Description : UseModWiki-style formatting for Wiki::Toolkit

A formatter backend for CGI::Wiki that supports UseMod-style
formatting.

This used to be CGI::Wiki::Formatter::Usemod which was referred to in
wnpp bug #280952.


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

Re: gcc 4.1 or not

[Gustavo Franco]

On 5/11/06, Martin Michlmayr <[EMAIL PROTECTED]> wrote:

* Gustavo Franco <[EMAIL PROTECTED]> [2006-05-11 14:39]:
> >> Why you did this metabug thing, and not just usertagged the bugs ? The
> >> results seems to be similar, but i don't think that a metabug can be
> >> managed by email, usertags are.
> >What can not be managed by email?
> The metabug itself, AFAIK just individual bugs can be managed, no?

Well, I've no idea what you mean by "manage".  You can add new
blockers to the meta bug and remove them, which is all I want to
do.


by mail, really ? Well, that's weird. Why we've usertags[0] too ?

[0] = http://wiki.debian.org/bugs.debian.org/usertags

thanks,
-- stratus

Processed: closing dead old bugs

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> # This bug is from 2000, and the submitter failed to give the requested
> # followup information.  Furthermore devfs is dead meat.
> close 78282
Bug#78282: DevFS incompatabilities
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Eric Windisch <[EMAIL PROTECTED]>

> # This bug has been unreproducible since Nov. 2000 and was reported against
> # potato
> close 77570
Bug#77570: corrupted /var/lib/dpkg/status file
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Roland Bauerschmidt <[EMAIL 
PROTECTED]>

> # Another bug on upgrade to potato, which means it will *never* be fixed.
> # Hasn't been reproducible in recent years
> close 60573
Bug#60573: upgrade to potato broke permissions on /dev/null and /tmp
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to "der.hans" <[EMAIL PROTECTED]>

> # Per-file md5sums are not mandated by policy and may be undesirable,
> # as per the bug discussion; this bug is invalid.
> close 223772
Bug#223772: general: no md5sums for many packages (e.g. bc)
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to [EMAIL PROTECTED]

> # No information from submitter since request in Sept. 2004
> close 273936
Bug#273936: bug report bad monitor
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to "[EMAIL PROTECTED]" <[EMAIL 
PROTECTED]>

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: gcc 4.1 or not

[Steve Langasek]

On Thu, May 11, 2006 at 02:20:29PM +0200, Martin Michlmayr wrote:
> * Martin Zobel-Helas <[EMAIL PROTECTED]> [2006-05-11 13:38]:
> > I know, tbm tried to build all packages on mips*. It would be intersting
> > to know, how other architectures behave. Also i have not seen any
> > comments from doko yet.

> I built mips and amd64, and in the mean time also powerpc and most of
> sparc.

> Apparently hppa has some problems but I don't know any details:

> 22:10 < vorlon> also, do you know about the hppa ABI skew issues?
> 22:12 < vorlon> libstdc++6 from gcc-4.1 source doesn't work with gcc-4.0 as
> a compiler, because of a libgcc_s soname change

This is a problem, caused by the *introduction* of gcc-4.1 into the archive,
which will be fixed (well, fixable) when gcc-4.1 is the default compiler. 
So this is a reason for getting gcc-4.1 as default, not against it.  (It's
also another pool of porters you can tap to do NMUs for the switch, which is
why I mentioned it to you :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: gcc 4.1 or not

[Steve Langasek]

On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote:
> On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL 
> PROTECTED]> wrote:
> > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:

> > > there were some requests, e.g. by Martin Michlmayr to the release team
> > > whether we could switch gcc to 4.1 or not for etch.  As we're heading to

> > what about the transition to python 2.4? is it going to start or etch
> > is going to ship with 2.3?

> what about the transition to libgnutls13 ? I noticed yesterday when
> debootstraping that we get libgnutls11, 12 AND 13 installed by default.
> Do we really need that many libgnutls ?

I don't see anything at all in the reverse-deps that would explain
libgnutls11 being pulled in by debootstrap.  Is it still hard-coded in a
package list somewhere in the version of debootstrap you're using?

Anyway, it would be nice to get libgnutls11 out of etch completely, but
AFAICT it should at least have been removed from the list of base libs
already.  If you wanted to file bugs and NMU (*not* 0-day NMUs) to take it
the rest of the way, that'd be great. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Re: multiarch status update

[neroden]

>I have created a new page in the wiki to track info and status
>
>  http://wiki.debian.org/multiarch

I looked at the "upstream standards proposal":
http://lackof.org/taggart/hacking/multiarch/

It's good.
I am particularly pleased by the specification:

"The terms arch and os represent the Architecture and Operating System 
as defined and provided by config.guess."

It is crucial that this naming be entirely standardized.  This *should*
be sufficient.  Is it sufficient?  Cases where it would not be sufficient
would be the following:

(1) Cases where config.guess reports the same name for functionally different
systems, such as the two MIPS ABIs.  This should be considered a bug in
config.guess, plain and simple.

(2) Cases where config.guess gives noncanonical results.  This should not
happen, and if it does it's a bug in config.guess.

(3) Cases where the *manufacturer name* is the sole discriminator between
two functionally different systems.  While this *is* the case for some legacy
UNIX systems, I believe it is not the case for any system which might consider
using the FHS or multiarch, or indeed for any common system, so this is
probably not important.  However, it could be avoided by simply using the
full canonical system name.  However, there are arguments against that,
notably the use of the 'manufacturer' slot in unreliable and inconsistent ways
by Linux distribution vendors, despite no real platform difference.

(4) There is an ambiguity in the specification.  config.sub notes:
# The goal of this file is to map all the various variations of a given
# machine specification into a single specification in the form:
#   CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
# or in some cases, the newer four-part form:
#   CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM

I believe that when it is the output of config.guess, the 
KERNEL-OPERATING_SYSTEM should be considered the $os portion in a 
multiarch implementation.  This will be necessary to discriminate 
between different systems.  This would be the natural result of the 
naive implementation (which doesn't consider the existence of four-part
canonical system names) anyway.

(5) config.guess has been known to vary its output from system to system
when perhaps it shouldn't. :-)  It will be necessary to standardize the
canonical system names for multiarch in this case: it is crucial that we not
have (for instance) i486-linux and i486-linux-gnu directories floating around
separately.  Accordingly, I suggest that the upstream proposals should
*specify* the expected $arch-$os results from config.guess for the common,
existing platforms.

-
There is yet another issue with the $arch portion of the canonical system
name: chips which are upgrades of other chips.  For instance, Fedora will
give you 'i686', while Debian will give you 'i486'.  This will (and should)
result in two different directories -- different multiarch variants.
However, programs compiled for i486 will run on i686.

This raises fairly complex program interpreter issues for the simplest case
(intercompatibility between Debian and RedHat on x86).
Software must expect to be able to install to the i486-linux-gnu directories
and function immediately, even on a "natively" i686-linux-gnu system.
Likewise software should be able to install to the i686-linux-gnu directories
and function immediately if the chip is actually an i686, even on an
i486-linux-gnu system.

Now, this is in fact trivial with the current non-multiarch situation.  We
must be careful not to break it with multiarch!  Perhaps an "x86 annexe" to
the specifications would help?

I *believe* that this can be handled as follows:
(1) Specify a list of arch-os pairs which are ABI-compatible
(i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps)
(2) Rework the program interpreter to search through all three arch-os pairs,
starting with the "highest" one which the actual chip supports.

However, this all seems to duplicate the existing functionality with 
/usr/lib/tls/{i486, i586, i686}.  But perhaps it should be considered
to be replacing that functionality?  That seems like a wise way to go,
actually.

If not, it may be simpler to just specify outright that all x86 machines 
should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what 
config.guess thinks, and that libraries compiled for the higher chips 
should use the subdirectories.

Please consider the x86 intercompatibility case before making any final
proposals.  It's very important.  :-)

--Nathanael Nerode


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

Re: python version?

[Don Armstrong]

On Thu, 11 May 2006, Andreas Barth wrote:
> * Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]:
> > > Andreas Barth <[EMAIL PROTECTED]> writes:
> > 
> > >> An upload of python-defaults switching to 2.4 has been repeatedly asked
> > >> during the last months, and it was ignored by the maintainer. I'm not
> > >> aware of anything preventing this upload currently.
> > 
> > > The maintainer is not ignoring it, but the transition needs to have some
> > > issues fixed first. (And if you want to discuss aboutt hat, please leave
> > > -release out of the discussion. :)
> > 
> > The last time this came up in, the majority view was to transition to 2.4 as
> > default the "old way" rather than keeping it pending for so long. 
> 
> I'm not really aware of the python issues. Are there enough python
> people on Debconf to make an ad-hoc BoF about python?

There are slots available for this; if someone wants to organize this,
let me know, and I'll give you a slot.


Don Armstrong

-- 
You could say she lived on the edge... Well, maybe not exactly on the edge,
just close enough to watch other people fall off.
  -- hugh macleod http://www.gapingvoid.com/batch8.htm

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


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[martin f krafft]

also sprach Michael Banck <[EMAIL PROTECTED]> [2006.05.11.1702 +0200]:
> > That will make it pretty useless for non-GPL applications. 
> 
> Non-GPL compatible applications, you mean?

Yeah well. IMHO that pretty much excludes all sensible licences.

> > Why don't you choose (if possible) a less "viral" licence?
> 
> Wow.  First off, Kari does not appear to be upstream, so who are
> you addressing?

Him. I think he's in the better position to talk to upstream about
it. Or in fact not make the package.

> Seconds, since when do we consider the GPL to be viral?

I have always done so and never used the GPL for any of my work.

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
unix, because rebooting is for adding new hardware.


signature.asc
Description: Digital signature (GPG/PGP)

Re: gcc 4.1 or not

[Martin Michlmayr]

* Gustavo Franco <[EMAIL PROTECTED]> [2006-05-11 15:05]:
> >Well, I've no idea what you mean by "manage".  You can add new
> >blockers to the meta bug and remove them, which is all I want to
> >do.
> by mail, really ?

Yeah, "block xx by foo".
-- 
Martin Michlmayr
http://www.cyrius.com/


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

Re: Intent to hijack Bacula

[Roberto Lumbreras]

On Thu, May 11, 2006 at 08:37:35AM -0400, Stephen Frost wrote:
: * Roberto Lumbreras ([EMAIL PROTECTED]) wrote:
: > Speaking about your mail, I think it's your opinion, mine is different.
: 
: Sure, but you're looking through some very rosy glasses.

hey, I've tried to be fair...

: > Jose Luis doesn't want just his name in some place, he has worked a lot
: > in bacula in the past, and I don't know why he can't remain as
: > maintainer or co-maitainer if he is going to work on it again.
: 
: You don't get to rest on your laurels in Debian.  Especially when it's
: been over a year.

don't be so rude with Jose Luis, and it's not him the only person to
blame, he is not the only person who can do an upload of a package (in
fact, he can't)

: > Obviuosly if he is unable to maitain it or work on it, it should orphan
: > the package, but it seems that things are different.
: 
: That would be exactly the problem- he wants to remain as maintainer or
: co-maintainer yet has shown nothing to indicate that he's going to work
: on it again.  Not only that but he's trying to refuse work done by others 
: (John) which is clearly in the best interest of Debian and its users
: (like, I dunno, getting bacula into a state where it can get back into
: testing...).

He has packaged the last version of bacula, and it is not uploaded
because it's not ready, then a new version was showed up... he has a
personal apt repository that users from bacula mailing list uses, and
packages (not yet finished) in sourceforge... so is it clear for you
that he is not going to work on it again? not for me, I think he was
working, then the John started to do NMUs, and refusing to be
co-maintainer with Jose Luis. After John has refused to do that, then
Jose Luis has done the same. I think it's a kids game :-(

: Besides, Jose Luis will still be able to help with bacula, if he really
: wants to, by doing bug triage, submitting patches, etc.  I fully agree
: with John's statement though- based on the state which bacula was in and
: the things which were done in it that were *clearly* policy violations,
: Jose Luis' contributions need to be checked before being committed.
: 
: This is something that anyone sponsoring anyone's packages *should* have
: been doing already.  Unfortunately, that part seems to have been
: forgotten by some.

Hey, again, don't be so rude... some of those serious policy violations
are things like mistakes erasing logfiles and editing conffiles that
couldn't be done in another way. I don't even remember if it was me who
uploaded that version of bacula doing so evil things... but if it was me
a year ago, it was because another version was supposed to come soon
fixing that and then it didn't happen. And I've worked tons of hours
even days reviewing Jose Luis packages, maybe I'm not god but please
don't say things so easily.

:   Enjoy,
: 
:   Stephen

Salud,
-- 
Roberto Lumbreras   .''`.

Debian Developer   `. `' 
 `-  


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

Re: multiarch status update

[Henrique de Moraes Holschuh]

On Thu, 11 May 2006, [EMAIL PROTECTED] wrote:
> "The terms arch and os represent the Architecture and Operating System 
> as defined and provided by config.guess."

Well, config.sub is the one whose function is to provide canonical
names, config.guess might not do so for one reason or another (but it
usually does provide canonical names, at least when it can).

I'd say "config.sub $(config.guess)"  is better than just config.guess.

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


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

Re: Intent to hijack Bacula

[David Nusinow]

On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote:
> He has packaged the last version of bacula, and it is not uploaded
> because it's not ready, then a new version was showed up... he has a
> personal apt repository that users from bacula mailing list uses, and
> packages (not yet finished) in sourceforge... so is it clear for you
> that he is not going to work on it again? not for me, I think he was
> working, then the John started to do NMUs, and refusing to be
> co-maintainer with Jose Luis. After John has refused to do that, then
> Jose Luis has done the same. I think it's a kids game :-(

John has managed to not only update to the latest upstream version in his
upload, but he's also managed to fix 24 bugs by my count. It is notable
that he has managed to achieve so much while Jose struggled just to update
to the new version.

Since John has said he's open to having an alioth group maintain bacula,
with Jose on the team, I hope Jose chooses to actively work with everyone
to get the help, and apparently training, that he needs to manage something
this complicated. I got tons of help from people both in and out of Debian
while working on Xorg, and I still get it almost daily. There's no shame in
doing so, and Jose should take advantage of it to become a stronger
maintainer.

 - David Nusinow


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

Re: gcc 4.1 or not

[Mike Hommey]

On Thu, May 11, 2006 at 11:34:50AM -0700, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote:
> > On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL 
> > PROTECTED]> wrote:
> > > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> 
> > > > there were some requests, e.g. by Martin Michlmayr to the release team
> > > > whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> 
> > > what about the transition to python 2.4? is it going to start or etch
> > > is going to ship with 2.3?
> 
> > what about the transition to libgnutls13 ? I noticed yesterday when
> > debootstraping that we get libgnutls11, 12 AND 13 installed by default.
> > Do we really need that many libgnutls ?
> 
> I don't see anything at all in the reverse-deps that would explain
> libgnutls11 being pulled in by debootstrap.  Is it still hard-coded in a
> package list somewhere in the version of debootstrap you're using?

# grep-available -s Package -s Priority -P libgnutls
(...)
Package: libgnutls12
Priority: standard

Package: libgnutls13
Priority: important

Package: libgnutls11
Priority: important

> Anyway, it would be nice to get libgnutls11 out of etch completely, but
> AFAICT it should at least have been removed from the list of base libs
> already.  If you wanted to file bugs and NMU (*not* 0-day NMUs) to take it
> the rest of the way, that'd be great. :)

I promise I'll deal with that as soon as I'll have time.

Mike


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

Re: gcc 4.1 or not

[Steve Langasek]

On Thu, May 11, 2006 at 09:56:04PM +0200, Mike Hommey wrote:
> On Thu, May 11, 2006 at 11:34:50AM -0700, Steve Langasek <[EMAIL PROTECTED]> 
> wrote:
> > On Thu, May 11, 2006 at 10:59:27AM +0200, Mike Hommey wrote:
> > > On Thu, May 11, 2006 at 10:09:11AM +0200, Domenico Andreoli <[EMAIL 
> > > PROTECTED]> wrote:
> > > > On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:

> > > > > there were some requests, e.g. by Martin Michlmayr to the release team
> > > > > whether we could switch gcc to 4.1 or not for etch.  As we're heading 
> > > > > to

> > > > what about the transition to python 2.4? is it going to start or etch
> > > > is going to ship with 2.3?

> > > what about the transition to libgnutls13 ? I noticed yesterday when
> > > debootstraping that we get libgnutls11, 12 AND 13 installed by default.
> > > Do we really need that many libgnutls ?

> > I don't see anything at all in the reverse-deps that would explain
> > libgnutls11 being pulled in by debootstrap.  Is it still hard-coded in a
> > package list somewhere in the version of debootstrap you're using?

> # grep-available -s Package -s Priority -P libgnutls
> (...)
> Package: libgnutls12
> Priority: standard
> 
> Package: libgnutls13
> Priority: important
> 
> Package: libgnutls11
> Priority: important

Cool, even better: fixable just by filing a bug on ftp.d.o asking for the
priority to be dropped.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


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

Why isn't gnome in testing?

[Julian Gilbey]

Does anyone know why the binary package gnome is no longer in testing?
The source package meta-gnome2 is there

   Julian


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

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[Josselin Mouette]

Le jeudi 11 mai 2006 à 16:46 +0200, martin f krafft a écrit :
> also sprach Kari Pahula <[EMAIL PROTECTED]> [2006.05.11.1535 +0200]:
> > * License : GPL v2 or later
> 
> That will make it pretty useless for non-GPL applications. Why don't
> you choose (if possible) a less "viral" licence?

I think this is the whole point of licensing a library under the GPL.
There's not much point in using a copyleft if you allow proprietary
applications to use the library.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Why isn't gnome in testing?

[Andreas Barth]

* Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]:
> Does anyone know why the binary package gnome is no longer in testing?
> The source package meta-gnome2 is there

Seems like an accident currently. We're researching the matter.

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Bug#366879: ITP: libodbc++ -- C++ library for ODBC SQL database access

[Ondřej SurÃœ]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý" <[EMAIL PROTECTED]>

* Package name: libodbc++
  Version : 0.2.4pre3
  Upstream Author : Manush Dodunekov <[EMAIL PROTECTED]>
* URL : http://libodbcxx.sourceforge.net
* License : LGPL
  Programming Lang: C++
  Description : C++ library for ODBC SQL database access

Source: libodbc++
Priority: optional
Maintainer: Ondřej Surý <[EMAIL PROTECTED]>
Build-Depends: debhelper (>= 4.0.0), autotools-dev, cdbs, libiodbc2-dev,
doxygen
Standards-Version: 3.6.2
Section: libs

Package: libodbc++-dev
Section: libdevel
Architecture: any
Depends: libodbc++4 (= ${Source-Version})
Description: C++ library for ODBC SQL database access
 libodbc++ is a C++ class library for accessing SQL databases.
 It is designed with standards in mind, so it provides a subset
 of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
 and Unix/Linux.
 .
 This package contains the header files and static libraries which is
 needed for development.

Package: libodbc++4
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: C++ library for ODBC SQL database access
 libodbc++ is a C++ class library for accessing SQL databases.
 It is designed with standards in mind, so it provides a subset
 of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
 and Unix/Linux.
 .
 This package contains the shared libraries.

Package: libodbc++-doc
Architecture: all
Section: doc
Description: C++ library for ODBC SQL database access
 libodbc++ is a C++ class library for accessing SQL databases.
 It is designed with standards in mind, so it provides a subset
 of the well-known JDBC 2.0(tm) and runs on top of ODBC on Windows
 and Unix/Linux.
 .
 This package contains documentation files for the ODBC++ library
functions.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-22-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)

Re: multiarch status update

[Joe Smith]

"Matt Taggart and others" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi debian-devel,

For a couple years now a few of us have been talking about an idea called
"multiarch". This is a way to seamlessly allow support for multiple 
different
binary targets on the same system, for example running both i386-linux-gnu 
and
amd64-linux-gnu binaries on the same system (many other working 
combinations
exist as well). I have created a new page in the wiki to track info and 
status


My thoughts on a few multi-arch concepts.

It is important to differentiate between the types of non-native files.

There are files that are not native, but are intended to be used by native
programs targeting the non-native arch. These include things like 
arch-specific header files.
It almost seems like these should be put in /usr/share/include/$arch-$os/. 
(where $arch and $os represent the target arch) That is because headers for 
cross compiling are normally dependent on the target arch, but not the host 
arch.


On the other hand, if we continue that thought process we could end up with 
all headers and libraries in /usr/share/, which is absurd.


Indeed, the current proposal almost seems to be reversing this.
Non-target specific libraries and header files remain in $prefix/lib and 
$prefix/include.
It seems to me that libraries and headers that are not target specific are 
supposed to go in /usr/share.
That is because if they are not target specific they are most certainly 
cross-platform.


Hm... This entire concept seems messy. It seems that processors that support 
multiple architectures,
as well as cross compilition are begining to blur the line between /usr and 
/usr/share.





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

Re: multiarch status update

[Thiemo Seufer]

[EMAIL PROTECTED] wrote:
> >I have created a new page in the wiki to track info and status
> >
> >  http://wiki.debian.org/multiarch
> 
> I looked at the "upstream standards proposal":
> http://lackof.org/taggart/hacking/multiarch/
> 
> It's good.
> I am particularly pleased by the specification:
> 
> "The terms arch and os represent the Architecture and Operating System 
> as defined and provided by config.guess."
> 
> It is crucial that this naming be entirely standardized.  This *should*
> be sufficient.  Is it sufficient?  Cases where it would not be sufficient
> would be the following:
> 
> (1) Cases where config.guess reports the same name for functionally different
> systems, such as the two MIPS ABIs.  This should be considered a bug in
> config.guess, plain and simple.

To expand a bit on this, I don't think config.guess is sufficient to
handle those cases. E.g. for a MIPS system with 64bit kernel,
config.guess will return

mips64el-unknown-linux-gnu

even when there's only a (little endian) O32 userland installed, but
for a 32bit kernel it will be

mipsel-unknown-linux-gnu

unless the call is prefixed with linux32, which changes the uname,
and thus the config.guess output.

The endianness is guessed from the defaults of the system compiler
(the first cc in $PATH), which is
a) not necessarily available, and
b) supposed to be exchangable in a full multiarch environment.

What's worse, "mips64" is a rather entrenched term with inconsistent
meanings which cover both the N32 and N64 ABI. A "fix" to config.guess
would AFAICS require to specify a multiarch mode, which changes the
output to, say, mipsn32el-unknown-linux-gnu for N32 and to
mipsn64-unknown-linux-gnu for N64 (that still doesn't answer the
question which ABI would be the "native" one). But in that case the
config.guess can't be the canonical source of information any more.

This is not only MIPS-specific, a similiar problem arises e.g. for a
ILP32 ABI for x86_64.

I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which
provides mappings for multiarch-sensitive programs.


Thiemo


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

Re: screenshot with package description

[Andrew Donnellan]

On 5/10/06, Michelle Konzack <[EMAIL PROTECTED]> wrote:

Better to create 15.000 additional DEB's with pics and additonal
descriptoons (per screenshoot) and make Meta packages to instal with

apt-get install aptpics-all (for installing the
 whole pics-archive)
or
apt-get install aptpics-x   (for installing per
 LETTER archive)


OUCH! This would mean that all of a sudden the 20-30 seconds it takes
while 'Reading database...' would suddenly become 45-60 seconds.

The TAR archives are a much better idea IMHO.

--
Andrew Donnellan
http://andrewdonnellan.com
http://ajdlinux.blogspot.com
Jabber - [EMAIL PROTECTED]
---
Member of Linux Australia - http://linux.org.au
Debian user - http://debian.org
Get free rewards - http://ezyrewards.com/?id=23484
OpenNIC user - http://www.opennic.unrated.net

Re: Intent to hijack Bacula

[José Luis Tallón]

David Nusinow wrote:
> On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote:
>   
>> He has packaged the last version of bacula, and it is not uploaded
>> because it's not ready, then a new version was showed up... he has a
>> personal apt repository that users from bacula mailing list uses, and
>> packages (not yet finished) in sourceforge... so is it clear for you
>> that he is not going to work on it again? not for me, I think he was
>> working, then the John started to do NMUs, and refusing to be
>> co-maintainer with Jose Luis. After John has refused to do that, then
>> Jose Luis has done the same. I think it's a kids game :-(
>> 
>
> John has managed to not only update to the latest upstream version in his
> upload, but he's also managed to fix 24 bugs by my count. It is notable
> that he has managed to achieve so much while Jose struggled just to update
> to the new version.
>   
I have been away from home for 20 months; During the latest 3 I have had
random hardware errors which I couldn't fix.

I have myself fixed in excess of 40 bugs in my packages in the last 48h,
when I have been back to speed.
So what???
> Since John has said he's open to having an alioth group maintain bacula,
> with Jose on the team,
Hmm.. he chose to hijack my package instead.
That is *not* collaborative maintenance.
> I hope Jose chooses to actively work with everyone to get the help, and 
> apparently training, that he needs to manage something
> this complicated. 
Sorry, but I fail to see how well you know my work for Debian (three
years so far) in order to be able to judge me.
Please check your facts before joining a thread this harsh.
> I got tons of help from people both in and out of Debian
> while working on Xorg, and I still get it almost daily. There's no shame in
> doing so, and Jose should take advantage of it to become a stronger
> maintainer.
>   
Correct. That's why I appreciate patches (and even NMUs). This is
completely different.

Hijacking a package without contacting the maintainer first is against
the Developers' Reference and can only be considered a personal attack.


I still don't know what is John Goerzen trying to achieve with this.
More on this later.


J.L.


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

Re: multiarch status update

[Daniel Ruoso]

Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:
> On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
> > Why would that not fly?
> > Both versions of the arch-independent package could be installed at
> > the same time.
> /usr/share/foo/bar can't point to two different files at the same time,
> so you can't install multiple package versions containing
> incompatible /usr/share/foo/bar files.
> The only way to support your proposal would be to kill the concept of
> arch-independent packages and make everything arch-dependent.

And what if dpkg knows about it and handle arch-independant packages in
a different way?

In fact, if the system is multiarch, dpkg should have a centralized list
of which packages are installed for each architecture and which packages
are installed for arch: all...

But there's still the problem of arch-independant files inside
arch-dependant files (maybe an arch-dependant package should not include
arch-indenpendant files at all)...

daniel


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

Re: Intent to hijack Bacula

[Ondrej Sury]

On Thu, 2006-05-11 at 23:07 +0200, José Luis Tallón wrote:
> > John has managed to not only update to the latest upstream version in his
> > upload, but he's also managed to fix 24 bugs by my count. It is notable
> > that he has managed to achieve so much while Jose struggled just to update
> > to the new version.
> >   
> I have been away from home for 20 months; During the latest 3 I have had
> random hardware errors which I couldn't fix.

Stick to the facts.  Bacula was broken, was removed from testing and not
updated for very long time.  You were not able to do anything with it to
get it to better shape.  Sorry, but fact that you have been away from
home and you have had broken hardware doesn't help our users. If you
were not able to fullfill your maintainership duties for 20 months (or
so), you should have stepped down much earlier and ask for help.  And
you started to work on bacula again only after John announced
hijack...well, I don't believe in coincidences.

Cool down please and come back only after you realize that our users are
priority.

Ondrej.
-- 
Ondrej Sury <[EMAIL PROTECTED]>


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

Re: Intent to hijack Bacula

[Thomas Bushnell BSG]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> writes:

> Roberto Lumbreras <[EMAIL PROTECTED]> writes:
> [...]
>> Ok, the maintainer has not fixed the bugs, has not packaged the last
>> version of it in time, etc, but he has done a great job anyway, and I
>> still don't see the point of hijacking the package.
>
> So he has done not one of the things expected of a good package
> maintainer. *What* of that is a "great job"?

Brownie, you're doing a great job!


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

Re: gcc 4.1 or not

[Thomas Bushnell BSG]

Domenico Andreoli <[EMAIL PROTECTED]> writes:

> On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
>> Hi,
>
> hi,
>
>> there were some requests, e.g. by Martin Michlmayr to the release team
>> whether we could switch gcc to 4.1 or not for etch.  As we're heading to
>
> what about the transition to python 2.4? is it going to start or etch
> is going to ship with 2.3?

Yeah, what about it?

There is an open bug, it's blocking lilypond which should have an
updated version in etch, and the python team has been discussing it
apparently but there is a deafening silence about telling me what the
plan is.


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

python 2.4?

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]:
> Domenico Andreoli <[EMAIL PROTECTED]> writes:
> > what about the transition to python 2.4? is it going to start or etch
> > is going to ship with 2.3?
> 
> Yeah, what about it?
> 
> There is an open bug, it's blocking lilypond which should have an
> updated version in etch, and the python team has been discussing it
> apparently but there is a deafening silence about telling me what the
> plan is.

Ok, I'll make sure there is some information latest for the next relese
update, which is due in May.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: python version?

[Thomas Bushnell BSG]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Josselin Mouette ([EMAIL PROTECTED]) [060511 10:48]:
>> Le jeudi 11 mai 2006 à 10:09 +0200, Domenico Andreoli a écrit :
>> > what about the transition to python 2.4? is it going to start or etch
>> > is going to ship with 2.3?
>> 
>> An upload of python-defaults switching to 2.4 has been repeatedly asked
>> during the last months, and it was ignored by the maintainer. I'm not
>> aware of anything preventing this upload currently.
>
> The maintainer is not ignoring it, but the transition needs to have some
> issues fixed first. (And if you want to discuss aboutt hat, please leave
> -release out of the discussion. :)

How nice it would be to have the maintainer say this when people ask
"what's the status, please?"

So, what are the issues that need to be fixed?  Currently #360851
doesn't say it's blocked by anything, and two packages are blocked
waiting for it.

Thomas

Re: Bug#366834: ITP: cxxtools -- library of unrelated, but useful C++ classes

[martin f krafft]

also sprach Josselin Mouette <[EMAIL PROTECTED]> [2006.05.11.2219 +0200]:
> I think this is the whole point of licensing a library under the GPL.

For me the point of a library is code reuse. Putting a library under
the GPL is more of a political statement.

> There's not much point in using a copyleft if you allow
> proprietary applications to use the library.

I still see a difference between cut-n-paste and link-to-library
code reuse.

From what I understand, if your product links to a GPL library, you
have to make it GPL as well. We analysed the situation back when we
wanted to make libhid Artistic and concluded that we cannnot do that
because it links against hidparser, which is GPL'd. If our analysis
was wrong, all the better...

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`. martin f. krafft <[EMAIL PROTECTED]>
: :'  :proud Debian developer and author: http://debiansystem.info
`. `'`
  `-  Debian - when you have better things to do than fixing a system
 
stupidity management for the superuser
is a user space issue in unix systems.
   -- alan cox


signature.asc
Description: Digital signature (GPG/PGP)

Re: python 2.4?

[Thomas Bushnell BSG]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]:
>> Domenico Andreoli <[EMAIL PROTECTED]> writes:
>> > what about the transition to python 2.4? is it going to start or etch
>> > is going to ship with 2.3?
>> 
>> Yeah, what about it?
>> 
>> There is an open bug, it's blocking lilypond which should have an
>> updated version in etch, and the python team has been discussing it
>> apparently but there is a deafening silence about telling me what the
>> plan is.
>
> Ok, I'll make sure there is some information latest for the next relese
> update, which is due in May.

How about, right now, just a statement "this is what the issues are".
Or even, "this [URL here] is the mailing list post where the issues
are outlined."

Thomas


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

Re: python version?

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:56]:
> So, what are the issues that need to be fixed?  Currently #360851
> doesn't say it's blocked by anything, and two packages are blocked
> waiting for it.

As said, I put it on my "need to work on"-list, and you'll get results
in May (and hopefully already after the python BoF on debconf).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: python 2.4?

[Andreas Barth]

* Thomas Bushnell BSG ([EMAIL PROTECTED]) [060512 00:00]:
> Andreas Barth <[EMAIL PROTECTED]> writes:
> 
> > * Thomas Bushnell BSG ([EMAIL PROTECTED]) [060511 23:54]:
> >> Domenico Andreoli <[EMAIL PROTECTED]> writes:
> >> > what about the transition to python 2.4? is it going to start or etch
> >> > is going to ship with 2.3?
> >> 
> >> Yeah, what about it?
> >> 
> >> There is an open bug, it's blocking lilypond which should have an
> >> updated version in etch, and the python team has been discussing it
> >> apparently but there is a deafening silence about telling me what the
> >> plan is.
> >
> > Ok, I'll make sure there is some information latest for the next relese
> > update, which is due in May.
> 
> How about, right now, just a statement "this is what the issues are".
> Or even, "this [URL here] is the mailing list post where the issues
> are outlined."

I forgot about them. So, I need to collect them again. Even release
managers don't have a superhuman brain (though we sometimes pretend we
do :).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: python version?

[Andreas Barth]

* Don Armstrong ([EMAIL PROTECTED]) [060511 20:21]:
> On Thu, 11 May 2006, Andreas Barth wrote:
> > * Ganesan Rajagopal ([EMAIL PROTECTED]) [060511 14:12]:
> > > > Andreas Barth <[EMAIL PROTECTED]> writes:
> > > 
> > > >> An upload of python-defaults switching to 2.4 has been repeatedly asked
> > > >> during the last months, and it was ignored by the maintainer. I'm not
> > > >> aware of anything preventing this upload currently.
> > > 
> > > > The maintainer is not ignoring it, but the transition needs to have some
> > > > issues fixed first. (And if you want to discuss aboutt hat, please leave
> > > > -release out of the discussion. :)
> > > 
> > > The last time this came up in, the majority view was to transition to 2.4 
> > > as
> > > default the "old way" rather than keeping it pending for so long. 
> > 
> > I'm not really aware of the python issues. Are there enough python
> > people on Debconf to make an ad-hoc BoF about python?
> 
> There are slots available for this; if someone wants to organize this,
> let me know, and I'll give you a slot.

I'd like to organize this, but it depends a bit on the python people -
there is no sense organizing it w/o them. :)

Well, perhaps give me a slot now, and we could still cancel it.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: Intent to hijack Bacula

[John Goerzen]

On Thu, May 11, 2006 at 11:07:55PM +0200, José Luis Tallón wrote:

[ snip ]

> I have myself fixed in excess of 40 bugs in my packages in the last 48h,
> when I have been back to speed.
> So what???

I had already checked the packages you posted on sf.net and have not been able
to find bug fixes anywhere near that number.  In fact, most of the bugs
you listed as fixed were ones that my NMUs fixed.

> > I hope Jose chooses to actively work with everyone to get the help, and 
> > apparently training, that he needs to manage something
> > this complicated. 
> Sorry, but I fail to see how well you know my work for Debian (three
> years so far) in order to be able to judge me.

Your packages speak for themselves.

> Correct. That's why I appreciate patches (and even NMUs). This is
> completely different.
> 
> Hijacking a package without contacting the maintainer first is against
> the Developers' Reference and can only be considered a personal attack.

I did not do that.

 * On March 13, I submitted #356755 asking for a new version.  You said
   you had it "packaged already".

 * On April 27, I offered to adopt it for you.  I received no reply
   prior to posting my message on debian-devel.

I can provide logs and message copies if you need them.

> I still don't know what is John Goerzen trying to achieve with this.

Working Bacula packages in Debian.  Period.

> More on this later.

I'm sure thousands of Debian developers around the world are waiting
with eager anticipation for your latest theories on why I am fixing
Bacula.

-- John

Bug#366893: init.d stopping messages not standardized or even always logged

[Dan Jacobson]

Package: general
Severity: wishlist

Looking at the myriad ways of starting messages in /var/log/boot,
Starting X TrueType font server: xfstt.
Starting /usr/sbin/chronyd...
Starting anac(h)ronistic cron: anacron.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler
(especially that last mystery program one), got me looking at
start/stop messages.  Stop messages for example:

We see poor convergence of start messages in /etc/init.d:
$ cd /etc/init.d/
$ grep -i stopping *
acpid:  echo -n "Stopping Advanced Configuration and Power Interface daemon: "
apache2:log_begin_msg "Stopping apache 2.0 web server..."
atd:log_daemon_msg "Stopping deferred execution scheduler" "atd"
bind:   echo -n "Stopping domain name service: named"
bootlogd:   log_daemon_msg "Stopping $DESC" "$NAME"
cpufreqd:   log_daemon_msg "Stopping $DESC" "$NAME"
cron:stop)  log_begin_msg "Stopping periodic command scheduler..."
cupsys: echo -n "Stopping $DESC: $NAME"
cwdaemon:echo -n "Stopping $DESC: $NAME"
dbus-1:  echo -n "Stopping $DESC: "
etc.

Also even
$ grep --files-without-match -i stopping [a-z]*|wc -l
66

Despite policy:
  When you stop or restart a daemon, you should issue a message
  identical to the startup message, except that `Starting' is
  replaced with `Stopping' or `Restarting' respectively.

However, even policy's
$ zgrep -i stopping policy.txt.gz
  echo -n "Stopping domain name service: named"
isn't as systematic as
  echo -n "Stopping $DESC: $NAME"
Therefore, policy should provide a better role model.

However, I also notice that although there is a bootlogger to log all
those starting messages, upon shutdown syslog or whatever is shutdown
too early in the order of shutting things down, so that many of those
"stopping" messages, or errors upon stopping, aren't logged at all!


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

Re: Why isn't gnome in testing?

[Julian Gilbey]

On Thu, May 11, 2006 at 10:32:36PM +0200, Andreas Barth wrote:
> * Julian Gilbey ([EMAIL PROTECTED]) [060511 22:17]:
> > Does anyone know why the binary package gnome is no longer in testing?
> > The source package meta-gnome2 is there
> 
> Seems like an accident currently. We're researching the matter.
> 
> Cheers,
> Andi

Cheers!

   Julian


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

Re: Intent to hijack Bacula

[Steve Langasek]

On Thu, May 11, 2006 at 09:30:40PM +0200, Roberto Lumbreras wrote:
> On Thu, May 11, 2006 at 08:37:35AM -0400, Stephen Frost wrote:

> : > Jose Luis doesn't want just his name in some place, he has worked a lot
> : > in bacula in the past, and I don't know why he can't remain as
> : > maintainer or co-maitainer if he is going to work on it again.

> : You don't get to rest on your laurels in Debian.  Especially when it's
> : been over a year.

> don't be so rude with Jose Luis, and it's not him the only person to
> blame, he is not the only person who can do an upload of a package (in
> fact, he can't)

It is the responsibility of a package maintainer to ensure that fixes for
bugs are uploaded in a timely manner.  If José Luis isn't able to do this,
because he doesn't have a sponsor or for any other reason, then he is not an
effective maintainer for the package.

Actually, we've heard in this thread that Stephen (his AM) *did* offer to
sponsor bacula uploads, and José Luis did not avail himself of this.  So
it's not at all clear to me why you think anyone other than José Luis should
bear the responsibility of this package not being fixed.

> He has packaged the last version of bacula, and it is not uploaded
> because it's not ready, then a new version was showed up... he has a
> personal apt repository that users from bacula mailing list uses, and
> packages (not yet finished) in sourceforge... so is it clear for you
> that he is not going to work on it again?

IME, making plans in Debian based on whether someone else has *promised* to
do something does not give very good results.  The bacula packages have been
removed from testing *repeatedly* over the past year due to one RC bug or
another being reported against it; and it seems that the only real movement
towards getting them fixed has only come in response to John's takeover
attempt.  I can't say that I fault John for wishing to take over this
package and fix it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#366780: ITP: summain -- compute and verify file checksums

[Lars Wirzenius]

to, 2006-05-11 kello 07:13 -0700, Ben Pfaff kirjoitti:
> It's not clear to me, from the description, what the program does
> that the md5sum and sha1sum utilities do not.

It handles .dsc, .changes, and Sources files. But I also forgot to
mention the main reason I wrote it: it gives progress feedback and has
some convenience features.

An updated suggestion for a long description, which also incorporates
Thijs's suggestion to reorder paragraphs:

 summain computes and checks files against such checksums. It supports
 both MD5 and SHA-1 checksums, using formats compatible with the md5sum
 and sha1sum utilities, both for reading and writing. In addition, it
 can read and verify checksums from Debian .dsc, .changes, and Sources
 files.
 .
 Apart from supporting more file formats, summain differs from the
 traditional md5sum and sha1sum utilities by providing progress
 reporting, and via convenience features such as automatic recursion
 into directories, and looking up files relative to the location of the
 checksum file, rather than the current working directory.
 .
 A checksum is a number that identifies the contents of a file: if the
 contents change, so does the checksum. If you create a checksum before
 you burn a CD, when you know the files are correct, you can easily
 check the CD at any time: just compute the checksum again and see if
 they have changed.

I hope this is better.

-- 
RFC 1437 - yet another MIME specification Microsoft ignores


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

Re: Debian Light Desktop - meta package

[Eugen Paiuc]

Hi,

I'd add localepurge - witch save my >25 % disk space on 6-700 mb 
installation.


Thanks!

Eugen Paiuc



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

Re: multiarch status update

[Adam Borowski]

On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
> On the other hand, if we continue that thought process we could end up
> with all headers and libraries in /usr/share/, which is absurd.

Why?  This is exactly what's beautiful, especially if EVERYTHING ends up in
/usr/share/ at one day, at which point /share/ will be redundant and the FHS
will change.

> Indeed, the current proposal almost seems to be reversing this.
> >Non-target specific libraries and header files remain in $prefix/lib and 
> >$prefix/include.
> It seems to me that libraries and headers that are not target specific are 
> supposed to go in /usr/share.
> That is because if they are not target specific they are most certainly 
> cross-platform.

I remember a lab that consisted mostly of SGI Indy boxes, a SunOS server,
some O2 and a stray Linux or two.  The common problem was incompatibility of
binaries: things compiled on an Indy worked on the Indies and O2, but things
compiled on O2 were incompatible with Indy.  Exactly the same thing as
i386->i486->i586->i686->amd64.

Now, imagine that /usr/bin is split this way:
/usr/bin (perl, bash)
/usr/bin/indy (binaries)
/usr/bin/o2 (binaries)
/usr/bin/sun (binaries) [1]
Can you see what I mean?  By just having different PATHs, everything would
be completely transparent.  And the multiarch would take care of all
libraries and headers.

> Hm... This entire concept seems messy. It seems that processors that
> support multiple architectures, as well as cross compilition are begining
> to blur the line between /usr and /usr/share.

It's not "messy", it's plain awesome.  And if the line gets blurred into
oblivion, it will be a reason for joy.


[1] Ok, ok.  I'm stretching it a bit, as SunOS was a different beast than
IRIX.  But if all boxes are Debian...

Cheers.
-- 
1KB // Rule #6: If violence wasn't your last resort,
// you failed to resort to enough of it.
//   - The Seven Habits of Highly Effective Pirates


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

Re: Intent to hijack Bacula

[José Luis Tallón]

Steve Langasek wrote:
> It is the responsibility of a package maintainer to ensure that fixes for
> bugs are uploaded in a timely manner.  If José Luis isn't able to do this,
> because he doesn't have a sponsor or for any other reason, then he is not an
> effective maintainer for the package.
>   
That is another matter, probably. I never claimed that I have been the
best maintainer for this.
> Actually, we've heard in this thread that Stephen (his AM) *did* offer to
> sponsor bacula uploads, and José Luis did not avail himself of this.
When the offer did come, I wasn't able to prepare the upload anyway.
I suspected that Stephen, given the state of things, would be in excess
picky with my packaging.
Moreover, I couldn't trust that he would upload in a timely manner...
>   So
> it's not at all clear to me why you think anyone other than José Luis should
> bear the responsibility of this package not being fixed.
>   
>> He has packaged the last version of bacula, and it is not uploaded
>> because it's not ready, then a new version was showed up... he has a
>> personal apt repository that users from bacula mailing list uses, and
>> packages (not yet finished) in sourceforge... so is it clear for you
>> that he is not going to work on it again?
>> 
>
> IME, making plans in Debian based on whether someone else has *promised* to
> do something does not give very good results. 
I can understand this.
>  The bacula packages have been removed from testing *repeatedly* over the 
> past year due to one RC bug or
> another being reported against it; and it seems that the only real movement
> towards getting them fixed has only come in response to John's takeover
> attempt. 
It does happen to be the same time when I am finally home (just returned
from Sweden, where I have been for almost 21 months) and had the
opportunity to work effectively on my packages again.
Unfortunate coincidence, I must admit.
> I can't say that I fault John for wishing to take over this package and fix 
> it.
>   
Thank you for being impartial and acting cool on this, Steve.

However, regular practice for this is to offer help or co-maintainership
(which others did before) and not hijacking the package.
Even when I explicitly denied being willing to give up the package, John
has attempted (and almost succeeded already) hijacking my package. This
is what I don't accept.

I have in the past always accepted patches and included them as soon as
I could.
How is it different this time?

I can feel nervousness due to the upcoming freeze... there is still
almost three months left for the base freeze.
Why shouldn't I be able to fix my packages in a reasonable period of
time (say, before the end of May) now that I am back home? Assuming I
failed, this "super-duper developer", John Goerzen, has proved to be
able to "fix everything" to your liking in a very short amount of time,
and so would be able to have Bacula in Etch in no time.


If grave personal issues are not a valid excuse for not devoting Debian
as much time as I would have liked to in the past months, then most of
the people in this thread shall step out of it and shut up.
I won't point fingers here. You know who you are, and I need not say it.


If that is indeed the case, state it clearly so that all people
approaching Debian will be warned beforehand.
I will also consider whether I am interested in contributing any work to
Debian in that case, too... as will probably most other people.


However, I am amazed about how much attention Bacula has attracted as of
lately... when I first packaged it and began maintaining it almost three
years ago, nobody cared a bit about it. Now that the worst is over and
Bacula is becoming famous, all sorts of people want to have their names
attached to it... I can't hardly be surprised by this.

Note, however, that I have accepted co-maintainership (as long as it is
done on fair terms to me) and have even created an Alioth project for this.



Thanks,

J.L.


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

Bug#366900: ITP: asterisk-prompt-es-co -- Colombian Spanish voice prompts for the Asterisk PBX

[Santiago Ruano Rincón]

Package: wnpp
Severity: wishlist
Owner: "Santiago Ruano Rincón" <[EMAIL PROTECTED]>


* Package name: asterisk-prompt-es-co
  Version : 0.0.20060503
  Upstream Author : Avatar Ltda. <[EMAIL PROTECTED]>
* URL : http://www.avatar.com.co/
* License : GPL
  Description : Colombian Spanish voice prompts for the Asterisk PBX

 These are Colombian Spanish voice prompts for the Asterisk PBX, courtesy
 of Avatar Ltda., Colombia.
 .
 You need this package if you intend to run Asterisk and wish to support
 Spanish-speaking callers.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.15
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8)


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

Re: Getting rid of circular dependencies, stage 4

[Andrew Vaughan]

On Thursday 11 May 2006 01:25, Frank Küster wrote:
> The only things that should be installed separately are
> probably aptitude, apt and dpkg, then just dist-upgrade.
>

From memory, upgrading apt + friends seperately isn't possible whilst synaptic is installed.  In sarge, the gnome meta package depends on synaptic, so this probably applies to a lot of desktop systems. 

In sarge, synaptic depends on libapt-pkg-libc6.3-5-3.3, which is provided by apt.

In etch, apt provides libapt-pkg-libc6.3-6-3.11, which matches the depends of synaptic in etch.  

Adding CC to APT Development Team  since I'm wondering whether the changes to apt really required dropping the provides of libapt-pkg-libc6.3-5-3.3?

For the future, could apt provide a real library, hence solving this problem for etch+1? 

Andrew V.

Re: Intent to hijack Bacula

[José Luis Tallón]

Stephen Frost wrote:
>> If the maintainer still wants to maintain it, help him, do NMUs, whatever,
>> but I'm still looking for one reason you can take over the package against
>> the maintainer's opinion.
>> 
>
> He wants to have his name on the package w/o doing the work
> (apparently). 
What if I prove you wrong? Afraid of that?
You might as well not be right on this...



J.L.


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

Re: Intent to hijack Bacula

[Stephen Frost]

* Jos? Luis Tall?n ([EMAIL PROTECTED]) wrote:
> Steve Langasek wrote:
> > Actually, we've heard in this thread that Stephen (his AM) *did* offer to
> > sponsor bacula uploads, and José Luis did not avail himself of this.
> When the offer did come, I wasn't able to prepare the upload anyway.
> I suspected that Stephen, given the state of things, would be in excess
> picky with my packaging.

I certainly would have been picky, as any DD *should* be.  It's
unfortunate that you've been able to slide by without someone picking
through your package.

> Moreover, I couldn't trust that he would upload in a timely manner...

Uh-huh, this argument really only flies if you'd actually *tried* it and
been unsuccessful.  Saying "I couldn't upload fixes because someone
offered but I'm not sure if he'd actually have time so I didn't bother
to ask" doesn't really cut it.  I *had* asked you for packages which
fixed the issues I found and those never appeared either.

> It does happen to be the same time when I am finally home (just returned
> from Sweden, where I have been for almost 21 months) and had the
> opportunity to work effectively on my packages again.
> Unfortunate coincidence, I must admit.

Rather unfortunate, especially when you were telling me in February that
you were going to have fixed packages soon after a harddrive failure or
some such, iirc...

> However, regular practice for this is to offer help or co-maintainership
> (which others did before) and not hijacking the package.

No, regular practice is to hijack it.  It's just that in general the
'maintainer' is MIA entirely instead of only-in-practice.

> Even when I explicitly denied being willing to give up the package, John
> has attempted (and almost succeeded already) hijacking my package. This
> is what I don't accept.

Erm, he's already 'succeeded'..  There really isn't any question about
it, he's just cleaning up more of the mess before uploading the new
version.  Feel free to take a look at darcs...

> I have in the past always accepted patches and included them as soon as
> I could.
> How is it different this time?

You don't seem to understand that some of what your package was doing
was unacceptable and seemed uninclined to accept patches for it.  Not to
mention that you havn't done an upload in ages and seem to feel unstable
is a place for dumping broken garbage..

> Why shouldn't I be able to fix my packages in a reasonable period of
> time (say, before the end of May) now that I am back home? Assuming I
> failed, this "super-duper developer", John Goerzen, has proved to be
> able to "fix everything" to your liking in a very short amount of time,
> and so would be able to have Bacula in Etch in no time.

Unfortunately, it's just plain too late, and your attitude regarding it
doesn't work.  Take a break from it for a couple of days, let John
upload the packages when he's done with them and then review & critque
them, if you're still interested in working on bacula packaging.  I'm
very sure John would be happy to look at patches or suggestions you
might have.

> If grave personal issues are not a valid excuse for not devoting Debian
> as much time as I would have liked to in the past months, then most of
> the people in this thread shall step out of it and shut up.

Past year, and the 'grave personal issue' excuse has been played a
number of times..  It may be that it's time for you to accept that you
don't really have time to commit to a package such as bacula and that
John does.

> If that is indeed the case, state it clearly so that all people
> approaching Debian will be warned beforehand.

I'm pretty sure people who are approaching Debian to be maintainers
realize that letting packages with RC bugs for over a year sit around
with nothing done on them isn't appropriate.

> I will also consider whether I am interested in contributing any work to
> Debian in that case, too... as will probably most other people.

I doubt many people have the misconception that they can ignore their
Debian packages for over a year with outstanding RC bugs against them.

> However, I am amazed about how much attention Bacula has attracted as of
> lately... when I first packaged it and began maintaining it almost three
> years ago, nobody cared a bit about it. Now that the worst is over and
> Bacula is becoming famous, all sorts of people want to have their names
> attached to it... I can't hardly be surprised by this.

No, the only thing attracting attention here is your steadfast
insistance on trying to continue to be the maintainer of bacula when
it's pretty clear that you've done a poor job to date and John can clean
it up and get something our users can use into unstable quickly.

> Note, however, that I have accepted co-maintainership (as long as it is
> done on fair terms to me) and have even created an Alioth project for this.

It's pretty clear that any changes you'd like to make to the packaging
need to be reviewed before being applied.

Enjoy,