Has recibido una postal de 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 -

Re: divergence from upstream as a bug

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 Debia

Re: divergence from upstream as a bug

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 ups

Re: Sorting out mail-transport-agent mess

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 su

Re: divergence from upstream as a bug

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

Re: Mailing lsit code of conduct, again

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

Re: Mailing lsit code of conduct, again

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,

Re: ssl security desaster

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 elsewh

Re: Mailing lsit code of conduct, again

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 i

Re: Mailing lsit code of conduct, again

"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,

Re: Mailing lsit code of conduct, again

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

Re: divergence from upstream as a bug

'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

Re: Mailing lsit code of conduct, again

"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)...

Re: Mailing lsit code of conduct, again

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 "Re

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

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

deactivated native samba support in mc

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

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

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 ..

Re: Mailing lsit code of conduct, again

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] OOO

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

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. > > >

Re: Mailing lsit code of conduct, again

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 t

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

(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 t

Re: Mailing lsit code of conduct, again

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 d

Re: Tracking divergence from upstream as a bug

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

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

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 perfec

Re: Mailing lsit code of conduct, again

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

Re: Mailing lsit code of conduct, again

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 > periodical

Re: Tracking divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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 i

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

(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 > > > > develop

Re: divergence from upstream as a bug

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 s

Re: divergence from upstream as a bug

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 mainta

Re: Mailing lsit code of conduct, again

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

Re: divergence from upstream as a bug

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

Re: RFS: figtoipe / difficulties with Replaces:

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 woul

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

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

Re: divergence from upstream as a bug

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,

Re: Mailing lsit code of conduct, again

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 o

Re: Mailing lsit code of conduct, again

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.

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

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 >

Re: divergence from upstream as a bug

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 > > (appl

Re: Mailing lsit code of conduct, again

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

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

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 > inte

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

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

Re: Mailing lsit code of conduct, again

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 heade

Re: Mailing lsit code of conduct, again

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

Re: Mailing lsit code of conduct, again

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 >

Re: Mailing lsit code of conduct, again

* 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 yo

Re: Mailing lsit code of conduct, again

-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

Re: Mailing lsit code of conduct, again

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 consiste

Re: Mailing lsit code of conduct, again

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 no

Re: divergence from upstream as a bug

* 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 upst

Re: How to handle Debian patches

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

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

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 se

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

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 prop

Re: How to handle Debian patches

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

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

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 cha

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

* 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 i

Re: divergence from upstream as a bug

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 - mai

Re: divergence from upstream as a bug

"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)

Re: divergence from upstream as a bug

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

Re: How to handle Debian patches

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 w

Re: divergence from upstream as a bug

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 debiani

Re: How to handle Debian patches

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

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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 over

Re: divergence from upstream as a bug

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

Re: Mailing lsit code of conduct, again

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 solutio

Re: divergence from upstream as a bug

* 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 look

Re: divergence from upstream as a bug

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·

Re: divergence from upstream as a bug

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, al

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

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,

Re: Mailing lsit code of conduct, again

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 con

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

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

Re: divergence from upstream as a bug

"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

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

* 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 y

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

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

Re: divergence from upstream as a bug

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 ple

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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 wor

Re: divergence from upstream as a bug

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 n

Re: divergence from upstream as a bug

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 th

Re: divergence from upstream as a bug

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

Re: Sorting out mail-transport-agent mess

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 > > > con

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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 debiani

Re: How to handle Debian patches

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

Re: How to handle Debian patches

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 thi

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

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 [EM

Re: divergence from upstream as a bug

"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

Re: divergence from upstream as a bug

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 gon

Re: divergence from upstream as a bug

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 set

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

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 mod

Re: divergence from upstream as a bug

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

Re: divergence from upstream as a bug

* 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 qu

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

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-Different

  1   2   >