[00:05] infinity, cjwatson: for cross build db, I'm hit by debian bug #625484. this now fails on amd64 as a native build [00:05] Debian bug 625484 in libdb4.8 "libdb4.8: 'Build signature doesn't match environment' in 4.8.30-6" [Critical,Fixed] http://bugs.debian.org/625484 [00:06] I think we need the bug reporting in Launchpad as it provides a way for developers / reporters to communicate at least until we have server side hooks implemented in the crash database. [00:08] doko: Weird. That claims to have been fixed long before any DB version we have in the archive... === slank is now known as slank_away [00:20] ahh, typo [01:32] sabdfl: how is Las Vegas? [01:32] :) [01:33] just getting the stand ready, big opening is tomorrow, press event tonight [01:33] very nice [01:33] show looks to be as huge as ever [01:33] we've already had folks taking photos of the stand as "i was there" keepsakes [01:33] which is nice :) [01:33] sabdfl: well good thing you have something really big to show those attendees :) [01:34] sabdfl: price of fame :) === chiluk is now known as chiluk_away [02:08] can anyone jog my memory on the bash syntax for matching part of a string? It think it involved a #... like I want a for loop on *.patch, but I want to reference only the part before the .patch? [02:10] psusi: ${filename%.patch} -- http://tldp.org/LDP/abs/html/refcards.html [02:11] ahh... heh, I could have sworn it was a #... thanks... [02:11] psusi: # cuts in the other direction. [02:11] psusi: # is the front :) [02:11] aha [02:12] would be nice if I could have found that under brace substitution in the bash info page... heh... === dayangkun_ is now known as dayangkun [06:11] Good morning [06:11] bdmurray: yes, I already enabled it in the packaging branch [06:11] bdmurray: I'll release 2.8 today and then upload [06:12] infinity: just keeping errors.u.c. for crashes is indeed the plan, but we are missing the extra developer hooks for those still [06:12] and/or the request "the next person who experiences this, please file a LP bug" [06:12] both are planned, we discussed it on the London sprint === pcarrier_ is now known as pcarrier === Ursinha_ is now known as Ursinha === Tonio_aw is now known as Tonio_ [08:53] pitti: Minor nitpick you should fix in apport upstream before it hits Debian, that libc6-dbg dependency should be libc-dbg (all the libcN-dbg packages provide it). [08:53] pitti: Accepting anyway, though, since it's fine for Ubuntu, where all our arches are libc6. [08:54] infinity: ah, thanks; so in the spirit of "real dep first", libc6-dbg | libc-dbg ? [08:55] pitti: That's not a real package on all arches. If you really wanted to do that, you'd want "libc6-dbg | libc6.1-dbg | libc0.1-dbg | libc-dbg" [08:55] (I feel like I might be missing one...) [08:55] I don't want to pull in e. g. libc6-dbg-arm64-cross [08:56] Ahh, 0.3 on hurd, that's the one I was missing. [08:56] ok, I don't think I'm interested in those for Ubuntu [08:57] So, yeah, if you want to do real|virt, "libc6-dbg | libc6.1-dbg | libc0.3-dbg | libc0.1-dbg | libc-dbg" for Debian. [08:57] infinity: http://paste.ubuntu.com/1508926/ enough for ubuntu? [08:57] For us, sure, libc6-dbg | libc-dbg is fine (or even what you have there is fine). [08:57] Just pointing it out if the generic Debian packaging is upstream. [08:57] no, trunk has no packaging [08:57] (And, really, it doesn't hurt to have the extra deps in the Ubuntu package to keep the delta lower) [08:58] *nod* [08:58] I'm not sure how often the Debian maintainer syncs his packaging with our's, but I'll commit that for now [08:58] thanks for pointing out! [08:58] He's at 2.7-2 right now, uploaded on New Year's Eve. [08:58] So, I'm guessing reasonably often. [08:59] Oh, packaging, not upstream versions. Yeah, no idea how out of sync the packaging is. [08:59] Someone might want to look at that some day before we end up with an unreconcilable mess. [09:00] http://anonscm.debian.org/gitweb/?p=collab-maint/apport.git;a=tree;f=debian; looks reasonably close to our's [09:00] If they can be brought pretty close to in sync, we might want to just switch to a "maintain in experimental/sid, merge to Ubuntu" model. [09:00] Personally, I find that helps keep the world lett fragmented, but YMMV. [09:01] s/lett/less/ [09:01] yeah, and it's collab-maint anyway [09:01] one of these days I'll walk through our remaining delta and see how it can be minimized [09:02] Anyhow, that heads-up was mostly just cause Debian ftpmaster will (or should) have the same nitpick. If you don't do the Debian packaging anyway, meh. [09:02] s/do/have anything to do with/ [09:04] … just get the person maintaining the thing for Debian in the discussion loop and get the diff to zero. There; a better world. [09:06] that shouldn't be a problem, Ritesh contacts me rather often to fix things upstream in the debian backend, etc. === smb` is now known as smb === Tonio_ is now known as Tonio_aw === henrix_ is now known as henrix === Tonio_aw is now known as Tonio_ === elky` is now known as elky === cpg is now known as cpg|away === Ivanka_ is now known as Ivanka === tkamppeter__ is now known as tkamppeter === security is now known as fire === _salem is now known as salem_ === funkyHat_ is now known as funkyHat === doko_ is now known as doko [12:32] cjwatson: sure, I'll merge mcrypt today === Tonio_ is now known as Tonio_aw [12:32] s/mcrypt/m2crypto/ === MacSlow is now known as MacSlow|lunch [12:59] who is responsible for failsafe mode in R? [12:59] foundations [13:01] cjwatson: thanks networking mode dpkg mode and others don't work :( [13:08] zul,adam_g: openstackx has been removed from Debian because it's no longer needed (Debian bug #679077); do you agree with this and can I remove it from Ubuntu too? [13:08] Debian bug 679077 in ftp.debian.org "RM: openstackx -- ROM; now useless" [Normal,Open] http://bugs.debian.org/679077 [13:09] cjwatson: be my guest [13:09] done, thanks [13:19] stgraber: Do you still care about qtnx? It's been removed from Debian (Debian bug #652377). [13:20] Debian bug 652377 in ftp.debian.org "RM: qtnx -- RoQA; unmaintained, dead upstream" [Normal,Open] http://bugs.debian.org/652377 === Tonio_aw is now known as Tonio_ === dayangkun_ is now known as dayangkun === ppetraki_ is now known as ppetraki === MacSlow|lunch is now known as MacSlow [14:13] doko: the mesa/llvm issue should fix itself once we prepare the next mesa version for raring, since it got rid of the llvm-backend that caused trouble (moved to the llvm branch by tstellar, targeted for 3.3) [14:14] tjaalton, does this mean, that you need a 3.3 snapshot? [14:14] doko: not necessarily, they said that the radeonsi driver isn't that useful yet anyway, so we could just disable it until 3.3 is released [14:15] ahh, good to know. I don't want to have a snapshot in main [14:15] right [14:15] we could also ship a version just for mesa [14:16] but too much work for little benefit, I think [14:21] cjwatson: I think it can go now. It used to be handy to reproduce bugs for older versions of WebLive, but the last of those was natty, so I no longer care :) === chiluk_away is now known as chiluk === pgraner` is now known as pgraner === slank_away is now known as slank [14:52] cyphermox: hey! got a minute? I'm preparing a checkbox upload and wanted to ask about the actual uploading process (http://developer.ubuntu.com/packaging/html/udd-uploading.html) [14:52] cyphermox: basically I'd push from my branch to ubuntu:checkbox, then dput the source.changes, and that's it? [15:10] * xnox thought lp:checkbox is now used `as if it's lp:ubuntu/checkbox` [15:13] roadmr: depends what your branch is [15:13] if lp:checkbox is still different than ubuntu:checkbox you'll still want to apply a debdiff [15:14] while it needed sponsoring it was easier, but now for your own sanity I'd figure out a way to bring the two branches in sync ;) [15:15] but otherwise, yes, you do the changes on then push to ubuntu:checkbox, and dput the changes file [15:17] cyphermox, xnox : that's my next question, we want to ensure the branches at least have common ancestry, does bzr push --overwrite lp:ubuntu/checkbox sound good? (I'd then port the Ubuntu changelog to ensure that doesn't get lost) === arges_ is now known as arges [15:18] cyphermox, xnox : having a common ancestor will greatly simplify post-FF merging [15:21] roadmr: doesn't sound like the right way to achieve that [15:22] cyphermox: would going the other way do it? [15:22] maybe [15:22] currently looking at something entirely different. maybe try to see how well you can merge ubuntu:checkbox back into lp:checkbox? [15:24] if lp:checkbox already has everything you need I'm not sure you need to worry too much about the rest though; if everything for upload goes through lp:checkbox, you can make your changes there, and build source packages from that branch with no issues [15:25] cyphermox: the problem is post-FF, when we have to be selective about which changes in lp:checkbox go into the lp:ubuntu/checkbox (and from there to the package) [15:25] oh, right [15:25] cjwatson: hey, do you know if there's been any change on the UEFI netboot story [15:25] zyga: No [15:25] cyphermox: being selective using patch (because no common ancestry) is very error-prone since patch/diff is dumber than bzr merge [15:25] cjwatson: we've been following https://wiki.ubuntu.com/UEFI/PXE-netboot-install [15:26] zyga: Somebody needs to give me a reproducible test case for the GRUB bug I've heard about [15:26] roadmr: could you simply use branches to do that? e.g. branch for a new release and selectively merge from trunk? [15:26] cjwatson: and got to a point where we have "error: variable `prefix' isn't set" [15:26] One that I can follow using KVM [15:26] cjwatson: well, if that's the stuff we're seeing we can certainly arrange something for you [15:27] Something that I can run locally [15:27] I'm not going to do this in the lab [15:27] cjwatson: I see [15:27] cyphermox: hm, so branches of lp:checkbox for each release? what happens to lp:ubuntu/checkbox then? [15:27] I need to compile test GRUB binaries and that sort of thing that's a right pain to arrange remotely [15:28] zyga: have you tried using the pre-built secure boot UEFI images? [15:28] cjwatson: no, do they support netbooting in any way? [15:28] roadmr: it would just keep track of all the uploads. if you see something different there you'd just want to merge it back in, either via a merge of by taking the diff [15:28] probably won't work either but might at least fail differently :-) [15:29] zyga: in theory [15:29] zyga: I'm not aware of any positive reports [15:29] cjwatson: ok, we are willing to try that, what should we do? [15:30] /ubuntu/dists/raring/main/uefi/grub2-amd64/current/gcdx64.efi rather than building your own with grub-mkimage [15:30] or possibly grubx64.efi, not quite sure [15:30] cjwatson: right, we'll find that [15:30] Will mobile be develop in a open model? Where is the git repository? [15:31] zyga: hmm, actually maybe this is a waste of time [15:31] zyga: I wonder if I can reproduce this problem in kvm based on that wiki page [15:33] cjwatson: so if we give you access to some hardware remotely [15:33] cjwatson: could you help us with that a little? [15:34] zyga: my experiences with remote hardware access in Canonical have been excruciatingly painful [15:34] zyga: I'm willing to go to some effort to avoid having to do that [15:35] hmm [15:35] maybe we can ship you one [15:35] no thanks [15:35] no space [15:35] zyga: can you send me the test image you're currently using - the one you built with grub-mkimage? [15:35] yeah [15:35] roadmr: ^^ [15:35] zyga: the one I built just now based on raring produces that same error message, but it's just noise and it works [15:35] ah [15:36] so that error message is probably not actually the root cause of your problem [15:36] roadmr: could we push the image to people.c.c? [15:36] cjwatson: mine uses quantal, I can certainly build a new one with raring, let me try that [15:36] zyga: we can === Tonio_ is now known as Tonio_aw [15:37] given the way this method works, it should be reproducible without actually netbooting [15:38] cjwatson: what do you mean by that? [15:38] cjwatson: you mean that it's actually just booting an ISO that was copied over the network? [15:38] the firmware is acquiring the entire thing, grub and the iso, in one giant blob [15:38] right [15:39] so given that you've got into grub, it shouldn't require any more magic to get as far as the iso [15:39] I mean nothing environment-dependent [15:39] cjwatson: this is what we were trying to use [15:39] yeah, you are right [15:39] http://people.canonical.com/~roadmr/bootx64-quantal.efi [15:39] therefore, should reproduce in kvm [15:39] put it in an otherwise empty directory, kvm -L /path/to/built/ovmf/firmware -monitor stdio -m 1024 -hda fat:/path/to/that/directory, and execute the .efi binary from the efi shell [15:39] roadmr: thanks, downloading [15:40] zyga: do you have an OVMF build? [15:41] cjwatson: yes [15:41] well, a release actually, I didn't go to build it myself [15:41] zyga: it would be worth trying with the method above to see if you get the same results that way, then [15:41] I built one for SB support, but a release should od [15:41] *do [15:41] trying === Tonio_aw is now known as Tonio_ [15:42] ok [15:42] * zyga is rusty on his efi shell [15:42] so what do I do after getting to uefi shell [15:43] fs0: [15:43] then 'dir' and you should see the name of the .efi file - you can then just type that in [15:43] ah [15:43] yeah [15:43] man, like DOS [15:43] volumes with names [15:43] nostalgia, right [15:43] yeah [15:43] works [15:43] remember, this is MODERN FIRMWARE [15:43] LOL :D [15:44] I saw that error [15:44] but now I'm in grub menu [15:44] likewise [15:45] so install hangs for me, how do I switch to kvm serial console? [15:45] ok [15:45] in the KVM window, alt-ctrl-3 [15:45] actually 2 [15:45] hmm [15:46] so I see the same error as we reported before ('error: variable `prefix isn't set.') [15:46] then ' error: no device connected. ' (repeated 8 times) [15:46] I don't see that message [15:46] what exactly is on the mini iso [15:47] what should we be seeing after grub? [15:47] well, you should get to the menu [15:48] "no device connected" is a message from GRUB's PATA driver [15:48] I tried it a number of times [15:48] and I cannot even see the kernel booting [15:48] hmm, this may be because you're (unwisely) building in every possible module rather than just the ones you need [15:48] I just tried the rescue stuff [15:49] so if one of GRUB's drivers gets stuck trying to operate some bit of hardware, it could hang [15:49] ah [15:49] that makes sense [15:49] so for the sake of exercise, which drivers should I be loading for OVMF? [15:49] let's see what minimal set would work [15:50] and which for random real hardware [15:50] give me a few minutes to experiment here [15:50] shouldn't be hardware-dependent at all [15:50] thanks, sure [15:50] I mean, the minimal set you need [15:50] after all it's loading the iso from its own image [15:54] zyga: so, for raring, instead of that `...` expression, try: all_video boot cat echo font gfxterm gzio iso9660 linux memdisk minicmd normal test video [15:54] zyga: for precise/quantal, you'd probably want to replace "all_video" with "efi_gop efi_uga" [15:54] cjwatson: ok, let me try this and get back to you [15:55] * zyga has local family/kids interrupt [16:18] stgraber: thanks, removed now [16:24] doko: a cross-buildable libnih is uploaded, but it does _not_ declare two ":native" build-deps. One can work around that by manually running: apt-get build-dep libnih; apt-get build-dep libnih -aarmhf. Wiki updated to yellow/DEP status for sbuild :native support. [16:27] jodh, libnih crossbuild fixes uploaded ^ [16:29] mpt: bdmurray has pointed out that the rank of different problems on errors.u.c can swap quite often [16:30] xnox: thanks! [16:30] we're wondering if there's a better way to handle this. Maybe a short hash of the problem instead of a ranking? [16:30] cyphermox: sorry for the delay, so say I prepare a branch of lp:checkbox with changes I want in ubuntu, how would I integrate them into lp:ubuntu/checkbox ? [16:30] so "9c3d" instead of "#10" [16:30] but you filed the original bug, so I want to make sure it covers your use cases [16:30] ev: and what would that be used for? [16:31] bdmurray: identifying issues over the phone [16:31] roadmr: you can apply the changes on the branch with a diff and upload/push, or just upload and let the importer do it [16:32] ev: would a sequence number be workable? it has the nice property that you can get a feel for how old an issue is [16:32] cyphermox: so you'd prefer to continue doing it the old way (with diff/patch) ? [16:32] (perhaps it's too late to establish that, though) [16:32] we could always back populate them [16:33] roadmr: it would be much easier if it was branches you could work with directly [16:33] ev, I suggest fixing bug 1033813 then seeing if that problem persists. [16:33] bug 1033813 in Errors "report of most common crashes "today" tracks calendar days, becomes useless when the clock rolls over" [High,Triaged] https://launchpad.net/bugs/1033813 [16:33] ev, because of that bug, early in any day, the rankings will take a while to settle. [16:34] mpt: yeah, you're absolutely right [16:34] is it still early in the day now? [16:35] cyphermox: well "internally" that's the way I do it, I branch ubuntu/checkbox and patch my changes into that, but that gap where diff has to be used is the painful part :/ [16:35] xnox, fixed ustr [16:35] because the frequency difference between many crashes is quite small [16:35] roadmr: right, but you can do away with this by using release branches and merging just the change you want when you're actually cherry-picking changes post-FF [16:36] bdmurray, yeah, there are a lot of ties, even. [16:37] bdmurray, for that reason, in bug 1068060 I suggested making "the past week" the default choice. [16:37] bug 1068060 in Errors ""the past week" is missing from table period menu" [Medium,Confirmed] https://launchpad.net/bugs/1068060 [16:38] so if that bug (default view of a week) were fixed then having the rank be a unique number would be more useful? [16:38] I think so, yes. [16:39] (Though it's hard to tell for sure, not being able to see those counts.) [16:39] RAOF, around ? [16:41] ev: would it be very challenging to see those counts? [16:44] bdmurray: when you say unique number do you mean the rank as we have it implemented or cjwatson's suggestion of using a sequence number? [16:45] ev: I meant rank as it is currently implemented (without ties) [16:45] bdrung, micahg, stgraber: hey ... I'm quite disappointed by the libreoffice ppu hostage situation, that's getting ridiculous that our maintainer who is handling for over 1.5 years and got strong endorsement from 3 coredev sponsors get rejected [16:45] so you're asking if making the week view the default is going to be challenging? [16:46] roadmr: so you tell me it still hangs, after building just few modules in [16:46] yes - we'd first need to track a rolling 7 days and implement TPUT [16:46] roadmr: can you confirm that it hangs in kvm with ovmf [16:46] we should do this though, definitely [16:46] zyga: yes, just the list cjwatson gave earlier, I get the very same error (variable 'prefix' isn't set). Sounds like a grub error to me [16:46] ev: no, how hard would it be to use pycassa to figure out the frequency values for the top 50 for a week to see if there variance in frequency would be greater than now [16:47] bdrung, micahg: what's this "lack of devel release uploads" btw? since when uploading devel release is a criterious to get upload rights? [16:47] zyga: sure, I don't have kvm with ovmf set up though so it'll take a bit [16:47] roadmr: install kvm, I'll give you the stuff to download for ovmf [16:47] because if the difference isn't greater we should move away from rank [16:47] oh, not terribly difficult. The date range selection lets us do something like that already. [16:48] oh right! ;-) [16:49] roadmr: the bit about prefix is a red herring [16:49] roadmr: people.canonical.com/~zyga/ovmf.tar.gz -- careful the tarball has no directory inside [16:49] it's basically just a minor misconfiguration such that grub tries to load something or other before it's got all its variables set up properly - but it continues on anyway [16:50] cjwatson: ok so we should focus on the next error then? error: no device connected. /me looks it up [16:51] roadmr: you sure you removed pata? what was your full grub-mkimage line? [16:52] cjwatson: http://paste.ubuntu.com/1509967/ [16:53] roadmr: please triple-check that that image is really the one you're booting, then, since it shouldn't be possible to get the message you're reporting with that configuration [16:53] i.e. the code should simply not be present [16:53] cjwatson: you're right, I dumbly forgot to move it to the proper tftpboot location :/ fixing... [16:54] \o/ [16:55] better? [16:55] zyga, cjwatson : thanks! I got a grub menu now with several install options [16:55] roadmr: try any [16:55] great [16:55] yep, trying the first one, it put me in a d-i environment, install is proceeding now [16:56] cool [16:56] roadmr: is that on the desktop that failed before? [16:56] zyga: yep, the very same [17:03] roadmr: so, what's it like? [17:04] zyga: it's like... heaven X-D [17:04] zyga: hehe install is progressing, no problems so far [17:04] cool [17:04] did you do that out of the existing certification infrastructure [17:06] zyga: yep, all I really had to change was the file that's sent to the client (in the dhcp server config) [17:06] zyga: that'd be quite easy to do with checkbox-satellite, with either a new plugin or a hack of an existing one [17:07] that's very promising [17:07] roadmr: we may need to differentiate systems [17:07] roadmr: we don't have a 'boot via efi' flag, do we? [17:07] zyga: nope, that'd be one way to do it (in c3 for instance) [17:08] roadmr: I'm not that familiar with that part of the system, how else could we do it? [17:08] zyga: for experimentation purposes we could add a parameter to launch_testrun to force efi boot for a batch of systems [17:08] roadmr: dding a flag is not easy, that involves generating message files and those come from the cert site which we don't control [17:08] zyga: I think configuring it in one place, per-system, and not worrying about it anywhere else, would be the way to go [17:08] roadmr: yeah [17:09] hey all, say I have to have different build rules for different architectures (eg, armhf and amd64)... what is the best way to do this in debian/rules? [17:10] kdub: I'd use ifeq sections === Tonio_ is now known as Tonio_aw [17:10] with a bunch of tests on DPKG_ARCHITECTURE (right?) althought I'm not recent on the cross building foo that was added everywhere [17:11] zyga, its enough to start googling though, thanks, I just wanted to make sure I'm not totally barking up the wrong tree [17:12] wookey: ^^ [17:13] cyphermox: apologies for pestering you incessantly :) I'm not too clear on how your release branches idea would ease our lives, maybe an example? [17:14] kdub,zyga: DEB_HOST_ARCH would be the variable to conditionalise on [17:14] zyga, cjwatson : install was successful, system is up and running now :D [17:14] cjwatson: thanks, I need to do some native development once in a while [17:14] roadmr: excellent [17:15] roadmr: so [17:15] (and isn't new - there's never been a DPKG_ARCHITECTURE that you might use in debian/rules, although some people might mistakenly have used DEB_BUILD_ARCH I suppose which would break under cross-building) [17:15] roadmr: oh good [17:15] roadmr: update the taskboard with the cool success story :) [17:15] zyga: yes! [17:15] and update the wiki page if you'd be so kind, too [17:15] cjwatson: ah, I was confused with dpkg-architecture that spits them out :) [17:15] cjwatson: good point [17:16] thanks cjwatson === Tonio_aw is now known as Tonio_ === Tonio_ is now known as Tonio_aw === yofel_ is now known as yofel === alexlist` is now known as alexlist [17:52] cjwatson, xnox: uploaded build-essential to b-d on python3:any. but looking at your libnih upload, python3:native might be more appropriate? just want to make sure that the interpreter can be executed [17:58] * xnox ponders if it's possible to cross-compile when the current machine arch != DEB_BUILD_ARCH. If that is possible, :any will work yet :native might not be executable. [17:59] DEB_BUILD_ARCH must be of an arch you can execute [17:59] and yes, it's possible, I do it all the time [18:00] doko: I'm not sure it makes a practical difference, THB [18:00] TBH [18:00] interesting. === henrix is now known as henrix_ [18:00] xnox: (specifically, i386 host system, amd64->armhf cross-build chroot) [18:00] (though amd64 kernel) [18:01] amd64 kernel and host system with i386->armhf cross-build chroot would work equally well === henrix_ is now known as henrix [18:05] cjwatson: Remind me of the location of your sbuild-cross wiki cheat sheet? I'm redoing my whole setup, and that's falling off my stack since I last did it. [18:07] infinity: https://wiki.ubuntu.com/CrossBuilding [18:09] cjwatson: How am I ever supposed to find wiki pages with such clear, simple, and obvious naming schemes? [18:18] when I'm making my chroot with pcreate, I can't seem to get it to take my keyring from the host's /etc/apt/trusted.db, the chroot always has the default keyring. any suggestions? === Tonio_aw is now known as Tonio_ [18:43] tkamppeter: I assume there's already a cups upload in the works that will rm_conffile /etc/logrotate.d/cups from cups? [18:43] tkamppeter: (Or some other way of avoiding the duplicate conffile between cups and cups-daemon that's making logrotate sad) === salem_ is now known as _salem [19:20] Where can I find information about the tests that are run before packages move from proposed to release? [19:22] soren: Nowhere, because none are run currently. [19:22] infinity: Oh, the autopkgtest stuff never happened? [19:23] soren: It's in progress, but it's not plugged into proposed-migration/britney yet. [19:23] Hm. Ok. I must have misinterpreted some conversations then. [19:23] infinity: Alright, cool. Thanks! [19:33] soren: Yeah, I meant to finish that integration last month but ran out of year [19:33] cjwatson: There was a lot of that going around a couple of weeks ago. [19:34] I don't even know... Are we running the auto-pkg-tests at all yet? [19:34] soren: We are, yeah. Just not tied into migration. [19:34] Cool. [19:34] Where can I see the output from those tests? [19:35] jenkins.qa.ubuntu.com [19:35] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [19:35] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [19:35] :) [19:35] hello. i wrote one or two of those tests in december [19:36] Oh, each package with autopkgtest tets get a corresponding Jenkins job? [19:37] yes [19:37] * infinity needs to sort out what to do about glibc's testsuite and kvm not getting along. [19:37] I assume it's probably actually qemu bugs, but finding and fixing those sounds like serious effort. [19:40] One thing about these tests that I haven't really worked out... Why not run the tests during the package builds so that the build can be rejected earlier? I undertand some tests will have lots more dependencies, but some of the example use cases are simply the unit tests. [19:41] soren: This isn't an either/or thing. Packages that have build-time testsuites SHOULD be running them, and absolutely SHOULD fail the build if the test fails. [19:41] soren: But autopkgtest is meant to test a slightly different thing, which is how the actual debs themselves work when installed. [19:41] infinity: So what's the benefit of adding an extra run of those same tests? [19:42] there's stuff in the autopkgtest docs about rationale [19:42] but aside from that, running them this way lets us rerun tests of reverse-dependencies when their dependencies change [19:42] soren: Running the same tests against a build tree doesn't often make sense (unless it's an rdep rebuild test, as the toolchain does), but tearing out tests and running them against installed binaries can be quite enlightening. [19:42] lets us catch the "somebody changed pygobject and it broke ubiquity" case [19:42] (say) [19:42] That makes sense. [19:43] We've been doing that in Ubuntu-server for a while, actually. [19:43] and it lets you test that the installed package is functional (that you didn't miss out a vital file) [19:43] infinity: I'ld say that a lot of software isn't designed with that in mind [19:43] Chipzz: Yes, but that's fixable. :P [19:43] We had a cron job that would take a bunch of packages, bump the version and push it to a ppa to see if the test suites still passed. [19:44] I think it has caught a few things that were introduced by changes to a library the the package in question depended on. [19:44] It's been rare, though. [19:44] infinity: it should also be documented how to run these tests. A couple of weeks ago I wanted to run a python test against my installed python, but it took me a bit to figure out how [19:45] (wasn't on ubuntu though) [19:45] Chipzz: In the later years of Maemo, Nokia QA was requiring that every single package that was part of the official published API also build a testsuite package (foo-tests depended on test-harness and foo), so their test harness could test debs on the fly. It took some wrangling to decouple tests from builds, but when coverage increased, it became obviously useful. === rickspencer3_ is now known as rickspencer3 [19:46] right. but there the tests are written with the intention of being able to run them outside the source tree [19:47] If they're fixable, we fix them. If they're not, (a) why wouldn't they be, this is free software, (b) it isn't actually mandatory to have autopkgtests [19:47] Chipzz: Usually not. The tests were often us tearing build-tree unit tests out and fixing them to not make in-tree assumptions (and skipping ones that obviously only make sense at build-time) [19:47] I have no proof for this, but I would say that the majority of tests a) isn't designed to be run that way and b) isn't even tested outside the build tree at all [19:47] Chipzz: This doesn't matter. [19:47] It's a distraction. [19:47] Anyhow, unlike Nokia, we're not mandating anything. [19:48] So, if you don't want an autopkgtest suite, don't have one. And wait for some clever fellow to come along and contribute fixes. [19:48] So, sure, it might take some work. Whatever. [19:48] It's still better than nothing. [19:48] cjwatson: not 100% sure how to interpret your statement. If you mean I'm derailing the discussion, I'll gladly shut up [19:48] I don't see what useful thing it contributes to say that some tests aren't designed for this [19:49] Yes, we know, but it's not relevant because either we fix them or we don't have autopkgtests for that package [19:49] It manifestly hasn't stopped us from having quite a number of autopkgtests already [19:49] And IME it in fact turns out that plenty of test suites already find it convenient for their own purposes to parameterise the locations of the things they're testing [19:50] Sure, not all, and there are often lots of little glitches [19:50] But it's not a doomed endeavour [19:52] autopkgtest has an option to require a built tree to be present, which lets you not have to solve the whole problem at once: you get the feature of retesting things automatically when their dependencies change, without having to fully parameterise the test suite [19:54] cjwatson: anyway my apologies. I tried to join a discussion when I was lacking some of the context I think [20:00] python testsuites are usually very well suited for autopkgtest [20:00] many run from installed locations out of the box [20:00] if the package installs them [20:01] on the otherhand many are not written for integration tests and are not particulary useful === rickspencer3_ is now known as rickspencer3 [20:09] Hi guys. I am planning to buy laptop and I wanted to ask ubuntu dev community if you have some exp with ulv cpus. Can ultrabook be a good machine for software developer ? [20:10] mterry: ping for some reason i cant get the testsuite to run for testrepository [20:11] zul: hi [20:12] lifeless: hey so i tried using make check and it doesnt work [20:12] at all [20:13] zul: make check 2>&1 | pastebinit [20:13] http://paste.ubuntu.com/1510422/ [20:13] zul: thats what you should see from a source tree. [20:13] zul, hyeo [20:14] zul, I'm in a bit of a fire-fighting mode over here, my hard drive may have died [20:14] mterry: ok ill check back later [20:15] lifeless: http://paste.ubuntu.com/1510427/ [20:15] zul: you're not running it from source? [20:16] zul: bzr branch lp:testrepository [20:16] no from the archive [20:16] oh, its not setup to dist all the ancilliary files [20:17] a quick look though suggests that that may be all thats missing, I'll add it to MANIFEST.in [20:19]