control: tags + pending control: retitle also use apt debug options in schroots Hi David, On Montag, 5. Januar 2015, David Kalnischkies wrote: > first of all, thanks for all these chroot jobs, they are quiet handy. :) yay! > That said, I wonder if they would be even more useful if we could enable > a bunch of debug options for apt. Failures like [0] are e.g. hard to reason > about as-is as the info shown is about stuff which remained broken even > after trying hard, while information about what was tried would be nice > and probably more helpful to identify and fix the (initial) problem. > The totally untested attached diff adds an array of those, which all just > print (many) many lines on stderr (well, actually stdlog) but do not > modify behaviour otherwise. The patch looked good to me, so I've merged + deployed it. https://jenkins.debian.net/view/chroot-installation/view/Problems/job/chroot- installation_jessie_install_qt4_upgrade_to_sid_aptdpkg_first/ is the next job run which will use it :) Thanks for your patch and bug report! I'll keep the bug open until these options are a.) verified to be working and b.) applied to schroot tests as well. More patches very welcome! ;-) (Best via a git remote I can add as remote.) > There are others which could be interesting like showing how dpkg is > called ( -o Debug::pkgDpkgPm=true ) and newer tricks like not > downloading deb files ( -o Debug::pkgAcqArchive::NoQueue=true ), but > they modify behaviour and would therefore need other changes and I am > not sure if that would actually be worthed it, so just noting in case > you want to dig deeper. For the regular runs I dont want anything modifiyng behaviour, maybe it would be good to document those options in the jenkins README or the yet-largely-to- be-written documentation about how to reproduce the jenkins job runs locally. > Related, it might be interesting to store the /var/lib/dpkg/status file > at various steps in the job (if that is even possible with jenkins). sure, jenkins just runs code we feed it. > Setting up (especially the bigger cases) takes quiet a bit of time and > traffic, while to reproduce some problems, all you need is the status > file and "-o dir::state::status=/path/to/file -s". I wonder whether I should clone the bug report for this or... > And while talking about reproducibility, a strategic > grep -H '^Date:' /var/lib/apt/lists/*Release* > after 'apt-get update's might help in figuring out what to tell > snapshot.d.o to get the exact same data as used in the job. Are you aware of http://lists.alioth.debian.org/pipermail/reproducible- builds/Week-of-Mon-20141229/000613.html ? I think this srebuild wrapper is really a nice PoC but believe this functionality should probably also land in apt. And it's on my todo-list to file a wishlist bug about it... cheers & thanks again, much appreciated! Holger
Attachment:
signature.asc
Description: This is a digitally signed message part.