Has recibido una postal de Michael

[Michael]

Hola debian-devel@lists.debian.org, 

Has recibido una postal de Michael <[EMAIL PROTECTED]> !

Para ver tu postal por favor clickea este link :
http://postales.sonico.com/view.php?cid=12354503&[EMAIL 
PROTECTED]&db=1&t=ecards_sonico&ss=1


Muchas Gracias,
http://Postales.Sonico.com



Sitios recomendados

http://www.TarjetasTelefonicas.com - Ahorra hasta 95% en tus llamadas 
telefónicas

http://www.Sexymetro.com - ¿Crees que eres sexy?


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> On 18/05/08 at 15:55 +0200, Goswin von Brederlow wrote:
>> Esspecially when you have debian specific patches where things are a
>> clear divergence there won't be an upstream record.
>
> If there's a patch that is not going to be useful outside of Debian, and
> it's 100% clear, why should I even create a bug on the BTS about it?
> There's no point in discussing something that doesn't need discussion.

Because it is a divergence. Documenting only divergences upstream will
accept would be short sighted.

>> I agree with you that the bug description should be a summary. The BTS
>> would be the history of the patch. The how and why it became. If that
>> info is in upstreams BTS then you would just link that.
>> 
>> > 2) It makes the BTS another place to look at for upstreams or other
>> > distros interested in our patches.
>> 
>> What other place is there currently besides extracting the source and
>> checking that?
>
> The source package's debian/patches dir, which will still be the
> canonical place to get the up-to-date patch?

That assumes everyone uses debian/patches. Would be nice but that is
not reality.

>> > 4) The bureaucracy/usefulness ratio looks very high to me. After all,
>> > we spent 15 years not doing that, and it seems to me that many patches
>> > are small and don't require any discussion, so the overhead would be
>> > huge. Maybe we could try a simpler solution first?
>> 
>> "bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
>> the BTS. Not mutch work.
>
> That's not enough. It doesn't extract the relevant patch automatically

That was said to be optional. Once you know that there is a patch you
can always download the source and get it or patches.d.o could have it.

> and update the corresponding bug report, and it doesn't work with
> version-tracking, which would need to be updated have 3 notions:
> - notfound (already exist)

???

> - fixed using a Debian specific patch

(Fixes: #1234) in changelog.

> - fixed in upstream

(Closes: #1234) in changelog

Or equivalent mails to control. Fixes would do version tracking just
like closes does.

MfG
Goswin


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Ben Finney <[EMAIL PROTECTED]> writes:

> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> The proposal is about tracking the required patches in the BTS.

Should have said tracking the state of patches. Didn't mean the
patches verbatim.

> No, the bug is about classifying "divergence from upstream" as a bug
> to be tracked in the Debian BTS. The location of patches isn't a
> necessary part of the proposal.
>
> Patches in the BTS are listed in the proposal as a "can", not a
> "should" -- i.e. something that would be a natural part of the
> workflow, but not a necessary part of the proposal.

MfG
Goswin


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

Re: Sorting out mail-transport-agent mess

[Richard A Nelson]

On a related note


If I dood it, I get a whipping. I dood it.


What about the possibility of MTA/MSP alternatives - I'd like to
support the next generation sendmail (Meta - used to be SM x) -
a very postfix like design for enhanced security.

I recall RH, or a deriviative that supported multiple MTAs being
installed concurrently via alternatives.

For quite a while, Meta was only usable for an outgoing MTA, and
was missinge milter support (making it unusable, IMNSHO for inbound)
so I did some prelimiary work to support this in the sendmail package,
there would need be much infrastructure suppport to make this feasible.

--
Rick Nelson
"Even more amazing was the realization that God has Internet access.  I
wonder if He has a full newsfeed?"
(By Matt Welsh)


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

Re: divergence from upstream as a bug

[George Danchev]

On Sunday 18 May 2008, Bastian Blank wrote:
--cut--
> | $ md5sum dist*
> | 7417436d2d0cbe9322d7503041c2e2df  [EMAIL PROTECTED]
> | b959d34e40b01303e98a6b85255dd92d  dist_3.70.orig.tar.gz
> | $ mkdir 1 2
> | $ tar -C 1 -xzf [EMAIL PROTECTED]
> | $ tar -C 2 -xzf dist_3.70.orig.tar.gz
> | $ diff -urN 1/[EMAIL PROTECTED] 2/dist-3.70.orig | diffstat
> |  0 files changed
>
> Your point being?

Ops, sorry for the false positive -- my memory served me bad, I should have 
checked that first.

Another reason I thought of for seeing such defferences might be a silent 
subsequent change of the tarball at the upstream site (md5,sha1 sums 
including).

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Mailing lsit code of conduct, again

[Hamish Moffatt]

On Sun, May 18, 2008 at 07:21:29PM +0100, Mark Brown wrote:
> On Sun, May 18, 2008 at 06:08:23PM +0200, Raphael Hertzog wrote:
> 
> > public list that end up in their main INBOX. If those can't make the
> > effort to setup Mail-Followup-To, they should post less and not _more_
> > just for the sake of complaining about the copies.
> 
> Of course, MFT brings up the whole "it's not a standard, why should I
> follow it, my MUA never heard of it" thing...  You can't win.

Our code of conduct has the same problem - ours is different to many
other communities where CCs are fine or even welcome, eg the kernel
communities.


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


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

Re: Mailing lsit code of conduct, again

[Brian May]

Mark Brown wrote:

public list that end up in their main INBOX. If those can't make the
effort to setup Mail-Followup-To, they should post less and not _more_
just for the sake of complaining about the copies.



Of course, MFT brings up the whole "it's not a standard, why should I
follow it, my MUA never heard of it" thing...  You can't win.
  


This would be less of an issue if MUAs supplied with Debian supported it..

I know of two that do: mutt and gnus.

As far as I can tell, others don't have full support: e.g. evolution, 
icedove, etc.


isedove in Debian/etch doesn't even have a reply to list function 
(although it did the right thing for this email when I did "reply-all"; 
strange; maybe I am wrong and it really does support MFT at least when 
replying? Still I can't see how to set it automatically for outgoing 
emails).


Brian May


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

Re: ssl security desaster

[Martin Uecker]

Tollef Fog Heen wrote:
> * Martin Uecker 

[...]

> | There was a thread "building packages with exact binary matches"
> | about it. Unfortunately, most people seem to think that this is not
> | worth it.
>
> I don't think that's unfortunate; I think it's a waste of resources
> better spent elsewhere.

If somebody hacks into a DD's machine, the obvious thing for an attacker 
to do is to trojan a Debian package. I wonder how long it would take 
to find out... Maybe it did already happen, who knows?

> | > I believe that postinsts need the flexibility shell (or perl or
> | > python or whatever) gives them.  If you want to restrict postinsts
> | > to only be able to do a limited set of operations, the quality of
> | > packages will detoriate quite a bit as they are no longer flexible
> | > enough to cater for all packages's needs.

In fact, I think the opposite would be the case: The quality of Debian
would rise, because there would be the need to establish standard
interfaces for all reasonable cases where packages have to mess
with the system during installation. Compare this with running windows
applications without system privileges. You could argue as above,
that the quality of those programs will detoriate, because applications
are no longer flexible to cater for all applications's need. So
where is the difference?


Martin



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

Re: Mailing lsit code of conduct, again

[Martin Langhoff]

On Mon, May 19, 2008 at 12:33 PM, Ben Finney
<[EMAIL PROTECTED]> wrote:
> I'm not interested in receiving them in my email. I participate in the
> Debian mailing lists via a non-email interface, which makes it much
> more manageable. (For me, that is. I don't expect everyone to follow
> my habits in matters that affect only themselves.)

Just out filter *anything* that has [EMAIL PROTECTED] in the to or cc
fields, and you're *done*. No more funny rules.

Would that not work?



m
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


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

Re: Mailing lsit code of conduct, again

[Ben Finney]

"Martin Langhoff" <[EMAIL PROTECTED]> writes:

> On Mon, May 19, 2008 at 11:34 AM, Ben Finney
> <[EMAIL PROTECTED]> wrote:
> > Because I've configured all of the above, and *still* get
> > individual copies of messages that were sent to the list. I'm not
> > subscribed to the Debian mailing lists, so there is no "duplicate"
> > that can be detected by such methods.
> 
> So you are *not* interested in receiving replies to threads you are
> participating in? Interesting... but a bit strange.

I'm not interested in receiving them in my email. I participate in the
Debian mailing lists via a non-email interface, which makes it much
more manageable. (For me, that is. I don't expect everyone to follow
my habits in matters that affect only themselves.)

This is made inestimably more manageable because most people follow
the CoC and reply to the mailing lists without Cc to me, and I don't
have to remind most of them to do so all the time.

Threads like this are the unfortunate exception to that happy rule,
but if they have the outcome that more people become aware of the CoC
provision of no-Cc-by-default then that's something good among the
bad.

-- 
 \ "I am an optimist. It does not seem too much use being anything |
  `\  else."  -- Winston Churchill |
_o__)  |
Ben Finney


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

Re: Mailing lsit code of conduct, again

[Martin Langhoff]

On Mon, May 19, 2008 at 11:34 AM, Ben Finney
<[EMAIL PROTECTED]> wrote:
> Because I've configured all of the above, and *still* get individual
> copies of messages that were sent to the list. I'm not subscribed to
> the Debian mailing lists, so there is no "duplicate" that can be
> detected by such methods.
>
> The solution, as requested in the CoC, is to not have the message
> copies sent individually in the first place.

So you are *not* interested in receiving replies to threads you are
participating in? Interesting... but a bit strange.

I sometimes post in a list I'm not sub'd to and I sure hope people CC
me in their replies so I don't have to go hunting in various archives
for possible replies. This seems to be the most common scenario,
AFAIK.

cheers,


m
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


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

Re: divergence from upstream as a bug

[Charles Plessy]

'morning Neil and everybody. So many mails to read for breakfast!

Le Sun, May 18, 2008 at 03:51:18PM +0100, Neil Williams a écrit :
> proposal:
> 
> [EMAIL PROTECTED] | (Fixes: #nnn)
>   marks the bug as fixed by a patch added by Debian and
>   awaiting a new release upstream to be finally closed. 
>   nnn-fixed is ignored if the upstream tag is not already
>   set. Bugs can be fixed in the changelog of an upload using
>   (Fixes: #1234) in a similar manner to (Closes: #1234). The
>   principle usage of "fixed" is to denote points at which 
>   Debian diverges from upstream. Filenames of patch files must 
>   be clearly identified when using (Fixes: #1234) in the
>   changelog.

Even simpler: Fixes: #nnn downgrades the severity to wishlist, adds "To
be merged upstream:" to the subject, and sends a message saying "This
bug has been fixed by patching the original sources; we will forward
this patch to the upstream authors and close this bug report when
upgrading the Debian package to an upstream source in which the patch
has been merged or obsoleted".

This does not offer all the functionalities one could dream of, but it
may be the easiest start, especially that it can be performed by hand.
(Which I am considering doing for the packages I maintain).

> With suitable changes in debchange, we could have:
> 
> $ dch -a --fixes 1234 "Add 090_missing_stdlib_h.patch"
> ... time passes, new upstream release made...
> $ dch -a --closes 1234
> 
> Simple.

I like it :)

Have nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Mailing lsit code of conduct, again

[Ben Finney]

"Martin Langhoff" <[EMAIL PROTECTED]> writes:

> In this modern age of a mailman that lets subscribers configure their
> subscription to avoid duplicates, and procmail filters that help do
> the same at the client end (and some mail clients that have similar
> abilities of their own - ie gmail)... why does this funny and akward
> rule of debian lists persist?

Because I've configured all of the above, and *still* get individual
copies of messages that were sent to the list. I'm not subscribed to
the Debian mailing lists, so there is no "duplicate" that can be
detected by such methods.

The solution, as requested in the CoC, is to not have the message
copies sent individually in the first place.

-- 
 \"I fly Air Bizarre. You buy a combination one-way round-trip |
  `\ticket. Leave any Monday, and they bring you back the previous |
_o__)  Friday. That way you still have the weekend."  -- Steven Wright |
Ben Finney


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

Re: Mailing lsit code of conduct, again

[Ben Finney]

Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes:

> I believe it could be easier that the mailing list software left the
> mailing list in the reply-header. The main issue is that when you
> hit "Reply" the only one who is left in the headers is actually who
> sent the email and if you hit "Reply All" obviously the author of
> the last email is listed too.

So you use "Reply to List", which sends to the mailing list. If your
MUA doesn't support that, you're left with the task of doing so
manually, and reporting that lack as a bug to the vendor of your MUA.

> There's a good reason why this haven't been done yet? Other mailing
> lists which I've been subscribed use this.

http://woozle.org/~neale/papers/reply-to-still-harmful.html>

-- 
 \ "It is far better to grasp the universe as it really is than to |
  `\  persist in delusion, however satisfying and reassuring." |
_o__)  —Carl Sagan |
Ben Finney


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
>lsdiff -z -x '*/debian/*' *.diff.gz 
> or whatever - as long as I get a list of patched files brought up to my
> intention immediately.

I dont see a reason why the normal unpack action should spam the user. If
you care about the changes, just use the command. You can even have an alias
if you prefer that.

BTW:
+++ openssl-0.9.8g/Makefile
+++ openssl-0.9.8g/Configure
+++ openssl-0.9.8g/Makefile.shared
+++ openssl-0.9.8g/config
+++ openssl-0.9.8g/Makefile.org
+++ openssl-0.9.8g/openssl.ld
+++ openssl-0.9.8g/debian/libcrypto0.9.8-udeb.dirs
+++ openssl-0.9.8g/VMS/VMSify-conf.pl
+++ openssl-0.9.8g/Netware/do_tests.pl
+++ openssl-0.9.8g/apps/s_time.c
+++ openssl-0.9.8g/apps/CA.sh
+++ openssl-0.9.8g/apps/CA.pl.in
+++ openssl-0.9.8g/apps/speed.c
+++ openssl-0.9.8g/apps/CA.pl
+++ openssl-0.9.8g/os2/backwardify.pl
+++ openssl-0.9.8g/engines/Makefile
+++ openssl-0.9.8g/engines/openssl.ld
+++ openssl-0.9.8g/tools/c_rehash
+++ openssl-0.9.8g/tools/c_rehash.in
+++ openssl-0.9.8g/ssl/t1_lib.c
+++ openssl-0.9.8g/ms/uplink.pl
+++ openssl-0.9.8g/demos/tunala/configure.in
+++ openssl-0.9.8g/doc/Makefile
+++ openssl-0.9.8g/doc/apps/c_rehash.pod
+++ openssl-0.9.8g/crypto/Makefile
+++ openssl-0.9.8g/crypto/x86cpuid.pl
+++ openssl-0.9.8g/crypto/opensslconf.h
+++ openssl-0.9.8g/crypto/x86_64cpuid.pl
+++ openssl-0.9.8g/crypto/md5/asm/md5-x86_64.pl
+++ openssl-0.9.8g/crypto/md5/asm/md5-sparcv9.S
+++ openssl-0.9.8g/crypto/sha/sha.h
+++ openssl-0.9.8g/crypto/sha/asm/sha1-ia64.pl
+++ openssl-0.9.8g/crypto/sha/asm/sha512-sse2.pl
+++ openssl-0.9.8g/crypto/sha/asm/sha512-ia64.pl
+++ openssl-0.9.8g/crypto/rand/md_rand.c
+++ openssl-0.9.8g/crypto/des/asm/desboth.pl
+++ openssl-0.9.8g/crypto/rc4/asm/rc4-x86_64.pl
+++ openssl-0.9.8g/crypto/perlasm/x86unix.pl
+++ openssl-0.9.8g/crypto/perlasm/cbc.pl
+++ openssl-0.9.8g/crypto/perlasm/x86_64-xlate.pl
+++ openssl-0.9.8g/crypto/pkcs7/pk7_mime.c
+++ openssl-0.9.8g/crypto/bn/asm/ppc.pl
+++ openssl-0.9.8g/crypto/aes/asm/aes-586.pl
+++ openssl-0.9.8g/crypto/asn1/charmap.pl
+++ openssl-0.9.8g/util/mkerr.pl
+++ openssl-0.9.8g/util/clean-depend.pl
+++ openssl-0.9.8g/util/extract-names.pl
+++ openssl-0.9.8g/util/pod2man.pl
+++ openssl-0.9.8g/util/mkstack.pl
+++ openssl-0.9.8g/util/selftest.pl
+++ openssl-0.9.8g/util/extract-section.pl
+++ openssl-0.9.8g/util/mkdef.pl
+++ openssl-0.9.8g/util/pl/netware.pl

Gruss
Bernd


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

deactivated native samba support in mc

[Patrick Winnertz]

Hey,

I've disabled after thinking a long time over this issue, the native samba 
support in mc. I hope that not so much people used that.

My reasons for disabling this feature is that this was based on a 
statically linked in samba lib from 1996... without any updates to it.
Since the features of samba changed since 1996 a lot it is clear that there 
were quite many issues with that feature.
See #451964  & #432324 for example. 

Furthermore I had some fears that his lib might contains some security 
bugs... so deactivating this feature would solve several problems.

If there is anybody who is interested in this feature please mail me, since 
upstream is pretty dead there is no great chance that he will fix this in 
a reasonable time. So if someone have good C skills and would like to help 
to port mc to link dynamically against libsmbclient please start working 
on it ;-)

Greetings
Winnie

-- 
 .''`.   Patrick Winnertz <[EMAIL PROTECTED]>
:  :' :  GNU/Linux Debian Developer
`. `'`   http://www.der-winnie.de http://people.skolelinux.org/~winnie
  `-  Debian - when you have better things to do than fixing systems
  Spamtrap: [EMAIL PROTECTED]


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Sun, 18 May 2008, Raphael Hertzog wrote:


With the 3.0 quilt format, dpkg-source -x will list each patch that it
applies (and since the debian directory is stored in a tarball and not in
a .diff, it always means _real_ changes contrary to the v1 format where we
always see the line "applying diff.gz").


Well, I don't know anything about quilt 3.0 and I was actually talking about
packages that do *not* using quilt or any other patch system, but just "hide"
some patches in the diff.gz.  I would like to see dpkg-source -x make some
noise about this fact - actually this idea came to me when you said that your
normally overlook those patches.  So we might nead this feature for all the
packages that *do* *not* use quilt.

And I aczually do not really care whether it is implemented using grep or

   lsdiff -z -x '*/debian/*' *.diff.gz 
or whatever - as long as I get a list of patched files brought up to my

intention immediately.

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Mailing lsit code of conduct, again

[Pierre Habouzit]

On Sun, May 18, 2008 at 07:03:39PM +, Clint Adams wrote:
> I am posting far too much in this thread.

  Do you say that because you got too many Cc's ?

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


pgpfwZXzHQDqV.pgp
Description: PGP signature

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

On Sun, 2008-05-18 at 21:40 +0200, Lucas Nussbaum wrote:
> (you can skip to the end for a summary of what I think we agree on)
> > >  The only
> > > thing that he would additionaly get is a notification when the change is
> > > applied upstream and fixed in Debian by a new upstream version.
> > 
> > Don echoed that sentiment by offering just to not archive bugs tagged
> > with 'divergence'. I would agree that the submitter doesn't really need
> > to know when Fixed: is replaced by Closes: - it is a maintainer issue
> > but one that does need to be publicly visible.
> 
> OK, but then you have to remove the divergence tag when the change is
> integrated upstream -- not just close the bug. This would be still be a
> manual process, right?

I suppose bts-link could be utilised - after all, the bug tagged
'divergence' should also be forwarded so it can be updated from there.
However, it might be just as well that it is manual. As I mentioned
before, removing a tag can be done by anyone so it's not a big issue.

> Users can choose whichever bug tracker they prefer, but DDs should
> always report patches that should be reported upstream to the upstream
> BTS. It would be nonsense if DDs started reporting patches for upstream
> only to the Debian BTS.

ok.

> OK, I think that we generally agree. Let's summarize again to make sure:
> 
> 1) Encourage maintainers to use patches in debian/patches. Define some
> useful pseudo-headers.

Definitely.

> 2) Build patches.debian.org, fully automated export of Debian patches.

Yes.

> 3) For patches that need to be sent upstream, a pseudo header in the
> patch indicates where the submission of the patch to upstream is
> discussed.
> -> If upstream has a BTS, the discussion happens on upstream's
>BTS, and the pseudo header in the patch points there.
> -> If upstream doesn't have a BTS, a bug is created/reused on the Debian
>BTS, and the discussion with upstream is Cced with this bug. The
>pseudo header in the patch points to that Debian BTS bug.
>Additionally, this bug is tagged +divergence to indicate what it's
>about.
>Also, bugs tagged divergence are not archived. So even after the bug
>has been closed in Debian, the bug can continue to be used to discuss
>the patch with upstream.
> 
> Sounds good?

Yes, it does.

It could also be possible to add some automation because as the
pseudo-header is in the patch, scripts could check that the list of
pseudo-headers with a bugs.d.o URL matches the list of diversion bugs
obtained via SOAP. Lintian doesn't currently do SOAP queries of the BTS
but a QA script should be relatively easy to create. Maybe bts-link
could be drafted in to provide some leverage over pseudo-headers mapping
to an upstream bug tracker.

Lintian could check that the pseudo-header exists.

-- 
Neil Williams <[EMAIL PROTECTED]>


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

Re: Mailing lsit code of conduct, again

[Martin Langhoff]

On Mon, May 19, 2008 at 5:31 AM, Frans Pop <[EMAIL PROTECTED]> wrote:
> Clint Adams wrote:
>> On Sun, May 18, 2008 at 06:35:20PM +0200, Frans Pop wrote:
>>> Wrong. You neglected to request to be CCed.
>>
>> My M-F-T was clearly a request to be Cc'd.
>
> Which possibly only goes to show how broken that header is. you could have
> noted the request to be CCed in the body of the mail (which is what I
> always do when posting to lists I'm not subscribed to).
>
> However, in this case I'll take the blame. I happen to read that list
> through a news reader and did not allow for M-F-T headers. I will make sure
> I do check for M-F-T in the future. My apologies.

Apologies in advance for lengthening this less-than-useful thread.

In this modern age of a mailman that lets subscribers configure their
subscription to avoid duplicates, and procmail filters that help do
the same at the client end (and some mail clients that have similar
abilities of their own - ie gmail)... why does this funny and akward
rule of debian lists persist?

Frankly, I want to just use reply/reply-all normally on any of the
many mailing lists I am sub'd to, and if a few people in the thread
are CC'd, I don't think it is a reasonable expectation that I have to
decide whether each one of them wants or not the CC.

A funny side-effect of this is that I've seen subscribers of debian
lists get in trouble in non debian lists because they use funny
headers in lists with differnt expectations

cheers,



m
-- 
 [EMAIL PROTECTED]
 [EMAIL PROTECTED] -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff


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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

(you can skip to the end for a summary of what I think we agree on)

On 18/05/08 at 19:49 +0100, Neil Williams wrote:
> > > I still like the two-stage closure option because sometimes we just need
> > > to upload a fix before an upstream release can be made and the bug
> > > submitter should know that the bug has been fixed using a divergence
> > > whilst still waiting for upstream.
> > 
> > OK, but is that really a problem? Currently, the submitter will receive
> > the close message, can read the changelog, and see if his bug was closed
> > in a new upstream release, or by a Debian-specific change.
> 
> My point is that the bug submitter should get notification as soon as
> the package is fixed in Debian. It is the maintainer who needs to know
> about matters after that. It doesn't matter what the submitter receives
> as long as it is sent asap. Just using 'divergence' without closing the
> Debian side of the bug would leave the bug open but with different tags.
> 
> Don's idea of simply not archiving such bugs (and therefore using
> Closes: at the first opportunity) isn't quite what I was thinking but it
> would work. Just might not be as easy to scan for those bugs in the bts
> webpages.
> 
> >  The only
> > thing that he would additionaly get is a notification when the change is
> > applied upstream and fixed in Debian by a new upstream version.
> 
> Don echoed that sentiment by offering just to not archive bugs tagged
> with 'divergence'. I would agree that the submitter doesn't really need
> to know when Fixed: is replaced by Closes: - it is a maintainer issue
> but one that does need to be publicly visible.

OK, but then you have to remove the divergence tag when the change is
integrated upstream -- not just close the bug. This would be still be a
manual process, right?

> > > OK, so problem 1:
> > > Q: How to improve Debian forwarding patches to upstream using upstream
> > > bug trackers?
> > > A: Leave the burden on the DD to handle multiple logins to multiple bug
> > > trackers but make life easier in the BTS so that everyone can read the
> > > patch without needing a login. This, IMHO, is met by the Fixed|Closed
> > > two stage closure idea.
> > 
> > Can you point to some upstream BTS that require you to login to read
> > patches? I was under the impression that most BTS give you read access
> > without login.
> 
> The DD doesn't just need to read patches, he needs to login and post new
> patches and new comments, but yes, I got that bit confused. What I meant
> was upstreams where the "bug tracker" is actually private email or
> similar. (Some do only offer the login window and tuck a little
> "anonymous" box in the top corner.)

When upstream has no good way to track patches, I'm perfectly fine with
the Debian maintainer choosing that the right way to track patches
submitted upstream is to open bugs in the Debian BTS for each of those
patches.  That's a sensible thing to do. What I strongly oppose is
asking all maintainers to do this, even when upstream has a good way to
track patches/bugs.

> I should have stuck with the original paragraph:
> 
> > I want Debian to go to upstream (as now) and let DD's suffer the hassle
> > of divergent upstream bug trackers so as to not force that workload on
> > our users or members of different upstream teams trying to work out why
> > their code is suffering from a buggy -dev package. If appropriate, feed
> > that info into the BTS.
> Message-Id: <[EMAIL PROTECTED]>
> 
> > I fear that this will turn into DDs thinking that it's enough to file a
> > bug in the BTS to consider a bug as "forwarded upstream".  While it's
> > obviously not the case.
> 
> I'm not sure how that follows but I don't want that either. (I suggested
> that Fixed would only work if Forwarded was set.)

If you enforce the "file a bug in the Debian BTS for each patch you want
to see integrated upstream", it might end up sounding like "filing bugs
in the Debian BTS is sufficient". A bit like the "if it's lintian-clean,
then it's clean" problem.

> > If my upstream BTS doesn't require login to read the bug, are there
> > other reasons (beside the "submitter want to be notified when the patch
> > is applied upstream" one -- see question above) for duplicating the bug
> > discussion into the BTS?
> 
> Similar reason to why you added that CC - because when dealing with a
> variety of inputs, it is helpful to get an overview of the changes
> across all packages. I'm not sure where you see duplication:
> 
> > Use tags in the BTS and custom webpages to let others know which bugs we
> > fixed with these patches. If the upstream tracker isn't public, file the
> > patches in the BTS too so that everyone can find it. 

If the discussion happens publicly both in upstream's BTS and in
Debian's BTS, then there's a clear duplication problem (dropped Ccs,
lost mails, etc). If the discussion happens via private emails with
upstream, Cced with the Debian BTS, then it's fine.

> and
> 
> > Users can choose wh

Re: Mailing lsit code of conduct, again

[Clint Adams]

On Sun, May 18, 2008 at 07:31:37PM +0200, Frans Pop wrote:
> I agree it has been controversial. However, "wrong" is just your opinion.
> My opinion is that it is "right" for Debian's lists.

My preference for a default is to suggest that everyone always Cc unless
otherwise requested.  Note that I did not mail a patch that codifies
this, because legislating something like that when there is clearly
no consensus about the right thing to do would lead to all sorts of
strife.  Do you see where I'm going with this?

What I proposed instead amounted to a single grammar change, and the
removal of some controversial, sometimes-flouted, and, as Russ points
out, unenforced bits of the CoC upon which the project never actually
agreed.  Such a change would introduce benefits: a certain group of
people would no longer have the option of using that webpage as a
"stick to beat people with"; the CoC would gain a smidge more
legitimacy since a higher percentage of it would be less controversial;
fewer people might be encouraged to omit Cc's in spite of my M-F-T.

I am posting far too much in this thread.


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

Re: Tracking divergence from upstream as a bug

[Neil Williams]

On Sun, 2008-05-18 at 18:51 +0100, Don Armstrong wrote:
> On Sun, 18 May 2008, Neil Williams wrote:
> > Yes - supported by the use of (Fixed: #1234) in
> > debian/changelog, .changes etc. and a revised interface for PTS and DDPO
> > to discriminate between Fixed and Closed bugs.
> 
> I could easily handle this by just not archiving bugs tagged
> divergence; when it's fixed upstream, you just untag it.
> 
> No need for complicated mucking about with the changelog parsers.

Hmmm, ok. Should be straightforward to create QA pages/scripts that can
check on bugs that might get missed.

Untagging is also something that can be done by anyone so it has the
advantage that more people can pick up such errors and fix them.

I've already started talking myself into circles (see my reply to Lucas)
so I think I'll quit while I'm ahead and go for that solution.
:-)


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

On Sun, 2008-05-18 at 19:39 +0200, Lucas Nussbaum wrote:
> (please don't remove Ccs. I added one for a reason)

(Not sure you want d-devel and direct since I know you are subscribed,
so removed that one. :-))

> > > That sounds logical to have both:
> > > - they know that distro devs are not perfect and sometimes don't forward
> > >   simple patches
> > > - they want to know which patches are actually used (and widely tested),
> > >   because that make them better candidates for integration upstream
> > 
> > > But maybe I'm just misunderstanding upstreams' needs?
> > 
> > There's no accounting for the variety in upstream teams - I don't know
> > many that want the second option but I can see that some will probably
> > want it that way, if only because of an MIA DD.
> 
> Well, Vincent Untz (GNOME release manager) explicitely said that he
> needed that in [1] and [2]. But it's true that more input from other
> upstreams would be interesting.
> [1] http://lists.debian.org/debian-devel/2008/05/msg00496.html
> [2] http://lists.debian.org/debian-devel/2008/05/msg00509.html

I guess it's because that is an over-arching upstream and has to deal
with a variety of GNOME teams and Debian DD's. 

It's kind-of how I expect to use divergence for GPE packages and
possibly Emdebian (treating Debian as our upstream).

> But my main motivation for providing something like patches.d.o is that,
> after the openssl debacle, many people have the impression that we are
> patching a lot of useless stuff, and that we don't know what we are
> doing. A good answer to that would be to expose all our patches in
> something like patches.d.o. (sort of "we don't hide our problems"
> applied to packages)
> 
> Also, it's really cheap to do: it can be fully automated.

If you're sure that all that online disc space really is cheap, it's
fine by me. Maybe working with embedded devices has obscured the real
cost of online space but I can't help but complain about every extra Mb.
:-)
 
> > I still like the two-stage closure option because sometimes we just need
> > to upload a fix before an upstream release can be made and the bug
> > submitter should know that the bug has been fixed using a divergence
> > whilst still waiting for upstream.
> 
> OK, but is that really a problem? Currently, the submitter will receive
> the close message, can read the changelog, and see if his bug was closed
> in a new upstream release, or by a Debian-specific change.

My point is that the bug submitter should get notification as soon as
the package is fixed in Debian. It is the maintainer who needs to know
about matters after that. It doesn't matter what the submitter receives
as long as it is sent asap. Just using 'divergence' without closing the
Debian side of the bug would leave the bug open but with different tags.

Don's idea of simply not archiving such bugs (and therefore using
Closes: at the first opportunity) isn't quite what I was thinking but it
would work. Just might not be as easy to scan for those bugs in the bts
webpages.

>  The only
> thing that he would additionaly get is a notification when the change is
> applied upstream and fixed in Debian by a new upstream version.

Don echoed that sentiment by offering just to not archive bugs tagged
with 'divergence'. I would agree that the submitter doesn't really need
to know when Fixed: is replaced by Closes: - it is a maintainer issue
but one that does need to be publicly visible.
 
> > OK, so problem 1:
> > Q: How to improve Debian forwarding patches to upstream using upstream
> > bug trackers?
> > A: Leave the burden on the DD to handle multiple logins to multiple bug
> > trackers but make life easier in the BTS so that everyone can read the
> > patch without needing a login. This, IMHO, is met by the Fixed|Closed
> > two stage closure idea.
> 
> Can you point to some upstream BTS that require you to login to read
> patches? I was under the impression that most BTS give you read access
> without login.

The DD doesn't just need to read patches, he needs to login and post new
patches and new comments, but yes, I got that bit confused. What I meant
was upstreams where the "bug tracker" is actually private email or
similar. (Some do only offer the login window and tuck a little
"anonymous" box in the top corner.)

I should have stuck with the original paragraph:

> I want Debian to go to upstream (as now) and let DD's suffer the hassle
> of divergent upstream bug trackers so as to not force that workload on
> our users or members of different upstream teams trying to work out why
> their code is suffering from a buggy -dev package. If appropriate, feed
> that info into the BTS.
Message-Id: <[EMAIL PROTECTED]>

> I fear that this will turn into DDs thinking that it's enough to file a
> bug in the BTS to consider a bug as "forwarded upstream".  While it's
> obviously not the case.

I'm not sure how that follows but I don't want that either. (I suggested
that Fixed would only work if Forwarded was set.

Re: Mailing lsit code of conduct, again

[Mark Brown]

On Sun, May 18, 2008 at 06:08:23PM +0200, Raphael Hertzog wrote:

> public list that end up in their main INBOX. If those can't make the
> effort to setup Mail-Followup-To, they should post less and not _more_
> just for the sake of complaining about the copies.

Of course, MFT brings up the whole "it's not a standard, why should I
follow it, my MUA never heard of it" thing...  You can't win.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Mailing lsit code of conduct, again

[Mark Brown]

On Sun, May 18, 2008 at 07:14:10AM -0700, Russ Allbery wrote:

> The solution to this problem is to fix the mailing list code of conduct to
> stop creating this expectation.  We don't enforce it anyway, and all this
> provision seems to do in practice is create these annoying arguments
> periodically.

In my experience it's helpful to have a convention - there always seems
to be some exchange of ideas on the issue but if there's a convention
then at least you can point at it and say "that's the way we do things
round here".

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: Tracking divergence from upstream as a bug

[Don Armstrong]

On Sun, 18 May 2008, Neil Williams wrote:
> Yes - supported by the use of (Fixed: #1234) in
> debian/changelog, .changes etc. and a revised interface for PTS and DDPO
> to discriminate between Fixed and Closed bugs.

I could easily handle this by just not archiving bugs tagged
divergence; when it's fixed upstream, you just untag it.

No need for complicated mucking about with the changelog parsers.


Don Armstrong

-- 
There is no such thing as "social gambling." Either you are there to
cut the other bloke's heart out and eat it--or you're a sucker. If you
don't like this choice--don't gamble.
 -- Robert Heinlein _Time Enough For Love_ p250

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


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

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 05:19:28PM +, Niko Tyni wrote:
> On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:
> 
> >   1/ check bts-link is aware of your upstream BTS (means that there is a
> >  small configuration step to do once and for all) and that the kind
> >  of BTS it uses it supported. RT isn't. Launchpad should be
> 
> Uh, rt.cpan.org seems to work fine with bts-link, and it's already in
> btslink.cfg :)
> 
>  
> http://git.debian.org/?p=bts-link/bts-link.git;a=blob_plain;f=btslink.cfg;hb=HEAD

  Yeah I didn't remember about it, and it's probably because it's code
that is 2 yo, and that I didn't write myself to begin with :)

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


pgpC976niOmHq.pgp
Description: PGP signature

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

(please don't remove Ccs. I added one for a reason)

On 18/05/08 at 18:02 +0100, Neil Williams wrote:
> On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote:
> > > > The problem I am interested in solving is:
> > > >   It is currently difficult for people not involved in Debian
> > > >   development (upstream, other distros, users) to know which patches we
> > > >   applied, the reason for the patch, and whether they should be
> > > >   interested in that patch or not.
> > > 
> > > In that case, the fault lies in Debian for not using Forwarded properly.
> > > IMHO we should be going out of our way to communicate with upstream
> > > using the systems preferred BY upstream, not trying to devise a new one.
> > > 
> > > I know it's a PITA using bugzilla and a gazillion different logins but
> > > that is part of the workload.
> > 
> > I think that upstreams would like two different things:
> > - that distros forward patches to their BTS
> > - that distros provide an automated, simple way to see what they patched
> 
> ok - so two problems, not one.

Yes.

> > That sounds logical to have both:
> > - they know that distro devs are not perfect and sometimes don't forward
> >   simple patches
> > - they want to know which patches are actually used (and widely tested),
> >   because that make them better candidates for integration upstream
> 
> > But maybe I'm just misunderstanding upstreams' needs?
> 
> There's no accounting for the variety in upstream teams - I don't know
> many that want the second option but I can see that some will probably
> want it that way, if only because of an MIA DD.

Well, Vincent Untz (GNOME release manager) explicitely said that he
needed that in [1] and [2]. But it's true that more input from other
upstreams would be interesting.
[1] http://lists.debian.org/debian-devel/2008/05/msg00496.html
[2] http://lists.debian.org/debian-devel/2008/05/msg00509.html

But my main motivation for providing something like patches.d.o is that,
after the openssl debacle, many people have the impression that we are
patching a lot of useless stuff, and that we don't know what we are
doing. A good answer to that would be to expose all our patches in
something like patches.d.o. (sort of "we don't hide our problems"
applied to packages)

Also, it's really cheap to do: it can be fully automated.

> > > > I thought that the problem of tracking changes for Debian developers was
> > > > already solved by using a VCS and advertising it thought Vcs-*?
> > > 
> > > No, it isn't because Debian developers still need to track where Debian
> > > patches have diverged from upstream due to delays in upstream
> > > development. Vcs does nothing for that, nothing whatsoever (and I
> > > consider it a nonsense to include the entire upstream codebase in our
> > > RCS).
> > 
> > If we have a Formarded-upstream: field in patches.d.o (pointing to the
> > upstream bug for a patch), it would be easy to modify bts-link and
> > automatically monitor those upstream bugs.
> 
> I still like the two-stage closure option because sometimes we just need
> to upload a fix before an upstream release can be made and the bug
> submitter should know that the bug has been fixed using a divergence
> whilst still waiting for upstream.

OK, but is that really a problem? Currently, the submitter will receive
the close message, can read the changelog, and see if his bug was closed
in a new upstream release, or by a Debian-specific change. The only
thing that he would additionaly get is a notification when the change is
applied upstream and fixed in Debian by a new upstream version.

Do we really want to "solve" that? Have submitters been asking for that?

> > Yes. One problem with this discussion is that we are discussing:
> >What can/can't we do by using, abusing and modifying our current
> >infrastructure (i.e the BTS)?
> > Instead of discussing:
> >What is the real problem that we are trying to solve? What needs
> >to be done to fix that problem? (what features/requirements are
> >needed in a candidate solution?)
> > The discussion is polluted by technical details about BTS things, and
> > this hides the real issues.
> 
> OK, so problem 1:
> Q: How to improve Debian forwarding patches to upstream using upstream
> bug trackers?
> A: Leave the burden on the DD to handle multiple logins to multiple bug
> trackers but make life easier in the BTS so that everyone can read the
> patch without needing a login. This, IMHO, is met by the Fixed|Closed
> two stage closure idea.

Can you point to some upstream BTS that require you to login to read
patches? I was under the impression that most BTS give you read access
without login.

I fear that this will turn into DDs thinking that it's enough to file a
bug in the BTS to consider a bug as "forwarded upstream".  While it's
obviously not the case.

If my upstream BTS doesn't require login to read the bug, are there
other reasons (beside the "submitter want to be notified when the patch
is

Re: divergence from upstream as a bug

[Niko Tyni]

On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:

>   1/ check bts-link is aware of your upstream BTS (means that there is a
>  small configuration step to do once and for all) and that the kind
>  of BTS it uses it supported. RT isn't. Launchpad should be

Uh, rt.cpan.org seems to work fine with bts-link, and it's already in
btslink.cfg :)

 
http://git.debian.org/?p=bts-link/bts-link.git;a=blob_plain;f=btslink.cfg;hb=HEAD
-- 
Niko Tyni   [EMAIL PROTECTED]


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

Re: divergence from upstream as a bug

[Michael Banck]

On Sat, May 17, 2008 at 06:57:54PM -0400, Joey Hess wrote:
> In that case, it really doesn't matter whether the list of Debian
> patches is on patches.debian.org, or on a page in the BTS. If upstream
> wants to, they can look at them either way.

Sure it matters, for example for other Debian maintainers to easily look
at or (more importantly) for other distribution packagers to look at.


Michael


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

Re: Mailing lsit code of conduct, again

[Frans Pop]

Clint Adams wrote:
> On Sun, May 18, 2008 at 06:35:20PM +0200, Frans Pop wrote:
>> Wrong. You neglected to request to be CCed.
> 
> My M-F-T was clearly a request to be Cc'd.

Which possibly only goes to show how broken that header is. you could have 
noted the request to be CCed in the body of the mail (which is what I 
always do when posting to lists I'm not subscribed to).

However, in this case I'll take the blame. I happen to read that list 
through a news reader and did not allow for M-F-T headers. I will make sure 
I do check for M-F-T in the future. My apologies.
 
>> That's bullshit. The CoC has been in place and unchanged for years.
>> Please
> 
> Yes, and it has been controversial and WRONG for years.

I agree it has been controversial. However, "wrong" is just your opinion.
My opinion is that it is "right" for Debian's lists.

> There have only been people trying to tell other people to do things that
> make sense because other people are apparently too stubborn or inept to
> use their software properly.

Right, but that argument works both ways. You are obviously to stubborn and 
inept to use the "reply-to-list" function of your software.

I personally use kmail [1], which unfortunately does not support setting 
M-F-T. However, it does a great job of recognizing list mail and correctly 
doing reply-to-list automatically.

Cheers,
FJP

[1] Note that I did _not_ use kmail for the post to d-www. If I had, it 
would have respected the M-F-T header.


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

Re: divergence from upstream as a bug

[Bastian Blank]

On Sun, May 18, 2008 at 07:53:39PM +0300, George Danchev wrote:
> On Sunday 18 May 2008, Russ Allbery wrote:
> > Isn't this already the case in practice?  Do you really see many Debian
> > packages that have modified *.orig.tar.gz tarballs?  And if so, have you
> > filed bugs?
> Sorry for the delay, but now I saw that Don Armstrong also asked such a 
> question, but I forgot to reply to him while having a lunch yesterday. While 
> digging in debian source packages I have seen several such in the past, but I 
> only remember dist now -- compare:
> http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
> http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz

| $ wget http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
| [...]
| $ wget http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz
| [...]
| $ md5sum dist*
| 7417436d2d0cbe9322d7503041c2e2df  [EMAIL PROTECTED]
| b959d34e40b01303e98a6b85255dd92d  dist_3.70.orig.tar.gz
| $ mkdir 1 2
| $ tar -C 1 -xzf [EMAIL PROTECTED]
| $ tar -C 2 -xzf dist_3.70.orig.tar.gz 
| $ diff -urN 1/[EMAIL PROTECTED] 2/dist-3.70.orig | diffstat
|  0 files changed

Your point being?

Bastian

-- 
What kind of love is that?  Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, "Metamorphosis",
   stardate 3219.8


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

Re: RFS: figtoipe / difficulties with Replaces:

[Steve Greenland]

On 17-May-08, 11:51 (CDT), Daniel Burrows <[EMAIL PROTECTED]> wrote: 
>   Using Replaces on its own seems bizarre to me.  OTOH, some packages do
> this; e.g., xfce4 Replaces xfce4-dev without conflicting with it. [0]

It's not bizarre. That's how you move files from one package to another.

It would be nifty if you could explicitly list the files being Replaced,
to avoid accidents, but I suspect there are more important things to be
done.

Steve
-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

On Sun, 2008-05-18 at 18:22 +0200, Lucas Nussbaum wrote:
> > > The problem I am interested in solving is:
> > >   It is currently difficult for people not involved in Debian
> > >   development (upstream, other distros, users) to know which patches we
> > >   applied, the reason for the patch, and whether they should be
> > >   interested in that patch or not.
> > 
> > In that case, the fault lies in Debian for not using Forwarded properly.
> > IMHO we should be going out of our way to communicate with upstream
> > using the systems preferred BY upstream, not trying to devise a new one.
> > 
> > I know it's a PITA using bugzilla and a gazillion different logins but
> > that is part of the workload.
> 
> I think that upstreams would like two different things:
> - that distros forward patches to their BTS
> - that distros provide an automated, simple way to see what they patched

ok - so two problems, not one.

> That sounds logical to have both:
> - they know that distro devs are not perfect and sometimes don't forward
>   simple patches
> - they want to know which patches are actually used (and widely tested),
>   because that make them better candidates for integration upstream

> But maybe I'm just misunderstanding upstreams' needs?

There's no accounting for the variety in upstream teams - I don't know
many that want the second option but I can see that some will probably
want it that way, if only because of an MIA DD.

> > > I thought that the problem of tracking changes for Debian developers was
> > > already solved by using a VCS and advertising it thought Vcs-*?
> > 
> > No, it isn't because Debian developers still need to track where Debian
> > patches have diverged from upstream due to delays in upstream
> > development. Vcs does nothing for that, nothing whatsoever (and I
> > consider it a nonsense to include the entire upstream codebase in our
> > RCS).
> 
> If we have a Formarded-upstream: field in patches.d.o (pointing to the
> upstream bug for a patch), it would be easy to modify bts-link and
> automatically monitor those upstream bugs.

I still like the two-stage closure option because sometimes we just need
to upload a fix before an upstream release can be made and the bug
submitter should know that the bug has been fixed using a divergence
whilst still waiting for upstream.

> Yes. One problem with this discussion is that we are discussing:
>What can/can't we do by using, abusing and modifying our current
>infrastructure (i.e the BTS)?
> Instead of discussing:
>What is the real problem that we are trying to solve? What needs
>to be done to fix that problem? (what features/requirements are
>needed in a candidate solution?)
> The discussion is polluted by technical details about BTS things, and
> this hides the real issues.

OK, so problem 1:
Q: How to improve Debian forwarding patches to upstream using upstream
bug trackers?
A: Leave the burden on the DD to handle multiple logins to multiple bug
trackers but make life easier in the BTS so that everyone can read the
patch without needing a login. This, IMHO, is met by the Fixed|Closed
two stage closure idea.

Problem 2:
Q: How to help upstream find out from Debian which patches are actually
in use.
A: provide browsable patch files organised by source package (the
upstream source package name if it differs) - this sounds like the
patches.d.o idea.

I'll stick to Problem 1. :-)

I think you're right that there are two distinct problems - although I'm
still not convinced that Problem 2 is sufficiently common to require a
whole new bug/patch tracker.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: divergence from upstream as a bug

[George Danchev]

On Sunday 18 May 2008, Russ Allbery wrote:
--cut--

> Isn't this already the case in practice?  Do you really see many Debian
> packages that have modified *.orig.tar.gz tarballs?  And if so, have you
> filed bugs?

Sorry for the delay, but now I saw that Don Armstrong also asked such a 
question, but I forgot to reply to him while having a lunch yesterday. While 
digging in debian source packages I have seen several such in the past, but I 
only remember dist now -- compare:
http://search.cpan.org/CPAN/authors/id/R/RA/RAM/[EMAIL PROTECTED]
http://ftp.de.debian.org/debian/pool/main/d/dist/dist_3.70.orig.tar.gz

the rest might already been fixed now... And no, I didn't file a bugs against 
these, since I wanted to avoid an useless teaching of how to access the DD 
VCS, which I hate most.

> > And when extending the source packaging format, do not throw away the
> > good properties lightly. Git for example is no format to present
> > modifications. It is one to present history (which is almost but not
> > quite something completely different).

True.

> Git is quite good at presenting modifications if you know how to use it.

...and also true.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Mailing lsit code of conduct, again

[Clint Adams]

On Sun, May 18, 2008 at 06:35:20PM +0200, Frans Pop wrote:
> Wrong. You neglected to request to be CCed.

My M-F-T was clearly a request to be Cc'd.

> That's bullshit. The CoC has been in place and unchanged for years. Please 

Yes, and it has been controversial and WRONG for years.

> check the origin in the relevant VCS before making such claims.

Check the mailing list archives where I have stated that this is a bad idea.
I have opposed this, as an active member of this project, for longer
than that damn webpage has existed.  There has never been consensus.  There
have only been people trying to tell other people to do things that make sense
because other people are apparently too stubborn or inept to use their software
properly.

> It was also not committed by "random members of webwml", but by a Debian 
> Listmaster, i.e. by someone acting within his delegated authority.

If you think that such inanity is in the purview of Listmaster then
maybe we should "clarify" that instead.


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

Re: Mailing lsit code of conduct, again

[Frans Pop]

Clint Adams wrote:
> On Sun, May 18, 2008 at 05:21:52PM +0200, Frans Pop wrote:
>> Clint Adams sent a request to d-www to have the CoC changed and I have
>> replied with a strong NACK to that suggestion. If the CoC should be
> 
> You neglected to Cc me.

Wrong. You neglected to request to be CCed.
 
>> changed, it should be done after a proper discussion (on d-project
>> probably) and at least be done in coordination with the listmasters, not
>> as the result of an individual request by a random DD.
> 
> Since the code of conduct was published without discussion and a
> consensus within the project, and since modified by "random" DDs
> (depending on whether or not you consider the members of webwml random)
> without discussion or consensus within the project, I consider this a
> somewhat deceitful stance to take.

That's bullshit. The CoC has been in place and unchanged for years. Please 
check the origin in the relevant VCS before making such claims.
It was also not committed by "random members of webwml", but by a Debian 
Listmaster, i.e. by someone acting within his delegated authority.


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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

On 18/05/08 at 16:44 +0100, Neil Williams wrote:
> On Sun, 2008-05-18 at 17:05 +0200, Lucas Nussbaum wrote:
> > On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
> > > On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
> > > > But the problem we want to solve is making things easier for
> > > > upstreams.
> > > 
> > > Oh?  When I read the proposal, I understood that the problem we want to
> > > solve is about tracking changes we make to upstream.
> > 
> > Ah, interesting. We are not trying to solve the same problem, which
> > might explain why it's so hard to converge to a single solution.
> > 
> > The problem I am interested in solving is:
> >   It is currently difficult for people not involved in Debian
> >   development (upstream, other distros, users) to know which patches we
> >   applied, the reason for the patch, and whether they should be
> >   interested in that patch or not.
> 
> In that case, the fault lies in Debian for not using Forwarded properly.
> IMHO we should be going out of our way to communicate with upstream
> using the systems preferred BY upstream, not trying to devise a new one.
> 
> I know it's a PITA using bugzilla and a gazillion different logins but
> that is part of the workload.

I think that upstreams would like two different things:
- that distros forward patches to their BTS
- that distros provide an automated, simple way to see what they patched

That sounds logical to have both:
- they know that distro devs are not perfect and sometimes don't forward
  simple patches
- they want to know which patches are actually used (and widely tested),
  because that make them better candidates for integration upstream

But maybe I'm just misunderstanding upstreams' needs?

> > I thought that the problem of tracking changes for Debian developers was
> > already solved by using a VCS and advertising it thought Vcs-*?
> 
> No, it isn't because Debian developers still need to track where Debian
> patches have diverged from upstream due to delays in upstream
> development. Vcs does nothing for that, nothing whatsoever (and I
> consider it a nonsense to include the entire upstream codebase in our
> RCS).

If we have a Formarded-upstream: field in patches.d.o (pointing to the
upstream bug for a patch), it would be easy to modify bts-link and
automatically monitor those upstream bugs.

> Going back to the original message:
> http://lists.debian.org/debian-devel/2008/05/msg00536.html
> 
> "The BTS could be enhanced to allow opening a bug and forwarding it
> upstream in a single message. (IIRC currently, it takes two). This would
> allow a very simple workflow where a DD makes a change to a package,
> generates a patch, and sends it upstream while also recording the
> divergence in the BTS."

Yes. One problem with this discussion is that we are discussing:
   What can/can't we do by using, abusing and modifying our current
   infrastructure (i.e the BTS)?
Instead of discussing:
   What is the real problem that we are trying to solve? What needs
   to be done to fix that problem? (what features/requirements are
   needed in a candidate solution?)
The discussion is polluted by technical details about BTS things, and
this hides the real issues.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[George Danchev]

On Sunday 18 May 2008, Ben Finney wrote:
> George Danchev <[EMAIL PROTECTED]> writes:
> > You seem to forgot that people will actually work with the source
> > code and actual patches applied to it, not with a bunch of patches
> > floating in Debian BTS with not so clear/predictable state
> > (applied/unapplied/blamed/whatever). Such a service to can only be a
> > companion one, but not a reliable source of what has actually
> > changed, so consider it 'yet another place to DIG at'.
>
> Whether the patch is in the bug report or not, I don't see how that
> affects the proposal.
>
> > You wil have hard time teaching every upstream in Debian BTS (new)
> > tags and features, but they all already know how to deal well
> > prepared diffs from debian ftp mirrors.
>
> I've gone back to re-read the original proposal that starts this
> thread, and I can't see where everyone is reading "bureaucracy" and
> "extra workload" and "patches floating in the BTS" and "forcing
> upstream to read new BTS tags and features".

Although not mentioned in the first place these are all unavoidable 
consequences you will face at some point.

> The proposal, at its core, is merely about how to *classify*
> divergence from upstream source in a Debian package. There's nothing
> in the original message that requires patches to be duplicated, or
> upstream to get patches in a different way, or any of the other
> spectres people are raising here.
>
> It *suggests* that, with such a classification, certain workflows
> would be enabled naturally; but it doesn't *insist* on any of them.
>
> There's merely the proposal that we start *tracking* the divergence as
> a bug that needs resolution, like any other bug report in the BTS.

Such a classification may exists, but it is not a reliable source of code 
changes and their states which are actually deployed and are being in use.

> Am I wrong?

Well, not wrong, but you ask for too much load for almost no gain in solving 
the problem of exposure of debian changes for easy public peer review.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: Mailing lsit code of conduct, again

[Raphael Hertzog]

On Sun, 18 May 2008, Russ Allbery wrote:
> Ben Finney <[EMAIL PROTECTED]> writes:
> 
> > Your mail message individually to me is not wanted, and I have a
> > reasonable expectation through the mailing list code of conduct *and*
> > through my explicit request that you not send it.
> 
> The solution to this problem is to fix the mailing list code of conduct to
> stop creating this expectation.  We don't enforce it anyway, and all this
> provision seems to do in practice is create these annoying arguments
> periodically.

+1

I find that a significant proportion of people bothered by CC are those
who post too much and are probably annoyed by the number of replies to
public list that end up in their main INBOX. If those can't make the
effort to setup Mail-Followup-To, they should post less and not _more_
just for the sake of complaining about the copies.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Miriam Ruiz]

2008/5/18 Lucas Nussbaum <[EMAIL PROTECTED]>:
> The problem I am interested in solving is:
>  It is currently difficult for people not involved in Debian
>  development (upstream, other distros, users) to know which patches we
>  applied, the reason for the patch, and whether they should be
>  interested in that patch or not.

I agree there too. That's the problem I'm interested in solving too,
and I think that the proposed solution of having some pseudoheaders
added to the patches and an automated system to fetch those patches
and publish them automatically would be the best solution. This would
allow an easy inspection, not only from upstream, but also from people
from other distros, third parties and Debian collaborators.

Miry


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

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Neil Williams]

On Sun, 2008-05-18 at 17:05 +0200, Lucas Nussbaum wrote:
> On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
> > On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
> > > But the problem we want to solve is making things easier for
> > > upstreams.
> > 
> > Oh?  When I read the proposal, I understood that the problem we want to
> > solve is about tracking changes we make to upstream.
> 
> Ah, interesting. We are not trying to solve the same problem, which
> might explain why it's so hard to converge to a single solution.
> 
> The problem I am interested in solving is:
>   It is currently difficult for people not involved in Debian
>   development (upstream, other distros, users) to know which patches we
>   applied, the reason for the patch, and whether they should be
>   interested in that patch or not.

In that case, the fault lies in Debian for not using Forwarded properly.
IMHO we should be going out of our way to communicate with upstream
using the systems preferred BY upstream, not trying to devise a new one.

I know it's a PITA using bugzilla and a gazillion different logins but
that is part of the workload.

> I thought that the problem of tracking changes for Debian developers was
> already solved by using a VCS and advertising it thought Vcs-*?

No, it isn't because Debian developers still need to track where Debian
patches have diverged from upstream due to delays in upstream
development. Vcs does nothing for that, nothing whatsoever (and I
consider it a nonsense to include the entire upstream codebase in our
RCS).

Going back to the original message:
http://lists.debian.org/debian-devel/2008/05/msg00536.html

"The BTS could be enhanced to allow opening a bug and forwarding it
upstream in a single message. (IIRC currently, it takes two). This would
allow a very simple workflow where a DD makes a change to a package,
generates a patch, and sends it upstream while also recording the
divergence in the BTS."

To me, that reads as:
Use the upstream trackers to let upstream people know which patches we
applied and why. Use the BTS to track the Debian side of the divergence.

(Every divergence has two sides, otherwise there would be no difference
between Debian and upstream.)

I'd like to see that extended to include:
Use tags in the BTS and custom webpages to let others know which bugs we
fixed with these patches. If the upstream tracker isn't public, file the
patches in the BTS too so that everyone can find it. 

Then, when an upstream release finally includes the effect of the patch,
remove the patch from Debian and change Fixes: to Closes:.

What this proposal is about is identifying where Debian has diverged
from upstream so that it is easier for Debian to get back into sync with
upstream, not for upstream to get into sync with Debian. (Subtle
difference).

You appear to want upstream to come to us and for us to provide
one-tracker-to-rule-them-all to suit the needs of every upstream team
with a Debian package. That isn't going to happen.

I want Debian to go to upstream (as now) and let DD's suffer the hassle
of divergent upstream bug trackers so as to not force that workload on
our users or members of different upstream teams trying to work out why
their code is suffering from a buggy -dev package. If appropriate, feed
that info into the BTS.

Users can choose whichever bug tracker they prefer - the Debian BTS or
the upstream bug tracker for the project concerned. It is up to Debian
to ensure that proper use of Forwarded ensures that the same information
is available via (but not necessarily in) both. i.e. whichever entry
route is chosen, links are available to go to the relevant point where
the information is publicly available (without logins). Whether that
particular point is in the upstream bug tracker or the BTS is
inconsequential. The essential point is that it does exist and it is
linked from both entry points.

Upstream have chosen their bug tracker and whether we like it or not,
they are unlikely to migrate to one that Debian devises. That way lies
Launchpad. Yuck. As an upstream myself, I simply refuse to use that
horror. There again, I would also refuse to use the RH or Fedora bug
trackers or the OSX bug trackers or Fink or BSD or who knows what else.
As upstream, I've settled on the bug tracker I want to use upstream (and
in some cases it is the BTS) and I'm not going to go trawling round the
distros myself. I want the distros to come to me - as the BTS currently
does via Forwarded and the Fedora people do via their methods. I've
clearly documented the preferred bug tracker for each project on the
relevant website for that project.

The BTS cannot be all things to all people and I fail to see that Vcs
solves anything with regard to divergence (it only provides history, not
divergence).

With or without a README.source, Vcs does nothing to help me track which
patches that I have applied in Debian are actually diverging from
upstream and which have been applied. To find that o

Re: Mailing lsit code of conduct, again

[Pierre Habouzit]

On Sun, May 18, 2008 at 03:30:47PM +, Julien Cristau wrote:
> On Mon, May 19, 2008 at 01:26:29 +1000, Ben Finney wrote:
> 
> > Vincent Bernat <[EMAIL PROTECTED]> writes:
> > 
> > > Another solution  on your  side is to  use Mail-Followup-To.
> > > [...]
> > > Most mailers comply with this header.
> > 
> > That field is non-standard, and there are many MUAs that don't obey
> > it. It's not much of a solution if I can't expect it to be applied
> > consistently.
> 
> And many MUAs obey it.  So adding it has upsides (you will get less
> CCs), and no downsides.  Sounds like a win to me.


  Oh noes, this isn't the full proper way to do it, so rather do nothing
  than fixing it for half of the subscribers !


  I don't get why we're even discussing it again. I've not seen MJR post
here yet, to explain the evilness of MFT. Once he hace, we can let this
subpart of the thread rot in piece.

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


pgpEYDX1IP9G4.pgp
Description: PGP signature

Re: Mailing lsit code of conduct, again

[Clint Adams]

On Sun, May 18, 2008 at 05:21:52PM +0200, Frans Pop wrote:
> Clint Adams sent a request to d-www to have the CoC changed and I have 
> replied with a strong NACK to that suggestion. If the CoC should be 

You neglected to Cc me.

> changed, it should be done after a proper discussion (on d-project 
> probably) and at least be done in coordination with the listmasters, not as 
> the result of an individual request by a random DD.

Since the code of conduct was published without discussion and a
consensus within the project, and since modified by "random" DDs
(depending on whether or not you consider the members of webwml random)
without discussion or consensus within the project, I consider this a
somewhat deceitful stance to take.


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

Re: Mailing lsit code of conduct, again

[Julien Cristau]

On Mon, May 19, 2008 at 01:26:29 +1000, Ben Finney wrote:

> Vincent Bernat <[EMAIL PROTECTED]> writes:
> 
> > Another solution  on your  side is to  use Mail-Followup-To.
> > [...]
> > Most mailers comply with this header.
> 
> That field is non-standard, and there are many MUAs that don't obey
> it. It's not much of a solution if I can't expect it to be applied
> consistently.

And many MUAs obey it.  So adding it has upsides (you will get less
CCs), and no downsides.  Sounds like a win to me.

> > With gnus, this is really easy: just set message-subscribed-regexps
> > to a list of regexps of the list you are subscribed to.
> 
> That set is empty. I don't (nor do I wish to) receive messages in
> Debian list discussions via email.
> 
Srsly.  s/are subscribed to/don't want to be CCed on/

Cheers,
Julien


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

Re: Mailing lsit code of conduct, again

[Bernhard R. Link]

* Jose Luis Rivas Contreras <[EMAIL PROTECTED]> [080518 17:27]:
> I believe it could be easier that the mailing list software left the
> mailing list in the reply-header. The main issue is that when you hit
> "Reply" the only one who is left in the headers is actually who sent the
> email and if you hit "Reply All" obviously the author of the last email
> is listed too.
>
> There's a good reason why this haven't been done yet? Other mailing
> lists which I've been subscribed use this.

This makes it impossible for people to set their own reply-to to specify
where they want to get private answers sent to. And it makes pressing the
reply button sending mails to the list instead of replying privately,
which is very confusing...

Hochachtungsvoll,
Bernhard R. Link


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

Re: Mailing lsit code of conduct, again

[Jose Luis Rivas Contreras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Frans Pop wrote:
> Ben Finney wrote:
>> Russ Allbery <[EMAIL PROTECTED]> writes:
>>> We don't enforce it anyway, and all this provision seems to do in
>>> practice is create these annoying arguments periodically.
>> No, that's not all it does. It also has the significant effect that
>> discussions in these forums do not, in the main, generate needless
>> individual copies of messages in the participants's mailboxes. I, and
>> presumably the people who drafted the code of conduct, continue to
>> find that a very favourable outcome of this provision.
> 
> Fully agreed. I'd hate to see this dropped from the CoC.
> 
> Clint Adams sent a request to d-www to have the CoC changed and I have 
> replied with a strong NACK to that suggestion. If the CoC should be 
> changed, it should be done after a proper discussion (on d-project 
> probably) and at least be done in coordination with the listmasters, not as 
> the result of an individual request by a random DD.
> 
> Cheers,
> FJP

I believe it could be easier that the mailing list software left the
mailing list in the reply-header. The main issue is that when you hit
"Reply" the only one who is left in the headers is actually who sent the
email and if you hit "Reply All" obviously the author of the last email
is listed too.

There's a good reason why this haven't been done yet? Other mailing
lists which I've been subscribed use this.

Regards.
- --
Jose Luis Rivas. San Cristóbal, Venezuela. PGP: 0xCACAB118
http://ghostbar.ath.cx/{about,acerca} - http://debian.org.ve
`ghostbar' @ irc.debian.org/#debian-ve,#debian-devel-es
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIMErPOKCtW8rKsRgRAiieAKCaf3a+JQZhCNQP3/vdvhQpNBgMIACfUBLA
MpQ/DR0Ce5xQj2OZXi2wrkk=
=mtbj
-END PGP SIGNATURE-


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

Re: Mailing lsit code of conduct, again

[Ben Finney]

Vincent Bernat <[EMAIL PROTECTED]> writes:

> Another solution  on your  side is to  use Mail-Followup-To.
> [...]
> Most mailers comply with this header.

That field is non-standard, and there are many MUAs that don't obey
it. It's not much of a solution if I can't expect it to be applied
consistently.

Whereas with the ML CoC, I do have a reasonable expectation that most
people should follow it as a recommended best practice on the mailing
lists.

> With gnus, this is really easy: just set message-subscribed-regexps
> to a list of regexps of the list you are subscribed to.

That set is empty. I don't (nor do I wish to) receive messages in
Debian list discussions via email.

-- 
 \  Q: "I've heard that Linux causes cancer..."  Torvalds: "That's |
  `\   a filthy lie. Besides, it was only in rats and has not been |
_o__)reproduced in humans."  -- Linus Torvalds |
Ben Finney


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

Re: Mailing lsit code of conduct, again

[Frans Pop]

Ben Finney wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>> We don't enforce it anyway, and all this provision seems to do in
>> practice is create these annoying arguments periodically.
> 
> No, that's not all it does. It also has the significant effect that
> discussions in these forums do not, in the main, generate needless
> individual copies of messages in the participants's mailboxes. I, and
> presumably the people who drafted the code of conduct, continue to
> find that a very favourable outcome of this provision.

Fully agreed. I'd hate to see this dropped from the CoC.

Clint Adams sent a request to d-www to have the CoC changed and I have 
replied with a strong NACK to that suggestion. If the CoC should be 
changed, it should be done after a proper discussion (on d-project 
probably) and at least be done in coordination with the listmasters, not as 
the result of an individual request by a random DD.

Cheers,
FJP


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

Re: divergence from upstream as a bug

[Bernhard R. Link]

* Russ Allbery <[EMAIL PROTECTED]> [080518 16:50]:
> "Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> > I think adding a website which nicely formats those files (with
> > diffstats, and properly showing included patch files) would be a thing
> > that really helps all involved people. Not only upstreams forgotten or
> > vanished and reappeared. Not just other upstreams of forks. But also our
> > users to see at once what is changed.
> 
> Yup, and that's exactly the point of the discussion.  Joey's proposal
> about using the BTS is one set of tools that would generate such a web
> site, using the web site generation and tracking logic already present in
> the BTS to keep it maintained.  There are other possible ways of
> implementing such a web site, of course.

My point was especially as having an interface to those files. Writing
automatic things to feed those in the BTS will surely be more work than
having a page just parsing those file directly.
Having the maintainer put things there means more work on the maintainer
to spread stuff to more places. This punishes maintainers doing a good
work (updating a description or refreshing a patch needs multiple
actions) and creates a danger of things getting out of sync.

> Well, yes, obviously.  But I almost never see this outside of discussions
> like this where it's used as an example of what not to do.  In practice,
> nearly all code is under-commented and these sorts of problems are rare.

Useable code is almot always under-commented. When you force or educate
people to write comments, you regulary get comments worse than no
comments. It's just efford wasted in the wrong direction.

> Most code that's lived in the wild for a while will develop workarounds
> and obscure fixes to problems that were not at all obvious when it was
> originally written.  The details of those workarounds and fixes *need* to
> be written down, and as much as we might wish otherwise, there is no
> programming language in existence that makes such problems so clear that
> it can usually replace comments.

As I said, comments are best when there are little. Not comments are
best when there are none.

> The general rule of thumb used in many parts of GCC is that if you had to
> fix a bug in a piece of code, you probably should at least consider adding
> a comment making it clear why the code needs to be written the new way,
> since it's apparently not as obvious as you think (or the previous coder
> wouldn't have gotten it wrong).  That's correct more often than not in my
> experience.

And I totaly agree. But it has nothing to with my point.

> What does this have to do with your point?  As you say, that's not a
> modified version.  I think it's messy too, but it's not like we're putting
> Debian-specific modifications into the upstream *.orig.tar.gz (which as
> far as I'm concerned would be a fairly serious bug).

Well, the only thing suggesting this that strictly is devref.

> > And packages having a .tar.gz containing the real tar files and
> > sometimes even patches may be seldom and declining but to be stumbled
> > over regulary.
>
> Oh, this is still quite common, but I don't think that's an example of
> your point.  I think it's an awkward way of laying out the package, but
> usually the people who do this are even *more* careful about using
> pristine upstream tarballs -- that's exactly why they use this layout,
> which can do things like handle multiple upstream tarballs.  The tradeoff
> is that you have to unpack the *.orig.tar.gz to get the upstream tarball,
> but it is there.

You have to download the tarball, then find out where the patches are,
and how they are stored in there, and then how they are applied.
It adds quite a bit of complexity to answering the question "what
exectly is modified here".

> This isn't what I'm talking about.  Git is quite good at presenting
> *modifications* if you know how to use it.  Diffing topic branches is as
> easy and as reliable as looking at patches in debian/patches, and provides
> better tools for manipulating the results.  gitk shows a much better
> picture of the relationship between branches than one can get from a quilt
> series file, once you know what you're looking at.
>
> The drawback is that you have to know how to use Git.  I agree that this
> is a drawback and that expecting all upstreams to know how to use Git
> isn't reasonable.

I think to actually get this to work, and to get it to work in
non-trivial examples, you need quite a deep understanding of git.
At least I don't think that things like making one feature branch
depending on another after those already exist for some time sounds
that easy...

Hochachtungsvoll,
Bernhard R. Link


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

Re: How to handle Debian patches

[Mike Hommey]

On Sun, May 18, 2008 at 04:54:28PM +0200, Lucas Nussbaum wrote:
> On 18/05/08 at 16:48 +0200, Mike Hommey wrote:
> > On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
> > > On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
> > > > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
> > > > > On Sat, 17 May 2008, Joey Hess wrote:
> > > > > > Raphael Hertzog wrote:
> > > > > > > On Fri, 16 May 2008, Joey Hess wrote:
> > > > > > > > Coming up with a complex set of requirements that everyone has 
> > > > > > > > to follow
> > > > > > > > up front in their workflow[1] is not going to yeld the best 
> > > > > > > > results, and
> > > > > > > > I think that's my core reason for disliking Raphael's proposal. 
> > > > > > > > Now, if
> > > > > > > > you can come up with protocols/interfaces that can be used to
> > > > > > > > publish/communicate patches, that are managed/generated in 
> > > > > > > > whatever way
> > > > > > > > is most useful for the maintainer, that seems more likely to 
> > > > > > > > work.
> > > > > > > 
> > > > > > > Aren't "patch files in debian/patches/ with some headers" a 
> > > > > > > defined interface?
> > > > > > 
> > > > > > It's an interface, that if you stop there in defining it, means 
> > > > > > that I
> > > > > > have to check debian/patches/ into revision control, and bloat my
> > > > > > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 
> > > > > > source)
> > > > > > with them.
> > > > > 
> > > > > You don't have to check it in revision control, you just have to be 
> > > > > able
> > > > > to generate them from revision control. 
> > > > > 
> > > > > For .diff.gz, we already have tools to handle such files properly
> > > > > (without duplicating their content), it's called quilt or 
> > > > > simple-patch-sys
> > > > > of CDBS and you know it (but you don' like those).
> > > > > 
> > > > > For .git.tar.gz, if you have a tool to generate the patches, it would 
> > > > > be
> > > > > possible to hook it into the automated system that uploads patches to
> > > > > patches.debian.org. If that process is not the same across all
> > > > > .git.tar.gz, we can mandate a new debian/rules target that must 
> > > > > generate a
> > > > > debian/patches directory with all the patches.
> > > > 
> > > > Note how infrastructure needs would decrease considerably if packages
> > > > were mandated to use v3(quilt) format: patches.debian.org would be
> > > > ftp.debian.org and would just need nothing new (except for how source
> > > > packages are created)
> > > 
> > > No, you would need to untar the .debian.tar.gz file, so upstream can
> > > browse the patches.
> > 
> > And? You also have to untar the source .tar.gz from upstream web site...
> 
> It sounds better to be able to tell upstream:
>patch available from http://.../the_patch.diff fixes that.
> Rather than:
>patch the_patch.diff  in http://./foo.debian.tar.gz fixes that.

It sounds better to send the patch directly instead of telling upstream
to go to some random place to gather it.

Mike


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

Re: Mailing lsit code of conduct, again (was: divergence from upstream as a bug)

[Vincent Bernat]

OoO En  ce début d'après-midi ensoleillé  du dimanche 18  mai 2008, vers
15:56, Ben Finney <[EMAIL PROTECTED]> disait:

> Then please have it reduce your rudeness, and comply with explicit
> requests both from me and the ML CoC: stop sending unwanted mail
> messages when the messages are already sent to the list.

Hi Ben!

Another solution  on your  side is to  use Mail-Followup-To.  With gnus,
this is  really easy: just  set message-subscribed-regexps to a  list of
regexps of the list you are subscribed to. For example:

(setq message-subscribed-regexps '("@lists.debian.org"
   "@lists.alioth.debian.org"
   ))

Most mailers comply with this header.
-- 
GRAMMAR IS NOT A TIME OF WASTE
GRAMMAR IS NOT A TIME OF WASTE
GRAMMAR IS NOT A TIME OF WASTE
-+- Bart Simpson on chalkboard in episode AABF10


pgpNfC594wBfW.pgp
Description: PGP signature

Re: Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Pierre Habouzit]

On Sun, May 18, 2008 at 03:05:41PM +, Lucas Nussbaum wrote:
> On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
> > On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
> > > But the problem we want to solve is making things easier for
> > > upstreams.
> > 
> > Oh?  When I read the proposal, I understood that the problem we want to
> > solve is about tracking changes we make to upstream.
> 
> Ah, interesting. We are not trying to solve the same problem, which
> might explain why it's so hard to converge to a single solution.
> 
> The problem I am interested in solving is:
>   It is currently difficult for people not involved in Debian
>   development (upstream, other distros, users) to know which patches we
>   applied, the reason for the patch, and whether they should be
>   interested in that patch or not.
> 
> I thought that the problem of tracking changes for Debian developers was
> already solved by using a VCS and advertising it thought Vcs-*?

  Seconded, on both account. And if the exact details of how the VCS
handles those changes so that an outsider from the maintenance team can
contribute aren't obvious, I read about a README.source proposal that
seems to fill the gap nicely enough.

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


pgpWVxWM5PKxQ.pgp
Description: PGP signature

Re: How to handle Debian patches

[Lucas Nussbaum]

On 18/05/08 at 16:48 +0200, Mike Hommey wrote:
> On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
> > On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
> > > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
> > > > On Sat, 17 May 2008, Joey Hess wrote:
> > > > > Raphael Hertzog wrote:
> > > > > > On Fri, 16 May 2008, Joey Hess wrote:
> > > > > > > Coming up with a complex set of requirements that everyone has to 
> > > > > > > follow
> > > > > > > up front in their workflow[1] is not going to yeld the best 
> > > > > > > results, and
> > > > > > > I think that's my core reason for disliking Raphael's proposal. 
> > > > > > > Now, if
> > > > > > > you can come up with protocols/interfaces that can be used to
> > > > > > > publish/communicate patches, that are managed/generated in 
> > > > > > > whatever way
> > > > > > > is most useful for the maintainer, that seems more likely to work.
> > > > > > 
> > > > > > Aren't "patch files in debian/patches/ with some headers" a defined 
> > > > > > interface?
> > > > > 
> > > > > It's an interface, that if you stop there in defining it, means that I
> > > > > have to check debian/patches/ into revision control, and bloat my
> > > > > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 
> > > > > source)
> > > > > with them.
> > > > 
> > > > You don't have to check it in revision control, you just have to be able
> > > > to generate them from revision control. 
> > > > 
> > > > For .diff.gz, we already have tools to handle such files properly
> > > > (without duplicating their content), it's called quilt or 
> > > > simple-patch-sys
> > > > of CDBS and you know it (but you don' like those).
> > > > 
> > > > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > > > possible to hook it into the automated system that uploads patches to
> > > > patches.debian.org. If that process is not the same across all
> > > > .git.tar.gz, we can mandate a new debian/rules target that must 
> > > > generate a
> > > > debian/patches directory with all the patches.
> > > 
> > > Note how infrastructure needs would decrease considerably if packages
> > > were mandated to use v3(quilt) format: patches.debian.org would be
> > > ftp.debian.org and would just need nothing new (except for how source
> > > packages are created)
> > 
> > No, you would need to untar the .debian.tar.gz file, so upstream can
> > browse the patches.
> 
> And? You also have to untar the source .tar.gz from upstream web site...

It sounds better to be able to tell upstream:
   patch available from http://.../the_patch.diff fixes that.
Rather than:
   patch the_patch.diff  in http://./foo.debian.tar.gz fixes that.

No?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Which problem are we trying to solve? (Was: divergence from upstream as a bug)

[Lucas Nussbaum]

On 18/05/08 at 16:27 +0200, Bas Wijnen wrote:
> On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
> > But the problem we want to solve is making things easier for
> > upstreams.
> 
> Oh?  When I read the proposal, I understood that the problem we want to
> solve is about tracking changes we make to upstream.

Ah, interesting. We are not trying to solve the same problem, which
might explain why it's so hard to converge to a single solution.

The problem I am interested in solving is:
  It is currently difficult for people not involved in Debian
  development (upstream, other distros, users) to know which patches we
  applied, the reason for the patch, and whether they should be
  interested in that patch or not.

I thought that the problem of tracking changes for Debian developers was
already solved by using a VCS and advertising it thought Vcs-*?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The diff.gz contains all the changes including the debian dir. It is
> by no means obvious if there are patches in there or not.

I think reading a debian diff is the every day job of DD and DAs. And all of
them learned to search for +++ and ignore debian/.

However I do agree, extractin that to a web repository would be nice, to
make it linkable.

Gruss
Bernd


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

Re: divergence from upstream as a bug

[Bernhard R. Link]

* Goswin von Brederlow <[EMAIL PROTECTED]> [080518 16:09]:
> The diff.gz contains all the changes including the debian dir. It is
> by no means obvious if there are patches in there or not.

The limit to a single file is a real problem. But at least the
information has to be in there, and a .diff is usually tried to be
reasonably small.
Compared with some vcs information, where one has to first learn the
layout of that vcs, how branches are accessed via some webinterface
or (even harder) the actual tool. And so on...

> > Everything else is just overhead, as with comments in source
> > code: they are nice to have as long there little, but if there are too
> > many they are most of the time outdated, wrong or distracting.
>
> I find the why and how a patch came together important
> information. You compare this idea to comments in source code. I find
> those invaluable in understanding sources. So you actually made a
> point for the idea imho.

A comment in code that describes how something was implemented is not
really what you want. What you want is information about the current
code: How it works, what is important, what possible pitfalls there are.
Sometimes history can substitute for a bit of that information ("A
changed this in May 1998 to foo, B changed it back one week later because
that causes problems elsewhere" can subsitute for "note that this and
that other code needs this and that here").
Sometimes history is even part of this information (a la "This was once
so and so, be prepared that old data can have this").
History can be valuable information to track down when and how some problem
was introduced, but it is simply so much more information that one needs
an additional view for the important stuff.

> > Instead of adding new stuff, why not actually enforce and improve what
> > we have:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> Say goodby to all packages with +dfsg tarballs. This is just not practical.

Hey, I said "or pure subsets of those". For this the devref "suggests":
"should not contain any file that does not come from the upstream
author(s), or whose contents has been changed by you."

> The quilt extension is certainly a big improvement and will hopefully
> unify a lot of patch system using packages after lenny.

Though I guess there still needs to be a way to get such a patchset
constructed from non-quilt based work models, especially with things
centered on history. For example something to tag commits to git
repository, so some package creating tool can put changes belonging
together (like a modification and its updates for newer upstreams)
into a single .diff of such a series. (be that meta-tags in the
description, automatic utilisation of feature branches, extending the
git format or whatever git experts can think of or consider worthwile)
(or perhaps I'm just too stupid to find branch-hopping and manual
merging manually convenient enough to actually do).

Hochachtungsvoll,
Bernhard R. Link


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

Re: divergence from upstream as a bug

[Neil Williams]

On Sun, 2008-05-18 at 15:30 +0200, Goswin von Brederlow wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> >
> > 1 - User reports bug with a patch against upstream code
> > [open, patch]
> > 2 - maintainer forwards the patch upstream
> > [confirmed, patch, upstream, forwarded]
> > 3 - maintainer uploads divergent code with Fixed: #1234
> > [fixed, divergence, forwarded]
> > 4 - bts-link tags the report as upstream work on the issue
> >   [fixed, divergence, forwarded, fixed-upstream],
> > [fixed, divergence, forwarded, pending] etc.
> > 5 - maintainer closes bug in the relevant upstream release
> > [closed]
> > ... time passes ...
> > [archived]
> >
> > 'Tags: + upstream' would mean that the issue is an upstream issue but
> > without a Debian-specific patch (or fix), yet.
> > 'Tags: + divergence' would mean that the upstream issue has been fixed
> > in Debian with a patch in advance of an upstream fix.
> 
> 'fixed + upstream' would mean divergence. No need for a new tag actually.

Hmm, that's interesting. Good idea.

This would mean a relatively simple change to implement the entire
proposal:

[EMAIL PROTECTED] | (Fixes: #nnn)
marks the bug as fixed by a patch added by Debian and
awaiting a new release upstream to be finally closed. 
nnn-fixed is ignored if the upstream tag is not already
set. Bugs can be fixed in the changelog of an upload using
(Fixes: #1234) in a similar manner to (Closes: #1234). The
principle usage of "fixed" is to denote points at which 
Debian diverges from upstream. Filenames of patch files must 
be clearly identified when using (Fixes: #1234) in the
changelog.

Possibly add:
"Fixed bugs must also be tagged Forwarded as well as just
upstream."

or alternatively, 
"Forwarded is equivalent to upstream and one or both tags must
be used for Fixed to work."

Probably also add:
"Fixed bugs must be tagged "patch" for Fixed to work."

Also add: 
"The maintainer may choose not to post the patch to the BTS when
using Fixes: as long as the upstream bug tracker makes all
patches publicly visible without requiring passwords or
authentication."

Lintian could check that the specified patch actually exists and use
that to output a warning if the patch was removed (due to the changes
already being present in the upstream). The other checks implemented in
debchange and in bugs.debian.org.

The requirement for a filename in debian/patches is so that it is easier
to track the point at which Fixes: needs to become Closes:. I suppose it
might be possible to parse the output of lsdiff -z *.diff.gz | grep -v
debian to find the filename of the files being patched and put those in
the Fixes: changelog entry but I would prefer the use of debian/patches
as one source file may contain more than one issue to be Fixed - e.g. a
FTBFS bug in the #include lines and a seg fault in a function
declaration in src/foo.c. YMMV.

Is this acceptable as a possible policy proposal?

> > Uploading a divergent package with Fixed: would mean removing the patch
> > tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed
> > not set). As divergence implies upstream, replace 'upstream' with
> > 'divergence'.
> 
> Why remove the patch tag? Well, ok, maybe it is better so you can get
> a list of pending patches in your package without having already
> applied patches show up.

Well that was just the simplest way of doing things but if the PTS can
be adapted to *ignore* patches where the bug is "fixed" (or at least
split those numbers into a different section of the ToDo list in the
PTS) then that would solve the problem by allowing everyone to clearly
identify which BTS patches are in the package and which are not. Leaving
the patch tag in place could be useful, as long as the relevant web
pages and tools can discriminate between patches in open bugs and
patches in Fixed bugs.

> > In effect, divergence would be a sub-case of upstream as Fixed would be
> > a sub-case of Closed.
> >
> > (Native packages simply use Closed: directly, as now.)
> >
> > We could also specify that Fixed: cannot be used unless 'forwarded' is
> > already set - debchange could check for that.
> 
> So what you're saying is that we only need a minimal change:
> 
> - (Fixes: #1234) in changelog when adding a patch
> - The fixed state from NMU uploads is reused for divergent sources.
> [- debchange does some extra sanity checking]
> 
> And we use "fixed + upstream" as source being divergent.

Yes. A tweak or two in dpkg-dev as well so that Fixes: gets into
the .changes file alongside Closes: (after all, the same upload may
Close some bugs and Fix others), e.g. where the Closed issue is
critical / security-related and warranted an urgent upstream release but
the Fixed issue(s) were minor (or disruptive) and need to wait for a
later upstream release.

This is no more work for 

Re: divergence from upstream as a bug

[Russ Allbery]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Russ Allbery <[EMAIL PROTECTED]> [080518 15:28]:

>> I don't think this is as universally true as it looks on first glance.
>> Often the reason why the divergence remains a divergence is because
>> it's a quick hack that only works on (for example) Linux systems or
>> glibc systems and upstream would accept it if it were
>> better-implemented.

> This is an orthogonal issue. That explains why some patches are not yet
> incorporated upstream. It does not explain why the patch is necessary.

Er, yes.  However, what I was responding to was your feeling that these
aren't bugs in the Debian package.  I think often they are, in that the
Debian-specific change is less than ideal (per Policy 4.3) and needs
additional work.

> It may be a mess, but it is there. And it is always current.  Not having
> or knowing all things like diffstat and co make it hard to read, but it
> is a place and format everyone can find and everyone can look at.

Sure, I don't think anyone disagrees with that.

> I think adding a website which nicely formats those files (with
> diffstats, and properly showing included patch files) would be a thing
> that really helps all involved people. Not only upstreams forgotten or
> vanished and reappeared. Not just other upstreams of forks. But also our
> users to see at once what is changed.

Yup, and that's exactly the point of the discussion.  Joey's proposal
about using the BTS is one set of tools that would generate such a web
site, using the web site generation and tracking logic already present in
the BTS to keep it maintained.  There are other possible ways of
implementing such a web site, of course.

>>> Everything else is just overhead, as with comments in source code:
>>> they are nice to have as long there little, but if there are too many
>>> they are most of the time outdated, wrong or distracting.

>> Hm, you and I may have very, *very* different ideas of what
>> well-maintained code looks like.  :)

> Things like
>
>  /* add 1 to where p points at */
>  *p++;
>
> are not helpful.

Well, yes, obviously.  But I almost never see this outside of discussions
like this where it's used as an example of what not to do.  In practice,
nearly all code is under-commented and these sorts of problems are rare.

> Good code with comments helping with the things not codified (which
> should be little, or the code cannot really be called good) is good. Bad
> code will hardly get better and not really much more maintainable with
> more comments.

This is kind of a digression, but.

Most code that's lived in the wild for a while will develop workarounds
and obscure fixes to problems that were not at all obvious when it was
originally written.  The details of those workarounds and fixes *need* to
be written down, and as much as we might wish otherwise, there is no
programming language in existence that makes such problems so clear that
it can usually replace comments.

The general rule of thumb used in many parts of GCC is that if you had to
fix a bug in a piece of code, you probably should at least consider adding
a comment making it clear why the code needs to be written the new way,
since it's apparently not as obvious as you think (or the previous coder
wouldn't have gotten it wrong).  That's correct more often than not in my
experience.

Yes, of course, you have to maintain the comments just like you have to
maintain all other documentation or they quickly become worse than
useless.

>> Isn't this already the case in practice?  Do you really see many Debian
>> packages that have modified *.orig.tar.gz tarballs?  And if so, have
>> you filed bugs?

> They may not be so many, but there are. FTPmasters consider .orig.tar.gz
> repackaged (though without modification) so minor they just accept them.

What does this have to do with your point?  As you say, that's not a
modified version.  I think it's messy too, but it's not like we're putting
Debian-specific modifications into the upstream *.orig.tar.gz (which as
far as I'm concerned would be a fairly serious bug).

> Our secretary tells people devref is not even worth looking at because
> that says different things in that regard than he likes to do himself.

I'm a bit lost.  Is this referring to the debate over handling DFSG
modifications to upstream tarballs that we had back when the GR passed?

> And packages having a .tar.gz containing the real tar files and
> sometimes even patches may be seldom and declining but to be stumbled
> over regulary.

Oh, this is still quite common, but I don't think that's an example of
your point.  I think it's an awkward way of laying out the package, but
usually the people who do this are even *more* careful about using
pristine upstream tarballs -- that's exactly why they use this layout,
which can do things like handle multiple upstream tarballs.  The tradeoff
is that you have to unpack the *.orig.tar.gz to get the upstream tarball,
but it is there.

>> Git is quite

Re: divergence from upstream as a bug

[Daniel Burrows]

On Sun, May 18, 2008 at 12:07:04PM +0200, Lucas Nussbaum <[EMAIL PROTECTED]> 
was heard to say:
> A saner solution would be to only use the BTS when it's not possible
> to discuss the patch with upstream. We could do the following:
> 
> - add pseudo-headers in the patches for:
>   + URL of the bug that the patch is fixing (could be a Debian
> bug or an upstream bug, or even another distro's bug)
>   + URL of the discussion (patch, ML thread) happening upstream about
> this patch

  It seems to me that if you also add a pseudo-header for the bugs
that are relevant to a patch, the BTS could automatically incorporate
the patch into the bug log, and set any states that are deemed
appropriate.

  Daniel


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

Re: How to handle Debian patches

[Mike Hommey]

On Sun, May 18, 2008 at 04:44:29PM +0200, Lucas Nussbaum wrote:
> On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
> > On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
> > > On Sat, 17 May 2008, Joey Hess wrote:
> > > > Raphael Hertzog wrote:
> > > > > On Fri, 16 May 2008, Joey Hess wrote:
> > > > > > Coming up with a complex set of requirements that everyone has to 
> > > > > > follow
> > > > > > up front in their workflow[1] is not going to yeld the best 
> > > > > > results, and
> > > > > > I think that's my core reason for disliking Raphael's proposal. 
> > > > > > Now, if
> > > > > > you can come up with protocols/interfaces that can be used to
> > > > > > publish/communicate patches, that are managed/generated in whatever 
> > > > > > way
> > > > > > is most useful for the maintainer, that seems more likely to work.
> > > > > 
> > > > > Aren't "patch files in debian/patches/ with some headers" a defined 
> > > > > interface?
> > > > 
> > > > It's an interface, that if you stop there in defining it, means that I
> > > > have to check debian/patches/ into revision control, and bloat my
> > > > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > > > with them.
> > > 
> > > You don't have to check it in revision control, you just have to be able
> > > to generate them from revision control. 
> > > 
> > > For .diff.gz, we already have tools to handle such files properly
> > > (without duplicating their content), it's called quilt or simple-patch-sys
> > > of CDBS and you know it (but you don' like those).
> > > 
> > > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > > possible to hook it into the automated system that uploads patches to
> > > patches.debian.org. If that process is not the same across all
> > > .git.tar.gz, we can mandate a new debian/rules target that must generate a
> > > debian/patches directory with all the patches.
> > 
> > Note how infrastructure needs would decrease considerably if packages
> > were mandated to use v3(quilt) format: patches.debian.org would be
> > ftp.debian.org and would just need nothing new (except for how source
> > packages are created)
> 
> No, you would need to untar the .debian.tar.gz file, so upstream can
> browse the patches.

And? You also have to untar the source .tar.gz from upstream web site...

Mike


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

Re: divergence from upstream as a bug

[Lucas Nussbaum]

On 18/05/08 at 15:55 +0200, Goswin von Brederlow wrote:
> Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> 
> > On 17/05/08 at 17:01 -0400, Joey Hess wrote:
> >> What if we just decide that changes made to upstream sources[1] qualify
> >> as a bug? A change might be a bug in upstream, or in the debianisation,
> >> or in Debian for requiring the change. But just call it a bug.
> >> Everything else follows from that quite naturally..
> >
> > After re-reading the whole thread, I still have several concerns
> > about the idea of tracking each divergence from upstream as a bug in
> > the BTS, and I still don't think it's a good idea.
> >
> > 1) It duplicates information. We will already duplicate information
> > between the patch description and the upstream bug tracker or mailing
> > list where the patch was forwarded (but the patch description should
> > only a summary of the discussion happening upstream). I don't see any
> > reason to additionally duplicate information into the BTS, especially
> > since the discussion of the patch would have to happen both on the
> > upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
> > possible!)
> 
> Who says upstream has a BTS or that the bug was discussed there?

See below ; I agree that filing a bug in the Debian BTS could be a
solution when there's no way to report the patch upstream.

> Esspecially when you have debian specific patches where things are a
> clear divergence there won't be an upstream record.

If there's a patch that is not going to be useful outside of Debian, and
it's 100% clear, why should I even create a bug on the BTS about it?
There's no point in discussing something that doesn't need discussion.

> I agree with you that the bug description should be a summary. The BTS
> would be the history of the patch. The how and why it became. If that
> info is in upstreams BTS then you would just link that.
> 
> > 2) It makes the BTS another place to look at for upstreams or other
> > distros interested in our patches.
> 
> What other place is there currently besides extracting the source and
> checking that?

The source package's debian/patches dir, which will still be the
canonical place to get the up-to-date patch?

> > 3) BTS bugs do a poor job at providing summaries, so nobody can have a
> > quick glance at a patch and determine its status. Sure, a design was
> > posted for a "summary" feature for the BTS (and I'd like that
> > feature). But there's no implementation yet.
> 
> Lets not improve things because we haven't improved things yet?
> This is a stupid argument.

My point is "let's not make this improvement depend on a whole tree of
improvements in other parts of Debian infrastructure, if possible".

> > 4) The bureaucracy/usefulness ratio looks very high to me. After all,
> > we spent 15 years not doing that, and it seems to me that many patches
> > are small and don't require any discussion, so the overhead would be
> > huge. Maybe we could try a simpler solution first?
> 
> "bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
> the BTS. Not mutch work.

That's not enough. It doesn't extract the relevant patch automatically
and update the corresponding bug report, and it doesn't work with
version-tracking, which would need to be updated have 3 notions:
- notfound (already exist)
- fixed using a Debian specific patch
- fixed in upstream

> > A saner solution would be to only use the BTS when it's not possible
> > to discuss the patch with upstream. We could do the following:
> >
> > - add pseudo-headers in the patches for:
> >   + URL of the bug that the patch is fixing (could be a Debian
> > bug or an upstream bug, or even another distro's bug)
> >   + URL of the discussion (patch, ML thread) happening upstream about
> > this patch
> >
> > - encourage maintainers to use those pseudo-headers
> >
> > - publish patches on patches.debian.org so upstreams, other distros
> >   and users can have an easy look at them.
> >
> > - make patches.debian.org able to track upstream bugs and mark
> >   patches that were integrated upstream as such.
> >
> > - when there's really no place to submit patches upstream, encourage
> >   maintainers to file a bug in the Debian BTS about the patch, so
> >   the discussion about it can happen there. (with all the
> >   infrastructure you want in the BTS about it -- see the many mails in
> >   the thread about technical details).
> 
> So you not only duplicate version tracking in patches.d.o but also add
> that and the BTS to the places upstream should look for patches?

No need to duplicate version tracking. We can just export patches for
the versions in stable/testing/unstable.

Yes, I would add patches.debian.org to the places where upstream should
look for patches. But that would be the only place where upstream should
look for patches (unless upstream really wants to follow Debian closely,
which is not the general case), and upstream would have the guarantee
that all Debian modif

Re: How to handle Debian patches

[Lucas Nussbaum]

On 18/05/08 at 11:27 +0200, Mike Hommey wrote:
> On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote:
> > On Sat, 17 May 2008, Joey Hess wrote:
> > > Raphael Hertzog wrote:
> > > > On Fri, 16 May 2008, Joey Hess wrote:
> > > > > Coming up with a complex set of requirements that everyone has to 
> > > > > follow
> > > > > up front in their workflow[1] is not going to yeld the best results, 
> > > > > and
> > > > > I think that's my core reason for disliking Raphael's proposal. Now, 
> > > > > if
> > > > > you can come up with protocols/interfaces that can be used to
> > > > > publish/communicate patches, that are managed/generated in whatever 
> > > > > way
> > > > > is most useful for the maintainer, that seems more likely to work.
> > > > 
> > > > Aren't "patch files in debian/patches/ with some headers" a defined 
> > > > interface?
> > > 
> > > It's an interface, that if you stop there in defining it, means that I
> > > have to check debian/patches/ into revision control, and bloat my
> > > .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source)
> > > with them.
> > 
> > You don't have to check it in revision control, you just have to be able
> > to generate them from revision control. 
> > 
> > For .diff.gz, we already have tools to handle such files properly
> > (without duplicating their content), it's called quilt or simple-patch-sys
> > of CDBS and you know it (but you don' like those).
> > 
> > For .git.tar.gz, if you have a tool to generate the patches, it would be
> > possible to hook it into the automated system that uploads patches to
> > patches.debian.org. If that process is not the same across all
> > .git.tar.gz, we can mandate a new debian/rules target that must generate a
> > debian/patches directory with all the patches.
> 
> Note how infrastructure needs would decrease considerably if packages
> were mandated to use v3(quilt) format: patches.debian.org would be
> ftp.debian.org and would just need nothing new (except for how source
> packages are created)

No, you would need to untar the .debian.tar.gz file, so upstream can
browse the patches.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: divergence from upstream as a bug

[Bas Wijnen]

On Sun, May 18, 2008 at 03:18:12PM +0200, Pierre Habouzit wrote:
> But the problem we want to solve is making things easier for
> upstreams.

Oh?  When I read the proposal, I understood that the problem we want to
solve is about tracking changes we make to upstream.  If upstream wants
those changes, there is nothing to track.  So it's not about helping
upstream, it's about helping others who may be interested in our
changes.  Such people may be NMUers, or other distribution's packagers,
for example.

> > >   What Joey's proposal is:
> > >   * put more burden on the maintainers that already report patch
> > > upstream ;
> > 
> > Are these maintainers not recording the fact of a bug in the BTS?
> 
> When it's fixed in Debian ? What's the point ?

They have already reported the issue as a bug, if they did things right,
and they close that bug with their change.  In other words, they're
interacting with the BTS already anyway.

In fact, it could be a good idea to let this BTS interaction work
through debian/changelog as well, similar to closes: #123456.  (It
should of course be able to open bugs as well.)

The point is that this information is worth tracking, and the BTS is a
technical system which is very capable of doing so.  A bug in the BTS
doesn't mean that there is something that needs fixing.  Already it
doesn't, which is why we have the WONTFIX tag.  This just adds another
category of bugs which may or may not need fixing.

The benefit is not that the number of changes will be minimized due to
people trying to get the BTS empty[1].  The benefit is that things are
nicely documented and trackable.

Also, all the extra work you see is minimal IMO.  We're talking about
the situation where the maintainer will be writing code and testing the
changes.  This takes something like half an hour, minimum.  Then a good
maintainer will inform upstream about this, which takes about 5 minutes.
Most upstreams will be reached using e-mail (a mailinglist, usually).
In that case, adding the Cc: and pseudo-headers takes less than a
minute.  If they don't have e-mail, sending one to the BTS takes perhaps
two minutes.  This is really not significant compared to the task it is
added to.

I don't see your problem.

Thanks,
Bas

[1] Just to plug in one of my favorite subjects: IMO if the maintainer
disagrees with upstream about how to fix something, it is good that
the maintainer will make the changes (which are then not
incorporated upstream).  So in those cases, I would be against
"fixing" those bugs by dropping the patches.

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Bas Wijnen]

On Sun, May 18, 2008 at 04:11:09PM +0200, Pierre Habouzit wrote:
>   IOW basically, just do your usual workflow, bts-link adds 0 overhead
> on your work, that's exactly why it's valuable.

Huh?  This is just as true for the proposal we're discussing here, which
you seem to claim gives too much overhead...

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html


signature.asc
Description: Digital signature

Re: divergence from upstream as a bug

[Cyril Brulebois]

On 18/05/2008, Pierre Habouzit wrote:
> oh boy, are we really "fighting" over a dupe of a mail ? wasting 4k of
> data and two keystrokes ? (in mutt, D~=\n will remove dupes, kmail has
> the same functionnality, and most decent MUA do to). CoC is meant to
> reduce rudeness, not technical issues from another century.

Oh boy, are you really “fighting” over wasting one half second to type
‘L’ instead of ‘r’ when you reply to a list? (In mutt, there’s a
list-reply function, why not use it in the first place? Most decent MUAs
have that feature as well.)

Mraw,
KiBi.


pgpPdSwa6xk0H.pgp
Description: PGP signature

Re: Mailing lsit code of conduct, again

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Ben Finney <[EMAIL PROTECTED]> writes:
> 
> > Your mail message individually to me is not wanted, and I have a
> > reasonable expectation through the mailing list code of conduct
> > *and* through my explicit request that you not send it.
> 
> The solution to this problem is to fix the mailing list code of
> conduct to stop creating this expectation.

Presumably the code of conduct requests it because it was deemed
desirable.

> We don't enforce it anyway, and all this provision seems to do in
> practice is create these annoying arguments periodically.

No, that's not all it does. It also has the significant effect that
discussions in these forums do not, in the main, generate needless
individual copies of messages in the participants's mailboxes. I, and
presumably the people who drafted the code of conduct, continue to
find that a very favourable outcome of this provision.

-- 
 \ "A fine is a tax for doing wrong. A tax is a fine for doing |
  `\  well."  -- Anonymous |
_o__)  |
Ben Finney


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

Re: divergence from upstream as a bug

[Bernhard R. Link]

* Russ Allbery <[EMAIL PROTECTED]> [080518 15:28]:
> > Except that it has an important scope problem. Divergences with the
> > Debian package are not open bugs in Debian, they are open bugs in
> > upstream that are localy fixed within Debian.
>
> I don't think this is as universally true as it looks on first glance.
> Often the reason why the divergence remains a divergence is because it's a
> quick hack that only works on (for example) Linux systems or glibc systems
> and upstream would accept it if it were better-implemented.

This is an orthogonal issue. That explains why some patches are not yet
incorporated upstream. It does not explain why the patch is necessary.

> Except from upstream's perspective, it's a mess, and not necessarily worth
> their time to bother to read.  All the debian directory stuff is mixed in
> with Autoconf noise, config.* updates, and actual changes they might care
> about.  Even if the patches are broken out into separate files in
> debian/patches, they now have to download the diff and apply it to
> something to get readable patches.  And after they go to all that work,
> they may discover there's no meaningful divergence at all; there's no
> warning in advance of whether that's the case.

It may be a mess, but it is there. And it is always current.
Not having or knowing all things like diffstat and co make it hard to
read, but it is a place and format everyone can find and everyone can
look at.
I think adding a website which nicely formats those files (with
diffstats, and properly showing included patch files) would be a thing
that really helps all involved people. Not only upstreams forgotten
or vanished and reappeared. Not just other upstreams of forks. But also
our users to see at once what is changed.
And with no additional impact for maintainers than to look at using
proper formats, adding description to the patches and stuff like that.

> > Everything else is just overhead, as with comments in source code: they
> > are nice to have as long there little, but if there are too many they
> > are most of the time outdated, wrong or distracting.
> 
> Hm, you and I may have very, *very* different ideas of what
> well-maintained code looks like.  :)

Things like

 /* add 1 to where p points at */
 *p++;

are not helpful. If types and variable do not speak or even only indenting
is incomprehensible, comments can not help. A comment stating what one
can see with one look at once glare do not help but are annoying once
no longer in sync. Prose being so long one cannot see the code and the
types of the local variables on the same screen is also most likely
causing more problems then helping. Good code with comments helping
with the things not codified (which should be little, or the
code cannot really be called good) is good. Bad code will hardly get
better and not really much more maintainable with more comments.

> > Instead of adding new stuff, why not actually enforce and improve what
> > we have:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> Isn't this already the case in practice?  Do you really see many Debian
> packages that have modified *.orig.tar.gz tarballs?  And if so, have you
> filed bugs?

They may not be so many, but there are. FTPmasters consider .orig.tar.gz
repackaged (though without modification) so minor they just accept them.
Our secretary tells people devref is not even worth looking at because
that says different things in that regard than he likes to do himself.
And packages having a .tar.gz containing the real tar files and
sometimes even patches may be seldom and declining but to be stumbled
over regulary.

> Git is quite good at presenting modifications if you know how to use it.

Git is good at representing history. It might be nice for a maintainer
to see that line X was once changed and then changed again later, or
rather not really changed but only merged with the new upstream. And
then some years later the variable accessed here was renamed thus the
line had to be changed again.
I've from time to time tried to look at other people's modifications to
packages I maintain. And especially the BSDs tend to always have had all
stuff in VCSes. I'd rather have a large .diff.gz without any other
smaller files than to have to wade to history. (In the former it are at
least other changes, which sometimes might be related to what I look at,
the history is almost never intresting[1]).

Hochachtungsvoll,
Bernhard R. Link

[1] That does not claim that it is never or not very valuable then. But
for the common case it is so much littering, that if it somewhere, then
that should be somewhere else.


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

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 02:11:09PM +, Pierre Habouzit wrote:
>  of BTS it uses it supported. RT isn't. Launchpad should be
>  supported since yesterday thanks to Jelmer Vernooij, sf.net is

  Okay #417692 shows that it's a bit flaky atm, but it should be fixed
quite soon :)



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


pgp2VXNRBPTaf.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 01:49:36PM +, Russ Allbery wrote:
> Yes, there is bts-link -- I don't know how well it works having never
> been lucky enough to have an upstream with a tracker that it support, so
> far as I can tell.  Or maybe I just don't know how to use it?  My
> upstreams use RT, although I guess tf5 does use the Sourceforge tracker,
> kind of.

  There's two things to use bts-link:

  1/ check bts-link is aware of your upstream BTS (means that there is a
 small configuration step to do once and for all) and that the kind
 of BTS it uses it supported. RT isn't. Launchpad should be
 supported since yesterday thanks to Jelmer Vernooij, sf.net is
 supported as well.

  2/ mark the bugs you know have a corresponding bug on the upstream bts
 as 'forwarded' with the proper URL.

  IOW basically, just do your usual workflow, bts-link adds 0 overhead
on your work, that's exactly why it's valuable. You can see a small doc
on http://bts-link.alioth.debian.org/ about what I just said.

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


pgpI97ycqOFb0.pgp
Description: PGP signature

Re: Packages using VCS but with no 'Vcs-*' control field

[Ben Finney]

Bernd Eckenfels <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]> you wrote:
> > When such bugs are filed, I would ask that they not refer to
> > "headers" which is a term that doesn't apply to 'debian/control'.
> > The contents of 'debian/control' is a set of *fields*, not
> > headers, just like the fields in the header of an email message.
> 
> Are we making new packaging policy here?

No. It's a request for correct terminology. Hopefully it doesn't need
policy rules to enforce.

-- 
 \  "That's all very good in practice, but how does it work in |
  `\  *theory*?"  -- Anonymous |
_o__)  |
Ben Finney


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

Re: Mailing lsit code of conduct, again

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:

> Your mail message individually to me is not wanted, and I have a
> reasonable expectation through the mailing list code of conduct *and*
> through my explicit request that you not send it.

The solution to this problem is to fix the mailing list code of conduct to
stop creating this expectation.  We don't enforce it anyway, and all this
provision seems to do in practice is create these annoying arguments
periodically.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Packages using VCS but with no 'Vcs-*' control field

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> When such bugs are filed, I would ask that they not refer to "headers"
> which is a term that doesn't apply to 'debian/control'. The contents
> of 'debian/control' is a set of *fields*, not headers, just like the
> fields in the header of an email message.

Are we making new packaging policy here? 

Gruss
Bernd


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:

> We have already such a place. It's called the .diff.gz. It's linked
> everywhere, on every mirror in the same directory as the software.
> This file is there to contain and show what is changed.
> Admitted, the original one file diff is not perfect for multiple
> patches, but for this adding additional patch files in there works
> smootly.

The diff.gz contains all the changes including the debian dir. It is
by no means obvious if there are patches in there or not.

> This is were people look at and what I from looking for changes of other
> distributions of packages I maintain often miss elsewhere: A complete,
> current list of what is actually changed.

Maybe the diff.gz could be parsed automatically for patches and linked
on packages[.qa].debian.org. At least the headers of each patch could
be directly accessible from the web just like the changelog. I think
that would be nice short of the BTS idea.

> Everything else is just overhead, as with comments in source
> code: they are nice to have as long there little, but if there are too
> many they are most of the time outdated, wrong or distracting.

I find the why and how a patch came together important
information. You compare this idea to comments in source code. I find
those invaluable in understanding sources. So you actually made a
point for the idea imho.

> Instead of adding new stuff, why not actually enforce and improve what
> we have:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.

Say goodby to all packages with +dfsg tarballs. This is just not practical.

> And when extending the source packaging format, do not throw away the good
> properties lightly. Git for example is no format to present
> modifications. It is one to present history (which is almost but not
> quite something completely different).

The quilt extension is certainly a big improvement and will hopefully
unify a lot of patch system using packages after lenny.

> Thanks in advance,
>   Bernhard R. Link

MfG
Goswin


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

Re: divergence from upstream as a bug

[Aurelien Jarno]

On Sun, May 18, 2008 at 03:19:28PM +0200, Goswin von Brederlow wrote:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
> 
> > On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
> >> On Sat, 17 May 2008, Pierre Habouzit wrote:
> >> 
> >> >... glibc without patches can't work.
> >>
> >> Isn't this the best support for Joey's proposal?
> >> A software which does not work without patches is IMHO buggy.
> >
> > Do you have a proposal for a remplacement of the glibc then?
> 
> Why would you want to replace it? The proposal is about tracking the
> required patches in the BTS. Not about removing them.

Because it was suggested by Andreas the glibc is buggy.

> > And note we *do* forward patches we apply to the Debian Glibc, which is
> > not always something pleasant to do, especially when it concerns
> > "embedded crap" [1]: at best your patch is ignored, at worst you get
> > insults.
> 
> Wouldn't it be nice to have those attempts and insults archived for
> other people to see? That way when something like the OpenSSL
> catastrophe hits you you can point to the BTS and show what discussion
> went on with upstream.

That's already the case, those bugs are in upstream BTS. It's really
easy to point to them. Also if the patch comes from a bug in the Debian
BTS, we already use the forwarded tag to make the link between the
Debian and upstream BTS.

> > That's why I personally don't want another level of administrative task
> > like proposed by Joey Hess, which won't improve things in that case. We 
> > already have hundreds of bugs to fix in the Debian Glibc package, I 
> > don't want to waste my time.
> 
> I don't think tagging a bug is so much work. And for a team maintained

We are not speaking about tagging a bug, but opening a second bug in 
*our* BTS. I already find that I am spending too much time fighting with
bugzilla, I don't want to spend more time opening a second bug in our
BTS (and later having to close it). 

> package it would make things more transparent for everyone. You
> already need to coordinate sending patches upstream in some way. Why
> not use the BTS?

We already use the name of the patch (local-, submitted- and cvs-) to
know the status of a given patch. This is even more productive than
using the BTS for that, as you don't want to have to lookup the BTS each
time you are looking at a patch

Also there is no need to coordinate sending patch upstream. The one who
add a non Debian specific (not local-) patch to our SVN should send it
upstream. That's all.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: divergence from upstream as a bug

[Bernhard R. Link]

* Bastian Blank <[EMAIL PROTECTED]> [080518 15:17]:
> On Sun, May 18, 2008 at 02:44:49PM +0200, Bernhard R. Link wrote:
> > I'd suggest to start with making pristine upstream tarballs (or pure
> > subsets of those) obligatory. No modifications allowed in there and no
> > exceptions.
>
> How would you define "no modifications"?

I think we already have a definition for that.

> Even a subset already implies modifications.

That's why I explicitly mentioned it. That is what repacking is supposed
to be limited to. (and doing this in itself is quite limited at least by
the text of the devref)

> But what about a snapshot from $VCS_OF_THE_DAY? The exists no pristine 
> tarball.

When no upstream exists then obviously putting the available stuff in
one (or using one of the available methods like make dist) is the obviously the
nearest approximation.

> And if someone really wants to do that he
> may pull the source unmodified from its own fork which is resynchronized
> for each version.

I'm not against forks. But who forks should also accept upstream
responsibilities.

Hochachtungsvoll,
Bernhard R. Link


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

Mailing lsit code of conduct, again (was: divergence from upstream as a bug)

[Ben Finney]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> On Sun, May 18, 2008 at 01:26:20PM +, Ben Finney wrote:
> > What I've requested is laid out in the Debian mailing list code of
> > conduct as behaviour to be expected in the absence of explicit
> > requests. A Mail-Followup-To field setting may or may not count as
> > an explicit request; in the absence of that, the code of conduct
> > should apply.
> 
> oh boy, are we really "fighting" over a dupe of a mail ?

Your mail message individually to me is not wanted, and I have a
reasonable expectation through the mailing list code of conduct *and*
through my explicit request that you not send it. Yet you continue to
do so, violating both.

> wasting 4k of data and two keystrokes ?

You make unfounded assumptions about how I receive and handle messages
in this forum.

> CoC is meant to reduce rudeness

Then please have it reduce your rudeness, and comply with explicit
requests both from me and the ML CoC: stop sending unwanted mail
messages when the messages are already sent to the list.

-- 
 \  "I bought some powdered water, but I don't know what to add."  |
  `\  -- Steven Wright |
_o__)  |
Ben Finney


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

Re: divergence from upstream as a bug

[Aurelien Jarno]

On Sun, May 18, 2008 at 01:37:53PM +0300, Riku Voipio wrote:
> On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
> > Do you have a proposal for a remplacement of the glibc then?
> 
> > And note we *do* forward patches we apply to the Debian Glibc, which is
> > not always something pleasant to do, especially when it concerns
> > "embedded crap" [1]: at best your patch is ignored, at worst you get
> > insults.
> 
> Has using eglibc.org as upstream been considered? Forking is a valid
> option when upstream is as hostile and unco-operative as glibc's is.

While I plainly support EGLIBC, it is mainly targeted to the embedded
world. I am not sure it is a good idea to switch a server/desktop
distribution to EGLIBC *yet*, also given that I find this project a big
young. Also it would cause divergence from other distributions, which 
seems to be the exact contrary to what seems to be discussed in this
thread.

That said, if the relation with upstream doesn't improve, and if in the
next years EGLIBC prove to be the way to go, we would consider switching
to it.


> > That's why I personally don't want another level of administrative task
> > like proposed by Joey Hess, which won't improve things in that case.
> 
> It seems very debian way - fix collaboration problems with policies
> and bureacracy..

Exactly. The problem is that most maintainers do not really feel it is
important to submit patch upstreams. Creating new tools won't help in
that case, while they will bother those already doing that.


> I would propose that maintainers can suggest alternative
> collobarion models with upstream as well. Such as maintaing the delta
> against upstream in VCS branch of upstream, maintaining a policy that

The problem is that you can't change upstream if it has proved to be
non-collaborative. OTOH I think we are currently managing the patches we
apply correctly, they are sorted by architecture, and by status (debian
specific, submitted and taken from cvs).


> packager will only include patches that are already in committed upstream
> VCS, or extreme cases declaring that the debian packaging is a fork of
> upstream.

For the glibc case, that would mean we should drop support for at least
half of the currently supported architecture.

Our current policy is to not commit a patch (except debian specific 
ones) in the SVN if it has not been submitted upstream.

IMHO, each package is specific, you can't have a global policy on the
way to forward patches upstream.

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:

> On 17/05/08 at 17:01 -0400, Joey Hess wrote:
>> What if we just decide that changes made to upstream sources[1] qualify
>> as a bug? A change might be a bug in upstream, or in the debianisation,
>> or in Debian for requiring the change. But just call it a bug.
>> Everything else follows from that quite naturally..
>
> After re-reading the whole thread, I still have several concerns
> about the idea of tracking each divergence from upstream as a bug in
> the BTS, and I still don't think it's a good idea.
>
> 1) It duplicates information. We will already duplicate information
> between the patch description and the upstream bug tracker or mailing
> list where the patch was forwarded (but the patch description should
> only a summary of the discussion happening upstream). I don't see any
> reason to additionally duplicate information into the BTS, especially
> since the discussion of the patch would have to happen both on the
> upstream bug tracker and the BTS. (=> huge Cc lists, if it's even
> possible!)

Who says upstream has a BTS or that the bug was discussed there?
Esspecially when you have debian specific patches where things are a
clear divergence there won't be an upstream record.

I agree with you that the bug description should be a summary. The BTS
would be the history of the patch. The how and why it became. If that
info is in upstreams BTS then you would just link that.

> 2) It makes the BTS another place to look at for upstreams or other
> distros interested in our patches.

What other place is there currently besides extracting the source and
checking that?

> 3) BTS bugs do a poor job at providing summaries, so nobody can have a
> quick glance at a patch and determine its status. Sure, a design was
> posted for a "summary" feature for the BTS (and I'd like that
> feature). But there's no implementation yet.

Lets not improve things because we haven't improved things yet?
This is a stupid argument.

> 4) The bureaucracy/usefulness ratio looks very high to me. After all,
> we spent 15 years not doing that, and it seems to me that many patches
> are small and don't require any discussion, so the overhead would be
> huge. Maybe we could try a simpler solution first?

"bts tag 1234 + ..." or (Fixes: 1234) in changelog and CCing mails to
the BTS. Not mutch work.

> A saner solution would be to only use the BTS when it's not possible
> to discuss the patch with upstream. We could do the following:
>
> - add pseudo-headers in the patches for:
>   + URL of the bug that the patch is fixing (could be a Debian
> bug or an upstream bug, or even another distro's bug)
>   + URL of the discussion (patch, ML thread) happening upstream about
> this patch
>
> - encourage maintainers to use those pseudo-headers
>
> - publish patches on patches.debian.org so upstreams, other distros
>   and users can have an easy look at them.
>
> - make patches.debian.org able to track upstream bugs and mark
>   patches that were integrated upstream as such.
>
> - when there's really no place to submit patches upstream, encourage
>   maintainers to file a bug in the Debian BTS about the patch, so
>   the discussion about it can happen there. (with all the
>   infrastructure you want in the BTS about it -- see the many mails in
>   the thread about technical details).

So you not only duplicate version tracking in patches.d.o but also add
that and the BTS to the places upstream should look for patches?

That contradicts your 2) above.

> - Lucas

MfG
Goswin


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

Re: divergence from upstream as a bug

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:

>> And note we *do* forward patches we apply to the Debian Glibc, which is
>> not always something pleasant to do, especially when it concerns
>> "embedded crap" [1]: at best your patch is ignored, at worst you get
>> insults.

> Wouldn't it be nice to have those attempts and insults archived for
> other people to see? That way when something like the OpenSSL
> catastrophe hits you you can point to the BTS and show what discussion
> went on with upstream.

Finding the attempts of and resulting insults towards people trying to
work with glibc upstream isn't particularly hard.  I think the libc-alpha
mailing list is archived, for example.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: divergence from upstream as a bug

[Russ Allbery]

Ben Finney <[EMAIL PROTECTED]> writes:

> I don't have enough experience using the BTS to interact with upstream
> to comment on this, but I'll watch the responses of others (who do have
> such experience) with interest.

You basically can't, currently, use the BTS to interact with upstream,
only note that you are interacting with upstream, unless upstream is
willing to do what we all do and send all the discussion to the bug
address.  And even that only gets the discussion, not any state changes.

(Yes, there is bts-link -- I don't know how well it works having never
been lucky enough to have an upstream with a tracker that it support, so
far as I can tell.  Or maybe I just don't know how to use it?  My
upstreams use RT, although I guess tf5 does use the Sourceforge tracker,
kind of.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: divergence from upstream as a bug

[Ben Finney]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> [tracking divergence from upstream as a bug in the Debian BTS is]
> additional work. That's creepy and uninteresting work to begin with,
> its useless with proper upstreams, and is needed only for bad
> upstreams, that won't eve take a glance at all that work ever. Yay.
> That's kind of what I call bureaucracy indeed.

This, at least, is addressing the point of the proposal. Thanks.

I don't have enough experience using the BTS to interact with upstream
to comment on this, but I'll watch the responses of others (who do
have such experience) with interest.

-- 
 \ “Any intelligent fool can make things bigger and more |
  `\complex... It takes a touch of genius – and a lot of courage |
_o__) – to move in the opposite direction.” —Albert Einstein |
Ben Finney


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

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 01:26:20PM +, Ben Finney wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> 
> > FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
> > honour that.
> 
> What I've requested is laid out in the Debian mailing list code of
> conduct as behaviour to be expected in the absence of explicit
> requests. A Mail-Followup-To field setting may or may not count as an
> explicit request; in the absence of that, the code of conduct should
> apply.

  oh boy, are we really "fighting" over a dupe of a mail ? wasting 4k of
data and two keystrokes ? (in mutt, D~=\n will remove dupes, kmail has
the same functionnality, and most decent MUA do to). CoC is meant to
reduce rudeness, not technical issues from another century.

> > debian/patches is the proper place to put your changes.
> 
> Is it? Where is that stated to be required for all packages throughout
> Debian?

  For any reasonnably sized package, yes it should. Though it's not
required. The same way it's not required to use debhelper, even if
something like 90% of the archive do. Don't mix up things that are
mandatory, with best practices.

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


pgp3V3KEPEyz3.pgp
Description: PGP signature

Re: Sorting out mail-transport-agent mess

[Hamish Moffatt]

On Fri, May 16, 2008 at 02:10:39AM +0200, Eugeniy Meshcheryakov wrote:
> 15 травня 2008 о 16:24 -0700 Steve Langasek написав(-ла):
> > > What concerns me about this approach is that it could easilly end up with 
> > > dist-upgrades swapping out users mail systems without warning. I would 
> > > consider such behaviour unacceptable as it could easilly cause mail loss 
> > 
> > Er, no, that wouldn't happen.  As long as packages correctly depend on
> > default-mta | mail-transport-agent, this will have no impact on upgrades.
> > 
> This can happen if user has 'default-mta' package installed, and it
> changes (if it is done like with 'gcc' package now).

What if default-mta itself depend on the current default (exim4) |
mail-transport-agent? Then future changes to default-mta would not
affect installed users.

ie:

Package: something-that-needs-an-mta
Depends: default-mta | mail-transport-agent

Package: default-mta
Depends: exim4-daemon-light | mail-transport-agent



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


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

Re: divergence from upstream as a bug

[Ben Finney]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:

> The proposal is about tracking the required patches in the BTS.

No, the bug is about classifying "divergence from upstream" as a bug
to be tracked in the Debian BTS. The location of patches isn't a
necessary part of the proposal.

Patches in the BTS are listed in the proposal as a "can", not a
"should" -- i.e. something that would be a natural part of the
workflow, but not a necessary part of the proposal.

-- 
 \"Don't worry about people stealing your ideas. If your ideas |
  `\are any good, you'll have to ram them down people's throats."  |
_o__)  -- Howard Aiken |
Ben Finney


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Neil Williams <[EMAIL PROTECTED]> writes:

> On Sun, 2008-05-18 at 09:40 +0200, Goswin von Brederlow wrote:
>> Joey Hess <[EMAIL PROTECTED]> writes:
>> 
>> > What if we just decide that changes made to upstream sources[1] qualify
>> > as a bug? A change might be a bug in upstream, or in the debianisation,
>> > or in Debian for requiring the change. But just call it a bug.
>> > Everything else follows from that quite naturally..
>> >
>> > The bug can be tracked, with a patch, in our BTS. The bug can be
>> > forwarded upstream as the patch is sent upstream. A tag "divergence" can
>> > be used to query for all such bugs, or to sort such bugs out of the way.
>> 
>> I think a frequent workflow goes like this:
>> 
>> 1) user reports bug  [open]
>> 2) patch is added[open, Tags: patch]
>> 3) bug gets closed   [closed]
>> 
>> where 2 and 3 are often just a new version being uploaded. If I
>> understand you right you would add the following:
>> 
>> 2b) patch is send upstream [open, Tags: patch, send-upstream]
>> 3b) source diverges[closed, Tags: divergence, send-upstream]
>> 4) upstream accepts patch  [closed, Tags: divergence, fixed-upstream]
>> 5) new upstream release[closed]
>
> s/send-upstream/upstream/ - we already have a fixed-upstream.
>
> 1 - User reports bug with a patch against upstream code
>   [open, patch]
> 2 - maintainer forwards the patch upstream
>   [confirmed, patch, upstream, forwarded]
> 3 - maintainer uploads divergent code with Fixed: #1234
>   [fixed, divergence, forwarded]
> 4 - bts-link tags the report as upstream work on the issue
> [fixed, divergence, forwarded, fixed-upstream],
>   [fixed, divergence, forwarded, pending] etc.
> 5 - maintainer closes bug in the relevant upstream release
>   [closed]
> ... time passes ...
>   [archived]
>
> 'Tags: + upstream' would mean that the issue is an upstream issue but
> without a Debian-specific patch (or fix), yet.
> 'Tags: + divergence' would mean that the upstream issue has been fixed
> in Debian with a patch in advance of an upstream fix.

'fixed + upstream' would mean divergence. No need for a new tag actually.

> Uploading a divergent package with Fixed: would mean removing the patch
> tag and changing 'confirmed' into 'fixed' (or adding fixed if confirmed
> not set). As divergence implies upstream, replace 'upstream' with
> 'divergence'.

Why remove the patch tag? Well, ok, maybe it is better so you can get
a list of pending patches in your package without having already
applied patches show up.

> In effect, divergence would be a sub-case of upstream as Fixed would be
> a sub-case of Closed.
>
> (Native packages simply use Closed: directly, as now.)
>
> We could also specify that Fixed: cannot be used unless 'forwarded' is
> already set - debchange could check for that.

So what you're saying is that we only need a minimal change:

- (Fixes: #1234) in changelog when adding a patch
- The fixed state from NMU uploads is reused for divergent sources.
[- debchange does some extra sanity checking]

And we use "fixed + upstream" as source being divergent.

MfG
Goswin


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

Re: How to handle Debian patches

[Josselin Mouette]

Le samedi 17 mai 2008 à 22:55 -0400, Joey Hess a écrit :
> > Unless you serialize your changes, you cannot expect them to be
> > understandable for NMUers.
> 
> I have no idea what you're talking about WRT serialising changes.

This is what I’m concerned about. You’re so blinded by the coolness of
your VCS that you don’t realize you are making things more complicated
for the others.

> However, I am sure I doh't want to discuss this with you. Bye.

You haven’t been discussing anything from the very beginning of this
discussion.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: How to handle Debian patches

[Josselin Mouette]

Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit :
> As a Debian package maintainer however I'm convinced that we'd be better
> served by having only native + 3.0 quilt. The VCS comes _before_ the
> source package and the source package is just an export from the VCS.

> However I think that .git.tar.gz would be acceptable as replacement
> for native packages (like debhelper for example). 

Full ACK.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Russ Allbery]

Neil Williams <[EMAIL PROTECTED]> writes:

> Incidentally, you can collapse the zgrep into lsdiff -z:
>
> $ lsdiff -z *.diff.gz | grep -v debian

lsdiff -z -x '*/debian/*' *.diff.gz

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: divergence from upstream as a bug

[Russ Allbery]

"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * Joey Hess <[EMAIL PROTECTED]> [080517 23:01]:

>> What if we just decide that changes made to upstream sources[1] qualify
>> as a bug? A change might be a bug in upstream, or in the debianisation,
>> or in Debian for requiring the change. But just call it a bug.
>> Everything else follows from that quite naturally..

> Except that it has an important scope problem. Divergences with the
> Debian package are not open bugs in Debian, they are open bugs in
> upstream that are localy fixed within Debian.

I don't think this is as universally true as it looks on first glance.
Often the reason why the divergence remains a divergence is because it's a
quick hack that only works on (for example) Linux systems or glibc systems
and upstream would accept it if it were better-implemented.  In that case,
it really is still an open bug against the Debian package (and Policy
concurs).

There are certainly patches in the category that you describe, however.
Many of them are even cherry-picked from upstream's VCS.

> We have already such a place. It's called the .diff.gz. It's linked
> everywhere, on every mirror in the same directory as the software.  This
> file is there to contain and show what is changed.  Admitted, the
> original one file diff is not perfect for multiple patches, but for this
> adding additional patch files in there works smootly.
>
> This is were people look at and what I from looking for changes of other
> distributions of packages I maintain often miss elsewhere: A complete,
> current list of what is actually changed.

Except from upstream's perspective, it's a mess, and not necessarily worth
their time to bother to read.  All the debian directory stuff is mixed in
with Autoconf noise, config.* updates, and actual changes they might care
about.  Even if the patches are broken out into separate files in
debian/patches, they now have to download the diff and apply it to
something to get readable patches.  And after they go to all that work,
they may discover there's no meaningful divergence at all; there's no
warning in advance of whether that's the case.

> Everything else is just overhead, as with comments in source code: they
> are nice to have as long there little, but if there are too many they
> are most of the time outdated, wrong or distracting.

Hm, you and I may have very, *very* different ideas of what
well-maintained code looks like.  :)

> Instead of adding new stuff, why not actually enforce and improve what
> we have:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.

Isn't this already the case in practice?  Do you really see many Debian
packages that have modified *.orig.tar.gz tarballs?  And if so, have you
filed bugs?

> And when extending the source packaging format, do not throw away the
> good properties lightly. Git for example is no format to present
> modifications. It is one to present history (which is almost but not
> quite something completely different).

Git is quite good at presenting modifications if you know how to use it.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 01:14:09PM +, Ben Finney wrote:
> George Danchev <[EMAIL PROTECTED]> writes:
> > You wil have hard time teaching every upstream in Debian BTS (new)
> > tags and features, but they all already know how to deal well
> > prepared diffs from debian ftp mirrors.
> 
> I've gone back to re-read the original proposal that starts this
> thread, and I can't see where everyone is reading "bureaucracy" and
> "extra workload" and "patches floating in the BTS" and "forcing
> upstream to read new BTS tags and features".
> 
> The proposal, at its core, is merely about how to *classify*
> divergence from upstream source in a Debian package. There's nothing
> in the original message that requires patches to be duplicated, or
> upstream to get patches in a different way, or any of the other
> spectres people are raising here.

  That's additional work. That's creepy and uninteresting work to begin
with, its useless with proper upstreams, and is needed only for bad
upstreams, that won't eve take a glance at all that work ever. Yay.
That's kind of what I call bureaucracy indeed.

  What _would_ help is helping maintainers to report bugs upstream,
whatever the upstream way of tracking them works, with a unified
method/tool/whatever. _That_ would be more than useful. And it could
probably do what we're discussing as a side effect of reporting the bug
upstream. That would be in the end _LESS_ work for the maintainer, as it
eases the report to upstream, while having all the side effects you
want.

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


pgpe6aY6XTb2h.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Ben Finney]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
> honour that.

What I've requested is laid out in the Debian mailing list code of
conduct as behaviour to be expected in the absence of explicit
requests. A Mail-Followup-To field setting may or may not count as an
explicit request; in the absence of that, the code of conduct should
apply.

> debian/patches is the proper place to put your changes.

Is it? Where is that stated to be required for all packages throughout
Debian?

-- 
 \  "Truth: Something somehow discreditable to someone."  -- Henry |
  `\L. Mencken |
_o__)  |
Ben Finney


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

Re: divergence from upstream as a bug

[Russ Allbery]

Raphael Hertzog <[EMAIL PROTECTED]> writes:

> BTW, as a side thought, we could have tools that give list of bugs
> tagged divergence which are not forwarded and as the task of forwarding
> those is not really difficult when the patch is well commented, we could
> have many contributors helping us to forward our patches. (Some
> corner-case have to be dealt for example when upstream is dead or has no
> appropriate infrastructure (no ML and no BTS)).

Yes, although one has to be a bit careful about this.  Some upstreams are
land mines and the forwarding of patches has to be done very carefully and
with specific types of justification.  Otherwise, all you get is a rant
about how Debian is breaking their software.  I wouldn't want to subject
someone new to Debian to that (or risk that someone new to that sort of
interaction might make matters worse).

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: divergence from upstream as a bug

[Goswin von Brederlow]

Aurelien Jarno <[EMAIL PROTECTED]> writes:

> On Sun, May 18, 2008 at 09:39:07AM +0200, Andreas Tille wrote:
>> On Sat, 17 May 2008, Pierre Habouzit wrote:
>> 
>> >... glibc without patches can't work.
>>
>> Isn't this the best support for Joey's proposal?
>> A software which does not work without patches is IMHO buggy.
>
> Do you have a proposal for a remplacement of the glibc then?

Why would you want to replace it? The proposal is about tracking the
required patches in the BTS. Not about removing them.

> And note we *do* forward patches we apply to the Debian Glibc, which is
> not always something pleasant to do, especially when it concerns
> "embedded crap" [1]: at best your patch is ignored, at worst you get
> insults.

Wouldn't it be nice to have those attempts and insults archived for
other people to see? That way when something like the OpenSSL
catastrophe hits you you can point to the BTS and show what discussion
went on with upstream.

> That's why I personally don't want another level of administrative task
> like proposed by Joey Hess, which won't improve things in that case. We 
> already have hundreds of bugs to fix in the Debian Glibc package, I 
> don't want to waste my time.

I don't think tagging a bug is so much work. And for a team maintained
package it would make things more transparent for everyone. You
already need to coordinate sending patches upstream in some way. Why
not use the BTS?

MfG
Goswin


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

Re: divergence from upstream as a bug

[Pierre Habouzit]

On Sun, May 18, 2008 at 10:24:10AM +, Ben Finney wrote:
> Pierre, please fix your MUA to honour the request I made earlier: stop
> sending individual copies of messages that you also send to the Debian
> lists. It's a request in the mailing list guidelines, and I've
> explicitly pointed it out earlier.

  FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will
honour that.

> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > On Sun, May 18, 2008 at 09:57:02AM +, Ben Finney wrote:
> > > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >   But it's NOT ABOUT Debian package maintainers.
> 
> You seem to contradict yourself; in the earlier message I quoted
> above, *you* raised the issue of "requires more work from the
> maintainer". I was responding directly to that point. If you don't
> think the effect on maintainers is relevant, I don't see why you
> raised it in the first place.

  huh you don't get it. It requires more work from the maintainer, _and_
gives nothing to upstream. But the problem we want to solve is making
things easier for upstreams. And it doesn't, at the cost of *OUR* time
that is already soo scarce.

> >   More administrivia is never an improvement. See (yeah I know it's
> > always about the glibc, but well … that's a very good example for the
> > discussion) in the glibc we have
> > debian/patches/$arch/$state-$subject.patches. For $state in
> > {submitted,local,cvs}. submitted means its sent upstream, local means
> > that it's not, cvs that it's a cherry-pick from upstream. Why on earth
> > would we need to write that in _yet another place_ ?
> 
> Again, the BTS is not "yet another place"; it's already a place where
> Debian-specific information needs to be about other changes to the
> package. It's a proposal to *consolidate* information into a place
> that already has much similar information for similar purposes,
> instead of having that information scattered in many places.

  *g* you absolutely miss my point. Upstream *DON'T* go to our BTS
except in very rare case, because they don't really care about Debian
more than say fedora, gentoo, $distro.

> >   What Joey's proposal is:
> >   * put more burden on the maintainers that already report patch
> > upstream ;
> 
> Are these maintainers not recording the fact of a bug in the BTS?

  When it's fixed in Debian ? What's the point ?

> This assumes that 'debian/patches' is a known standard interface for
> all Debian packages, which I would think it clearly isn't in light of
> previous threads here. The Debian BTS, on the other hand, *is* a known
> standard interface for all Debian packages.

  debian/patches is the proper place to put your changes. the BTS is the
proper place to track _actual_ bugs in Debian. Not the one that are
fixed in Debian and not upstream's. upstream BTSes are made for that.

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


pgp9DTgwLhG34.pgp
Description: PGP signature

Re: divergence from upstream as a bug

[Bastian Blank]

On Sun, May 18, 2008 at 02:44:49PM +0200, Bernhard R. Link wrote:
> I'd suggest to start with making pristine upstream tarballs (or pure
> subsets of those) obligatory. No modifications allowed in there and no
> exceptions.

How would you define "no modifications"? Even a subset already implies
modifications. But what about a snapshot from $VCS_OF_THE_DAY? The
exists no pristine tarball. And if someone really wants to do that he
may pull the source unmodified from its own fork which is resynchronized
for each version.

Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, "Errand of Mercy", stardate 3198.4


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

Re: divergence from upstream as a bug

[Ben Finney]

George Danchev <[EMAIL PROTECTED]> writes:

> You seem to forgot that people will actually work with the source
> code and actual patches applied to it, not with a bunch of patches
> floating in Debian BTS with not so clear/predictable state
> (applied/unapplied/blamed/whatever). Such a service to can only be a
> companion one, but not a reliable source of what has actually
> changed, so consider it 'yet another place to DIG at'.

Whether the patch is in the bug report or not, I don't see how that
affects the proposal.

> You wil have hard time teaching every upstream in Debian BTS (new)
> tags and features, but they all already know how to deal well
> prepared diffs from debian ftp mirrors.

I've gone back to re-read the original proposal that starts this
thread, and I can't see where everyone is reading "bureaucracy" and
"extra workload" and "patches floating in the BTS" and "forcing
upstream to read new BTS tags and features".

The proposal, at its core, is merely about how to *classify*
divergence from upstream source in a Debian package. There's nothing
in the original message that requires patches to be duplicated, or
upstream to get patches in a different way, or any of the other
spectres people are raising here.

It *suggests* that, with such a classification, certain workflows
would be enabled naturally; but it doesn't *insist* on any of them.

There's merely the proposal that we start *tracking* the divergence as
a bug that needs resolution, like any other bug report in the BTS.

Am I wrong?

-- 
 \"I hate it when my foot falls asleep during the day, because |
  `\ that means it's gonna be up all night."  -- Steven Wright |
_o__)  |
Ben Finney


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

Re: divergence from upstream as a bug

[Bernhard R. Link]

* Joey Hess <[EMAIL PROTECTED]> [080517 23:01]:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite naturally..

Except that it has an important scope problem. Divergences with the
Debian package are not open bugs in Debian, they are open bugs in
upstream that are localy fixed within Debian.

> For all the maintainers who already keep on top of forwarding their
> changes upstream, this won't be much of a burden; ideally you just CC
> the BTS and add some pseudoheaders.

Except that this hardly fits in reality. With active upstream you
usually have the discussion first, and decide to add the patch after
that and considering the impact on the code, the severity of the bug and
the perspective of upcoming upstream releases.

> For ones who can't, because they
> cannot communicate with upstream (for whatever reason), it gives them a
> way to communicate with other interested parties (users, other distros)
> and maybe resume communication with upstream in the future.

We have already such a place. It's called the .diff.gz. It's linked
everywhere, on every mirror in the same directory as the software.
This file is there to contain and show what is changed.
Admitted, the original one file diff is not perfect for multiple
patches, but for this adding additional patch files in there works
smootly.

This is were people look at and what I from looking for changes of other
distributions of packages I maintain often miss elsewhere: A complete,
current list of what is actually changed.

Everything else is just overhead, as with comments in source
code: they are nice to have as long there little, but if there are too
many they are most of the time outdated, wrong or distracting.

Instead of adding new stuff, why not actually enforce and improve what
we have:
I'd suggest to start with making pristine upstream tarballs (or pure
subsets of those) obligatory. No modifications allowed in there and no
exceptions.
And when extending the source packaging format, do not throw away the good
properties lightly. Git for example is no format to present
modifications. It is one to present history (which is almost but not
quite something completely different).

Thanks in advance,
Bernhard R. Link


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

Bug#481756: ITP: libmath-calculus-differentiate-perl -- Algebraic Differentiation Engine

[Deepak Tripathi]

Package: wnpp
Severity: wishlist
Owner: Deepak Tripathi <[EMAIL PROTECTED]>


* Package name: libmath-calculus-differentiate-perl
  Version : 0.3 
  Upstream Author : Jonathan Worthington, <[EMAIL PROTECTED]> 
* URL : 
http://search.cpan.org/~jonathan/Math-Calculus-Differentiate-0.3/ 
* License : Perl License 
  Programming Lang: Perl
  Description : Algebraic Differentiation Engine

This module can take an algebraic expression, parse it into a tree
   structure, modify the tree to give a representation of the
   differentiated function, simplify the tree and turn the tree back into
   an output of the same form as the input.

It supports differentiation of expressions including the +, -, *, /
   and ^ (raise to power) operators, bracketed expressions to enable
   correct precedence and the functions ln, exp, sin, cos, tan, sec,
   cosec, cot, sinh, cosh, tanh, sech, cosech, coth, asin, acos, atan,
   asinh, acosh and atanh.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- 
Thanks & Regards,
Deepak Tripathi(DK)| GPG: 0xB9B0C9F2 | IRC: deepak
deepaktripathi.blogspot.com

E3 71V3 8Y C063 (We Live By Code)
--











signature.asc
Description: Digital signature