Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
m...@linux.it (Marco d'Itri) writes: On May 18, Russ Allbery r...@debian.org wrote: I do this work in cases where keeping the patches separate is useful for some reason, but mostly it's not. Some of my packages have 30-60 patches (mature software...), and merging them would make them impossibile to understand. Is there a VCS workflow which would make such packages easier to manage than with quilt? (I like quilt, BTW.) -- ciao, Marco Check out gitpkg. It has hooks to create the quilt patches from a set of feature branches in some form. Also note that in this scheme where you produce a single debian patch you would not be working on the single debian patch. You would still work on your 30-60 feature branches (or whatever else you use instead of a patch queue). The single debian patch would just be the fallback for people that can't access your VCS. The single patch would be hard to understand but it would be unfair to compare it to 30-60 patches in a patch queue. What you have to compare the single patch with is a single debian diff.gz. Obviously if you can make a meaningfull patch queue with seperate patches that is preferable. The single patch method is for situations where you can't. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5o7mj4t.fsf@frosties.localnet
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
m...@linux.it (Marco d'Itri) writes: On May 18, Russ Allbery r...@debian.org wrote: I do this work in cases where keeping the patches separate is useful for some reason, but mostly it's not. Some of my packages have 30-60 patches (mature software...), and merging them would make them impossibile to understand. Is there a VCS workflow which would make such packages easier to manage than with quilt? (I like quilt, BTW.) In cases like that where quilt is already doing what I want, I've been known to just check the patches into Git and make sure that I only do git commits after quilt pop -a. I do that with our local builds of Heimdal, for example. There are more complicated things that let you serialize your patches from Git commits and turn them into quilt patch sets, but they're mostly ways to do something quilt-like in Git while avoiding using quilt directly. If you're comfortable using quilt directly, I'm not sure they'll buy you anything. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr46yqdy@windlord.stanford.edu
RE : Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
gitpkg with quilt hook is very nice. Have a branch with debian change, one for patch queue, one for upstream Use git cherry pick for porting patch I use it for imagemagick Will post my workflow tomorrow I post from my phone, sorry for top post and brievety Bastien Le 21 mai 2012 02:56, Marco d'Itri m...@linux.it a écrit : On May 18, Russ Allbery r...@debian.org wrote: I do this work in cases where keeping the patches... Some of my packages have 30-60 patches (mature software...), and merging them would make them impossibile to understand. Is there a VCS workflow which would make such packages easier to manage than with quilt? (I like quilt, BTW.) -- ciao, Marco
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On May 18, Russ Allbery r...@debian.org wrote: I do this work in cases where keeping the patches separate is useful for some reason, but mostly it's not. Some of my packages have 30-60 patches (mature software...), and merging them would make them impossibile to understand. Is there a VCS workflow which would make such packages easier to manage than with quilt? (I like quilt, BTW.) -- ciao, Marco signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski kilob...@angband.pl writes: On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote: On 05/17/2012 04:52 PM, Gergely Nagy wrote: I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. Doing that is the most stupid idea ever. All it does is to ensure that you package can't be NMUed sanely and that people who need to work with the sources I have to say you are saddly mistaken there. Just because you use a single patch under debian/patches and do not track it in git in no way prevents the debian source package to work as expected. Everybody can download the source package, build it, NMU it, whatever. All he is saying is that when building from git all upstream changes not covered by existing patches shall go into debian/patches/debian-changes (instead of debian/patches/debian-changes-version) and not to track this automatically generated file in git. Which is totaly sane. and your patches for whatever reason have to clone your git, which might be not available or just too large for them to download - so at the end changes are high that they end up with a largish unreadable patch, similar to the mess we get from Ubuntu sometimes. The only thing that makes sense would be to use git-format-patch to export your patches to debian/patches and list them in the series file. Or use gbp-pq, which was made exactly for that. Uhm, please switch around git and quilt, and say that again. Uhm, no. That is besides the point. Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, this ends up with no end of woe. Quilt sprinkles its modifications around the source, breaks timestamps causing unnecessary rebuilds, breaks basic VCS abilities like bisection, makes it really hard to even review history, and so on. You complain about forcing people to use git, while you push quilt onto everyone else. And while git can do every single thing quilt can do, the reverse is thoroughly untrue. I really wish there was a 3.0 format besides 3.0 (quilt), so people are not mislead into thinking they have to (or even, would gain anything) from writing patches in quilt's format. And you too are totaly missing the point of the exercise. The point of the described setup was so that people do not have to write patches in quilt's format. The described setup gives you a 3.0 (quilt) format where quilt plays no part in your workflow and thus does not interfere with the VCS. The resulting source package that gets uploaded will use quilt but you as VCS user don't have to care about it. All the benefits of the 3.0 format without the (imho mostly imagined) quilt problems. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87likok4oi.fsf@frosties.localnet
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski kilob...@angband.pl writes: On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. How come? If the .git directory shipped in the package is pruned, there is no hidden data. All you have to review are commits that are present there, which is exactly the same as with quilt: you need to review the tarball and every single patch. And there you have hit the problem. If the history is pruned to just the latest version then it is pointless. All you end up is a bunch of branches without history that randomly lack their interconnections and a master branch that again lacks the interconnections to the feature branches. Any change to a feature branch will likely cause a merge conflict when you try to merge it to master because the history of past conflict resolutions is missing. And if you do keep enough history to preserve the interconnections between branches then ftp-master has to review all that history. Note: if the pruned feature branches do not cause merge conflicts then you have a set of features that is trivialy serializable (since it has no dependencies on the order) and your feature branches are identical to a set of patch files. So you have gained nothing of 3.0 (quilt). There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, There's a whole world between shallow clones and complete ones. While existing git porcelain provides no convenient tools to selectively shallowify a repository, this is because no one had that need before. For example, if you limit yourself to a bunch of linear rebased commits atop Sorry, but if you rebase you have already lost. Rebase destroys history and makes the commit a one-shot deal. You will not have continuity. Rebase is something you can use internally or to create a serilaized patch queue but not something to distribute to the world. of the newest upstream tag, you can exactly emulate quilt workflow except for not having to deal with quilt's peculiarities. This goes to the point of shipping EXACTLY the same data as quilt would, with only metadata different[1]. And unlike what you say, commits are not flattened in any way. If you manage to get your git branches serialized and rebased to the point of shipping EXACTLY the same data as quilt would then there really is no point of not shipping the data as quilt would. At that point you have destroyed any benefits of git but are still forcing the much more complex git format on people instead of a simple patch queue (which doesn't even need quilt or quilt knowledge to use). If we allow non-linear Debian changes (ie, merged not rebased, etc), there is indeed a complex question: where to cut[2]. But even then, a given commit is either present or not. If too much old history is there, that's no different from the upstream shipping an old tarball and a pile of patches upon it (like ancient apache or qmail). And if we don't allow non-linear Debian changes then there is 0 benefit from not using 3.0 (quilt) format. Once you have gotten your changes serialized (linear) it is absolutely trivial to automatically create a 3.0 (quilt) format package from your git repository at no loss (other than the history you were going to prune anyway). That's what for example gitpkg does. And besides, what's the reason behind enforcing exactly one upstream and exactly one Debian? This just leads to problems if either side has multiple layers. and it's not horribly clear what the advantages of 3.0 (git) are at that point. Many of the really compelling use cases for 3.0 (git), neat stuff like possibly being able to just push a signed tag instead of uploading or having the package history when you get the source package, aren't very interesting with shallow clones. It's more a psychological issue: while you can use 3.0 (quilt) to emulate 1.0, people don't know about that. Even though 6500 of packages in Debian store their packaging in git, they typically fight with quilt, while that shallow copy = single-debian-patch would at least remove that concern. It would just lead to people fighting with git. As you say the 3.0 (quilt) problem is more a psychological issue. The solution isn't to switch to a much more complex tool like git but to teach people
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hello, On Thu, 17 May 2012 16:52:02 +0200 Gergely Nagy alger...@balabit.hu wrote: Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. I find it a very bad idea, as then it's very hard to track what patches we have applied. And no, VCS history doesn't help at all as we see *all* the patches ever applied or not, and also upstream changes sometimes. For that reason I prefer keeping patches themselves tracked as well, or I even (mostly) unapply them so the source in the VCS is clean. -- WBR, Andrew signature.asc Description: PGP signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On 05/17/2012 04:52 PM, Gergely Nagy wrote: Chris Knadle chris.kna...@coredump.us writes: On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. Doing that is the most stupid idea ever. All it does is to ensure that you package can't be NMUed sanely and that people who need to work with the sources and your patches for whatever reason have to clone your git, which might be not available or just too large for them to download - so at the end changes are high that they end up with a largish unreadable patch, similar to the mess we get from Ubuntu sometimes. The only thing that makes sense would be to use git-format-patch to export your patches to debian/patches and list them in the series file. Or use gbp-pq, which was made exactly for that. [...] Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). Which again requires people to find and clone the git instead of just looking what we ship on our mirrors and discs. Remember, there are people without (fast) internet, they might not be able to clone your git, or not be allowed to do so for whatever reasons. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb5f914.8050...@bzed.de
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
18.05.2012 00:11, Russ Allbery пишет: Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. As always, it's easier to add another abstraction layer and so generate the (somewhat pointless) source package and upload that, rather than modifying dak (and/or buildd) to handle two kinds of sources and source tools. I do agree it'd be better if we could just get rid of source packages, but we're far from there yet, sadly. Oh, sure. And I'd be fine with that. I just really like the idea of having everything about the package build automated, including generation of the source package, so that we no longer have problems where the maintainer does something weird on their local system. I'm fine with it being optional for those who want to use it, but I'd like to use it. One would test the build locally and then just push the tag, and the whole process would be reproduced in our infrastructure with a known configuration and we'd identify problems much faster. It would also mean that any Debian maintainer could easily clone the canonical source for a package that's using Git and that infrastructure, which we sort of have with debcheckout but a bit awkwardly, and NMUs could always be pushed to the same place, with the security handled via regular upload rights checking instead of the more ad hoc git.debian.org permission approach. It feels like the sort of direction in which software development is moving, and it feels like embracing our tools in ways that we're not yet doing. What about stable release? Git branches? What about users who want rebuild a package (probably with new patches)? dget functionality is really good for me. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb60a9e.5010...@gmail.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Thu, May 17, 2012 at 06:23:49PM -0400, Chris Knadle wrote: Another thing I've seen with another package I'm working on in collaboration is using a Git repo in which the only contents are the debian/ files and not the original source tarball nor source files at all. To do a built the source is then downloaded via uscan, expanded, and the debian/ directory is copied into the expanded source directory, and then built. With this kind of configuration no source files are tracked in Git, so instead it's necessary to track debian/patches so that patches can be applied to the pristine source. At the moment I'm following the latter methodology to see how well it works out and whether I like it. If anyone else has used this method and has comments on it, I'd be interested in reading them. I've never used it with git, but I used to use it with svn as part of the Debian games team. For some (1 in 1000) packages, it may be necessary due to the sheer size of the orig source (esp. with svn which wasn't efficient with storage); but IMHO it's an incredible pain in the arse. When I moved those packages to git I gleefully stitched the VCS history together with the upstream sources via git-filter-branch. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518085508.GA27744@debian
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote: On 05/17/2012 04:52 PM, Gergely Nagy wrote: I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. Doing that is the most stupid idea ever. All it does is to ensure that you package can't be NMUed sanely and that people who need to work with the sources and your patches for whatever reason have to clone your git, which might be not available or just too large for them to download - so at the end changes are high that they end up with a largish unreadable patch, similar to the mess we get from Ubuntu sometimes. The only thing that makes sense would be to use git-format-patch to export your patches to debian/patches and list them in the series file. Or use gbp-pq, which was made exactly for that. Uhm, please switch around git and quilt, and say that again. Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, this ends up with no end of woe. Quilt sprinkles its modifications around the source, breaks timestamps causing unnecessary rebuilds, breaks basic VCS abilities like bisection, makes it really hard to even review history, and so on. You complain about forcing people to use git, while you push quilt onto everyone else. And while git can do every single thing quilt can do, the reverse is thoroughly untrue. I really wish there was a 3.0 format besides 3.0 (quilt), so people are not mislead into thinking they have to (or even, would gain anything) from writing patches in quilt's format. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
]] Igor Pashev What about stable release? Git branches? Sure. Branches are cheap. What about users who want rebuild a package (probably with new patches)? They'll then just grab the git tree, apply their patches, build their package. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5opssq1@qurzaw.varnish-software.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hello, On Fri, 18 May 2012 11:37:08 +0200 Adam Borowski kilob...@angband.pl wrote: Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, this ends up with no end of woe. Quilt sprinkles its modifications around the source, breaks timestamps causing unnecessary rebuilds, breaks basic VCS abilities like bisection, makes it really hard to even review history, and so on. I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch queue management system, and it does its job well. And, by the way, git can't do it better at the moment as guilt seems to be dead, and stgit is buggy (mq in mercurial is better than quilt, but we speak of git atm). Keeping patches in git makes thing less transparent and more complicated. You have to inspect all the history just to find out what changes did maintainer do to the original source. And, of course, you need to have a clone of the repo. You complain about forcing people to use git, while you push quilt onto everyone else. And while git can do every single thing quilt can do, the reverse is thoroughly untrue. No, it can't. Please check what git, and what quilt is. They are different tools for different purposes and they can't do each other's job well enough. -- WBR, Andrew signature.asc Description: PGP signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Jon Dowland j...@debian.org writes: On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote: It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore Thanks for the recipes for avoiding the quilt stuff; whilst still more work than just use 1.0, but perhaps the advantages are indeed worth it. (Esp. in light of the talk re: xz compression.) For me a huge advantage is that .hg and .git files are properly ignored when building source packages. Not to mention multiple upstream tarballs and support for adding binary files (think debian icon). Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. I had to go away and read up on the other things 3.0 brings to the table. Indeed they are nice-to-haves, which I am not benefiting from precisely because they are presently only available in Debian via 3.0 (quilt). This is a bit of a marketing fail for 3.0., in hindsight. I think one large problem is that people don't know how to make 3.0 (quilt) format play nice with RCS systems and their own worflows. This is something that has only evolved recently as more people have used 3.0 (quilt) format with their favourite RCS and workflow and the surrounding tools have adapted. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehqhlor2.fsf@frosties.localnet
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. How come? If the .git directory shipped in the package is pruned, there is no hidden data. All you have to review are commits that are present there, which is exactly the same as with quilt: you need to review the tarball and every single patch. There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, There's a whole world between shallow clones and complete ones. While existing git porcelain provides no convenient tools to selectively shallowify a repository, this is because no one had that need before. For example, if you limit yourself to a bunch of linear rebased commits atop of the newest upstream tag, you can exactly emulate quilt workflow except for not having to deal with quilt's peculiarities. This goes to the point of shipping EXACTLY the same data as quilt would, with only metadata different[1]. And unlike what you say, commits are not flattened in any way. If we allow non-linear Debian changes (ie, merged not rebased, etc), there is indeed a complex question: where to cut[2]. But even then, a given commit is either present or not. If too much old history is there, that's no different from the upstream shipping an old tarball and a pile of patches upon it (like ancient apache or qmail). And besides, what's the reason behind enforcing exactly one upstream and exactly one Debian? This just leads to problems if either side has multiple layers. and it's not horribly clear what the advantages of 3.0 (git) are at that point. Many of the really compelling use cases for 3.0 (git), neat stuff like possibly being able to just push a signed tag instead of uploading or having the package history when you get the source package, aren't very interesting with shallow clones. It's more a psychological issue: while you can use 3.0 (quilt) to emulate 1.0, people don't know about that. Even though 6500 of packages in Debian store their packaging in git, they typically fight with quilt, while that shallow copy = single-debian-patch would at least remove that concern. [1]. Git keeps references to commits not present in the shallow repository. 3.0 (quilt) in turn partially and inconsistently preserves timestamps, but only on files that haven't been modified in any of the patches. Also, the tarball may ship an empty directory, device nodes, named pipes, etc -- again, only as long as no patch touches them. [2]. One way: cut all commits which don't have one of current upstream tarballs as an ancestor. This can sometimes cut more than one would want, but is strictly better than a shallow copy. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle chris.kna...@coredump.us writes: On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? You're source VCS would be with the patches applied already. When building the source package dpkg-source will simply create debian/patches/debian-changes as the diff between your working directory and the orig tarball every time. Same as it did create a diff.gz file with 1.0 format. and perhaps rm -rf .pc debian/patches in the clean target if those bother you -- and you have all the goodies that come with the 3.0 format, with getting none of quilt brain damage onto you. Suddenly, nothing conflicts with the VCS you're using, nothing breaks bisects, nothing causes spurious recompiles, etc. Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. If debian/ is nuked then so is debian/patches, and if Git has been told to ignore debian/patches then it cannot bring those files back. Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. Small misunderstanding here. If you have a 1.0 format package that contains debian/ in the orig tarball then the diff.gz will contain only the changes to the debian dir. In 3.0 (quilt) the debian dir is ignored when unpacking an orig tarball and the debian tarball contains the full debian dir. The benefit is that you do no longer need to repack the orig tarball to remove files from the debian dir and changes upstream does to the debian dir are ignored. The drawback is that changes upstream does to the debian dir are ignored. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa15lodn.fsf@frosties.localnet
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote: On Fri, 18 May 2012 11:37:08 +0200 Adam Borowski kilob...@angband.pl wrote: Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch queue management system, and it does its job well. And, by the way, git can't do it better at the moment as guilt seems to be dead, and stgit is buggy (mq in mercurial is better than quilt, but we speak of git atm). What would you need guilt or stgit for? Various invocations of git-rebase can already do all of that. -i in particular can do most of that in an user-friendly way. Keeping patches in git makes thing less transparent and more complicated. You have to inspect all the history just to find out what changes did maintainer do to the original source. I'm sorry but I fail to see any core differences between quilt and a series of patches rebased on top of the latest upstream tag. Except that git's porcelain has better tools to do that -- just recall recent complains about unfuzzying patches. Git will do a 3-way merge during rebasing, which is more powerful than just copying a patch over as it has more context (especially, old context vs new context) to work with. A rebased series is just one way to work with git, but it alone can do everything quilt can. And, of course, you need to have a clone of the repo. A semi-shallow clone of [upstream_tag .. HEAD] ships exactly as much as tarball + quilt series. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, May 18, 2012 at 01:27:50PM +0200, Adam Borowski wrote: On Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery wrote: Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. How come? If the .git directory shipped in the package is pruned, there is no hidden data. All you have to review are commits that are present there, which is exactly the same as with quilt: you need to review the tarball and every single patch. I think this is a key point. The aim of the git format should not be provide the entire history, any more than the other formats do (not). What should be provided needs to be - sufficient to build the package - sufficient to determine the changes made between the Upstream release and the Debian upload - sufficient to allow further uploads, including NMUs - (allow restoration of the full history) There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, There's a whole world between shallow clones and complete ones. While existing git porcelain provides no convenient tools to selectively shallowify a repository, this is because no one had that need before. If we allow non-linear Debian changes (ie, merged not rebased, etc), there is indeed a complex question: where to cut[2]. But even then, a given commit is either present or not. If too much old history is there, that's no different from the upstream shipping an old tarball and a pile of patches upon it (like ancient apache or qmail). If the git repo contain two tags, maybe signed, one which uniquely referenced the upstream version, and one which referenced the debian version, then all commits not part of the graph between these two commits could be dropped. This would preserve all history of branching and merging between these two points. Tools used for importing upstream tarballs could automatically create such tags; native git projects can do this themselves. These tags could be put in the .dsc, so that projects can use their own naming rules, or dpkg-source could use a specific method. [As an upstream who uses signed tags for all releases, the flexibility to use the project- specific tags would be useful.] dak could check that the upstream tag referenced the same commit between uploads, as well as maybe also verifying the tag signature. This would ensure that the upstream source couldn't be altered in an upload, the same as is enforced for orig.tar right now. dak could also check the debian tag if required; though the .dsc signature would presumably be sufficient, signed tag verification would be useful for a potential git-only workflow in the future. Providing that the packaged repo contains links to the public git repo, and we can get this from debian/control (in case the developer is using a private or git+ssh repo), the end user should be able to do a simple git fetch origin to restore the full history. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518124912.gi22...@codelibre.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Fri, 18 May 2012, Adam Borowski wrote: On Fri, May 18, 2012 at 12:16:40PM +0200, Andrew Shadura wrote: On Fri, 18 May 2012 11:37:08 +0200 Adam Borowski kilob...@angband.pl wrote: Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, I'm sorry to disappoint you, but quilt isn't a VCS at all. It's a patch queue management system, and it does its job well. And, by the way, git can't do it better at the moment as guilt seems to be dead, and stgit is buggy (mq in mercurial is better than quilt, but we speak of git atm). What would you need guilt or stgit for? Various invocations of git-rebase can already do all of that. -i in particular can do most of that in an user-friendly way. You rebase, that branch is crap that cannot possibly be used by others in any way that is not (1) error-prone; (2) annoying; (3) at least as troublesome as quilt (IMHO it is much worse than quilt). Have you ever been downstream from someone that publishes branches that are rebased all the time? But yes, git is *MUCH* better at merging than patch, which would be the reason why I work on development of patch-based deliverables (anything for the Linux kernel, and anything that is supposed to make its way upstream) using the latest development shapshot of stgit instead of quilt. When it is time to release/upload, the branch gets git format-patch'd, and makes its way to debian/patches for 3.0(quilt) to handle. That branch is never published. git-pq can automate this stuff in an even better way that is rebase-less if you want, but I don't bother. I'm sorry but I fail to see any core differences between quilt and a series of patches rebased on top of the latest upstream tag. Except that git's 3.0(quilt) doesn't need a full git repository to actually be manipulated. Since we cannot use 3.0(git) with the full git repository in Debian, IMO that makes 3.0(git) useless if you're going to use it like that. You're free to propose that we change the way 3.0(git) is supposed to be used, and maybe that will require a 3.1(git), or maybe not. That's probably where we'll get some value out of this necrotic thread. Damn, I hate the stink of dead horse corpses... It would certainly be possible to define that all that can go in the git repository is the snapshots uploaded to Debian/Ubuntu. That DOES mean you CANNOT use git directly with the upstream repository, you'll need to transport changes using git format-patch and git-am, or maybe git cherry-pick from a remote. I think this will actually be worse for people to understand than 3.0(quilt), but it does have the advantage that you will be using git instead of quilt to manipulate the changes. We'd need a procedure to deal with uploads fixing cannot be distributed, but it was problems, and THAT will require rewriting history to get rid of the offending data. Which is rather nasty, but doable. A rebased series is just one way to work with git, but it alone can do everything quilt can. Indeed. But shallow clones are not the way (we've debated this already on a huge technical thread, at least twice). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518140907.ge...@khazad-dum.debian.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
* Adam Borowski kilob...@angband.pl [120518 11:37]: You complain about forcing people to use git, while you push quilt onto everyone else. [...] I really wish there was a 3.0 format besides 3.0 (quilt), so people are not mislead into thinking they have to (or even, would gain anything) from writing patches in quilt's format. Noone is forcing quilt on anyone. We need a source format that can properly represent changes to the upstream source code and that is best done as some series of patches. Using a format that is a subset of quilt without all the magic makes sense as that makes it easy for anyone to write or read. (It's just a set of patches to be applied with -p1 and a file to list the names of those patches line by line, i.e. no special sort algorithm for filesnames needs to be defined). One of the biggest faults of 3.0 (quilt) is its name. It should really have been called 3.0 (patches) or even better 3.0 (non-native). A proper package should either have no upstream changes or broken down changeset that can actually be applied. If you have those changes it is trivial to create a 3.0 (quilt) source package out of that. And yes, git is the better quilt for managing a source tree. Which is why I use it exclusively to work on my 3.0 (quilt) packages. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120518145644.gb2...@client.brlink.eu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/18/2012 11:37 AM, Adam Borowski wrote: On Fri, May 18, 2012 at 09:24:04AM +0200, Bernd Zeimetz wrote: On 05/17/2012 04:52 PM, Gergely Nagy wrote: I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. Doing that is the most stupid idea ever. All it does is to ensure that you package can't be NMUed sanely and that people who need to work with the sources and your patches for whatever reason have to clone your git, which might be not available or just too large for them to download - so at the end changes are high that they end up with a largish unreadable patch, similar to the mess we get from Ubuntu sometimes. The only thing that makes sense would be to use git-format-patch to export your patches to debian/patches and list them in the series file. Or use gbp-pq, which was made exactly for that. Uhm, please switch around git and quilt, and say that again. No. Quilt is a kind of really primitive VCS. It does not make sense to use both it and a modern one, and when someone tries, this ends up with no end of woe. Quilt sprinkles its modifications around the source, breaks timestamps causing unnecessary rebuilds, breaks basic VCS abilities like bisection, makes it really hard to even review history, and so on. If you get a cd image with sources nobody cares what the maintainer used to manage the package. A developer without internet access cares about usable patches in debian/patches instead of a big, uncommented blob. Quilt is not a VCS at all, it is a system to apply and unapply a list of patches, nothing more. You complain about forcing people to use git, while you push quilt onto everyone else. And while git can do every single thing quilt can do, the reverse is thoroughly untrue. See above. To use patches in debian/patches you don't even need quilt. People might not have access to your famous git repository. I really wish there was a 3.0 format besides 3.0 (quilt), so people are not mislead into thinking they have to (or even, would gain anything) from writing patches in quilt's format. Quilt doesn't us a special format. You can just go and run git-format-patch to export patches from git. If you want people to be able to work with your patches *AND* you don't like to ship a proper (quilt) set of patches, figure out what needs to be done to get 3.0 (git) accepted (like automatic removal of branches which are not part of the packaging, ensuring that source versions which were not distributable were removed from the repository, and so on...) - then you can happily assume that people are able to use your git repository as they actually get a copy on CD. - -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPtnjHAAoJEOs2Fxpv+UNfQREP/A9Y2Cy6zzd+kQeje8AvjtSQ VrWJEFwNDcWM/Sf5K6NvccSg+G+8dMjb8XXv9HOJKf9wnSXLLpHTbIAUpTTms71a HHis4lCIrm6t1HAU7GmQAHwhJKW+z1G52xzzEXC9SHfECCaMERDPgUwrHsO2mujx qN9ormQufui0SmWUlIvRyNp9S5UtY7Qvq1iNzquK+D/9l8U5sCx8TcxhBmR7L8ZO 8Ncby9dIzvYVUahGXwpOB4am/1VPPJkMIMW+IrpJIXKrpjg8KWXJ5JC1eFOu3PHs vUBoqm42M9LeFhmcCO2H20aCF9JhoMQkPkqTmQBJEpvtIvo3xm9/SQIm296aGtKS dWA3Vs3XZCL0+OOxfo0pE46kwxb3M7m327dg2O0mdMtq+NPTh8Xon1E2k4yHVSEe BBl4o2JRrXEVKj3NnJbT9PbajwzOMzZYuIk0APyWePPfi1j5j6kaZXFBblz6x4H/ +R5PshcVoiX0ZQKmXcOmr1QNDc6XygiS2PCapeQbFURcVBqEvf1ePtqHAendYP+F 1QmIYh5HbKVI+Tkr9962Kd782zJuT2Ja9GeZE40XpxxXiKKI84mVdlNTuUzHXixl 8MIg97VsEOp0LC6K9Oa3vOEObJ+4ln3ZCKUn9npWDZ59+Yt9Fmkw1K3V/NuJFsTS uYhgNlkRtgPojwfw+L5t =oQ0Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb678d5.8040...@bzed.de
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Henrique de Moraes Holschuh h...@debian.org writes: When it is time to release/upload, the branch gets git format-patch'd, and makes its way to debian/patches for 3.0(quilt) to handle. That branch is never published. git-pq can automate this stuff in an even better way that is rebase-less if you want, but I don't bother. I do this work in cases where keeping the patches separate is useful for some reason, but mostly it's not. I therefore use single-debian-patch for most of my packages, and only use this sort of automation for a very few where there are lots of upstream changes and some benefit to keeping them separate. I'm unwilling to do all this extra work for a theoretical marginal benefit that only applies to people who aren't using Git. I'm only willing to do it when the benefit is not theoretical. For most of my packages, no one is going to care, particularly for those where I'm also upstream. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4uhcmi8@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Le Wed, May 16, 2012 at 07:45:24PM -0700, Russ Allbery a écrit : Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. There was never really a satisfactory resolution to that discussion. Hi Russ and everybody, it is indeed hard to reach conclusions when discussing on high-traffic mailing lists. I have attempted to summarise some elements of discussion on wiki.debian.org. Please let me know if I have misunderstood or misrepresented people's contributions, and I will correct. Please of course feel free to correct or update by yourself. http://wiki.debian.org/GitSrc#Discussion In the case of the initial copryight review, which is if I understand well the strongest objection, wouldn't it be solved if the first upload to Debian would contain as few history as possible ? Then the quantity of history in the source packages could be allowed to grow, for instance up to one or two previous stable releases. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120519025607.ga5...@falafel.plessy.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
]] Roger Leigh I think this is a key point. The aim of the git format should not be provide the entire history, any more than the other formats do (not). What should be provided needs to be - sufficient to build the package - sufficient to determine the changes made between the Upstream release and the Debian upload - sufficient to allow further uploads, including NMUs - (allow restoration of the full history) - The source, aka the preferred form for modification. I think we're failing to provide that in many cases today, since if you're going to do any serious hacking on a project, you end up cloning its VCS, you don't just grab a tarball and use that. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txzcsrc7@qurzaw.varnish-software.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? and perhaps rm -rf .pc debian/patches in the clean target if those bother you -- and you have all the goodies that come with the 3.0 format, with getting none of quilt brain damage onto you. Suddenly, nothing conflicts with the VCS you're using, nothing breaks bisects, nothing causes spurious recompiles, etc. Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. If debian/ is nuked then so is debian/patches, and if Git has been told to ignore debian/patches then it cannot bring those files back. Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote: I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? It's the other way around. You manage changes to the source package as commits in the VCS; perhaps tracked on separate branches, perhaps not. The source package ends up being a flattened version of all of these commits. So the 'preferred form for modification' is the VCS archive; the source package is a second class citizen. So to follow Adam's instructions you would first apply each of the patches as a commit in your VCS, then delete them, then ignore debian/patches going forward (treating it as an implementation detail of a legacy source archive format) Yes, I think it's a shame if the preferred form for modification wasn't the source package. I also think it's turning a blind eye to say putting git repos in as source packages would be not worth the work to audit them; but we can keep hosting them at git.debian.org just fine. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517145410.GB7703@debian
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Chris Knadle chris.kna...@coredump.us writes: On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. If debian/ is nuked then so is debian/patches, and if Git has been told to ignore debian/patches then it cannot bring those files back. You're misreading this. Nuking upstream debian/ means ignoring any debian/ directory upstream may have had. That is generally a Good Thing(tm), as we want to have our own packaging. The original is still available in both the upstream tarball, and the upstream branch. debian/patches in this case is irrelevant, as that is automatically generated by diffing the upstream tree against the current (git) tree and folding it into a single patch file. Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umioo6l.fsf@algernon.balabit
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Tollef Fog Heen tfh...@err.no writes: Pushing a signed tag and having source packages and binaries built from that doesn't rely on 3.0 (git), though. «Just» a repository somewhere with hooks that go «oh, a signed tag, let me build a source package and upload that». Might fire it off as a job to a separate process so pushing to big repos doesn't take a winter and a day, but that's really an implementation detail. Good point. If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umiy9r8@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
* Russ Allbery (r...@debian.org) [120517 19:53]: Tollef Fog Heen tfh...@err.no writes: Pushing a signed tag and having source packages and binaries built from that doesn't rely on 3.0 (git), though. «Just» a repository somewhere with hooks that go «oh, a signed tag, let me build a source package and upload that». Might fire it off as a job to a separate process so pushing to big repos doesn't take a winter and a day, but that's really an implementation detail. Good point. If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. git.debian.org isn't license-reviewed either, so could be the same level of being public. Having special form of git-tags on git.d.o automatically uploaded to ftp-master (and having there the usual checks) would sound a good idea (of course, also for svn and other vcs). However, this package format would still need to allow NMUs (and/or having the vcs in question having support for NMUs). Andi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517181917.ga2...@mails.so.argh.org
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
]] Russ Allbery If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. As always, it's easier to add another abstraction layer and so generate the (somewhat pointless) source package and upload that, rather than modifying dak (and/or buildd) to handle two kinds of sources and source tools. I do agree it'd be better if we could just get rid of source packages, but we're far from there yet, sadly. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obpmtzob@qurzaw.varnish-software.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Thursday, May 17, 2012 10:52:02, Gergely Nagy wrote: Chris Knadle chris.kna...@coredump.us writes: On Wednesday, May 16, 2012 06:38:49, Adam Borowski wrote: On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? Git does have a complete view. What the above does, is tell dpkg-source to fold any changes made to the upstream sources into a single patch. Since the git tree already has the patches applied (with upstream sources on a different branch, most probably), it has a full view. This basically folds whatever patches the git tree has over upstream, outside of debian/ into a single file. That's about it. Since that file is generated, it has no business staying in git. So essentially this uses Git to create the 3.0 (quilt) format without actually using quilt, yet acts similar to the original 1.0 format of making a single patch. That's pretty interesting. Thanks for the explanation. Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. If debian/ is nuked then so is debian/patches, and if Git has been told to ignore debian/patches then it cannot bring those files back. You're misreading this. Nuking upstream debian/ means ignoring any debian/ directory upstream may have had. That is generally a Good Thing(tm), as we want to have our own packaging. Okay. I don't commonly see debian/ directories in the upstream sources themselves, so I couldn't tell that's what you had meant. The original is still available in both the upstream tarball, and the upstream branch. debian/patches in this case is irrelevant, as that is automatically generated by diffing the upstream tree against the current (git) tree and folding it into a single patch file. Yes I see. Patching the source can be an effort especially concerning documenting why the patches were done and the source of the patches, so these seem like they'd be important to track rather than something to ignore. The reasons can - and should be - documented in git. Granted, that does not transfer to the debianized source package, which is unfortunate, but it's still better than fighting with integrating quilt with a VCS (in which case, everyone with a higher number of patches would go back to 1.0 and custom patching systems and ignore every other benefit of 3.0, because quilt and VCS generally don't play nice together). One of the problems I'm running into is in working on updating a package that has been abandoned and is now three years older than upstream, and which has a single (1.0 format) patch with no notes in the files themselves, and no VCS location. I can look through the changelog in the package, but without any way of matching up dates due to the patch being bundled into a single file, I cannot seem to match up what changes within the patch match up with the changelog, so I cannot tell which elements of the patch may still be relevent today with a new upstream version of the software. If Git had been used it would be possible to figure out which commit made what change, but it would still be a lenthy process. Quilt patches with annotated headers to describe each patch still seems like they have an advantage in that the annotated headers are in the patch files themselves. I'm not sure which is better at this point (and it may depend on the situation) but either way it's nice to know about both options. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On mar., 2012-05-15 at 14:32 +0900, Norbert Preining wrote: Hi dpkg-* maintainers, I think you missed the correct mailing list to reach the dpkg-* maintainers. -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Tollef Fog Heen tfh...@err.no writes: ]] Russ Allbery If I were to pick between the enhancements to Debian in this area, none of which I have time to work on and therefore can't vote on via implementation, I'd be way more interested in avoiding the entire source package upload process entirely and be able to just push signed Git tags to a trusted host that stores Git repositories for our packages. Even if those repositories were only accessible to Debian maintainers because they're not license-reviewed. As always, it's easier to add another abstraction layer and so generate the (somewhat pointless) source package and upload that, rather than modifying dak (and/or buildd) to handle two kinds of sources and source tools. I do agree it'd be better if we could just get rid of source packages, but we're far from there yet, sadly. Oh, sure. And I'd be fine with that. I just really like the idea of having everything about the package build automated, including generation of the source package, so that we no longer have problems where the maintainer does something weird on their local system. I'm fine with it being optional for those who want to use it, but I'd like to use it. One would test the build locally and then just push the tag, and the whole process would be reproduced in our infrastructure with a known configuration and we'd identify problems much faster. It would also mean that any Debian maintainer could easily clone the canonical source for a package that's using Git and that infrastructure, which we sort of have with debcheckout but a bit awkwardly, and NMUs could always be pushed to the same place, with the security handled via regular upload rights checking instead of the more ad hoc git.debian.org permission approach. It feels like the sort of direction in which software development is moving, and it feels like embracing our tools in ways that we're not yet doing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d362va8x@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Thursday, May 17, 2012 10:54:15, Jon Dowland wrote: On Thu, May 17, 2012 at 10:41:37AM -0400, Chris Knadle wrote: I'm confused concerning the above; the point of a VCS in this context is to track changes to the source package, and the patches are themselves important changes to the source package. If you have Git ignore the patches then Git doesn't have a complete view of the source package anymore. Why would you want to do that? It's the other way around. You manage changes to the source package as commits in the VCS; perhaps tracked on separate branches, perhaps not. The source package ends up being a flattened version of all of these commits. So the 'preferred form for modification' is the VCS archive; the source package is a second class citizen. So to follow Adam's instructions you would first apply each of the patches as a commit in your VCS, then delete them, then ignore debian/patches going forward (treating it as an implementation detail of a legacy source archive format) Yes, I think it's a shame if the preferred form for modification wasn't the source package. I also think it's turning a blind eye to say putting git repos in as source packages would be not worth the work to audit them; but we can keep hosting them at git.debian.org just fine. Although I like the /idea/ of being able to modify the source package directly via Git as if there were a 3.0 (Git) source format, I also think it's important to be able to verify the source download that came from upstream. Including the original source tarball isn't enough because that is then being modified. Doing something like 'git diff original-source-commit..HEAD' to find out how the source has been changed would presumably also contain diffs from debian/ files not related to the source. Looking at the manpage for 'git diff' it isn't immediately clear to me how you'd filter those out. [Although I'm sure there's a way.] Another thing I've seen with another package I'm working on in collaboration is using a Git repo in which the only contents are the debian/ files and not the original source tarball nor source files at all. To do a built the source is then downloaded via uscan, expanded, and the debian/ directory is copied into the expanded source directory, and then built. With this kind of configuration no source files are tracked in Git, so instead it's necessary to track debian/patches so that patches can be applied to the pristine source. At the moment I'm following the latter methodology to see how well it works out and whether I like it. If anyone else has used this method and has comments on it, I'd be interested in reading them. Thanks. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Tue, May 15, 2012 at 11:10 AM, Jon Dowland j...@debian.org wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. You could use gitpkg with a quilt export hook. i use it regularly with imagemagick and it work perfectly (it is gitpkg over git over svn). Bastien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515091028.GB24635@debian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAaMrJR2y15X0OKteGT47SZ1Ej=QG=v++iywstkvuod...@mail.gmail.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore and perhaps rm -rf .pc debian/patches in the clean target if those bother you -- and you have all the goodies that come with the 3.0 format, with getting none of quilt brain damage onto you. Suddenly, nothing conflicts with the VCS you're using, nothing breaks bisects, nothing causes spurious recompiles, etc. Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. -- “This is gonna be as easy as cheating on an ethics exam!” -Cerise Brightmoon signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski wrote: It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore Thanks for the recipes for avoiding the quilt stuff; whilst still more work than just use 1.0, but perhaps the advantages are indeed worth it. (Esp. in light of the talk re: xz compression.) Except for nuking upstream debian/ dir which can mean a bit of lost work if the upstream is sane (and can save some if they're not), the 3.0 format is strictly better than 1.0. I had to go away and read up on the other things 3.0 brings to the table. Indeed they are nice-to-haves, which I am not benefiting from precisely because they are presently only available in Debian via 3.0 (quilt). This is a bit of a marketing fail for 3.0., in hindsight. -- Jon Dowland -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516123707.GA6784@debian
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Adam Borowski kilob...@angband.pl writes: It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore I recommend using local-options instead of options. That way all of your changes go into a single patch, but any NMUs automatically are put into separate patches by version number. It makes analyzing packages that have been NMU'd much nicer. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr4cvy2a@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Le Wed, May 16, 2012 at 12:38:49PM +0200, Adam Borowski a écrit : On Tue, May 15, 2012 at 10:10:28AM +0100, Jon Dowland wrote: On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. I can't see any reason to use 1.0 anymore, ever. It is true that 3.0 (quilt) does have a great downside, quilt, but it also has a number of upsides. And working around quilt is simple: echo single-debian-patch debian/source/options echo /.pc .gitignore echo /debian/patches .gitignore It strikes me that while we have more than 6,500 source packages managed with Git, we are pushing for a source package format that does not work transparently with them. Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120516230943.gd17...@falafel.plessy.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Thu, 17 May 2012, Charles Plessy wrote: It strikes me that while we have more than 6,500 source packages managed with Git, we are pushing for a source package format that does not work transparently with them. It does, but not on all workflows. A very large number of DDs are using 3.0 (quilt) with git just fine. I don't exactly like quilt, in fact all my patch-based work is done using stgit, but: 1) it is much better than dpatch and other homebrew stuff. At least you know exactly what to expect, and it is the same in the entire distro. 2) properly used, it enforces neatness and lowers a damn great deal the barrier of entry (*and* reduces the risk of mistakes) for someone who needs to do quick maintenance, security updates, NMUs, when taking over the package, and even for automated extraction of changes to upstream code. Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. This is a _very_ dead horse. I'd appreciate if you'd kindly refrain from any further attempts at necromancy on this thread. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517003922.gb8...@khazad-dum.debian.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Charles Plessy ple...@debian.org writes: Also, it is very sad that, as a project, we can not decide whether we go for 3.0 (git) or not, or have a concrete list of resolvable objections from the people whose work is direclty impacted by the use of this format. We know what a primary concrete objection is. We discussed it at length at DebConf two years ago, and then on debian-devel afterwards. Uploading a Git archive requires reviewing the entire contents of the archive, not just the current code, for licensing issues, which is pretty painful from the ftp-master perspective. There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, and it's not horribly clear what the advantages of 3.0 (git) are at that point. Many of the really compelling use cases for 3.0 (git), neat stuff like possibly being able to just push a signed tag instead of uploading or having the package history when you get the source package, aren't very interesting with shallow clones. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqa3seyj@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
]] Russ Allbery There was never really a satisfactory resolution to that discussion. We can upload very shallow clones, but they end up looking a lot like the existing quilt format with single-debian-patch, and it's not horribly clear what the advantages of 3.0 (git) are at that point. Many of the really compelling use cases for 3.0 (git), neat stuff like possibly being able to just push a signed tag instead of uploading or having the package history when you get the source package, aren't very interesting with shallow clones. Pushing a signed tag and having source packages and binaries built from that doesn't rely on 3.0 (git), though. «Just» a repository somewhere with hooks that go «oh, a signed tag, let me build a source package and upload that». Might fire it off as a job to a separate process so pushing to big repos doesn't take a winter and a day, but that's really an implementation detail. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87likricaf@xoog.err.no
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On 2012-05-15, Norbert Preining prein...@logic.at wrote: Is there a rational behind not allowing any fuzz? I think it makes perfect sense to expect the patches to apply perfectly, so we don't rely on patch quilt to be able to unfuzz things. Especially when unfuzzing patches are so simple. while quilt push ; do quilt refresh ; done #sanitychecks dch ... refresh patches /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjr3scl.p7v.nos...@sshway.ssh.pusling.com
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Norbert Preining prein...@logic.at writes: Is there a rational behind not allowing any fuzz? Fuzz indicates that the source file has changed since the patch has been generated, which means that the patch may no longer apply properly. Fuzz is a guess of convenience by the patch program that the result is *probably* what was intended. But fuzz indicates there may be a problem; for example, I've seen patches apply with fuzz that add duplicate lines to a file (because the lines were added upstream in a different location), resulting in everything from compilation errors to serious hidden bugs in the program. Therefore, I think it makes sense to require the maintainer to confirm that, yes, the patch applied with fuzz still makes the correct change and isn't indicative of an error. A good way to indicate that is to unfuzz the patch. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87liku0y9w@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Mo, 14 Mai 2012, Russ Allbery wrote:
isn't indicative of an error. A good way to indicate that is to unfuzz
the patch.
Or build a source and binary package, do normal testing *as*usual*
and upload ...
No, I hereby start saying good by to 3.0
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
KIRBY MISPERTON (n.)
One who kindly attempts to wipe an apparent kirby (q.v.) off another's
face with a napkin, and then discovers it to be a wart or other
permanent fixture, is said to have committed a 'kirby misperton'.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515061717.gg19...@gamma.logic.tuwien.ac.at
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hi, (Caveat: I am not a dpkg-source maintainer.) Sune Vuorela wrote: On 2012-05-15, Norbert Preining prein...@logic.at wrote: Is there a rational behind not allowing any fuzz? I think it makes perfect sense to expect the patches to apply perfectly, so we don't rely on patch quilt to be able to unfuzz things. Indeed, unfuzzing involves guessing where the patch is supposed to apply, and different versions of GNU patch (which is what quilt uses) may make different guesses as patch gets smarter. The same source package producing a different unpacked result depending on the tools in the surrounding environment does not sound like fun to me. I can imagine dpkg-source or wrappers like git-buildpackage learning to automatically refresh patches when generating the source package if requested to do so, so it would only have to make the guess once. Perhaps someone would like to work on that? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515061800.GA11441@burratino
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Norbert Preining prein...@logic.at writes: On Mo, 14 Mai 2012, Russ Allbery wrote: isn't indicative of an error. A good way to indicate that is to unfuzz the patch. Or build a source and binary package, do normal testing *as*usual* and upload ... There was a reason why I added the word subtle in front of serious bugs. Duplicate code (the biggest risk of fuzzed patches) can do weird stuff, like create odd memory leaks or nasty heisenbugs (think of duplicating part of a mutex segment). It only takes a minute to unfuzz a patch, if that, and nearly all that time is spent inspecting the patch to be sure that it can be unfuzzed safely. quilt push -a Look for fuzzy patch warnings. For each fuzzy patch: quilt pop patch # inspect the fuzzy files to be sure everything is as expected quilt refresh Then: quilt pop -a svn commit # or VCS of your choice Of all the things that one has to do with a package, this is pretty minor. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fwb20xiw@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Russ Allbery wrote: Norbert Preining prein...@logic.at writes: Is there a rational behind not allowing any fuzz? Fuzz indicates that the source file has changed since the patch has been generated, which means that the patch may no longer apply properly. Fuzz is a guess of convenience by the patch program that the result is *probably* what was intended. But fuzz indicates there may be a problem; for example, I've seen patches apply with fuzz that add duplicate lines to a file (because the lines were added upstream in a different location), resulting in everything from compilation errors to serious hidden bugs in the program. Therefore, I think it makes sense to require the maintainer to confirm that, yes, the patch applied with fuzz still makes the correct change and isn't indicative of an error. A good way to indicate that is to unfuzz the patch. JFTR: Doing `quilt refresh' won't preserve the above described issue. You can only avouid this by reporting issues upstream and tracking their status or by checking the necessity of every patch with every new upstream version. Regards, Daniel -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515062713.3...@gmx.net
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: On Mo, 14 Mai 2012, Russ Allbery wrote: isn't indicative of an error. A good way to indicate that is to unfuzz the patch. Or build a source and binary package, do normal testing *as*usual* and upload ... Hmmm, what exactly is normal testing *as*usual*? Isn't it a duty of the maintainer to inspect critical parts of the code? IMHO existing patches are a perfect sign for a critical part of the code and leaving a fuzzy patch implies you did not spended time on investigating the code. A clean patch is somehow a tickmark Yes, I've checked this problematic piece of code. I really like this sensible behavour of dpkg-*. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515063258.ga3...@an3as.eu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Mo, 14 Mai 2012, Russ Allbery wrote:
Of all the things that one has to do with a package, this is pretty minor.
If you are talking of a normal small package. Not of 2.6G of packages
where even the source packages are *generated*, and unfuzzying is a
process that takes quite some time.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
KELLING (participial vb.)
A person searching for something, who has reached the futile stage of
re-looking in all the places they have looked once already, is said to
be kelling.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515063956.gh19...@gamma.logic.tuwien.ac.at
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Norbert Preining prein...@logic.at writes: On Mo, 14 Mai 2012, Russ Allbery wrote: Of all the things that one has to do with a package, this is pretty minor. If you are talking of a normal small package. Not of 2.6G of packages where even the source packages are *generated*, and unfuzzying is a process that takes quite some time. If you don't care about checking the patches, it takes fifteen minutes one time to write a shell script and then less than ten seconds to run it before you do an upload. Something like (untested): quilt pop -a while ! quilt push -a --fuzz=0 ; do quilt push quilt refresh done quilt pop -a svn commit -m Unfuzzed all patches would probably do it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aa1a0wa2@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Hi,
On Di, 15 Mai 2012, Andreas Tille wrote:
Hmmm, what exactly is normal testing *as*usual*? Isn't it a duty of
Like I have, a test bed testing various upgrade and install scenaria
from stable/testing/sid.
the maintainer to inspect critical parts of the code? IMHO existing
Not all patches are for *code*. comments in config files etc etc.
The whole point is: this behaviour declares developers uncapable of
deciding by themselves!
I want decide *myself* when I unfuzzify. Not dpkg-source.
dpkg-source should do its work, and nothing else. Not
taking over *my* responsability in checking this, because it is not
a check, at all. Let us make a small Gedankenexperiment:
According to many of these suggestions here I should run something
like quilt push ; quilt refresh; ... for all patches regularly,
or in a script. That only *hides* the fact that there was a fuzz.
What is better? A patch that tells me that it is fuzzy or a patch
that is wasted and destroyed to a automatic quilt push ; refresh
that moves the patch around?
This behaviour as advertised here to unfuzzify patches is actually
counter-productive.
No, it is taking over responsability that is and should only be in
the developers hand.
If we continue in this way, what is next? We have to name patches in
a very specific way? Or what other funny rules and regulations
are there created.
I don't know who is writing this and whether this is his spare time or
he is emplyoed for that. But I am using my free time and that is rare,
and I want to decide by myself, not be forced to do things how
dpkg maintainers thought it is a good idea.
(what is next? dpkg-source checking that we are not running under X
not to be distracted? Or checking our passwd file that not more than
one user is active? just to name a few development ideas!)
Anyway, I will migrate away from 3.0 as far as possible.
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCRABSTER (n.)
One of those dogs which has it off on your leg during tea.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515065614.gi19...@gamma.logic.tuwien.ac.at
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Mo, 14 Mai 2012, Russ Allbery wrote:
If you don't care about checking the patches, it takes fifteen minutes one
time to write a shell script and then less than ten seconds to run it
before you do an upload.
See my other answer. This is conceptually wrong, because you might
end up with a *wrong* patch and the old one is destroyed due to the
refresh (patch just messed it up .. and I didn't realize it, uuups).
I am against this kind of automatism. I prefer to be *reminded* that
there is something worth looking into. And I can decide myself that
if in this patch there is a off-by-one, I don't need to check.
But in other patches I have to check.
Again, my responsability, that is what I want. Not dpkg-source holding
my hand like a baby: don't don't don't do that!
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SPROSTON GREEN (n.)
The violent colour of one of Nigel Rees's jackets, worn when he thinks
he's being elegant.
--- Douglas Adams, The Meaning of Liff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515065931.gj19...@gamma.logic.tuwien.ac.at
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
Norbert Preining prein...@logic.at writes: On Mo, 14 Mai 2012, Russ Allbery wrote: If you don't care about checking the patches, it takes fifteen minutes one time to write a shell script and then less than ten seconds to run it before you do an upload. See my other answer. This is conceptually wrong, because you might end up with a *wrong* patch and the old one is destroyed due to the refresh (patch just messed it up .. and I didn't realize it, uuups). I am against this kind of automatism. I prefer to be *reminded* that there is something worth looking into. In your previous message, it sounded like you weren't concerned about the fuzz because you trusted your testing process. Apparently you feel this does require manual inspection after all? I'm confused by the idea that you are opposed to silencing the warning because you know it's something that you need to look at, but you're extremely angry that dpkg-source wants you to look at it before you upload to the archive. If you're going to need to look at it eventually, why not before you upload it for installation on other people's machines? Anyway, if you want to clear the fuzz but record that the patch may require further attention, that's also pretty trivial: quilt push fuzz (echo ''; echo Patch was fuzzy on `date`; cat fuzz) | quilt header -a rm fuzz quilt refresh to add the fuzzy output from the patch to the patch header for later inspection. Again, my responsability, that is what I want. Not dpkg-source holding my hand like a baby: don't don't don't do that! Maybe it's because I do software development as my day job and am a huge fan of test-driven development, but I'm generally in favor of software holding my hand like a baby and telling me that I didn't run the test suite, didn't make all the tests pass, or introduced warnings. It prevents me from doing things for the sake of expediency that waste huge amounts of my time later. That's why I use Lintian, turn on all the compiler warnings, and so forth. I think you're arguing that a fuzzy patch is probably only a minor issue and therefore shouldn't result in essentially a package rejection by dpkg-source, but the alternative is for dpkg-source to do something that's essentially unsafe. I appreciate it erring on the side of caution and requiring that someone investigate. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871uml2a40@windlord.stanford.edu
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Tue, May 15, 2012 at 03:59:31PM +0900, Norbert Preining wrote: See my other answer. This is conceptually wrong, because you might end up with a *wrong* patch and the old one is destroyed due to the refresh (patch just messed it up .. and I didn't realize it, uuups). Why don't you use a VCS? -- WBR, wRAR signature.asc Description: Digital signature
Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
On Tue, May 15, 2012 at 03:17:17PM +0900, Norbert Preining wrote: No, I hereby start saying good by to 3.0 I'm hoping we can revisit 3.0 (git) post-squeeze, myself. But I have also found myself to be incompatible iwth 3.0 (quilt) and used 1.0 for my last few packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515091028.GB24635@debian
why do people introduce stup^Wstrange changes to quilt 3.0 format
Hi dpkg-* maintainers,
I know, it is documented in dpkg-source man page:
Contrary to quilt's default behaviour, patches are expected to apply
without any fuzz. When that is not the case, you should refresh such
patches with quilt, or dpkg-source will error out while trying to
apply them.
Still I request reverting this change. It is a PITA and nothing else.
Is there a rational behind not allowing any fuzz?
Any *rational* explanation why I and probably many other have to
unfuzzify permanently patches where I *KNOW* that they are ok?
If I have a fuzzy patch that shifts one line or so, especially when
using svn/git based orig.tar.gz, this is as much a hurdle as anything else.
Well, the only options is to drop stupid 3.0 format and move back to
1.0 and use quilt manually. Is this what Debian dpkg devs want?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
You're bound to be unhappy if you optimize everything.
--- Donald E. Knuth
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120515053212.gf19...@gamma.logic.tuwien.ac.at
