[00:38] for those of you idling for the piuparts/vm session, i've placed some notes at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-23 [00:39] it's a good idea to go ahead and configure pbuilder, piuparts, and your vm === pleia2 changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/ubuntu-classroom | Upcoming: 23 Apr @ 00:00 UTC Package testing: piuparts and VMs | Run 'date -u' in a terminal to find out the UTC time [01:00] all right folks, it being 00:00 utc and such, let's roll on through. i hear there's a release being prepared. :-) [01:01] :) [01:01] again, this packaging session will introduce piuparts for package testing, and we'll mention how to use a VM to further test functionality [01:02] there are some notes (and corrections!) at https://wiki.ubuntu.com/Packaging/Training/Logs/2009-04-23, so please take look and get your prerequisites all shiny [01:02] damn, I've managed to stay awake for this session.. any cookies for me? ;} [01:02] cough, take a* look [01:02] any questions before we dive in? [01:03] Why so late? ;) === Pollywog is now known as pollywog_ [01:03] (no idea! the schedule rotation deems it so) [01:03] ok, and with that resounding silence, let's get started. [01:04] dtchen: wait - how to configure piuparts? [01:04] do i even have to? [01:04] hopefully this VM gets installed before you're too far through. [01:04] :) [01:04] piuparts(8) is a tool for providing a somewhat systematic method for testing whether a binary package can be installed and removed, and/or any of the intermediate upgrade steps [01:05] we are installing a vm? [01:05] kklimonda: as long as you have piuparts installed, that will suffice [01:05] Pollywog: My desktop is intrepid [01:05] ic [01:05] eythian: / Pollywog: you don't necessarily *need* a VM, but it's quite useful for actual usage testing [01:06] (ok, back to topic) [01:06] some (many?) people are familiar with building binary packages from source packages on their local systems [01:07] pbuilder is but one such utility - granted, it's a very nice utility [01:07] briefly, one would do something akin to: # pbuilder build foo.dsc [01:08] if everything "goes well", one ends up with ../*.deb (and the other parts of the source package) [01:08] people often then use dpkg -i (or gdebi or ...) to install ../*.deb [01:09] however, pbuilder has one fairly glaring omission in the maintenance sense: it doesn't actually test-install/remove/etc. the generated binary packages [01:09] dtchen: is it possible to install packages in pbuilder chroot without too much work? [01:09] Yes kklimonda [01:09] kklimonda: absolutely, and i'll touch on that briefly, too, with something called pbuilder hooks [01:10] since kklimonda provided such a nice segue... [01:10] pbuilder has an extension mechanism known as hooks. take a look in /usr/share/doc/pbuilder/examples/ [01:11] now, piuparts and pbuilder hooks for executing an install/upgrade/removal test are nominally similar [01:11] where piuparts really differs is the ability to test install/upgrade/removal for an entire archive [01:11] that's a bit much for pbuilder (although it's certainly possible with some additional scripting) [01:12] (so, next time you encounter liw online, give him a virtual beer) [01:12] does anyone have any questions regarding what piuparts is used for? [01:13] no [01:13] ok, now let's look at the functional testing of binary packages [01:14] piuparts and pbuilder (with hooks) are useful for fairly basic testing, but they don't actually test whether your pbuilt/sbuilt package actually starts, throws pretty screen bling up, crackles/hisses/pops, etc. [01:14] (err, oops, was that pulseaudio?) [01:14] :) [01:15] to get a sense of whether your package works, you really should use a VM. at the very least, you can install in the pbuilder chroot and invoke the program(s). [01:15] now that i've set the stage, let's look at the two munged source packages i've placed at http://kernel.ubuntu.com/~dtchen/package-training-2009.04.23/ [01:16] the first is oss-compat, and we'll use that to demonstrate piuparts [01:16] Should we download the packages? [01:16] yes, we should have the munged source packages downloaded [01:17] done [01:17] for people who preferred `apt-get source oss-compat', i'll pastebin the debdiff [01:17] (well, the relevant portion) [01:18] For everyone else, you can use dget to download the source package [01:18] http://paste.ubuntu.com/156227/ [01:19] so the basic idea here is that as of jaunty, module-init-tools requires files to have the ".conf" suffix/extension [01:19] this modification is a fairly straightforward one: we look at the source package and modify debian/postinst [01:20] (then adjust debian/control, add/modify the changelog entry, etc.) [01:20] now, when that package is pbuilt using pbuilder [without hooks], the deb will be generated correctly [01:21] this case is an excellent illustration of where the install pbuilder hook and piuparts shine [01:21] because the actual error lies in the postinst, pbuilder [without hooks] won't throw any errors [01:21] so let's actually use piuparts ;-) [01:22] the syntax is fairly basic: [01:22] sudo piuparts foo.deb [01:23] on my system, because i use apt-cacher-ng, the syntax is bit more convoluted: [01:23] sudo piuparts -m "http://localhost:3142/ubuntu" --skip-minimize -- foo.deb [01:24] dtchen: i get " E: Couldn't find package debfoster" [01:25] I've added --skip-minimize and it worked [01:25] if you're using jaunty, you'll probably need the --skip-minimize [01:25] now, piuparts will create a minimal chroot if you use the above command, but most of you likely have a pbuilder base.tgz (or jaunty.tgz or whatnot) already [01:26] you can instruct piuparts to use the existing pbuilder base.tgz by passing -p [01:26] (so, as piuparts runs...) [01:26] dtchen: -p ? not -b ? [01:27] kklimonda: -b is more flexible [01:27] i see - it's a shortcut [01:27] :) [01:27] dtchen: but still when i use my pbuilder base.tgz I get "E: Couldn't find package debfoster" error [01:28] kklimonda: are you using jaunty's piuparts? [01:28] dtchen: yes [01:28] 0.35ubuntu1 [01:28] let's troubleshoot that offline [01:29] so piuparts is different for different releases? [01:29] kklimonda: adding --keep-sources-list option probably it works [01:29] dtchen: appending --skip-minimize (as adviced in bug #317721) helps [01:29] oh, no ubottu here :) [01:29] Pollywog: ideally, no - however, there is a difference between the Debian and Ubuntu components and priorities [01:30] juanje1: yes - it also worked [01:30] the Ubuntu modification in jaunty helps work around it, but it's imperfect)( [01:30] (hmm, Home key fail) [01:31] dtchen: -b is used to specify a specific base tarball, right? I've got pbuilder set up for jaunty, intrepid, and sid [01:31] asomething: correct [01:31] now, piuparts's output is fairly verbose [01:32] the parts we're interested in lie toward the end of the output [01:32] namely, PASS/FAIL/ERROR [01:33] note the: [01:33] ERROR: Broken symlinks: [01:33] /etc/modprobe.d/oss-compat.conf -> /lib/oss-compat/linu [01:33] (that's deftly illustrated at http://paste.ubuntu.com/156227/) [01:34] the process of correcting the error as a maintainer is fairly intuitive [01:34] we readd the omitted character, regenerate the source package, rebuild it, rerun piuparts on it. (rinse, lather, repeat) [01:35] any questions thus far? [01:36] ok, so we've quickly demonstrated how piuparts can assist in catching maintainer script errors [01:37] now, as maintainers/developers, we're supposed to be testing all our changes [01:37] due to whatever excuses, many of us don't ;-) [01:37] functional testing, however, is quite important [01:38] really, changes must be tested in a VM for both correctness and efficiency [01:38] the second example munged source package in my kernel.ubuntu.com space is pavucontrol [01:39] the change that actually makes jaunty's pavucontrol binary package usable is introduced in debian/patches/0002-Handle-noninitialised-data.patch [01:40] several iterations of that patch were generated before i discovered that upstream's fix wasn't entirely applicable to our source package [01:40] i.e., sometimes it's not as straightforward as "just applying upstream fixes" [01:41] briefly, jaunty ships with an older pulseaudio source package with many, many backported alsa fixes [01:41] these backported fixes differ from the current upstream source package, and therefore there are several assumptions in upstream's pavucontrol fix that aren't applicable to Ubuntu [01:42] mhm [01:42] so we should use "test before release" as our mantra ? :) [01:44] for our purposes, however, we're only going to illustrate that using a VM to test changes is the most efficient manner of demonstrating that a bug was fixed [01:44] (that's bug 359274) [01:44] if one were to take my munged source package, it is functionally equivalent to jaunty's superceded 0.9.7-1ubuntu1 [01:44] that version crashes as soon as a user attempts to mute System Sounds in the Playback tab [01:44] thus, testing in a VM (or a chroot or whatnot) is the simplest way to demonstrate the efficacy of a fix [01:44] absolutely [01:45] since many people don't have VMs configured, i won't insist that everyone duplicate the crash right this moment, but run through it on your own time, and remember that development really needs this constant testing [01:46] anecdote: if i had consistently used piuparts on my alsa-* and pulseaudio* source uploads for jaunty, i probably would have eliminated a half-dozen uploads [01:46] so, what do we take away from this session? using piuparts is good. testing in a vm after using piuparts is good. [01:47] i'll open it up for general questions now. [01:47] are there some Ubuntu-specific tutorials? [01:47] for piuparts [01:48] no, but feel free to pitch in :-) [01:48] (this session was just an intro to piuparts) [01:48] dtchen: i have a minor problem with pbuilder but it's unrelated to this class. [01:48] kklimonda: right, we can discuss that offline in -motu after this session [01:48] ok [01:49] Pollywog: do you have specific questions on using piuparts in a particular context? [01:49] dtchen: thanks for piuparts introduction - i was going to read about it some time ago and then forgot how it's called :) [01:49] dtchen: Is there a hook for pbuilder to have it run the deb through piuparts? [01:50] no, I am really confused because I have not used piuparts [01:50] nhandler: no, but there's some duplication in /usr/share/doc/pbuilder/examples/B91dpkg-i [01:50] I have played with pbuilder a few times [01:50] but in Debian [01:51] Pollywog: ok. very briefly, one uses pbuilder to generate a set of binary package(s) from a source package [01:51] Pollywog: however, pbuilder by default does not actually test the installation/upgrade/removal of said generated binary package(s) [01:52] Pollywog: it can be particularly troublesome if errors lie in the maintainer scripts [01:52] (since we only encounter those at package install/upgrade/removal) [01:54] Pollywog: try this: sudo piuparts --skip-minimize hello [01:54] juanje1: i have not tried using jaunty's piuparts on hardy, so i don't know offhand if it's feasible [01:54] juanje1: one thing to be aware of is the python2.6 transition [01:55] Pollywog: err, i think i omitted an -a [01:56] I will need to get the sources for hello [01:57] oh something happened [01:57] Pollywog: actually, you don't have to retrieve the sources [01:57] yes I see that now [01:57] Pollywog: -a instructs piuparts to retrieve from the repository using apt-get [01:57] I added the -a [01:58] juanje1: i generally filter the output in some other process [01:58] juanje1: the verboseness of piuparts can be cumbersome [01:59] is there a way to adjust the verbosity? [01:59] Pollywog: not quite [01:59] k [02:00] any other questions before we wrap up? [02:00] none here [02:00] dtchen: thanks for the class [02:00] no prob, thanks all! [02:00] dtchen: yep, thanks :-) [02:01] dtchen: thanks! [02:02] so, next week is dholbach with "Getting Started with Ubuntu Development" [02:02] it will take place on 30 April 2009, 06:00 UTC [02:02] hope to see you here! === alexbobp is now known as socat === socat is now known as alexbobp === croppa_ is now known as croppa === ChanServ changed the topic of #ubuntu-classroom to: Ubuntu Classroom || https://wiki.ubuntu.com/Classroom || https://lists.ubuntu.com/mailman/listinfo/ubuntu-classroom | Upcoming: 24 Apr 2009 @ 00:00 UTC: SSH; Ubuntu Open Week! Mon 27 April - Fri 1 May https://wiki.ubuntu.com/UbuntuOpenWeek | Run 'date -u' in a terminal to find out the UTC time === MTeck is now known as MTecknology === patrick is now known as Guest73092 [23:06] guess I'll do a Photoshop break in an hour [23:06] this chan has always been here ? [23:07] yes [23:07] Thu 23 Apr 2009 22:07:27 UTC [23:07] bodhi_zazen: surely you mean in TWO hours ;) [23:08] what is this class going to be about? [23:08] /topic [23:09] SSH? [23:09] ssh [23:10] two hours, lol [23:10] ah, yes :) [23:10] sorry [23:10] what exactly? ssh basics - rsa keys etc. ? [23:11] kklimonda: what ever people like [23:12] I would like these sessions to be Q&A more then lectures [23:12] and I have a shared ssh session set up so can demo commands in a shared session [23:12] mhm [23:13] >:) [23:13] http://paste.ubuntu.com/156798/ [23:13] you will not be able to log in as of yet though [23:15] >O [23:15] a lecture on SSH would be easy [23:16] 1. Get "SSH: the definitive guite" from O'REilly [23:16] 2. Read it [23:16] 3. ??? [23:16] 4. PROFIT! [23:18] what? [23:18] lol [23:19] you, sir, just won an internets [23:23] :<