Dev Week -- Testing your .deb with piuparts -- liw -- Fri, Jan 23
UTC
[16:00] <dholbach> Ok... welcome everybody! [16:00] <dholbach> We have the amazing Lars Wirzenius here today and I promise he won't bite [16:00] * weboide is ready for it! [16:00] <dholbach> instead, he'll talk about the fantastic things you can do with piuparts and I hope you enjoy the ride [16:01] <dholbach> questions, as always, go into #ubuntu-classroom-chat please [16:01] <dholbach> and please prefix them with QUESTION: [16:01] <liw> if someone wants to volunteer to paste questions to this channel, that would be fabulous! [16:01] <dholbach> ie: QUESTION: liw: why don't Finns hug? [16:01] <dholbach> enjoy the session, liw: the floor is yours :) [16:01] <liw> dholbach, thank you, thank you [16:02] <dholbach> :-)( [16:03] <liw> so, I'm going to talk about piuparts. Questions are welcome at any time. I've structured this into sections: What is piuparts; basic usage; interpreting the results; speeding it up; testing for newer releasees; gotchas [16:03] <liw> if I'm going too fast, or too slow, don't hesitate to tell me [16:03] <liw> first section: What is piuparts? [16:03] <liw> Piuparts is a tool to test that a .deb package can be installed and removed, and installed, upgraded, and removed. [16:04] <liw> It is primarily meant for people who maintain and upload packages. [16:04] <liw> It works by constructing a chroot with a minimal Debian or Ubuntu installation, and then installing the package being tested into the chroot. It also installs the dependencies. [16:04] <liw> After this is done, it removes and then purges the package, and any other packages that got installed. [16:04] <liw> Finally, it compares the state of the chroot before the package and its dependencies were installed, and after they got purged. [16:04] <liw> It checks that all files are still there, and haven't been changed, and that there are no new files. [16:04] <liw> Obviously, some things will always change, such as log files. Piuparts ignores those. [16:04] <liw> any questions so far? anyone getting this at all? [16:05] <zerwas> <weboide> QUESTION: is this like pbuilder ? [16:05] <liw> zerwas, thanks (I was just fighting my irc client to do that :) [16:06] <liw> weboide, pbuilder uses a chroot to build a package in a clean environment; piuparts uses a chroot to test that a package installs into a clean environment, so there are similarities, but they are solving different problems with chroots [16:07] <liw> I will get back to pbuilder in a bit [16:07] <liw> any other questions? if not, I'll continue on to the next section [16:07] <liw> second section: Basic usage [16:07] <liw> The very basic way of using piuparts is as follows: [16:08] <liw> piuparts foo.deb [16:08] <liw> where foo.deb is a .deb package you have built. [16:08] <liw> Note that this can take a long time, and can produce quite a lot of output. [16:08] <liw> You probably don't want to run the command just now. [16:08] <liw> Because piuparts builds a chroot, it must run as root. [16:08] <liw> Prefix the command with sudo. (But not yet) [16:08] <liw> To avoid people accidentally copypasting commands when they shouldn't, I'm not prefixing it in examples. [16:09] <liw> The above command will run the install/remove/purge test. [16:09] <liw> If the package is already in the archive, it will also test that the package can be upgraded from the archive to the .deb you give. [16:09] <liw> The other way of running piuparts is as follows: [16:09] <liw> piuparts -a foo [16:09] <liw> Here foo is the name of a package, not of a .deb. [16:09] <liw> Piuparts will fetch the package from the archive and test it. [16:09] <liw> This will, obviously, not test upgrades since there is no newer package. [16:09] <liw> If you feel like being evil, you can spend your time worse than running piuparts on all sorts of random packages and filing bugs for serious problems. [16:10] <liw> any questions so far? [16:10] <liw> continuin... [16:10] <liw> You can also test upgrading from release to release: [16:10] <liw> piuparts -a -d dapper -d hardy -d intrepid -d jaunty foo [16:10] <liw> This will take even longer. [16:11] <liw> it will first construct a chroot with dapper, install the package into that, then upgrade the whole chroot to hardy, then to intrepid, then to jaunty, and then remove and purge the package and its dependencies [16:11] <zerwas> <ia> QUESTION: can piuparts use pbuilder's tgz chroot images (so to don't create for each tool each set of chroots)? [16:11] <liw> ia, yes; I'll show an example in a while [16:12] <zerwas> <weboide> QUESTION: what version of piuparts should be we use? repos version? dev version? [16:12] <liw> weboide, you should use the version in current development version of Ubuntu, by preference, unless that breaks [16:13] <liw> piuparts development has not been very fast in the past couple of years, so there are not a lot of versions to choose from that are easily available [16:14] <liw> third section: Interpreting the results [16:14] <liw> Piuparts outputs quite a lot of text when it runs. [16:14] <liw> This is because when I was developing it, it was quite useful to me to see what was going on and figure out when things broke. [16:14] <liw> I never got around to fixing things so that it was nice to use for other people. [16:14] <liw> (sorry) [16:14] <liw> Since the output can be pretty large, up to several hundred kilobytes, it is best to capture it in a file: [16:14] <liw> piuparts -l foo.log foo.deb [16:14] <liw> The output will go to the named file, and also to the screen. [16:14] <liw> Every line of output piuparts outputs is prefixed with a relative timestamp (minutes and seconds since piuparts started), and a log level: DUMP, DEBUG, INFO, WARNING, ERROR, FATAL. [16:15] <liw> DUMP and DEBUG you can mostly ignore; unfortunately there is no switch to let you do that at the moment. [16:15] <liw> (sorry) [16:15] <liw> The useful stuff is in INFO, and in ERROR if it is there. [16:15] <liw> Therefore, the way to read a piuparts log file is to grep for INFO and ERROR. [16:15] <liw> Then, if those don't make any sense, read DUMP and DEBUG as well. [16:15] <liw> When piuparts finishes, it outputs one of two things: either a PASS or a FAIL message. [16:15] <liw> They look like these: [16:15] <liw> 2m11.0s INFO: PASS: All tests. [16:15] <liw> 5m33.8s ERROR: Broken symlinks: [16:15] <liw> Obviously these were from different runs. You only get one of them per run. [16:16] <liw> I should pastebin some actual log output, just a minute. [16:17] <liw> http://paste.ubuntu.com/108624/ and http://paste.ubuntu.com/108625/ are two snippets of an actual log file [16:18] <liw> just to give you a taste of what they look like. the beginning and the end. [16:18] <zerwas> <Ape3000> QUESTION: How much time does the basic test usually take? [16:19] <liw> Ape3000, the second pastebin answers that for the hello package: almost 7 minutes (but that was running inside kvm) [16:19] <liw> any questions about interpreting those log files? they're long, but hopefully not too obscure [16:20] <liw> next section (is this 12765 already?): Speeding it up [16:20] <liw> (everyone's favorite topic) [16:20] <liw> It can take a long time to construct the chroot. [16:21] <liw> Since most package maintainers use pbuilder, and it constructs a chroot too, piuparts provides the --pbuilder (-p) option to use the pbuiler tarball to create the chroot. [16:21] <liw> This makes things much faster. [16:21] <zerwas> <Laney> QUESTION: Does the chroot have to be created every time? [16:21] <liw> On the server I used to use to run piuparts on all packages in Debian, a couple of years ago, piuparts took only a few seconds per typical small package, when using a pre-built chroot tarball. [16:21] <liw> Laney, so yeah, some kind of chroot gets created every time. When it is created by unpacking a tarball, it is pretty fast, just a couple of seconds [16:22] <liw> except on a netbook, perhaps === smarter_ is now known as smarter [16:22] <liw> In addition to -p, piuparts can create its own tarballs. Or you can construct one by hand. But let's stick to pbuilder ones, they're easiest for most people. [16:23] <zerwas> QUESTION: (by Laney) piuparts understands debian and ubuntu releases, right? [16:23] <liw> Laney, yes; piuparts just uses apt-get to do stuff, so it is fine with anything that apt understands [16:23] <liw> next+1 section: Testing packages for newer releases [16:24] <liw> Piuparts can test packages for newer releases of Ubuntu, on older release of Ubuntu, if you use the debootstrap package from backports. [16:24] <liw> This way, if your machine runs intrepid, but you want to test that your package works in jaunty, you can. [16:24] <liw> okay, I have one final section to go through (Gotchas), and after that you're all ready to actually start running things without ruining things :) [16:25] <liw> last section: Gotchas [16:25] <liw> Piuparts works on a chroot. [16:25] <liw> This means that it does not properly protect the host system. [16:25] <liw> A malicious package, or a really unfortunately buggy package, may ruin the host system. [16:25] <liw> In the three years since I wrote piuparts, I have had that happen, but it's possible. [16:25] <liw> The solution, of course, is to fix piuparts to use KVM. (Volunteers welcome.) Or to run piuparts in a virtual machine (that's what I do now). [16:26] <liw> Piuparts can use a lot of CPU, RAM, disk I/O, and network bandwidth. [16:26] <liw> Be prepared for that. It's nowhere near as fast to use as, say, lintian. [16:26] <liw> Some of the checks piuparts does often fail, but they don't matter much in real life. [16:26] <liw> The manual page has lists all options, so you can look there if something annoys you. [16:26] <liw> For example, piuparts checks that all symlinks point somewhere that actually exist. [16:26] <liw> For some reason, this is triggered fairly often, so you can disable it with the --no-symlinks (-N) option. [16:26] <liw> piuparts in Ubuntu defaults to gutsy, since it hasn't been updated since the hardy release to a better default. You can blame me for that. [16:27] <liw> Actually, don't blame me, file a bug in Launchpad, and subscribe me to it (liw on Launchpad). [16:27] <liw> (Yes, everyone reading this can do that. I can take it.) [16:27] <liw> You can work around this by specifying the distribution manually with the -d option: [16:27] <liw> piuparts -d jaunty foo [16:27] <liw> OK. Go run piuparts now. I want questions. [16:29] <liw> <Laney> So what's the command to test upgradability from the current stable release? I guess -d intrepid -d jaunty foo.deb? [16:30] <liw> yep, unless I forget something [16:30] <Laney> \o/ [16:30] <liw> it's possible piuparts can only test upgrades between releases for packages already in the archive, in which case you need to specify "-a foo" instead of "foo.deb" [16:30] <zerwas> <weboide> I just had this error: E: Couldn't find package debfoster [16:31] <liw> weboide, hmm, let me check [16:31] <liw> ah, I think we're hitting the difference between "main" in Debian and Ubuntu here [16:32] <liw> let me check something [16:34] <liw> the problem is that debfoster is in main in Debian (almost everything is), but in universe in Ubuntu, and piuparts was written before I really knew about Ubuntu, so it assumes it's enough to just use main [16:35] <liw> so the solution is to tell piuparts to use universe as well as main [16:36] <liw> except for some reason, for me the debfoster thing works, so I have a hard time testing, hmm [16:37] <liw> oh, I forgot -p [16:37] <liw> no wonder it was slow :) [16:37] <liw> debugging under public scrutiny does wonders for my humility muscles [16:40] <liw> weboide, anyway, the solution should be to specify the mirror for piuparts: -m 'http://your.mirrorhere/ubuntu main universe' [16:40] <liw> weboide, could you test that? [16:40] <weboide> liw: sure [16:43] <weboide> liw: It just passed the debfoster installation. so it helped :) [16:43] <liw> weboide, yay [16:47] <liw> any further questions? is everyone busy waiting for their machines to stop churning? [16:48] <jbernard> yep ;) === bac is now known as bac_lunch [16:57] <mneptok> liw: i thought "Thou shalt not paste Unix commands from Finns on IRC into thy shell," was one of the new commandments. [16:58] <liw> I think we're just about out of time. Thank you, everyone. If you have further questions about piuparts, I'm often available on #ubuntu-devel and other IRC channels. [16:59] <dinxter> cheers liw! [17:00] <Ape3000> I just got it working :D [17:00] <liw> Ape3000, yeay [17:01] <zerwas> THANKS for all this liw!