Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Quoting Holger Levsen (2018-06-09 22:12:33) > As it sounds, I now believe this script would better live in src:devscripts > and as such I would like to reassign #774415 to devscripts - or do you see > any issue with that? I see no issues with that from my side. signature.asc Description: signature
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi josch, adding #774415 to to: and reply-to:… On Fri, Jun 08, 2018 at 07:54:20PM +0200, Johannes Schauer wrote: > > as I'm not an sbuild user (yet) myself, I was hesistant to try this > > myself, so I'm confused now: does it work as it is now? (or does it need > > changes to snapshot.d.o?) > > yes, it does work as it is now. > > Just supply the script with a buildinfo file to see it in action. > > It does not require superuser privileges. > > The script will query snapshot.debian.org to retrieve the right snapshot > timestamp that contains all the package versions specified in the buildinfo > file. > > At the end of execution the script will print how to either reproduce the > buildinfo manually via dpkg-buildpackage or how to run sbuild such that it > does > it for you. > > People who know how to use pbuilder could easily add a section that outputs > how > to run pbuilder to do the same. > > Naturally, instead of just printing how to use sbuild or pbuilder, the script > could also be made actually run either. > > The main two limitations of the script are: > > 1. it will fail if there is not a single snapshot that contains all the right > package versions > > 2. it will instruct sbuild/pbuilder to use the last stable release as the > base > which might not allow upgrading to the right package versions > > Both issues can be fixed by manually downloading exactly the required binary > package set and creating a completely new chroot with exactly the required > packages. But I didn't get around to doing that yet. thank you very much for this nice summary! As it sounds, I now believe this script would better live in src:devscripts and as such I would like to reassign #774415 to devscripts - or do you see any issue with that? -- cheers, Holger signature.asc Description: PGP signature
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi Holger, Quoting Holger Levsen (2018-06-08 17:47:47) > as I'm not an sbuild user (yet) myself, I was hesistant to try this > myself, so I'm confused now: does it work as it is now? (or does it need > changes to snapshot.d.o?) yes, it does work as it is now. Just supply the script with a buildinfo file to see it in action. It does not require superuser privileges. The script will query snapshot.debian.org to retrieve the right snapshot timestamp that contains all the package versions specified in the buildinfo file. At the end of execution the script will print how to either reproduce the buildinfo manually via dpkg-buildpackage or how to run sbuild such that it does it for you. People who know how to use pbuilder could easily add a section that outputs how to run pbuilder to do the same. Naturally, instead of just printing how to use sbuild or pbuilder, the script could also be made actually run either. The main two limitations of the script are: 1. it will fail if there is not a single snapshot that contains all the right package versions 2. it will instruct sbuild/pbuilder to use the last stable release as the base which might not allow upgrading to the right package versions Both issues can be fixed by manually downloading exactly the required binary package set and creating a completely new chroot with exactly the required packages. But I didn't get around to doing that yet. Thanks! cheers, josch signature.asc Description: signature
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Guillem, josch: thanks for your feedback, much appreciated. On Fri, Jun 08, 2018 at 08:38:49AM +0200, Johannes Schauer wrote: > > I say it's an artificial blocker, because it is based on the problem > > faced while implementing the srebuild script to use the current > > snapshot.d.o API. And I think that's your actual blocker. Fixing that > > API would also mean you can use it right away independently of what's > > already installed on the system and might be useful for other users > > too. I think the fix would imply adding an API entry point based on > > the name-version-arch tuple. > > yes, that would also solve the problem. as I'm not an sbuild user (yet) myself, I was hesistant to try this myself, so I'm confused now: does it work as it is now? (or does it need changes to snapshot.d.o?) > I unblocked the bug, because it's not a hard blocker but just an > inconvenience. thanks > The bigger blocker of #774415 is, that the script needs somebody who feels > responsible for it and who is willing to maintain it. I only wrote it but I > have no intention of being its maintainer. I'd be happy to maintain it, once I'm a user of it :) (which might happen quite soon via tests.r-b.o…) -- cheers, Holger signature.asc Description: PGP signature
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi, Quoting Guillem Jover (2018-06-08 04:30:45) > Having reread the blocking bug, and the specific message where josch > says this one is a blocker (https://bugs.debian.org/774415#44), I > think this is actually an artificial blocker! > > [...] > > I say it's an artificial blocker, because it is based on the problem > faced while implementing the srebuild script to use the current > snapshot.d.o API. And I think that's your actual blocker. Fixing that > API would also mean you can use it right away independently of what's > already installed on the system and might be useful for other users > too. I think the fix would imply adding an API entry point based on > the name-version-arch tuple. yes, that would also solve the problem. I unblocked the bug, because it's not a hard blocker but just an inconvenience. The bigger blocker of #774415 is, that the script needs somebody who feels responsible for it and who is willing to maintain it. I only wrote it but I have no intention of being its maintainer. Thanks! cheers, josch signature.asc Description: signature
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi! On Wed, 2018-06-06 at 23:40:54 +, Holger Levsen wrote: > ping on this bug, you haven't replied to it yet and it's a blocker for > "#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds" Oh, had not noticed this was a blocker for anything sorry. And thought the previous discussion on the list and on the bug was complete enough for now. :) > which is a rather important one to give users the means to easily > reproduce Debian packages, which is a core feature of reproducible > builds and which we would love to see for Buster…! Having reread the blocking bug, and the specific message where josch says this one is a blocker (https://bugs.debian.org/774415#44), I think this is actually an artificial blocker! I think this specific bug should eventually be fixed, how, I don't know yet. It would fix some rough edges and make life easier for apt and other frontends. But for the specific case in the reproducibility effort, I think even if we fixed this tomorrow you would not be able to rely on it, because it would require feeding the hashes for all pre-installed packages, as David Kalnischkies already mentioned previously. I say it's an artificial blocker, because it is based on the problem faced while implementing the srebuild script to use the current snapshot.d.o API. And I think that's your actual blocker. Fixing that API would also mean you can use it right away independently of what's already installed on the system and might be useful for other users too. I think the fix would imply adding an API entry point based on the name-version-arch tuple. Thanks, Guillem
Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it
Hi Guillem, ping on this bug, you haven't replied to it yet and it's a blocker for "#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds" which is a rather important one to give users the means to easily reproduce Debian packages, which is a core feature of reproducible builds and which we would love to see for Buster…! :) -- cheers, Holger signature.asc Description: PGP signature
