Re: First steps towards source-only uploads
On Wed, Aug 13, 2014, at 14:02, Guillem Jover wrote: Hi! On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote: #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs This is now available in dpkg 1.17.11, and as mentioned on the bug report, you can use it in at least these ways: # Source and arch-indep only build, will fail if the package does # not produce any arch-indep binary, in which case you'd use -S. $ dpkg-buildpackage -g or # Full build, but filter the generated .changes file to only inlcude # source and possibly arch-indep binaries, will not fail if the # latter are missing. $ dpkg-buildpackage --changes-option=-g Any success of passing this to git-pbuilder? I had to modify pdebuild to not pass $DEBBUILDOPTS to dpkg-buildpackage invocation and only pass those options to the build inside of pbuilder. Ondrej -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1409041723.583972.156795125.3f34c...@webmail.messagingengine.com
Re: First steps towards source-only uploads
On Fri, 2014-08-15 at 11:27:00 +0200, Johannes Schauer wrote: Quoting Guillem Jover (2014-08-13 13:48:11) On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote: There are also other problems that need to be eventually addressed: as far as I know there are some source packages producing arch:all binaries that cannot be built on all architectures. A Build-Architecture-Indep field was proposed to indicate where it should be built in this case[1], but for now I think we can require that maintainers have to upload the arch:all packages in this case. I think all proposed field names in that thread are rather confusing. In Debian packaging lingo build means several things, it can mean at least the build machine (!= host machine), or it can mean the act of building. In the case of Build-Depends style fields, it's referring to the act of building, but Architecture is related to the host system/compiler, so mixing the different meanings would be messy, think for example about cross-compiling. But is the question not *on* which architecture arch:all packages are built, and would the term build in Build-Architecture-Indep thus not be correct in both of its meanings (as the architecture I'm building *on* as well as the act of building)? Exactly, that was precisely my point, thus why this would be very confusing. (I guess I didn't make myself clear enough :) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140823010451.gb12...@gaara.hadrons.org
Re: First steps towards source-only uploads
Hello, 2014-08-15 16:04 GMT+02:00 Ondřej Surý ond...@sury.org: I have encountered a situation where the FTBFS bug was caused by segfault in other package. This has forced me to split opendnssec-doc to arch:all package (which was good thing anyway), so there are cases where you want to build the arch:all on most stable and fastest arch. Could we just pick amd64 and be done? :) We currently got powerpc or s390x machines producing faster builds than amd64, or would you instead base your arch selection on archive build coverage which amd64 is probably closer to 100% than any other arch. If amd64 was to be picked, what would happen to packages producing arch:all packages that do not build on such architecture? Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caodfweeabq7nuxldcjd6ce9vaw9jwmzhkkjcnbsch92ugm1...@mail.gmail.com
Re: First steps towards source-only uploads
On Tue, 19 Aug 2014, Hector Oron wrote: If amd64 was to be picked, what would happen to packages producing arch:all packages that do not build on such architecture? They would get a FTBFS bug and they would get fixed. Or, if it's not a bug, the package would be uploaded by the maintainer himself (until we have the required support to document in a field the architecture that should build the package). Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819141244.gb13...@x230-buxy.home.ouaza.com
Re: First steps towards source-only uploads
On Tue, 19 Aug 2014, Hector Oron wrote: 2014-08-15 16:04 GMT+02:00 Ondřej Surý ond...@sury.org: I have encountered a situation where the FTBFS bug was caused by segfault in other package. This has forced me to split opendnssec-doc to arch:all package (which was good thing anyway), so there are cases where you want to build the arch:all on most stable and fastest arch. Could we just pick amd64 and be done? :) We currently got powerpc or s390x machines producing faster builds than amd64, or would you instead base your arch selection on archive build coverage which amd64 is probably closer to 100% than any other arch. The *use* coverage is the major reason, IMO. AMD64 is the arch most likely to have the best quality assurance, because it is directly used by the vast majority of the packagers. s390X is not generally available and we cannot own or replace them easily, so using it would be a bad idea IMHO: we need to keep our independence. AFAIK, very powerful AMD64 boxes are easier and cheaper to buy/replace than very powerful powerpc ones. Especially outside the USA and EU. If amd64 was to be picked, what would happen to packages producing arch:all packages that do not build on such architecture? It is a FTBFS error that must be fixed. Nothing new there. I do think we should ignore FTBFS bugs for arch:all on arches where the build failure happens due to insufficient resources (memory, storage, address space, etc). So, if the FTBFS bug for the arch:all package happens in some other arch than AMD64 *and* it is not due to resource restrictions on that arch, it is a FTBFS bug that has to be fixed just the same. This does not discriminate against other arches. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140819191532.ga19...@khazad-dum.debian.net
Re: First steps towards source-only uploads
Hi, Quoting Guillem Jover (2014-08-13 13:48:11) On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote: There are also other problems that need to be eventually addressed: as far as I know there are some source packages producing arch:all binaries that cannot be built on all architectures. A Build-Architecture-Indep field was proposed to indicate where it should be built in this case[1], but for now I think we can require that maintainers have to upload the arch:all packages in this case. I think all proposed field names in that thread are rather confusing. In Debian packaging lingo build means several things, it can mean at least the build machine (!= host machine), or it can mean the act of building. In the case of Build-Depends style fields, it's referring to the act of building, but Architecture is related to the host system/compiler, so mixing the different meanings would be messy, think for example about cross-compiling. But is the question not *on* which architecture arch:all packages are built, and would the term build in Build-Architecture-Indep thus not be correct in both of its meanings (as the architecture I'm building *on* as well as the act of building)? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815092700.14069.93664@hoothoot
Re: First steps towards source-only uploads
Hello, 2014-08-13 22:59 GMT+02:00 Philipp Kern pk...@debian.org: On 2014-08-13 14:34, Raphael Hertzog wrote: On Wed, 13 Aug 2014, Colin Watson wrote: I don't think there's a good reason to build them separately, and some good reasons not to (for example, it would waste a good deal of buildd time for a number of packages without very hygienic separation of their build rules). My suggestion would be to just build them along with the architecture-dependent binaries for some nominated architecture, which could be package-specific or not depending on what you all have time for, and be done with it. In kali, that's exactly what I have been doing. Any package that builds an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd gets called with -A. It doesn't matter whether it builds only the arch: all or another package too. We need to convey if the arch:all is actually needed, though, otherwise dak will reject the package. Or could we simply build it always and have it discarded if the maintainer's copy had been accepted? Even building arch:all packages in one architecture might solve the issue, I do not like that approach, as it holds other arches from building until that primary arch has built arch:all packages. It also leads to not fully buildable packages for the rest of architectures, i.e. #690260 (openjdk-7: build empty doc packages on arm). Building arch:all on every architecture can also be seen as a waste of build time but effective. Another approach would be to find out if arch:all packages are available for build, if not, then build them along package in whichever architecture, otherwise skip them. That looks the most fair approach to me, but it can possibly lead to interesting races, depending on implementation. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caodfwegv40bnpuj_u5i-4nzvr5ua4wdo5wy+8xj+7wqs1lu...@mail.gmail.com
Re: First steps towards source-only uploads
On Fri, 15 Aug 2014, Hector Oron wrote: Even building arch:all packages in one architecture might solve the issue, I do not like that approach, as it holds other arches from building until that primary arch has built arch:all packages. I understand the concern at the philosophical level but on a practical level, using the fastest architecture we have is actually the way to ensure that all arches get their arch all packages in the fastest possible way. It also leads to not fully buildable packages for the rest of architectures, i.e. #690260 (openjdk-7: build empty doc packages on arm). Those are bugs that can be found as part of QA activities, we don't have to complicate our build infrastructure just to ensure that this specific class of bugs gets found during build. On the contrary, this is a sure way to create unexpected problems (by letting bad arch all packages enter the archive) that maintainers won't be able to anticipate as they do test-build their packages on i386/amd64 mainly. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815130004.gc17...@x230-buxy.home.ouaza.com
Re: First steps towards source-only uploads
On Fri, 15 Aug 2014, Raphael Hertzog wrote: On Fri, 15 Aug 2014, Hector Oron wrote: Even building arch:all packages in one architecture might solve the issue, I do not like that approach, as it holds other arches from building until that primary arch has built arch:all packages. I understand the concern at the philosophical level but on a practical level, using the fastest architecture we have is actually the way to ensure that all arches get their arch all packages in the fastest possible way. And any package that cannot build arch:all on a released arch for which it produces binary packages potentially has a FTBFS bug, anyway, which can be reported by any interested parties. Exceptions would be arches that are too resource-constrained to build it in the first place. IMHO, it is NOT the job of the autobuilders to track down and find every FTBFS bug in Debian. They cannot be expected to waste resources tracking down FTBFS bugs that have no effect on the current operations of the autobuilder network. It also leads to not fully buildable packages for the rest of architectures, i.e. #690260 (openjdk-7: build empty doc packages on arm). Those are bugs that can be found as part of QA activities, we don't have to complicate our build infrastructure just to ensure that this specific class of bugs gets found during build. Agreed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815133712.gc26...@khazad-dum.debian.net
Re: First steps towards source-only uploads
On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote: And any package that cannot build arch:all on a released arch for which it produces binary packages potentially has a FTBFS bug, anyway, which can be reported by any interested parties. Exceptions would be arches that are too resource-constrained to build it in the first place. I have encountered a situation where the FTBFS bug was caused by segfault in other package. This has forced me to split opendnssec-doc to arch:all package (which was good thing anyway), so there are cases where you want to build the arch:all on most stable and fastest arch. Could we just pick amd64 and be done? :) Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408111452.213427.153089893.5c8a7...@webmail.messagingengine.com
Re: First steps towards source-only uploads
On Fri, 15 Aug 2014, Ondřej Surý wrote: On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote: And any package that cannot build arch:all on a released arch for which it produces binary packages potentially has a FTBFS bug, anyway, which can be reported by any interested parties. Exceptions would be arches that are too resource-constrained to build it in the first place. I have encountered a situation where the FTBFS bug was caused by segfault in other package. This has forced me to split opendnssec-doc to arch:all package (which was good thing anyway), so there are cases where you want to build the arch:all on most stable and fastest arch. Could we just pick amd64 and be done? :) Yes, please :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140815140823.ga1...@khazad-dum.debian.net
Re: First steps towards source-only uploads
Hi! [ I had a note to reply to the previous thread, but never got to it. ] On Tue, 2014-08-12 at 13:27:38 +0200, Ansgar Burchardt wrote: On 08/12/2014 12:33, Hector Oron wrote: 2014-08-01 9:37 GMT+02:00 Ansgar Burchardt ans...@debian.org: We will allow not including arch:all packages in uploads once we have sorted out how to get them built. Has it been already discussed? If so, where? There are also other problems that need to be eventually addressed: as far as I know there are some source packages producing arch:all binaries that cannot be built on all architectures. A Build-Architecture-Indep field was proposed to indicate where it should be built in this case[1], but for now I think we can require that maintainers have to upload the arch:all packages in this case. I think all proposed field names in that thread are rather confusing. In Debian packaging lingo build means several things, it can mean at least the build machine (!= host machine), or it can mean the act of building. In the case of Build-Depends style fields, it's referring to the act of building, but Architecture is related to the host system/compiler, so mixing the different meanings would be messy, think for example about cross-compiling. [1] https://lists.debian.org/debian-devel/2014/02/msg01149.html Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813114811.ga13...@gaara.hadrons.org
Re: First steps towards source-only uploads
Hi! On Mon, 2014-08-04 at 02:35:46 -0400, Joey Hess wrote: #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs This is now available in dpkg 1.17.11, and as mentioned on the bug report, you can use it in at least these ways: # Source and arch-indep only build, will fail if the package does # not produce any arch-indep binary, in which case you'd use -S. $ dpkg-buildpackage -g or # Full build, but filter the generated .changes file to only inlcude # source and possibly arch-indep binaries, will not fail if the # latter are missing. $ dpkg-buildpackage --changes-option=-g The advantage of the second is that the package is fully built so that the maintainer can test that it builds and can install and test the resulting packages. Unfortunately as arch-specific packages are filtered out from the .changes file, lintian will not be able to find them. So you migth want to do a normal build followed by one with either -S or -g. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813120220.gb13...@gaara.hadrons.org
Re: First steps towards source-only uploads
Hi, On Tue, 12 Aug 2014, Ansgar Burchardt wrote: First, w-b has to recognize that arch:all packages need to be built. And they need to be scheduled on a buildd which builds the arch:all packages (and only the arch:all packages?). For the latter I assume sbuild would need an option to build only the arch:all packages using dpkg-buildpackage -A. It would also be interesting to test which packages FTBFS in this case. FWIW, sbuild supports -A (--arch-all) and this will result in calling dpkg-buildpackage -b (instead of -B). On Wed, 13 Aug 2014, Colin Watson wrote: I don't think there's a good reason to build them separately, and some good reasons not to (for example, it would waste a good deal of buildd time for a number of packages without very hygienic separation of their build rules). My suggestion would be to just build them along with the architecture-dependent binaries for some nominated architecture, which could be package-specific or not depending on what you all have time for, and be done with it. +1 In kali, that's exactly what I have been doing. Any package that builds an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd gets called with -A. It doesn't matter whether it builds only the arch: all or another package too. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813123433.gb6...@x230-buxy.home.ouaza.com
Re: First steps towards source-only uploads
Guillem Jover wrote: # Full build, but filter the generated .changes file to only inlcude # source and possibly arch-indep binaries, will not fail if the # latter are missing. $ dpkg-buildpackage --changes-option=-g The advantage of the second is that the package is fully built so that the maintainer can test that it builds and can install and test the resulting packages. Unfortunately as arch-specific packages are filtered out from the .changes file, lintian will not be able to find them. So you migth want to do a normal build followed by one with either -S or -g. I tend to use debuild from devscripts, primarily because it automatically runs lintian. If dpkg-buildpackage gained native support for invoking lintian, it could do so on the unfiltered changes file, and then emit the filtered changes file. Would you consider including support for that in dpkg-buildpackage? - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813192409.GA3056@jtriplet-mobl1
Re: First steps towards source-only uploads
On Wed, 2014-08-13 at 12:24:49 -0700, Josh Triplett wrote: Guillem Jover wrote: # Full build, but filter the generated .changes file to only inlcude # source and possibly arch-indep binaries, will not fail if the # latter are missing. $ dpkg-buildpackage --changes-option=-g The advantage of the second is that the package is fully built so that the maintainer can test that it builds and can install and test the resulting packages. Unfortunately as arch-specific packages are filtered out from the .changes file, lintian will not be able to find them. So you migth want to do a normal build followed by one with either -S or -g. I tend to use debuild from devscripts, primarily because it automatically runs lintian. If dpkg-buildpackage gained native support for invoking lintian, it could do so on the unfiltered changes file, and then emit the filtered changes file. Would you consider including support for that in dpkg-buildpackage? dpkg-buildpackage does support running a checker like lintian since 1.17.6 (see --check-command and DEB_CHECK_COMMAND in the man page). Doing what you request would require running dpkg-genchanges twice, but only sometimes, I'm not sure I like how that would smell as an interface, but I'll ponder about it (maybe just adding an option to request the filtering, so that the build type option is passed to dpkg-genchanges for the final .changes file, but otherwise dpkg-buildpackage performs a normal full build, hmmm). What comes to mind though, although slightly cumbersome, is that right now there's also this other option, which should cover all requirements (except being succint :): $ export DEB_CHECK_COMMAND=lintian $ dpkg-buildpackage -us -uc $ dpkg-genchanges -g ../pkgname_version_src+all.changes $ debsign ../pkgname_version_src+all.changes (dpkg-genchanges really needs a -O[filename] option, which I'll be implementing soon, and signing should eventually be disabled by default anyway as discussed some time ago here.) Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813201603.ga11...@gaara.hadrons.org
Re: First steps towards source-only uploads
On 2014-08-13 14:34, Raphael Hertzog wrote: On Wed, 13 Aug 2014, Colin Watson wrote: I don't think there's a good reason to build them separately, and some good reasons not to (for example, it would waste a good deal of buildd time for a number of packages without very hygienic separation of their build rules). My suggestion would be to just build them along with the architecture-dependent binaries for some nominated architecture, which could be package-specific or not depending on what you all have time for, and be done with it. +1 In kali, that's exactly what I have been doing. Any package that builds an arch: all is sent to an amd64 buildd and sbuild on the amd64 buildd gets called with -A. It doesn't matter whether it builds only the arch: all or another package too. We need to convey if the arch:all is actually needed, though, otherwise dak will reject the package. Or could we simply build it always and have it discarded if the maintainer's copy had been accepted? 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 Archive: https://lists.debian.org/99bea068419b09ad368191a1cd596...@hub.kern.lc
Re: First steps towards source-only uploads
Hello, 2014-08-01 9:37 GMT+02:00 Ansgar Burchardt ans...@debian.org: We will allow not including arch:all packages in uploads once we have sorted out how to get them built. Has it been already discussed? If so, where? Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAODfWeFagKRU8wE-N=wSFqaqBo4Ysg1Qpd9z3o+0=2w51sn...@mail.gmail.com
Re: First steps towards source-only uploads
Hi, On 08/12/2014 12:33, Hector Oron wrote: 2014-08-01 9:37 GMT+02:00 Ansgar Burchardt ans...@debian.org: We will allow not including arch:all packages in uploads once we have sorted out how to get them built. Has it been already discussed? If so, where? Not the part to actually implement it. But from my memories people in the buildd team had no principal objections, it's just that someone needs to spend time to implement everything needed for this. I asked in #-buildd recently what needs to be done to start building arch:all packages in the buildd network: First, w-b has to recognize that arch:all packages need to be built. And they need to be scheduled on a buildd which builds the arch:all packages (and only the arch:all packages?). For the latter I assume sbuild would need an option to build only the arch:all packages using dpkg-buildpackage -A. It would also be interesting to test which packages FTBFS in this case. There are also other problems that need to be eventually addressed: as far as I know there are some source packages producing arch:all binaries that cannot be built on all architectures. A Build-Architecture-Indep field was proposed to indicate where it should be built in this case[1], but for now I think we can require that maintainers have to upload the arch:all packages in this case. Ansgar [1] https://lists.debian.org/debian-devel/2014/02/msg01149.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e9fa2a.5090...@debian.org
Re: First steps towards source-only uploads
On Tue, Aug 12, 2014 at 01:27:38PM +0200, Ansgar Burchardt wrote: First, w-b has to recognize that arch:all packages need to be built. And they need to be scheduled on a buildd which builds the arch:all packages (and only the arch:all packages?). For the latter I assume sbuild would need an option to build only the arch:all packages using dpkg-buildpackage -A. It would also be interesting to test which packages FTBFS in this case. I don't think there's a good reason to build them separately, and some good reasons not to (for example, it would waste a good deal of buildd time for a number of packages without very hygienic separation of their build rules). My suggestion would be to just build them along with the architecture-dependent binaries for some nominated architecture, which could be package-specific or not depending on what you all have time for, and be done with it. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812232335.ga14...@riva.ucam.org
Re: Bug#756835: First steps towards source-only uploads
Hi, Quoting Matthias Urlichs (2014-08-07 07:54:26) Also, build profiles are not explained anywhere in Policy (unless that's been added after 3.9.5), so how would I discover which values are allowed / make sense? right. For the purpose of documenting the Package-List its usage for build profiles can just be omitted until build profiles are documented. Somehow I thought that a bug to document the restriction list syntax and build profiles had long been filled but apparently that wasn't the case so now there is #757760. cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811075507.14069.52073@hoothoot
Re: First steps towards source-only uploads
Hi, Quoting Charles Plessy (2014-08-06 07:41:40) what do you think about the patch I sent to the Policy, for describing the syntax of the current optional fields of the Packages-List field ? Do you think that modifications are needed ? Would you second it ? https://bugs.debian.org/756835 Have a nice day, I had worded it a bit differently: diff --git a/policy.sgml b/policy.sgml index fbbe4a3..840951c 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3824,10 +3824,17 @@ Checksums-Sha256: the source package, considering every architecture. The first line of the field value is empty. Each one of the next lines describes one binary package, by listing its name, type, section and priority - separated by spaces. Fifth and subsequent space-separated items - may be present and parsers must allow them. See the - qref id=f-Package-TypePackage-Type/qref field for a list of - package types. + separated by spaces. + See the qref id=f-Package-TypePackage-Type/qref field for a + list of package types. + Fifth and subsequent space-separated items are key/value pairs of + the form ttkey=value1,value2/tt. The currently used keys are + the ttarch/tt key which lists the architectures a binary + package builds for and the ttprofile/tt key which lists the + build profiles a binary package builds in. + footnoteThe key/value syntax for all fields after the fourth was + introduced in prgndpkg/prgn version tt1.17.7/tt in + emJessie/em./footnote /p /sect1 cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806060316.19236.55079@hoothoot
Re: First steps towards source-only uploads
Ansgar Burchardt ans...@debian.org (2014-08-01): as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. We will allow not including arch:all packages in uploads once we have sorted out how to get them built. Source-only uploads to NEW might also come in the future, but dak needs a bit more work to be able to handle them. This is absolutely awesome. Many many thanks. Mraw, KiBi. signature.asc Description: Digital signature
Re: First steps towards source-only uploads
hi can you please take this adress off the list ? many thanks! LG Von meinem iPod gesendet Am 01.08.2014 um 09:37 schrieb Ansgar Burchardt ans...@debian.org: Hi, as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. We will allow not including arch:all packages in uploads once we have sorted out how to get them built. Source-only uploads to NEW might also come in the future, but dak needs a bit more work to be able to handle them. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/896d20a3-161c-4fd6-8c4e-5a6dad258...@gmx.ch
Re: First steps towards source-only uploads
Hi, Quoting Ansgar Burchardt (2014-08-01 12:25:05) I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. The field started out with the binary package name, type, section and priority. For bootstrapping it is necessary to know for which architectures and build profiles a binary package builds without having access to the unpacked source package but just from looking at the Packages/Sources files. Thus this information was added as optional fields. Every field that comes after the first four will be of the form key=value. The arch information will always be printed and the profile field only for a build with a build profile. Guillem explains the new field here: https://lists.debian.org/20140421140417.ga1...@gaara.hadrons.org cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140806051637.19236.26348@hoothoot
Re: First steps towards source-only uploads
Control: retitle -1 Extension of the syntax of the Packages-List field. Le Wed, Aug 06, 2014 at 07:16:37AM +0200, Johannes Schauer a écrit : The field started out with the binary package name, type, section and priority. For bootstrapping it is necessary to know for which architectures and build profiles a binary package builds without having access to the unpacked source package but just from looking at the Packages/Sources files. Thus this information was added as optional fields. Every field that comes after the first four will be of the form key=value. The arch information will always be printed and the profile field only for a build with a build profile. Guillem explains the new field here: Hi Johannes, Ansgar, Guillem, and everybody, what do you think about the patch I sent to the Policy, for describing the syntax of the current optional fields of the Packages-List field ? Do you think that modifications are needed ? Would you second it ? https://bugs.debian.org/756835 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 Archive: https://lists.debian.org/20140806054139.ga13...@falafel.plessy.net
Re: First steps towards source-only uploads
Filed a few bug reports on this: #756975 dpkg-dev: dpkg-genchanges option to only include arch:all debs #756978 dgit: .tar-less push The possibility of the second one is .. pretty amazing! -- see shy jo signature.asc Description: Digital signature
Re: First steps towards source-only uploads
On 08/01/2014 06:15 PM, Holger Levsen wrote: Hi Ansgar, On Freitag, 1. August 2014, Ansgar Burchardt wrote: as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: [...] whoooh! Yay! Thanks a lot to those who made this real! This is *great* news! cheers, Holger Likewise! Thanks for working on this. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ddf708.6070...@debian.org
Re: First steps towards source-only uploads
Hi, Kurt Roeckx k...@roeckx.be writes: Please also make sure you rename the changes files to not conflict with the .changes files the buildd is going to use. As of today, that's no longer required. :) Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zjfl46kd@deep-thought.43-1.org
Re: First steps towards source-only uploads
Ansgar Burchardt wrote: * Architecture-independent (arch:all) packages must be included in uploads. That can be read 2 different ways.. I hope it means: If you have an arch:all, you have to upload it, but if there is none, you can upload with no .debs. Is that correct? -- see shy jo, still on dialup, so could probably find excuses to add arch:all to most of his packages if he needed to.. signature.asc Description: Digital signature
Re: First steps towards source-only uploads
On Sun, Aug 3, 2014 at 8:13 PM, Joey Hess jo...@debian.org wrote: Ansgar Burchardt wrote: * Architecture-independent (arch:all) packages must be included in uploads. That can be read 2 different ways.. I hope it means: If you have an arch:all, you have to upload it, but if there is none, you can upload with no .debs. Is that correct? Yes, that's correct. You can upload just the source package itself if it doesn't build any arch-indep packages. Regards, Vincent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caczd_tcxlluqd2p7dgamboh38wqsl4okmpt9f15j7rxgveh...@mail.gmail.com
Bug#756835: First steps towards source-only uploads
Package: debian-policy Severity: wishlist Version: 3.9.5.0 Le Fri, Aug 01, 2014 at 12:25:05PM +0200, Ansgar Burchardt a écrit : On 08/01/2014 12:17, martin f krafft wrote: also sprach Paul Wise p...@debian.org [2014-08-01 11:33 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. Hi Ansgar, Martin, and Policy Editors, here is a proposed update for the description of the Package-List field in the Policy's section 5.6.27. (patch attached). For the busy people, here is the current content of §5.6.27–8. - 5.6.27 Package-List Multiline field listing all the packages that can be built from the source package, considering every architecture. The first line of the field value is empty. Each one of the next lines describes one binary package, by listing its name, type, section and priority separated by spaces. Fifth and subsequent space-separated items may be present and parsers must allow them. See the Package-Type field for a list of package types. 5.6.28 Package-Type Simple field containing a word indicating the type of package: deb for binary packages and udeb for micro binary packages. Other types not defined here may be indicated. In source package control files, the Package-Type field should be omitted instead of giving it a value of deb, as this value is assumed for paragraphs lacking this field. - Everybody's suggestions are welcome ! Have a nice week-end, and big thank you to Ansgar and the other FTP Masters for the source-only uploads ! -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan From b1aa1bf72723e4594557f9898da97afe23f0c900 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sat, 2 Aug 2014 19:30:57 +0900 Subject: [PATCH] =?UTF-8?q?Document=20the=20=E2=80=98arch=E2=80=99=20and?= =?UTF-8?q?=20=E2=80=98profile=E2=80=99=20options=20in=20the=20Package-Lis?= =?UTF-8?q?t=20field.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- policy.sgml | 8 1 file changed, 8 insertions(+) diff --git a/policy.sgml b/policy.sgml index ae9d173..33c4f1a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3826,6 +3826,14 @@ Checksums-Sha256: qref id=f-Package-TypePackage-Type/qref field for a list of package types. /p + p + The optional fields currently in use add informations related to +architectures build profiles, with a syntax such as +ttname=value1,value2/tt and names ttarch/tt and +ttprofile/ttfootnote + They were introduced in prgndpkg/prgn version + tt1.17.7/tt in emJessie/em/footnote. + /p /sect1 sect1 id=f-Package-Type -- 2.0.1
Re: First steps towards source-only uploads
01.08.2014 11:37, Ansgar Burchardt wrote: Hi, as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. Is there an easy way to produce such uploads? Thanks! /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53db47b6.7010...@msgid.tls.msk.ru
Re: First steps towards source-only uploads
On Fri, 01 Aug 2014, Michael Tokarev wrote: 01.08.2014 11:37, Ansgar Burchardt wrote: as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. Is there an easy way to produce such uploads? If your source builds arch-all packages, this has actually worked for a long time already. The changestool utility from the reprepro package can be used to manipulate a .changes file as needed. For instance, the way my tor-package build machinery works, I end up with a source-only .changes file (created by dpkg-genchanges -S) and then add the .all package using changestool adddeb. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801080951.gl30...@anguilla.noreply.org
Re: First steps towards source-only uploads
On Fri, Aug 1, 2014, at 09:54, Michael Tokarev wrote: 01.08.2014 11:37, Ansgar Burchardt wrote: Hi, as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. Is there an easy way to produce such uploads? Build binary packages as usual, but sed-out _(amd64|i386).deb from resulting .changes before signing it. Ondrej -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1406880972.2158370.147993346.05a1a...@webmail.messagingengine.com
Re: First steps towards source-only uploads
also sprach Ansgar Burchardt ans...@debian.org [2014-08-01 09:37 +0200]: as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: Wow. This is great news! Thank you so much for your perseverance. * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems without a god, life is only a matter of opinion. -- douglas adams digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: First steps towards source-only uploads
On Fri, Aug 1, 2014 at 4:38 PM, martin f krafft wrote: also sprach Ansgar Burchardt ans...@debian.org [2014-08-01 09:37 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. -- bye, pabs https://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 Archive: https://lists.debian.org/CAKTje6Eijt3Eft8ZJv6=wa3gckioqpvfnasqsan9eobmfmn...@mail.gmail.com
Re: First steps towards source-only uploads
also sprach Paul Wise p...@debian.org [2014-08-01 11:33 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. I want to understand purpose and syntax of this new field. -- .''`. martin f. krafft madduck@d.o @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems quidquid latine dictum sit, altum viditur. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: First steps towards source-only uploads
Hi Ansgar, On Freitag, 1. August 2014, Ansgar Burchardt wrote: as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: [...] whoooh! Yay! Thanks a lot to those who made this real! This is *great* news! cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: First steps towards source-only uploads
On 08/01/2014 12:17, martin f krafft wrote: also sprach Paul Wise p...@debian.org [2014-08-01 11:33 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. Ansgar [1] This is currently broken in dak, but teaching process-new to handle source-only uploads will also address this. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53db6b01.70...@debian.org
Re: First steps towards source-only uploads
Thanks a lot; this is great news! Richard Sent by mobile; excuse my brevity.
Re: First steps towards source-only uploads
On Fri, Aug 01, 2014 at 10:16:12AM +0200, Ondrej Surý wrote: On Fri, Aug 1, 2014, at 09:54, Michael Tokarev wrote: 01.08.2014 11:37, Ansgar Burchardt wrote: Hi, as a first step towards source-only uploads, the archive will now accept source-only uploads provided the following conditions are met: * The source package is not NEW and does not build NEW binaries. * Architecture-independent (arch:all) packages must be included in uploads. Is there an easy way to produce such uploads? Build binary packages as usual, but sed-out _(amd64|i386).deb from resulting .changes before signing it. Please also make sure you rename the changes files to not conflict with the .changes files the buildd is going to use. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801205857.ga9...@roeckx.be
Re: First steps towards source-only uploads
* Kurt Roeckx k...@roeckx.be, 2014-08-01, 22:58: Build binary packages as usual, but sed-out _(amd64|i386).deb from resulting .changes before signing it. Please also make sure you rename the changes files to not conflict with the .changes files the buildd is going to use. Can we fix dak not to care about names of *.changes? These names are not cryptographically signed, so they shouldn't be trusted anyway. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801215149.ga8...@jwilk.net
