Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 that well, if patches of upstream code are kind of hidden in the unpacked Debian source. So this is rather a definition what we understand as going well. Providing a --verbose option rather than a --quiet option would be my preference. If it is accompanied by a config file option for those people who might forget to specify --verbose it is probably OK for this case. Having a tool print out a lot of information that is peripheral to what I'm doing is distracting, and if it happens often, I start mentally ignoring the output until something breaks. Important point! Listing patches when I unpack source is one of those cases to me. Summarizing the thread I would file a wishlist bug report saying something like this: 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 reside outside of the debian directory. It would be even better if a config file option would be parsed that enables to switch on this option by default. Would you regard this as a useful bug report or not? Kind regards Andreas. -- http://fam-tille.de -- 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)
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 PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 would be to include an actual patch to implement it. ... as always. So I use the excuse (as always) that my time is currently to limited to fiddle around with this things while trusting that the implementation is easy enough for a person who knows the code much better than me. I had a look into dpkg-source before my proposal and it is rather a matter of style how to resolve this bug and I would not try to force my rude beginners style onto a perl professional. Kind regards Andreas. -- http://fam-tille.de -- 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)
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 reside outside of the debian directory. It would be even better if a config file option would be parsed that enables to switch on this option by default. Would you regard this as a useful bug report or not? No. 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 deprecate in lenny+1. And I already said that the 3.0 (quilt) format list patches that it applies during dpkg-source -x. 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: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 makes sense for the old format that I hope to deprecate in lenny+1. 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 over years? I would personally welcome your plan, but I have certain doubts that such kind of transitions are faster than for instance /usr/doc - /usr/share/doc and something like that. And I already said that the 3.0 (quilt) format list patches that it applies during dpkg-source -x. Which is nice - and thus I would love to see this implemented now for every format if it can be approached fairly easy. But the maintainer has the last word and I have no real problem if you tag the bug wontfix or just close it. I personally do this anyway on my systems - I just thought that the idea would add some tiny bit to help in the problem we detected. Kind regards Andreas. -- http://fam-tille.de -- 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)
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 deprecate in lenny+1. Hmmm, do you regard it as realistic that all maintainers will change to a new format in Lenny+1? $FOO is deprecated in lenny+1 means that, in lenny+1, usage of $FOO will be deprecated. It doesn't mean no-one is permitted to use $FOO. At some point *after* deprecation (i.e. at some point after lenny+1, in this example), $FOO becomes unsupported, but preferably only after a significant proportion has responded to the deprecation by migrating away from $FOO. but I have certain doubts that such kind of transitions are faster than for instance /usr/doc - /usr/share/doc and something like that. A perfect example. '/usr/doc' was deprecated for a long time, yet it was not until most packages had migrated away from it that it became mandatory to do so. -- \If you continue running Windows, your system may become | `\unstable. —Microsoft, Windows 95 bluescreen error message | _o__) | 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)
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 over years? I would personally welcome your plan, but I have certain doubts that such kind of transitions are faster than for instance /usr/doc - /usr/share/doc and something like that. Because if the new format is the default format built by dpkg-source, this will happen automatically when you rebuild your packages... of course, it means that all the .diff.gz (except the debian dir) will end up in a single debian/patches/debian-changes-version.diff if you don't take care to put the changes in separate patches. But the new source package will still be 3.0 (quilt) and at unpack time you'll be informed that debian-changes-version.diff is applied. Which is nice - and thus I would love to see this implemented now for every format if it can be approached fairly easy. But the maintainer What means now? dpkg in lenny is frozen... 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: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 that most probably those packages are not really the candidates that might need extra care about security patches. Which is nice - and thus I would love to see this implemented now for every format if it can be approached fairly easy. But the maintainer What means now? dpkg in lenny is frozen... Now means what you can expect for a wishlist bug - just going to unstable according to maintainers decision. And unstable is the place were packages you might like to change normaly reside - so it would perfectly fit. But well, I suggest we just end this discussion here. There are enough threads running and after having filed the bug I turned my idea into the shape I wanted it to be. The dpkg-dev maintainers will decide ... Kind regards Andreas. -- http://fam-tille.de -- 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)
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 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). Hi all, If we take openssl as an example, we can see that many .pl files are modified. A quick inspection shows that for most of them the only change is the path to Perl in the first line. The only way to know if it is the case for all is to look at all of them one by one. The Debian diff.gz file is a technical way to apply the Debian modifications to the original sources, but it seems to me a very suboptimal way to publish patches of the quality level that one would expect for his own software. To keep on the openssl example, the patched .pl are dispersed within the .diff.gz file. That is, different logical units are mixed, and to submit one of them would necessitate to generate a new patch that is not a contiguous extract of the original diff.gz. This is how I understand - and agree with - the claim that patches are hidden in the diff.gz. Have a 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: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 read about habits of other fellow developers in this thread. Just reread and come back if you are really sure that an extra hint about patches is really useless. 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. Providing a --verbose option rather than a --quiet option would be my preference. Having a tool print out a lot of information that is peripheral to what I'm doing is distracting, and if it happens often, I start mentally ignoring the output until something breaks. Listing patches when I unpack source is one of those cases to me. -- 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)
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 seeing the list of files, it would be the other way around :) Gruss Bernd -- 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)
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 stuff if you really feel spammed. 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) +++ openssl-0.9.8g/util/pl/netware.pl This is *exactly* what I want the user to see. The information that the source has *a lot* (53) files that are patched by the Debian maintainer is no spam at all but might make the user aware that there might be reasons to inspect the diff carefully and that it is not enough to look into debian/patches (which might not exist in this case, did not checked). Kind regards Andreas. -- http://fam-tille.de -- 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)
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) +++ openssl-0.9.8g/util/pl/netware.pl This is *exactly* what I want the user to see. The information that the source has *a lot* (53) files that are patched by the Debian maintainer is no spam at all but might make the user aware that there might be reasons to inspect the diff carefully and that it is not enough to look into debian/patches (which might not exist in this case, did not checked). 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 quilt or not. Am I missing something? manoj -- Peace cannot be kept by force; it can only be achieved by understanding. Albert Einstein Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- 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)
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 quilt or not. Am I missing something? Yes. You are missing the fact that anybody who inspects a package will inspect the debian dir anyway. If there is a patches directory it is obvious that upstream files are patched and there is no need to explicitely 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. Kind regards Andreas. -- http://fam-tille.de -- 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)
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 publish them (at least for some (most?) of the debian packages following policy). Gruss Bernd PS: are we going to somehow react to the massive loss of trust into debian, for example by publishing a new policy, a qa task force or anything? From quite some discussions I know it is expected (however I dont claim to have a practcable answer). I just wonder why we currently discuss Mailing List netiqette instead of the current issue. -- 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)
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 of other fellow developers in this thread. Just reread and come back if you are really sure that an extra hint about patches is really useless. PS: are we going to somehow react to the massive loss of trust into debian, No I just try to think about implementing what I regularly do and would call a reasonable habit that might help others. I just wonder why we currently discuss Mailing List netiqette instead of the current issue. I do so as well, but my 'd'-key works perfectly for this kind of subjects ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 a package but not to what's in .diff.gz only. If I inspect an unknown package I always do zgrep ^+++ *.diff.gz | grep -v /debian/ and I wonder whether I should file a bug report against dpkg-source -x to do this by default. Kind regards Andreas. -- http://fam-tille.de -- 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)
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 tend to give a look to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. If I inspect an unknown package I always do zgrep ^+++ *.diff.gz | grep -v /debian/ and I wonder whether I should file a bug report against dpkg-source -x to do this by default. lintian already has that level of check but it does have problems with generated files, see #471263: Files that are changed as the result of a patch to a file that is processed during the build should be ignored - e.g. patching configure.in|ac should mean that changes in ./configure must be ignored. Otherwise, as soon as autotools updates or an m4 macro gets updated in some -dev package, the patch for ./configure will break for no good reason and we get a FTBFS RC bug. Detecting which files are changed as a by-product of a patch isn't always particularly obvious. Incidentally, you can collapse the zgrep into lsdiff -z: $ lsdiff -z *.diff.gz | grep -v debian -- 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: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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 to what's in debian/patches/ when I rebuild a package but not to what's in .diff.gz only. If I inspect an unknown package I always do zgrep ^+++ *.diff.gz | grep -v /debian/ and I wonder whether I should file a bug report against dpkg-source -x to do this by default. 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). 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: 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]) http://www.eyrie.org/~eagle/ -- 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)
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: 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 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]
