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? 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
