=== JasonO- is now known as JasonO === Ursinha is now known as Ursinha-afk [06:39] Good morning [06:39] test hacking day! [07:01] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-December/000999.html [07:05] morning pitti [07:07] hey elfy [07:40] good morning! [07:40] bonjour jibel [07:42] guten Morgen pitti [07:42] ready to hack? [07:42] oui, je suis! [07:43] great! [07:43] So, I did a little count this morning [07:43] I checked https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [07:44] and there are 63 packages with tests and 11 of them are failing [07:44] let see how much we can add or fix in a day [07:44] I want to work on some failing ones today [07:44] and I'm happy to review/test/sponsor contributor tests [07:47] pitti, which failing package will you start with? [07:47] I can give a try at update-manager [07:48] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-update-manager [07:48] from the log there is only 1 failing test, looks like a low hanging fruit [07:48] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-update-manager/44/ARCH=i386,label=adt/artifact/results/dsc0t-nose-tests-stdout [07:48] perfect for me :) [07:50] I'll file a bug first for this failure [07:50] jibel: it's not quite that simple, I'm afraid; it fails with two different missing packages on i386/amd64 [07:50] but it might still be simple after all, I haven't looked into it yet [07:51] pitti, right, never underestimate mvo's code ;) [07:57] I filed bug 1089793 [07:57] Launchpad bug 1089793 in update-manager (Ubuntu) "testOriginMatcherWithVersionInUpdatesAndSecurity failed withAssertionError: None == None : no package 'ecryptfs-utils' installed " [Undecided,New] https://launchpad.net/bugs/1089793 [07:59] so now, I'll prepare a fresh testing environment with prepare-testbed from lp:auto-package-testing [07:59] $ ./bin/prepare-testbed amd64 [08:03] good morning [08:03] hallo dholbach [08:03] happy automated testing day! [08:03] happy hacking day! /me gets his axe [08:03] :-) [08:04] Hey dholbach [08:04] pitti, jibel: at 9 UTC I'm going to interview didrocks for the ubuntudev hangout when do you think we should do a automated testing hangout? [08:05] I can do a hangout for about 1 minute [08:05] then google mutes me [08:05] dholbach, anytime is good [08:05] pitti, wow [08:05] pitti, did you try the nexus with android [08:05] ? [08:05] is that on raring? :-( [08:05] that sucks [08:05] yes, on raring; not sure whether that matters [08:06] jibel: I guess I could kill raring on the nexus and install android, yes [08:06] we did hangout with didrocks for hours [08:06] it was similar when I interviewed Laney - but it wasn't after 1 minute, but 3 times in a 1h hangout [08:07] I also must set g+ hangout preferences to low bandwidth despite I have a 100Mbps connection [08:12] did anyone try killing pulse before, or something like that? [08:18] I'm going to look at the eternal udisks2 hang [08:19] maybe somebody else could later on demo a few things? [08:20] it might be good to have a bit of a schedule and if we could do something in the European start of the day and maybe something in the US start of the day [08:21] jibel: I updated https://wiki.ubuntu.com/QATeam/RequiredTests to grab udisks2, and noted you down for update-manager [08:23] pitti, ack [08:23] so it's interesting, adt-run fails when running update-manager tests from the source tree when it runs dh_auto_build [08:24] it uses the wrong version of python, despite the override in the rules file [08:34] err, not amused; running the udisks Luks tests causes a kernel oops [08:37] ah, that explains the test hangs forever [08:37] I'll check if it also happens in kvm [08:41] is there a time limit on how long autopkgtests can run? [08:41] e.g. is 8 hours too much? [08:41] I'd say yes; there is only so much capacity we have in teh DC [08:41] there should probably be a restriction specifier for slow tests? [08:42] so that one can run those less often [08:42] in dep8 [08:42] autopkgtest defaults to a timeout of 2.7 h (10.000 s) for tests [08:43] that does not include the build though, if you have a test with build-needed [08:46] jtaylor: well, we can't run them less often -- they need to run on each package and dependency upload, otherwise they wouldn't do what we want them to do (prevent regressions from landing in ubuntu) [08:47] jtaylor: perhaps you can disable some very expensive tests for dep8, and then they can run manually every now and then? [08:48] couldn't you run the fast tests on every change and the slow test once a week if there was a change? [08:48] we don't have that kind of smarts ATM [08:48] or at certain milestone points [08:48] jenkins can do that easily [08:49] wel, not in ADT; we can run them as a different kind of test [08:49] right [08:52] good morning [08:52] i want to help with the simple compile/link/run tests [08:57] i'm starting at the top of the list, libatk-dev [08:57] dkessel: great! [09:00] pitti, dholbach and all, I created http://pad.ubuntu.com/testing-hackfest-20121213 to keep track of our progress [09:02] ah, so we won't use the wiki page? [09:05] it's more dynamic and easier to use for the day, then we'll update the wiki page for history [09:06] ack [09:08] mvo, about bug 1089808, I can just remove the dh_auto_build call from the override in debian/rules, right? [09:08] Launchpad bug 1089808 in update-manager (Ubuntu) "debian/rules build failed with ImportError: No module named DistUtilsExtra.command" [Undecided,New] https://launchpad.net/bugs/1089808 [09:14] jibel: let me check [09:15] jibel: yeah, that should be ok [09:16] i am trying to follow the steps on http://developer.ubuntu.com/packaging/html/auto-pkg-test.html [09:17] if i run [09:17] bzr branch ubuntu:libatk1.0-dev [09:17] jibel: are you on it or should I just do it and upload? [09:18] i get: ERROR: no branch: »bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/libatk1.0-dev/ [09:21] mvo, I was about to do it, but go for it [09:23] dkessel, I think it's bzr branch ubuntu:atk1.0 [09:24] dkessel, atk1.0 is the source package for libatk1.0-dev [09:24] oh, right [09:24] according to apt-cache showsrc libatk1.0-dev [09:24] thx [09:25] * dkessel takes notes on new commands :) [09:27] mvo, I'm on bug 1089793, you can save an upload if you wait a bit. [09:27] Launchpad bug 1089793 in update-manager (Ubuntu) "testOriginMatcherWithVersionInUpdatesAndSecurity failed withAssertionError: None == None : no package 'ecryptfs-utils' installed " [Undecided,New] https://launchpad.net/bugs/1089793 [09:27] jibel: sure, I will just commit [09:27] jibel: and wait for your ack [09:29] jibel: so just to double check, its calling py2 even when run with --with=python3? [09:29] mvo, yes [09:29] jibel: ok, commited [09:31] mvo, we had a similar issue last week with unity and fixed it with the same override http://bazaar.launchpad.net/~online-accounts/unity-scope-gdrive/trunk/view/head:/debian/rules [09:57] mvo, does apt always re-reads dpkg-status when Cache.open() is called? [09:57] mvo, I'm on test_update_origin.py in update-manager [09:57] this test testOriginMatcherWithVersionInUpdatesAndSecurity [09:57] these lines (105-122) http://paste.ubuntu.com/1429365/ [09:58] and pkg._pkg.current_ver is always None, despite the record is set to 'installed' in dpkg status [09:59] jibel: it should be [09:59] * mvo scratches head [10:05] jibel, awesome [10:09] pitti, didrocks used his tablet for the hangout as well :) [10:10] well, the sound is cutting down on my laptop machine after a minute in a hangout for some unknown reason, so yeah, have to use a tablet :) [10:10] yeah, same for me [10:10] weird that not everyone is impacted [10:12] didrocks, laney had a similar problem on tuesday, but it wasn't after a minute - "just" 3 times in an one hour hangout [10:12] 20 minutes in a average is 20 times better! :-) [10:12] quite reliably under a minute here :/ [10:12] s/in a/on a/ [10:13] I'm not impacted as I'm still on quantal on my laptop :) [10:13] I know, cheating, I know :-P [10:13] dholbach: and you tell that without being ashamed of it? :-) [10:13] I see, I see ;) [10:13] I use raring elsewhere :) [10:13] heh [10:24] mvo, I did the following test http://paste.ubuntu.com/1429399/ and current_ver is always None, any idea? [10:29] jibel: give me some minutes, I should have this ready in a bit [10:29] jibel: eh, I mean, I should be able to look in a bit, just need to finish a mail [10:31] Hi guys: Automated testing hacking right? [10:32] hello smartboyhw; yes [10:32] pitti, OK so what can I hack? [10:33] smartboyhw: if you want to start with something small, I guess adding a compile/link/run autopkgtest to a library is a good start [10:33] smartboyhw: see https://wiki.ubuntu.com/QATeam/RequiredTests for a list of library packages that need one [10:33] pitti, OK [10:33] let me remove the ones which got tests in the meantime [10:36] ok, done [10:36] I dropped the libs which have tests from https://wiki.ubuntu.com/QATeam/RequiredTests and removed stale locks [10:36] jibel: hm, could that be that there is simply the "Architecture:" missing? that is fixed in current trunk [10:37] dkessel: so you are working on libatk, right? [10:37] dkessel, smartboyhw: if you "grab" a package, please note so on http://pad.ubuntu.com/testing-hackfest-20121213, so that we avoid overlapping [10:38] jibel: I think thats it, I can upload and it should be green again, the fix is in trunk but not uploaded [10:39] mvo, that's it [10:39] pitti: yes, libatk [10:39] * jibel hugs mvo [10:39] jibel: cool, I will upload then [10:39] pitti: i tried, but i can't access it - "Either you have not been granted access to this resource or your entitlement has timed out. Please try again." [10:39] * mvo hugs jibel back :) [10:40] dkessel: ah, odd; anyway, I'll add a note for you [10:40] dkessel: this should work though standard SSO [10:41] jibel: edit wars! [10:41] pitti: not for me - tried logging out and in again... don't have any problems accessing e.g. launchpad... [10:42] * mvo hugs jibel again, just because [10:44] i get an exception in adt-run when running my test with it: http://pastebin.com/DewiGnWd [10:45] it's trying to call /usr/lib/pbuilder/pbuilder-satisfydepends-classic [10:45] dkessel: please sudo apt-get install pbuilder [10:46] it's recommended by autopkgtest, apparently you disabled recommends in apt? [10:46] pitti: oh, you're using -classic as well? I have to use that for using some options that are display in --help by unimplemented in other flavors [10:47] didrocks: it's what autopkgtest calls [10:47] ok, so we are aligned on that at least :) [10:49] * pitti uploads an udisks2 which should avoid the kernel crash and succeed again [10:51] pitti: hum, nice crash. I was telling: this is what I use in my cowbuilder to prepare the source package, but as the other build-deps or maybe not available, I'm doing it with --force-version and --continue-fail [10:51] I looked ath the software-center failures a while ago, and it seems there's a gazillion different failures; both due to real bugs, and also some because of the test environment [10:51] mvo: ^ does it make sense to fix those, or will s-c be obsoleted by the unity dash soon anyway? [10:52] pitti: apt-cache show autopkgtest says "Recommends: apt-utils" for me... not pbuilder. this is on precise... [10:53] pitti: it will be obsoleted, but I guess its still worth exploring, let me create a VM for it - raring I assume? [10:53] mvo: right [10:53] * mvo run ./bin/prepare-testbed [10:53] mvo: but I figure you can reproduce most of the failures by simply calling debian/tests/whatever locally [10:53] dkessel: ooh [10:53] dkessel: I'm afraid autopkgtest is fairly buggy on precise still [10:54] dkessel: so you might want to run prepare-testbed and run the full test in kvm [10:54] pitti: interessting, its doing ok for me, the testsuite is run before each upload but maybe my box is the only system :/ [10:54] dkessel: and for the first test you can just call debian/tests/yourtestname and ensure that succeeds, doesn't print out anything on stderr, and exits with 0 [10:55] mvo: in fact, it seems the recent runs fail even before that [10:55] mvo: a while ago the tests actually ran, with two dozen errors [10:55] now it just says "please run sudo update-apt-xapian-index", and then aborts [10:56] pitti, I might try libatk1.0-dev [10:57] smartboyhw: dkessel is working on that one [10:57] smartboyhw: see http://pad.ubuntu.com/testing-hackfest-20121213 [10:57] pitti, ok let me choose another one [10:57] smartboyhw: gdk-pixbuf perhaps, or pango? [10:58] hang on, pango ought to have one already [10:58] ah, it's missing an XS-Testsuite: header; I'll fix that [10:58] pitti, uh is there anyone who are working on libarchive-dev? [10:58] smartboyhw: we have one already, see https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [10:59] * pitti updates wiki page [10:59] pitti, please update:( [10:59] done [10:59] pitti: i have run the test already and verified the results. now i am stuck on how to run my local branch on the testbed [11:00] dkessel: did you run "prepare-testbed -r raring" already? [11:01] do i just have to run that from the package source directory? [11:02] dkessel, no, first branch the project auto-package-testing: bzr branch lp:auto-package-testing [11:02] pitti: ^ [11:02] dkessel, then cd auto-package-testing [11:02] dkessel, and prepare a test environment with: [11:02] pitti, well then: How about libsecret-1-dev? [11:02] jibel: ok, i did the preparation steps yesterday [11:03] smartboyhw: sounds good! I'll make a note in the pad [11:03] pitti, :) [11:04] dkessel, ok, did you upload a branch with your tests on bzr or its on your local disk? [11:05] jibel: i have done the preparation, but how do i run my test for libatk on it? [11:05] oh. on my local disk [11:09] dkessel: push it to LP under e. g. lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest [11:10] dkessel: and then you can call run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest [11:10] dkessel: sorry, run it like that to avoid building the package again: [11:10] run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest atk1.0 [11:10] (this is all in the documentation, btw) [11:11] dkessel, or you can start the VM with: ./bin/run-adt-test -kl [11:12] this will start the test env and log you in [11:12] then copy your files from your local drive [11:13] we should definitely add an option to copy local tests or use any VCS [11:13] yeah, that'd be convenient [11:18] pitti: ./bin/run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest atk1.0 fails with: ./bin/run-adt-test: 2: /home/daniel/workspace/auto-package-testing/bin/../etc/config: distro-info: not found [11:19] dkessel: ah, please instaoo the "distro-info" package [11:19] "install" [11:20] dkessel, it is documented here http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/doc/USAGE.md === _salem is now known as salem_ [11:23] jibel: thanks. i read http://developer.ubuntu.com/packaging/html/auto-pkg-test.html and that is missing distro-info [11:24] jibel: if run-adt-test just outputs "2012-12-13 12:24:06: Info: Cleaning up " - does that mean the test has completed without errors? [11:25] check "echo $?", it should be 0 [11:25] dkessel, if it's all you got from the run it's suspicious [11:25] err yes, it should certainly output two screenfuls of pages before that [11:25] dkessel, what's the full output, and yeah return status as pitti said [11:26] jibel, pitti: that is the full output.... [11:27] dkessel, can you run again with -d and paste the output [11:27] ? [11:29] apperently, it tries to load the image from /tmp. well - i rebooted since yesterday ;) ok, i rerun the prepare step.... but maybe it should fail with an error if it does not find the image ;) [11:30] dkessel, right, could you file a bug against https://bugs.launchpad.net/auto-package-testing please ? [11:31] you can change the location of the image cache in the config file. [11:35] pitti, a question: Would it be easier for me to use the tests available originally in libsecret? [11:35] mvo, should apt-clone testsuite run as root or normal user? [11:36] smartboyhw: if you can convince the upstream tests to run against the installed library instaed of the ones in the source tree, that's ideal of course [11:36] smartboyhw: but that is orthogonal to adding a compile/link/run test, so you might want to do both (one debian/tests/upstream and a debian/tests/compile) [11:37] pitti, ok [11:37] smartboyhw: but as long as the upstream tests run during the package build, they are not really that important to be run again in autopkgtest [11:37] it cannot hurt of course, so if you can make it work easily, please do :) [11:47] jibel: i filed bug 1089885 [11:47] Launchpad bug 1089885 in Auto Package Testing "run-adt-test silently fails when test image is missing" [Undecided,New] https://launchpad.net/bugs/1089885 [11:48] dkessel, thanks [11:48] pitti, sorry for asking (quite stupid): So in http://people.gnome.org/~stefw/libsecret-docs/c-examples.html#c-schema-example it says I need to have a header..... so I need to create another header right? [11:48] update-manager is green again \o/ [11:52] smartboyhw: no, I don't think you'll need that for a simple compile test; this isn't installed anywhere [11:52] pitti, then I need my OWN schema...... [11:52] * smartboyhw does not know how to do it....Beginner C guy here [11:56] * jibel -> lunch [11:57] jibel: enjoy! I guess you won't need the intro session :) [11:57] dholbach: ok, I have an intro prepped [11:59] jibel: udisks is green again, too! [11:59] ♩ another one bites the dust ♫ ♬ [11:59] grabbing u-d-common next [11:59] pitti: libakt's debian/control said i should edit debian/control.in instead... so i did that - now run-adt test fails with: "no such directory: ./debian/control" [12:00] dkessel: that's right, you need to edit debian/control.in and then run "debclean" [12:00] dkessel: hm, does debian/control exist? [12:00] pitti: ... and then commit and push again i guess [12:00] right [12:01] but ensure that the XS- header is in debian/control as well; debclean should do that, and then you should see it in bzr diff [12:01] ATTENTION PLEASE [12:02] I prepared a short intro about today's hackfest; for those who know about autopkgtest or are already knee-deep in it this won't be of much use, but if we have any newcomers here I'll do it now as dholbach announced in his blog [12:02] so can you please wave if you are here for the hackfest? [12:04] * dkessel (needlessly) waves :) [12:04] * pitti hugs dkessel [12:04] smartboyhw as well, but he's also already working on a test [12:05] ok, so let's cut this short [12:06] dkessel, smartboyhw: I just want to ensure that you have all the links [12:06] this document describes all the details about how to create and run tests, including a detailled example of a compile/link/run library test: [12:06] http://developer.ubuntu.com/packaging/html/auto-pkg-test.html [12:06] If you create a test, I suggest that for the first iterations you just run the debian/tests/yourtestname script on your local machine until that succeeds. Once it does, you need to run the test in a virtual machine, to ensure that it also works in that environment and you specified all necessary test dependencies. [12:06] If you start working on a package, please add a note to our coordination pad, to avoid stepping on each other's toes: [12:06] http://pad.ubuntu.com/testing-hackfest-20121213 [12:07] and finally, you can see the current tests and their status here: [12:07] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ [12:09] *tock tock*, is this thing on? [12:09] yup [12:10] smartboyhw - can you access http://pad.ubuntu.com/testing-hackfest-20121213 ? [12:10] becaus i can't [12:13] jibel: \o/ [12:16] * dkessel waits.... and waits... [12:16] how can i stop the test image from upgrading the kernel each time it starts? [12:17] there's no switch for that, I'm afraid [12:17] it's an unfortunate day, it seems we didn't get fresh cloud images today [12:21] dkessel, hmm i can:P [12:22] pitti: :( hm, i did debclean, commit and push - and it still complains about missing "debian/control" when i run: ./bin/run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest [12:24] dkessel: right, so do you have a debian/control ? [12:24] (in your source package branch) [12:25] dkessel: what's the branch you pushed this to? [12:25] I'll have a look on LP [12:25] oh, got it, https://code.launchpad.net/~d-kessel/ubuntu/raring/atk1.0/autopkgtest [12:26] ok, the file is there [12:26] * pitti runs it himself [12:26] pitti, hmm is there more easier packages to work with autopkgtest? I found this one quite hard, if I were to test it's functions [12:28] smartboyhw: poppler-dev should be more straightforward; you need to add a test dependency to a packge that ships a PDF, and can then try to open that with libpoppler, and check a few basic properties with it [12:28] pitti, OK [12:28] smartboyhw: that should provide quite a nice smoketest, and poppler doesn't have the kind of complicated callback API that libsecret has [12:29] smartboyhw: but even with libsecret, note that you don't need to do anything complicated [12:29] smartboyhw: any simple library call will do, which proves that you can compile against the library [12:29] dkessel: I get [12:30] chmod: cannot access ‘/tmp/tmp.eVTEXdaDCI/ubtree0-ubtree/debian/tests/build’: No such file or directory [12:30] adt-run: unexpected error: failed to chmod +x /tmp/tmp.eVTEXdaDCI/ubtree0-ubtree/debian/tests/build [12:30] dkessel: which is because your debian/tests/control says "Tests: build" [12:30] dkessel: but you named your script debian/tests/atk1.0-dev_test [12:30] aaaah so thats that that line means.... [12:30] :) [12:30] smartboyhw: poppler-dev should be more straightforward; you need to add a test dependency to a packge that ships a PDF, and can then try to open that with libpoppler, and check a few basic properties with itdebian/tests/atk1.0-dev_test debian/tests/build" [12:30] erk, what was that [12:30] pitti, yes I get it... [12:31] smartboyhw: sorry, weechat failure [12:31] pitti: i still wonder why you get a different error message [12:31] dkessel: so I suggest to do bzr mv debian/tests/atk1.0-dev_test debian/tests/build [12:31] dkessel: as this is the atk1.0 package, there is no doubt which package you are testing :) [12:32] dkessel: yeah :( I'm on raring, you are on precise; as I said autopkgtest on precise still has a number of bugs, that might be the problem [12:32] dkessel: perhaps you can try "wget http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_2.2.3ubuntu1_all.deb" [12:32] dkessel: and then "sudo dpkg -i autopkgtest_2.2.3ubuntu1_all.deb" [12:33] dkessel: the current versino should work just fine on precise [12:33] dkessel: ah no, I'm talking gibberish, sorry [12:33] dkessel: if you created a raring VM, it'll use autopkgtest in that VM, not locally [12:34] * dkessel running kernel upgrade :) [12:35] pitti, ok i will change my focus to poppler-dev now [12:36] pitti: can you try running it again? i fixed the file name and it still fails with "missing debian/control" here... [12:37] dkessel: sure! running [12:37] silly question - I have my testbed now but how do I log into it to try to figure out how to fix the tests in a more interactive way [12:37] mvo: what I usually do is "run-adt-test -sk ..." [12:38] mvo: that will install all the deps, run the tests, and then keep the VM running, and print an ssh command to log into it [12:38] aha, nice === Ursinha-afk is now known as Ursinha [12:38] mvo: or "run-adt-test -sl" and then do the apt-get source, install deps etc. yourself [12:38] mvo: (-s is just for speed if you have lots of RAM; -k vs. -l is the important bit here) === yofel_ is now known as yofel [12:39] but -s rocks; it's great to see 200 MB of dependencies getting unpacked and configured in like 3 seconds [12:39] pitti, the sad thing is: I can't seem to think of any packages that includes a PDF file in mind:P [12:39] sweet [12:39] dkessel: Fortschritt! http://paste.ubuntu.com/1429597/ [12:40] smartboyhw: grep '\.pdf' /var/lib/dpkg/info/*.list [12:41] pitti: i guess i have to get interactive too... [12:41] dkessel: so cups-filter's /usr/share/cups/data/default-testpage.pdf should do [12:42] dkessel: your debian/tests/control depends on libglib2.0-dev, but you want libatk1.0-dev :) [12:42] copy & paste FTW [12:42] pitti, hmm the poppler website is very short of documentation:P [12:42] dkessel: you did create a raring VM, not a precise one, right? [12:43] oopsie [12:43] pitti: yes, a raring vm [12:44] smartboyhw: file:///usr/share/doc/libpoppler-glib-dev/html/poppler/PopplerDocument.html#poppler-document-new-from-file [12:44] smartboyhw: this looks quite reasonable [12:45] smartboyhw: i. e. one call to load a file and get a PopplerDocument [12:45] smartboyhw: then maybe check file:///usr/share/doc/libpoppler-glib-dev/html/poppler/PopplerDocument.html#poppler-document-get-n-pages for the expected number of pages [12:45] pitti, OK [12:46] smartboyhw: and that should actually be enough for a c/l/r test [12:46] pitti, OK [12:46] smartboyhw: then add a dependency to cups-filters for /usr/share/cups/data/default-testpage.pdf, and there you go :) [12:46] :) [12:49] pitti: the tests are running now, I keep you updated [12:49] jibel: hm, right now jenkins runs udisks amd64 three times in parallel; comment est-ce possible? [12:50] mvo: you got beyond the "run xapian-update" thingy? [12:50] pitti, ce n'est pas possible, it's a UI bug [12:50] pitti: it should work now - but i can't verify because of the error in the VM... [12:50] * pitti turns the crank on dkessel's branch [12:51] *sigh* [12:51] it uses a blinking ball for all the jobs with the same name in the latest builds panel [12:51] jibel: yes, but I see it on three different slaves on the left side [12:52] alderamin, aldebaran, and wazn [12:52] dkessel: Bazinga! [12:53] dkessel: thank you for having shopped at Ubuntu QA Labs Inc. Please collect your free beer at the counter now! [12:53] dkessel: so I'll merge and upload this, and commit it to Debian too [12:53] pitti, on the left side, there is 1 for amd64, 1 for i386 and a virtual job with a role of controller for jenkins internal mechanics and which will consolidate the results of all the architectures [12:55] pitti: yay! thanks for the help - I'll have lunch before the beer though :) [12:56] I restarted udisk because of this hashsum mismatch error again [12:57] jibel: ah, thanks; I was about to restart it because of the hash sum error, and saw that it was already running [12:57] I don't know why it happens soooo frequently [12:57] ah, c'est vert a nouveau! [12:58] * pitti donne une accolade à udisks2 [13:02] dkessel: I add -Wall -Werror for extra nitpickyness, if you don't mind [13:02] Uh I give up..... (/me really needs to go to revise C) [13:03] jibel: hm, is it still creating new jobs properly? I fixed pango1.0's XS-Testsuite header, and it's in raring already, but not in jenkins [13:04] pitti: sure, do that. i'll be back after lunch :) [13:04] dkessel: nah, I'm doing it while merging; just a FYI [13:04] pitti, 1.30.1-1ubuntu1? let me check [13:04] jibel: oui [13:04] sometimes lillypilly is lagging a bit [13:06] pitti, I give up... [13:06] I really like manual testing more:P [13:06] pitti: well, I need to run it manually, but that I can fix easily so far two test failures [13:07] (and what looks like a hang :/ [13:08] (one releated to not having network it seems) [13:15] pitti, the mirror on lillypilly is a bit behind and only knows about 1.30.1-1 [13:15] jibel: ah ok, so it's just that; thanks for checking! [13:16] dkessel, atk1.0 2.7.2-0ubuntu2 \o/ [13:16] congrats [13:24] hey mvo, pitti :) [13:24] hey zyga, how are you? [13:25] pitti: fine, enjoying my free time :) [13:25] lots of holiday added up [13:25] oh, nice; enjoy! [13:39] jibel: yay, my first code contribution to OSS :) [13:39] so... next package ... who will it be... [13:41] dkessel: poppler? :-) [13:41] dkessel: what I suggested to smartboyhw a while ago, with poppler-document-new-from-file() and checking some properties [13:44] pitti: ok, i can give it a try [13:45] pitti, dholbach or anyone could you review https://code.launchpad.net/~jibel/apt-clone/adt-fixes/+merge/139702 [13:49] looking [13:50] jibel: did you already test it in run-adt-tes? [13:50] pitti, I did [13:50] with --user=ubuntu [13:50] it fails as root [13:51] replied [13:55] pitti, thanks, added a comment in r19 [13:56] o/ [13:56] jibel: ah, perhaps we can also fix the tests to write to stdout? [13:57] jibel: I usually use [13:57] unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2)) [13:57] pitti, this is better indeed. fixing [13:59] ah, there goes a new green "pango1.0" dot [14:03] hey jamespage [14:03] hey jibel [14:03] I noticed, dovecot, cyrus, keystone for example have dep8 tests but no testsuite header [14:04]