Ciao a tutti,
sto iniziando a manutenere apt-spy e ho impostato il mio progetto con
anjuta ma non vorrei che i file di anjuta andassero nel pacchetto.
Esiste un modo per dire a dpkg-buildpackage di escludere quei file? Io
non ho trovato nulla ne sul manuale ne in giro per Internet.
TIA
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream communication
processing which brings even more complexity to the
su, 2008-05-18 kello 11:42 +1000, Ben Finney kirjoitti:
Joey Hess [EMAIL PROTECTED] writes:
I think it's about time to file mass bugs on whatever packages are
left that use version control and lack the fields.
How would the putative filer of these bugs determine which packages
are in
On Sat, 2008-05-17 at 23:01 -0400, Joey Hess wrote:
Ben Finney wrote:
Care to discuss what tags you plan to use, so an attempt at consensus
can be made on naming the tags for this purpose?
I'm using a divergence usertag, with users [EMAIL PROTECTED] and
[EMAIL PROTECTED] (so it'll show up
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.
Despite the technical fact in this specific case it also forces divergences
between distributions -
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
On Sun, 18 May 2008, Josselin Mouette wrote:
That would be very nice. I think you could easily make giant
improvements by reworking the bug listing pages. They would be much more
useful with a table listing all bugs with one bug per line, color
indicators for the severity, and a column on the
On Fri, 16 May 2008, Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look to what's
in debian/patches/ when I rebuild
On Sunday 18 May 2008, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream communication
processing
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
On Sun, 2008-05-18 at 09:51 +0200, Andreas Tille wrote:
On Fri, 16 May 2008, Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I
sbackup has been merged and superseded by nssbackup, which is not yet
in Debian. I will see if I can get a version properly suited to be
packaged in Debian, and I will ask sbackup to be removed from archive.
On Thu, May 15, 2008 at 3:58 PM, Charles Plessy [EMAIL PROTECTED] wrote:
Dear all,
it
Joey Hess wrote:
FWIW, I like the general idea of tracking upstream diverge with a bug.
Mike Hommey wrote:
The BTS would also need something to make it easier to spot patches in a
bug. Patch tracking is one of the few things bugzilla is not bad at, for
instance.
I guess you're talking
su, 2008-05-18 kello 18:40 +1000, Ben Finney kirjoitti:
This would still not meet the stated requirement for the proposed mass
bug filing, of finding packages that *do* use a VCS but don't declare
it.
That is true, but it would get all package maintainers to add the
headers, and the package
Lars Wirzenius [EMAIL PROTECTED] writes:
su, 2008-05-18 kello 11:42 +1000, Ben Finney kirjoitti:
Joey Hess [EMAIL PROTECTED] writes:
I think it's about time to file mass bugs on whatever packages are
left that use version control and lack the fields.
How would the putative filer
Neil Williams [EMAIL PROTECTED] writes:
However, from a bug submitter point of view, I don't think I want to
see the bug report kept open (tagged divergence) after it has
actually been closed by a Debian-specific patch. As upstream it
might make a fair bit of sense but as a user / bug
On Sun, May 18, 2008 at 07:39:07AM +, 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.
Despite the technical fact in
On Sun, May 18, 2008, Lucas Nussbaum wrote:
(This discussion is similar to the one about DEPs vs BTS bugs -- a
discussion on the BTS would always miss a summary.)
I didn't follow this discussion, but it strikes me that many bug
trackers have a summary for bugs.
--
Loïc Minier
--
To
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
On Sun, 2008-05-18 at 18:43 +1000, Ben Finney wrote:
Neil Williams [EMAIL PROTECTED] writes:
However, from a bug submitter point of view, I don't think I want to
see the bug report kept open (tagged divergence) after it has
actually been closed by a Debian-specific patch. As upstream it
On Sat, May 17, 2008, Joey Hess wrote:
If I grab an upstream change from their VCS, I wont open a
Debian bug about it; if I find a bug in the Debian version which also
applies to upstream, I might skip to directly reporting it upstream,
and only there.
If you grab a patch from
On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote:
George Danchev [EMAIL PROTECTED] writes:
I strongly believe that [...] there is no any urgent need for more
infrastrucre enhancements and yet another places to look at (like
teaching BTS/PTS of doing additional DD-upstream
Lars Wirzenius [EMAIL PROTECTED] writes:
su, 2008-05-18 kello 18:40 +1000, Ben Finney kirjoitti:
This would still not meet the stated requirement for the proposed
mass bug filing, of finding packages that *do* use a VCS but don't
declare it.
That is true, but it would get all package
On Sunday 18 May 2008, Mike Hommey wrote:
--cut--
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
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote:
The
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
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
So it's already the case that they have a certain number of places
to look, *including* the Debian BTS if the work is packaged for
Debian. I don't see that this proposal changes that.
On Sunday 18 May 2008, Ben Finney wrote:
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
Please follow URL:http://www.debian.org/MailingLists#codeofconduct
and avoid sending messages individually to someone when the message is
also sent to the list, unless they ask for it.
…
Pierre Habouzit [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
On Sat, 17 May 2008, Lucas Nussbaum wrote:
On 16/05/08 at 17:54 +0200, Raphael Hertzog wrote:
In the general case, I do believe that the new source package format 3.0
(quilt) will help as all Debian specific changes will always end up in
debian/patches/.
If I understand things correctly
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
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
On Sun, May 18, 2008 at 09:57:02AM +, Ben Finney wrote:
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May 18, 2008 at 09:26:12AM +, Ben Finney wrote:
So it's already the case that they have a certain number of places
to look, *including* the Debian BTS if the work is
On Sat, 17 May 2008, Joey Hess wrote:
Lucas Nussbaum wrote:
At some point, we will need to find a way to decide which v3 format we
are going to choose in adddition to the v3 (native) format (with a GR?).
We can't afford to allow several different v3 formats to coexist.
The entire point
On 18/05/08 at 19:57 +1000, Ben Finney wrote:
As I understand it, the proposal is to put *new* information (that
Debian source diverges, and exactly why) into an existing location
that is already a place we expect upstream to know about (the Debian
BTS)
Huh? Upstreams knowing about the Debian
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.
Pierre Habouzit [EMAIL PROTECTED] writes:
On Sun, May
Mike Hommey a écrit :
On Sun, May 18, 2008 at 12:03:17PM +0200, Aurelien Jarno wrote:
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
Lucas Nussbaum [EMAIL PROTECTED] writes:
On 18/05/08 at 19:57 +1000, Ben Finney wrote:
As I understand it, the proposal is to put *new* information (that
Debian source diverges, and exactly why) into an existing location
that is already a place we expect upstream to know about (the
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
On Sun, 18 May 2008, Andreas Tille wrote:
On Fri, 16 May 2008, Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look
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
Le Sun, May 18, 2008 at 10:25:19AM +0200, Jose Carlos Garcia Sogo a écrit :
sbackup has been merged and superseded by nssbackup, which is not yet
in Debian. I will see if I can get a version properly suited to be
packaged in Debian, and I will ask sbackup to be removed from archive.
Hi Jose,
Hi,
On Sat, 17 May 2008, Joey Hess wrote:
The state of a bug being a divergence can just be one step in the
life-cycle of a bug.
Consider a new bug filed one a package, which turns out to be an
upstream bug, is forwarded upstream, gets patched in Debian, and then
has the patch forwarded
On Sunday 18 May 2008, Ben Finney wrote:
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
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 :
* 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
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
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
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
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
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
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
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
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
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]) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to [EMAIL
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
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
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
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
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
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
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
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
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
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.
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
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
* 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
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
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
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
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
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
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,
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·
* 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
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
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
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
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,
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
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,
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:
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
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
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
* 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
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/.
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
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 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
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
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:
* 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
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
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
-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
* 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
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
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
1 - 100 of 211 matches
Mail list logo
