Re: Bug#1052004: libcbor: requires source-only upload to transition
Hi Vincent On 2023-09-15 23:29:27 +0200, Vincent Bernat wrote: > On 2023-09-15 21:04, Sebastian Ramacher wrote: > > Source: libcbor > > Version: 0.10.2-1 > > Severity: serious > > X-Debbugs-Cc: sramac...@debian.org > > > > https://qa.debian.org/excuses.php?package=libcbor > > > > Issues preventing migration: > > > > Not built on buildd: arch amd64 binaries uploaded by bernat > > Not built on buildd: arch all binaries uploaded by bernat, a new > > source-only upload is needed to allow migration > > What's the status of throwing away the binaries when doing a non-source-only > upload? This is a major pain point for me. You upload the package a first > time as a source-only upload and get an error 15 minutes later telling you > it's NEW and you have to do a binary upload. Then, it gets accepted and you > need another source-only upload. Following the recommended transition process also works around the problem: https://wiki.debian.org/Teams/ReleaseTeam/Transitions I'd appreciate a source-only upload so that we can complete this transition. Cheers -- Sebastian Ramacher
Re: Re: Bug#1052004: libcbor: requires source-only upload to transition
It would be lovely to get this enabled! It's a pain point for me also, on occasion. -Steve
Re: Bug#1052004: libcbor: requires source-only upload to transition
On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote: > What's the status of throwing away the binaries when doing a non-source-only > upload? it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess that nowish would be a good time to enable it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Do yo ever think about how capitalism is forcing us to work up until the eminent extinction of our species as the earth heats to an unlivable temperature? (@aishamadeit) signature.asc Description: PGP signature
Re: Bug#1052004: libcbor: requires source-only upload to transition
On 2023-09-15 21:04, Sebastian Ramacher wrote: Source: libcbor Version: 0.10.2-1 Severity: serious X-Debbugs-Cc: sramac...@debian.org https://qa.debian.org/excuses.php?package=libcbor Issues preventing migration: Not built on buildd: arch amd64 binaries uploaded by bernat Not built on buildd: arch all binaries uploaded by bernat, a new source-only upload is needed to allow migration What's the status of throwing away the binaries when doing a non-source-only upload? This is a major pain point for me. You upload the package a first time as a source-only upload and get an error 15 minutes later telling you it's NEW and you have to do a binary upload. Then, it gets accepted and you need another source-only upload.
Re: Review on packages blocked from testing migration due to non-source-only upload
Hi, 在 2020-10-21星期三的 19:34 +0200，Paul Gevers写道： > Hi Boyuan, > > On 21-10-2020 18:45, Boyuan Yang wrote: > > Looking into https://release.debian.org/britney/update_excuses.html > > and > > searching "source-only", you can find tens of (if not hundreds of) > > packages that did not migrate to Debian Testing solely because of > > having a non-source-only upload [1]. This especially applies to > > arch:all packages since binNMU is still not possible yet. > > > > Since we are now months before the projected release freeze, it > > might > > be a good time to review all those affected packages and make sure > > no > > package misses the release solely due to that. > > If packages are already in testing, they'll have bugs [1] reported if > the situation lasts longer than 60 days. Checking [1], there's not > much > packages in that state. > > [1] > https://udd.debian.org/dev/bugs.cgi?release=bullseye=ign=7=7=only=out-of-sync=release.debian.org%40packages.debian.org=1=1=1=1=lastupload_s=asc=html#results There are also multiple packages that are not currently in Testing but did not migrate solely due to non-buildd binaries. This especially applies to those packages maintained by non-DD / non-DM where a package sponsorship happened to pass NEW queue but later in lack of a following source-only upload. This is happening every now and then and consists of a considerable amount of packages stuck in Unstable. Also I have observed the following scenario multiple times: 1. Package A's latest upload was a non-source-only upload before Debian 10 release 2. One of the package's dependency(B) becomes RC-buggy and removed from Testing 3. Package A got removed from Testing together with B 4. The RC bug of package B got fixed and the fix enters Testing 5. Package A won't migrate to Testing due to non-source-only upload This is actually reasonable though kind of unexpected. What I'm proposing is to go through all packages in you hand (and ideally those on the testing migration excuse page) and make sure such fallout won't impact the next release. Thanks, Boyuan signature.asc Description: This is a digitally signed message part
Re: Review on packages blocked from testing migration due to non-source-only upload
Hi Boyuan, On 21-10-2020 18:45, Boyuan Yang wrote: > Looking into https://release.debian.org/britney/update_excuses.html and > searching "source-only", you can find tens of (if not hundreds of) > packages that did not migrate to Debian Testing solely because of > having a non-source-only upload [1]. This especially applies to > arch:all packages since binNMU is still not possible yet. > > Since we are now months before the projected release freeze, it might > be a good time to review all those affected packages and make sure no > package misses the release solely due to that. If packages are already in testing, they'll have bugs [1] reported if the situation lasts longer than 60 days. Checking [1], there's not much packages in that state. Paul [1] https://udd.debian.org/dev/bugs.cgi?release=bullseye=ign=7=7=only=out-of-sync=release.debian.org%40packages.debian.org=1=1=1=1=lastupload_s=asc=html#results signature.asc Description: OpenPGP digital signature
Review on packages blocked from testing migration due to non-source-only upload
Hi all, Looking into https://release.debian.org/britney/update_excuses.html and searching "source-only", you can find tens of (if not hundreds of) packages that did not migrate to Debian Testing solely because of having a non-source-only upload [1]. This especially applies to arch:all packages since binNMU is still not possible yet. Since we are now months before the projected release freeze, it might be a good time to review all those affected packages and make sure no package misses the release solely due to that. Thanks, Boyuan Yang [1] https://wiki.debian.org/SourceOnlyUpload signature.asc Description: This is a digitally signed message part
Re: Source only upload
On Tue, Jul 21, 2020 at 9:28 AM Wouter Verhelst wrote: > The reason we don't do this is because of bootstrapping: some tools > require themselves to build, so you need to cross-build them on a > different architecture, upload the cross-built binary, get an exception > for that upload, and then re-upload the same version so it gets built on > the buildds. If you have a solution for that issue that allows not > accepting bootstrapped binaries in unstable, then by all means suggest > it. Otherwise I think the current situation is the best possible > solution given the requirements that exist. The solution is to do the sourceful upload without binaries, build the binaries and upload the binaries without the source in the second upload. Or just a .changes field to keep binaries like Mattia suggests. Or as Johannes suggests, we require every package to have a proper bootstrap process without cyclic or self build-deps, which the buildds could then do via build profiles. > Having said that, a warning by dupload or dak that you're uploading > binaries to unstable and is this really what you want would definitely > seem appropriate. That already exists for dupload IIRC, not sure about dput/dput-ng though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Source only upload
Quoting mat...@debian.org (2020-07-21 11:35:30) > On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote: > > The reason we don't do this is because of bootstrapping: some tools > > require themselves to build, so you need to cross-build them on a > > different architecture, upload the cross-built binary, get an exception > > for that upload, and then re-upload the same version so it gets built on > > the buildds. If you have a solution for that issue that allows not > > accepting bootstrapped binaries in unstable, then by all means suggest > > it. Otherwise I think the current situation is the best possible > > solution given the requirements that exist. > > All considering, an extra, special field in the .changes that instruct > dak to just not throw away the binaries just for that specific upload would > be more than enough to do what you say. https://wiki.debian.org/BuildProfileSpec#The_Built-For-Profiles_field Built-For-Profiles: nopython Ideally, a source-only upload would happen, some component would analyze the build-profiles annotation and figure out in which order to build packages so that build-dependency cycles are broken by doing non-default builds with some profile active, and then building the packages accordingly. Since that component is missing, dak could accept uploads of a changes file that contains the instructions with which build profile to build a package, so that some binary packages are generated that allow the full build in a second pass. Thanks! cheers, josch signature.asc Description: signature
Re: Source only upload
On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote: > The reason we don't do this is because of bootstrapping: some tools > require themselves to build, so you need to cross-build them on a > different architecture, upload the cross-built binary, get an exception > for that upload, and then re-upload the same version so it gets built on > the buildds. If you have a solution for that issue that allows not > accepting bootstrapped binaries in unstable, then by all means suggest > it. Otherwise I think the current situation is the best possible > solution given the requirements that exist. All considering, an extra, special field in the .changes that instruct dak to just not throw away the binaries just for that specific upload would be more than enough to do what you say. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Source only upload
On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote: > On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote: > > Personally, I think we should discard binaries from all sourceful > > uploads and only accept binaries from binary-only uploads such as the > > uploads done by the buildds. > > The reason we don't do this is because of bootstrapping: some tools > require themselves to build, so you need to cross-build them on a > different architecture, upload the cross-built binary, get an exception > for that upload, and then re-upload the same version so it gets built on Actually, you don't need an exception for that upload, but it needs to go to unstable (and not testing). Sorry for the confusion, my brain was a bit foggy apparently ;-) -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Source only upload
On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote: > Personally, I think we should discard binaries from all sourceful > uploads and only accept binaries from binary-only uploads such as the > uploads done by the buildds. The reason we don't do this is because of bootstrapping: some tools require themselves to build, so you need to cross-build them on a different architecture, upload the cross-built binary, get an exception for that upload, and then re-upload the same version so it gets built on the buildds. If you have a solution for that issue that allows not accepting bootstrapped binaries in unstable, then by all means suggest it. Otherwise I think the current situation is the best possible solution given the requirements that exist. Having said that, a warning by dupload or dak that you're uploading binaries to unstable and is this really what you want would definitely seem appropriate. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Source only upload
On Wed, Jul 15, 2020 at 01:33:10PM +, Paul Wise wrote: > > > So we have the buildds installing packages from snapshot.d.o based on > > > what the maintainer built the package with? > > no(t yet?) > I'm confused, Thomas proposed that packages are rejected unless the > buildd binaries are identical to the maintainer binaries. So the > buildds would need to run debrebuild and install build-deps from > snapshot.debian.org instead of from the main archive, in order to > avoid build-dep version skew between maintainer and buildd binaries. > Correct? yes. (It's a proposal indeed. The above quote to me sounded like you were trying to describe reality.) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Source only upload
On Wed, Jul 15, 2020 at 12:45 PM Holger Levsen wrote: > On Wed, Jul 15, 2020 at 12:41:00PM +, Paul Wise wrote: > > So we have the buildds installing packages from snapshot.d.o based on > > what the maintainer built the package with? > > no(t yet?) > > also: s#what the maintainer built the package with#what the packages was > built with# I'm confused, Thomas proposed that packages are rejected unless the buildd binaries are identical to the maintainer binaries. So the buildds would need to run debrebuild and install build-deps from snapshot.debian.org instead of from the main archive, in order to avoid build-dep version skew between maintainer and buildd binaries. Correct? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Source only upload
On Wed, Jul 15, 2020 at 12:41:00PM +, Paul Wise wrote: > So we have the buildds installing packages from snapshot.d.o based on > what the maintainer built the package with? no(t yet?) also: s#what the maintainer built the package with#what the packages was built with# -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Source only upload
On Wed, Jul 15, 2020 at 11:22 AM Holger Levsen wrote: > debrebuild from src:devscripts can create an sbuild commandline to install > exactly the build depends which were installed in the build which is about > to be rebuild, using the data from the .buildinfo file. So we have the buildds installing packages from snapshot.d.o based on what the maintainer built the package with? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Source only upload
On Wed, Jul 15, 2020 at 02:37:26AM +, Paul Wise wrote: > On Tue, Jul 14, 2020 at 4:06 PM Thomas Goirand wrote: > > Better: we must mandate binary uploads, rebuild them, and make sure they > > are reproducible. Then get the buildd upload the binary they build (or > > the one from the uploader, since that's the same thing...). > > > > When the package isn't reproducible: reject the package and provide a > > link to diffoscope. :) > That would be nice, but I wonder if build-dep version skew will make > it infeasible. debrebuild from src:devscripts can create an sbuild commandline to install exactly the build depends which were installed in the build which is about to be rebuild, using the data from the .buildinfo file. -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Source only upload
On Tue, Jul 14, 2020 at 4:06 PM Thomas Goirand wrote: > Better: we must mandate binary uploads, rebuild them, and make sure they > are reproducible. Then get the buildd upload the binary they build (or > the one from the uploader, since that's the same thing...). > > When the package isn't reproducible: reject the package and provide a > link to diffoscope. :) That would be nice, but I wonder if build-dep version skew will make it infeasible. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Source only upload
Hi Michael, > I just fell into the trap (again) and uploaded a binary package instead of > sources only. We don't want the binaries to be uploaded, that much I get, but > could anyone please explain to me, why we still accept binary uploads and why > no tool in the whole chain gives as much as a warning, let alone is configured > to do the right thing? I've changed my workflow so I won't build binary packages all, that is only done by the salsa CI. I regularly forget that NEW need binary packages, but those few cases don't matter much. I know its just a workaround, but it works well for me. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Source only upload
On 7/14/20 3:55 PM, Michael Meskes wrote: > Hi, > > I just fell into the trap (again) and uploaded a binary package instead of > sources only. We don't want the binaries to be uploaded, that much I get, but > could anyone please explain to me, why we still accept binary uploads and why > no tool in the whole chain gives as much as a warning, let alone is configured > to do the right thing? > > If I missed something, please point me into the right direction. Sure! The sources are here: https://salsa.debian.org/debian/dput-ng/ Feel free to produce a patch to display a huge warning, together with a --sure-I-know-what-I-am-doing flag... :P Thomas Goirand (zigo)
Re: Source only upload
On 7/14/20 4:21 PM, Paul Wise wrote: > On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote: > >> I just fell into the trap (again) and uploaded a binary package instead of >> sources only. We don't want the binaries to be uploaded, that much I get, but >> could anyone please explain to me, why we still accept binary uploads and why >> no tool in the whole chain gives as much as a warning, let alone is >> configured >> to do the right thing? > > Looks like the following bugs aren't yet filed: > > sbuild/pbuilder: default to --source-only-changes > dput/dput-ng/dupload: default to _source.changes except for NEW or > when the _source.changes file is missing/invalid. > > Making dak discard binaries in NEW sourceful uploads is in progress: > > https://lists.debian.org/msgid-search/27641434-e45a-404f-254f-daea89916...@debian.org > > Personally, I think we should discard binaries from all sourceful > uploads and only accept binaries from binary-only uploads such as the > uploads done by the buildds. Better: we must mandate binary uploads, rebuild them, and make sure they are reproducible. Then get the buildd upload the binary they build (or the one from the uploader, since that's the same thing...). When the package isn't reproducible: reject the package and provide a link to diffoscope. :) Cheers, Thomas Goirand (zigo) P.S: Just my 2 cents, since I don't have time to implement any of this myself ...
Re: Source only upload
On Tue, Jul 14, 2020 at 2:56 PM Michael Meskes wrote: > > Hi, > > I just fell into the trap (again) and uploaded a binary package instead of > sources only. We don't want the binaries to be uploaded, that much I get, but > could anyone please explain to me, why we still accept binary uploads and why > no tool in the whole chain gives as much as a warning, let alone is configured > to do the right thing? I have created a bash alias which does "debsign -S" after I was bitten by this once. -- Regards Sudip
Re: Source only upload
> Personally, I think we should discard binaries from all sourceful > uploads and only accept binaries from binary-only uploads such as the > uploads done by the buildds. > > https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org Agreed, that would be the easiest solution, at least the easiest I can think of. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Source only upload
> You still need to produce binary packages unfortunately if you > upload > something to NEW or binary-NEW. Sure, but that could be checked for as well. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Source only upload
On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote: > On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote: > > > I just fell into the trap (again) and uploaded a binary package instead of > > sources only. We don't want the binaries to be uploaded, that much I get, > > but > > could anyone please explain to me, why we still accept binary uploads and > > why > > no tool in the whole chain gives as much as a warning, let alone is > > configured > > to do the right thing? > > Looks like the following bugs aren't yet filed: > > sbuild/pbuilder: default to --source-only-changes > dput/dput-ng/dupload: default to _source.changes except for NEW or > when the _source.changes file is missing/invalid. I don't think we can detect binary-NEW, though just checking whether there is only one changelog entry will already be useful. -- WBR, wRAR signature.asc Description: PGP signature
Re: Source only upload
On Tue, Jul 14, 2020 at 15:55, Michael Meskes wrote: Hi, I just fell into the trap (again) and uploaded a binary package instead of sources only. We don't want the binaries to be uploaded, that much I get, but could anyone please explain to me, why we still accept binary uploads and why no tool in the whole chain gives as much as a warning, let alone is configured to do the right thing? If I missed something, please point me into the right direction. We use build-and-upload script from https://salsa.debian.org/ruby-team/meta/ in ruby team which does the right thing. I use it for other packages as well. It runs sbuild, autopkgtest and also optionally same for all reverse (build) dependencies. Very useful for library updates and transitions.
Re: Source only upload
On Tue, 14 Jul 2020, Michael Meskes wrote: I just fell into the trap (again) and uploaded a binary package instead of sources only. We don't want the binaries to be uploaded, that much I get, but could anyone please explain to me, why we still accept binary uploads and why no tool in the whole chain gives as much as a warning, let alone is configured to do the right thing? If I missed something, please point me into the right direction. You still need to produce binary packages unfortunately if you upload something to NEW or binary-NEW. Scott
Re: Source only upload
On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote: > I just fell into the trap (again) and uploaded a binary package instead of > sources only. We don't want the binaries to be uploaded, that much I get, but > could anyone please explain to me, why we still accept binary uploads and why > no tool in the whole chain gives as much as a warning, let alone is configured > to do the right thing? Looks like the following bugs aren't yet filed: sbuild/pbuilder: default to --source-only-changes dput/dput-ng/dupload: default to _source.changes except for NEW or when the _source.changes file is missing/invalid. Making dak discard binaries in NEW sourceful uploads is in progress: https://lists.debian.org/msgid-search/27641434-e45a-404f-254f-daea89916...@debian.org Personally, I think we should discard binaries from all sourceful uploads and only accept binaries from binary-only uploads such as the uploads done by the buildds. https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org -- bye, pabs https://wiki.debian.org/PaulWise
Source only upload
Hi, I just fell into the trap (again) and uploaded a binary package instead of sources only. We don't want the binaries to be uploaded, that much I get, but could anyone please explain to me, why we still accept binary uploads and why no tool in the whole chain gives as much as a warning, let alone is configured to do the right thing? If I missed something, please point me into the right direction. Thanks, Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes dot org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Re: Source-only upload and build profiles
On Fri, 17 Jan 2020 at 18:08:59 +0530, Pirate Praveen wrote: > I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild -s > --source-only-changes That doesn't mean what you think it does. My understanding is that the profiles only affect the binaries that *you* built, which were omitted from the source-only .changes anyway. Built-For-Profiles: nocheck is information about the binaries you built not being the "official" version, not a request to buildds to build this source code with different options. > This is required because node-uglifyjs-webpack-plugin has dependency on > webpack (it actually requires files from webpack). I believe the intention is that you might use build-profiles to bootstrap your own build environment, but when you upload binaries to the real Debian archive, they are always meant to be built *without* profiles. So if you have two packages, foo Build-Depends: bar and bar Build-Depends: foo , you'd have to do something like this: - build foo with DEB_BUILD_PROFILES=nocheck - build bar normally - rebuild foo normally - delete the temporary DEB_BUILD_PROFILES=nocheck version of foo (don't upload it) - upload either foo or bar with binaries (built with no profiles) - upload the other package, with or without binaries (This matters more for profiles that might alter the content of the packages, like nodoc, stage1, stage2, or any profile that is not "safe".) smcv
Source-only upload and build profiles
Hi, I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild -s --source-only-changes https://tracker.debian.org/news/1094664/accepted-node-webpack-4300-2-source-into-experimental/ But it seems the buildd did not consider Built-For-Profiles: nocheck in the source.changes file. I think I will have to do a binary included upload, but it'd be nice if buildd can support build profiles. This is required because node-uglifyjs-webpack-plugin has dependency on webpack (it actually requires files from webpack). Thanks Praveen
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/11/19 6:30 PM, Theodore Y. Ts'o wrote: > Yes, and that's why I use debian/master instead of debian/buster or > debian/bullseye. :-) > > When I do create debian/buster (once it became the stable branch), the > first thing I did after I branched off debian/buster from > debian/master was to edit debian/gbp.conf was to have: > > debian-branch=debian/buster > > I only do this when I need to do the first stable backport of a > serious/security bug, such that I have to create the debian/buster > branch in the first place. So it hasn't been all that annoying for > me. +1 I do pretty much similar things in my repositories, and I neither want people to mess with the way I choose branch names nor do NMUers want do have to figure out which branch to use for what. debian/gbp.conf is perfect for that, so please maintain it. It is very easy! -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/14/19 1:59 AM, Jeremy Bicha wrote: > Let me try to be more specific. Many packages are maintained by people > who use gbp. Many packages have pristine-tar branches but do not have > "pristine-tar = True" set. When I work on one of these packages (and I > work on many packages with many maintainers), I need to have > "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want > to work on an OpenStack package, I have to change my user config to > set "pristine-tar = False". No you don't. The only think you need is the orig tarball form the archive in your build path. Cheers, Thomas Goirand (zigo)
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Wed, 13 Nov 2019 at 19:59:07 -0500, Jeremy Bicha wrote: > Let me try to be more specific. Many packages are maintained by people > who use gbp. Many packages have pristine-tar branches but do not have > "pristine-tar = True" set. When I work on one of these packages (and I > work on many packages with many maintainers), I need to have > "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want > to work on an OpenStack package, I have to change my user config to > set "pristine-tar = False". This is a very manual process and I'm > likely to make a mistake. I think it's worth emphasizing that the options for which this is valuable are exactly the options that affect interoperability with other maintainers, or to put it another way, that affect what you commit. For example, pristine-tar, debian-branch, upstream-branch and upstream-vcs-tag affect what `gbp import-orig` does, so they need to be the same for anyone who plans to import new upstream releases. I think that means they make sense in d/gbp.conf for the reasons Jeremy stated. If you prefer to use ignore-branch instead of debian-branch then that's your choice, or perhaps your team's, and if you use that option then maybe you don't need debian-branch; but when you import a new upstream release you're not on the upstream branch, so `gbp import-orig` still needs to know where the upstream-branch is. Conversely, tarball-dir, export-dir and builder are personal preference or local system configuration, and should not appear in d/gbp.conf, only in ~/.gbp.conf or .git/gbp.conf. The first few packages I maintained with git in Debian did have tarball-dir and export-dir in d/gbp.conf, mimicking the way svn-buildpackage's directory properties worked; but that was a bug, which I believe has now been fixed in everything I still maintain. smcv
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand wrote: > On 11/11/19 12:50 PM, Jeremy Bicha wrote: > > It is absolutely not possible to set the correct > > pristine-tar=True/False in ~/.gbp.conf to work with your packages > > (which avoid pristine-tar) and the vast majority of gbp packages in > > Debian which do use pristine-tar. Those settings are specific to the > > workflow for that repo, and everyone using that repo needs to use > > those same settings to avoid issues. > > I don't think what you wrote above is correct. None of the options you > mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it > will assume that we're using an upstream tag, which is fine. > ... > Besides this, nobody is forced to use gbp. Just typing "sbuild" to build > a package is also perfectly valid. So why adding preferences for one set > of tooling, when there's many alternatives? It doesn't make sense. Let me try to be more specific. Many packages are maintained by people who use gbp. Many packages have pristine-tar branches but do not have "pristine-tar = True" set. When I work on one of these packages (and I work on many packages with many maintainers), I need to have "pristine-tar = True" set in my ~/.gbp.conf. However, when I then want to work on an OpenStack package, I have to change my user config to set "pristine-tar = False". This is a very manual process and I'm likely to make a mistake. Ideally, packages maintained by someone who wants to consistently use pristine-tar will have that set in debian/gbp.conf and the minority of maintainers who don't will have that set in debian/gbp.conf too. While you could use sbuild to build gnome-calculator for instance, you do have to use gbp to **maintain** gnome-calculator -- especially when packaging new versions. That is because gnome-calculator is team-maintained by the Debian GNOME team and we have guidelines for how our packages are maintained [1]. To make life easier for contributors, we enforce as many of those guidelines as possible in debian/gbp.conf. Similarly, you have guidelines for how OpenStack packaging updates and bugfixes are handled and it seems to me like it would make a whole lot more sense for you to explicitly "forbid" pristine-tar from being used in your packages, as long as you are the maintainer and you believe that pristine-tar is unsuitable for those packages. [1] https://wiki.debian.org/Gnome/Git Thanks, Jeremy Bicha
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/13/19 1:53 PM, Andreas Tille wrote: > Except for not agreeing with your opinion about pristine-tar I agree that > debian/gbp.conf is frequently not very helpful and flooded with unneeded > options sometimes. It really makes sense to use ~/.gbp.conf instead. This was the single and only point I was trying to make, and I wasn't trying to convince anyone about anything else! :) Cheers, Thomas Goirand (zigo)
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Tue, Nov 12, 2019 at 11:23:08AM +0100, Thomas Goirand wrote: > > If you're rebuilding a package which is already in the archive, you're > supposed to take the .orig.tar.xz from the archive, and if not, you're > supposed to generate it with git archive (or with the shortcut for that > command: ./debian/rules gen-orig-xz). Either ways, you don't need to set > pristine-tar to do that. ... but there are teams that rely successfully on pristine-tar which solves the problem you describe at least to my experience perfectly. > I also think this should become the default too: > no-create-orig = True Please don't. > because otherwise, you easily get a generated wrong file, which will not > be the same as the archive one (because pristine-tar is broken in many > ways, as many of us know already). >From time to time I hear this statement. I can confirm that in all teams I'm working on pristine-tar belongs to the team policy and I never experienced in those > 2000 packages I've touched any problem with this. For me this makes some statistically relevant set which makes me believe that blaming pristine-tar to be broken in many ways is exaggerating and should not become a reason to force standard options that would really break pristine-tar. > Besides this, nobody is forced to use gbp. Just typing "sbuild" to build > a package is also perfectly valid. So why adding preferences for one set > of tooling, when there's many alternatives? It doesn't make sense. Except for not agreeing with your opinion about pristine-tar I agree that debian/gbp.conf is frequently not very helpful and flooded with unneeded options sometimes. It really makes sense to use ~/.gbp.conf instead. Kind regards Andreas. -- http://fam-tille.de
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/11/19 12:50 PM, Jeremy Bicha wrote: > On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: >> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: >>> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: Please, *never* do that. It's generally a very bad idea to write anything to debian/gbp.conf. It's as if you were adding your text editor preferences in the package. Instead, please prefer writing in ~/.gbp.conf. >>> >>> I keep most of my git-buildpackage settings which are specific to my >>> developer environment in ~/.gbp.conf. However, there are some gbp >>> settings which are specific to the repository set up, and those I >>> think, IMHO, *are* appropriate for debian/gbp.conf. For example: >>> >>> [DEFAULT] >>> pristine-tar = True >>> upstream-tag='v%(version)s' >>> debian-branch=debian/master >> >> The first 2, yes. The last one, it's my opinion that it's useless, and >> that you only need it because "ignore-branch = True" isn't the default >> in git-buildpackage. It's ok as long as you always keep the same >> packagig branch, but if, like in my team, we need a new branch name >> every 6 months, and for 400+ repositories, then keeping the branch name >> declared in debian/gbp.conf becomes super annoying (as it forces one to >> change the "debian-branch" each time). > > Could you please add debian/gbp.conf back to your packages? As I > understand it, I think your preferred settings would look something > like this: > > [DEFAULT] > ignore-branch = True > pristine-tar = False > > [buildpackage] > sign-tags = True > > [dch] > multimaint-merge = True > > [import-orig] > upstream-tag = %(version)s > > [pq] > patch-numbers = False > > > > It is absolutely not possible to set the correct > pristine-tar=True/False in ~/.gbp.conf to work with your packages > (which avoid pristine-tar) and the vast majority of gbp packages in > Debian which do use pristine-tar. Those settings are specific to the > workflow for that repo, and everyone using that repo needs to use > those same settings to avoid issues. Hi Jeremy, I don't think what you wrote above is correct. None of the options you mentioned are mandatory. If GBP doesn't see the use of pristine-tar, it will assume that we're using an upstream tag, which is fine. If you're rebuilding a package which is already in the archive, you're supposed to take the .orig.tar.xz from the archive, and if not, you're supposed to generate it with git archive (or with the shortcut for that command: ./debian/rules gen-orig-xz). Either ways, you don't need to set pristine-tar to do that. So, as I wrote, the only single thing you need, is: ignore-branch = True and it is my view that it should be good to have it become the default. I also think this should become the default too: no-create-orig = True because otherwise, you easily get a generated wrong file, which will not be the same as the archive one (because pristine-tar is broken in many ways, as many of us know already). Besides this, nobody is forced to use gbp. Just typing "sbuild" to build a package is also perfectly valid. So why adding preferences for one set of tooling, when there's many alternatives? It doesn't make sense. Cheers, Thomas Goirand (zigo)
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote: > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were adding your text editor > >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > > > I keep most of my git-buildpackage settings which are specific to my > > developer environment in ~/.gbp.conf. However, there are some gbp > > settings which are specific to the repository set up, and those I > > think, IMHO, *are* appropriate for debian/gbp.conf. For example: > > > > [DEFAULT] > > pristine-tar = True > > upstream-tag='v%(version)s' > > debian-branch=debian/master > > The first 2, yes. The last one, it's my opinion that it's useless, and > that you only need it because "ignore-branch = True" isn't the default > in git-buildpackage. It's ok as long as you always keep the same > packagig branch, but if, like in my team, we need a new branch name > every 6 months, and for 400+ repositories, then keeping the branch name > declared in debian/gbp.conf becomes super annoying (as it forces one to > change the "debian-branch" each time). Yes, and that's why I use debian/master instead of debian/buster or debian/bullseye. :-) When I do create debian/buster (once it became the stable branch), the first thing I did after I branched off debian/buster from debian/master was to edit debian/gbp.conf was to have: debian-branch=debian/buster I only do this when I need to do the first stable backport of a serious/security bug, such that I have to create the debian/buster branch in the first place. So it hasn't been all that annoying for me. Cheers, - Ted
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote: > On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: > > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > >> > >> Please, *never* do that. It's generally a very bad idea to write > >> anything to debian/gbp.conf. It's as if you were adding your text editor > >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > > > I keep most of my git-buildpackage settings which are specific to my > > developer environment in ~/.gbp.conf. However, there are some gbp > > settings which are specific to the repository set up, and those I > > think, IMHO, *are* appropriate for debian/gbp.conf. For example: > > > > [DEFAULT] > > pristine-tar = True > > upstream-tag='v%(version)s' > > debian-branch=debian/master > > The first 2, yes. The last one, it's my opinion that it's useless, and > that you only need it because "ignore-branch = True" isn't the default > in git-buildpackage. It's ok as long as you always keep the same > packagig branch, but if, like in my team, we need a new branch name > every 6 months, and for 400+ repositories, then keeping the branch name > declared in debian/gbp.conf becomes super annoying (as it forces one to > change the "debian-branch" each time). Could you please add debian/gbp.conf back to your packages? As I understand it, I think your preferred settings would look something like this: [DEFAULT] ignore-branch = True pristine-tar = False [buildpackage] sign-tags = True [dch] multimaint-merge = True [import-orig] upstream-tag = %(version)s [pq] patch-numbers = False It is absolutely not possible to set the correct pristine-tar=True/False in ~/.gbp.conf to work with your packages (which avoid pristine-tar) and the vast majority of gbp packages in Debian which do use pristine-tar. Those settings are specific to the workflow for that repo, and everyone using that repo needs to use those same settings to avoid issues. On the other hand, there are some developer-level preferences like export-dir and "pbuilder = True". Those should not be in the repo's debian/gbp.conf but they should be in ~/.gbp.conf . Thanks, Jeremy Bicha
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote: > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: >> >> Please, *never* do that. It's generally a very bad idea to write >> anything to debian/gbp.conf. It's as if you were adding your text editor >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf. > > I keep most of my git-buildpackage settings which are specific to my > developer environment in ~/.gbp.conf. However, there are some gbp > settings which are specific to the repository set up, and those I > think, IMHO, *are* appropriate for debian/gbp.conf. For example: > > [DEFAULT] > pristine-tar = True > upstream-tag='v%(version)s' > debian-branch=debian/master The first 2, yes. The last one, it's my opinion that it's useless, and that you only need it because "ignore-branch = True" isn't the default in git-buildpackage. It's ok as long as you always keep the same packagig branch, but if, like in my team, we need a new branch name every 6 months, and for 400+ repositories, then keeping the branch name declared in debian/gbp.conf becomes super annoying (as it forces one to change the "debian-branch" each time). Cheers, Thomas Goirand (zigo)
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote: > > Please, *never* do that. It's generally a very bad idea to write > anything to debian/gbp.conf. It's as if you were adding your text editor > preferences in the package. Instead, please prefer writing in ~/.gbp.conf. I keep most of my git-buildpackage settings which are specific to my developer environment in ~/.gbp.conf. However, there are some gbp settings which are specific to the repository set up, and those I think, IMHO, *are* appropriate for debian/gbp.conf. For example: [DEFAULT] pristine-tar = True upstream-tag='v%(version)s' debian-branch=debian/master If you are going to be cloning the e2fsprogs repository and wanting to use gbp-buildpackage, you *will* want to use these settings, and putting them in ~/.gbp.conf doesn't work well, since they won't apply for all packages that they might want to build. Regards, - Ted
Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)
On 10/5/19 7:48 PM, Attila Szalay wrote: > I added the "pbuilder-options = --source-only-changes" option to the > [buildpackage] part of the debian/gbp.conf Please, *never* do that. It's generally a very bad idea to write anything to debian/gbp.conf. It's as if you were adding your text editor preferences in the package. Instead, please prefer writing in ~/.gbp.conf. Just an example: if someone is using pbuilder, and wants to add a new binary to your package, then your debian/gbp.conf will be super annoying, because in such case, we need to upload *with* binaries (as source-only uploads aren't possible in the NEW queue). Also, please remember that not everyone is using git-buildpackage, and that nobody is ever, forced to do so, even when using git for packaging (just calling plain sbuild works perfectly, for example). A few years ago, we decided to *completely* remove all traces of debian/gbp.conf inside the OpenStack team, and I very much enjoy this choice. The only annoying bit, is that now, everyone *must* write in ~/.gbp.conf this: [DEFAULT] ignore-branch = True By the way, it'd be nice if it became the default in git-buildpackage. This missleads everyone into writing a debian/gbp.conf just in order to tell git-buildpackage what branch to build with. Cheers, Thomas Goirand (zigo)
Re: source only upload with git-buildpackage
Am Sonntag, den 06.10.2019, 22:09 +0200 schrieb Bernd Zeimetz: > Hi, > > > I'm struggling with it for a while now and I couldn't find the solution. > > I have a package maintained with git-buildpackage. And now, that I > > "cannot" upload binary packages I tried to compile the new version with > > the option to create a source-only changes file too. But for some reason > > that changes files are not created. > > I'm using this alias: > > % type git-bcS > git-bcS is an alias for gbp buildpackage --git-builder='debuild -i^\.git > -i^\.travis.yml -I.git -S -d' JFTR: If you add a .gitattributes file and set the files like .travis.yml to 'export-ignore', they shouldn't be there at all and you don't need to exclude them from dpkg-source. Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: source only upload with git-buildpackage
Am Sonntag, den 06.10.2019, 11:27 +0200 schrieb Alf Gaida: > On 06.10.19 08:18, Attila Szalay wrote: > > That option means that the system will create not only the binary > > .amd.changes but another changes too which contains only the source > > packages. And I would like to use this method to be sure the package > > compiles, to be able to run the lintian against the package and even > > be able to test it before the upload. > > > Sounds cool, right now i use a different workflow: Build and sign source > packages and send them to pbuilder (different machine) - build in two > architectures, lintian is part of the build process, pbuilder hook. So i > was a bit irritated :) I'm using the same workflow. But I send the unsigned packages to the buildd running pbuilder (local network) and let pbuilder build and test the packages and create the source file, which then gets signed and uploaded. So gbp just runs: debuild --no-lintian -d -sa -us -uc -nc -S and uploads the packages to my buildd via: dput -f buildd `echo $GBP_CHANGES_FILE | sed -e 's/amd64/source/g'` Regards, Daniel signature.asc Description: This is a digitally signed message part
Re: source only upload with git-buildpackage
On 10/6/19 11:15 PM, PICCA Frederic-Emmanuel wrote: > And what about > > dgit --gbp push-source ? not going to touch that. dgit is imho way to over-engineered while having requirements at the same time, that I don't want to have (like using dgit.debian.org...). We have salsa as central repository, there is absolutely no need to have something else. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: source only upload with git-buildpackage
Hi, > I'm struggling with it for a while now and I couldn't find the solution. > I have a package maintained with git-buildpackage. And now, that I > "cannot" upload binary packages I tried to compile the new version with > the option to create a source-only changes file too. But for some reason > that changes files are not created. I'm using this alias: % type git-bcS git-bcS is an alias for gbp buildpackage --git-builder='debuild -i^\.git -i^\.travis.yml -I.git -S -d' That should do what you want :) Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: source only upload with git-buildpackage
On Sun, Oct 6, 2019 at 6:27 PM Alf Gaida wrote: > > On 06.10.19 08:18, Attila Szalay wrote: > > That option means that the system will create not only the binary > > .amd.changes but another changes too which contains only the source > > packages. And I would like to use this method to be sure the package > > compiles, to be able to run the lintian against the package and even > > be able to test it before the upload. > > > Sounds cool, right now i use a different workflow: Build and sign source > packages and send them to pbuilder (different machine) - build in two > architectures, lintian is part of the build process, pbuilder hook. So i > was a bit irritated :) I'm not sure what's your configuration. But I use git buildpackage, too. Seems you're using pbuilder / cowbuilder to do the real build, rather than git buildpackage. So you need to set up ~/.pbuilderrc, instead of ~/.gbp.conf Personally, I set up "SOURCE_ONLY_CHANGES=yes" in ~/.pbuilderrc. And I think you can get more info about pbuilder / cowbuilder by: - https://wiki.debian.org/PbuilderTricks - https://wiki.debian.org/git-pbuilder If you need more help, I think you should share your ~/.gbp.conf and ~/.pbuilderrc Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Re: source only upload with git-buildpackage
On 06.10.19 08:18, Attila Szalay wrote: > That option means that the system will create not only the binary > .amd.changes but another changes too which contains only the source > packages. And I would like to use this method to be sure the package > compiles, to be able to run the lintian against the package and even > be able to test it before the upload. > Sounds cool, right now i use a different workflow: Build and sign source packages and send them to pbuilder (different machine) - build in two architectures, lintian is part of the build process, pbuilder hook. So i was a bit irritated :) Cheers Alf
Re: source only upload with git-buildpackage
That option means that the system will create not only the binary .amd.changes but another changes too which contains only the source packages. And I would like to use this method to be sure the package compiles, to be able to run the lintian against the package and even be able to test it before the upload. On Sat, Oct 5, 2019, 23:36 Alf Gaida wrote: > > On 05.10.19 23:14, Andrey Rahmatullin wrote: > > On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote: > that is miss something - my point is: Why do you invoke pbuilder (read > the same question about sbuild too) to create pure source packages? > >>> To make sure they build correctly. > >>> > >> Ok, checked the calender, it is not April 1. I'm out. > > --source-only-changes doesn't mean "only create the source package". > > Maybe i have a general problem in understanding the gbp workflow - > thanks for the explanation. > > >
Re: source only upload with git-buildpackage
On 05.10.19 23:14, Andrey Rahmatullin wrote: > On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote: that is miss something - my point is: Why do you invoke pbuilder (read the same question about sbuild too) to create pure source packages? >>> To make sure they build correctly. >>> >> Ok, checked the calender, it is not April 1. I'm out. > --source-only-changes doesn't mean "only create the source package". Maybe i have a general problem in understanding the gbp workflow - thanks for the explanation.
Re: source only upload with git-buildpackage
On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote: > >> that is miss something - my point is: Why do you invoke pbuilder (read > >> the same question about sbuild too) to create pure source packages? > > To make sure they build correctly. > > > Ok, checked the calender, it is not April 1. I'm out. --source-only-changes doesn't mean "only create the source package". -- WBR, wRAR signature.asc Description: PGP signature
Re: source only upload with git-buildpackage
On 05.10.19 21:48, Andrey Rahmatullin wrote: > On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote: >> that is miss something - my point is: Why do you invoke pbuilder (read >> the same question about sbuild too) to create pure source packages? > To make sure they build correctly. > Ok, checked the calender, it is not April 1. I'm out. Cheers Alf
Re: source only upload with git-buildpackage
On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote: > that is miss something - my point is: Why do you invoke pbuilder (read > the same question about sbuild too) to create pure source packages? To make sure they build correctly. -- WBR, wRAR signature.asc Description: PGP signature
Re: source only upload with git-buildpackage
On 05.10.19 19:48, Attila Szalay wrote: > Hi, > > I'm struggling with it for a while now and I couldn't find the > solution. I have a package maintained with git-buildpackage. And now, > that I "cannot" upload binary packages I tried to compile the new > version with the option to create a source-only changes file too. But > for some reason that changes files are not created. > Ok, not uploading binaries is default now, isn't it? Maybe i don't understand your question right, but i've created my needed source packages yesterday with: gbp buildpackage -S and uploaded them - ok, i use gbp only for a month now so it might be that is miss something - my point is: Why do you invoke pbuilder (read the same question about sbuild too) to create pure source packages? Cheers Alf
source only upload with git-buildpackage
Hi, I'm struggling with it for a while now and I couldn't find the solution. I have a package maintained with git-buildpackage. And now, that I "cannot" upload binary packages I tried to compile the new version with the option to create a source-only changes file too. But for some reason that changes files are not created. I added the "pbuilder-options = --source-only-changes" option to the [buildpackage] part of the debian/gbp.conf and when I run the "gbp buildpackage --git-export="WC" --git-ignore-new" command I can see that the pbuilder got this option: I: Invoking pbuilder I: forking: pbuilder execute --bindmounts /home/sasa/src/debian/zorp/build-area *--source-only-changes* --buildplace /var/cache/pbuilder/build/cow.24170 --mirror http://ftp.hu.debian.org/debian --distribution sid --no-targz --internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.24170 cow-shell' /usr/lib/pbuilder/pdebuild-internal /home/sasa/src/debian/zorp/build-area/zorp-7.0.1~alpha2 --debbuildopts --debbuildopts --uid 1000 --gid 1000 --pbuildersatisfydepends /usr/lib/pbuilder/pbuilder-satisfydepends Is there anything I can check why the non-binary changes file is not created? sasa@sasa:~/src/debian/zorp/src$ apt policy git-buildpackage pbuilder cowbuilder git-buildpackage: Installed: 0.9.15 Candidate: 0.9.15 Version table: *** 0.9.15 500 500 http://ftp.hu.debian.org/debian testing/main amd64 Packages 500 http://ftp.hu.debian.org/debian testing/main i386 Packages 500 http://ftp.de.debian.org/debian testing/main amd64 Packages 500 http://ftp.de.debian.org/debian testing/main i386 Packages 100 /var/lib/dpkg/status pbuilder: Installed: 0.230.4 Candidate: 0.230.4 Version table: *** 0.230.4 500 500 http://ftp.hu.debian.org/debian testing/main amd64 Packages 500 http://ftp.hu.debian.org/debian testing/main i386 Packages 500 http://ftp.de.debian.org/debian testing/main amd64 Packages 500 http://ftp.de.debian.org/debian testing/main i386 Packages 100 /var/lib/dpkg/status cowbuilder: Installed: 0.88 Candidate: 0.88 Version table: *** 0.88 500 500 http://ftp.hu.debian.org/debian testing/main amd64 Packages 500 http://ftp.de.debian.org/debian testing/main amd64 Packages 100 /var/lib/dpkg/status And the created files: I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474.dsc is already in target, not copying. I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474.debian.tar.xz is already in target, not copying. I: file ../libzorp-7.0-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../libzorp-7.0_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../libzorp-dev_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../munin-plugins-zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../nagios-plugins-zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../zorp-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../zorp-modules-dbgsym_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../zorp-modules_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.buildinfo is already in target, not copying. I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.deb is already in target, not copying. I: file ../zorp_7.0.1~alpha2-2~1.gbp7d4474_amd64.changes is already in target, not copying.
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
On 20 September 2019 at 13:27, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
| > -build: build-arch
| > +## edd 19 Sep 2019 for source uploads also build build-indep
| > +build: build-arch build-indep
| >
| > build-arch: make-arch
| > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
| >
| > Fetched the package from pool and r-base-html is still 'empty'.
|
| If you want to continue to try to fix this without a rewrite, I think
| you need to repro locally. Have you tried the dpkg-buildpackage rune
| which builds only arch:all, namely --build=all ? (NB that does not
| mean build all the things, it means build only "all" things.)
Fully agreed. That's next.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
> -build: build-arch
> +## edd 19 Sep 2019 for source uploads also build build-indep
> +build: build-arch build-indep
>
> build-arch: make-arch
> ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
>
> Fetched the package from pool and r-base-html is still 'empty'.
If you want to continue to try to fix this without a rewrite, I think
you need to repro locally. Have you tried the dpkg-buildpackage rune
which builds only arch:all, namely --build=all ? (NB that does not
mean build all the things, it means build only "all" things.)
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
On 19 September 2019 at 20:40, Dirk Eddelbuettel wrote: | On 19 September 2019 at 16:03, Guillem Jover wrote: | | On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote: | | > So presumably the dependency graph within debian/rules is wrong. Would | | > anybody here know | | > | | > - either a failsafe idiom forcing the right thing to happen | | > - or a more efficient way | | > | | > to ensure the binary-arch is built before binary-all? Should I force it? Is | | > that wasteful? Is there a recommended way? | | | | I've just skimmed over the rules, but I indeed see several problematic | | constructs there: | | | | - «build: build-arch» that should include build-indep too. | | Ok. Tried, but failed. In 3.6.1-5 I now have modified debian/rules @@ -215,7 +215,8 @@ denmark: ## edd 15 Jan 2004 trying again on build only build: build-arch build-indep ## the main hook is to then have binary depend on both ## binary-arch and binary-indep, and those on their builds -build: build-arch +## edd 19 Sep 2019 for source uploads also build build-indep +build: build-arch build-indep build-arch: make-arch ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) Fetched the package from pool and r-base-html is still 'empty'. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
> On 19 September 2019 at 14:51, Ian Jackson wrote:
> | This would be a good idea. It is quite some effort but I think you
> | would be rewarded with significantly lower maintenance burden.
>
> Agreed in principle. Finding time to do it the right is the issue.
Indeed. Things that make this easier: 1. you'll get a good level of
support from the rest of the Debian community, who'll be generally
happy to help debug etc. 2. You will set out to produce identical
output packages, except for deliberate changes, so you can use debdiff
to see whether your new rules file works as desired.
Because of (2), you can just start with the trivial dh rules file and
iterate until it (i) builds (ii) produces the output you want.
I did this for src:xen (another complex package with a *lot* of, erm,
technical debt in its package build) last year. It took about 2-3
days' solid effort. I think it's been repaid already.
> On 19 September 2019 at 16:03, Guillem Jover wrote:
> | [a lot of detailed comments]
>
> [ Dirk's responses ]
In your position would definitely try to minimise the amount of work
to the existing rules file.
So for example:
> | - It seems generally parallel unsafe, as many targets declare what
> | should be serially executed as parallely-executed, as in:
...
> Fair. Do we build packages with 'make -j ...' now?
This can simply be disabled (and it's still disabled by default). I
would not encourage you to try to get rid of the concurrency bugs in
this rules file, other than by a complete rewrite.
Guillem's comments on this are of course very helpful, more generally.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
Ian, Guillem,
On 19 September 2019 at 14:51, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Possible doc package side-effect from going
source-only upload"):
| > Maybe someone on the list can help with a sharp insight before I go trying.
| >
| > The r-base source package (for the R system and language) has a somewhat
| > cobbled together debian/rules [1], mostly of my making over the last 20+
| > years since I helped Doug more and more and eventually took it over. I
| > apologize for the rough shape it is in, but hey, it works. Mostly. Read on.
|
| > So presumably the dependency graph within debian/rules is wrong. Would
| > anybody here know
| > - either a failsafe idiom forcing the right thing to happen
| > - or a more efficient way
| > to ensure the binary-arch is built before binary-all? Should I force it? Is
| > that wasteful? Is there a recommended way?
|
| You could take the first part of the binary-arch target and split it
| out into something that both binary-arch and binary-indep depend on.
| That would probably "fix" this problem.
Yes, my thinking was along those lines, but so far less refined. Will try this.
| Holger Levsen writes ("Re: Possible doc package side-effect from going
source-only upload"):
| > not really that helpful of a comment, but I think the rules file would
| > be a lot more readable if you'd dropped all the old commented out code
| > in it.
|
| I agree with this.
I did not see Holger's post as he did not CC me (and I had a crazy day, have
not check d-devel archives). I agree in the abstract and feel the same from
time ot time -- but in practice the comments are 'lab notes' for myself and
have been rather helpful a few times. And as I maintain the file they'll
stay for as long as they help me.
| > (and then I think^wbelieve your arch-all problem could be solved by
| > switching to dh style...)
|
| This would be a good idea. It is quite some effort but I think you
| would be rewarded with significantly lower maintenance burden.
Agreed in principle. Finding time to do it the right is the issue. I am
maintainer for well over 100 packages most of which are cookie-cutter CRAN
packages and alike -- they all use dh. A handful of older / larger packages
are still older-school.
On 19 September 2019 at 16:03, Guillem Jover wrote:
| On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote:
| > So presumably the dependency graph within debian/rules is wrong. Would
| > anybody here know
| >
| > - either a failsafe idiom forcing the right thing to happen
| > - or a more efficient way
| >
| > to ensure the binary-arch is built before binary-all? Should I force it? Is
| > that wasteful? Is there a recommended way?
|
| I've just skimmed over the rules, but I indeed see several problematic
| constructs there:
|
| - «build: build-arch» that should include build-indep too.
Ok.
| - install-arch has build-arch as a dependency, but install-indep
| has make-indep, this seems inconsitent and possibly wrong.
I will take a look.
| - Some of the prerequisites are not protected behind stamp files, so
| they will get executed multiple times, which seems counter to using
| stamp files (although I find stamp files to be somewhat of an
| anti-pattern :). Stuff like:
|
| barrier: prereq-1 barrier
| barrier-stamp:
|
| but this is in a way covered already by the next point.
I used them in the 1990s when most if not all debian/rules files had, I never
really had they feeling they worked all that well. Use of them seems to have
disappeared over time.
| - It seems generally parallel unsafe, as many targets declare what
| should be serially executed as parallely-executed, as in:
|
| target: prereq-a prereq-b
|
| can execute both prereqs at the same time. The way to serialize
| them is:
|
| prereq-1: prereq-2
| target: prereq-1
Fair. Do we build packages with 'make -j ...' now?
| Not sure whether fixing all the above will fix your problem, but this
| is something that should be done non the less IMO. :)
All good hints. Much appreciated :)
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Possible doc package side-effect from going source-only upload
Hi! On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote: > So presumably the dependency graph within debian/rules is wrong. Would > anybody here know > > - either a failsafe idiom forcing the right thing to happen > - or a more efficient way > > to ensure the binary-arch is built before binary-all? Should I force it? Is > that wasteful? Is there a recommended way? I've just skimmed over the rules, but I indeed see several problematic constructs there: - «build: build-arch» that should include build-indep too. - install-arch has build-arch as a dependency, but install-indep has make-indep, this seems inconsitent and possibly wrong. - Some of the prerequisites are not protected behind stamp files, so they will get executed multiple times, which seems counter to using stamp files (although I find stamp files to be somewhat of an anti-pattern :). Stuff like: barrier: prereq-1 barrier barrier-stamp: but this is in a way covered already by the next point. - It seems generally parallel unsafe, as many targets declare what should be serially executed as parallely-executed, as in: target: prereq-a prereq-b can execute both prereqs at the same time. The way to serialize them is: prereq-1: prereq-2 target: prereq-1 Not sure whether fixing all the above will fix your problem, but this is something that should be done non the less IMO. :) Thanks, Guillem
Re: Possible doc package side-effect from going source-only upload [and 1 more messages]
Dirk Eddelbuettel writes ("Possible doc package side-effect from going
source-only upload"):
> Maybe someone on the list can help with a sharp insight before I go trying.
>
> The r-base source package (for the R system and language) has a somewhat
> cobbled together debian/rules [1], mostly of my making over the last 20+
> years since I helped Doug more and more and eventually took it over. I
> apologize for the rough shape it is in, but hey, it works. Mostly. Read on.
> So presumably the dependency graph within debian/rules is wrong. Would
> anybody here know
> - either a failsafe idiom forcing the right thing to happen
> - or a more efficient way
> to ensure the binary-arch is built before binary-all? Should I force it? Is
> that wasteful? Is there a recommended way?
You could take the first part of the binary-arch target and split it
out into something that both binary-arch and binary-indep depend on.
That would probably "fix" this problem.
Holger Levsen writes ("Re: Possible doc package side-effect from going
source-only upload"):
> not really that helpful of a comment, but I think the rules file would
> be a lot more readable if you'd dropped all the old commented out code
> in it.
I agree with this.
> (and then I think^wbelieve your arch-all problem could be solved by
> switching to dh style...)
This would be a good idea. It is quite some effort but I think you
would be rewarded with significantly lower maintenance burden.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Possible doc package side-effect from going source-only upload
On Thu, Sep 19, 2019 at 07:15:43AM -0500, Dirk Eddelbuettel wrote: > [1] https://salsa.debian.org/edd/r-base/blob/master/debian/rules not really that helpful of a comment, but I think the rules file would be a lot more readable if you'd dropped all the old commented out code in it. (and then I think^wbelieve your arch-all problem could be solved by switching to dh style...) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Possible doc package side-effect from going source-only upload
Hi all, Maybe someone on the list can help with a sharp insight before I go trying. The r-base source package (for the R system and language) has a somewhat cobbled together debian/rules [1], mostly of my making over the last 20+ years since I helped Doug more and more and eventually took it over. I apologize for the rough shape it is in, but hey, it works. Mostly. Read on. As it was common, I used to binary upload, so arch: all documentation packages where built here and shipped. A user alerted me (in private mail, rather than via BTS, it happens) that the most recent upload is missing some files: I have just realized that all the /usr/lib/R/library/*/html/00Index.html and /usr/lib/R/library/*/html/R.css files are missing from r-base-html_3.6.1-4_all.deb and r-base-html_3.6.1-3_all.deb. They are there in r-base-html_3.6.1-2_all.deb. He is correct, and pondering this I realized that it very likely corresponds to me being gently nudged to source uploads (a good thing, overall). So presumably the dependency graph within debian/rules is wrong. Would anybody here know - either a failsafe idiom forcing the right thing to happen - or a more efficient way to ensure the binary-arch is built before binary-all? Should I force it? Is that wasteful? Is there a recommended way? Happy to test a few things but I thought I'd ask before wasting a lot of time on it more randomly. Please CC me on replies. Many thanks, Dirk [1] https://salsa.debian.org/edd/r-base/blob/master/debian/rules -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
