Bug#675145: ITP: mediawiki-math -- math rendering plugin for MediaWiki (new source package for)
Package: wnpp Severity: wishlist Owner: Jonathan Wiltshire j...@debian.org * Package name: mediawiki-math Version : 2:1.0+git20120528 Upstream Author : Tomasz Wegrzanowski, Brion Vibber, various MediaWiki contributors * URL : http://www.mediawiki.org/wiki/Extension:Math * License : GPL-2 Programming Lang: OCaml, PHP Description : math rendering plugin for MediaWiki (new source package for) The math extension for mediawiki is no longer shipped in versions 1.18+ and instead has joined the other extensions in their proper place. This new source package is therefore necessary to continue providing it for our users. -- 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/20120530073138.6347.27400.reportbug@lupin
Re: New source package formats now available
Charles Plessy ple...@debian.org writes: Le Tue, Nov 24, 2009 at 08:17:17AM +0100, Raphael Hertzog a écrit : I can add a new option --no-debian-patch that would refuse to create the automatic quilt patch debian-changes-ver and make it fail instead if there are upstream changes. Hi Raphaël, even simpler, an option or a format that would completely ignore what is outside the debian directory: - When packing a source package, a compressed tar archive would be made from the contents of the debian directory. - When unpacking a source package, the compressed debian tar archive would be unpacked in the upstream sources, after deleting any existing debian directory. As it is already the case with Format 1.0 when the maintainer took care of having a diff.gz file that only contains files within the debian directory, the packaging system would not patch or unpatch the upstream sources, leaving this task to the maintainer. Have a nice day, With one HUGE difference. When someone (e.g. an NMUer) does edit an upstream file and builds the package then the source do not contain those changes while the binary will. That is clearly going to cause no end of pains. Building the source package and unpacking it should always result in the same source tree or fail to build in the first place. Simply ignoring changes is too dangerous. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Russ Allbery r...@debian.org writes: Brian May b...@snoopy.debian.net writes: Just a general observation, it is rather painful to have to set and maintian QUILT_PATCHES by hand everytime I want to modify a patch. There have been a number of times now I have accidentally created the patch in the wrong directory, which can be very confusing (mess two projects up in one go!). Maybe this is now fixed in unstable, last I checked it wasn't. If the only thing you use quilt for is Debian packaging and you perform quilt operations from the top of the tree, then this setting in ~/.quiltrc works fine: QUILT_PATCHES=debian/patches There's a more complex recipe in the quilt documentation that handles more cases. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ http://bugs.debian.org/557623 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=26;filename=quilt-remember_locations.patch;att=1;bug=557623 Please do test. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit : When someone (e.g. an NMUer) does edit an upstream file and builds the package then the source do not contain those changes while the binary will. That is clearly going to cause no end of pains. Building the source package and unpacking it should always result in the same source tree or fail to build in the first place. Simply ignoring changes is too dangerous. Sorry Goswin, but I will be politically incorrect… Please do not take personnaly. Primo) I checked your Debian QA page and it does not seem that you are doing NMUs. On the other hand, if you check my QA page, you will see that do regular uploads quite frequently. Therefore, when I write that it is not convenient for quilt users that dpkg suddenly attempts to take control of the patch management they were taking care by themselves, and when you answer that it is a necessary feature for people who do NMU, isn't there a strong discrepancy in the discussion since I speak from experience and you don't? Secundo) As I already answered (too harshly) to Raphaël, I and many developers only upload packages that were built in a clean chroot. Therefore, I think that your statement about ignoring changes being “too dangerous” is a gross overstatement that is not backed by facts. By the way, I started recently (for reasons unrelated to this thread) to document in README.Debian how to test the packages I maintain, to facilitate uploads by people not familiar with the package if needed, as well as to inform the users about what level of testing they should expect. I encourage other maintainers—especially those concerned with helping “NMUers”—to do so. Cheers, -- 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
Re: New source package formats now available
Charles Plessy ple...@debian.org writes: Le Mon, Nov 30, 2009 at 11:47:04AM +0100, Goswin von Brederlow a écrit : When someone (e.g. an NMUer) does edit an upstream file and builds the package then the source do not contain those changes while the binary will. That is clearly going to cause no end of pains. Building the source package and unpacking it should always result in the same source tree or fail to build in the first place. Simply ignoring changes is too dangerous. Sorry Goswin, but I will be politically incorrect⦠Please do not take personnaly. Primo) I checked your Debian QA page and it does not seem that you are doing NMUs. On the other hand, if you check my QA page, you will see that do regular uploads quite frequently. Therefore, when I write that it is not convenient for quilt users that dpkg suddenly attempts to take control of the patch management they were taking care by themselves, and when you answer that it is a necessary feature for people who do NMU, isn't there a strong discrepancy in the discussion since I speak from experience and you don't? Nowhere in my mail do I say that. I made no mention of quilt or dpkg doing patch management. My argumentation has nothing to do with that but only with your proposal. Your suggestion to simply ignore all changes to upstream files makes it dangerously simple to forget some of them and is totaly avoidable. I have nothing against your proposed quiltless format but then dpkg should fail if there are upstream changes. That way you can not forget to update the patches or add a file to the patches or forgot to commit to git or whatever is being used. As for experience you are arguing from the experience of a good maintainer that is carefull and methodical. I'm arguing from experience of how badly maintainer manage to screw things up. I've seen packages being uploaded with a syntax error in debian/rules but still having all the binary debs build as well. Packages linked against stable or experimental libraries. and the list goes on and on. People do screw up. They are people. Secundo) As I already answered (too harshly) to Raphaël, I and many developers only upload packages that were built in a clean chroot. Therefore, I think that your statement about ignoring changes being âtoo dangerousâ is a gross overstatement that is not backed by facts. And many developers do not build in a clean chroot. Also the chroot being clean or not has no affect on building the source. Unless you build the source first and then do a clean build starting with unpacking the source again your clean build would still be broken. Far too many people do not build source and then call pbuilder with the dsc file for an upload (or equivalent). And it only takes one to screw up. By the way, I started recently (for reasons unrelated to this thread) to document in README.Debian how to test the packages I maintain, to facilitate uploads by people not familiar with the package if needed, as well as to inform the users about what level of testing they should expect. I encourage other maintainersâespecially those concerned with helping âNMUersââto do so. Don't get me wrong. Documenting ways to test your package is great. But why should I need to test something that dpkg can far better test automatically with 100% accuracy? Cheers, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote: Am I doing something wrong? Just a general observation, it is rather painful to have to set and maintian QUILT_PATCHES by hand everytime I want to modify a patch. There have been a number of times now I have accidentally created the patch in the wrong directory, which can be very confusing (mess two projects up in one go!). Maybe this is now fixed in unstable, last I checked it wasn't. -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Brian May b...@snoopy.debian.net writes: Just a general observation, it is rather painful to have to set and maintian QUILT_PATCHES by hand everytime I want to modify a patch. There have been a number of times now I have accidentally created the patch in the wrong directory, which can be very confusing (mess two projects up in one go!). Maybe this is now fixed in unstable, last I checked it wasn't. If the only thing you use quilt for is Debian packaging and you perform quilt operations from the top of the tree, then this setting in ~/.quiltrc works fine: QUILT_PATCHES=debian/patches There's a more complex recipe in the quilt documentation that handles more cases. -- 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
Re: New source package formats now available
On Fri, 27 Nov 2009, Charles Plessy wrote: That would be a useful compromise. How about the second half, which is to not patch anything during the unpacking of the package? Maybe this could be combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’? There's already --skip-patches, but options in debian/source/options only apply at build time obviously (and not at unpack time since that file is not unpacked yet). Le Thu, Nov 26, 2009 at 12:30:12PM -0800, Russ Allbery a écrit : I can understand not wanting, in the very long run, to support multiple patch formats. Does that mean that the use of options discussed above may become forbidden in our archive in the future? If yes, there is little point making concessions now… I don't understand how you can jump to that conclusion from this discussion. Obviously, we don't want to have many formats in the archive and it's best if 3.0 (quilt) is flexible enough so that we don't have to invent many other formats. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le 27 nov. 09 à 14:28, Raphael Hertzog a écrit : On Fri, 27 Nov 2009, Charles Plessy wrote: That would be a useful compromise. How about the second half, which is to not patch anything during the unpacking of the package? Maybe this could be combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’? There's already --skip-patches, but options in debian/source/options only apply at build time obviously (and not at unpack time since that file is not unpacked yet). But the package is unpacked before it can be patched. The patches themselves are in debian/patches: when they become available, debian/ source/options and debian/source/format are available as well. Regards, Thibaut. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Fri, 27 Nov 2009, Thibaut Paumard wrote: But the package is unpacked before it can be patched. The patches themselves are in debian/patches: when they become available, debian/source/options and debian/source/format are available as well. Right, but unpacking should be under control of the unpacker and not under control of the one who crafted the source package. So it's still not a good idea. Furthermore I don't see at all what putting this option in the source package would be used for. If you don't want the patch system, you don't create patches with it but creating patches only to not have them applied at unpack time is non-sense IMO. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Fri, Nov 27, 2009 at 02:28:26PM +0100, Raphael Hertzog a écrit : Obviously, we don't want to have many formats in the archive and it's best if 3.0 (quilt) is flexible enough so that we don't have to invent many other formats. Le Fri, Nov 27, 2009 at 02:49:39PM +0100, Raphael Hertzog a écrit : Unpacking should be under control of the unpacker and not under control of the one who crafted the source package. I think that this is a monopolist point of view: - You have two different softwares (a packaging software and a patch management software) and you bundle them together so that people who would like the former must also use the latter. - You present the removal of a feature like a costly solution (like when people were asked to pay an extra if they do not want to use Windows on their new PC). - You plan to break backward compatibility to force users to upgrade, by making 3.0 the default before it is widely adopted. Remember this each time you get a .docx document that you can not open. - You try to hijack the directory where your competitors are doing their work (debian/patches), by applying quilt patches that were not made for the format 3.0 (and sometimes fail). Your design decisions make the format ‘3.0 (quilt)’ not particularly useful for the maintainers who already implemented a workflow based on a VCS and a patch management system (or a VCS that does both). Worse, it seems that it creates problems when one wants to keep the patch and unpatch targets in debian/rules. I would be interested in the other improvements, namely the possibility to use .tar.bz2 original upstream sources, and the possibiltiy to store the debian directory in a tar archive, but I can also keep on working with format 1.0 as before. Last question: is the use of the Format field in debian/control deprecated, or can I use it for the packages that I would like to stay in the format 1.0? Cheers, -- 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
Re: New source package formats now available
On Thu, 26 Nov 2009, Charles Plessy wrote: even simpler, an option or a format that would completely ignore what is outside the debian directory: That's option -i.*. As I said I plan to support the -i -I option inside debian/source/options just like I recently added support for -z -Z there. But I'm pretty sure that using .* as value is a bad idea because you can end up building a binary package that does not match the source package that you upload together with the binary packages. As it is already the case with Format 1.0 when the maintainer took care of having a diff.gz file that only contains files within the debian directory, the packaging system would not patch or unpatch the upstream sources, leaving this task to the maintainer. That's still the same here, dpkg-source only comes into play ith its quilt patch when the upstream files are modified. If the automatic patch was not versionned, you would always regenerate a single diff that is exactly like the old .diff.gz. Would that please those that prefer staying with 1.0 ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi, On Wed, 25 Nov 2009, Russ Allbery wrote: I've considered using TopGit to generate a real quilt patch set, but it's kind of complicated and I'm not convinced that the work required to generate the exported patch tree even with TopGit is really worth it. Given that, for packages currently maintained in Git, 3.0 (quilt) is extra complexity over 1.0 that doesn't seem to be buying me very much. Why not generate a single patch then instead of a patch set? If that single patch contains an header explaining why it's not split and where you can review the changes in a more friendly manner you can have all the other features of the new format and yet the the situation improve wrt to knowledge/advertisement of our debian-specific changes. It would be nice, however, to have the other features of the 3.0 format (including binaries in the debian directory, not shipping the debian directory as a patch, using multiple upstream tarballs, using bzip2-compressed upstream tarballs) without having the quilt-like patch system in play. Even if quilt supports multiple patches, you are not forced to use multiple patches. You can get the same than a 1.0 source package with a single patch that you regenerate each time. I would be ok to add support for this in 3.0 (quilt): - add an option --single-debian-patch that could be set in debian/source/options. With this option dpkg-source would update debian/patches/debian-changes (instead of debian-changes-ver) - support a debian/source/debian-patch-header that would be used as header of the automatic patch (debian/patches/debian-changes in this case) How does that sound? (Thanks to mrvn who suggested me the ideas) Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Thu, Nov 26, 2009 at 09:09:45AM +0100, Raphael Hertzog a écrit : you can end up building a binary package that does not match the source package that you upload together with the binary packages. “You”? Not me. What I upload comes from sbuild. -- 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
Re: New source package formats now available
also sprach Raphael Hertzog hert...@debian.org [2009.11.26.0920 +0100]: I would be ok to add support for this in 3.0 (quilt): - add an option --single-debian-patch that could be set in debian/source/options. With this option dpkg-source would update debian/patches/debian-changes (instead of debian-changes-ver) - support a debian/source/debian-patch-header that would be used as header of the automatic patch (debian/patches/debian-changes in this case) How does that sound? (Thanks to mrvn who suggested me the ideas) How about implying --single-debian-patch when debian/source/debian-patch-header exists? -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems a human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. specialization is for insects. -- robert heinlein -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Raphael Hertzog hert...@debian.org writes: On Wed, 25 Nov 2009, Russ Allbery wrote: I've considered using TopGit to generate a real quilt patch set, but it's kind of complicated and I'm not convinced that the work required to generate the exported patch tree even with TopGit is really worth it. Given that, for packages currently maintained in Git, 3.0 (quilt) is extra complexity over 1.0 that doesn't seem to be buying me very much. Why not generate a single patch then instead of a patch set? If that single patch contains an header explaining why it's not split and where you can review the changes in a more friendly manner you can have all the other features of the new format and yet the the situation improve wrt to knowledge/advertisement of our debian-specific changes. Generating the single patch out of Git is nearly as complex as generating a patch series if dpkg-source doesn't just do it for me (as it does with the 1.0 format). I know 3.0 (quilt) will as well (without any header), but it doesn't really provide any functionality over 1.0 for this use case and adds some extra complexity. However... I would be ok to add support for this in 3.0 (quilt): - add an option --single-debian-patch that could be set in debian/source/options. With this option dpkg-source would update debian/patches/debian-changes (instead of debian-changes-ver) - support a debian/source/debian-patch-header that would be used as header of the automatic patch (debian/patches/debian-changes in this case) How does that sound? (Thanks to mrvn who suggested me the ideas) ...I think this is a really good idea, particularly since I can understand not wanting, in the very long run, to support multiple patch formats. Seems like a fairly reasonable approach to me. -- 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
Re: New source package formats now available
On Tue, Nov 24, 2009 at 02:02:02AM +0100, Raphael Hertzog wrote: dpkg-source -b heimdal-1.3.1.dfsg.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying all patches with quilt push -q 030_autotools Applying patch 011_sharedlibs Applying patch 020_maintainermode Applying patch 021_debian Applying patch 022_openafs Applying patch 024_rxtelnet Applying patch 025_pthreads Applying patch 027_rsh_use_ktelnet Applying patch 030_autotools Now at patch 030_autotools dpkg-source: info: building heimdal using existing ./heimdal_1.3.1.dfsg.1.orig.tar.gz dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave error exit status 1 dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit status 2 You probably have upstream changes that are not under quilt's control (they appear in the .diff.gz up to now). And one of your patches depends on that change... without it it doesn't apply. Thus the quilt series fails to apply on directory with only the upstream tarball unpacked. Just for the record, I think I have a good guess what happened here, basically the process I used to change to a new upstream source was flawed, and this was not immediately obvious. (this is not intended to be read as a complaint, just my general observations) Anyway, I used uupdate to update to the new source code. I think at the time there must have been some changes to the source code with respect to the org.tar.gz I wasn't aware of. uupdate loyally copied these changes to the new version, and I created a new autotools patch on top of these changes. Previously, while yucky, this wouldn't be a problem, because the base changes would get applied first, before the quilt patches get applies. With the new source code system, my understanding is that the patches get applied in the opposite order - patches from debian/patches get applied first, and any extra changes are applied last in the list. Hence it didn't work, as the autotools patch was based on changes I hadn't realized were there. It seems the best way to upgrade to a new upstream version may be to copy the debian subtree by hand, and ignore uupdate. -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Thu, Nov 26, 2009 at 09:09:45AM +0100, Raphael Hertzog a écrit : On Thu, 26 Nov 2009, Charles Plessy wrote: even simpler, an option or a format that would completely ignore what is outside the debian directory: That's option -i.*. As I said I plan to support the -i -I option inside debian/source/options just like I recently added support for -z -Z there. That would be a useful compromise. How about the second half, which is to not patch anything during the unpacking of the package? Maybe this could be combined in a single ‘no-patch’ option, or an alias like ’3.0 (simple)’? Le Thu, Nov 26, 2009 at 12:30:12PM -0800, Russ Allbery a écrit : I can understand not wanting, in the very long run, to support multiple patch formats. Does that mean that the use of options discussed above may become forbidden in our archive in the future? If yes, there is little point making concessions now… The best way to avoid the burden of supporting multiple patch formats in dpkg-dev is to leave this task to the maintainers. 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
Re: New source package formats now available
Le Tue, Nov 24, 2009 at 08:17:17AM +0100, Raphael Hertzog a écrit : I can add a new option --no-debian-patch that would refuse to create the automatic quilt patch debian-changes-ver and make it fail instead if there are upstream changes. Hi Raphaël, even simpler, an option or a format that would completely ignore what is outside the debian directory: - When packing a source package, a compressed tar archive would be made from the contents of the debian directory. - When unpacking a source package, the compressed debian tar archive would be unpacked in the upstream sources, after deleting any existing debian directory. As it is already the case with Format 1.0 when the maintainer took care of having a diff.gz file that only contains files within the debian directory, the packaging system would not patch or unpatch the upstream sources, leaving this task to the maintainer. 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
Re: New source package formats now available
Raphael Hertzog hert...@debian.org writes: On Mon, 23 Nov 2009, Joey Hess wrote: I understand that you do not want to throw away your work on this patch management system, but by making it optional, I think that you will actually increase your chances of success… I think that's very wise. It is optional already. Just don't make any direct changes to upstream files. What else do you need? Until we have 3.0 (git), I think I'm going to stick with direct source modifications to the upstream source and hence with version 1.0. I've considered using TopGit to generate a real quilt patch set, but it's kind of complicated and I'm not convinced that the work required to generate the exported patch tree even with TopGit is really worth it. Given that, for packages currently maintained in Git, 3.0 (quilt) is extra complexity over 1.0 that doesn't seem to be buying me very much. It would be nice, however, to have the other features of the 3.0 format (including binaries in the debian directory, not shipping the debian directory as a patch, using multiple upstream tarballs, using bzip2-compressed upstream tarballs) without having the quilt-like patch system in play. -- 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
Re: New source package formats now available
Raphael Hertzog hert...@debian.org writes: On Tue, 24 Nov 2009, Goswin von Brederlow wrote: Bugs as of today. * Packages with different patch systems like linux-2.6. In this case dpkg-source ignores failures to register a patch and produces sources without the changes. (#557618) As discussed on IRC this is a matter of false advertising by the announcement and the wiki. Which also seems to be the main problem Rhonda has with the format. It's not false advertising. The problem that Bastian saw is that quilt is not returning an error when debian/patches/series is not a file. I'm going to check for that in the next dpkg version. In the special case of linux-2.6 that might be a bug. But how will 3.0 (quilt) format then work? So it doesn't go and do something crazy anymore. Instead it fails. That is not working. And I there were more examples in the thread like e.g. wesnoth. YOU CAN NOT MIX PATCH SYSTEMS. You certainly can. It doesn't mean that it's always a good idea though. For packages like linux-2.6, it makes sense. I made some choices to avoid conflicts with other patch systems, in particular no .patch or .diff extension to automatic patches so that they are not picked up by patch systems like simple-patchsys. Cheers, -- Raphaël Hertzog If it works it is luck. It only works if the patch system does not pick up any of the dpkg files and dpkg does not pick up any of the patch systems files. Which generaly is not the case. Gnerally you have to do some work to make sure nothing conflicts or to make it not conflict. Esspecially the case where the packages patch system is quilt is tricky as it works if dpkg uses quilt (if quilt is installed before dpkg-source is called) but not if quilt is pulled in later through Build-Depends. So while you can make the two work side by side, if you seperate them enough, I stand by what I wrote for the general case. Blindly mixing patch systems spells disaster. The advertising makes it sound like it will magcially always work. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Raphael Hertzog hert...@debian.org writes: Hi, On Sat, 21 Nov 2009, Mike Hommey wrote: The modifications are implied, but it means that the source format is already this heavy modification, on a similarly heavy modification scale. Additionally, if someone wants to sepearte the patches into feature-patches instead of one-modification-patch-per-upload they will have to additionally pull in quilt anyway to work on it properly, Well, they can drop the patch in debian/patches, and add it to the end of debian/patches/series. If quilt is installed, it should work as dpkg-source will use quilt applied to know whether patches needs to be applied. If quilt is not installed, it assumes all patches are applied, so you should also apply the patch. Are you sure about that? dpkg creates a debian/patches/dpkg-applied-patches file listing the patches it has applied. It should notice when the series file has more patches than were applied and remedy the situation. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Mike Hommey m...@glandium.org writes: On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote: Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. Fixing cosmetic issues or changing the packaging style in NMUs is discouraged. Adding a patching system is surely changing the packaging style. OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. My point is : dpkg-source -x should be idempotent, whatever other packages are installed when you do it. The fact that you can't dpkg-source -x, and *then* install quilt to manage the patches is a nuisance. Mike There could be a simple call to dpkg to quiltify the source. But what it comes down to is to unpack the orig, apply patches witzh quilt and then copy over the .pc directory. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Mike Hommey m...@glandium.org writes: On Sun, Nov 22, 2009 at 11:30:45AM +0100, Raphael Hertzog wrote: On Sun, 22 Nov 2009, Mike Hommey wrote: On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote: Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. Fixing cosmetic issues or changing the packaging style in NMUs is discouraged. Adding a patching system is surely changing the packaging style. Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you can't do the right thing in a NMU, either you break the above rule or you have to meld patches in the .diff.gz with no other information than what you put in the changelog. No, you don't have to meld patches in the .diff.gz, you just do your changes, put an entry in debian/changelog and do dpkg-source -b. Nothing more. It's actually much more NMU-friendly than having to deal with a patch system. OTOH, 3.0 (quilt) is a patch system without being one, so it is a bit less pain. But it is not more NMU-friendly than plain 1.0. It is more NMU-friendly than 1.0 + patch system, though. Mike More friendly to the reciever of the NMU (maintainer) as the change will be nicely sperated in debian/patches. At no cost to the NMUer if he doesn't want to use quilt. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi! :) * Raphael Hertzog hert...@debian.org [2009-11-22 10:48:14 CET]: Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 (native), which kind of suggests 3.0 (quilt) is being forced down. That's maybe not what you are thinking, but it's how it feels. Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native packages and 3.0 (quilt) is for all the other who have an upstream tarball + a debian dir. Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). If you want to really make proper use of it (like seperating into feature patches instead of one per upload) you need to have quilt installed anyway, and speaking of NMUs, people that just download the source, patch and upload will produce low-standard patches, most probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't really offer what quilt offers. It feels a bit like the regression that svn brought on top of cvs with taking away the posibility to tag properly (but create tag-branches instead). 3.0 (quilt) looks like a good idea, but it's still rough at the edges somehow. :/ And about not needing a README.Source for it, I don't see that because otherwise we wouldn't have the need for discussions like that, especially if we want to have proper DEP3 tagged patches. :) OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. It is causing troubles for people that are familiar with quilt and think they will be able to work with quilt with the source package when they dpkg-source -x it - which unfortunately isn't the case. Only when quilt is installed, but then, this is getting different results depending on the environment one has, and I thought this was always one of the big NO-GOs in Debian that we should avoid - and here we have it even intentional? Sorry that this doesn't make me (and from what I can see others too) happy :/ About you just have to install quilt - *before* you unpack the source. If you install it afterwards, you have lost. So long, and thanks. :) Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, 23 Nov 2009, Goswin von Brederlow wrote: Well, they can drop the patch in debian/patches, and add it to the end of debian/patches/series. If quilt is installed, it should work as dpkg-source will use quilt applied to know whether patches needs to be applied. If quilt is not installed, it assumes all patches are applied, so you should also apply the patch. Are you sure about that? Yes. dpkg creates a debian/patches/dpkg-applied-patches file listing the patches it has applied. It should notice when the series file has more patches than were applied and remedy the situation. It was partly the goal when I created this file but it simply creates more problems than it solves. You can't be sure that this file really corresponds to the current state of the tree, it's created at unpack time but it's not maintained over time when you rebuild. In the end, I decided to trust nothing and to verify if the first patch can be applied or not. If it can be applied, we assume that the patches have not been applied and we apply them all (unless --no-preparation is given). If quilt is available, instead of checking the first patch, I check the first patch returned by quilt unapplied and apply the remaining of the patches if needed. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Gerfried Fuchs rho...@deb.at writes: Hi! :) * Raphael Hertzog hert...@debian.org [2009-11-22 10:48:14 CET]: Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 (native), which kind of suggests 3.0 (quilt) is being forced down. That's maybe not what you are thinking, but it's how it feels. Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native packages and 3.0 (quilt) is for all the other who have an upstream tarball + a debian dir. Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). If you want to really make proper use of it (like seperating into feature patches instead of one per upload) you need to have quilt installed anyway, and speaking of NMUs, people that just download the source, patch and upload will produce low-standard patches, most probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't really offer what quilt offers. It feels a bit like the regression that svn brought on top of cvs with taking away the posibility to tag properly (but create tag-branches instead). Why do you think that? I can split patches any which way and edit the debian/patches/series to match all completly without quilt. It only becomes simpler with quilt and you would always have it installed. A 3.0 (native) + quilt package would force people to use quilt and result in build failures for anyone missing the fact you use quilt manually instead of 3.0 (quilt) format. There really is no advantage in that. 3.0 (quilt) looks like a good idea, but it's still rough at the edges somehow. :/ And about not needing a README.Source for it, I don't see that because otherwise we wouldn't have the need for discussions like that, especially if we want to have proper DEP3 tagged patches. :) Improvements are always welcome. OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. It is causing troubles for people that are familiar with quilt and think they will be able to work with quilt with the source package when they dpkg-source -x it - which unfortunately isn't the case. Only when quilt is installed, but then, this is getting different results depending on the environment one has, and I thought this was always one of the big NO-GOs in Debian that we should avoid - and here we have it even intentional? Sorry that this doesn't make me (and from what I can see others too) happy :/ And as a quilt using person you often have quilt not installed? Worst case you unpack the source again after installing quilt. So far this only happened to me once. Since then I have quilt installed per default in new chroots ment for compiling. About you just have to install quilt - *before* you unpack the source. If you install it afterwards, you have lost. So you do want a dpkg-source --quiltify-source to fix this post unpacking instead of manually unpacking the source again? Maybe dpkg could note if a package was specifically unpacked without quilt and otherwise quiltify the source during build when quilt happens to be available now. So long, and thanks. :) Rhonda MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, 23 Nov 2009, Gerfried Fuchs wrote: Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). Yay for reuploading the full tarball for each revision! I'd rather you keep using 1.0 instead of doing this... If you want to really make proper use of it (like seperating into feature patches instead of one per upload) you need to have quilt installed anyway, and speaking of NMUs, people that just download the source, patch and upload will produce low-standard patches, most probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't really offer what quilt offers. It feels a bit like the regression that svn brought on top of cvs with taking away the posibility to tag properly (but create tag-branches instead). The automatic patch now features DEP-3 headers by default. The NMUer can rename it and edit the headers easily. If he wants to create one patch per feature, he can simply rebuild the source package after having applied each patch. For each patch: - apply patch - dpkg-buildpackage -S - rename debian/patches/debian-changes-ver into something else and edit its headers - fix debian/patches/series Note: this works only if quilt is not installed (or if you ensure dpkg-source is called with --without-quilt which you currently can't pass via dpkg-buildpackage). I would certainly prefer using quilt directly but it's not required if you don't have it installed. 3.0 (quilt) looks like a good idea, but it's still rough at the edges somehow. :/ And about not needing a README.Source for it, I don't see It's new, it's just that we haven't developed the toolset around it. I always expected that people would start developing new tools à la devscripts to make it easier for some specific scenario. And I'm including improvements that make sense based on the feedback that I get. that because otherwise we wouldn't have the need for discussions like that, especially if we want to have proper DEP3 tagged patches. :) Well, everything has a learning curve. It's normal to have to learn once. The point of README.source was to document stuff that not all DD are supposed to know. Knowledge of the new source format will be common in the near future. It is causing troubles for people that are familiar with quilt and think they will be able to work with quilt with the source package when they dpkg-source -x it - which unfortunately isn't the case. Only when quilt is installed, but then, this is getting different results depending on the environment one has, and I thought this was always one of the big NO-GOs in Debian that we should avoid - and here we have it even intentional? Sorry that this doesn't make me (and from what I can see others too) happy :/ Well, people familiar with quilt have it already installed. And most packages are built out of VCS with patches un-applied so it doesn't even matter in most cases. I have nothing against adding quilt to dependencies of dpkg-dev but I can tell that I will get the same number of grumbles from other people equally unhappy with that choice. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
* Goswin von Brederlow goswin-...@web.de [2009-11-23 09:48:36 CET]: Why do you think that? I can split patches any which way and edit the debian/patches/series to match all completly without quilt. How so? I don't find anything in man dpkg or dpkg-source that would help with that. It only becomes simpler with quilt and you would always have it installed. A 3.0 (native) + quilt package would force people to use quilt and result in build failures for anyone missing the fact you use quilt manually instead of 3.0 (quilt) format. There really is no advantage in that. ?! What build failures? Can you please elaborate on why would you see build failures down that path, anywhere?! There's the advantage in it that people actually *do* have quilt installed to work properly with the (implied) quilt patches instead of maybe having it not around and still are expected to work on the patches. It is causing troubles for people that are familiar with quilt and think they will be able to work with quilt with the source package when they dpkg-source -x it - which unfortunately isn't the case. Only when quilt is installed, but then, this is getting different results depending on the environment one has, and I thought this was always one of the big NO-GOs in Debian that we should avoid - and here we have it even intentional? Sorry that this doesn't make me (and from what I can see others too) happy :/ And as a quilt using person you often have quilt not installed? This isn't about me or you but about NMUing people or others you want to have working on the package. And the question is trying to distract from the issue and not answering the question, sorry. Worst case you unpack the source again after installing quilt. So far this only happened to me once. Since then I have quilt installed per default in new chroots ment for compiling. Worst case you don't know about it because it is said to not require a README.Source anymore and is nowhere really hinted that it will give you different results. About you just have to install quilt - *before* you unpack the source. If you install it afterwards, you have lost. So you do want a dpkg-source --quiltify-source to fix this post unpacking instead of manually unpacking the source again? I would expect a dpkg-source -x to always result in the same thing, no matter wether quilt is installed or not. And when the format claims to be (quilt) I expect it to be quilt-ready *by default*. Implementing just a subset but calling that subset with the same name is just confusing. :/ So long. :) Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 09:30:00AM +0100, Raphael Hertzog wrote: On Mon, 23 Nov 2009, Goswin von Brederlow wrote: Well, they can drop the patch in debian/patches, and add it to the end of debian/patches/series. If quilt is installed, it should work as dpkg-source will use quilt applied to know whether patches needs to be applied. If quilt is not installed, it assumes all patches are applied, so you should also apply the patch. Are you sure about that? Yes. dpkg creates a debian/patches/dpkg-applied-patches file listing the patches it has applied. It should notice when the series file has more patches than were applied and remedy the situation. It was partly the goal when I created this file but it simply creates more problems than it solves. You can't be sure that this file really corresponds to the current state of the tree, it's created at unpack time but it's not maintained over time when you rebuild. In the end, I decided to trust nothing and to verify if the first patch can be applied or not. If it can be applied, we assume that the patches have not been applied and we apply them all (unless --no-preparation is given). If quilt is available, instead of checking the first patch, I check the first patch returned by quilt unapplied and apply the remaining of the patches if needed. The more I read your mails in this thread, the more I think you should dump the part that doesn't require quilt, and make dpkg-dev depend on quilt. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
* Raphael Hertzog hert...@debian.org [2009-11-23 09:50:15 CET]: On Mon, 23 Nov 2009, Gerfried Fuchs wrote: Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). Yay for reuploading the full tarball for each revision! I'd rather you keep using 1.0 instead of doing this... But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill off 1.0 and implicit convert it to 3.0 (quilt) so keep using 1.0 would still mean having to change stuff in the package. The automatic patch now features DEP-3 headers by default. The NMUer can rename it and edit the headers easily. If he wants to create one patch per feature, he can simply rebuild the source package after having applied each patch. Have you tried rebuilding the source package after having applied a patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data? :) For each patch: - apply patch - dpkg-buildpackage -S - rename debian/patches/debian-changes-ver into something else and edit its headers - fix debian/patches/series Note: this works only if quilt is not installed (or if you ensure dpkg-source is called with --without-quilt which you currently can't pass via dpkg-buildpackage). Ah yes, again different workflows required - so we actually do need a README.Source to warn people to not having quilt installed when working with 3.0 (quilt) format? This sounds a bit backwards and strange, to be honest. It's new, it's just that we haven't developed the toolset around it. I always expected that people would start developing new tools à la devscripts to make it easier for some specific scenario. Expecting others to jump the wagon isn't something you should depend on, you are well adviced to be ready to do the work yourself in case your expectations are over the top. :) Well, everything has a learning curve. It's normal to have to learn once. The point of README.source was to document stuff that not all DD are supposed to know. Knowledge of the new source format will be common in the near future. Given that there seems to be different workflows needed and required depending on what packages one has installed I still see the need for that, to be honest ... Well, people familiar with quilt have it already installed. And most packages are built out of VCS with patches un-applied so it doesn't even matter in most cases. That's unfortunately still evading the problem at hand. dpkg-source isn't giving well-defined results, it acts differently with different stuff installed. :/ I have nothing against adding quilt to dependencies of dpkg-dev but I can tell that I will get the same number of grumbles from other people equally unhappy with that choice. Wouldn't it be possible to make dpkg able to create the .pc directory with the stuff quilt needs to know? That would produce a well-defined result and not different results on different systems. So long! Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 10:10:51AM +0100, Gerfried Fuchs wrote: * Raphael Hertzog hert...@debian.org [2009-11-23 09:50:15 CET]: On Mon, 23 Nov 2009, Gerfried Fuchs wrote: Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). Yay for reuploading the full tarball for each revision! I'd rather you keep using 1.0 instead of doing this... But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill off 1.0 and implicit convert it to 3.0 (quilt) so keep using 1.0 would still mean having to change stuff in the package. The automatic patch now features DEP-3 headers by default. The NMUer can rename it and edit the headers easily. If he wants to create one patch per feature, he can simply rebuild the source package after having applied each patch. Have you tried rebuilding the source package after having applied a patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data? :) Actually, on big packages, the latest dpkg-source is now 5 to 10 times as fast as the old one. (for any format, for that matter) Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Gerfried Fuchs rho...@deb.at writes: * Goswin von Brederlow goswin-...@web.de [2009-11-23 09:48:36 CET]: Why do you think that? I can split patches any which way and edit the debian/patches/series to match all completly without quilt. How so? I don't find anything in man dpkg or dpkg-source that would help with that. In the section about 3.0 (quilt) the section in Extracting says: All patches listed in debian/patches/debian.series or debian/patches/series are then applied. And in Building it says following the same logic as for the unpack and explains a bit more. Nowhere does it say you can not split, merge, edit patches or the series file to your likeing. It only becomes simpler with quilt and you would always have it installed. A 3.0 (native) + quilt package would force people to use quilt and result in build failures for anyone missing the fact you use quilt manually instead of 3.0 (quilt) format. There really is no advantage in that. ?! What build failures? Can you please elaborate on why would you see build failures down that path, anywhere?! There's the advantage in it that people actually *do* have quilt installed to work properly with the (implied) quilt patches instead of maybe having it not around and still are expected to work on the patches. You unpack the source, edit some file and try to build. Suddenly quilt fails to apply patches. Or you unpack, build the package once to check the debian source still builds cleanly, edit some file and then clean fails to unapply patches. Or you know the package uses quilt and you use it. But, since you are new to quilt, you forget to quilt add file before editing and then you don't know how to fix that again. Note that with 3.0 (quilt) people are not required to work on the patches and for an NMU I'm not sure what is better: A change in an existing patch or a small additional patch on top. It is causing troubles for people that are familiar with quilt and think they will be able to work with quilt with the source package when they dpkg-source -x it - which unfortunately isn't the case. Only when quilt is installed, but then, this is getting different results depending on the environment one has, and I thought this was always one of the big NO-GOs in Debian that we should avoid - and here we have it even intentional? Sorry that this doesn't make me (and from what I can see others too) happy :/ And as a quilt using person you often have quilt not installed? This isn't about me or you but about NMUing people or others you want to have working on the package. And the question is trying to distract from the issue and not answering the question, sorry. Worst case you unpack the source again after installing quilt. So far this only happened to me once. Since then I have quilt installed per default in new chroots ment for compiling. Worst case you don't know about it because it is said to not require a README.Source anymore and is nowhere really hinted that it will give you different results. As said above. I'm not sure I want them to work on the existing patches. Esspecially if you have meta infos in them about being send upstream and so on. It is probably best if an NMUer just gets the source, edits, builds and sends the automatically created debian/patches/debian-changes-1.2-3.1 file to the BTS. About you just have to install quilt - *before* you unpack the source. If you install it afterwards, you have lost. So you do want a dpkg-source --quiltify-source to fix this post unpacking instead of manually unpacking the source again? I would expect a dpkg-source -x to always result in the same thing, no matter wether quilt is installed or not. And when the format claims to be (quilt) I expect it to be quilt-ready *by default*. Implementing just a subset but calling that subset with the same name is just confusing. :/ Yeah. It annoyed me once and then I added quilt to the list of packages to be installed in a fresh chroot by default. How about this solution: dpkg-dev should recommend quilt. While dpkg-dev works fine without quilt I too believe quilt should always be installed when 3.0 (quilt) format is supposed to be(come) the default format. A recommends would install quilt by default but not require it. So long. :) Rhonda and thanks for all the fish. Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, 23 Nov 2009, Bastian Blank wrote: I tried 3.0 (quilt) with several packages today and none worked properly, so several large packages will be stuck with 3.0 (native). 1.0 is not going away even if we change the default. Bugs as of today. Won't comment here. I have already commented an each individual bugs and will fix those that make sense. The whole thing is super fragile. It is mostly impossible to use both 3.0 (quilt) and quilt themself because you use it to develop. That's just wrong. I do it without problems by using the .quiltrc snippet from /usr/share/doc/quilt/README.source. I will propose a GR to stop you if you go on until it works properly. That's always a nice thing to say at the start of a discussion. You have proven once more that your social skills suck. And yes, this includes packages like linux-2.6, which have to use a more sophisticated patch system than quilt. If you avoid the conflict on debian/patches/series being a directory instead of a file, there's no reason it will be more problematic than a random package. Just use another directory name and let that file empty in case someone changes an upstream files without using your custom patch system. Or you start and propose a different format that can be mostly like 3.0 (quilt) for the result (multiple tars) but without the implicit quilt constraints. Not me, no. And people should have requested that 1-2 years ago when we were discussing the new formats in -devel. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote: Am I doing something wrong? sys11:/home/brian/tree/heimdal# lintian heimdal_1.2.e1.dfsg.1-5_i386.changes warning: lintian's authors do not recommend running it with root privileges! internal error: command failed with error code 25 warning: could not unpack package to desired level warning: skipping check of source package heimdal What does error 25 mean? As I got no response, I submitted bug #557717. Next problem: [...] dpkg-source -b heimdal-1.3.1.dfsg.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying all patches with quilt push -q 030_autotools Applying patch 011_sharedlibs Applying patch 020_maintainermode Applying patch 021_debian Applying patch 022_openafs Applying patch 024_rxtelnet Applying patch 025_pthreads Applying patch 027_rsh_use_ktelnet Applying patch 030_autotools Now at patch 030_autotools dpkg-source: info: building heimdal using existing ./heimdal_1.3.1.dfsg.1.orig.tar.gz dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave error exit status 1 dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit status 2 debuild: fatal error at line 1330: dpkg-buildpackage -rfakeroot -d -us -uc -S failed -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
For each patch:
- apply patch
- dpkg-buildpackage -S
- rename debian/patches/debian-changes-ver into something else
and edit its headers
- fix debian/patches/series
Note: this works only if quilt is not installed (or if you ensure
dpkg-source is called with --without-quilt which you currently can't pass
via dpkg-buildpackage).
JFTR, is also works with quilt installed, given that you don't rename
applied patches.
The following shell function automates the required quilt pop/push and
the adjustment of the series file:
dquilt-rename() {
(
source $HOME/.quiltrc;
cd ${QUILT_PATCHES:-patches};
j=`quilt applied | wc -l`;
quilt pop -a;
if [ -f $1 ] ! [ -f $2 ];
then
mv $1 $2;
sed -i s/^$1\$/$2/ series;
fi;
for i in $(seq $j); do
quilt push || [ $? eq 2 ] || return 1;
done
)
}
I just wrote it and only ran it once, so don't expect it to be mature.
It requires the snippet given in /usr/share/doc/quilt/README.source as
$HOME/.quiltrc.
Regards
Carsten
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Tue, 24 Nov 2009, Brian May wrote: Next problem: [...] dpkg-source -b heimdal-1.3.1.dfsg.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying all patches with quilt push -q 030_autotools Applying patch 011_sharedlibs Applying patch 020_maintainermode Applying patch 021_debian Applying patch 022_openafs Applying patch 024_rxtelnet Applying patch 025_pthreads Applying patch 027_rsh_use_ktelnet Applying patch 030_autotools Now at patch 030_autotools dpkg-source: info: building heimdal using existing ./heimdal_1.3.1.dfsg.1.orig.tar.gz dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave error exit status 1 dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit status 2 You probably have upstream changes that are not under quilt's control (they appear in the .diff.gz up to now). And one of your patches depends on that change... without it it doesn't apply. Thus the quilt series fails to apply on directory with only the upstream tarball unpacked. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote: In the end, I decided to trust nothing and to verify if the first patch can be applied or not. If it can be applied, we assume that the patches have not been applied and we apply them all (unless --no-preparation is given). If quilt is available, instead of checking the first patch, I check the first patch returned by quilt unapplied and apply the remaining of the patches if needed. This heuristic is likely to fail - patches that solely add content can apply repeatedly without error. -Rob signature.asc Description: This is a digitally signed message part
Re: New source package formats now available
On Tue, Nov 24, 2009 at 01:53:34AM +0100, Carsten Hey wrote:
On Mon, Nov 23, 2009 at 09:50:15AM +0100, Raphael Hertzog wrote:
For each patch:
- ...
Note: this works only if quilt is not installed (or if you ensure
dpkg-source is called with --without-quilt which you currently can't pass
via dpkg-buildpackage).
JFTR, is also works with quilt installed, given that you don't rename
applied patches.
The following shell function automates the required quilt pop/push and
the adjustment of the series file:
dquilt-rename() {
...
}
Or just use quilt rename instead ;)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Tue, Nov 24, 2009 at 12:32:40AM +0100, Raphael Hertzog a écrit : Or you start and propose a different format that can be mostly like 3.0 (quilt) for the result (multiple tars) but without the implicit quilt constraints. Not me, no. And people should have requested that 1-2 years ago when we were discussing the new formats in -devel. Maybe it is because you never wanted to listen to people who were interested to have the debian directory in a tar.gz, without a patch system on top of it? I answered to your feedback request, realised that you were not going to change your mind about format ‘3.0 (quilt)’, and then gave up. How many others? I understand that you do not want to throw away your work on this patch management system, but by making it optional, I think that you will actually increase your chances of success… Cheers, -- 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
Re: New source package formats now available
Charles Plessy wrote: Maybe it is because you never wanted to listen to people who were interested to have the debian directory in a tar.gz, without a patch system on top of it? I answered to your feedback request, realised that you were not going to change your mind about format ‘3.0 (quilt)’, and then gave up. How many others? I didn't work much on 3.0 (git) beyond submission, because I was getting a definite vibe that Raphael was interested in his quilt format and only that format. Perhaps Raphael in turn was sensing that I didn't have a deep knowledge of git -- I had only used it for a month or so at the time. And in fact, we now know a much better way to do a git based format. I have been considering working on it again, after #554682 is fixed. I understand that you do not want to throw away your work on this patch management system, but by making it optional, I think that you will actually increase your chances of success… I think that's very wise. -- see shy jo signature.asc Description: Digital signature
Re: New source package formats now available
Raphael Hertzog wrote: That's just wrong. I do it without problems by using the .quiltrc snippet from /usr/share/doc/quilt/README.source. Hmm, that is verging on beware of the leopard non-obviousness. I mean, you just argued in another mail that such a README.source would soon not be necessary. Perhaps a little wrapper script to run quilt with the right QUILT_PATCHES could make this slightly easier. -- see shy jo signature.asc Description: Digital signature
Re: New source package formats now available
On Tue, Nov 24, 2009 at 02:02:02AM +0100, Raphael Hertzog wrote: On Tue, 24 Nov 2009, Brian May wrote: Next problem: [...] dpkg-source -b heimdal-1.3.1.dfsg.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying all patches with quilt push -q 030_autotools Applying patch 011_sharedlibs Applying patch 020_maintainermode Applying patch 021_debian Applying patch 022_openafs Applying patch 024_rxtelnet Applying patch 025_pthreads Applying patch 027_rsh_use_ktelnet Applying patch 030_autotools Now at patch 030_autotools dpkg-source: info: building heimdal using existing ./heimdal_1.3.1.dfsg.1.orig.tar.gz dpkg-source: error: quilt --quiltrc /dev/null push -q 030_autotools gave error exit status 1 dpkg-buildpackage: error: dpkg-source -b heimdal-1.3.1.dfsg.1 gave error exit status 2 You probably have upstream changes that are not under quilt's control (they appear in the .diff.gz up to now). And one of your patches depends on that change... without it it doesn't apply. Thus the quilt series fails to apply on directory with only the upstream tarball unpacked. Ok, I did the following: 1. Extract clean tar ball 2. Copy debian directory from old 3. Ensure all patches are clean and apply 4. run debuild -us -uc -S, which runs dpkg-buildpackage -rfakeroot -d -us -uc -S === cut === dpkg-buildpackage -rfakeroot -d -us -uc -S dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: -Wl,-Bsymbolic-functions dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package heimdal dpkg-buildpackage: source version 1.3.1.dfsg.1-1 dpkg-buildpackage: source changed by Brian May b...@snoopy.debian.net fakeroot debian/rules clean test -x debian/rules dh_testroot /usr/bin/make -C . -k distclean make[1]: Entering directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1' make[1]: *** No rule to make target `distclean'. make[1]: Leaving directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1' make: [makefile-clean] Error 2 (ignored) rm -f debian/stamp-makefile-build for i in ./config.guess ./config.sub ; do \ if test -e $i.cdbs-orig ; then \ mv $i.cdbs-orig $i ; \ fi ; \ done dh_clean rm -f debian/stamp-autotools-files /usr/bin/make -f debian/rules reverse-config make[1]: Entering directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1' for i in ./config.guess ./config.sub ; do \ if test -e $i.cdbs-orig ; then \ mv $i.cdbs-orig $i ; \ fi ; \ done make[1]: Leaving directory `/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1' if [ -d . ]; then \ cd . QUILT_PATCHES=/home/brian/tree/heimdal/heimdal-1.3.1.dfsg.1/debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 ; \ fi Removing patch 027_rsh_use_ktelnet Restoring appl/rsh/rsh.c Restoring appl/rsh/rsh.1 Removing patch 025_pthreads Restoring cf/pthreads.m4 Removing patch 024_rxtelnet Restoring appl/kx/rxtelnet.in Restoring appl/kx/rxterm.in Removing patch 022_openafs Restoring lib/krb5/keytab_keyfile.c Removing patch 021_debian Restoring kdc/kdc.8 Restoring doc/setup.texi Restoring appl/telnet/telnetd/telnetd.h Removing patch 020_maintainermode Restoring configure.in Removing patch 011_sharedlibs Restoring tools/krb5-config.in No patches applied rm -rf ./.pc rm -f debian/stamp-patch* # clean files not cleaned by make file rm -f appl/rsh/login_access.c rm -f appl/rsh/rsh.cat1 rm -f include/*.h rm -f include/kadm5/*.h rm -f include/version.h.in rm -f krb5/libkrb5.ver rm -f lib/com_err/Makefile rm -f lib/com_err/snprintf.c rm -f lib/com_err/strlcpy.c rm -f lib/des/Makefile rm -f lib/editline/Makefile rm -f lib/krb5/libkrb5.ver rm -f lib/otp/snprintf.c rm -f lib/otp/strcasecmp.c rm -f lib/otp/strlcat.c rm -f lib/otp/strlcpy.c rm -f lib/otp/strlwr.c rm -f lib/otp/strncasecmp.c rm -f lib/sl/slc-gram.c rm -f lib/sl/slc-gram.h rm -f lib/sl/slc-lex.c rm -f appl/ftp/ftpd/ftpcmd.c rm -f lib/otp/ndbm_wrap.c rm -f lib/otp/ndbm_wrap.h rm -f lib/wind/*.pyc rm -f doc/heimdal.info rm -f lib/hx509/sel-gram.c rm -f lib/roken/roken-glob.h dpkg-source -b heimdal-1.3.1.dfsg.1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: warning: patches have not been applied, applying them now (use --no-preparation to override) dpkg-source: info: applying all patches with quilt push -q 030_autotools Applying patch 011_sharedlibs Applying patch 020_maintainermode Applying patch 021_debian Applying patch 022_openafs Applying patch 024_rxtelnet Applying patch 025_pthreads Applying patch 027_rsh_use_ktelnet Applying patch 030_autotools 9 out of 42 hunks FAILED Patch 030_autotools does not apply (enforce with -f) dpkg-source: error: quilt
Re: New source package formats now available
On So, 22 Nov 2009, Steve Langasek wrote: and as far as I see: clean: unpatch Well, the latter is wrong - this breaks if you're patching the build system. Ah, good to know, but well, my poiint is that this is a bit a PITA if the system changes again and again. But that has nothing to do with the source package format (which would alleviate us from thinking about that ;-) Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- OSSETT (n.) A frilly spare-toilet-roll-cosy. --- 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
Re: New source package formats now available
On Tue, Nov 24, 2009 at 02:30:59PM +1100, Brian May wrote: Ok, I did the following: Disregard those results, I screwed up and forgot to cd into the new working directory after I moved the old one. So it looked OK but wasn't. Retry. Hmmm. So far it looks better... -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, Nov 23 2009, Joey Hess wrote: Perhaps Raphael in turn was sensing that I didn't have a deep knowledge of git -- I had only used it for a month or so at the time. And in fact, we now know a much better way to do a git based format. I have been considering working on it again, after #554682 is fixed. I would like to help, especially when it comes to support for submodules. manoj -- Youth had been a habit of hers so long that she could not part with it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Gerfried Fuchs rho...@deb.at writes: * Raphael Hertzog hert...@debian.org [2009-11-23 09:50:15 CET]: On Mon, 23 Nov 2009, Gerfried Fuchs wrote: Actually, I feel rather to convert my packages to 3.0 (native) + quilt. The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to me). Yay for reuploading the full tarball for each revision! I'd rather you keep using 1.0 instead of doing this... But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill off 1.0 and implicit convert it to 3.0 (quilt) so keep using 1.0 would still mean having to change stuff in the package. The automatic patch now features DEP-3 headers by default. The NMUer can rename it and edit the headers easily. If he wants to create one patch per feature, he can simply rebuild the source package after having applied each patch. Have you tried rebuilding the source package after having applied a patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data? :) For each patch: - apply patch - dpkg-buildpackage -S - rename debian/patches/debian-changes-ver into something else and edit its headers - fix debian/patches/series Note: this works only if quilt is not installed (or if you ensure dpkg-source is called with --without-quilt which you currently can't pass via dpkg-buildpackage). Ah yes, again different workflows required - so we actually do need a README.Source to warn people to not having quilt installed when working with 3.0 (quilt) format? This sounds a bit backwards and strange, to be honest. Full ACK. There should be a dpkg-edit-patch, dpkg-rename-patch, dpkg-import-patch, ... to hide the difference of with or without quilt if dpkg wants to keep going that way. I suggested something like that in the past but the dpkg team didn't like it. Or at a minimum dpkg should catch when a patch was manually renamed while quilt is used and repair that. I.e. make just renaming work even with quilt being used. I consider this a bug. It's new, it's just that we haven't developed the toolset around it. I always expected that people would start developing new tools à la devscripts to make it easier for some specific scenario. Expecting others to jump the wagon isn't something you should depend on, you are well adviced to be ready to do the work yourself in case your expectations are over the top. :) Well, everything has a learning curve. It's normal to have to learn once. The point of README.source was to document stuff that not all DD are supposed to know. Knowledge of the new source format will be common in the near future. Given that there seems to be different workflows needed and required depending on what packages one has installed I still see the need for that, to be honest ... Yes, but not in every pakage. At most a link to a file provided by dpkg. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Joey Hess jo...@debian.org writes: Raphael Hertzog wrote: That's just wrong. I do it without problems by using the .quiltrc snippet from /usr/share/doc/quilt/README.source. Hmm, that is verging on beware of the leopard non-obviousness. I mean, you just argued in another mail that such a README.source would soon not be necessary. Perhaps a little wrapper script to run quilt with the right QUILT_PATCHES could make this slightly easier. -- see shy jo #557623 Quilt should remember where it first got patches and series from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557623 No more need to set QUILT_PATCHES. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Bastian Blank wa...@debian.org writes: On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote: since a few weeks the Debian archive accepts source package using the new formats 3.0 (quilt) and 3.0 (native). I tried 3.0 (quilt) with several packages today and none worked properly, so several large packages will be stuck with 3.0 (native). Bugs as of today. * Packages with different patch systems like linux-2.6. In this case dpkg-source ignores failures to register a patch and produces sources without the changes. (#557618) As discussed on IRC this is a matter of false advertising by the announcement and the wiki. Which also seems to be the main problem Rhonda has with the format. YOU CAN NOT MIX PATCH SYSTEMS. If the package uses a patch system, which might or might not be quilt, and you declare it 3.0 (quilt) format then dpkg also uses a patch system, which might or might not be quilt. You then pitch two patch systems against each other and most likely both will be using debian/patches/ with, unsurprisingly, catastrophic results. If you convert to 3.0 (quilt) then remove the patch system from debian/rules. In extrem cases, like linux-2.6, where that isn't possible you need to make sure it does not interfere with dpkg. The simplest way would be to not use debian/patches. Use debian/kernel-patches/ or something other. * The 3.0 (quilt) format is incompatible with quilt by using different patch directories and features. (#557619) Quilt supports alternative patches directories and series files. It just isn't verry good at it as it requires QUILT_PATCHES / QUILT_SERIES to be set correctly every time you work on the source. The patch in #557623 makes quilt remember where it got its patches and series file from the first time you use it (e.g. when called from dpkg-source -x) so it just works out of the box after then. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557623 * Fuzzy patches leads to silent ignore of the complete patchset. (#557664) * Different behaviour between quilt installed/not installed. Several others against quilt themself are missing. The whole thing is super fragile. It is mostly impossible to use both 3.0 (quilt) and quilt themself because you use it to develop. Yes, a matter of false advertising. Use a different dir for the packages quilt use. The last step for us (dpkg maintainers) in this project is to change dpkg-source to use those new formats by default. I will propose a GR to stop you if you go on until it works properly. And yes, this includes packages like linux-2.6, which have to use a more sophisticated patch system than quilt. Or you start and propose a different format that can be mostly like 3.0 (quilt) for the result (multiple tars) but without the implicit quilt constraints. However, before we do this we want to ensure that no packages (in sid) will be broken due to this switch and there are quite a few packages left to fix: You have to add the bugs above. Bastian It seems more and more people are against switching and really what is the point? Everyone who wants the new format is creating debian/source/format already. So all you do by switching the default is piss of those people that are against 3.0 (quilt) format and please no one. Further packages with patch systems need to be changed to work reliably with 3.0 (quilt) format, i.e. need to remove the patch system from debian/rules. Without adding debian/source/format at that time the packages then don't build as 1.0 format anymore so backporting breaks. Another large group of people and users pissed at you. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Tue, 24 Nov 2009, Robert Collins wrote: On Mon, 2009-11-23 at 09:30 +0100, Raphael Hertzog wrote: In the end, I decided to trust nothing and to verify if the first patch can be applied or not. If it can be applied, we assume that the patches have not been applied and we apply them all (unless --no-preparation is given). If quilt is available, instead of checking the first patch, I check the first patch returned by quilt unapplied and apply the remaining of the patches if needed. This heuristic is likely to fail - patches that solely add content can apply repeatedly without error. I know, that's why it's called an heuristic (it doesn't get it right 100% of the cases) and why --no-preparation exists and why it's best to not allow for any fuzz in that test. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Mon, 23 Nov 2009, Joey Hess wrote: I understand that you do not want to throw away your work on this patch management system, but by making it optional, I think that you will actually increase your chances of success… I think that's very wise. It is optional already. Just don't make any direct changes to upstream files. What else do you need? I can add a new option --no-debian-patch that would refuse to create the automatic quilt patch debian-changes-ver and make it fail instead if there are upstream changes. That option can then be put in debian/source/options just like you can put compression = bzip2 currently. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Tue, 24 Nov 2009, Goswin von Brederlow wrote: Bugs as of today. * Packages with different patch systems like linux-2.6. In this case dpkg-source ignores failures to register a patch and produces sources without the changes. (#557618) As discussed on IRC this is a matter of false advertising by the announcement and the wiki. Which also seems to be the main problem Rhonda has with the format. It's not false advertising. The problem that Bastian saw is that quilt is not returning an error when debian/patches/series is not a file. I'm going to check for that in the next dpkg version. YOU CAN NOT MIX PATCH SYSTEMS. You certainly can. It doesn't mean that it's always a good idea though. For packages like linux-2.6, it makes sense. I made some choices to avoid conflicts with other patch systems, in particular no .patch or .diff extension to automatic patches so that they are not picked up by patch systems like simple-patchsys. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi. Le samedi 21 novembre 2009 à 16:54 +0100, Raphael Hertzog a écrit : Hello, We have collected some question/answers from early adopters in the dedicated wiki page, the most important information is pasted below. We hope you will find it helpful to convert your own packages. http://wiki.debian.org/Projects/DebSrc3.0#FAQ Maybe that's very explicit for eveyone, but I couldn't find any explenation for regular humans of what quilt is (ok, I think I have a clue, but remember not all newcomers may be familiar with it for instance), and then what the difference are between native and quilt formats in the page abobe. As this was a general announcements, maybe recapping these background facts would have helped. Sorry if I'm the only one who thinks that this wasn't really obvious for all concerned parties. Best regards, -- Olivier BERGER olivier.ber...@it-sudparis.eu http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi, On Sun, 22 Nov 2009, Olivier Berger wrote: Maybe that's very explicit for eveyone, but I couldn't find any explenation for regular humans of what quilt is (ok, I think I have a clue, but remember not all newcomers may be familiar with it for instance), and then what the difference are between native and quilt formats in the page abobe. The difference is explained in the dpkg-source manual page, if you feel like a short introduction would be good on the above page, please write one, I'll improve it if needed (I'm subscribed to changes on the wiki page). Thanks for your help! ;-) Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi, On Sat, 21 Nov 2009, Mike Hommey wrote: On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote: Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. If there is no patch system when you are NMUing, why would you want to add one ? Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. We're not forcing anyone, we make it easier for people to use that patch system and we explain why we think it's a wise choice to consider quilt as the default patch system to use when you don't have any specific reason to pick one over the other. Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 (native), which kind of suggests 3.0 (quilt) is being forced down. That's maybe not what you are thinking, but it's how it feels. Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native packages and 3.0 (quilt) is for all the other who have an upstream tarball + a debian dir. The release goal is only about 3.0 (quilt) because switching from a native source package in format 1.0 to 3.0 (native) will always work and thus requires no preparation work. OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. On Sat, 21 Nov 2009, Gerfried Fuchs wrote: Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. Heavy modification? What's so heavy on three entries there? Don't be blocked on the heavy, it will of course depends on how the package was built (CDBS, debhelper, dh7, hand-crafted). The point is that you have to choose a patch system in place of the maintainer. You add a quilt build-depends and associated changes when he uses CDBS and would have preferred simple-patchsys. Sorry, but these additions are next to nowhere heavy modifications, that's a bit over overrating, to say the least. Agreed, sorry. The modifications are implied, but it means that the source format is already this heavy modification, on a similarly heavy modification scale. Additionally, if someone wants to sepearte the patches into feature-patches instead of one-modification-patch-per-upload they will have to additionally pull in quilt anyway to work on it properly, Well, they can drop the patch in debian/patches, and add it to the end of debian/patches/series. If quilt is installed, it should work as dpkg-source will use quilt applied to know whether patches needs to be applied. If quilt is not installed, it assumes all patches are applied, so you should also apply the patch. Alright, thanks for explaining the issue - so for the time, what do you suggest? Remove the quilt handling? Yes, there's no reason to keep it. Actually ignore the error that quilt gives (like you suggested on IRC)? No, I did not suggest that. I was confused on why you saw the failure and first thought that it was misusage of quilt. Or wait until the sbuild fix is applied everywhere? No, by experience that would mean to wait for quite long, despite the efforts of the wanna-build maintainers to get buildd maintainers to update their buildd. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote: Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. Fixing cosmetic issues or changing the packaging style in NMUs is discouraged. Adding a patching system is surely changing the packaging style. OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. I don't agree with that statement. dpkg-source implements a subset of quilt to work without that tool installed, that subset defines the interface of the source package and it does not include the .pc directory in the general case. If you want that part which is internal to quilt itself, you just have to install quilt. My point is : dpkg-source -x should be idempotent, whatever other packages are installed when you do it. The fact that you can't dpkg-source -x, and *then* install quilt to manage the patches is a nuisance. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sun, 22 Nov 2009, Mike Hommey wrote: On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote: Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. Fixing cosmetic issues or changing the packaging style in NMUs is discouraged. Adding a patching system is surely changing the packaging style. Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you can't do the right thing in a NMU, either you break the above rule or you have to meld patches in the .diff.gz with no other information than what you put in the changelog. My point is : dpkg-source -x should be idempotent, whatever other packages are installed when you do it. The fact that you can't dpkg-source -x, and *then* install quilt to manage the patches is a nuisance. It's a minor one, yes. But it should happen only once... the next time will be still be installed. And since quilt is not needed during a simple build, I don't see the need to add it the dependencies of dpkg-dev. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Le Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog a écrit : Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. That sounds like an artificial situation to me. Either the maintainer is active and a patch system can be agreed with him, or the maintainer is MIA and the package should be hijacked, orphaned, or removed. It is more work than just doing a NMU, but it fixes the real problem, which is not the bug itself but the absence of a maintainer to deal with it. Also, as a side comment, I would like to add that the “NMU workflow” often advertised on this list completely ignores that a large number of packages are stored in a VCS where all DDs have write acceess. Uploading a package with an anonymous and monolithic patch puts an additional load on the maintainer's work, which contradicts the goal of a NMU, to help a busy maintainer. The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like the use of multiple tarballs, different compression systems, and having the debian directory in a single tarball, which removes the need of uuencoding binary documents. I would welcome a variant that leaves the patch system in the hands of the maintainer. It would simplify our work by removing the need to fight against the modifications introduced by runing the autotools, which would be simply ignored instead of being turned into an useless patch. And it would also open a way to unify with the VCS-based formats. Cheers, -- 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
Re: New source package formats now available
On Sun, 22 Nov 2009, Charles Plessy wrote: Also, as a side comment, I would like to add that the “NMU workflow” often advertised on this list completely ignores that a large number of packages are stored in a VCS where all DDs have write acceess. Uploading a package with an anonymous and monolithic patch puts an additional load on the maintainer's work, which contradicts the goal of a NMU, to help a busy maintainer. Well, IMO, the VCS helper tool should have a tool to import an NMU. git-buildpackage has git-import-dsc for example. The formats ‘2.0’ and ‘3.0 (variant)’ bring a lot of nice improvements, like the use of multiple tarballs, different compression systems, and having the debian directory in a single tarball, which removes the need of uuencoding binary documents. I would welcome a variant that leaves the patch system in the hands of the maintainer. It would simplify our work by removing the need to fight against the modifications introduced by runing the autotools, which would be simply ignored instead of being turned into an useless patch. And it would also open a way to unify with the VCS-based formats. You're fighting the wrong target here, your clean rules should bring the package in a clean state again. However, we have debian/source/options now to pass default options to dpkg-source, we can certainly add more options to change the default set of ignored files (-i command line option currently) so that you don't end up with a supplementary patch in that case. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sun, 22 Nov 2009, Raphael Hertzog wrote: On Sun, 22 Nov 2009, Mike Hommey wrote: My point is : dpkg-source -x should be idempotent, whatever other packages are installed when you do it. The fact that you can't dpkg-source -x, and *then* install quilt to manage the patches is a nuisance. It's a minor one, yes. But it should happen only once... the next time will be still be installed. And since quilt is not needed during a simple build, I don't see the need to add it the dependencies of dpkg-dev. The principle of least surprise is a damn good reason to add that dependency. We don't need any extra aggravation right now, especially not related to the 3.0 format. Please add the dependency. -- 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
Re: New source package formats now available
On Sun, Nov 22, 2009 at 11:30:45AM +0100, Raphael Hertzog wrote: On Sun, 22 Nov 2009, Mike Hommey wrote: On Sun, Nov 22, 2009 at 10:48:14AM +0100, Raphael Hertzog wrote: Because you want the patch to be clearly identified and to carry its meta-information. Or because maybe you're applying 2 separate patches in the same NMU upload. Fixing cosmetic issues or changing the packaging style in NMUs is discouraged. Adding a patching system is surely changing the packaging style. Exactly, that is why 1.0 is less NMU-friendly than 3.0 (quilt)... you can't do the right thing in a NMU, either you break the above rule or you have to meld patches in the .diff.gz with no other information than what you put in the changelog. No, you don't have to meld patches in the .diff.gz, you just do your changes, put an entry in debian/changelog and do dpkg-source -b. Nothing more. It's actually much more NMU-friendly than having to deal with a patch system. OTOH, 3.0 (quilt) is a patch system without being one, so it is a bit less pain. But it is not more NMU-friendly than plain 1.0. It is more NMU-friendly than 1.0 + patch system, though. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote: You need to put 3.0 (quilt) or 3.0 (native) in debian/source/format to indicate the desired format to dpkg-source (see the dpkg-source(1) manual page for more information). Am I doing something wrong? sys11:/home/brian/tree/heimdal# lintian heimdal_1.2.e1.dfsg.1-5_i386.changes warning: lintian's authors do not recommend running it with root privileges! internal error: command failed with error code 25 warning: could not unpack package to desired level warning: skipping check of source package heimdal What does error 25 mean? -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi! Some few comments. * Raphael Hertzog hert...@debian.org [2009-11-21 16:54:36 CET]: * even if you don't have any upstream patch right now, next time that someone must NMU your package, they can cleanly add a patch (with a proper DEP-3 header) without having to modify the build system This is nothing new for the 3.0 (quilt) format, this is a reason for any patch system format, so this feels a bit like false-advertising, sorry. Don't get me wrong, I use quilt where I have to touch upstream sources myself and totally like it, I just don't see the need to use this as advertising for the 3.0 format because that doesn't buy you much more in that respect. * in the long run it's best to standardize on a single patch system (new contributors need to learn a single system, more people can help you, etc.) and quilt appears to be that patch system. That part feels also a bit strange - I don't think it should be the decision of the dpkg team to force people to use a specific patch system. Again, I use quilt myself. Though, Debian (and free software in general) always was about choice. And yes, I know, there's 3.0 (native), but that wasn't mentioned. When you switch to 3.0 (quilt), there are other changes that you might want to do: * You can remove everything related to quilt in debian/rules (patch/unpatch logic, cleanup of quilt stamp file and its .pc directory). Unfortunately, I can't follow that can remove. It sounds like it would work if you keep it in. Unfortunately that's not the case. Please take a look at the build logs for wesnoth 1:1.7.8-1. The story is easy: -) The buildd does a debian/rules clean. -) quilt doesn't find any applied patches (because dpkg doesn't create the .pc/ directory structure) -) The buildd then starts with the building. -) quilt likes to apply the patches and failes because they already *are* applied but quilt doesn't know about it. So pretty please, change that can remove into a MUST remove, otherwise you will stumble into problems. === Does a 3.0 (quilt) source package need to build-depend on quilt? === If you drop the quilt usage in debian/rules (patch/unpatch logic), then no. You *HAVE* to drop the quilt usage in debian/rules, otherwise it will fail. So long, and thanks for the work involved, but this minor issues should still be addressed, in one way or the other. :) *waves* Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
Hi, On Sat, 21 Nov 2009, Gerfried Fuchs wrote: * Raphael Hertzog hert...@debian.org [2009-11-21 16:54:36 CET]: * even if you don't have any upstream patch right now, next time that someone must NMU your package, they can cleanly add a patch (with a proper DEP-3 header) without having to modify the build system This is nothing new for the 3.0 (quilt) format, this is a reason for any patch system format, so this feels a bit like false-advertising, sorry. Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. With 3.0 (quilt), you don't need to do any such modification... the patch system is already available even if not used. That's what this point means. * in the long run it's best to standardize on a single patch system (new contributors need to learn a single system, more people can help you, etc.) and quilt appears to be that patch system. That part feels also a bit strange - I don't think it should be the decision of the dpkg team to force people to use a specific patch system. We're not forcing anyone, we make it easier for people to use that patch system and we explain why we think it's a wise choice to consider quilt as the default patch system to use when you don't have any specific reason to pick one over the other. * You can remove everything related to quilt in debian/rules (patch/unpatch logic, cleanup of quilt stamp file and its .pc directory). Unfortunately, I can't follow that can remove. It sounds like it would work if you keep it in. In general it should work, but you're right that we have a problem here with the buildds running an old version of sbuild (there are still many buildd in that situation) because they do dpkg-source -x outside of the buildd chroot where quilt is not installed even if you added quilt in your build-depends. AFAIK newer sbuild should do dpkg-source -x in the chroot where quilt is installed due to build-depends and the .pc directory is then created at unpack time. -) quilt doesn't find any applied patches (because dpkg doesn't create the .pc/ directory structure) dpkg-source -x uses quilt if it's installed, so if it's here the .pc structure is created. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sat, Nov 21, 2009 at 08:51:51PM +0100, Raphael Hertzog wrote: Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. If there is no patch system when you are NMUing, why would you want to add one ? We're not forcing anyone, we make it easier for people to use that patch system and we explain why we think it's a wise choice to consider quilt as the default patch system to use when you don't have any specific reason to pick one over the other. Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0 (native), which kind of suggests 3.0 (quilt) is being forced down. That's maybe not what you are thinking, but it's how it feels. In general it should work, but you're right that we have a problem here with the buildds running an old version of sbuild (there are still many buildd in that situation) because they do dpkg-source -x outside of the buildd chroot where quilt is not installed even if you added quilt in your build-depends. AFAIK newer sbuild should do dpkg-source -x in the chroot where quilt is installed due to build-depends and the .pc directory is then created at unpack time. OTOH, dpkg-source -x should result in the same tree (including the .pc directory), whatever the status of quilt installation is on the system. Or if that is not possible without quilt, then dpkg-dev should depend on quilt. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
* Raphael Hertzog hert...@debian.org [2009-11-21 20:51:51 CET]: Hi, On Sat, 21 Nov 2009, Gerfried Fuchs wrote: * Raphael Hertzog hert...@debian.org [2009-11-21 16:54:36 CET]: * even if you don't have any upstream patch right now, next time that someone must NMU your package, they can cleanly add a patch (with a proper DEP-3 header) without having to modify the build system This is nothing new for the 3.0 (quilt) format, this is a reason for any patch system format, so this feels a bit like false-advertising, sorry. Currently a package without a patch system needs heavy modifications in debian/rules to setup the patch system. So when you want to add a patch in debian/patches and not in the .diff.gz, you have to choose a patch system in place of the maintainer. Heavy modification? What's so heavy on three entries there? include /usr/share/quilt/quilt.make clean: [...] unpatch build-stamp: patch Sorry, but these additions are next to nowhere heavy modifications, that's a bit over overrating, to say the least. With 3.0 (quilt), you don't need to do any such modification... the patch system is already available even if not used. That's what this point means. The modifications are implied, but it means that the source format is already this heavy modification, on a similarly heavy modification scale. Additionally, if someone wants to sepearte the patches into feature-patches instead of one-modification-patch-per-upload they will have to additionally pull in quilt anyway to work on it properly, without having it implied through the build-depends and being guided in the right direction through README.Source. In general it should work, but you're right that we have a problem here with the buildds running an old version of sbuild (there are still many buildd in that situation) because they do dpkg-source -x outside of the buildd chroot where quilt is not installed even if you added quilt in your build-depends. AFAIK newer sbuild should do dpkg-source -x in the chroot where quilt is installed due to build-depends and the .pc directory is then created at unpack time. -) quilt doesn't find any applied patches (because dpkg doesn't create the .pc/ directory structure) dpkg-source -x uses quilt if it's installed, so if it's here the .pc structure is created. Alright, thanks for explaining the issue - so for the time, what do you suggest? Remove the quilt handling? Actually ignore the error that quilt gives (like you suggested on IRC)? Or wait until the sbuild fix is applied everywhere? Thanks, Rhonda -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sa, 21 Nov 2009, Gerfried Fuchs wrote: Heavy modification? What's so heavy on three entries there? include /usr/share/quilt/quilt.make clean: [...] unpatch build-stamp: patch Besides that that snippet is broken? It made me nuts that quilt people are changing that snippet and breaking many packages, like all of mine. It should be: build-stamp: $(QUILT_STAMPFN) ... and as far as I see: clean: unpatch DOn't get me wrong, I am already using quilt, but the interface with quilt.make should not change (again, hopefully). Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- ABERBEEG (vb.) Of amateur actors, to adopt a Mexican accent when called upon to play any variety of foreigner (except Pakistanis - from whom a Welsh accent is considered sufficient). --- 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
Re: New source package formats now available
Gerfried Fuchs rho...@deb.at writes: Hi! Some few comments. * Raphael Hertzog hert...@debian.org [2009-11-21 16:54:36 CET]: * even if you don't have any upstream patch right now, next time that someone must NMU your package, they can cleanly add a patch (with a proper DEP-3 header) without having to modify the build system This is nothing new for the 3.0 (quilt) format, this is a reason for any patch system format, so this feels a bit like false-advertising, sorry. Don't get me wrong, I use quilt where I have to touch upstream sources myself and totally like it, I just don't see the need to use this as advertising for the 3.0 format because that doesn't buy you much more in that respect. The BIG difference is that you (as NMUer) can just apt-get source foo cd foo*/ dch -i $EDITOR file debuild and a new patch will be created automatically. You work on the source as if there is no patch system involved and it will do the right thing. If you do happen to know about quilt and the package already has patches you can take advantage of quilt features. You can edit patches or annotate files to find the guilty patch and so on. But if you don't know or don't like quilt you can also totaly ignore it. So what you get is a free (as in nothing needs to be in debian/rules or Build-Depends) patch system that is also free to anyone using the source. There is no required learning curve. * in the long run it's best to standardize on a single patch system (new contributors need to learn a single system, more people can help you, etc.) and quilt appears to be that patch system. That part feels also a bit strange - I don't think it should be the decision of the dpkg team to force people to use a specific patch system. Again, I use quilt myself. Though, Debian (and free software in general) always was about choice. And yes, I know, there's 3.0 (native), but that wasn't mentioned. And the choice is still there. As you say yourself there is 3.0 (native) even if it wasn't advertized. Also things like topgit can be used and the resulting source package can still use 3.0 (quilt) format. That will allow for the maintainer to use his/her favourite environment while everybody else still has to option to use the resulting source package with or even without quilt. Again, no learning curve to modify the source. Maybe think of 3.0 (quilt) more as an interchange format of debian patches. When you switch to 3.0 (quilt), there are other changes that you might want to do: addressed in other mails MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sun, Nov 22, 2009 at 01:16:47AM +0100, Norbert Preining wrote: Besides that that snippet is broken? It made me nuts that quilt people are changing that snippet and breaking many packages, like all of mine. It should be: build-stamp: $(QUILT_STAMPFN) ... and as far as I see: clean: unpatch Well, the latter is wrong - this breaks if you're patching the build system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
newspost - neues Paket bauen - Fragen -- newspost - build new source package - questions
Bitte um Hilfe bei einigen Fragen betr. des Bauens von Quellpaketen:
Habe einige Erweiterungen / Änderungen gemacht zum Programm (Source
Paket) newspost.
Folgendes ist mir inzwischen gelungen:
Vorhanden Datei: newspost_2.1.1.orig.tar.gz
Datei: newspost_2.1.2.beta.tar.gz ( erzeugt mit dpkg-source -b
newspost-2.1.2.beta) - dieses Verzeichnis enthält alle Dateien, darunter
die von mir geänderten und die zwei neuen.
cd newspost-2.1.2.beta
dpkg-distaddfile newspost_2.1.1.orig.tar.gz news optional und:
dpkg-distaddfile newspost_2.1.2.beta.tar.gz news optional
hat ebenfalls funktioniert (Erzeugen der Datei debian/files).
Jetzt - bin immer noch im Verzeichnis newspost-2.1.2.beta -
dpkg-genchanges -sa ergibt einige Warnungen:
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
dpkg-genchanges: Warnung: Paket newspost in Steuerdatei aber nicht in
Dateiliste
dpkg-genchanges: Warnung: unbekanntes Informationsfeld »Error« in den
Eingabedateien in ausgewertete Version des changelogs
dpkg-genchanges: füge kompletten Quellcode beim Hochladen hinzu
Format: 1.8
Date: Tue, 29 Apr 2008 19:29:55 +0200
Source: newspost
Binary: newspost
Architecture: source
Version: 2.1.2.beta
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Description:
newspost - Usenet binary autoposter
Changes:
newspost (2.1.2.beta) unstable; urgency=low
.
* Functions for external calls added.
Checksums-Sha1:
7d7a2e71a04dd3fc5999e1c0a931d0e4dffaad7b 483 newspost_2.1.2.beta.dsc
147d6b0d932acb7564b7f77eac4642e672fa01ce 67286 newspost_2.1.2.beta.tar.gz
244f31c6e5aa8e41224310295e477ab4a8a17071 61412 newspost_2.1.1.orig.tar.gz
Checksums-Sha256:
867137bea86c78680ca95070fc78fc35662af893f4c2cb5f9973b978e24efab1 483
newspost_2.1.2.beta.dsc
13f952b7cd0de96de65a74fb197d74585ba451ad43016f41f4a393cf210b5a86 67286
newspost_2.1.2.beta.tar.gz
bdd1ae83d7459d2cdd726115c028405fce33f9b60e71b88969f82fbc02672be7 61412
newspost_2.1.1.orig.tar.gz
Files:
0c4718a9952e30cf7d33ec9980ffaf51 483 news optional newspost_2.1.2.beta.dsc
e4e28deecf535fe28435a206fb8ab74f 67286 news optional
newspost_2.1.2.beta.tar.gz
099a69ce511f746aec88a57d03575d5f 61412 news optional
newspost_2.1.1.orig.tar.gz
Jetzt - dpkg-buildpackage -k66256351 -sa
ergibt folgendes:
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
dpkg-buildpackage: Quellpaket newspost
dpkg-buildpackage: Quellversion 2.1.2.beta
dpkg-buildpackage: Fehler: kann Quellen geändert durch nicht bestimmen
Die beiden Warnungen sind wohl nicht tödlich, aber die Zeile zum Schluss:
was bedeutet sie genau, und wie kann man den Fehler beheben?
Beim Versuch, das Paket mit dput zu mentors.debian hochzuladen, kommt:
[EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master newspost.changes
Traceback (most recent call last):
File /usr/bin/dput, line 919, in ?
main()
File /usr/bin/dput, line 767, in main
unsigned_upload, debug)
File /usr/bin/dput, line 281, in verify_files
changes = parse_changes(chg_fd)
File /usr/bin/dput, line 80, in parse_changes
for a in changes.dict['files'].split('\n'):
KeyError: 'files'
Weglassen der
build new source package - questions
Please help, I have some questions regarding building Source Packages.
Made some changes to source package newspost.
Successful with following:
There exists file: newspost_2.1.1.orig.tar.gz
File: newspost_2.1.2.beta.tar.gz ( erzeugt mit dpkg-source -b
newspost-2.1.2.beta)
- all files, also those i have changed and the new ones.
cd newspost-2.1.2.beta
dpkg-distaddfile newspost_2.1.1.orig.tar.gz news optional and:
dpkg-distaddfile newspost_2.1.2.beta.tar.gz news optional
successful too (create file debian/files).
Jetzt - still in newspost-2.1.2.beta - dpkg-genchanges -sa - some warnings:
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
dpkg-genchanges: Warnung: Paket newspost in Steuerdatei aber nicht in
Dateiliste
dpkg-genchanges: Warnung: unbekanntes Informationsfeld »Error« in den
Eingabedateien in ausgewertete Version des changelogs
dpkg-genchanges: füge kompletten Quellcode beim Hochladen hinzu
Format: 1.8
Date: Tue, 29 Apr 2008 19:29:55 +0200
Source: newspost
Binary: newspost
Architecture: source
Version: 2.1.2.beta
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group [EMAIL PROTECTED]
Description:
newspost - Usenet binary autoposter
Changes:
newspost (2.1.2.beta) unstable; urgency=low
.
* Functions for external calls added.
Checksums-Sha1:
7d7a2e71a04dd3fc5999e1c0a931d0e4dffaad7b 483 newspost_2.1.2.beta.dsc
147d6b0d932acb7564b7f77eac4642e672fa01ce 67286 newspost_2.1.2.beta.tar.gz
244f31c6e5aa8e41224310295e477ab4a8a17071 61412 newspost_2.1.1.orig.tar.gz
Checksums-Sha256:
867137bea86c78680ca95070fc78fc35662af893f4c2cb5f9973b978e24efab1 483
newspost_2.1.2.beta.dsc
13f952b7cd0de96de65a74fb197d74585ba451ad43016f41f4a393cf210b5a86 67286
newspost_2.1.2.beta.tar.gz
bdd1ae83d7459d2cdd726115c028405fce33f9b60e71b88969f82fbc02672be7 61412
newspost_2.1.1.orig.tar.gz
Files:
0c4718a9952e30cf7d33ec9980ffaf51 483 news optional newspost_2.1.2.beta.dsc
e4e28deecf535fe28435a206fb8ab74f 67286 news optional
newspost_2.1.2.beta.tar.gz
099a69ce511f746aec88a57d03575d5f 61412 news optional
newspost_2.1.1.orig.tar.gz
Now - dpkg-buildpackage -k66256351 -sa
gives following:
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2
parsechangelog/debian: Warnung: debian/changelog(l5): ungültig
formatierte Zeile im Nachspann
LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200
parsechangelog/debian: Warnung: debian/changelog(l7): found start of
entry where expected more change data or trailer
LINE: newspost (2.1.1-4) unstable; urgency=low +0200
parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo
more change data or trailer erwartet wurde
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
Use of uninitialized value in pattern match (m//) at
/usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7.
dpkg-buildpackage: Quellpaket newspost
dpkg-buildpackage: Quellversion 2.1.2.beta
dpkg-buildpackage: Fehler: kann Quellen geändert durch nicht bestimmen
(- cannot determine sources changed by)
Warnings seem not lethal but the last line:
what does it exactly mean and how can I successfully do it?
When trying to upload to mentors.debian.net with dput comes following:
[EMAIL PROTECTED]:~/newspost-2.1.2.beta$ dput -P ftp-master newspost.changes
Traceback (most recent call last):
File /usr/bin/dput, line 919, in ?
main()
File /usr/bin/dput, line 767, in main
unsigned_upload, debug)
File /usr/bin/dput, line 281, in verify_files
changes = parse_changes(chg_fd)
File /usr/bin/dput, line 80, in parse_changes
for a in changes.dict['files'].split('\n'):
KeyError: 'files'
No change when omitting Option -P (passive ftp).
Next question: If other persons are working on a new version of Debian
package newspost, how can I
Re: build new source package - questions
Just a few lines about appropiate mailing lists and their languages. Hallo David, schön, dass du mit Debian eine Distribution gefunden hast, für die es sich für dich zu lohnen scheint, etwas mehr zu tun; trotzdem gibt es ein paar Regeln, an die auch du gebeten bist, dich zu halten: 1. Man sendet eine Mail an eine(!) MailingListe; nämlich an die richtige. 2. Man passt sich der Sprache der MailingListe an. 3. Man sendet nicht das gleiche Problem/die gleiche Anfrage mehrmals. debian-devel ist die Liste, auf der auf englisch(!) die Entwickler (und natürlich jeder Interessierte) die gesamte Entwicklung der Distribution und ihrer Probleme diskutieren. Einzelne Paketbauprobleme haben hier, sofern sie nicht aufgrund eines Defekts in wichtigen Paketen wie apt oder dpkg entstehen, keinen Platz. debian-mentors ist eine Liste (ebenfalls auf englisch), auf der zukünftige oder anfangende Maintainer Probleme und Anfragen loswerden können, die sie haben, wenn sie Pakete für die Distribution herrichten. debian-user-german ist eine deutsche Liste für alle User, die alle ihre Fragen und Probleme hier loswerden können (auch Paketbau gehört dazu, weil nicht jder Pakete gleich für die Community baut). Ich (und ich vermute alle anderen auch) bitte dich also dringend, in Zukunft genau zu wählen, was wo angemessen ist. Das macht die Arbeit erheblich leichter. Cheers, Hauke PS: Deine Fragen würde ich erstmal versuchen auf user-german zu klären. On Tue, Apr 29, 2008 at 08:08:04PM +0200, David wrote: Please help, I have some questions regarding building Source Packages. Made some changes to source package newspost. Successful with following: There exists file: newspost_2.1.1.orig.tar.gz File: newspost_2.1.2.beta.tar.gz ( erzeugt mit dpkg-source -b newspost-2.1.2.beta) - all files, also those i have changed and the new ones. cd newspost-2.1.2.beta dpkg-distaddfile newspost_2.1.1.orig.tar.gz news optional and: dpkg-distaddfile newspost_2.1.2.beta.tar.gz news optional successful too (create file debian/files). Jetzt - still in newspost-2.1.2.beta - dpkg-genchanges -sa - some warnings: parsechangelog/debian: Warnung: debian/changelog(l5): ungültig formatierte Zeile im Nachspann LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200 parsechangelog/debian: Warnung: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: newspost (2.1.1-4) unstable; urgency=low +0200 parsechangelog/debian: Warnung: debian/changelog(l7): fand EOF wo more change data or trailer erwartet wurde Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Dpkg/Fields.pm line 202, STDIN line 7. parsechangelog/debian: Warnung: debian/changelog(l5): ungültig formatierte Zeile im Nachspann LINE: -- David Moerike [EMAIL PROTECTED] Sat, 26 Apr 08:01:02 +0200 parsechangelog/debian: Warnung: debian/changelog(l7): found start of entry where expected more change data or trailer LINE: newspost (2.1.1-4) unstable; urgency=low +0200 dpkg-genchanges: Warnung: Paket newspost in Steuerdatei aber nicht in Dateiliste dpkg-genchanges: Warnung: unbekanntes Informationsfeld »Error« in den Eingabedateien in ausgewertete Version des changelogs dpkg-genchanges: füge kompletten Quellcode beim Hochladen hinzu Format: 1.8 Date: Tue, 29 Apr 2008 19:29:55 +0200 Source: newspost Binary: newspost Architecture: source Version: 2.1.2.beta Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Description: newspost - Usenet binary autoposter Changes: newspost (2.1.2.beta) unstable; urgency=low . * Functions for external calls added. Checksums-Sha1: 7d7a2e71a04dd3fc5999e1c0a931d0e4dffaad7b 483 newspost_2.1.2.beta.dsc 147d6b0d932acb7564b7f77eac4642e672fa01ce 67286 newspost_2.1.2.beta.tar.gz 244f31c6e5aa8e41224310295e477ab4a8a17071 61412 newspost_2.1.1.orig.tar.gz Checksums-Sha256: 867137bea86c78680ca95070fc78fc35662af893f4c2cb5f9973b978e24efab1 483 newspost_2.1.2.beta.dsc 13f952b7cd0de96de65a74fb197d74585ba451ad43016f41f4a393cf210b5a86 67286 newspost_2.1.2.beta.tar.gz bdd1ae83d7459d2cdd726115c028405fce33f9b60e71b88969f82fbc02672be7 61412 newspost_2.1.1.orig.tar.gz Files: 0c4718a9952e30cf7d33ec9980ffaf51 483 news optional newspost_2.1.2.beta.dsc e4e28deecf535fe28435a206fb8ab74f 67286 news optional newspost_2.1.2.beta.tar.gz 099a69ce511f746aec88a57d03575d5f 61412 news optional newspost_2.1.1.orig.tar.gz Now - dpkg-buildpackage -k66256351 -sa gives following: dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2 dpkg-buildpackage: setze CPPFLAGS auf Standardwert: dpkg-buildpackage: setze LDFLAGS auf Standardwert: dpkg-buildpackage: setze FFLAGS auf Standardwert: -g -O2 dpkg-buildpackage: setze CXXFLAGS auf Standardwert: -g -O2 parsechangelog/debian:
new source package format in dpkg-dev
Hello, yesterday I merged all the work we did in the sourcev3 branch in the master branch of dpkg. It means it will be in the next dpkg upload. My last call for test[1] didn't lead to any feedback at all, which is a pity given the length of the discussion we had about patch management. I'm pretty sure people are interested in the topic... and it's important to make sure that the new code in dpkg-source respond to most of the feature requests that people had. So please try it out, I built a package here: http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.17_all.deb The dpkg-source manual page contains all the relevant information about the new formats. In particular I want feedback on the 3.0 (quilt) format which I'd like to promote as the standard format for non-native packages in lenny+1. It would be particularly interesting to try it out on quilt using packages and see if packages can be switched transparently or if we need some transition plan. In theory at least, it shoud be transparent provided that quilt was available at unpack time (so that the quilt metadata are available and the patch rule becomes a no-op instead of trying to reapply patches that have been already applied). Of course, if you notice any regression in the default behaviour for the current source package format, please tell me as well. This code is going to be uploaded to unstable RSN, when Guillem has finished merging the triggers functionnality. (Maybe we'll put it in experimental for a few days first, but that's not decided yet) Thanks in advance for your feedback. Cheers, [1] http://www.ouaza.com/wp/2008/03/16/new-source-package-formats-call-for-tests/ http://lists.debian.org/debian-dpkg/2008/03/msg00155.html http://lists.debian.org/debian-dpkg/2008/03/msg00166.html -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new source package format in dpkg-dev
On Fri, 28 Mar 2008, Raphael Hertzog wrote: My last call for test[1] didn't lead to any feedback at all, which is a pity given the length of the discussion we had about patch management. I'm pretty sure people are interested in the topic... and it's important to make sure that the new code in dpkg-source respond to most of the feature requests that people had. Ok, some people told me that they have no idea what this is all about and they won't install the package to discover it... so here are some other elements. First the updated dpkg-source manual page: http://people.debian.org/~hertzog/dpkg-source.html Then among the new features we have: - source package with multiple .orig tarball (gz/bz2/lzma) associated to a debian tarball - automatic application of patches listed in debian/patches/(debian\.)?series - automatic generation of a new patch at the end of the series if local modifications have been done (this means the NMU workflow works: unpack, modifiy, build gives a sane result and even keep the changes of each upload separate) - support of binary files anywhere in the source tree (you can drop in a new debian-specific icon for instance, add its path to debian/source/include-binaries, and it will be included in the source package, possibly overriding the corresponding upstream file) - we also have experimental VCS-based formats (git and bzr, thanks to Joey Hess and Colin Watson) So please try it out, I built a package here: http://people.debian.org/~hertzog/packages/dpkg-dev_1.14.17_all.deb Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New source package
Hi, I have developed some new software, an audioscrobbler client for last.fm, which I would like to see included, probably under Multimedia. It consists of two simple C source files - how do I go about getting it included in Debian? Cheers, David. [EMAIL PROTECTED] -- http://dmctek.googlepages.com
Re: New source package
On Thu, Oct 19, 2006 at 09:47:10AM +0100, David Moore wrote: Hi, I have developed some new software, an audioscrobbler client for last.fm, which I would like to see included, probably under Multimedia. It consists of two simple C source files - how do I go about getting it included in Debian? Two options: * File an RFP (reportbug wnpp) and hope someone will package it for you. * Read the documentation on how to package something, and try to find a sponsor who will upload it for you. You will have more success on debian-mentors than this mailinglist if you go down that road. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New source package
On Thu, Oct 19, 2006 at 09:47:10AM +0100, David Moore wrote: Hi, I have developed some new software, an audioscrobbler client for _l_a_s_t_._f_m, which I would like to see included, probably under Multimedia. It consists of two simple C source files - how do I go about getting it included in Debian? Cheers, Hi David, In the Debian Bug tracking system, there is a pseudo-package[0] call wnpp[1] that you file a ITP 'bug' (Intent to Package) against which states your intention to create a Debian package. If you are not a Debian Developer, you will need a 'sponsor' for your package. This person will inspect your package for numerous things including trojans, bugs, and Debian policy violation. If its OK, that person will upload it into the 'incoming' server[2] where it will propagate to the 'unstable' branch of Debian. The easiest way to file a wnpp bug is to use the Debian program 'reportbug' for your ITP. Fill in all the required details or it will be rejected. Read the MAN pages for info. You should check out the Debian Developer subsite[3] and start by reading the Debian new maintainers guide[4]. You should also read the Debian developers reference and Debian policy manual for complete detains on how to create a Debian package up to Debian Standards. You can join the debian-mentors list for help with creating a Debian package. Also, when you create your ITP, folks may question the need for the package for various reasons like: are you sure the license is DFSG free? is there already a similar program in Debian? if so, why do we need this one? Could you add it to an existing package, if its a small program? Don't be discouraged if you are asked, as folks want to make sure that software in Debian is not simply a one-line shell script or the 24th version of vi. And if you are really brave and patient, you can join the Debian new maintainer queue and join the ranks as a voting member of Debian. here's to seeing your package in Debian! Kev [0] http://www.debian.org/Bugs/pseudo-packages [1] http://bts.debian.org/wnpp [2] http://incoming.debian.org [3] http://www.debian.org/devel/ [4] http://www.debian.org/doc/maint-guide/ -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Removing and replacing a binary package with a new source package?
I'm planning to remove ifp-line from the archive now that libifp (and its ifp-line-equivalent) is mature and tested. Right now, the ifp-line source package generates an ifp-line binary package, and the libifp source package generates an ifp-line-libifp package (that Provides: ifp-line). What's the best way to do this to avoid confusing the archive scripts and/or bothering ftp-masters? The easiest thing to do would be file an RM bug for ifp-line and just have libifp generate an ifp-line package (which Provides: ifp-line-libifp). Is this going to cause any problems? Do I need to wait for ifp-line to be removed before uploading the new libifp? -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: new source package producing old deb's is not regarded as NEW
Jeroen van Wolffelaar [EMAIL PROTECTED] wrote: As it happens, due to some changes in the details of the override file handling, new source package names will soon make the package go to NEW too, even though there already exists a binary package by that name. That the new source package name already exists as binary package name is quite exceptional, but in this case indeed it matters. Thank you. I think these changes in the details do the right thing. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: new source package producing old deb's is not regarded as NEW
On Tue, Oct 04, 2005 at 07:01:07PM +0200, Frank Küster wrote: this week I uploaded a new source package, libkpathsea3, that produces existing binary packages (libkpathsea3, libkpathsea-dev). I was surprised to learn that this package was not subject to NEW processing, but rather was simply treated as any existing package. Your observations are correct, this is indeed what happens. The override file, which determines what packages are allowed in and what packages get in NEW for manual review, is simply a list of allowed package names. The assumption is here indeed that only if a totally new name comes about, it should be manually checked. There is a list for binary package names and for source package names, currently source packages are allowed if they occur in *either* of those two lists. As it happens, due to some changes in the details of the override file handling, new source package names will soon make the package go to NEW too, even though there already exists a binary package by that name. That the new source package name already exists as binary package name is quite exceptional, but in this case indeed it matters. Thanks, --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
new source package producing old deb's is not regarded as NEW
(Please note the M-F-T -devel) Hi, this week I uploaded a new source package, libkpathsea3, that produces existing binary packages (libkpathsea3, libkpathsea-dev). I was surprised to learn that this package was not subject to NEW processing, but rather was simply treated as any existing package. In my case the exact purpose of the package was to replace the old binary packages that were previously produced by tetex-bin. But it might as well be that somebody uploads a NEW package that just happens to produce an existing binary package that they don't know about. Furthermore, if the name of the source package changed, this might indicate that there were some upstream changes. This could include a new author, project or even license, and might deserve a look by the ftp-masters. What do you think? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
New source package uploads to `unstable' allowed
You may now upload packages in the new source format to `unstable'. Packages in `stable' will continue to be in the old format. Note that the caveats in my release announcement on debian-changes for 1.3.8 apply: * The new source tools have not been very well tested and will have bugs, some probably serious. * The source format is not entirely fixed yet. You may need to make significant changes. You _will_ need to keep up with minor documentation changes and _will_ need to make at least one further release when the format is finalised as the Standards-Version value will be changed. However, building releases is a lot easier now :-) and you don't have to re-upload the original source tarfile part of the source more than once per upstream version. I shall probably declare the new format official on Sunday. Ian.
dpkg 1.3.0, hello 1.3-7: new source package format
I'd like people to take a look at what I've done here. The dpkg 1.3.0
binary package is fine to install and use (and indeed, it fixes a bug
or two), but the whole thing ought not to be moved even into unstable
until we've finalised the new source package format.
The new dpkg contains a bevy of new scripts; the new hello package
should produce the same binary package, but the source is all
rearranged. For a more complex source example you can see dpkg.
Documentation, in the form of the new programmers' and policy manuals,
will be forthcoming very shortly.
Ian.
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Tue, 6 Aug 1996 02:31:52 +0100
Source: dpkg
Binary: dpkg
Architecture: source i386
Version: 1.3.0
Distribution: experimental
Urgency: low
Maintainer: Ian Jackson [EMAIL PROTECTED]
Description:
dpkg - Package maintenance system for Debian Linux
Changes:
dpkg (1.3.0) experimental; urgency=LOW
.
* dpkg can install named pipes.
* dpkg-deb supports directory for destination, generates filename.
* dpkg-{source,gencontrol,genchanges,parsechangelog,buildpackage},
dpkg-distaddfile scripts to support new source package format.
* a.out build no longer supported.
* Changed to new source package format.
Files:
cefed959519825093d3d5f9844fbbf9e 526 base required dpkg_1.3.0.dsc
1289e4578de3eee386770a6653045677 391353 base required dpkg_1.3.0.tar.gz
403586a1dc2ce73c3b60dc38c54e4815 241538 base required dpkg_1.3.0_i386.deb
f9c0d03408eb007a41aa0ad2d17dd85a 236451 byhand -
dpkg_1.3.0_i386.nondebbin.tar.gz
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMgdbNcMWjroj9a3bAQFvowP/Vy3wqOVEo0aSdS19/PRQWXG3sZXEHHES
g6gwReX1Q5S1jfNIbVfOsVK/6Ovj5hZzQu9SKFjuXQEWLZ5dwuPyAFfQXWBPrYmR
HvSoT4iVKJh04ceNeAAve9nju1UySoVcqjhPyEQXEUlpx0L6RS2hFHoX8EwyJVWi
g+0t3b68oWg=
=/ZEv
-END PGP SIGNATURE-
-BEGIN PGP SIGNED MESSAGE-
Format: 1.5
Date: Tue, 6 Aug 1996 02:22:38 +0100
Source: hello
Binary: hello
Architecture: source i386
Version: 1.3-7
Distribution: experimental
Urgency: low
Maintainer: Ian Jackson [EMAIL PROTECTED]
Description:
hello - The classic greeting, and a good example
Changes:
hello (1.3-7) experimental; urgency=LOW
.
* Changed to new source packing scheme.
Files:
67d6f1ce34215741d958a3e113ba512e 585 devel optional hello_1.3-7.dsc
1b36dd5413283b0e18f45784e6ee433b 87701 devel optional hello_1.3.orig.tar.gz
8a3125503ca8fadce859786ebd72ddb1 2612 devel optional hello_1.3-7.diff.gz
704d0342835a2a818c221db6b3078ba5 13726 devel optional hello_1.3-7_i386.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.2i
iQCVAwUBMgdbmMMWjroj9a3bAQFywQQAzMdFhorexxHrmrHlHYQF/FtkkpwRN0GV
mKEfVsU7iJUtSUjkDiZROlPGnzOvjUlg0pOBPcs1yInCTRG9M8/1KM+7l0hDsZWv
0XWpgQuHU5ra7c6TtQbLBzr8PSTMPSfPZTJcDyGXPwWoH5VOohC8RzfoS4CFn++A
7UmaLUQgCOI=
=D9yh
-END PGP SIGNATURE-
