On Thu, Jan 26, 2017 at 01:51:54AM +0100, Adam Williamson wrote: > On Wed, 2017-01-25 at 21:37 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > > You generally need to root to create and run a chroot, so this is > > expected. > > > > > Could something like that be part of Bodhi? > > > > I had a look at the source code. piuparts.py [1] has a mishmash > > of debian/ubuntu distro-specific config, functions for chroot > > creation, process management, helper functions, and the actual logic > > of testing stuff. That's why it's so large. Thankfully we wouldn't need > > most of that. > > > > It seems that we *could* use a test like that in taskotron. > > In particular, install the package, uninstall, reinstall, make sure > > scriptlets don't fail and not errors are logged. > > We certainly could build something like that. However, if you look at > this case, it's not entirely a simple one - because the package that > *broke* was polymake, but the package that *changed* was perl. polymake > didn't change at all. Knowing that we need to run the 'installpkg' (or > whatever we call it) test on polymake when perl changes makes things > somewhat more complex. Of course in this particular case it's not crazy > difficult - all we have to do is parse polymake's deps, easy right?! - > but this kind of thing leads you down lots of rabbit holes...for > instance, when perl gets an API bump, thousands of packages will > suddenly start 'failing' this test, because in Rawhide there's no way > to group package builds (so we can't 'group' the perl API bump with > rebuilds of all dependent packages)...what do we do about that? Yeah, the devil is in the details, as always ;) > Still, we don't have to make it perfect, and even just a test which > tried to install all of a source package's binary packages every time > that package was changed could be useful. Tim says this is something > that's been talked about but no-one's yet taken the time to do it. > > > There's dist.upgradepath test, but I have no idea what it does. > > It doesn't do that. It tries to check whether an update breaks the > upgrade path between releases; it's intended to catch cases where, say, > 'foo-2.0.fc24' is released while F25 still only has 'foo-1.5.fc25'. > It's somewhat less important now dnf system-upgrade does a distro-sync > by default, but still useful I think. > > > Unfortunately taskotron is rather opaque :( [2] > > > > [1] https://anonscm.debian.org/cgit/piuparts/piuparts.git/tree/piuparts.py > > [2] https://taskotron.fedoraproject.org/ documentation link points to > > https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest/docs > > which cannot be resolved. > > We're sorry about that - Tim's been updating and moving documentation > around (in an attempt to make it better), but that meant that URL went > stale. Or in his verbatim words (it's 1:30am here and we're quite > tired...), "Oh ****, I was going to do that tomorrow". :) > > You can now find the docs here: https://qa.fedoraproject.org/docs/libtaskotron/latest/ > Tim is also fixing the front page link now. There are supposed to be > redirects from the old URLs but they're not working, he's figuring that > out. Thanks! There's another broken link on the https://taskotron.fedoraproject.org/ page: "Development guide" → https://docs.qadevel.cloud.fedoraproject.org/libtaskotron/latest//docs/devguide.html. (I tried to find the source, but I got lost in the maze of repositories...) Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
