Re: [ad-hominem construct deleted]

[martin f krafft]

also sprach Matt Zimmerman <[EMAIL PROTECTED]> [2006.01.17.0039 +0100]:
> Ubuntu is a Debian derivative.  The work that Debian developers do is merged
> into Ubuntu as well.  Most of the source packages in Ubuntu are identical to
> the ones in Debian.  The statement that you quoted is an expression of
> gratitude and camaraderie.  I believe it was Mark who originally said it,
> but I agree with it.  I would also say that Debian's upstreams are, in the

s/Debian/Ubuntu

> same sense, Debian developers.  This is part of what makes free software so

And yes, all of this makes sense. I guess the issue some DDs have
with this model is that they aren't treated as Upstream because
there's a lack of information exchange. Moreover, Ubuntu has moved
ahead in a few areas, and Debian followed, which makes it difficult
to think in simple upstream-downstream terms.

Note that I don't hold the opinion, and I appreciate what Ubuntu is
doing -- I am just trying to echo the picture as I see it.

I concur that Scott's patches are not very useful since they
have been clearly automatically generated and often include
autogenerated files (see libhid for instance), but all in all,
Ubuntu is a worthy addition to the distro field, and Debian has
profitted *a lot* already: gcc4, python2.4, zope, xorg, you name it.

> maintainer to notify them that their package is present in Ubuntu sounds
> like spam to me, and posting Ubuntu-related announcements to Debian mailing

... not anymore than the migrated-to-testing-mails we get all the
time.

But anyway, we are not in need for more automated solutions. What
should happen is that DDs should be able to find out who's
responsible for their packages in Ubuntu, and the UD should treat
the DD as upstream, discussing with her/him and planning out
a strategy for changes. If a change is Ubuntu-specific, so be it. If
it isn't, work with the DD to have it integrated into Debian.

> The creation of Ubuntu was *very* widely publicized, as was the fact that it

... it's still not called "Debian for Humans" :)

-- 
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
 
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
 
"education is an admirable thing, but it is well to remember from time
 to time that nothing that is worth knowing can be taught."
-- oscar wilde


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

Re: making more packages binary NMU safe

[Steve Langasek]

On Mon, Jan 16, 2006 at 10:53:04PM -0600, Adam M. wrote:
> Ken Bloom wrote:
> > I noticed that glabels is broken on i386 because it's not binary NMU
> > safe, and someone did a binary NMU.

> > After poking around a bit, I found
> > http://lists.debian.org/debian-dpkg/2005/11/msg0.html, which
> > discussed a possible solution to this problem. Since then, we have
> > changed the version number format for binary NMUs, so I wanted to submit
> > a patch (based on the one mentioned previously) to allow the creation
> > more binNMU safe packages.

> Instead of doing blind substitutions like it is done currently, it is
> possible to separate Arch:all from Arch:any|other|whatever in the
> substitution script such that,

> Source-Version => bin NMU version for binaries that are build
> Source-Version => 'original' version for Arch:all binaries

Which would mean the value of the ${Source-Version} substitution would have
to change based on which *package name* preceded it in the control file --
horrible, horrible kludge!  No, the correct solution is to introduce two new
variables and deprecate the old one, instead of further re-defining
"Source-Version" in ways that have even less to do with the source version.

And why is this on -devel instead of on -dpkg, anyway?

-- 
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: when and why did python(-minimal) become essential?

[Anthony Towns]

On Mon, Jan 16, 2006 at 09:45:29PM -0500, Eric Cooper wrote:
> I saw today that the python-minimal package in unstable is tagged as
> Essential (and currently pulls in python2.3).  According to policy,
> this is supposed to happen only after discussion on debian-devel and
> consensus is reached, but I couldn't find that discussion in the list
> archives.

Joerg approved it at 09:50:15 2006/01/15, after Doko uploaded a
new python-defaults package (-4). I've no idea why he accepted it as
Priority:required and Essential:yes, and given that python-minimal isn't
any different to regular python (though presumably will be if we ever
switch to python2.4), I can't see why it was uploaded at this point.

The -5 upload removed the Essential:yes tag, and lowered the priority to
standard (apparently due to apt automatically installing Essential:yes
packages and thus screwing up people who've pinned stable or testing,
see #348354, and #348319), but since the override was already set at
required, that's what the Priority: field still shows.

Obviously, python2.4-minimal is what Ubuntu includes in its essential set;
so presumably the idea is to move Debian to a similar arrangement. Maybe
Doko's been paying attention to all the folks saying Ubuntu should
contribute back more?

I've changed the override to Priority: standard; I can't say I'm remotely
impressed by how this has been handled.

Cheers,
aj



signature.asc
Description: Digital signature

Re: making more packages binary NMU safe

[Peter Samuelson]

[Adam M.]
> Instead of doing blind substitutions like it is done currently, it is
> possible to separate Arch:all from Arch:any|other|whatever in the
> substitution script such that,
> 
> Source-Version => bin NMU version for binaries that are build
> Source-Version => 'original' version for Arch:all binaries

I suspect you haven't tried implementing that.  It would require a
major conceptual layering violation.  Worse than the disease.


signature.asc
Description: Digital signature

Re: making more packages binary NMU safe

[Ken Bloom]

Ken Bloom wrote:
> Peter Samuelson wrote:
> 
>>[Ken Bloom]
>>
>>
>>>$substvar{'Source-Version'}= $fi{"L Version"};
>>>+#Indep-Version is for supporting binary NMUs when a strict
>>>+#version dependancy is required against an arch independant package
>>>+$substvar{'Indep-Version'}= $fi{"L Version"};
>>>+#strip out the +bN format binary NMU version suffix
>>>+$substvar{'Indep-Version'} =~ s/\+b[0-9]+$//;
>>
>>
>>Uh, why does "Source-Version" not refer to, you know, the source
>>version?
>>
>>I think you meant this the other way around - a new Binary-Version or
>>Build-Version or something, to indicate the thing that Source-Version
>>misleadingly means now.
> 
> 
> Backward compatibility. According to
> http://lists.debian.org/debian-dpkg/2005/11/msg0.html, it's quite
> common for -dev packages to use Source-Version to depend on their
> libraries, so changing the behavior of Source-Version would require a
> large transition.
> 
> Perhaps the variables Source-Version should be left unchanged (and
> deprecated) but 2 variables ArchDep-Version and ArchIndep-Version should
> be introduced.

Here is the corresponding patch for that possibility. I hope the dpkg
maintainers will pick up one of these patches quickly.

--- controllib.pl.old   2006-01-15 22:50:55.0 -0600
+++ controllib.pl   2006-01-16 23:04:24.0 -0600
@@ -241,6 +241,9 @@
 &parsecdata('L',0,"parsed version of changelog");
 close(CDATA); $? && &subprocerr("parse changelog");
 $substvar{'Source-Version'}= $fi{"L Version"};
+$substvar{'ArchDep-Version'}= $fi{"L Version"};
+$substvar{'ArchIndep-Version'}= $fi{"L Version"};
+$substvar{'ArchIndep-Version'} =~ s/\+b[0-9]+$//
 }

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


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

Re: making more packages binary NMU safe

[Adam M.]

Ken Bloom wrote:
> I noticed that glabels is broken on i386 because it's not binary NMU
> safe, and someone did a binary NMU.
> 
> After poking around a bit, I found
> http://lists.debian.org/debian-dpkg/2005/11/msg0.html, which
> discussed a possible solution to this problem. Since then, we have
> changed the version number format for binary NMUs, so I wanted to submit
> a patch (based on the one mentioned previously) to allow the creation
> more binNMU safe packages.

Instead of doing blind substitutions like it is done currently, it is
possible to separate Arch:all from Arch:any|other|whatever in the
substitution script such that,

Source-Version => bin NMU version for binaries that are build
Source-Version => 'original' version for Arch:all binaries

This way nothing needs to be changed. No transition. Just some code. Not
as trivial as introducing new variables, but a lot simpler in the sort
term and the long term.

- Adam


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

Re: Need for launchpad

[Anthony Towns]

On Mon, Jan 16, 2006 at 06:58:47PM -0500, Joey Hess wrote:
> Matt Zimmerman wrote:
> > On Sun, Jan 15, 2006 at 05:09:44PM -0500, Joey Hess wrote:
> > > Hmm, it seems to me that Ubuntu has recently changed its practices
> > > regarding what degree of divergence from Debian is appropriate, notably
> > > in the introduction of the MOTU group.
> > The MOTU team was formed about a week after the first release of Ubuntu, in
> > October 2004.
> At what point did Ubuntu begin to add lots of people who weren't already
> seasoned Debian developers to the MOTU team, and set them loose making
> large numbers of changes to packages? Perhaps that's the inflection
> point that I'm looking for.

Well, if you want to know what's going on, you can always google. MOTU
Report #1, from 1st Mar 2005 (http://lwn.net/Articles/125666/) lists nine
MOTU, while the MOTU launchpad page (https://launchpad.net/people/motu/)
currently lists 35 MOTU, and the wiki lists some 22 MOTU teams
(https://wiki.ubuntu.com/MOTUTeams). These days there's also a fair
number of MOTU wannabes, I believe.

Cheers,
aj


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

when and why did python(-minimal) become essential?

[Eric Cooper]

I saw today that the python-minimal package in unstable is tagged as
Essential (and currently pulls in python2.3).  According to policy,
this is supposed to happen only after discussion on debian-devel and
consensus is reached, but I couldn't find that discussion in the list
archives.

-- 
Eric Cooper e c c @ c m u . e d u


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

Re: Need for launchpad

[Joey Hess]

I have replied to the implied ad-hominem in Matt's mail privately, but I
would like the state here that I didn't appreciate it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Need for launchpad

[Joey Hess]

Matt Zimmerman wrote:
> I think that you're looking for justification for your position after the
> fact, rather than making judgements based on observations. 

I've written at length in my blog before about the mess that Ubuntu
made of packages that I maintain in Debian. This mess seemed to become
much worse after the point that everyone began talking about MOTU.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Does it sometimes happen that people send mails before NMU ?

[Adeodato Simó]

* Per Olofsson [Mon, 16 Jan 2006 22:11:05 +0100]:

Hi,

> Mike Hommey:
> > The patch was 8 minutes prior to the NMU.

> I'm sorry about that, I had misinterpreted the 0-day NMU policy.

  My reading of the NMU policy as set by the release team is that it's
  okay to upload right after sending the patch, if you feel comfortable
  with it. I know this works well for a number of people (myself
  included), while some others prefer to always do a delayed upload.

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Ara que ets la meva dona, te la fotré fins a la melsa, bacona!
-- Borja Álvaro a Miranda Boronat en «Chulas y famosas»


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

Re: new mplayer 1.0pre7try2 package

[Vedran Furač]

A Mennucc wrote:
> hi everybody 
> 
> a new version of mplayer  1.0pre7try2  is available ; add  either
> 
> for the etch version, the line
>  "deb http://tonelli.sns.it/pub/mplayer/etch ./"

Hi!

Now we have mplayer in this repositories:

http://tonelli.sns.it/pub/mplayer/etch
ftp://ftp.nerim.net/debian-marillat/
http://apt.cerkinfo.be

...and probably in more. This could confuse users and lead to dependency
problems. Solution is to have only one repository for every piece of
software that can't be packaged in debian (i.e. non DFSG-free software and
software with patent problems). There is already such a repository, with
lots of packages:

http://debian-unofficial.org/

Could you, or someone else, put mplayer (and xvidcap, rte,...) there, and
notify people that run other repositories with mplayer to remove it or
help you to maintain it?


Regards,

Vedran Furač

Re: Getting rid of circular dependencies, stage 3

[Benjamin Seidenberg]

Joey Hess wrote:


Bill Allombert wrote:
 


Although sarge's aptitude did..
 


I don't know, there were no ways to upgrade to sarge's aptitude.
   



The bug log contains a log of astronut doing the upgrade with sarge's
aptitude..

 

I think the bigger problem is not whether it's possible to do this 
(which it somewhat was) but that it's not intuitive and that it would 
require research for someone to figure out how to do. Perhaps there 
should be some kind of upgrade pseudo-package created to ease the 
transition, that depends on the tools needed? Ie, aptitude install 
etch-upgrade would install the later version of aptitude, etc. needed 
for the upgrade.


Benjamin (astronut)


signature.asc
Description: OpenPGP digital signature

Re: [ad-hominem construct deleted]

[John Hasler]

Matt Zimmerman writes:
> Is the meaning of this statement truly unclear to you...

"Every Debian developer is also an Ubuntu developer" implies to me that I
can make uploads to Ubuntu.  I can't (not that I'm asking for that
privilege).  I don't doubt that it was meant as an expression of gratitude
and camaraderie, but it does not come across that way.  Perhaps "Every
Debian developer is, in a sense, also an Ubuntu developer" might get the
point across more clearly.

> Emailing every Debian maintainer to notify them that their package is
> present in Ubuntu sounds like spam to me...

It doesn't to me.  I am pleased when downstream distributions notify me
that they are using my packages.

-- 
John Hasler


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

Re: Need for launchpad

[Thomas Bushnell BSG]

Matt Zimmerman <[EMAIL PROTECTED]> writes:

> The ratio of Debian developers to upstream developers is *much* closer to
> 1:1 than the ratio of Ubuntu developers to Debian developers, but even so,
> my guess (based on at least some empirical observation of packages I'm
> familiar with) is that many of the same issues exist.  In some cases, there
> is a healthy and responsive relationship, and in others, there isn't.

Certainly, but the question here is not about individuals but about
the organizations.

Debian's policies tell all maintainers to submit patches upstream (and
that does not mean "tell them where they can get Debian and find the
patches themselves").

Debian's policies tell all maintainers to carefully distinguish the
Debian maintainer from the upstream maintainer, and to give proper
credit to both.

What I've been looking for is Ubuntu to do similar.


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

Re: [ad-hominem construct deleted]

[Robert Collins]

On Mon, 2006-01-16 at 19:21 -0500, Joey Hess wrote:
> > but I agree with it.  I would also say that Debian's upstreams are, in the
> > same sense, Debian developers. 
> 
> I think that we probably have hundreds of upstreams who would react with
> everything from disbelief to anger if Debian claimed that as a blanket
> statement.

And yet most upstreams can get pretty much arbitrary code into Debian,
just by committing it?. How many DD's read the -entire- diff on major
version upgrades from upstream. And not just read, audit.

Rob

-- 
GPG key available at: .


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

Re: Need for launchpad

[Matt Zimmerman]

On Mon, Jan 16, 2006 at 06:58:47PM -0500, Joey Hess wrote:
> Matt Zimmerman wrote:
> > On Sun, Jan 15, 2006 at 05:09:44PM -0500, Joey Hess wrote:
> > > Hmm, it seems to me that Ubuntu has recently changed its practices
> > > regarding what degree of divergence from Debian is appropriate, notably
> > > in the introduction of the MOTU group.
> > 
> > The MOTU team was formed about a week after the first release of Ubuntu, in
> > October 2004.
> 
> At what point did Ubuntu begin to add lots of people who weren't already
> seasoned Debian developers to the MOTU team, and set them loose making
> large numbers of changes to packages? Perhaps that's the inflection
> point that I'm looking for.

The MOTU team has never had a significant number of seasoned Debian
developers on it.  If such a developer is interested in contributing
directly to Ubuntu, they are more likely to join the core development team,
and the fact that we're already trusting them implicitly in certain ways is
taken into account when considering their application.  It has also always
been a relatively small group of people tackling maintenance of a large set
of packages, especially when considering transitions (e.g., new C++ ABI,
Python minor revisions) which involve changing a very large number of
packages.

I think that you're looking for justification for your position after the
fact, rather than making judgements based on observations.  I'm not entirely
sure where your negativity over Ubuntu originated (though I could hazard a
guess or two), but it wasn't because the MOTU team suddenly started behaving
differently.

-- 
 - mdz


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

Re: gerris FTBFS bug has not been fixed for 300 days

[kamaraju kusumanchi]

David Nusinow wrote:


On Mon, Jan 16, 2006 at 10:25:58AM -0500, kamaraju kusumanchi wrote:
 


Hi all
 Please let me know if there is other appropriate mailing list to 
report this problem. I am looking at the package gerris. This package 
has a FTBFS bug reported (along with a patch) against it 300 days ago. 
The bug report can be found at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300446 . There was no 
response from the maintainer since all these days. What can be done to 
improve this situation?
   



The maintainer for this package is MIA lately. I'm preparing an NMU for one
of his other packages, and I can NMU gerris sometime over the next few days
with your patch in his report. 


- David Nusinow
 

Just wanted to say that, the person who submitted the patch is not me. I 
am just interested in the package. Thanks for the NMU.


raju



--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


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

Re: [ad-hominem construct deleted]

[Joey Hess]

Matt Zimmerman wrote:
> On Sun, Jan 15, 2006 at 02:59:58AM +0100, Gerfried Fuchs wrote:
> >  It's not about succeeding. It's about false statements all the time,
> > like "Every Debian developer is also an Ubuntu developer."  If I were I
> > would know. And they are recompiling all my packages, so you can't even
> > say that they are using my packages directly.
> 
> Is the meaning of this statement truly unclear to you, or is this purely a
> rhetorical point?  Under the assumption that you read it differently than I
> do, I'll attempt to explain.

FWIW, Mark's statement is one that I flat out disagree with. I have no
obligation or committment to Ubuntu, therefore I am not an Ubuntu
developer. 

I appreciate his statement in the spirit I think he made it, but I don't
appreciate people who take it and shove it down my throat to try to
pretend that I have some committment to Ubuntu.

> but I agree with it.  I would also say that Debian's upstreams are, in the
> same sense, Debian developers. 

I think that we probably have hundreds of upstreams who would react with
everything from disbelief to anger if Debian claimed that as a blanket
statement.

Now, analog and procmeter's upstreams have on occasion read/subscribed
to the Debian BTS, sent patches to it, etc, and I certianly would be
happy to tell them I consider them to be in a sense Debian developers
because of that. But as a blanket statement it just makes the term
"Ubuntu|Debian developer" a no-op.

> Most Debian maintainers have probably never interacted with Ubuntu,
> and there's no reason that most of them should expect to.

And yet we're all "Ubuntu developers", hmm?

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Need for launchpad

[Matt Zimmerman]

On Mon, Jan 16, 2006 at 06:44:42PM -0500, Joey Hess wrote:
> It's amazing how the Debian project manages to communicate fixes to 
> an even more diverse set of upstream authors, isn't it.

I would be interested to know how you've measured this, because it sounds
hard.  It's only because Ubuntu publishes an archive of its patches that
it's possible to estimate how much of it propagates back into Debian, and
even so it isn't easy to get an accurate estimate.

The ratio of Debian developers to upstream developers is *much* closer to
1:1 than the ratio of Ubuntu developers to Debian developers, but even so,
my guess (based on at least some empirical observation of packages I'm
familiar with) is that many of the same issues exist.  In some cases, there
is a healthy and responsive relationship, and in others, there isn't.

-- 
 - mdz


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

Cool down?!

[Joerg Jaspert]

Hi

Could we stop the flaming period? Like - forever? And come back to
normal development, making the best distribution on this small planet.

Please remember that we have a Code of Conduct for our lists, which
includes nice things like
# Do not use foul language;
# Try not to flame; it is not polite. 

Back when I joined "the Net" someone told me two nice little sentences
(which are still true and also used, im sure you can find references
everywhere), which were something like "be nice to anyone else out
there, you want them to be nice to you" and "don't reply to a thread
just for the sake of it".

It would be great if that could work here too. No, you dont need to write
the same information the 7th time, just to keep the thread alive. And if
you are angry you should not write mail, postpone it, sleep a night and
then look at the mail again. Most probably the world is much better then...


-- 
bye Joerg
Unstable means "subject to rapid change" rather than "full of bugs",
though sometimes it is both :-).


pgpxl63KQC1wD.pgp
Description: PGP signature

Re: Need for launchpad

[Joey Hess]

Matt Zimmerman wrote:
> On Sun, Jan 15, 2006 at 05:09:44PM -0500, Joey Hess wrote:
> > Hmm, it seems to me that Ubuntu has recently changed its practices
> > regarding what degree of divergence from Debian is appropriate, notably
> > in the introduction of the MOTU group.
> 
> The MOTU team was formed about a week after the first release of Ubuntu, in
> October 2004.

At what point did Ubuntu begin to add lots of people who weren't already
seasoned Debian developers to the MOTU team, and set them loose making
large numbers of changes to packages? Perhaps that's the inflection
point that I'm looking for.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: [ad-hominem construct deleted]

[Matt Zimmerman]

On Sun, Jan 15, 2006 at 02:59:58AM +0100, Gerfried Fuchs wrote:
>  It's not about succeeding. It's about false statements all the time,
> like "Every Debian developer is also an Ubuntu developer."  If I were I
> would know. And they are recompiling all my packages, so you can't even
> say that they are using my packages directly.

Is the meaning of this statement truly unclear to you, or is this purely a
rhetorical point?  Under the assumption that you read it differently than I
do, I'll attempt to explain.

Ubuntu is a Debian derivative.  The work that Debian developers do is merged
into Ubuntu as well.  Most of the source packages in Ubuntu are identical to
the ones in Debian.  The statement that you quoted is an expression of
gratitude and camaraderie.  I believe it was Mark who originally said it,
but I agree with it.  I would also say that Debian's upstreams are, in the
same sense, Debian developers.  This is part of what makes free software so
special, that one's contributions travel far and wide to benefit others,
even if one has no direct involvement with them.

>  It's also about false statements like "We sync our packages to Debian
> regularly," because that simply doesn't happen for quite a lot of us,
> otherwise all these heated discussions wouldn't happen.

Given that you saw this on a wiki page, a disclaimer about wiki contents
should be implicit.  However, regardless of whether it's an accurate quote,
it's quite clear to me from context that your interpretation doesn't match
the text.

The full quote is "We sync our packages to Debian regularly, because that
introduces the latest work, the latest upstream code, and the newest
packaging efforts from a huge and competent open source community. Without
Debian, Ubuntu would not be possible."  It should be obvious from the
remainder of the sentence that it is talking about propagation of changes
*from* Debian *to* Ubuntu.

>  I can only speak for myself (like everyone anyway, but it seems to be
> mentioned), I haven't noticed anyone reaching me, so I hadn't had any
> chance to burn anyone. The only contact with respect to Ubuntu was a
> user disappointed that one of my packages in Debian had a fix that the
> one in Ubuntu hadn't... for several weeks. All I could do is thank him
> for appreciating my work but that it's out of my hands to fix it for
> Ubuntu because I never was notified about that it's included there, and
> wouldn't know at all who to contact therefore.

It was inappropriate for this user to raise this issue with you, rather than
with Ubuntu, but that's been discussed elsewhere in this thread already.
What I find interesting about your statement is that you seem to imply that
the situation would have been better if you had been notified that your
package was a part of Ubuntu.

This would be technically simple to implement, but I'm not convinced that
it's possible to do it in a socially acceptable way.  Emailing every Debian
maintainer to notify them that their package is present in Ubuntu sounds
like spam to me, and posting Ubuntu-related announcements to Debian mailing
lists has been deemed inappropriate by many in Debian as well.

The creation of Ubuntu was *very* widely publicized, as was the fact that it
was based on Debian, and this fact has been mentioned countless times since,
both in the press and on Debian mailing lists.  Clearly you were informed,
one way or another.  What was problematic about the way it happened, and how
could it have been improved?

> > They are really investing time on the co-operation,
> If they were, why would there be so much fuss about it?

Well, yes, I think so.  It's a complicated issue, and the fact that there
are discussions about it doesn't imply that either party isn't making an
effort.

> Again, speaking for myself, I haven't noticed such a thing for myself

I find this type of disclaimer very frustrating.  I see a number of opinions
expressed about the Ubuntu community by persons with no first-hand
experience with it.  Most Debian maintainers have probably never interacted
with Ubuntu, and there's no reason that most of them should expect to.
Setting aside the debate about patch submission for a moment, in the case of
most packages, there are no patches in Ubuntu relative to Debian.

In fact, I just looked, and I found only one package with maintainer
[EMAIL PROTECTED] which has a delta in Ubuntu: libmetakit2.4.9.3.  I read the
patch just now; here's what's in it:

- Transition to python2.4 as the default Python version in Ubuntu.  You
  don't want this patch for Debian yet.

- Packaging transition for the gcc4 C++ ABI.  Debian developers were
  notified about the availability of these patches in Ubuntu when the
  transition began in Debian, though it looks like you chose not to
  use it, and rebuilt the package instead.

- autoconf has been re-run.

In other words, I don't see what it is that you're dissatisfied about, in
your role as maintainer of these packages.  Are you speaking for yo

Re: Need for launchpad

[Joey Hess]

Matt Zimmerman wrote:
> Only Debian developers can push changes into Debian, and indeed only
> particular Debian developers can push particular changes into Debian.
> Routing patches through this mesh involves a lot of overhead, especially in
> the form of latency.  It's commonplace in Debian to wait weeks for a
> response from a maintainer, for example, and there's no one covering for
> them during that time.  Just as some aspects of Ubuntu's operation are not
> visible to the Debian community, Ubuntu MOTUs for example cannot be
> reasonably expected to know who is responsive, who is MIA, whether a
> particular maintainer doesn't want to receive email with the word "Ubuntu"
> in it, etc.

It's amazing how the Debian project manages to communicate fixes to 
an even more diverse set of upstream authors, isn't it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: For those who care about their packages in Ubuntu

[Joey Hess]

Raphael Hertzog wrote:
> Not really... it happens quite often that I plan on working on a new
> upstream version (or whatever) but for various reasons, I do not prioritze
> it much because I know I will do it in time for etch... however I may be
> interested to have that better version in Ubuntu as well instead of the
> actual version (which may be too buggy in my opinion).

On second read, this is also quite disrespectful of fellow DDs and users
who run Debian unstable (or testing) and who would be stuck with said
buggy software.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: new mplayer 1.0pre7try2 package

[Paul TBBle Hampson]

On Mon, Jan 16, 2006 at 06:27:40PM +0100, A Mennucc wrote:

> hi everybody 

> a new version of mplayer  1.0pre7try2  is available ; add  either

> for the etch version, the line
>  "deb http://tonelli.sns.it/pub/mplayer/etch ./"

> or

> for the sarge version, the line
>  "deb http://tonelli.sns.it/pub/mplayer/sarge ./"

> to /etc/apt/source.list .

Interesting... For a proposed-to-go-into-Debian-archive-build, there's
no sid version?

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/
---


pgpM32BJIqp8H.pgp
Description: PGP signature

Re: For those who care about their packages in Ubuntu

[Joey Hess]

Matthew Palmer wrote:
> It's a hell of a lot better than having useless crap with your
> name on it in a stable release of something as high profile as Ubuntu,
> though.

FYI, I refuse to allow the fact that my code happens to be present in 
a currently perceived as high profile distribution to hold my time
hostage. I've never done it before with other high profile distributions
(Corel's mangling of alien comes to mind), and I won't start now. The
correct action in these circumstances is a sufficiently evolved
killfile.

Please consider ALL code written/maintained by me that is present in
Ubuntu and is not bit-identical to code/binaries in Debian to be not
suitable for release with my name on it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: For those who care about their packages in Ubuntu

[Joey Hess]

Raphael Hertzog wrote:
> Not really... it happens quite often that I plan on working on a new
> upstream version (or whatever) but for various reasons, I do not prioritze
> it much because I know I will do it in time for etch...

I think that nearly anyone on the release team will tell you that this
is a false time optimisation. The general result is the delay of stable
releases.

It also doesn't take into account things like d-i beta releases, which
include a snapshot of all of Debian testing by way of the CD/DVD images.
(And which have never been pre-announced on d-d-a, FWIW).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: new mplayer 1.0pre7try2 package

[Eric Dorland]

* A Mennucc ([EMAIL PROTECTED]) wrote:
> 
> hi everybody 
> 
> a new version of mplayer  1.0pre7try2  is available ; add  either
> 
> for the etch version, the line
>  "deb http://tonelli.sns.it/pub/mplayer/etch ./"
> 
> or
> 
> for the sarge version, the line
>  "deb http://tonelli.sns.it/pub/mplayer/sarge ./"
> 
> to /etc/apt/source.list .

This has probably been covered ad nauseum, but where do we stand in
respect to getting mplayer in Debian?

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

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


signature.asc
Description: Digital signature

Re: Need for launchpad

[Matt Zimmerman]

On Sun, Jan 15, 2006 at 01:08:41AM +1100, Hamish Moffatt wrote:
> On Fri, Jan 13, 2006 at 12:34:51PM -0800, Matt Zimmerman wrote:
> > can easily spot the holes in it.  Likewise, a proposal that Ubuntu
> > developers should put their changes into Debian instead sounds simple, but
> > to an Ubuntu developer is obviously impractical.
> 
> Could you elaborate on this? It's not obvious to me at all why more
> changes couldn't be pushed through Debian and automatically into Ubuntu.

Only Debian developers can push changes into Debian, and indeed only
particular Debian developers can push particular changes into Debian.
Routing patches through this mesh involves a lot of overhead, especially in
the form of latency.  It's commonplace in Debian to wait weeks for a
response from a maintainer, for example, and there's no one covering for
them during that time.  Just as some aspects of Ubuntu's operation are not
visible to the Debian community, Ubuntu MOTUs for example cannot be
reasonably expected to know who is responsive, who is MIA, whether a
particular maintainer doesn't want to receive email with the word "Ubuntu"
in it, etc.

This is another instance of the long-standing "Debian has no face" issue.
Organizations external to Debian need genuine, responsive, personal,
persistent contacts to interface with.

I think that a more practical approach is to have someone (or a team)
working within Debian as a liaison, who will manage the queue and ensure
that the right people are contacted and that the changes eventually get
uploaded to Debian.  This is more or less what I hope the "utnubu" project
will do.

> On a related note, it seems to me that the existence of the "MOTU" team,
> as non-core Ubuntu developers who are also not Debian developers,
> encourages more packages to be forked. Those developers can't make
> direct Debian uploads even if they want to; at worst they have no interest 
> in contributing to Debian at all.

There are also Ubuntu core developers who are not also Debian developers,
and their number will continue to grow.  Joining Debian cannot be a
prerequisite for working on Ubuntu; that would be entirely impractical.

-- 
 - mdz


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

Bug#348423: ITP: python-pynids -- a python wrapper for libnids

[Lorenzo Martignoni]

Package: wnpp
Severity: wishlist
Owner: Lorenzo Martignoni <[EMAIL PROTECTED]>


* Package name: python-pynids
  Version : 0.5
  Upstream Author : Michael J. Pomraning <[EMAIL PROTECTED]>
* URL : http://pilcrow.madison.wi.us/pynids/
* License : GPL
  Description : a python wrapper for libnids

pynids is a python wrapper for libnids, a Network Intrusion Detection
System library offering sniffing, IP defragmentation, TCP stream
reassembly and TCP port scan detection.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.14
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)



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

Re: For those who care about their packages in Ubuntu

[Matthew Palmer]

On Mon, Jan 16, 2006 at 08:51:12AM +0100, Raphael Hertzog wrote:
> Hello Joey,
> 
> On Sun, 15 Jan 2006, Joey Hess wrote:
> > Leaving ubuntu out of this, what puzzles me about your message, Raphael,
> > is this:
> > 
> > Raphael Hertzog wrote:
> > > If you have some uploads pending, and would like to see those packages
> > > included [...]
> > 
> > > If for whatever reason you don't want to upload the new package to Debian
> > > directly [...]
> > 
> > This seems to assume that 
> > 
> > a) There might be a lot of Debian developers who have some upload ready
> >to go but are sitting on them for some reason.
> 
> Not really... it happens quite often that I plan on working on a new
> upstream version (or whatever) but for various reasons, I do not prioritze
> it much because I know I will do it in time for etch... however I may be
> interested to have that better version in Ubuntu as well instead of the
> actual version (which may be too buggy in my opinion). If I don't know
> about the Ubuntu freeze, I may miss the opportunity to work on it in time...

Personally, I think that Debian maintainers need to be a bit more proactive
about filing faux-serious "keep this out of testing" bugs (and requesting
removals from testing in the meantime), and Ubuntu needs to track this
activity to work out what stuff the Debian maintainer thinks is going to
suck if it ends up in the next Ubuntu release.

Until this utopia occurs, however, I've taken the liberty of requesting
removal of non-release-worthy packages for the next Ubuntu release.  E-mail
ubuntu-motu@lists.ubuntu.com (it's probably subscriber-only, though, which
makes it a bad choice for communications with the MOTUs by outsiders,
unfortunately) and make the request.

To be fair to the MOTUs, it's probably best to do this fairly quickly once
you realise that the current version is bong and you can't fix it quickly,
as (according to a senior Ubuntu person) MOTUs are supposed to be fixing
major bugs in Debian packages anyway, so if they know up-front that
something is broken, and they're doing their job, they can fix it or remove
it, at their choice.  Asking for removal now doesn't give the MOTUs much
time to fix.  It's a hell of a lot better than having useless crap with your
name on it in a stable release of something as high profile as Ubuntu,
though.

- Matt


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

Re: Does it sometimes happen that people send mails before NMU ?

[Per Olofsson]

Hi,

Mike Hommey:
> The patch was 8 minutes prior to the NMU.

I'm sorry about that, I had misinterpreted the 0-day NMU policy.

By the way, does anybody have a recommendation on how long the delay
between an NMU patch and upload should be?

(Please CC me on replies.)

-- 
Pelle


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

Re: gerris FTBFS bug has not been fixed for 300 days

[David Nusinow]

On Mon, Jan 16, 2006 at 03:42:54PM -0500, David Nusinow wrote:
> On Mon, Jan 16, 2006 at 10:25:58AM -0500, kamaraju kusumanchi wrote:
> > Hi all
> >   Please let me know if there is other appropriate mailing list to 
> > report this problem. I am looking at the package gerris. This package 
> > has a FTBFS bug reported (along with a patch) against it 300 days ago. 
> > The bug report can be found at 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300446 . There was no 
> > response from the maintainer since all these days. What can be done to 
> > improve this situation?
> 
> The maintainer for this package is MIA lately. I'm preparing an NMU for one
> of his other packages, and I can NMU gerris sometime over the next few days
> with your patch in his report. 
 ^^^
I meant "the" bug report, if that was unclear :-)

 - David Nusinow


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

Re: gerris FTBFS bug has not been fixed for 300 days

[David Nusinow]

On Mon, Jan 16, 2006 at 10:25:58AM -0500, kamaraju kusumanchi wrote:
> Hi all
>   Please let me know if there is other appropriate mailing list to 
> report this problem. I am looking at the package gerris. This package 
> has a FTBFS bug reported (along with a patch) against it 300 days ago. 
> The bug report can be found at 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300446 . There was no 
> response from the maintainer since all these days. What can be done to 
> improve this situation?

The maintainer for this package is MIA lately. I'm preparing an NMU for one
of his other packages, and I can NMU gerris sometime over the next few days
with your patch in his report. 

 - David Nusinow


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

Re: Need for launchpad

[Thomas Bushnell BSG]

Theodore Ts'o <[EMAIL PROTECTED]> writes:

> On Mon, Jan 16, 2006 at 12:44:01AM -0800, Thomas Bushnell BSG wrote:
>> I think this is not quite true.  In any case, my recollection was that
>> the bad cooperation was a two-way street, with you being extremely
>> reluctant to acknowledge the concerns and needs of distributions, and
>> on the other side, distributions disregarding your requests about how
>> the package should be modified or installed.
>
> If that means I wasn't ready to accept a patch which *wasn't* *ready*
> *yet*, and people went ahead and installed a patch which I rejected is
> evidence of my "relectant to acknowledge the concerns and needs of
> distributions", maybe.  When Debian users started having their
> filesystems getting corrupted, it was proved that I was right, didn't
> it?

I think the feeling was that there was an awful lot of foot-dragging.
I certainly don't think you should install a patch which is incorrect!
But I think people's perception was that you thought it was perfectly
fine for e2fs to not support large filesystems, for an arbitrarily
long stretch of time.  At least, my recollection was that there was
only "this patch isn't well thought out" and no "here is an approach
I'd like" or "this is a patch that does the job correctly."

> Free speech is a b*tch, isn't it?  Debian at the time claimed that
> everything was being done in the interests of the users.  It wasn't
> true, but hey, the the only way we can counter free speech is with
> more speech.  So if we believe that Ubuntu is not cooperating well
> with Debian, then Debian should issue a formal statement listing how
> Ubuntu is failing to cooperate well with Debian.  Of course, how the
> press release is worded will be critical in determining how people
> outside of Debian will perceive us as a result.

We don't need that, do we?  We aren't *that* bothered by Ubuntu's
actions, so we don't need to start a war.


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

Bug#348382: ITP: collatinus -- lemmatisation of latin text

[Christian Perrier]

Package: wnpp
Severity: wishlist
Owner: Christian Perrier <[EMAIL PROTECTED]>

* Package name: collatinus
  Version : 7.13
  Upstream Author : Yves Ouvrard <[EMAIL PROTECTED]>
* URL : http://www.collatinus.org
* License : GPL
  Description : lemmatisation of latin text

 Collatinus can be used to lemmatise latin texts, i.e. extract words and
 make a lexicon which indicates for each word its canonic form, and how
 the form actually found in the text was derived from it, for instance by
 declining it. Example : rosam gives : rosa-rosae -- acc. sing.
 Collatinus provides a nice graphic front-end to each operation.

This software has a long life in the French Educational software community.
The Debian packaging has been done and maintained by Georges Khaznadar who
will be the maintainer of the package in long term. 

This ITP is a first attempt to add one of the numerous interesting
developments made in the educational community in France to integrate the
official Debian archive and thus be more easily available to Debian and
Debian derivates (debian-edu/Skolelinux, Edubuntu) users.


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

new mplayer 1.0pre7try2 package

[A Mennucc]

hi everybody 

a new version of mplayer  1.0pre7try2  is available ; add  either

for the etch version, the line
 "deb http://tonelli.sns.it/pub/mplayer/etch ./"

or

for the sarge version, the line
 "deb http://tonelli.sns.it/pub/mplayer/sarge ./"

to /etc/apt/source.list .

a.


signature.asc
Description: Digital signature

Re: Development standards for unstable

[Thomas Viehmann]

Russ Allbery wrote:
> Thomas Viehmann <[EMAIL PROTECTED]> writes:
>>Russ Allbery wrote:
>>>The thing is... most of the orphaned packages are in fairly good shape.
>>How do you know?
> Well, because at one point I went through the PTS for each one of them,
> checked for filed bugs, checked lintian reports, etc.  I haven't
> specifically *used* each of them, but I think the choices are no one is
> using them (popcon seems to say no), no one is reporting problems
> (possible, but statistically I'd expect someone to notice), or they're in
> fairly good shape.

Well, given that several people with more QA experience than myself
objecting to this, I guess I'll yield to experience. Maybe I'll just
discuss a manual selection of packages first.

Thanks for your input.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Bug#348364: ITP: libyaml-syck-perl -- Fast, lightweight YAML loader and dumper

[Stephen Quinney]

Package: wnpp
Severity: wishlist
Owner: Stephen Quinney <[EMAIL PROTECTED]>


* Package name: libyaml-syck-perl
  Version : 0.28
  Upstream Author : Audrey Tang <[EMAIL PROTECTED]>
* URL : 
http://www.cpan.org/authors/id/A/AU/AUTRIJUS/YAML-Syck-0.28.tar.gz
* License : BSD + GPL (>= 1) or Perl Artistic
  Description : Fast, lightweight YAML loader and dumper

 This module provides a Perl interface to the libsyck data
 serialization library.  It exports the Dump and Load functions for
 converting Perl data structures to YAML strings, and the other way
 around.


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


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Mon, Jan 16, 2006 at 11:35:17PM +1000, Anthony Towns 
 wrote:
> If you've got more information than is in the bug report, that's fine; add
> it to the bug report, and do whatever else is appropriate to fix the problem.
> 
> Closing reports without fixing real bugs isn't "fine", but there's no
> point I can see to moping about it on -devel -- especially when the bug
> report didn't have all the information.

The point is: fixing RC bugs without going a bit further than what is
written in the bug report (which actually stated "At least the
following files", implying further investigation necessary) is the result
of the "let's fix RC bugs so that the RC bugs count goes down" attitude.

I just got pissed by the does-not-fix-anything
second-in-a-row-without-notice NMU.

I will, indeed, reopen the bug and document it.

End of thread.


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

Re: Does it sometimes happen that people send mails before NMU ?

[Anthony Towns]

On Mon, Jan 16, 2006 at 01:36:18PM +0100, Mike Hommey wrote:
> > > Fixing RC bugs just for the sake of making the RC bug count down is not
> > > the best thing to do IMHO. 
> > Putting a temporary fix in place while a permanent one continues to be
> > worked out is /exactly/ the right thing to do.
> Putting a fix that solves partially the problem so that we can say the
> RC bug is closed is not exactly the right thing to do.

If the problem's only partially solved, reopen the bug. If the partial
solution is enough to make it not-RC, downgrade it as well as reopen it.
If the partial solution is worse than doing nothing, make a new upload
reverting the change.

> The "right" temporary fix, then, would have been to remove *all* the test
> files.
> But the files listed in the RC bug have been removed, the RC bug is
> "fixed", the RC bug count going down, so everything is fine.

If you've got more information than is in the bug report, that's fine; add
it to the bug report, and do whatever else is appropriate to fix the problem.

Closing reports without fixing real bugs isn't "fine", but there's no
point I can see to moping about it on -devel -- especially when the bug
report didn't have all the information.

Cheers,
aj



signature.asc
Description: Digital signature

gerris FTBFS bug has not been fixed for 300 days

[kamaraju kusumanchi]

Hi all
  Please let me know if there is other appropriate mailing list to 
report this problem. I am looking at the package gerris. This package 
has a FTBFS bug reported (along with a patch) against it 300 days ago. 
The bug report can be found at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300446 . There was no 
response from the maintainer since all these days. What can be done to 
improve this situation?


thanks
raju

--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


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

Re: Need for launchpad

[Theodore Ts'o]

On Mon, Jan 16, 2006 at 12:06:29PM +0100, Moritz Muehlenhoff wrote:
> Theodore Ts'o wrote:
> > I can give a couple of examples; one is way back when, before I took
> > over the maintenance of the e2fsprogs package, and was merely the
> > upstream author.  The then maintainer of e2fsprogs attempted to add
> > support for filesystems > 2GB, but botched the job, and the result was
> > people with filesystems > 2GB would in some circumstances, get their
> > filesystems trashed.  Of course, those people complained directly to
> > me, and the reputation of e2fsprogs took a hit as a result.  I was
> > pissed, but I was informed there was nothing I could do; the
> > maintainer of the package can do whatever they want, upstream wishes
> > be d*mned, unless you try to go through a rather painful appeal
> > process via a then-relatively inactive technical committeee.
> 
> If it lured you into becoming a DD we should mess up more upstream code :-)

So obviously by that logic Ubuntu is doing the right thing by luring
all Debian developers to become Ubuntu in order to protect their
reputation?  :-)

- Ted


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

Re: making more packages binary NMU safe

[Ken Bloom]

Peter Samuelson wrote:
> [Ken Bloom]
> 
>> $substvar{'Source-Version'}= $fi{"L Version"};
>>+#Indep-Version is for supporting binary NMUs when a strict
>>+#version dependancy is required against an arch independant package
>>+$substvar{'Indep-Version'}= $fi{"L Version"};
>>+#strip out the +bN format binary NMU version suffix
>>+$substvar{'Indep-Version'} =~ s/\+b[0-9]+$//;
> 
> 
> Uh, why does "Source-Version" not refer to, you know, the source
> version?
> 
> I think you meant this the other way around - a new Binary-Version or
> Build-Version or something, to indicate the thing that Source-Version
> misleadingly means now.

Backward compatibility. According to
http://lists.debian.org/debian-dpkg/2005/11/msg0.html, it's quite
common for -dev packages to use Source-Version to depend on their
libraries, so changing the behavior of Source-Version would require a
large transition.

Perhaps the variables Source-Version should be left unchanged (and
deprecated) but 2 variables ArchDep-Version and ArchIndep-Version should
be introduced.

--Ken Bloom

-- 
I usually have a GPG digital signature included as an attachment.
See http://www.gnupg.org/ for info about these digital signatures.


signature.asc
Description: OpenPGP digital signature

Re: Need for launchpad

[Theodore Ts'o]

On Mon, Jan 16, 2006 at 12:44:01AM -0800, Thomas Bushnell BSG wrote:
> I think this is not quite true.  In any case, my recollection was that
> the bad cooperation was a two-way street, with you being extremely
> reluctant to acknowledge the concerns and needs of distributions, and
> on the other side, distributions disregarding your requests about how
> the package should be modified or installed.

If that means I wasn't ready to accept a patch which *wasn't* *ready*
*yet*, and people went ahead and installed a patch which I rejected is
evidence of my "relectant to acknowledge the concerns and needs of
distributions", maybe.  When Debian users started having their
filesystems getting corrupted, it was proved that I was right, didn't
it?

> > So if that's our formal distribution of power between our upstreams
> > and our Debian Developers, why are we complaining about how Ubuntu
> > treats us?
> 
> I would be happy to agree that Debian did not cooperate well with you
> with respect to the past history of e2fsprogs.
> 
> Ubuntu claims to cooperate well with Debian.  That's the problem.

Free speech is a b*tch, isn't it?  Debian at the time claimed that
everything was being done in the interests of the users.  It wasn't
true, but hey, the the only way we can counter free speech is with
more speech.  So if we believe that Ubuntu is not cooperating well
with Debian, then Debian should issue a formal statement listing how
Ubuntu is failing to cooperate well with Debian.  Of course, how the
press release is worded will be critical in determining how people
outside of Debian will perceive us as a result.

- Ted


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

Re: Does it sometimes happen that people send mails before NMU ?

[Riku Voipio]

On Monday 16 January 2006 10:41, Mike Hommey wrote:
> On Sun, Jan 15, 2006 at 11:31:10PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
> > Well, no, but the fact that it's a longstanding release-critical bug,
> > with no maintainer response, means that it does warrant NMUer attention. 

> Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
> actually trying to find a better solution than removing the files, with
> upstream cooperation, considering that upstream adds new testcases quite
> often, and that any addition is likely to have the same problem.

The correct action in this case would have been CC: this cooperation with 
upstream to [EMAIL PROTECTED] If you are not mailing BTS to tell 
what you are doing/planning to do with the bug, you can hardly blame the 
NMUer for it either, right?

The problem with requiring mailing days before upload is the lack of instant 
gratification that motivates the NMUer. A delayed upload queue would seem to 
fix that, but in practice people seem to get active on fixing RC bugs only 
when the 0-day upload period is declared. Someone with more insight on human 
mind than I have might have an explanation for that too.

Cheers,
Riku

-- 
hi


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

Re: Trivial bug on apt-file (Was : Re: Development standards for unstable)

[Jesus Climent]

On Sun, Jan 15, 2006 at 01:07:58PM +1000, Anthony Towns wrote:
> On Sat, Jan 14, 2006 at 06:00:41PM +0100, Jesus Climent wrote:
> > On Fri, Jan 13, 2006 at 07:31:17PM +0100, Luk Claes wrote:
> > > and this answers IMHO what the maintainer wants a patch for: a system
> > > that would work with all download managers.
> > Which is something it is not going to work.
> 
> Huh? What's so hard about that?

I meant to say that following the same reasoning, we can also claim that all
downloaders for X should be supported, since the end user might have a
preference to use them...

Anyway, my believe is that supporting those two as a baseline and then adding
support for more is not a problem, but should not stop us from having a sane
working option upon installation.

-- 
Jesus Climent  info:www.pumuki.org
Unix SysAdm|Linux User #66350|Debian Developer|2.6.14|Helsinki Finland
GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429  7E18 66FC 1D7F 8694 6D69

It is not the size, mate. It's how you use it.
--N. Powers (Austin Powers in Goldmember)


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Mon, Jan 16, 2006 at 08:34:07PM +1000, Anthony Towns 
 wrote:
> On Mon, Jan 16, 2006 at 09:41:12AM +0100, Mike Hommey wrote:
> > > Well, no, but the fact that it's a longstanding release-critical bug, with
> > > no maintainer response, means that it does warrant NMUer attention.  If 
> > > some
> > > non-free files have been missed in the process, that would be bad, but 
> > > that
> > > doesn't seem to be a reason to not try?  Of course, it's your prerogative 
> > > as
> > > maintainer to review the contents of the NMU for correctness before
> > > acknowledging the bug closure.
> > Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
> > actually trying to find a better solution than removing the files, with
> > upstream cooperation, considering that upstream adds new testcases quite
> > often, and that any addition is likely to have the same problem.
> 
> Then you should reopen the bug (or remove the fixed tag), retitle it
> to "Previous non-free content should be reincluded under a free list"
> and set the severity to wishlist.
> 
> Having an NMU that removes the files doesn't stop you from readding them
> later when you and upstream have come to a conclusion.
> 
> > Fixing RC bugs just for the sake of making the RC bug count down is not
> > the best thing to do IMHO. 
> 
> Putting a temporary fix in place while a permanent one continues to be
> worked out is /exactly/ the right thing to do.

Putting a fix that solves partially the problem so that we can say the
RC bug is closed is not exactly the right thing to do.
There are much more than the removed files whose content is doubtful
license-wise. On the other hand, some of the removed files (the slashdot
rss feeds, for instance), are not exactly the kind of document that
ought to have licensing issues, but IANAL.
The "right" temporary fix, then, would have been to remove *all* the test
files.
But the files listed in the RC bug have been removed, the RC bug is
"fixed", the RC bug count going down, so everything is fine.

Mike


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

Re:

[Shearer Jacob]

Re:

[Livingston Mercedes]

Bug#338694: ITP: denyhosts -- simple script to prevent ssh/telnet brute force login

[Marco Bertorello]

Package: wnpp
Followup-For: Bug #338694
Owner: Marco Bertorello <[EMAIL PROTECTED]>

* Package name: denyhosts
  Version : 1.1.4
  Upstream Author : Phil Schwartz <[EMAIL PROTECTED]>
* URL : http://denyhosts.sourceforge.net
* License : GPL
  Description : simple script to prevent ssh/telnet brute force login

DenyHosts is a python program that automatically blocks ssh
brute-force attacks by adding entries to /etc/hosts.deny.
It will also inform Linux administrators about offending
hosts, attacked users and suspicious logins.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (1002, 'unstable'), (1001, 'stable'), (101, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Does it sometimes happen that people send mails before NMU ?

[Anthony Towns]

On Mon, Jan 16, 2006 at 09:41:12AM +0100, Mike Hommey wrote:
> > Well, no, but the fact that it's a longstanding release-critical bug, with
> > no maintainer response, means that it does warrant NMUer attention.  If some
> > non-free files have been missed in the process, that would be bad, but that
> > doesn't seem to be a reason to not try?  Of course, it's your prerogative as
> > maintainer to review the contents of the NMU for correctness before
> > acknowledging the bug closure.
> Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
> actually trying to find a better solution than removing the files, with
> upstream cooperation, considering that upstream adds new testcases quite
> often, and that any addition is likely to have the same problem.

Then you should reopen the bug (or remove the fixed tag), retitle it
to "Previous non-free content should be reincluded under a free list"
and set the severity to wishlist.

Having an NMU that removes the files doesn't stop you from readding them
later when you and upstream have come to a conclusion.

> Fixing RC bugs just for the sake of making the RC bug count down is not
> the best thing to do IMHO. 

Putting a temporary fix in place while a permanent one continues to be
worked out is /exactly/ the right thing to do.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Need for launchpad

[Moritz Muehlenhoff]

Theodore Ts'o wrote:
> I can give a couple of examples; one is way back when, before I took
> over the maintenance of the e2fsprogs package, and was merely the
> upstream author.  The then maintainer of e2fsprogs attempted to add
> support for filesystems > 2GB, but botched the job, and the result was
> people with filesystems > 2GB would in some circumstances, get their
> filesystems trashed.  Of course, those people complained directly to
> me, and the reputation of e2fsprogs took a hit as a result.  I was
> pissed, but I was informed there was nothing I could do; the
> maintainer of the package can do whatever they want, upstream wishes
> be d*mned, unless you try to go through a rather painful appeal
> process via a then-relatively inactive technical committeee.

If it lured you into becoming a DD we should mess up more upstream code :-)

Cheers,
Moritz


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

Re: making more packages binary NMU safe

[Peter Samuelson]

[Ken Bloom]
>  $substvar{'Source-Version'}= $fi{"L Version"};
> +#Indep-Version is for supporting binary NMUs when a strict
> +#version dependancy is required against an arch independant package
> +$substvar{'Indep-Version'}= $fi{"L Version"};
> +#strip out the +bN format binary NMU version suffix
> +$substvar{'Indep-Version'} =~ s/\+b[0-9]+$//;

Uh, why does "Source-Version" not refer to, you know, the source
version?

I think you meant this the other way around - a new Binary-Version or
Build-Version or something, to indicate the thing that Source-Version
misleadingly means now.


signature.asc
Description: Digital signature

Re: Emphasize teams, not packages

[Peter Samuelson]

(M-F-T set.)

[Frans Jessop]
> When somebody wants to become a DD he is told ?Go find a package to
> maintain, one that you can be the maintainer for.?  I see serious
> problems with this approach as Debian increases in DD's.  I will how
> this is in a second.  What I think should be emphasized is ?Go find a
> package team and join it and contribute and show your stuff.?

The point of maintaining a package is to prove that you *can* maintain
a package.  Being on a team proves nothing.  Being on a team and doing
most of the work proves something, if this can be measured, but that's
difficult.  As it happens, I'm on at least one team where I do a
majority of the work, and at least one team in name only (haven't yet
done *any* work).  I don't particularly expect to be judged favorably
for the one or unfavorably for the other, because it's just too hard to
get the data.

> I think Debian needs to emphasize teams packaging, not just
> individuals for many reasons.

We've had this conversation already.  So I'll skip it.  Besides, there
are lots of things we need to emphasise in Debian.  We've had those
conversations, too.

> Future A:
> 
> There are now 10,000 DD's and over 100,000 packages, most nobody
> uses, they are just there because they were needed by people who
> wanted to become DD's.

Obvious solution: Change the requirement from "maintain a package" to
"maintain a package that a significant number of people care about".
Since AMs / DAMs are people rather than machines, we don't need an
accurate automated metric for this - something as vague as popcon
should be quite sufficient to reveal the difference between useful
packages and pet packages only ever installed by people who said to
themselves "hmmm I wonder what this does" and then never bothered to
uninstall them.


signature.asc
Description: Digital signature

Bug#348317: ITP: mozilla-bookmarksync -- Mozilla Firefox extension to synchronize bookmarks

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist

* Package name: mozilla-bookmarksync
  Version : 1.0.2
  Upstream Author : [EMAIL PROTECTED]
* URL or Web page : 
* License : MPL 1.1/GPL 2.0/LGPL 2.1
  Description : Mozilla Firefox extension to synchronize bookmarks

Bookmarks Synchronizer is a Mozilla Firefox extension that let you
connect to an FTP/WebDAV server and synchronize your bookmarks that
are stored in an XML file. Setup is easy; just write in your
FTP/WebDAV server address, username, password and a name for the XML
file (by default called xbel.xml).  To start, press Upload to create
the file on the server and set (if you want) to automatically download
the file on startup or upload it when you close your browser

--Yarik


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

Re: Does it sometimes happen that people send mails before NMU ?

[Thijs Kinkhorst]

On Mon, 2006-01-16 at 09:41 +0100, Mike Hommey wrote:
> Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
> actually trying to find a better solution than removing the files, with
> upstream cooperation, considering that upstream adds new testcases quite
> often, and that any addition is likely to have the same problem.

Well, the problem is that the BTS is the only way to know about the
status of a bug. If there's no maintainer response to a RC bug, there's
no way to know whether the maintainer is working on it, is planning to
work on it very soon, or doesn't have the opportunity of working on it
anytime soon. Especially if the bug is lacking maintainer response for
many months, the chances of it being the latter are of course
increasing.

You can't expect from NMU'ers to be able to guess what's going on.
They're making an effort to address as many of the most serious problems
we have, and there are a lot of those problems. Just attaching a small
note to the respective bug can clear up a lot of confusion.

Whenever I receive a RC-bug on a package of mine (or mostly, any bug), I
file a response as soon as possible with a quick first assessment. It's
then clear to both reporter and other interested developers what's going
on.


Thijs


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

Bug#348309: ITP: dhcdbd -- dbus interface for dhclient

[Riccardo Setti]

Package: wnpp
Severity: wishlist
Owner: Riccardo Setti <[EMAIL PROTECTED]>


* Package name: dhcdbd
  Version : 0.1.10
  Upstream Author : Jason Vas Dias <[EMAIL PROTECTED]>
* URL : http://people.redhat.com/jvdias/dhcdbd/
* License : GPL
  Description : dbus interface for dhclient

dhcdbd provides a dbus interface to dhclient, so application
such as NetworkManager can query and control dhclient. This allows
an application neutral interface for such operations

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8)


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

Re: Need for launchpad

[Thomas Bushnell BSG]

Theodore Ts'o <[EMAIL PROTECTED]> writes:

> On Sun, Jan 15, 2006 at 03:12:33PM -0800, Thomas Bushnell BSG wrote:
>> Actually, upstream maintainers have no voice before the technical
>> committee, which exists to resolve disputes between Debian developers,
>> not between Debian developers and outsiders.
>
> Indeed.  And likewise, we have absolutely no control over what Ubuntu
> chooses to distribute, either.

Not absolutely none.  They must comply with the licenses. :)

The objection from me, at least, and many others, has been that Ubuntu
is *claiming* to cooperate with us, while really not doing so very
well at all, and rebuffing attempts to encourage a more useful form of
cooperation. 

>> The question here is *NOT* whether Ubuntu has good patches, but
>> whether they contribute back, via the BTS, patches which are relevant
>> to the Debian upstream.
>
> Actually, Manoj raised the issue of not wanting his name on packages
> being modified by a committee since bugs may harm his reputation.  

Sorry, I muddled the two separate issues badly.

One issue is the reluctance of Ubuntu to adopt the policy of
submitting all relevant patches to the Debian BTS.

The second issue is the Ubuntu practice of labelling packages with the
Debian maintainers, and not labelling them with a suitable
Ubuntu-specific address.

The second issue, in the form Manoj raised it, is solved by saying
"this package came from the one Manoj maintains, and we have changed
it in thus-and-such ways."  This preserves the attribution of credit,
while avoiding the tarnishing of reputation.

> I have in the past had my reputation harmed by people who screwed up
> e2fsprogs at various distributions.

I think this is not quite true.  In any case, my recollection was that
the bad cooperation was a two-way street, with you being extremely
reluctant to acknowledge the concerns and needs of distributions, and
on the other side, distributions disregarding your requests about how
the package should be modified or installed.

> So if that's our formal distribution of power between our upstreams
> and our Debian Developers, why are we complaining about how Ubuntu
> treats us?

I would be happy to agree that Debian did not cooperate well with you
with respect to the past history of e2fsprogs.

Ubuntu claims to cooperate well with Debian.  That's the problem.

Thomas


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

Re: Does it sometimes happen that people send mails before NMU ?

[Mike Hommey]

On Sun, Jan 15, 2006 at 11:31:10PM -0800, Steve Langasek <[EMAIL PROTECTED]> 
wrote:
> Hi Mike,
> 
> On Mon, Jan 16, 2006 at 07:47:52AM +0100, Mike Hommey wrote:
> > There have been 2 NMUs on libxml2 in a week and I never got a message
> > beforehand. Now I wonder if that practice has disappeared somehow.
> 
> > I admit I've not spent enough time for libxml2 recently, but still, I
> > wouldn't have been bothered by some poking beforehand.
> 
> > Moreover, I'm not exactly sure the second NMU has indeed removed all
> > problematic content but the bug is closed, so the NMUer may be happy.
> > Ah, by the way, the bug was not even a problem for package propagation
> > to testing, so that doesn't make the propagation an argument for a quick
> > upload.
> 
> The first bug shows a message from the NMUer apologizing for not sending his
> patch beforehand.  The second bug shows a patch sent by the NMUer prior to
> the NMU.  Did you not receive these mails?

The patch was 8 minutes prior to the NMU.

> > Moreover, I'm not exactly sure the second NMU has indeed removed all
> > problematic content but the bug is closed, so the NMUer may be happy.
> > Ah, by the way, the bug was not even a problem for package propagation
> > to testing, so that doesn't make the propagation an argument for a quick
> > upload.
> 
> Well, no, but the fact that it's a longstanding release-critical bug, with
> no maintainer response, means that it does warrant NMUer attention.  If some
> non-free files have been missed in the process, that would be bad, but that
> doesn't seem to be a reason to not try?  Of course, it's your prerogative as
> maintainer to review the contents of the NMU for correctness before
> acknowledging the bug closure.

Yes, it's my fault i didn't tag the bug or sent any feedback, but I'm
actually trying to find a better solution than removing the files, with
upstream cooperation, considering that upstream adds new testcases quite
often, and that any addition is likely to have the same problem.

Fixing RC bugs just for the sake of making the RC bug count down is not
the best thing to do IMHO. Some might even only be important bugs tagged
as grave or serious for some wrong reasons.

Mike


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

Re: Need for launchpad

[Reinhard Tartler]

On 1/16/06, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > While I don't disagree with this sentiment, keep in mind that Debian
> > itself is sometimes guilty of adding changes to packages when the
> > upstream may or may not approve.  Of course, we'll justify by saying
> > that "users want it", or that it is in "the best interests of the
> > users", but isn't that exactly the same excuse used by Ubuntu?
>
> That's right.
>
> The objection is not to changes in Ubuntu.  The objection is to a
> refusal to submit patches back.

What makes you think that there is general 'refusal to submit patches
back'? Espc. these days, where there are wiki pages like this:
https://wiki.ubuntu.com/ContributingToDebian


--
regards,
Reinhard

Re: For those who care about their packages in Ubuntu

[Raphael Hertzog]

Hello Joey,

On Sun, 15 Jan 2006, Joey Hess wrote:
> Leaving ubuntu out of this, what puzzles me about your message, Raphael,
> is this:
> 
> Raphael Hertzog wrote:
> > If you have some uploads pending, and would like to see those packages
> > included [...]
> 
> > If for whatever reason you don't want to upload the new package to Debian
> > directly [...]
> 
> This seems to assume that 
> 
> a) There might be a lot of Debian developers who have some upload ready
>to go but are sitting on them for some reason.

Not really... it happens quite often that I plan on working on a new
upstream version (or whatever) but for various reasons, I do not prioritze
it much because I know I will do it in time for etch... however I may be
interested to have that better version in Ubuntu as well instead of the
actual version (which may be too buggy in my opinion). If I don't know
about the Ubuntu freeze, I may miss the opportunity to work on it in time...

> b) There might be a lot of Debian developers who are more interested in
>contributing to other distributions rather than Debian, or who don't
>know how to upload to experimental or something.

I can only imagine that it may be interesting in some particular cases,
for example when Ubuntu has already done a transition that Debian hasn't
and where we know that the packages in Ubuntu and in Debian can't be the
same.

> What I don't understand is why you'd think that either group is large
> enough to warrant a post to d-d-a. Do Debian developers habitually delay
> uploading packages that are ready to go? Is there some reason why Debian
> developers who are no longer interested in contributing to Debian
> shouldn't be shown the door?

I hope I have better explained why I thought it was relevant.

BTW, I'll take the opportunity of your mail (which is the only
public response which is actually constructive) to give some facts and
conclusion about this announce :
- I received 2 private emails saying that this should have gone to -devel
- I received 3 private emails thanking me for the announce and the effort I do
to favor the cooperation between Ubuntu and Debian
- of course, there have been lots of discussion on IRC and on the list
- there's the stupid mail to d-d-a from Andrew Suffield (which should be
  tought how to reply by private email to simply tell me that this should
  have gone to -devel (like others have done))

I won't reuse d-d-a for this purpose and I'll ask Lucas Nussbaum (who
asked me to forward this announce) to publish those himself directly on
-devel in the future (he has been subscribed for a long time).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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