On Tue, 20 May 2008, Lars Wirzenius wrote:
I'm a fairly long-time Unix user. I find it much preferably when command
line tools are quiet by default when things are going well.
I completely agree. I just have the feeling that some points were raised
in the discussion that things are not going
ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:
Would you regard this as a useful bug report or not?
I think that would be a rather excellently useful bug report. The only
way to improve it would be to include an actual patch to implement it.
--
To UNSUBSCRIBE, email to [EMAIL
On Wed, 21 May 2008, Lars Wirzenius wrote:
ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:
Would you regard this as a useful bug report or not?
I think that would be a rather excellently useful bug report.
OK, so I will go on filing it this way.
The only
way to improve it
On Wed, 21 May 2008, Andreas Tille wrote:
Subject: Please provide an option to list patches outside debian directory
Please add a --verbose/-v option to 'dpkg-source -x' that performs
lsdiff -z -x '*/debian/*' *.diff.gz
to point potential maintainers / bug fixers to patches that
On Wed, 21 May 2008, Raphael Hertzog wrote:
Would you regard this as a useful bug report or not?
No.
Ups, it's just to late (#482166)
I'm currently evaluating a smooth transition from all orig+diff to the
3.0 (quilt) format and as such I'm not really interested in a new option
that only
Andreas Tille [EMAIL PROTECTED] writes:
On Wed, 21 May 2008, Raphael Hertzog wrote:
I'm currently evaluating a smooth transition from all orig+diff to
the 3.0 (quilt) format and as such I'm not really interested in a
new option that only makes sense for the old format that I hope to
On Wed, 21 May 2008, Andreas Tille wrote:
Hmmm, do you regard it as realistic that all maintainers will change to
a new format in Lenny+1? I do not think of maintainers who are in principle
not happy about this format but those who maintain packages that might stay
untouched perfectly fine
On Wed, 21 May 2008, Raphael Hertzog wrote:
Because if the new format is the default format built by dpkg-source, this
will happen automatically when you rebuild your packages...
Yes. But there is probably some statistics about packages that are not
rebuild inbetween two releases. I admit
Le Mon, May 19, 2008 at 10:25:35PM +0200, Bernd Eckenfels a écrit :
In article [EMAIL PROTECTED] you wrote:
give a hint about this. If patches are hidden anywhere in the upstream
code some developers fail to realise this and my suggestion might help
noticing this fact.
The debian Diff
ti, 2008-05-20 kello 00:01 +0200, Andreas Tille kirjoitti:
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).
Well, I'm DD for 10 years - I know this fact. But did you
In article [EMAIL PROTECTED] you wrote:
modified. A quick inspection shows that for most of them the only change
is the path to Perl in the first line.
Yes, and I really wonder why they are using local perl and removing the -w
flag. Both is against best practise. I was actually asuming while
On Mon, 19 May 2008, Bernd Eckenfels wrote:
I dont see a reason why the normal unpack action should spam the user.
If a user feels spammed there might be means to switch this off. A command
line option that reduces the verbosity comes to mind even /dev/null might be
a place to foreward this
On Mon, 19 May 2008 09:20:11 +0200 (CEST), Andreas Tille [EMAIL PROTECTED]
said:
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
+++ ... (50 lines deleted)
+++
On Mon, 19 May 2008, Manoj Srivastava wrote:
In that case, I fail to see why you are only interested in this
information if the maintainer did not use quilt. Seems like you should
be concerned about changes made to upstream, period, regardless of
whether the changes are recorded in
In article [EMAIL PROTECTED] you wrote:
give a hint about this. If patches are hidden anywhere in the upstream
code some developers fail to realise this and my suggestion might help
noticing this fact.
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to
On Mon, 19 May 2008, Bernd Eckenfels wrote:
The debian Diff is not hiding patches in the upstream code. It is the
canonical place to publish them (at least for some (most?) of the debian
packages following policy).
Well, I'm DD for 10 years - I know this fact. But did you read about
habits
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 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
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
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
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
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
22 matches
Mail list logo
