Re: How to handle Debian patches
On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote: You can imagine harvesting alioth.d.o and extracting all debian/control stored in whatever $VCS you find there, but you can't be sure if this is the currently used $VCS, if there are other versions of the package versioned elsewhere, ... Plenty of room for false positives. Even Why debian/control? debian/changelog provides the source package name and the latest version. Matching data with the latest Sources of unstable should do the trick to know what is up to date in the $VCS, and what isn't. Uhm, interesting, you mean testing if the changelog version is greater or equal than the latest in unstable, right? This still leaves the room to the very same package version, greater than latest unstable, which has been moved from one VCS to the other before being uploaded, but I guess it is a pretty remote case. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
Stefano Zacchiroli wrote: On Wed, May 28, 2008 at 07:57:03PM -0500, Raphael Geissert wrote: You can imagine harvesting alioth.d.o and extracting all debian/control stored in whatever $VCS you find there, but you can't be sure if this is the currently used $VCS, if there are other versions of the package versioned elsewhere, ... Plenty of room for false positives. Even Why debian/control? debian/changelog provides the source package name and the latest version. Matching data with the latest Sources of unstable should do the trick to know what is up to date in the $VCS, and what isn't. Uhm, interesting, you mean testing if the changelog version is greater or equal than the latest in unstable, right? This still leaves the room to the very same package version, greater than latest unstable, which has been moved from one VCS to the other before being uploaded, but I guess it is a pretty remote case. I believe the number of false positives will be very very small, and if one takes a look at what would be done there's a chance to spot them. Cheers. Cheers, Raphael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Stefano Zacchiroli wrote: On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: I think it's about time to file mass bugs on whatever packages are left that use version control and lack the fields. ... You can imagine harvesting alioth.d.o and extracting all debian/control stored in whatever $VCS you find there, but you can't be sure if this is the currently used $VCS, if there are other versions of the package versioned elsewhere, ... Plenty of room for false positives. Even Why debian/control? debian/changelog provides the source package name and the latest version. Matching data with the latest Sources of unstable should do the trick to know what is up to date in the $VCS, and what isn't. Still, it is a good idea to start diffusing the culture of manually filing bugs against version controlled packages lacking the field. Cheers. Cheers, Raphael -- 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 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: How to handle Debian patches
Le mardi 20 mai 2008 à 23:03 -0500, Manoj Srivastava a écrit : A quilt format package with a single combined patch. Get the integration branch, get orig.tar.gz, build. dpkg-buildpackage will automatically create a debian_version.patch for you. It is easy. How is this better than the current diff.gz thing? It is not better, but the point is that it is not *worse*. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)
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: How to handle Debian patches
Manoj Srivastava [EMAIL PROTECTED] writes: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). A quilt format package with a single combined patch. Get the integration branch, get orig.tar.gz, build. dpkg-buildpackage will automatically create a debian_version.patch for you. It is easy. I'm not saying you get a nice and shiny debian/patches/* out of it. That indeed needs human interaction as already said elsewhere. To the non git (even not quilt) experienced user the combined patch will be usable in that he can edit the source and fix bugs. The git format does not allow that. Even with some git knowledge I think that most users that write a patch won't follow the maintainers workflow. They won't find the right feature branch a patch belongs to and how to merge that into an integration branch. Instead they will just edit the source, git commit and send the resulting patch. And that means you get a patch against the integration branch. Same as you would with the quilt format. Users that dig deeper into the source to find out the maintainers workflow I would expect to be able to find the maintainers git repository too and just use that directly. So the only use for the git format is for people that can already use the original git repository. Hence my view that it is a bad format. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Pierre Habouzit [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote: B) (This is an honest question). How many things can rerere remember? If I use rerere to record how to resolve current conflicts in feature branches, does the historical information get lost? (like, I use rerere to help merging the current upstream version, do we lose information about previous upstream versions?) git-rerere keeps recorded conflicts resolution for 60 days by default, and it's configureable, and it needs to use git-gc (or git rerere gc) to cleanse it, so if you don't, it just won't disappear. If you have a feature branch that won't be accepted upstream then that can be years old. And conflicts could have been resolved right at the start of that time. How does git-rerere dig out that years old conflict resolution? How do you tell git-rerere to keep all conflict resolutions needed to convert feature branches into a patch series but not others? How sure are you that will actually work right and not misidentify code at the wrong places? Ok, I guess you can compare the patch series output against the integration branch and they should be identical. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Gunnar Wolf [EMAIL PROTECTED] writes: Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]: If I understand things correctly (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. Yes it will. Any modified file will end up in debian/patches/ instead of modifying the file directly. It will not prevent patches but it ensures they are used exclusively. So no packages that change some files directly and use debian/patches/ for others. It seems to me that what we need to do is decide that using dpatch or quilt is the way to go (with properly commenting individual patches). It's a social problem, not a technical one. But with some time put to it, we can end up including a the maintainer shuold not modify files outside of the debian/ directory without a strong rationale, and provide lintian checks for packages still directly modifying upstream code... Do you mean no debian/patches at all? It can become a long transition, but a good one in the end, /methinks. MfG Goswin -- 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: How to handle Debian patches
On Sat, May 17, 2008 at 10:18:58PM +0100, Roger Leigh wrote: The syntax for the fields also does not currently let you specify a branch or tag, it's just the whole repo. Personally, I'd like it to allow specification of the branch/tag used to produce the specific release of the package in Sources.gz (or better, the latest development on that branch). For example: Vcs-Git: git://git.debian.org/git/buildd-tools/schroot This gives you the master branch, but the Debian packages are actually on the schroot-1.2 stable release branch. For people who want to hack on what's actually in use in Debian testing/unstable right now, this is the wrong branch. This is coherent with the initial idea of the field: give a human being (the Debian maintainer) a pointer to where the packages is being worked on. Then you will need some additional information to know where to look, as you would looking on the VCS tab of sourceforge or on the author homepage. If, as it seems to me, we are now starting to feel the need of having more structure Vcs-* information so as to enable _automatic_ processing of VCS information, well, let's sit down and standardize that. Though note that this will need to be done on a per-Vcs basis, as concepts from one VCS not necessarily apply to other (that's for example why we have $VCS-buildpackage rather than a single vcs-buildpackage). Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over I stopped buying this argument (generally, not specifically from you) on the basis that in most of the cases packages have several non overlapping patches wrt upstream. So the trivial part above is indeed true for a lot of packages. The remaining ones will indeed need manual intervention, but aren't this kind of changes those which are supposed to be pushed upstream? So some more burden on the developer on these rare (if you buy my statement above) cases can even be beneficial from a social point of view. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
On Tue, May 20, 2008 at 06:07:14AM +, Goswin von Brederlow wrote: How do you tell git-rerere to keep all conflict resolutions needed to convert feature branches into a patch series but not others? I was merely answering a first set of questions, for the rest please read documentation git-rerere(1) e.g. This part of the thread is *really* becoming OT. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpacYazid1E6.pgp Description: PGP signature
Re: How to handle Debian patches
Goswin von Brederlow dijo [Tue, May 20, 2008 at 08:10:05AM +0200]: If I understand things correctly (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. Yes it will. Any modified file will end up in debian/patches/ instead of modifying the file directly. It will not prevent patches but it ensures they are used exclusively. So no packages that change some files directly and use debian/patches/ for others. Ok... I have not followed the development of the new package version But with some time put to it, we can end up including a the maintainer shuold not modify files outside of the debian/ directory without a strong rationale, and provide lintian checks for packages still directly modifying upstream code... Do you mean no debian/patches at all? No, of course not - But I _do_ mean no patches with no rationale at all. If I understand correctly, were I to repackage something I have now that directly modifies the upstream code, my whole unorganized patchwork probably become something like debian/patches/01. Of course, a tool cannot understand _what_ it does, and how it should be split. I suppose (and, again, I'm just guessing right now, please forgive me) a good maintainer would split and name that in debian/patches/01_fixes_blah, debian/patches/02_foo and so on, and in each of the files' headers would note what bug or issue is this patch addressing. And we can make tools understand said headers - and complain if an unexplained patch was found. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- 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: How to handle Debian patches
On Tue, 20 May 2008 08:00:48 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). A quilt format package with a single combined patch. Get the integration branch, get orig.tar.gz, build. dpkg-buildpackage will automatically create a debian_version.patch for you. It is easy. How is this better than the current diff.gz thing? I'm not saying you get a nice and shiny debian/patches/* out of it. That indeed needs human interaction as already said elsewhere. To the non git (even not quilt) experienced user the combined patch will be usable in that he can edit the source and fix bugs. The git format does not allow that. Unpack a 3.0 (git) source package. Hack. git commit -a -mWhy I hacked this. dpkg-buildpackage Seems like does not allow is a bit strong. As more and more people swithc to git, git awareness will spread, making more people who can actually deal with creating a git branch to make changes on. Seems like a long term win. Even with some git knowledge I think that most users that write a patch won't follow the maintainers workflow. They won't find the right feature branch a patch belongs to and how to merge that into an integration branch. Instead they will just edit the source, git commit and send the resulting patch. And that means you get a patch against the integration branch. Same as you would with the quilt format. The users are not really following the maintainers workflow even in the git case (If I have to modify patch 7 of 9, I need some quilt-fu). manoj -- Do unto others before they undo you. 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: How to handle Debian patches
On Tue, 20 May 2008 00:44:44 +0200, Stefano Zacchiroli [EMAIL PROTECTED] said: On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over I stopped buying this argument (generally, not specifically from you) on the basis that in most of the cases packages have several non overlapping patches wrt upstream. So the trivial part above is indeed true for a lot of packages. If you want to only cater to package who currently do not have overlapping branches, sure. I am not sure I'll feel motivated enough to go along with a partial solution, but perhaps you do not need everyone buy-in. The remaining ones will indeed need manual intervention, but aren't this kind of changes those which are supposed to be pushed upstream? So some more burden on the developer on these rare (if you buy my statement above) cases can even be beneficial from a social point of view. While in theory evey divergence is something to be pushed upstream, and anything ihn ./debian/patches should disappear, in practice, for multitudinous reasons, we still have divergence. Any policy that relies on this not being the case is, umm, being somewhat unrealistic. manoj -- In every country and every age, the priest has been hostile to Liberty. Thomas Jefferson 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: How to handle Debian patches
Stefano Zacchiroli [EMAIL PROTECTED] writes: The remaining ones will indeed need manual intervention, but aren't this kind of changes those which are supposed to be pushed upstream? So some more burden on the developer on these rare (if you buy my statement above) cases can even be beneficial from a social point of view. In many of the cases discussed in this thread, the Debian package maintainer is already bearing much of the burden of the divergence and upstream (whatever their attitude to the developer) is not going to incorporate the patch any time soon. Why, in these cases, do you see extra burden on the Debian package maintainer to be a good thing? -- \ I hope some animal never bores a hole in my head and lays its | `\ eggs in my brain, because later you might think you're having a | _o__) good idea but it's just eggs hatching. -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : As a Debian package maintainer however I'm convinced that we'd be better served by having only native + 3.0 quilt. The VCS comes _before_ the source package and the source package is just an export from the VCS. However I think that .git.tar.gz would be acceptable as replacement for native packages (like debhelper for example). Full ACK. Full NACK. I would rather have native packages in 3.0 quilt format. Initialy they would have no patches but NMU uploads would automatically generate one. I mean what stops us from having foo_1.0-1.dsc contain: foo_1.0.tar.gz debian.tar.gz MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Mon, 19 May 2008, Goswin von Brederlow wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : As a Debian package maintainer however I'm convinced that we'd be better served by having only native + 3.0 quilt. The VCS comes _before_ the source package and the source package is just an export from the VCS. However I think that .git.tar.gz would be acceptable as replacement for native packages (like debhelper for example). Full ACK. Full NACK. Please stop using NACK on public lists, it's badly connotated. It looks like you're forbidding someone else to do something as if you had some veto power. I would rather have native packages in 3.0 quilt format. Initialy they would have no patches but NMU uploads would automatically generate one. If the maintainer decides to use a git-based format it's probably also because he prefers receving NMU as git branch in a new upload instead of a patch. So I don't see why you would refuse that liberty to the maintainer. It's not like the native package option will disappear... 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 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: How to handle Debian patches
Raphael Hertzog [EMAIL PROTECTED] writes: On Mon, 19 May 2008, Goswin von Brederlow wrote: Josselin Mouette [EMAIL PROTECTED] writes: Le dimanche 18 mai 2008 à 12:00 +0200, Raphael Hertzog a écrit : As a Debian package maintainer however I'm convinced that we'd be better served by having only native + 3.0 quilt. The VCS comes _before_ the source package and the source package is just an export from the VCS. However I think that .git.tar.gz would be acceptable as replacement for native packages (like debhelper for example). Full ACK. Full NACK. Please stop using NACK on public lists, it's badly connotated. It looks like you're forbidding someone else to do something as if you had some veto power. I would rather have native packages in 3.0 quilt format. Initialy they would have no patches but NMU uploads would automatically generate one. If the maintainer decides to use a git-based format it's probably also because he prefers receving NMU as git branch in a new upload instead of a patch. So I don't see why you would refuse that liberty to the maintainer. It's not like the native package option will disappear... Cheers, Because the git format is imho conceptualy broken and the implementation is far from completely thought out. The strongest point against it is that the user has to learn git to use it. The quilt format on the other hand can be used transparently instead of v1 format. The user does not need to learn quilt to use it. That aspect can be totally ignored unless you want to use it. The maintainer can use whatever he likes. It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. The maintainer can also import the quilt patches a NMU would add to the deb to the RCS repository. There is no real drawback in using quilt format even if you use git. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. The strongest point against it is that the user has to learn git to use it. I'm curious about this. Why is it conceptualy broken and badly implemented? Is there any public URL about that? The quilt format on the other hand can be used transparently instead of v1 format. The user does not need to learn quilt to use it. That aspect can be totally ignored unless you want to use it. The maintainer can use whatever he likes. It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. The maintainer can also import the quilt patches a NMU would add to the deb to the RCS repository. There is no real drawback in using quilt format even if you use git. I agree with you in this. Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Mon, May 19, 2008 at 10:55:00AM +0200, Miriam Ruiz wrote: 2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. The strongest point against it is that the user has to learn git to use it. I'm curious about this. Why is it conceptualy broken and badly implemented? Is there any public URL about that? #477954, for one. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Miriam Ruiz [EMAIL PROTECTED] writes: 2008/5/19 Goswin von Brederlow [EMAIL PROTECTED]: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. The strongest point against it is that the user has to learn git to use it. I'm curious about this. Why is it conceptualy broken and badly implemented? Is there any public URL about that? As for implementation see the bugreport in the other reply for some tidbits. Conceptually I think the following: A Debian source package is a snapshot in time of the source. The source at the specific time of the upload. A git repository is the full history of the source with all edits, pushes, pulls, merged, cherry-picking all documented in the log. So people said that the git repository should be pruned to only contain recent stuff. But you can not do that with feature branches without loosing the history between the branches. You can't merge changes in a feature branch into the integration branch with that anymore. Which would make it rather pointless. So lets not prune it. Then you put every single source version there ever was into the debian source package. And it will grow and grow and grow. And what is the point? Anyone familiar with git can just use the git repository directly without bothering with the debian source package. You just duplicate the repository on every debian mirror out there. And that is not even mentioning that the workflow in a git repository can greatly differ between maintainer. You can have many many branches and how is poor user supposed to know which branch to edit? And if the user just edits the source as is, figures out how to commit that to git and create a patch then all you end up is a patch against the integration branch and not any feature branch. With quilt format you get exactly the same patch automatically generated without all the extra hoops the user has to jump through for the git format. MfG Goswin -- 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: How to handle Debian patches
On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). Now, the quilt series has to be regenerated on every new version, or whenever any topic branch gets an input; and doing the manual conflict resolution every time might not result in the same output (and not just through human error). This brings into question the utility of the series: the quilt series is not what the package is built from, and might not accurately reflect the integration branch; so I am told that from a security review viewpoint the resulting quilt series is not that useful. Allow me to illustrate: Suppose there is a file that has 10 lines: --8---cut here---start-8--- 1 2 3 4 5 6 7 8 9 10 --8---cut here---end---8--- I have a topic branch called Odd: --8---cut here---start-8--- 101 2 103 4 105 6 107 8 9 10 --8---cut here---end---8--- And another one called even: --8---cut here---start-8--- 1 202 3 204 5 206 7 208 9 10 --8---cut here---end---8--- Every change in either branch will result in a conflict when trying to apply the second patch, though in this example the conflict resolution is trivial. Can you demonstrate a tool that will correctly generate a quilt series from these branches? manoj -- The meek are contesting the will. 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: How to handle Debian patches
On Mon, May 19, 2008 at 03:29:13PM +, Mike Hommey wrote: On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). (...) git has git rerere to deal with this. Even better, mkdir .git/rr-cache and it'll do it automatically for you. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9racu8kOBK.pgp Description: PGP signature
Re: How to handle Debian patches
On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). (...) git has git rerere to deal with this. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Mon, 19 May 2008 17:29:13 +0200, Mike Hommey [EMAIL PROTECTED] said: On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: Hmm. You say things like this: Because the git format is imho conceptualy broken and the implementation is far from completely thought out. And then you go saying things like that: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). (...) git has git rerere to deal with this. Two comments: A) This is great for git users. Is there a hg-rerere? svn-rerere? tla-rerere? bzr-rerere? I am just as opposed to everyone must use git as I am to everyone must use quilt. B) (This is an honest question). How many things can rerere remember? If I use rerere to record how to resolve current conflicts in feature branches, does the historical information get lost? (like, I use rerere to help merging the current upstream version, do we lose information about previous upstream versions?) manoj -- Many people feel that they deserve some kind of recognition for all the bad things they haven't done. 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: How to handle Debian patches
Lucas Nussbaum dijo [Sat, May 17, 2008 at 02:37:31PM +0200]: If I understand things correctly (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. It seems to me that what we need to do is decide that using dpatch or quilt is the way to go (with properly commenting individual patches). It's a social problem, not a technical one. But with some time put to it, we can end up including a the maintainer shuold not modify files outside of the debian/ directory without a strong rationale, and provide lintian checks for packages still directly modifying upstream code... It can become a long transition, but a good one in the end, /methinks. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- 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]
Re: How to handle Debian patches
On Mon, May 19, 2008 at 04:06:36PM +, Manoj Srivastava wrote:
B) (This is an honest question). How many things can rerere remember? If
I use rerere to record how to resolve current conflicts in feature
branches, does the historical information get lost? (like, I use
rerere to help merging the current upstream version, do we lose
information about previous upstream versions?)
git-rerere keeps recorded conflicts resolution for 60 days by default,
and it's configureable, and it needs to use git-gc (or git rerere gc) to
cleanse it, so if you don't, it just won't disappear.
git-rerere works by remembering versions of files before a conflict
and after its resolution, so that if this particular conflict is met
again, it just propose the last merge as a merge solution when a
conflict occurs. But it does not hides from you that you had a conflict,
it's just that instead of presenting to you a file with conflicts marks
in it, it replaced the hunks where there is a conflict with the previous
merge solution instead, so that in many cases you just have to {git
commit,git rebase --continue, ...} (depending on which action led you to
this conflict of course) without having to solve the conflict by hand.
I'm not sure I answer your question wrt history but I'm not sure
it's a relevant question either.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpv9T4YynuDk.pgp
Description: PGP signature
Re: How to handle Debian patches
Mike Hommey [EMAIL PROTECTED] writes: On Mon, May 19, 2008 at 09:58:55AM -0500, Manoj Srivastava wrote: On Mon, 19 May 2008 10:42:54 +0200, Goswin von Brederlow [EMAIL PROTECTED] said: It is trivial to generate a quilt format package from git/arch/hg/svn and I'm sure there will be a RCS-build-package soon enough that does that. This can not happen without manual intervention, if the topic branches have overlap. And Redoing the manual conflict resolution over and over and over again is a burden (the manual conflict resolution lives generally in the integration branch history, and can be done once, and mostly ignored from that point on). (...) git has git rerere to deal with this. Bazaar is soon to gain the loom feature, currently in development URL:http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt which also will deal with this issue. -- \ Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing. -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Tue, 20 May 2008, Pierre Habouzit wrote: git-rerere keeps recorded conflicts resolution for 60 days by default, and it's configureable, and it needs to use git-gc (or git rerere gc) to cleanse it, so if you don't, it just won't disappear. I admit I realy don't care what your favourite VCS of the day (yes I've also read the hint about bazaar loom feature comming soon) if an apt-get source pkgname which I regard THE method the obtain a Debian package source gives no better hints about patches in the upstream source. 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: How to handle Debian patches
On Sat, 17 May 2008, Joey Hess wrote: Raphael Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. 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: How to handle Debian patches
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 simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) Extremely wise and sound statement. If I ever meet you on private I'd buy you a beer, really! -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: On Sat, 17 May 2008, Joey Hess wrote: Raphael Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
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 (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. Yes but: 1/ you usually don't modify many files for many unrelated change in the same upload 2/ that process is rather meant for NMU 3/ we can have a lintian warning to discourage this practice if we think the maintainer should better rename the patch and It seems to me that what we need to do is decide that using dpatch or quilt is the way to go (with properly commenting individual patches). It's a social problem, not a technical one. Oh sure, but the standardization that v3 quilt can bring will help a lot. Should we wait for the switch to the new source format to create patches.debian.org? It sounds like a better idea to write it in a way that makes it work with both format 1.0 and 3.0 (quilt). Maybe work from the extract source... I don't want to stop anyone... feel free to start right now. :-) 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: How to handle Debian patches
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 of having support for multiple source formats in dpkg-source, and allowing it to extract any of those formats, and build a source package using any of those formats, is to allow multiple formats to be used. Yes, but not necessarily on ftp-master.debian.org. What you're suggesting is equivilant to us deciding by GR which helper system can be used in the rules file. I can understand how one can would have that feeling. But for me it's more like the policy process where we make decision of what's reasonable for us based on what's possible. As a dpkg maintainer, I can imagine scenario where the new source package formats are sensible to use and as such I gave my support to include them in the set of what's possible. 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. It would stifle any futher innovation in source formats. That's a particularly cruel thing to do when such innovation is just getting started after an interminable period of stasis. I can understand that if they are not allowed on ftp-master.d.o it means that they'll get less exposure. However, I really think that there's quite some work left to do before I would find it acceptable to use .git.tar.gz as replacement for .orig+.diff or the v3 quilt format. I already explained many of the shortcomings that concern me so I won't repeat them here (see our discussion on debian-dpkg on that topic). However I think that .git.tar.gz would be acceptable as replacement for native packages (like debhelper for example). 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 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: 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 think that .git.tar.gz would be acceptable as replacement for native packages (like debhelper for example). Full ACK. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: 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 your VCS that you don’t realize you are making things more complicated for the others. However, I am sure I doh't want to discuss this with you. Bye. You haven’t been discussing anything from the very beginning of this discussion. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to handle Debian patches
On 18/05/08 at 11:27 +0200, Mike Hommey wrote: On Sun, May 18, 2008 at 11:19:31AM +0200, Raphael Hertzog wrote: On Sat, 17 May 2008, Joey Hess wrote: Raphael Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) No, you would need to untar the .debian.tar.gz file, so upstream can browse the patches. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) No, you would need to untar the .debian.tar.gz file, so upstream can browse the patches. And? You also have to untar the source .tar.gz from upstream web site... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) No, you would need to untar the .debian.tar.gz file, so upstream can browse the patches. And? You also have to untar the source .tar.gz from upstream web site... It sounds better to be able to tell upstream: patch available from http://.../the_patch.diff fixes that. Rather than: patch the_patch.diff in http://./foo.debian.tar.gz fixes that. No? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 wrote: On Sat, 17 May 2008, Joey Hess wrote: Raphael Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. You don't have to check it in revision control, you just have to be able to generate them from revision control. For .diff.gz, we already have tools to handle such files properly (without duplicating their content), it's called quilt or simple-patch-sys of CDBS and you know it (but you don' like those). For .git.tar.gz, if you have a tool to generate the patches, it would be possible to hook it into the automated system that uploads patches to patches.debian.org. If that process is not the same across all .git.tar.gz, we can mandate a new debian/rules target that must generate a debian/patches directory with all the patches. Note how infrastructure needs would decrease considerably if packages were mandated to use v3(quilt) format: patches.debian.org would be ftp.debian.org and would just need nothing new (except for how source packages are created) No, you would need to untar the .debian.tar.gz file, so upstream can browse the patches. And? You also have to untar the source .tar.gz from upstream web site... It sounds better to be able to tell upstream: patch available from http://.../the_patch.diff fixes that. Rather than: patch the_patch.diff in http://./foo.debian.tar.gz fixes that. It sounds better to send the patch directly instead of telling upstream to go to some random place to gather it. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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]
Re: How to handle Debian patches
On Sat, May 17, 2008 at 12:45:20AM +0200, Miriam Ruiz wrote: 2008/5/16 martin f krafft [EMAIL PROTECTED]: Lucas Nussbaum threw the idea of having a webpage with posisbly annotated patches for each Debian package on *.debian.org at me the other day, in response to the OpenSSL debacle. I really liked it! I think it would be a great Idea, but the point would be to be able to automate the process of uploading the patches there somehow from the package source. Combined with the idea of anotating the patches in the source packages, the result might be quite useful. I'm quite afraid that if the process is not automatic, but manual, the amount of extra work and redundancy of uploading the patches twice (once for the package, another one for the patches alone) will lead to very few developers participating, and also to desynchronization between the patches being uploaded and the real patches in the packages. As an example, I'd point to http://glandium.org/debian/teams/pkg-mozilla/mozpatches.html which I maintained a while ago, and stopped because it was too time consuming and bothersome. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, May 16, 2008 at 05:13:24PM -0500, Manoj Srivastava wrote: On Fri, 16 May 2008 23:27:03 +0300, George Danchev [EMAIL PROTECTED] said: On Friday 16 May 2008, Joey Hess wrote: 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. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. This is true, but not always handy. What you might buy is that the upstream or resp. debian user is not supposed to know for your kind of VCS (having it installed, etc) and where to find your VCS repo -- a I find this to be true for quilt too. How does one extract what the 057th patch does, without examining all the leading patches up to that point? Linearizing features and intermixing integration changes along with feature-sets is something I have always found confusing. ftp'ing of diff.gz or apt-get source pkg should be enough to get the *clearly identified patches* to the upstream source tree. I find a quilt series to not fit the bill very well. On the other hand, creating ./debian/topics/foo/ with a git-format-patch series for each branch in there might be doable -- but then, these individual patches might not apply cleanly over each other. Having to merge 30 topic branches is not a workable solution either. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On 17/05/2008, Charles Plessy wrote: Other idea: when the package is produced through a workflow that uses debian/patches, shipping them in /usr/share/doc/package/patches. Do you really want that? openoffice.org_2.4.0-6.diff.gz 82,595.1 kB Not to mention all packages where an autoreconf run is stored as a patch, I'm not sure it'll help much to install it on each and every system. Mraw, KiBi. pgpYW8aznIxvp.pgp Description: PGP signature
Re: How to handle Debian patches
Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit : diffing the tips of branches in a SCM has been far more friendly. So I find my old and new SCM's preferable to a quilt series -- since any feature can be compared to any other feature, or upstream, independently, and easily; this is terribly hard to do with quilt. Diffing the tips of branches in a SCM will not show you which lines were changed by which changeset. If you want that information - which is one of the most useful ones, because the same file can be changed for many different purposes - you need to browse your SCM's history, in which changesets are dependent on each other. Just like quilt patches. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to handle Debian patches
On 17/05/08 at 00:45 +0200, Miriam Ruiz wrote: 2008/5/16 martin f krafft [EMAIL PROTECTED]: Lucas Nussbaum threw the idea of having a webpage with posisbly annotated patches for each Debian package on *.debian.org at me the other day, in response to the OpenSSL debacle. I really liked it! I think it would be a great Idea, but the point would be to be able to automate the process of uploading the patches there somehow from the package source. Sure, I was thinking of something automated, not manual. Doing this manually would be insane :-) -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
[I'm not subscribed to debian-devel, so feel free to cc me if you want to keep me in the loop] Le samedi 17 mai 2008, à 00:19 +0200, Raphael Hertzog a écrit : On Fri, 16 May 2008, Joey Hess wrote: I can certianly see some good benefits to the lines that you're thinking, but if this turns into a pile of patches on a website that upstream has to manually go find, and rarely does, and a lot of busywork keeping the patches up-to-date, and maintaining redundant metadata ... then why would I want to use that when I can shoot a mail off to upstream with a git-format-patch in it? Certainly patches.d.o is not meant to replace direct interaction with upstream developers but it would be a nice service for upstream developers when the debian maintainer sucks (and it happens...) and also for other distributions that can benefit from our work. But when we give away patches, we also like to get patches from other back so that's why I believe that if we design any patch sharing infrastructure, we must open it from the beginning to other distributions so that we actually benefit from it too. Here are some comments, with my upstream hat: + as some people already pointed out, the current situation with diff.gz is far from being optimal. I know I'm following packages for things I maintain in major distributions to see how it's getting patched. It turns out that for debian, the only useful resource for me is http://patches.ubuntu.com/by-release/extracted/debian/ + looks like some people think a patches.debian.org wouldn't be useful. I'd bet that most upstream people would find it useful. Sure, it might not be the best approach for everybody, but at least it's dead simple for upstream. You can build upon that later. + it also seems that some debian developers would prefer the VCS way instead of patches.debian.org. Well, if all the debian packages are maintained with the same VCS, and it's easy to browse this from one place, then yes. Else, if I have to use git for $a, bzr for $b, svn for $c, hg for $d, etc., this is going to be a nightmare from my upstream point of view. (although it'd be fine, I guess, to have $vcs_a for $distro_a and $vcs_b for $distro_b -- the important point is that consistency to access patches for all packages in a given distro is key for upstream people) (On a more general note, I really believe this is something that could be solved in a cross-distro way. Being able to do lspatches --all-distros $module would rock) Vincent -- Les gens heureux ne sont pas pressés. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
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 (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. It seems to me that what we need to do is decide that using dpatch or quilt is the way to go (with properly commenting individual patches). It's a social problem, not a technical one. Once we switched to this source format, it should be trivial to create patches.debian.org. [2] Should we wait for the switch to the new source format to create patches.debian.org? It sounds like a better idea to write it in a way that makes it work with both format 1.0 and 3.0 (quilt). Maybe work from the extract source... Also, the code behind http://patches.ubuntu.com/ is GPLed, AFAIK. We might not have to reinvent everything. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote: 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. To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. The current git version of git-dch allows to automatically prefix the debian/changelog entries with git commit id's like: * [958c4b1] attach multipath.conf to bugreports * [2ac083e] make multipath-tools-boot arch all This, together with the VCS-Browser/Git fields in debian/control makes mapping the modifications to an easily reviewable patch quiet comfortable. This is only a very special case, but could certainly be done for other VCS too. -- Guido stating: - a description of the patch and its purpose - the associated bug number - who wrote the patch - where it has been forwarded upstream - sign-off by reviewers maybe All stuff that you get essentially for free by committing to a VCS. [2] And IMO we should go further than patches.d.o, we need to create a cross-distro infrastructure where we can share patches. We really have to show the way here... (we complained enough that ubuntu patches were unusable, surely we can show how to do it right when it comes to sharing patches with others and upstream) We didn't just complain that Ubuntu's patches were unusable, but that their whole means of communication of them back to upstream, ie Debian, was/is flawed. We [1] complained that automatically publishing patches was not sufficient to get those patches integrated back into Debian because -- a) People cannot be expected to poll a directory somewhere for new patches. (Which Ubuntu has partially addressed, if your proposal does, it's not clear to me specifically how.) b) Monolithic patches that make multiple changes are near-useless. (Which Ubuntu has not satisfactorally addressed, IMHO; I still get automated patch mails with multiple changes in them. Your propsal tries to address this.) c) Patches lacked explanations of why changes were made, beyond the changelog, and it was difficult to figure out more. (Which Ubuntu has not particularly addressed, and I'm not sure your proposal addresses entirely..) d) The best way to get good code is to go out and get in communication with upstream about it, explain the rationalle so that they can fully understand it, and take their advice into account. (Which Ubuntu maintainers generally still fail to do with Debian, and which your proposal doesn't really facilitate Debian doing more than we do now.) I can certianly see some good benefits to the lines that you're thinking, but if this turns into a pile of patches on a website that upstream has to manually go find, and rarely does, and a lot of busywork keeping the patches up-to-date, and maintaining redundant metadata ... then why would I want to use that when I can shoot a mail off to upstream with a git-format-patch in it? -- see shy jo [1] specifically, me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Le samedi 17 mai 2008 à 14:37 +0200, Lucas Nussbaum a écrit : If I understand things correctly (but I'm really not sure I do), 3.0 (quilt) won't really help with that: it won't prevent maintainers to directly modify files outside of debian/ , and generate a huge debian/patches/debian-changes-version.diff. It seems to me that what we need to do is decide that using dpatch or quilt is the way to go (with properly commenting individual patches). It's a social problem, not a technical one. Certainly, but dpkg-source v3 is the technical part of the solution. Packages which already use quilt will finally be distributed properly instead of containing a diff of diffs. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to handle Debian patches
On Fri, May 16, 2008 at 08:07:38PM +0200, Goswin von Brederlow wrote: Someone recently posted an example of this. IMO we should write a DEP on patch management and standardize those headers. And probably enforce their usage for patches on sensitive packages (lintian checks?). It would be nice if dpkg-source would automatically create a header template if missing and fork an editor whenever it changes a patch. Maybe add a comment section with a diffstat of the last changes that will be removed when exiting the editor for quick reference while describing the change. I don't think we need such an integration at the dpkg-source level, lintian checks are more than enough IMO. Take for examples the huge amount of dpatch-es we have in Debian. Until a few months ago they were basically *all* not commented, with a boilerplate description in dpatch header. Then lintian started complaining about missing descriptions and a lot of people [1] started commenting them. The same approach would probably work for 3.0 (quilt) dpkg format, as long as the matching lintian test exists. Cheers. [1] I haven't made any statistics, this is an empirical analysis from my recent experience: in the past all dpatches I stumbled upon uncommented patches, including packages of mine, my recent experience show the contrary. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote: To me this one proof more than even when VCS are used to maintain packages, our source packages must clearly identify the Debian patches that are applied. You're insinuatiog that a VCS does not allow easily browsing and examining patches, and I just don't buy it. This is not the point IMO. The point is that we won't be able in the near future (5 years?) to converge to a single well-known $VCS, there are just too many, and we can't require all free software eyes to grok it. On the contrary it is the case that a list of (sequential) .diff files are understandable by whoever is manipulating free software source code. So yes, in this respect I concur that a set of published (though commented!) patches is better than $VCS. Cheers. PS I'm also convinced that 10 years from now the free software world will have converged on git, but this is a different story -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: [I'm not subscribed to debian-devel, so feel free to cc me if you want to keep me in the loop] done. + it also seems that some debian developers would prefer the VCS way instead of patches.debian.org. Well, if all the debian packages are maintained with the same VCS, and it's easy to browse this from one place, then yes. Else, if I have to use git for $a, bzr for $b, svn for $c, hg for $d, etc., this is going to be a nightmare from my upstream point of view. (although it'd be fine, I guess, to have $vcs_a for $distro_a and $vcs_b for $distro_b -- the important point is that consistency to access patches for all packages in a given distro is key for upstream people) We will never ever harmonize on one vcs in Debian. Don't dream of it, it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_ but I know quite a few Ubuntu developers that use git instead so…). FWIW I agree that the .diff.gz is a terrible way of exposing our modifications to the world, espcially since all is meld into that (debian/ specific changes not meant to be merged upstream like packaging stuff, or real patches that upstream should probably take). That's exactly why while I'm doing most of my work in git, I try to export patches in debian/patches sanely, and I usually also export a git branch, trivially browsable through my git.madism.org gitweb, hence without _any_ git knowledge, for upstreams to cherry-pick from. Sadly not everyone agrees that serializing changes we do is the way to go, and the latter (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. The sole thing that can work is that the source package is good enough for everyone wanting to grok what is in our packages, because that's the _SOLE_ thing everyone still uses in the end. Our source format is our common point, it's the best place to make things like that happen. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpikxjuGMyyw.pgp Description: PGP signature
Re: How to handle Debian patches
Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit : On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: [I'm not subscribed to debian-devel, so feel free to cc me if you want to keep me in the loop] done. + it also seems that some debian developers would prefer the VCS way instead of patches.debian.org. Well, if all the debian packages are maintained with the same VCS, and it's easy to browse this from one place, then yes. Else, if I have to use git for $a, bzr for $b, svn for $c, hg for $d, etc., this is going to be a nightmare from my upstream point of view. (although it'd be fine, I guess, to have $vcs_a for $distro_a and $vcs_b for $distro_b -- the important point is that consistency to access patches for all packages in a given distro is key for upstream people) We will never ever harmonize on one vcs in Debian. Don't dream of it, it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_ but I know quite a few Ubuntu developers that use git instead so…). Sorry, my point wasn't clear: I'm not suggesting that Debian developers should harmonize on one vcs. I was merely saying that if multiple vcs are used, you shouldn't expect upstream to be happy about having to go to multiple places to find the patches for debian packages (unless all those places are integrated in some way in one unique place afterwards). FWIW I agree that the .diff.gz is a terrible way of exposing our modifications to the world, espcially since all is meld into that (debian/ specific changes not meant to be merged upstream like packaging stuff, or real patches that upstream should probably take). That's exactly why while I'm doing most of my work in git, I try to export patches in debian/patches sanely, and I usually also export a git branch, trivially browsable through my git.madism.org gitweb, hence without _any_ git knowledge, for upstreams to cherry-pick from. Sadly not everyone agrees that serializing changes we do is the way to go, and the latter (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. It's not about git knowledge (which is also an important point, but the web interfaces makes it easy to solve it), it's about having to go to git.madism.org for one debian package, git.blabla.org for another debian package and then bzr.blablabla.org for a third debian package. Having a central place helps. The sole thing that can work is that the source package is good enough for everyone wanting to grok what is in our packages, because that's the _SOLE_ thing everyone still uses in the end. Our source format is our common point, it's the best place to make things like that happen. Kind of agree, yes. Except that when I check the patches for 10 modules I maintain in 5 distros, I find it more convenient to have something like http://patches.ubuntu.com/, http://cvs.fedoraproject.org/viewcvs/ or http://sources.gentoo.org/viewcvs.py/gentoo-x86/ to quickly look at everything. (but I'd be the first to agree that this method is suboptimal too and that all distros could do a better job) Just my €0.02 :-) Vincent -- Les gens heureux ne sont pas pressés. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Le Sat, May 17, 2008 at 11:36:00AM +0200, Cyril Brulebois a écrit : On 17/05/2008, Charles Plessy wrote: Other idea: when the package is produced through a workflow that uses debian/patches, shipping them in /usr/share/doc/package/patches. Do you really want that? openoffice.org_2.4.0-6.diff.gz 82,595.1 kB Not to mention all packages where an autoreconf run is stored as a patch, I'm not sure it'll help much to install it on each and every system. Salut Cyril, obviously, if nobody thinks it is a good idea, I will not go further. Nevertheless, none of the 100 packages we maintain in debian-med have 80 Mo of patches, nor do autofoo gizmo through patches instead of using the autotools-dev packages, but maybe I am mislead by our particular microcosm... Bon week-end, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Guillem Jover [EMAIL PROTECTED] writes: On Fri, 2008-05-16 at 15:49:25 -0700, Russ Allbery wrote: That would work, although it does... well, not double, but at least increase the work for any branch that also has a submission branch, since any upstream merge conflicts have to be resolved on both branches. Or is there some way to reuse the resolution work done with one of those branches when rebasing/merging the other? Check 'man git-rerere'. Oh, wow. Yes, that looks like exactly what I'm looking for. -- 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: How to handle Debian patches
On Saturday 17 May 2008, Vincent Untz wrote: Le samedi 17 mai 2008, à 15:24 +0200, Pierre Habouzit a écrit : On Sat, May 17, 2008 at 12:07:43PM +, Vincent Untz wrote: [I'm not subscribed to debian-devel, so feel free to cc me if you want to keep me in the loop] done. + it also seems that some debian developers would prefer the VCS way instead of patches.debian.org. Well, if all the debian packages are maintained with the same VCS, and it's easy to browse this from one place, then yes. Else, if I have to use git for $a, bzr for $b, svn for $c, hg for $d, etc., this is going to be a nightmare from my upstream point of view. (although it'd be fine, I guess, to have $vcs_a for $distro_a and $vcs_b for $distro_b -- the important point is that consistency to access patches for all packages in a given distro is key for upstream people) We will never ever harmonize on one vcs in Debian. Don't dream of it, it just won't work. Even Ubuntu can't do that (okay they use bzr a _lot_ but I know quite a few Ubuntu developers that use git instead so…). Sorry, my point wasn't clear: I'm not suggesting that Debian developers should harmonize on one vcs. I was merely saying that if multiple vcs are used, you shouldn't expect upstream to be happy about having to go to multiple places to find the patches for debian packages (unless all those places are integrated in some way in one unique place afterwards). I absolutely agree with you. Moreover DDs still can use their favourite VCS to maintain their packaging, but that does not mean that upstream developers and debian users should be forced to follow DD everywhere. See below. I maintain in 5 distros, I find it more convenient to have something like http://patches.ubuntu.com/, http://cvs.fedoraproject.org/viewcvs/ or http://sources.gentoo.org/viewcvs.py/gentoo-x86/ to quickly look at everything. (but I'd be the first to agree that this method is suboptimal too and that all distros could do a better job) Ok, here is an extremely simple approach you can follow ;-). You don't need any special patches.d.o fancy web cruft, you don't need to know about the favourite VCS of any particular DD either or their favourite debian-patch-sys ;-). You can have the patches applied to the upstream source code version currently found in Debian (you are not so interested about the past ones, since they were merged upstream) by simply fetching debian diff.gz from packages.d.o/pkg. Now comes the most stressful part: that diff.gz contains the debian packaging files and the changes done to the upstream source code. The Debian packaging files might not be of any particular importance to you, but the changes applied to the upstream source are, so it is best having a separate diff file for any logical change to the upstream code being done... and you are done! If that is not the case and you find yourself bored while fighting with one single monster blob of multiple logical changes being applied in a combined fashion to the upstream tree, you should fall-back to debian/control at least to have a clue how to visit the packager's favourite VCS repo. Meantime, you might learn that there is a new VCS invented and you should read some docs, but you shouldn't be unlucky since you will finally find the patches applied to a particular upstream tree of yours ;-) -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette [EMAIL PROTECTED] said: Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit : diffing the tips of branches in a SCM has been far more friendly. So I find my old and new SCM's preferable to a quilt series -- since any feature can be compared to any other feature, or upstream, independently, and easily; this is terribly hard to do with quilt. Diffing the tips of branches in a SCM will not show you which lines were changed by which changeset. If you want that information - which is one of the most useful ones, because the same file can be changed for many different purposes - you need to browse your SCM's history, in which changesets are dependent on each other. Just like quilt patches. I think you need to look at man git-blame. Or baz annotate. Or hg annotate. Or svn annotate. Or even cvs annotate. Gee, I guess RCS does not have the functionality, but how many people use RCS for version control? So no, modern SCMs do let you find out about who changed what line, though in practice I have rarely, if ever, used it. Is there a quilt annotate/blame around? manoj -- Someone's been mean to you! Tell me who it is, so I can punch him tastefully. Ralph Bakshi's Mighty Mouse 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: How to handle Debian patches
On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said: (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. Don't you think that Vcs-Browse and Vcs-$SCN headers are normalized ways for telling end users where to get the development sources from? We might want to see if we should shipt the VCS-* headers in the Packages file, but I thought we are trying to standardize publication of DVCS repositories in Debian now. manoj -- Alimony is like buying oats for a dead horse. Arthur Baer 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: How to handle Debian patches
On Sat, May 17, 2008 at 11:51:22AM -0500, Manoj Srivastava wrote: On Sat, 17 May 2008 11:40:43 +0200, Josselin Mouette [EMAIL PROTECTED] said: Le vendredi 16 mai 2008 à 17:08 -0500, Manoj Srivastava a écrit : diffing the tips of branches in a SCM has been far more friendly. So I find my old and new SCM's preferable to a quilt series -- since any feature can be compared to any other feature, or upstream, independently, and easily; this is terribly hard to do with quilt. Diffing the tips of branches in a SCM will not show you which lines were changed by which changeset. If you want that information - which is one of the most useful ones, because the same file can be changed for many different purposes - you need to browse your SCM's history, in which changesets are dependent on each other. Just like quilt patches. I think you need to look at man git-blame. Or baz annotate. Or hg annotate. Or svn annotate. Or even cvs annotate. Gee, I guess RCS does not have the functionality, but how many people use RCS for version control? OT, but while pristine RCS doesn't have that, there is a tool to just do it for RCS managed files: http://blame.sourceforge.net/ So no, modern SCMs do let you find out about who changed what line, though in practice I have rarely, if ever, used it. What could be useful, and doesn't exist, though, is a functionality to blame diffs (i.e. something displaying in what commits a line removal or a line addition happened). Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Sat, 17 May 2008 09:07:08 +0200, Mike Hommey [EMAIL PROTECTED] said: I find a quilt series to not fit the bill very well. On the other hand, creating ./debian/topics/foo/ with a git-format-patch series for each branch in there might be doable -- but then, these individual patches might not apply cleanly over each other. Having to merge 30 topic branches is not a workable solution either. I personally do not have a package with 30 topic branches. I have had ones with about 10 or so, though none at the moment. But in each topic branch, there are more than one patches -- I like having one patchset that makes a change, but still compiles and works, and then the next patchset, until I have the functionality needed for the topic branch. This breaking up the topic branch into separate, small, individually documented patches helps understanding; and does not create an explosion of branches -- all these patches are on the same topic. To do the same in quilt, by maintaining patchsets into small, easily understandable, but working chunks, we'll have to keep these patches separate -- which is why we can get away with fewer branches than we can with quilt patches. Or else make our quilt patches less easy to understand and test. manoj -- Be urgent in good; hold your thoughts off evil. When one is slack in doing good the mind delights in evil. 116 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: How to handle Debian patches
George Danchev wrote: Then comes even more, even Ben Laurie (as he writes in his blog) with all his aggression missed to find the debian's pkg-openssl VCS repo [1] unless he has been helped by someone at some point. I'm not against the VCS repo (I myself use some for my packaging), I just claim that you can expect that random upstream developers and random debian users know about it, they need instead extremely simple and stable interfaces to access the changes to their upstream source currently found in Debian archive, and we already have that for years. The openssl package is missing a Vcs-Svn field. If it had one it would be pretty easy to find its svn repo. I think it's about time to file mass bugs on whatever packages are left that use version control and lack the fields. -- see shy jo signature.asc Description: Digital signature
Re: How to handle Debian patches
On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote: In fact, despite being one of the big quilt advocates in the last round of this discussion, I am at this point pretty much sold on using Git due to its merges and branch support and have started to switch my packages over. However, the one thing discussed on this thread is still the thing I don't know how to do easily in Git. I have each logical change on its own branch, so I can trivially generate patches to feed to upstream with git diff upstream..bug/foo, but I don't know how to maintain a detailed description and status other than keeping a separate file with that information somewhere independent of the branch, or some special file included in the branch. How often is a logical change more than just a single commit? Espeically in the context of packaging, usually the changes are pretty trivial, and don't require multiple patches. Sure, a few bugs may require some new infrastructure, or making changes that would be best done with 2-3 patches, but any more than that and you probably want to be consulting with upstream before submit any changes anyway? So normally I just keep those sorts of changes in the commit header, where it is easily and safely bundled with each patch. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Saturday 17 May 2008, Joey Hess wrote: George Danchev wrote: Then comes even more, even Ben Laurie (as he writes in his blog) with all his aggression missed to find the debian's pkg-openssl VCS repo [1] unless he has been helped by someone at some point. I'm not against the VCS repo (I myself use some for my packaging), I just claim that you can expect that random upstream developers and random debian users know about it, they need instead extremely simple and stable interfaces to access the changes to their upstream source currently found in Debian archive, and we already have that for years. The openssl package is missing a Vcs-Svn field. If it had one it would be pretty easy to find its svn repo. I agree if we assume that Ben is willing to have that particular VCS installed or there is a simple web interface (most do) to the repo. What could be of great boredome for poor Ben and other possibly sharp eyes is that they should look back in the history to find out what patches has been applied to what source tree or export the debian's HEAD and diff it against the latest upstream source they have (please I don't need examples how various VCS'es rock comparing btw repos;-). Then again, we end up having all these logically separate changes (if any/many of them) in a combined fashion. If there were clearly separeted diffs in debian/patches/ is would be much easier for peer reviewers to take a look at them without the help of VCSes and their web interfaces. I think it's about time to file mass bugs on whatever packages are left that use version control and lack the fields. I agree. P.S. I don't blame openssl packaging, since I know how much valuable work has been done for Debian by these people. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Raphael Hertzog wrote: A VCS surely allows browsing and examining patches. But when I dig in a VCS history, it's because I have something precise to look up, I will rarely check it ouf of curiosity. debian/patches/ on the contrary is something that gets my attention when I unpack a source package. That's just a matter of personal preference; if I'm coming up to speed on a package, the first thing I do is check out its version control and read it. But expecting upstream do do either of these things is not going to result in a lot more upstreams seeing patches and prevent the next openssl disaster. In either case upstream will have to choose to wade through lots of changes that are not interesting to them, instead of looking at the next [PATCH] in their inbox. Certainly patches.d.o is not meant to replace direct interaction with upstream developers but it would be a nice service for upstream developers when the debian maintainer sucks (and it happens...) and also for other distributions that can benefit from our work. But when we give away patches, we also like to get patches from other back so that's why I believe that if we design any patch sharing infrastructure, we must open it from the beginning to other distributions so that we actually benefit from it too. Well, my experience with dealing with sorting through patches from other distributions trying to find useful changes to apply to my packages, either in Debian, or as upstream, is that it's generally a net time loss. And conversely, as upstream I'm git-aming patches emailed to me every day from people from all over, including other distributions, and that works quite well. The quality of the patches is often high since they are worked up to the point to be submitted upstream. And if a patch has problems, or if I don't understand it, I can immediatly talk to the person who developed it. -- see shy jo signature.asc Description: Digital signature
Re: How to handle Debian patches
Theodore Tso wrote: How often is a logical change more than just a single commit? I think the most common case for me is when I need to bring the change forward to new upstream versions (with conflicts). In that case, I'll end up with multiple commits in the VCS hostory for the change. So normally I just keep those sorts of changes in the commit header, where it is easily and safely bundled with each patch. Ditto, and if I find that I've needed multiple commits for a logical change, I break it out into a feature branch at that point. -- see shy jo signature.asc Description: Digital signature
Re: How to handle Debian patches
Raphael Hertzog wrote: On Fri, 16 May 2008, Joey Hess wrote: Coming up with a complex set of requirements that everyone has to follow up front in their workflow[1] is not going to yeld the best results, and I think that's my core reason for disliking Raphael's proposal. Now, if you can come up with protocols/interfaces that can be used to publish/communicate patches, that are managed/generated in whatever way is most useful for the maintainer, that seems more likely to work. Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. -- see shy jo signature.asc Description: Digital signature
Re: How to handle Debian patches
Le samedi 17 mai 2008 à 11:51 -0500, Manoj Srivastava a écrit : Diffing the tips of branches in a SCM will not show you which lines were changed by which changeset. If you want that information - which is one of the most useful ones, because the same file can be changed for many different purposes - you need to browse your SCM's history, in which changesets are dependent on each other. Just like quilt patches. I think you need to look at man git-blame. Or baz annotate. Or hg annotate. Or svn annotate. Or even cvs annotate. Geez, you’re comparing apples and oranges. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to handle Debian patches
Le samedi 17 mai 2008 à 15:12 -0400, Joey Hess a écrit : Aren't patch files in debian/patches/ with some headers a defined interface? It's an interface, that if you stop there in defining it, means that I have to check debian/patches/ into revision control, and bloat my .diff.gz or .git.tar.gz (depending on whether I'm using v1 or v3 source) with them. Are you deliberately omitting the sane formats to distribute patched debian sources that are implemented? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: How to handle Debian patches
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: George Danchev wrote: Then comes even more, even Ben Laurie (as he writes in his blog) with all his aggression missed to find the debian's pkg-openssl VCS repo [1] unless he has been helped by someone at some point. I'm not against the VCS repo (I myself use some for my packaging), I just claim that you can expect that random upstream developers and random debian users know about it, they need instead extremely simple and stable interfaces to access the changes to their upstream source currently found in Debian archive, and we already have that for years. The openssl package is missing a Vcs-Svn field. If it had one it would be pretty easy to find its svn repo. It would be nice that there was some kind of ducomentation on what people might want to put in the control file that isn't in policy, like those Vcs- things, Homepage, ... Similar, things like a watch file in all packages that can have one would be great. As far as I know, they're all documented in the developers reference. But I don't know of a list or recommended things a package should have. What I find handy about policy is that we have a version we put in the control file, and it has a nice upgrading checklist so that you know what changed since the last time. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Josselin Mouette wrote: Are you deliberately omitting the sane formats to distribute patched debian sources that are implemented? I'm talking about the formats that I expect to be using. The implication thst I'm somehow insane is not very useful. -- see shy jo signature.asc Description: Digital signature
Re: How to handle Debian patches
On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said: (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. Don't you think that Vcs-Browse and Vcs-$SCN headers are normalized ways for telling end users where to get the development sources from? For devel sources yes. Sadly, this won't give you the straight URL to what upstream are interested in. We might want to see if we should shipt the VCS-* headers in the Packages file, but I thought we are trying to standardize publication of DVCS repositories in Debian now. Well, that's not needed, that could be really easily used in a patches.d.o service like Vincent is asking for. Though even with VCS-* headers, it's still hard to _automatically_ present things coherently enough for automated tools to do some useful reports. OTOH such tools could be written for each VCS there aren't _that_ many of them (I mean, compared to the number of bug-trackers out there, bts-link showed such a task is doable). but again, even grokking the VCS isn't enough, you'll have to know where the maintainer put things in the first place. ANd here, grokking git isn't enough. *I* don't even use the same name for all my packages, I don't expect it to be more coherent for _different_ packagers. All in all, pointing to VCSes is just making things harder, because you fight against direct product of VCSes, workflows, and almost packages. And no tool is really gonna sort that out. OTOH, if we _do_ mandate people to one way or another serialize their patches in the source format, with comments and all that stuff, then it _IS_ a good thing, because that's the kind of things that can be grokked by tools trivially. And for that, the v3 format goes in the proper direction. I think people want to solve many problems, that happen to coincide locally, but are quite different in the end. I see three of them: * how to have packages that everyone can modify for NMUs and security updates, where it's obvious to anyone what the packager did. I know _you_ don't care about that [citation needed -- but it's not hard to find ;p] but I think it's a very important goal. * how to let upstreams be able to know what we do to their babies, even when we don't have time (or are too lazy to fight against the 128 steps needed to submit a damn patch in their bugzilla[1]) to send patches back, be able to see what we didn't sent yet easily, and automatically (and with a finer grained method than the .diff.gz please). * maintaining history of the patches, and how to they evolve for long-lived patches. Which is a discussion that generates long tro^H^H^Hfla^H^H^Hdiscussions on the vcs-pkg list. Too many people are in fact only considering the (3rd) issue because that's clearly the one that is mind challenging and I'd even say interesting. Though, sorry to try to try (I don't really think _you_'ll agree ...) to bring you back to earth, but the 1st and 2nd points are the utterly important ones, by far. How do we have nicer histories in our VCSes is just clever and twisted bikeshedding (that I'm clearly happy to participate in, because I'm a pervert and I like that), but it's not what matters. What matters for real, is how simple it is for other DD to fix our packages when we're absent, or when we don't want to maintain a package anymore, and how easy and automatic collaboration with upstream is. The VCS rebase vs. merge vs. patch queues vs. diff.gz discussions are just cherry on the top. [1] FWIW that's exactly what often makes me forget about reporting a patch. Bugzilla really really really sucks badly for the reporter, the Debian BTS is _way_ better in that regard. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptiQvAXwrv6.pgp Description: PGP signature
Re: How to handle Debian patches
On Sat, May 17, 2008 at 07:05:20PM +, Joey Hess wrote: And conversely, as upstream I'm git-aming patches emailed to me every day from people from all over, including other distributions, and that works quite well. The quality of the patches is often high since they are worked up to the point to be submitted upstream. And if a patch has problems, or if I don't understand it, I can immediatly talk to the person who developed it. that works if upstream uses this kind of decentralized way of working, where sending a patch to a list or a developper works. Some upstreams will tell you to send the patch to a bugzilla, where someone will probably eventually commit it, one day or the other (year). Not all upstreams are linux, git, ikiwiki or similar communities. Some other are glibc, mozilla, put your nicest upstream here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpvYsIUgGmeu.pgp Description: PGP signature
Re: How to handle Debian patches
On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said: (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. Don't you think that Vcs-Browse and Vcs-$SCN headers are normalized ways for telling end users where to get the development sources from? For devel sources yes. Sadly, this won't give you the straight URL to what upstream are interested in. We might want to see if we should shipt the VCS-* headers in the Packages file, but I thought we are trying to standardize publication of DVCS repositories in Debian now. Well, that's not needed, that could be really easily used in a patches.d.o service like Vincent is asking for. Though even with VCS-* headers, it's still hard to _automatically_ present things coherently enough for automated tools to do some useful reports. OTOH such tools could be written for each VCS there aren't _that_ many of them (I mean, compared to the number of bug-trackers out there, bts-link showed such a task is doable). but again, even grokking the VCS isn't enough, you'll have to know where the maintainer put things in the first place. ANd here, grokking git isn't enough. *I* don't even use the same name for all my packages, I don't expect it to be more coherent for _different_ packagers. All in all, pointing to VCSes is just making things harder, because you fight against direct product of VCSes, workflows, and almost packages. And no tool is really gonna sort that out. OTOH, if we _do_ mandate people to one way or another serialize their patches in the source format, with comments and all that stuff, then it _IS_ a good thing, because that's the kind of things that can be grokked by tools trivially. And for that, the v3 format goes in the proper direction. s/the v3 format/the v3 quilt format/ Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote: On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: All in all, pointing to VCSes is just making things harder, because you fight against direct product of VCSes, workflows, and almost packages. And no tool is really gonna sort that out. OTOH, if we _do_ mandate people to one way or another serialize their patches in the source format, with comments and all that stuff, then it _IS_ a good thing, because that's the kind of things that can be grokked by tools trivially. And for that, the v3 format goes in the proper direction. s/the v3 format/the v3 quilt format/ Err yes. I indeed think the other v3 formats are somehow insane. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpeEDXEZWvA8.pgp Description: PGP signature
Re: How to handle Debian patches
Pierre Habouzit [EMAIL PROTECTED] writes: On Sat, May 17, 2008 at 05:04:56PM +, Manoj Srivastava wrote: On Sat, 17 May 2008 15:24:13 +0200, Pierre Habouzit [EMAIL PROTECTED] said: (publishing my branch in a gitweb) isn't normalized, and won't probably ever be, or not under this form. Don't you think that Vcs-Browse and Vcs-$SCN headers are normalized ways for telling end users where to get the development sources from? For devel sources yes. Sadly, this won't give you the straight URL to what upstream are interested in. The syntax for the fields also does not currently let you specify a branch or tag, it's just the whole repo. Personally, I'd like it to allow specification of the branch/tag used to produce the specific release of the package in Sources.gz (or better, the latest development on that branch). For example: Vcs-Git: git://git.debian.org/git/buildd-tools/schroot This gives you the master branch, but the Debian packages are actually on the schroot-1.2 stable release branch. For people who want to hack on what's actually in use in Debian testing/unstable right now, this is the wrong branch. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpv0rGQMOJbh.pgp Description: PGP signature
Re: How to handle Debian patches
Theodore Tso [EMAIL PROTECTED] writes: On Fri, May 16, 2008 at 03:25:11PM -0700, Russ Allbery wrote: In fact, despite being one of the big quilt advocates in the last round of this discussion, I am at this point pretty much sold on using Git due to its merges and branch support and have started to switch my packages over. However, the one thing discussed on this thread is still the thing I don't know how to do easily in Git. I have each logical change on its own branch, so I can trivially generate patches to feed to upstream with git diff upstream..bug/foo, but I don't know how to maintain a detailed description and status other than keeping a separate file with that information somewhere independent of the branch, or some special file included in the branch. How often is a logical change more than just a single commit? Espeically in the context of packaging, usually the changes are pretty trivial, and don't require multiple patches. They often are just a single commit (although there are some exceptions), but I often need to update the patch description to include more information long after I originally wrote the patch. I like to note current upstream reactions and thinking, maybe target version numbers, and that sort of thing. I could so that with Manoj's idea of a separate submit branch for each one of those, since that one I'm rebasing anyway and can use git commit --amend or something similar to change old log messages without worrying about breaking things. That does require creating the separate submit branches, though; I don't think (unless I'm missing something) that I could do that with my topic branches without creating some of the same problems as rebasing, since changing the commit message makes the commit a different commit. Sure, a few bugs may require some new infrastructure, or making changes that would be best done with 2-3 patches, but any more than that and you probably want to be consulting with upstream before submit any changes anyway? The patches that I carry relative to upstream frequently *are* done with considerable consultation with upstream and are cherry-picked from upstream, but I still want to track them and I still want upstream to know what I've cherry-picked, and in general to be able to use the same infrastructure I'd use for patches that weren't done in consultation with upstream. -- 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: How to handle Debian patches
On Sat, May 17, 2008 at 02:26:29PM -0400, Joey Hess wrote: I think it's about time to file mass bugs on whatever packages are left that use version control and lack the fields. Unfortunately this is not easy to do, as least not as mass bug filing. Point is that it is not easy to spot which packages are actually maintained using a $VCS. I did an approximation of that crossing data coming from svnbuildstat with Vcs-* information, see http://upsilon.cc/~zack/stuff/vcs-urls/ . But it has serious limitations: it is Svn specific and only for packages registered under svnbuildstat.debian.net. You can imagine harvesting alioth.d.o and extracting all debian/control stored in whatever $VCS you find there, but you can't be sure if this is the currently used $VCS, if there are other versions of the package versioned elsewhere, ... Plenty of room for false positives. Even lintian won't be able to help much here, as VCS-specific info are usually not even in the source package (unless you want to warn for all packages lacking a Vcs-* field, no matter what). Still, it is a good idea to start diffusing the culture of manually filing bugs against version controlled packages lacking the field. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: How to handle Debian patches
On 17/05/08 at 23:00 +0200, Pierre Habouzit wrote: On Sat, May 17, 2008 at 08:49:39PM +, Mike Hommey wrote: On Sat, May 17, 2008 at 10:40:53PM +0200, Pierre Habouzit wrote: All in all, pointing to VCSes is just making things harder, because you fight against direct product of VCSes, workflows, and almost packages. And no tool is really gonna sort that out. OTOH, if we _do_ mandate people to one way or another serialize their patches in the source format, with comments and all that stuff, then it _IS_ a good thing, because that's the kind of things that can be grokked by tools trivially. And for that, the v3 format goes in the proper direction. s/the v3 format/the v3 quilt format/ Err yes. I indeed think the other v3 formats are somehow insane. 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. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: How to handle Debian patches
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 of having support for multiple source formats in dpkg-source, and allowing it to extract any of those formats, and build a source package using any of those formats, is to allow multiple formats to be used. What you're suggesting is equivilant to us deciding by GR which helper system can be used in the rules file. It would stifle any futher innovation in source formats. That's a particularly cruel thing to do when such innovation is just getting started after an interminable period of stasis. -- see shy jo signature.asc Description: Digital signature
