Re: Status of new source formats project
On Wednesday 05 August 2009 14:21:54 Cyril Brulebois wrote: Michael Banck mba...@debian.org (05/08/2009): On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, It's the preferred format for 99% of all Free Software work/projects AFAICT. I was wondering who could be in the last 1%. At least OpenSceneGraph people[1] prefer being sent the whole files. :) For everyone's further entertainment: The PostgreSQL project heavily prefers context diff patch submissions. This is also part of the reason why PostgreSQL is still stuck on CVS, because Git does not produce context diffs. There you go. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, It's the preferred format for 99% of all Free Software work/projects AFAICT. and that we like that others use the formats that we prefer. I think that is a too weak argument, so unless there is a real flaw in the format used upstream, I will not bother them for a change. This formats works with quilt, so I do not understand why it would be difficult to get it work with the format ???3.0 (quilt)??? of dpkg. According to the current discussion, the problem is more political than technical. If all fails, you can still drop the upstream patches in debian/upstream-patches/ or so for your own purposes. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Michael Banck mba...@debian.org (05/08/2009): On Wed, Aug 05, 2009 at 10:15:22AM +0900, Charles Plessy wrote: And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, It's the preferred format for 99% of all Free Software work/projects AFAICT. I was wondering who could be in the last 1%. At least OpenSceneGraph people[1] prefer being sent the whole files. :) 1. http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol Mraw, KiBi. signature.asc Description: Digital signature
Re: Status of new source formats project
Charles Plessy ple...@debian.org writes: Le Wed, Aug 05, 2009 at 03:45:00PM +1000, Ben Finney a écrit : The point, rather, seems to be that unified-diff format is the de facto standard format for exchanging patch information. Le Wed, Aug 05, 2009 at 10:53:21AM +0200, Michael Banck a écrit : It's the preferred format for 99% of all Free Software work/projects AFAICT. In my workplace's cafeteria, 99 % of the people eat curry rice with a spoon, and 1 % with chopsticks. But this is causing no trouble Right, because an individual's use of spoon or chopsticks to eat their own meal isn't about interaction *between* people; it's a private choice that affects only that individual. The analogy doesn't hold for this discussion, since this is about data interchange formats, which affects *all* parties in the transaction. See how far you'd get with expecting accommodation of 1% of people using a different form of currency to pay for their curry rice. I am all for campaigning for the unified diff format if there are arguments on which I can base a discussion with Upstream, but a mere cultural preference, be it the one of a very large majority, is a too weak argument. Standard data interchange formats is such an argument: one which you even quoted me as putting forth. The de facto standard data format for interchange of patch data is unified-diff format. -- \ “Well, my brother says Hello. So, hooray for speech therapy.” | `\ —Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Perhaps you could talk to upstream about switching to either using unified diffs for updates, tarballs for every release or a git/etc repository? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit : Perhaps you could talk to upstream about switching to either using unified diffs for updates, tarballs for every release or a git/etc repository? For sure, Debian can suggest them git, Ubuntu can suggest them bzr, Fedora can suggest them cvs, and Opensuze can suggest them svn. I do not mind working with patches instad of archive updates. For Debian, it also has the advantage of not having 12 orig.gz updates per year (12 × 20 Mo archives). I do not know how it matters with recent hard drives, however… And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, and that we like that others use the formats that we prefer. I think that is a too weak argument, so unless there is a real flaw in the format used upstream, I will not bother them for a change. This formats works with quilt, so I do not understand why it would be difficult to get it work with the format ’3.0 (quilt)’ of dpkg. According to the current discussion, the problem is more political than technical. We already do not manage to agree internally on what is the best workflow. I can propose Upstream to adapt their habits to our habits, but this has to come with benefits that overcome the energy invested in the changes, and the fact that what is best for distributor A will not match what distributor B expects. Much saner in my opinion is to have a toolchain that is liberal in what it accepts. (Hence the proposition to accept upstream ‘zip’ archives). 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: Status of new source formats project
Charles Plessy ple...@debian.org writes: Le Tue, Aug 04, 2009 at 09:51:26AM +0200, Paul Wise a écrit : Perhaps you could talk to upstream about switching to either using unified diffs for updates, tarballs for every release or a git/etc repository? For sure, Debian can suggest them git, Ubuntu can suggest them bzr, Fedora can suggest them cvs, and Opensuze can suggest them svn. Fine. Whichever one of those they choose, it can consume and produce unified-diff-format patches. And for the format of the patch, I do not know what to tell them apart that unified diff is the preferred format of some Debian developers, That's quite a misrepresentation; it's far wider than just “some Debian developers” who prefer that format. and that we like that others use the formats that we prefer. The point, rather, seems to be that unified-diff format is the de facto standard format for exchanging patch information. I think that is a too weak argument, so unless there is a real flaw in the format used upstream, I will not bother them for a change. The flaw is that patch information in any format other than unified-diff format is nowhere near as portable. Much saner in my opinion is to have a toolchain that is liberal in what it accepts. (Hence the proposition to accept upstream ‘zip’ archives). This is in opposition to the ideal of having standard [0] formats for data interchange, and choosing them on the basis of what is already widely produced and accepted. [0] “standard” in this usage necessarily including “freely-implemented”, which doesn't disqualify the other options being discussed, but I put this footnote in the hope of forestalling useless discussions about proprietary formats. -- \ “I moved into an all-electric house. I forgot and left the | `\ porch light on all day. When I got home the front door wouldn't | _o__)open.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Charles Plessy ple...@debian.org writes: Another question that I would like to ask is on the auto-patching functionality. One of the programs we package, EMBOSS, is released once a year every 15th of July, and other updates are made via patches. Currently it is possible to just give the patch to quilt to apply it. With the new source format â3.0 (quilt)â, it is not possible. Do you think it would be possible to change this behavior or at least to disable the auto-patching facilities? It would be of course easy to convert the patch, but I would really prefer to stay as identical to upstream's materials as possible. Have a nice sunday, Why not just use 3.0 (native) format then? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Vincent Danjean wrote: Emilio Pozuelo Monfort wrote: Charles Plessy wrote: I see that .bzip2 and .lzma are also supported compression methods for the 3.0 (native) format as well as for the binary packages. But I do not think it would be useful to add zip to this list. It seems to me that the only thing needed is the capacity to unpack the original upstream sources. In that case there would not be a need for a Lenny support, isn't it? You need it to be supported in stable before using it in unstable. So at best, you would need to implement it in Squeeze and wait for Squeeze+1 to use it. This requirement is here to ensure smooth upgrade (stable - testing (or new stable) with dpkg from stable). So it stand for .bzip2 and .lzma support in *binary* packages. Charles is talking about *sources* packages. Some packages in testing already require other packages from testing to build themselves (ie build-depends nor present in stable). This is catch by debbuild for example. Unpacking a source package is not needed during an upgrade. However, it occurs before a build. So, I understand the question of Charles as do we want that stable dpkg be able to unpack all packages from testing ?. I have no strong opinion for this. In stable servers I use sometime the sources of unstable/testing and I backport them. So I would like to have package compatibility actual stable to actual unstable. I do this things only on small packages, so I don't want to upgrade/backport dpkg. Anyway such things are not a common usage which should be supported, so I can live also with a breaking source package compatibility. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On Sun, 02 Aug 2009, Charles Plessy wrote: I see that .bzip2 and .lzma are also supported compression methods for the 3.0 (native) format as well as for the binary packages. But I do not think it would be useful to add zip to this list. It seems to me that the only thing needed is the capacity to unpack the original upstream sources. In that case there would not be a need for a Lenny support, isn't it? As stated elsewhere, its's good to be able to unpack all source packages with the current stable dpkg-source. The patch is not in unified format, which causes the failure of dpkg-buildpackage. It is trivial to refresh it with quilt to the unified format, but this introduces a divergence with upstream that I would prefer to avoid, because it makes it difficult for others to verify that we did not modify it. Can you support in the format ’3.0 (quilt)’ patches that are accepted by default quilt installation? No. I really prefer that we uniformize the patches that we provide through debian/patches/ as it's an external interface as well (and for people reviewing patches, unified format is certainly the most common format). Furthermore it would require disabling quite a lot of checks that are currently in place. 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: Status of new source formats project
Le Mon, Aug 03, 2009 at 06:18:57PM +0200, Raphael Hertzog a écrit : The patch is not in unified format, which causes the failure of dpkg-buildpackage. It is trivial to refresh it with quilt to the unified format, but this introduces a divergence with upstream that I would prefer to avoid, because it makes it difficult for others to verify that we did not modify it. Can you support in the format ’3.0 (quilt)’ patches that are accepted by default quilt installation? No. I really prefer that we uniformize the patches that we provide through debian/patches/ as it's an external interface as well (and for people reviewing patches, unified format is certainly the most common format). If this patch is to be reviewed, then in my opinion it is better to keep it in the original upstream format, because the first thing to check would be to make sure that it is not altered nor obsolete. Nobody ever complained about patches not in unified format in debian/patches before on this list. Lastly, let me stress out again that this is an upstream patch. Reviewing it has as much relevance as reviewing a couple of source files taken randomly in the original source archive. If using the unified format is to become a “must” in debian/patches, I would prefer to have it discussed rather than imposed silently. I would understand that your time to develop support for non-unified format is limited, but if the reason is that you want to enforce one format, then as a maintainer I think that I should have my word to say on how I manage my packages. In the meantime, I will move the patches from debian/patches to debian/patch, so that it does not block the switch to the format 3.0, which brings some improvements that are much welcome in addition to the patch management, that I think goes in the wrong direction. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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: Status of new source formats project
Le Thu, Jul 30, 2009 at 04:55:16PM +0200, Raphael Hertzog a écrit : I updated the wiki page listing the status of this project: http://wiki.debian.org/Projects/DebSrc3.0 Bonjour Raphaël, first of all, thank you for making things progress for the support of a next-generation source format. In the case of programs distributed as a bzipped tar archive, it will save us some time, allow to delete a few README.source and get-orig-source files, and simplifiy our rules files. But actually, among the programs that are not distributed upstream in a tar.gz format, we in the Debian Med team have as many zip cases as bzip2. Do you think that it would be possible to support zip format (i.e. .zip, .jar and .xpi extensions) for Debian source packages version 3? I understand that it would require to change a few things in the Dpkg perl modules, as they assume that the original archives are always using tar. I have quite poor programming skills, but if you and others do not have time but nevertheless are interested by such a modification, I can try to work on a patch (possibly using libarchive-any-perl). In that case, can you tell me what kind of timeline would fit? Another question that I would like to ask is on the auto-patching functionality. One of the programs we package, EMBOSS, is released once a year every 15th of July, and other updates are made via patches. Currently it is possible to just give the patch to quilt to apply it. With the new source format ‘3.0 (quilt)’, it is not possible. Do you think it would be possible to change this behavior or at least to disable the auto-patching facilities? It would be of course easy to convert the patch, but I would really prefer to stay as identical to upstream's materials as possible. Have a nice sunday, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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: Status of new source formats project
On Sun, 02 Aug 2009, Charles Plessy wrote: But actually, among the programs that are not distributed upstream in a tar.gz format, we in the Debian Med team have as many zip cases as bzip2. Do you think that it would be possible to support zip format (i.e. .zip, .jar and .xpi extensions) for Debian source packages version 3? Not really. First of all, that support should have been implemented with the rest so that it's available in lenny already. Then many options and features rely on the fact that tar is used. So it would probably requires addition of a supplementary abstraction/indirection. I understand that it would require to change a few things in the Dpkg perl modules, as they assume that the original archives are always using tar. I have quite poor programming skills, but if you and others do not have time but nevertheless are interested by such a modification, I can try to work on a patch (possibly using libarchive-any-perl). In that case, can you tell me what kind of timeline would fit? I try to avoid depending on modules outside of perl-modules. I might consider a patch if it's clean enough but then it will be not easy to integrate it cleanly. Then it will also require supplementary modifications to dak to allow .zip and I don't know if ftpmasters would like it, you should better check this before-hand. Another question that I would like to ask is on the auto-patching functionality. One of the programs we package, EMBOSS, is released once a year every 15th of July, and other updates are made via patches. Currently it is possible to just give the patch to quilt to apply it. With the new source format ‘3.0 (quilt)’, it is not possible. Do you think it would be possible to change this behavior or at least to disable the auto-patching facilities? Why would it be impossible? You can modify the patch series to integrate whatever set of patches that you want... You can avoid using auto-patching of course, just put your patches somewhere else than debian/patches/. It would be of course easy to convert the patch, but I would really prefer to stay as identical to upstream's materials as possible. How are patches distributed and what kind of conversions is 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: Status of new source formats project
Le Sun, Aug 02, 2009 at 11:03:11AM +0200, Raphael Hertzog a écrit : On Sun, 02 Aug 2009, Charles Plessy wrote: About zip support: But actually, among the programs that are not distributed upstream in a tar.gz format, we in the Debian Med team have as many zip cases as bzip2. Do you think that it would be possible to support zip format (i.e. .zip, .jar and .xpi extensions) for Debian source packages version 3? Not really. First of all, that support should have been implemented with the rest so that it's available in lenny already. Then many options and features rely on the fact that tar is used. So it would probably requires addition of a supplementary abstraction/indirection. I see that .bzip2 and .lzma are also supported compression methods for the 3.0 (native) format as well as for the binary packages. But I do not think it would be useful to add zip to this list. It seems to me that the only thing needed is the capacity to unpack the original upstream sources. In that case there would not be a need for a Lenny support, isn't it? About patches not accepted by dpkg-dev: It would be of course easy to convert the patch, but I would really prefer to stay as identical to upstream's materials as possible. How are patches distributed and what kind of conversions is needed? The patch is available from the upstream FTP server and it just works to drop it in debian/patches, the only modification being of course to add it a nice DEP-3 header. http://svn.debian.org/wsvn/debian-med/trunk/packages/emboss/trunk/debian/patches/official-upstream-patch.patch The patch is not in unified format, which causes the failure of dpkg-buildpackage. It is trivial to refresh it with quilt to the unified format, but this introduces a divergence with upstream that I would prefer to avoid, because it makes it difficult for others to verify that we did not modify it. Can you support in the format ’3.0 (quilt)’ patches that are accepted by default quilt installation? Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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: Status of new source formats project
Charles Plessy wrote: I see that .bzip2 and .lzma are also supported compression methods for the 3.0 (native) format as well as for the binary packages. But I do not think it would be useful to add zip to this list. It seems to me that the only thing needed is the capacity to unpack the original upstream sources. In that case there would not be a need for a Lenny support, isn't it? You need it to be supported in stable before using it in unstable. So at best, you would need to implement it in Squeeze and wait for Squeeze+1 to use it. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: Status of new source formats project
Raphael Hertzog hert...@debian.org writes: On Sun, 02 Aug 2009, Charles Plessy wrote: But actually, among the programs that are not distributed upstream in a tar.gz format, we in the Debian Med team have as many zip cases as bzip2. Do you think that it would be possible to support zip format (i.e. .zip, .jar and .xpi extensions) for Debian source packages version 3? Not really. First of all, that support should have been implemented with the rest so that it's available in lenny already. Then many options and features rely on the fact that tar is used. So it would probably requires addition of a supplementary abstraction/indirection. Adding .zip would also be rather a pain for things like lintian. Not impossible, but lintian assumes that it can get tar listings of Debian packages and knows their format. Different compression methods don't change that, but .zip is a completely different file format that requires a completely different set of tools. I would prefer that we not go this direction. I don't think the additional complexity is really worth it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
Emilio Pozuelo Monfort wrote: Charles Plessy wrote: I see that .bzip2 and .lzma are also supported compression methods for the 3.0 (native) format as well as for the binary packages. But I do not think it would be useful to add zip to this list. It seems to me that the only thing needed is the capacity to unpack the original upstream sources. In that case there would not be a need for a Lenny support, isn't it? You need it to be supported in stable before using it in unstable. So at best, you would need to implement it in Squeeze and wait for Squeeze+1 to use it. This requirement is here to ensure smooth upgrade (stable - testing (or new stable) with dpkg from stable). So it stand for .bzip2 and .lzma support in *binary* packages. Charles is talking about *sources* packages. Some packages in testing already require other packages from testing to build themselves (ie build-depends nor present in stable). This is catch by debbuild for example. Unpacking a source package is not needed during an upgrade. However, it occurs before a build. So, I understand the question of Charles as do we want that stable dpkg be able to unpack all packages from testing ?. I have no strong opinion for this. Regards, Vincent Cheers, Emilio -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On 2009-08-02, Vincent Danjean vdanjean...@free.fr wrote: Unpacking a source package is not needed during an upgrade. However, it occurs before a build. So, I understand the question of Charles as do we want that stable dpkg be able to unpack all packages from testing ?. I have no strong opinion for this. Our infrastructure relies on this. So yes. Both dak and sbuild do this. (At least the latter used to do it in older versions, I didn't check the new one.) Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of new source formats project
On Sun, Aug 02, 2009 at 08:11:57PM +, Philipp Kern wrote: On 2009-08-02, Vincent Danjean vdanjean...@free.fr wrote: Unpacking a source package is not needed during an upgrade. However, it occurs before a build. So, I understand the question of Charles as do we want that stable dpkg be able to unpack all packages from testing ?. I have no strong opinion for this. Our infrastructure relies on this. So yes. Both dak and sbuild do this. (At least the latter used to do it in older versions, I didn't check the new one.) The new sbuild always uses dpkg-source from inside the build environment, so there's no restriction there. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Status of new source formats project
Hello, I updated the wiki page listing the status of this project: http://wiki.debian.org/Projects/DebSrc3.0 During debconf I used part of my time to push this project forward. 1/ Lucas did again a rebuild of the archive to discover problems that will appear if all packages are converted to 3.0 (quilt) format. I processed 200 failed build logs and filed some new wishlist bugs to prepare for a global transition (and fixed a sid-only bug in dpkg-source detected thanks to this rebuild). http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=hert...@debian.org;tag=3.0-quilt-by-default 2/ I prepared some test source packages covering most interesting cases to try out with various tools, I checked the most important ones (apt-get source, sbuild) and they do cope with it. I encourage you to test all other tools and report your success/failures here (and please file bug for the failures). http://people.debian.org/~hertzog/packages/debsrc3.0/ 3/ I discussed with Jörg Jaspert and Mark Hymers the status of my patch against dak. Currently they plan to merge my patch after they have finished to update dak to use sqlalchemy, but given that this is an intrusive change they will have to test it carefully and Jörg expected that it will still be 2 to 3 months until they can integrate my patch. :-( Both patches/branches are going to conflict so someone will have to handle the merge conflict whatever the merge order is. I offered them to handle it myself even if my patch is merged now (without conflicting with anything since the sqlalchemy one is not yet ready/merged). The sqlalchemy rewrite is not yet public but Mark hopes to publish it this week-end (1-2 Aug). After my upcoming vacation, and if I still can't convince ftpmasters to merge my working branch immediately I'll create a new branch of my patch merged with the new sqlalchemy branch so that they have a chance to push both changes at the same time (or in the order that they want). This dak modification is the main blocker point for this project to go forward (and has been so for quite some time already). 4/ I discussed with Luk Claes if anything had to be done on the buildd side. There's not much to be done there since the new sbuild is working well with new source formats but there are still some buildd using the old version. Those have to be updated to the new sbuild and this process has been ongoing for quite some time already. I pinged some of the concerned buildd maintainers and provided sample buildd logs generated by the new sbuild with the new source formats so that they can adapt their build logs processing scripts immediately. 5/ In all cases, I hope we will enable support of new source formats in squeeze so that individual packages can switch to it (in particular bigger packages that would benefit from the multi-tarball thingie). But depending on the time left before the freeze, we might not start a global transition to the new formats (i.e. I would not modify dpkg-source to produce newer source formats when there's no debian/source/format). 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
