[06:39] <pitti> Good morning
[06:39] <pitti> test hacking day!
[07:01] <pitti> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-December/000999.html
[07:05] <elfy> morning pitti
[07:07] <pitti> hey elfy
[07:40] <jibel> good morning!
[07:40] <pitti> bonjour jibel
[07:42] <jibel> guten Morgen pitti
[07:42] <jibel> ready to hack?
[07:42] <pitti> oui, je suis!
[07:43] <jibel> great!
[07:43] <jibel> So, I did a little count this morning
[07:43] <jibel> I checked https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
[07:44] <jibel> and there are 63 packages with tests and 11 of them are failing
[07:44] <jibel> let see how much we can add or fix in a day
[07:44] <pitti> I want to work on some failing ones today
[07:44] <pitti> and I'm happy to review/test/sponsor contributor tests
[07:47] <jibel> pitti, which failing package will you start with?
[07:47] <jibel> I can give a try at update-manager
[07:48] <jibel> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-update-manager
[07:48] <jibel> from the log there is only 1 failing test, looks like a low hanging fruit
[07:48] <jibel> 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] <jibel> perfect for me :)
[07:50] <jibel> I'll file a bug first for this failure
[07:50] <pitti> jibel: it's not quite that simple, I'm afraid; it fails with two different missing packages on i386/amd64
[07:50] <pitti> but it might still be simple after all, I haven't looked into it yet
[07:51] <jibel> pitti, right, never underestimate mvo's code ;)
[07:57] <jibel> I filed bug 1089793
[07:59] <jibel> so now, I'll prepare a fresh testing environment with prepare-testbed from lp:auto-package-testing
[07:59] <jibel> $ ./bin/prepare-testbed amd64
[08:03] <dholbach> good morning
[08:03] <pitti> hallo dholbach
[08:03] <dholbach> happy automated testing day!
[08:03] <pitti> happy hacking day! /me gets his axe
[08:03] <dholbach> :-)
[08:04] <jibel> Hey dholbach
[08:04] <dholbach> 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] <pitti> I can do a hangout for about 1 minute
[08:05] <pitti> then google mutes me
[08:05] <jibel> dholbach, anytime is good
[08:05] <dholbach> pitti, wow
[08:05] <jibel> pitti, did you try the nexus with android
[08:05] <jibel> ?
[08:05] <dholbach> is that on raring? :-(
[08:05] <dholbach> that sucks
[08:05] <pitti> yes, on raring; not sure whether that matters
[08:06] <pitti> jibel: I guess I could kill raring on the nexus and install android, yes
[08:06] <jibel> we did hangout with didrocks for hours
[08:06] <dholbach> it was similar when I interviewed Laney - but it wasn't after 1 minute, but 3 times in a 1h hangout
[08:07] <jibel> I also must set g+ hangout preferences to low bandwidth despite I have a 100Mbps connection
[08:12] <pitti> did anyone try killing pulse before, or something like that?
[08:18] <pitti> I'm going to look at the eternal udisks2 hang
[08:19] <dholbach> maybe somebody else could later on demo a few things?
[08:20] <dholbach> 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] <pitti> jibel: I updated https://wiki.ubuntu.com/QATeam/RequiredTests to grab udisks2, and noted you down for update-manager
[08:23] <jibel> pitti, ack
[08:23] <jibel> so it's interesting, adt-run fails when running update-manager tests from the source tree when it runs dh_auto_build
[08:24] <jibel> it uses the wrong version of python, despite the override in the rules file
[08:34] <pitti> err, not amused; running the udisks Luks tests causes a kernel oops
[08:37] <jibel> ah, that explains the test hangs forever
[08:37] <pitti> I'll check if it also happens in kvm
[08:41] <jtaylor> is there a time limit on how long autopkgtests can run?
[08:41] <jtaylor> e.g. is 8 hours too much?
[08:41] <pitti> I'd say yes; there is only so much capacity we have in teh DC
[08:41] <jtaylor> there should probably be a restriction specifier for slow tests?
[08:42] <jtaylor> so that one can run those less often
[08:42] <jtaylor> in dep8
[08:42] <pitti> autopkgtest defaults to a timeout of 2.7 h (10.000 s) for tests
[08:43] <pitti> that does not include the build though, if you have a test with build-needed
[08:46] <pitti> 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] <pitti> jtaylor: perhaps you can disable some very expensive tests for dep8, and then they can run manually every now and then?
[08:48] <jtaylor> couldn't you run the fast tests on every change and the slow test once a week if there was a change?
[08:48] <pitti> we don't have that kind of smarts ATM
[08:48] <jtaylor> or at certain milestone points
[08:48] <jtaylor> jenkins can do that easily
[08:49] <pitti> wel, not in ADT; we can run them as a different kind of test
[08:49] <pitti> right
[08:52] <dkessel> good morning
[08:52] <dkessel> i want to help with the simple compile/link/run tests
[08:57] <dkessel> i'm starting at the top of the list, libatk-dev
[08:57] <pitti> dkessel: great!
[09:00] <jibel> pitti, dholbach and all, I created http://pad.ubuntu.com/testing-hackfest-20121213 to keep track of our progress
[09:02] <pitti> ah, so we won't use the wiki page?
[09:05] <jibel> it's more dynamic and easier to use for the day, then we'll update the wiki page for history
[09:06] <pitti> ack
[09:08] <jibel> mvo, about bug 1089808, I can just remove the dh_auto_build call from the override in debian/rules, right?
[09:14] <mvo> jibel: let me check
[09:15] <mvo> jibel: yeah, that should be ok
[09:16] <dkessel> i am trying to follow the steps on http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[09:17] <dkessel> if i run
[09:17] <dkessel> bzr branch ubuntu:libatk1.0-dev
[09:17] <mvo> jibel: are you on it or should I just do it and upload?
[09:18] <dkessel> i get: ERROR: no branch: »bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/libatk1.0-dev/
[09:21] <jibel> mvo, I was about to do it, but go for it
[09:23] <jibel> dkessel, I think it's bzr branch ubuntu:atk1.0
[09:24] <jibel> dkessel, atk1.0 is the source package for libatk1.0-dev
[09:24] <dkessel> oh, right
[09:24] <jibel> according to apt-cache showsrc libatk1.0-dev
[09:24] <dkessel> thx
[09:25]  * dkessel takes notes on new commands :)
[09:27] <jibel> mvo, I'm on bug 1089793, you can save an upload if you wait a bit.
[09:27] <mvo> jibel: sure, I will just commit
[09:27] <mvo> jibel: and wait for your ack
[09:29] <mvo> jibel: so just to double check, its calling py2 even when run with --with=python3?
[09:29] <jibel> mvo, yes
[09:29] <mvo> jibel: ok, commited
[09:31] <jibel> 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] <jibel> mvo, does apt always re-reads dpkg-status when Cache.open() is called?
[09:57] <jibel> mvo, I'm on test_update_origin.py in update-manager
[09:57] <jibel> this test testOriginMatcherWithVersionInUpdatesAndSecurity
[09:57] <jibel> these lines (105-122) http://paste.ubuntu.com/1429365/
[09:58] <jibel> and pkg._pkg.current_ver is always None, despite the record is set to 'installed' in dpkg status
[09:59] <mvo> jibel: it should be
[09:59]  * mvo scratches head
[10:05] <dholbach> jibel, awesome
[10:09] <dholbach> pitti, didrocks used his tablet for the hangout as well :)
[10:10] <didrocks> 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] <pitti> yeah, same for me
[10:10] <didrocks> weird that not everyone is impacted
[10:12] <dholbach> 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] <didrocks> 20 minutes in a average is 20 times better! :-)
[10:12] <didrocks> quite reliably under a minute here :/
[10:12] <didrocks> s/in a/on a/
[10:13] <dholbach> I'm not impacted as I'm still on quantal on my laptop :)
[10:13] <dholbach> I know, cheating, I know :-P
[10:13] <didrocks> dholbach: and you tell that without being ashamed of it? :-)
[10:13] <didrocks> I see, I see ;)
[10:13] <dholbach> I use raring elsewhere :)
[10:13] <didrocks> heh
[10:24] <jibel> mvo, I did the following test http://paste.ubuntu.com/1429399/  and current_ver is always None, any idea?
[10:29] <mvo> jibel: give me some minutes, I should have this ready in a bit
[10:29] <mvo> jibel: eh, I mean, I should be able to look in a bit, just need to finish a mail
[10:31] <smartboyhw> Hi guys: Automated testing hacking right?
[10:32] <pitti> hello smartboyhw; yes
[10:32] <smartboyhw> pitti, OK so what can I hack?
[10:33] <pitti> 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] <pitti> smartboyhw: see https://wiki.ubuntu.com/QATeam/RequiredTests for a list of library packages that need one
[10:33] <smartboyhw> pitti, OK
[10:33] <pitti> let me remove the ones which got tests in the meantime
[10:36] <pitti> ok, done
[10:36] <pitti> I dropped the libs which have tests from https://wiki.ubuntu.com/QATeam/RequiredTests and removed stale locks
[10:36] <mvo> jibel: hm, could that be that there is simply the "Architecture:" missing? that is fixed in current trunk
[10:37] <pitti> dkessel: so you are working on libatk, right?
[10:37] <pitti> 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] <mvo> jibel: I think thats it, I can upload and it should be green again, the fix is in trunk but not uploaded
[10:39] <jibel> mvo, that's it
[10:39] <dkessel> pitti: yes, libatk
[10:39]  * jibel hugs mvo
[10:39] <mvo> jibel: cool, I will upload then
[10:39] <dkessel> 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] <pitti> dkessel: ah, odd; anyway, I'll add a note for you
[10:40] <pitti> dkessel: this should work though standard SSO
[10:41] <pitti> jibel: edit wars!
[10:41] <dkessel> 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] <dkessel> i get an exception in adt-run when running my test with it: http://pastebin.com/DewiGnWd
[10:45] <pitti> it's trying to call /usr/lib/pbuilder/pbuilder-satisfydepends-classic
[10:45] <pitti> dkessel: please sudo apt-get install pbuilder
[10:46] <pitti> it's recommended by autopkgtest, apparently you disabled recommends in apt?
[10:46] <didrocks> 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] <pitti> didrocks: it's what autopkgtest calls
[10:47] <didrocks> 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] <didrocks> 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] <pitti> 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] <pitti> mvo: ^ does it make sense to fix those, or will s-c be obsoleted by the unity dash soon anyway?
[10:52] <dkessel> pitti: apt-cache show autopkgtest says "Recommends: apt-utils" for me... not pbuilder. this is on precise...
[10:53] <mvo> pitti: it will be obsoleted, but I guess its still worth exploring, let me create a VM for it - raring I assume?
[10:53] <pitti> mvo: right
[10:53]  * mvo run ./bin/prepare-testbed
[10:53] <pitti> mvo: but I figure you can reproduce most of the failures by simply calling debian/tests/whatever locally
[10:53] <pitti> dkessel: ooh
[10:53] <pitti> dkessel: I'm afraid autopkgtest is fairly buggy on precise still
[10:54] <pitti> dkessel: so you might want to run prepare-testbed and run the full test in kvm
[10:54] <mvo> pitti: interessting, its doing ok for me, the testsuite is run before each upload but maybe my box is the only system :/
[10:54] <pitti> 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] <pitti> mvo: in fact, it seems the recent runs fail even before that
[10:55] <pitti> mvo: a while ago the tests actually ran, with two dozen errors
[10:55] <pitti> now it just says "please run sudo update-apt-xapian-index", and then aborts
[10:56] <smartboyhw> pitti, I might try libatk1.0-dev
[10:57] <pitti> smartboyhw: dkessel is working on that one
[10:57] <pitti> smartboyhw: see http://pad.ubuntu.com/testing-hackfest-20121213
[10:57] <smartboyhw> pitti, ok let me choose another one
[10:57] <pitti> smartboyhw: gdk-pixbuf perhaps, or pango?
[10:58] <pitti> hang on, pango ought to have one already
[10:58] <pitti> ah, it's missing an XS-Testsuite: header; I'll fix that
[10:58] <smartboyhw> pitti, uh is there anyone who are working on libarchive-dev?
[10:58] <pitti> smartboyhw: we have one already, see https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
[10:59]  * pitti updates wiki page
[10:59] <smartboyhw> pitti, please update:(
[10:59] <pitti> done
[10:59] <dkessel> 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] <pitti> dkessel: did you run "prepare-testbed -r raring" already?
[11:01] <dkessel> do i just have to run that from the package source directory?
[11:02] <jibel> dkessel, no, first branch the project auto-package-testing: bzr branch lp:auto-package-testing
[11:02] <dkessel> pitti: ^
[11:02] <jibel> dkessel, then cd auto-package-testing
[11:02] <jibel> dkessel, and prepare a test environment with:
[11:02] <smartboyhw> pitti, well then: How about libsecret-1-dev?
[11:02] <dkessel> jibel: ok, i did the preparation steps yesterday
[11:03] <pitti> smartboyhw: sounds good! I'll make a note in the pad
[11:03] <smartboyhw> pitti, :)
[11:04] <jibel> dkessel, ok, did you upload a branch with your tests on bzr or its on your local disk?
[11:05] <dkessel> jibel: i have done the preparation, but how do i run my test for libatk on it?
[11:05] <dkessel> oh. on my local disk
[11:09] <pitti> dkessel: push it to LP under e. g. lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest
[11:10] <pitti> dkessel: and then you can call run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest
[11:10] <pitti> dkessel: sorry, run it like that to avoid building the package again:
[11:10] <pitti> run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/atk1.0/autopkgtest atk1.0
[11:10] <pitti> (this is all in the documentation, btw)
[11:11] <jibel> dkessel, or you can start the VM with: ./bin/run-adt-test -kl
[11:12] <jibel> this will start the test env and log you in
[11:12] <jibel> then copy your files from your local drive
[11:13] <jibel> we should definitely add an option to copy local tests or use any VCS
[11:13] <pitti> yeah, that'd be convenient
[11:18] <dkessel> 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] <pitti> dkessel: ah, please instaoo the "distro-info" package
[11:19] <pitti> "install"
[11:20] <jibel> dkessel, it is documented here http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/doc/USAGE.md
[11:23] <dkessel> jibel: thanks. i read http://developer.ubuntu.com/packaging/html/auto-pkg-test.html and that is missing distro-info
[11:24] <dkessel> 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] <pitti> check "echo $?", it should be 0
[11:25] <jibel> dkessel, if it's all you got from the run it's suspicious
[11:25] <pitti> err yes, it should certainly output two screenfuls of pages before that
[11:25] <jibel> dkessel, what's the full output, and yeah return status as pitti said
[11:26] <dkessel> jibel, pitti: that is the full output....
[11:27] <jibel> dkessel, can you run again with -d and paste the output
[11:27] <jibel> ?
[11:29] <dkessel> 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] <jibel> dkessel, right, could you file a bug against https://bugs.launchpad.net/auto-package-testing please ?
[11:31] <jibel> you can change the location of the image cache in the config file.
[11:35] <smartboyhw> pitti, a question: Would it be easier for me to use the tests available originally in libsecret?
[11:35] <jibel> mvo, should apt-clone testsuite run as root or normal user?
[11:36] <pitti> 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] <pitti> 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] <smartboyhw> pitti, ok
[11:37] <pitti> 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] <pitti> it cannot hurt of course, so if you can make it work easily, please do :)
[11:47] <dkessel> jibel: i filed bug 1089885
[11:48] <jibel> dkessel, thanks
[11:48] <smartboyhw> 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] <jibel> update-manager is green again \o/
[11:52] <pitti> smartboyhw: no, I don't think you'll need that for a simple compile test; this isn't installed anywhere
[11:52] <smartboyhw> 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] <pitti> jibel: enjoy! I guess you won't need the intro session :)
[11:57] <pitti> dholbach: ok, I have an intro prepped
[11:59] <pitti> jibel: udisks is green again, too!
[11:59] <pitti> ♩ another one bites the dust ♫ ♬
[11:59] <pitti> grabbing u-d-common next
[11:59] <dkessel> 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] <pitti> dkessel: that's right, you need to edit debian/control.in and then run "debclean"
[12:00] <pitti> dkessel: hm, does debian/control exist?
[12:00] <dkessel> pitti: ... and then commit and push again i guess
[12:00] <pitti> right
[12:01] <pitti> 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] <pitti> ATTENTION PLEASE
[12:02] <pitti> 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] <pitti> so can you please wave if you are here for the hackfest?
[12:04]  * dkessel (needlessly) waves :)
[12:04]  * pitti hugs dkessel
[12:04] <pitti> smartboyhw as well, but he's also already working on a test
[12:05] <pitti> ok, so let's cut this short
[12:06] <pitti> dkessel, smartboyhw: I just want to ensure that you have all the links
[12:06] <pitti> 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] <pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[12:06] <pitti> 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] <pitti> 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] <pitti>   http://pad.ubuntu.com/testing-hackfest-20121213
[12:07] <pitti> and finally, you can see the current tests and their status here:
[12:07] <pitti>   https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/
[12:09] <pitti> *tock tock*, is this thing on?
[12:09] <dkessel> yup
[12:10] <dkessel> smartboyhw - can you access http://pad.ubuntu.com/testing-hackfest-20121213 ?
[12:10] <dkessel> becaus i can't
[12:13] <mvo> jibel: \o/
[12:16]  * dkessel waits.... and waits...
[12:16] <dkessel> how can i stop the test image from upgrading the kernel each time it starts?
[12:17] <pitti> there's no switch for that, I'm afraid
[12:17] <pitti> it's an unfortunate day, it seems we didn't get fresh cloud images today
[12:21] <smartboyhw> dkessel, hmm i can:P
[12:22] <dkessel> 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] <pitti> dkessel: right, so do you have a debian/control ?
[12:24] <pitti> (in your source package branch)
[12:25] <pitti> dkessel: what's the branch you pushed this to?
[12:25] <pitti> I'll have a look on LP
[12:25] <pitti> oh, got it, https://code.launchpad.net/~d-kessel/ubuntu/raring/atk1.0/autopkgtest
[12:26] <pitti> ok, the file is there
[12:26]  * pitti runs it himself
[12:26] <smartboyhw> 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] <pitti> 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] <smartboyhw> pitti, OK
[12:28] <pitti> smartboyhw: that should provide quite a nice smoketest, and poppler doesn't have the kind of complicated callback API that libsecret has
[12:29] <pitti> smartboyhw: but even with libsecret, note that you don't need to do anything complicated
[12:29] <pitti> smartboyhw: any simple library call will do, which proves that you can compile against the library
[12:29] <pitti> dkessel: I get
[12:30] <pitti> chmod: cannot access ‘/tmp/tmp.eVTEXdaDCI/ubtree0-ubtree/debian/tests/build’: No such file or directory
[12:30] <pitti> adt-run: unexpected error: failed to chmod +x /tmp/tmp.eVTEXdaDCI/ubtree0-ubtree/debian/tests/build
[12:30] <pitti> dkessel: which is because your debian/tests/control says "Tests: build"
[12:30] <pitti> dkessel: but you named your script debian/tests/atk1.0-dev_test
[12:30] <dkessel> aaaah so thats that that line means....
[12:30] <dkessel> :)
[12:30] <pitti> 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] <pitti> erk, what was that
[12:30] <smartboyhw> pitti, yes I get it...
[12:31] <pitti> smartboyhw: sorry, weechat failure
[12:31] <dkessel> pitti: i still wonder why you get a different error message
[12:31] <pitti> dkessel: so I suggest to do bzr mv debian/tests/atk1.0-dev_test debian/tests/build
[12:31] <pitti> dkessel: as this is the atk1.0 package, there is no doubt which package you are testing :)
[12:32] <pitti> 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] <pitti> dkessel: perhaps you can try "wget http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_2.2.3ubuntu1_all.deb"
[12:32] <pitti> dkessel: and then "sudo dpkg -i autopkgtest_2.2.3ubuntu1_all.deb"
[12:33] <pitti> dkessel: the current versino should work just fine on precise
[12:33] <pitti> dkessel: ah no, I'm talking gibberish, sorry
[12:33] <pitti> dkessel: if you created a raring VM, it'll use autopkgtest in that VM, not locally
[12:34]  * dkessel running kernel upgrade :)
[12:35] <smartboyhw> pitti, ok i will change my focus to poppler-dev now
[12:36] <dkessel> pitti: can you try running it again? i fixed the file name and it still fails with "missing debian/control" here...
[12:37] <pitti> dkessel: sure! running
[12:37] <mvo> 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] <pitti> mvo: what I usually do is "run-adt-test -sk ..."
[12:38] <pitti> 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] <mvo> aha, nice
[12:38] <pitti> mvo: or "run-adt-test -sl" and then do the apt-get source, install deps etc. yourself
[12:38] <pitti> mvo: (-s is just for speed if you have lots of RAM; -k vs. -l is the important bit here)
[12:39] <pitti> but -s rocks; it's great to see 200 MB of dependencies getting unpacked and configured in like 3 seconds
[12:39] <smartboyhw> pitti, the sad thing is: I can't seem to think of any packages that includes a PDF file in mind:P
[12:39] <mvo> sweet
[12:39] <pitti> dkessel: Fortschritt! http://paste.ubuntu.com/1429597/
[12:40] <pitti> smartboyhw: grep '\.pdf' /var/lib/dpkg/info/*.list
[12:41] <dkessel> pitti: i guess i have to get interactive too...
[12:41] <pitti> dkessel: so cups-filter's /usr/share/cups/data/default-testpage.pdf should do
[12:42] <pitti> dkessel: your debian/tests/control depends on libglib2.0-dev, but you want libatk1.0-dev :)
[12:42] <pitti> copy & paste FTW
[12:42] <smartboyhw> pitti, hmm the poppler website is very short of documentation:P
[12:42] <pitti> dkessel: you did create a raring VM, not a precise one, right?
[12:43] <dkessel> oopsie
[12:43] <dkessel> pitti: yes, a raring vm
[12:44] <pitti> smartboyhw: file:///usr/share/doc/libpoppler-glib-dev/html/poppler/PopplerDocument.html#poppler-document-new-from-file
[12:44] <pitti> smartboyhw: this looks quite reasonable
[12:45] <pitti> smartboyhw: i. e. one call to load a file and get a PopplerDocument
[12:45] <pitti> 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] <smartboyhw> pitti, OK
[12:46] <pitti> smartboyhw: and that should actually be enough for a c/l/r test
[12:46] <smartboyhw> pitti, OK
[12:46] <pitti> smartboyhw: then add a dependency to cups-filters for /usr/share/cups/data/default-testpage.pdf, and there you go :)
[12:46] <smartboyhw> :)
[12:49] <mvo> pitti: the tests are running now, I keep you updated
[12:49] <pitti> jibel: hm, right now jenkins runs udisks amd64 three times in parallel; comment est-ce possible?
[12:50] <pitti> mvo: you got beyond the "run xapian-update" thingy?
[12:50] <jibel> pitti, ce n'est pas possible, it's a UI bug
[12:50] <dkessel> 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] <dkessel> *sigh*
[12:51] <jibel> it uses a blinking ball for all the jobs with the same name in the latest builds panel
[12:51] <pitti> jibel: yes, but I see it on three different slaves on the left side
[12:52] <pitti> alderamin, aldebaran, and wazn
[12:52] <pitti> dkessel: Bazinga!
[12:53] <pitti> dkessel: thank you for having shopped at Ubuntu QA Labs Inc. Please collect your free beer at the counter now!
[12:53] <pitti> dkessel: so I'll merge and upload this, and commit it to Debian too
[12:53] <jibel> 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] <dkessel> pitti: yay! thanks for the help - I'll have lunch before the beer though :)
[12:56] <jibel> I restarted udisk because of this hashsum mismatch error again
[12:57] <pitti> jibel: ah, thanks; I was about to restart it because of the hash sum error, and saw that it was already running
[12:57] <jibel> I don't know why it happens soooo frequently
[12:57] <pitti> ah, c'est vert a nouveau!
[12:58]  * pitti donne une accolade à udisks2
[13:02] <pitti> dkessel: I add -Wall -Werror for extra nitpickyness, if you don't mind
[13:02] <smartboyhw> Uh I give up..... (/me really needs to go to revise C)
[13:03] <pitti> 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] <dkessel> pitti: sure, do that. i'll be back after lunch :)
[13:04] <pitti> dkessel: nah, I'm doing it while merging; just a FYI
[13:04] <jibel> pitti,  1.30.1-1ubuntu1? let me check
[13:04] <pitti> jibel: oui
[13:04] <jibel> sometimes lillypilly is lagging a bit
[13:06] <smartboyhw> pitti, I give up...
[13:06] <smartboyhw> I really like manual testing more:P
[13:06] <mvo> pitti: well, I need to run it manually, but that I can fix easily so far two test failures
[13:07] <mvo> (and what looks like a hang :/
[13:08] <mvo> (one releated to not having network it seems)
[13:15] <jibel> pitti, the mirror on lillypilly is a bit behind and only knows about 1.30.1-1
[13:15] <pitti> jibel: ah ok, so it's just that; thanks for checking!
[13:16] <jibel> dkessel, atk1.0 2.7.2-0ubuntu2 \o/
[13:16] <jibel> congrats
[13:24] <zyga> hey mvo, pitti :)
[13:24] <pitti> hey zyga, how are you?
[13:25] <zyga> pitti: fine, enjoying my free time :)
[13:25] <zyga> lots of holiday added up
[13:25] <pitti> oh, nice; enjoy!
[13:39] <dkessel> jibel: yay, my first code contribution to OSS :)
[13:39] <dkessel> so... next package ... who will it be...
[13:41] <pitti> dkessel: poppler? :-)
[13:41] <pitti> dkessel: what I suggested to smartboyhw a while ago, with poppler-document-new-from-file() and checking some properties
[13:44] <dkessel> pitti: ok, i can give it a try
[13:45] <jibel> pitti, dholbach or anyone could you review https://code.launchpad.net/~jibel/apt-clone/adt-fixes/+merge/139702
[13:49] <pitti> looking
[13:50] <pitti> jibel: did you already test it in run-adt-tes?
[13:50] <jibel> pitti, I did
[13:50] <jibel> with --user=ubuntu
[13:50] <jibel> it fails as root
[13:51] <pitti> replied
[13:55] <jibel> pitti, thanks, added a comment in r19
[13:56] <jamespage> o/
[13:56] <pitti> jibel: ah, perhaps we can also fix the tests to write to stdout?
[13:57] <pitti> jibel: I usually use
[13:57] <pitti> unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))
[13:57] <jibel> pitti, this is better indeed. fixing
[13:59] <pitti> ah, there goes a new green "pango1.0" dot
[14:03] <jibel> hey jamespage
[14:03] <jamespage> hey jibel
[14:03] <jibel> I noticed, dovecot, cyrus, keystone for example have dep8 tests but no testsuite header
[14:04] <jibel> jamespage, maybe it's worth having a look
[14:04] <jamespage> jibel, those sounds like some easy wins!
[14:04] <jamespage> preparing my test bed now!
[14:04] <pitti> oh, ubuntu-drivers-common failure detects an actual regression in bcmwl-kernel-source
[14:06] <jibel> pitti, if I set stream=sys.stdout I still have the following warning on stderr
[14:06] <jibel> WARNING:root:can't add notification-daemon (pkg notification-daemon not marked upgrade)
[14:06] <jibel> WARNING:root:can't add notify-osd (pkg notify-osd not marked upgrade)
[14:07] <pitti> jibel: ah; no idea about them; so perhaps leave your >&2 in place for now?
[14:07] <jibel> pitti, yes, I didn't find where they come from
[14:08] <smartboyhw> God's sake my internet bandwidth is REALLY SLOW today
[14:08]  * smartboyhw reminds himself to do all the cadence testing tmr
[14:09] <jibel> another easy target in main: html2text
[14:17] <dholbach> hum
[14:17] <dholbach> https://jenkins.qa.ubuntu.com/search/?q=raring-adt seems broken
[14:17] <dholbach> it just shows 21 test-cases
[14:17] <dholbach> https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ has something like 60
[14:17]  * pitti adds another green gdk-pixbuf bullet
[14:17]  * dholbach hugs pitti
[14:18] <jibel> dholbach, 65
[14:19] <jamespage> jibel, pitti - is there a way that I can hack the testbed image to use a proxy?
[14:19] <dholbach> jibel, ah yes
[14:19] <pitti> jamespage: you can login with "run-adt-test -sl", then set up the proxy, then run "sudo ./run-adt package"
[14:20] <pitti> jamespage: (for testing)
[14:20] <pitti> jamespage: if your test itself wants to set up a proxy, it's got full root privs
[14:20] <pitti> jamespage: (if you set Restrictions: needs-root)
[14:20] <jamespage> pitti, no - I just sit on the end of a sucky internet connect and have a relatively well populated local squid-deb-proxy
[14:20] <pitti> jamespage: oh, I see
[14:21] <pitti> so prepare-testbed should grow a --mirror option
[14:21] <pitti> jamespage: ah, wait, proxy not mirror
[14:22] <jibel> jamespage, in prepare-testbed you can add an apt-proxy directive to the cloud-config script
[14:22] <pitti> jamespage: so running "http_proxy=... prepare-testbed ..." doesn't work?
[14:22] <jibel> or apt_proxy whatever it is called
[14:24] <pitti> jibel: I'm a bit confused about http://10.98.0.1:8080/view/Raring/view/AutoPkgTest/job/raring-adt-setup-testbed/52/
[14:25] <pitti> jibel: the job is red, but all 8 subtests are green
[14:27] <jibel> pitti, the provisioning failed on alderamin/i386 because a port was already in use, I forced a rebuilt of the failing image instead of everything
[14:27] <jibel> in this case the status is not propagated to the master job
[14:29] <pitti> jibel: so that'll just fix itself tomorrow then
[14:32]  * jamespage recreates his testbed
[14:39] <jamespage> jibel, pitti: thanks for that tip - hopefully that will make things a bit quicker :-)
[14:58] <jibel> pitti, a trivial one https://code.launchpad.net/~jibel/mawk/xs-testsuite tested with adt-run-test
[14:59] <jibel> I don't know why I cannot propose a merge
[15:03] <pitti> ok, u-d-common and bcmwl should be sorted out now
[15:06] <pitti> jibel: looking
[15:07] <pitti> jibel: peut-être que c'est un upstream branch
[15:07] <pitti> jibel: is it against an UDD packaging branch?
[15:08] <pitti> jibel: can you please refer to debian bug 692662 in the changelog? and then upload
[15:09]  * dkessel run-adt-tests his poppler test
[15:09] <pitti> jibel: oh, need sponsoring? je peux le faire
[15:09] <pitti> dkessel: *daumendrueck*
[15:10] <dkessel> pitti: "no such file or directory: '.debian/control' ....... again
[15:11] <pitti> dkessel: but ".debian" looks suspicious indeed
[15:11] <pitti> it should be ./debian or debian but not .debian
[15:11] <pitti> dkessel: how do you run this exactly?
[15:11] <dkessel> oh... i typed. it ... spelling error on my side
[15:11] <pitti> run-adt-test -sb  lp:~d-kessel/ubuntu/raring/atk1.0/autopkgtest atk1.0
[15:11] <pitti> that's what I ran
[15:12] <pitti> you probably need a -r raring
[15:12] <dkessel> ./bin/run-adt-test -r raring -b lp:~dkessel/ubuntu/raring/poppler/autopkgtest
[15:12] <dkessel> i'll paste the error log
[15:13] <dkessel> ah... d-kessel maybe?
[15:13] <jibel> pitti, I added a ref to debian bug 692662, and it should probably go directly there instead of ubuntu
[15:13] <pitti> jibel: fine to upload IMHO; it's very likely to get fixed with the next debian upload anyway, so we can sync it back
[15:14]  * pitti looks at samba4
[15:16] <pitti> jibel: ah, did you upload? I thought you weren't core-dev
[15:16] <jibel> pitti, no I didn't
[15:16] <jibel> and I am not a core dev
[15:16] <pitti> J'ai voir ton changement à pad
[15:17] <jibel> ah sorry
[15:17] <pitti> j'ai vu
[15:17] <jibel> reverting
[15:17] <pitti> jibel: I can upload it
[15:17] <jibel> I also readded apt-clone because it is not uploaded
[15:18] <pitti> jibel: you can push those to lp:~jibel/ubuntu/raring/pkgname/autopkgtest (i. e. to a distro branch)
[15:18] <pitti> then you can MP
[15:18] <pitti> (but don't worry about this for that one)
[15:20] <pitti> jibel: done both
[15:21] <dkessel> hm... how could i have stopped run-adt-test from building the package?
[15:21] <dkessel> poppler takes a while to build :/
[15:21] <jibel> pitti, danke schön!
[15:22] <pitti> dkessel: specify "poppler" as an additional argument at the end
[15:22] <pitti> dkessel: it's the difference between "-b branch" and "-b branch pkgname"
[15:26] <pitti> ah, samba4 est très facile
[15:26] <pitti> dkessel: want me to run a branch for you?
[15:45] <dkessel> pitti: i had a missing dependency, i am now trying to run my branch again...
[15:52] <dkessel> pitti: i guess my test just passed
[15:52] <pitti> \o/
[15:52] <pitti> dkessel: how did you get around the failure?
[15:53] <dkessel> i can't really tell...
[15:54] <dkessel> pitti: want to review https://code.launchpad.net/~d-kessel/ubuntu/raring/poppler/autopkgtest ?
[15:55] <pitti> dkessel: running
[15:55] <dkessel> pitti: i used -Wall and -Werrors this time :)
[15:55] <zyga> balloons: hey
[15:56] <zyga> balloons: would you mind if the hw cert team used this channel for all public discussions?
[15:56] <pitti> dkessel: I think you should replace libpoppler-dev, libglib2.0-dev with libpoppler-glib-dev
[15:56] <dkessel> ok
[15:56] <pitti> dkessel: actually no, you don't use poppler-glib, but just libpoppler-dev
[15:56] <pitti> dkessel: so drop the glib test dep, as you don't use it
[15:57] <pitti> dkessel: and your pkg-config calls libs poppler-glib which won't be there without libpoppler-glib-dev
[15:58] <dkessel> pitti: *confused*
[15:58] <pitti> dkessel: so, your code uses the poppler API; your pkg-config call wants poppler-glib; and your test dependency pull in poppler and glib
[15:58] <pitti> make up your mind :)
[15:59] <pitti> dkessel: in fact, if you want to write two tests, one for poppler and one for poppler-glib (with respective pkg-config and dependencies), that's even better
[16:00] <pitti> oh hm, libpoppler-dev doesn't have header files
[16:00] <pitti> thse are in libpoppler-private-dev
[16:01] <dkessel> yup
[16:01] <dkessel> pitti: that's why i went and searched for poppler.h ;)
[16:01] <pitti> dkessel: so I'm a bit confused what pulls in libpoppler-glib-dev
[16:02] <dkessel> that is where i found poppler.h
[16:02] <pitti> yes, but why does it get installed?
[16:02] <pitti> ooh
[16:02] <pitti> http://bazaar.launchpad.net/~d-kessel/ubuntu/raring/poppler/autopkgtest/revision/125
[16:02] <pitti> I was only looking at r124
[16:03] <pitti> dkessel: so yes, libpoppler-dev and libglib2.0-dev shoudl go
[16:03] <pitti> but I can do that during merge
[16:03] <pitti> dkessel: thanks! I'll upload this
[16:04] <dkessel> pitti: you're welcome. I am still not sure if my work saved anyone any time though ;)
[16:04] <pitti> oh, it does
[16:04] <pitti> and also, I hope you had some fun with it and you learned something
[16:05] <pitti> +# Author: Martin Pitt <martin.pitt@ubuntu.com>
[16:05] <pitti> dkessel: ^ you might want to fix that :)
[16:06] <dkessel> sure, I learned some stuff. And I think "two packages" was my goal for today :)
[16:06] <dkessel> ooh :)
[16:06] <dkessel> I will :D
[16:06] <pitti> then that was a good day, I say :)
[16:07] <pitti> dkessel: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-atk1.0/
[16:07] <balloons> zyga, no of course not :-)
[16:07] <balloons> it would be a good thing for people to see and know you
[16:08] <zyga> roadmr: it's set then
[16:08] <zyga> ara: o/
[16:08] <zyga> brendand: :)
[16:08] <roadmr> zyga: awesome!
[16:08] <zyga> :)
[16:08] <dkessel> pitti: juhu, grüne lampen :)
[16:08] <zyga> one step closer to building a community
[16:08] <dkessel> pitti: author is fixed
[16:09] <dkessel> is this wiki page updated after the hackfest? https://wiki.ubuntu.com/QATeam/RequiredTests
[16:09] <pitti> dkessel: danke
[16:09] <dkessel> i might do some more tests on my christmas holidays...
[16:10] <jtaylor> does the jenkins instance only build from the archive packages or can one also let it use branches to avoid uploading a package for e.g. a faulty test?
[16:10] <jibel> dkessel, not completely up to date, I'll update it with today's effort
[16:10] <pitti> jtaylor: only from the archive
[16:11] <dkessel> oh and i have another question... are there any packages which require tests written in java or c#?
[16:12] <jtaylor> dkessel: don'T limit yourself to the list, there are plenty packages in universe that need love too :)
[16:12] <pitti> in general it doesn't matter which language the tests are written in
[16:12] <pitti> but scripts are considerably easier of course as they don't have huge dependencies and don't need to be compiled
[16:13] <dkessel> i understand
[16:13] <jtaylor> c# has an interpreter
[16:14] <jtaylor> which should make writting tests a bit easier
[16:14] <jtaylor> I think it even works with hashbangs
[16:15] <dkessel> jtaylor: yeah, but I don't think I could pick one package myself that may be important to anyone...
[16:18] <dkessel> I guess I will just check by here when I want to do something more :)
[16:19] <dkessel> alright, see you guys. It has been an interesting event.
[16:19] <balloons> dkessel, thanks for hanging out with us!
[16:39] <jibel> more green dots with ubuntu-drivers-common
[16:41] <pitti> \o/
[16:41] <pitti> unfortuantely samba4 fails to build in a weird way, I'm fighting with that now
[16:48] <jibel> I'm on pbuilder and fighting with signatures :)
[16:50] <jibel> 68 tests, 2 to go to 70
[16:51] <pitti> dholbach, jibel: FYI, I need to leave in about 30 mins; in case you want to give an intro again, http://people.canonical.com/~pitti/tmp/intro.txt was what I had prepared
[16:52] <dholbach> pitti, awesome - have a great rest of your day!
[16:52] <jibel> pitti, great, thanks for your help and enjoy the evening!
[16:53] <pitti> thanks!
[17:25] <pitti> good night everyone!
[17:27] <jibel> good night pinky
[17:27] <jibel> pitti
[17:27] <pitti> uploaded a fix for the samba4 FTBFS, so hopefully that should go green, too
[17:27] <jibel> great way to end the day
[17:33] <dholbach> pitti, jibel: http://daniel.holba.ch/autopkgtests/ (I finally picked the right place to get the data about the number of raring test cases from :-))
[17:33] <dholbach> getting closer to 70 :)
[19:27] <phillw> balloons: are you about?
[19:27] <balloons> phillw, indeed
[19:28] <phillw> I've got a bug with installer, but a weird one that seems to affect only KVM running raring installs... as KVM is okay with p & Q I'm struggling to work out what to file it against?
[19:29] <balloons> you can cite ubiquity if you wish, but include kvm too
[19:29] <balloons> did you try the new version in the ppa?
[19:29] <balloons> not sure it landed in raring yet
[19:29] <balloons> I didn't check
[19:29] <balloons> kvm I mean
[19:29] <phillw> I'm running KVM on qua
[19:29] <phillw> quanatal
[19:29] <balloons> ahh
[19:29] <balloons> then you haven't got the new stuff
[19:30] <phillw> KVM in Q happily installs L, P & Q as VM's... on when trying to install R do I get the video corruption
[19:30] <phillw> s/on/only/
[19:31] <balloons> ohh
[19:31] <balloons> sorry I misunderstood your question
[19:31] <balloons> yes, blame ubiquity.. haha
[19:32] <balloons> have a look first though
[19:32] <phillw> I do recall an issue with video corruption a while back. but thought it had been resolved.
[19:32] <balloons> there is the blank screen bug already filed
[19:32] <phillw> this is not blank... just corrupt.
[19:33] <phillw> I'll re-assign it to ubiquity, I had it against lubuntu-artwork, but it also affects xubuntu - so deffo not lubuntu fault :)
[19:40] <phillw> balloons: hmm, not a ubiquity bug :/
[19:40] <phillw> video corruption still exists after installing via alternate.
[19:40] <balloons> hmm corruption when?
[19:40] <phillw> look like an X bug?
[19:40] <balloons> yes.. video corruption is not the installer
[19:41] <balloons> well, we can pinpoint it more perhaps
[19:41] <balloons> i guess xorg is fine
[19:41] <phillw> Very odd bug... the application windows work fine...
[19:41] <balloons> it might be plymouth
[19:42] <phillw> background is corrupt, and when installing from desktop the world-map where you choose where you are is corrupt.
[19:47] <balloons> ok, so might be a compiz / ubiquity bug
[19:47] <balloons> does it do that no matter how you install it?
[19:47] <balloons> aka, install now, or boot into desktop, then launch installeR/
[19:48] <balloons> they are different!
[19:50] <phillw> balloons: I battled through a desktop installation and get the corruption in the end product. alternate is less painful to install, but the resultant system is the same.
[19:51] <phillw> bug 1088692 has now got some screen shots
[19:51] <balloons> kk
[19:51] <balloons> hello letozaf_
[19:51] <letozaf_> hello :)
[19:51] <letozaf_> what are you guys doing ?
[19:52] <phillw> letozaf_: bug hunting and there is an automated hack-fest going on as well
[19:55] <letozaf_> I guess I am late for the hack-fest
[19:57] <phillw> letozaf_: shouldn't be, I believe that jibel is covering now :)
[19:59] <phillw> balloons: if you can have a look & a think. I'll be be back in 1 hour. Thanks.
[20:00] <balloons> letozaf_, yes, also working on docs
[20:00]  * SergioMeneses im back
[20:00] <balloons> have you seen the ubuntu.com/community page?
[20:00] <SergioMeneses> hey hey guys!
[20:00] <balloons> hello SergioMeneses, I owe you an email still
[20:01] <letozaf_> I'm looking at in now
[20:01] <SergioMeneses> balloons, perfect! Im working on lococouncil things but when I have time enough I see it :D
[20:01] <balloons> well, it's missing a quality page.. and as part of a drive to get all the pages updated, we have a pad: http://pad.ubuntu.com/communitywebsite-contribute-quality
[20:01] <SergioMeneses> I was reading dpm's email about the new documents, it sounds really nice
[20:02] <balloons> full details are on the wiki page: https://wiki.ubuntu.com/CommunityWebsite
[20:02] <SergioMeneses> balloons, Im working on another http://pad.ubuntu.com/communitywebsite-help-meeting-locos
[20:02] <balloons> I've started putting some stuff on there, but I'd like to get some of you folks a pass a editing it too
[20:02] <balloons> SergioMeneses, excellent!
[20:02] <balloons> phillw, when you get back you should have a look as well
[20:02] <balloons> :-p
[20:03]  * letozaf_ is reading
[20:04] <SergioMeneses> omg balloons said my name in his email, ty
[20:05] <balloons> SergioMeneses, yw
[20:15] <Noskcaj> hello, somehow my ibook is capable of being a computer so i am using it. unfortunatly i can do very little else as it has 376mb of ram
[20:15] <letozaf_> balloons: Well what can  I do to help ?
[20:15] <balloons> Noskcaj, nice
[20:15] <balloons> old machines are fun sometimes
[20:16] <balloons> letozaf_, well, feel free to edit the pad or just comment on things in it
[20:16] <Noskcaj> balloons, i dont believe you. i will joiin the pad
[20:16] <balloons> It's all my writing, and I haven't really attempted to edit it down yet
[20:18] <balloons> There's a secret inside the document.. Since it wanted links in the resources section, I thought I would make a new wiki page that could stay static and contain things of interest
[20:20] <vkottilil> hi, some questions on autopkgtest, this is my first time
[20:20] <balloons> vkottilil, sure
[20:21] <vkottilil> where should I create debian/tests/control ?
[20:21] <Noskcaj> how do i scroll in the pad? it just opens and closes the chat bar
[20:22] <jtaylor> vkottilil: in the debian package source
[20:22] <jtaylor> vkottilil: obtained e.g. with apt-get source package
[20:22] <balloons> Noskcaj, hmm.. my screen is too big, no scrollbar
[20:22] <balloons> let's see
[20:22] <balloons> ugh, yea, I can't use the scrollbars
[20:22] <balloons> I can scroll with my wheel or arrow pad
[20:22] <vkottilil> jtaylor: thanks, i just completed ./bin/prepare-testbed -r raring amd64
[20:23] <Noskcaj> i found a workaround, select the text and pull down
[20:23] <balloons> yea, similar idea
[20:23] <balloons> pg up / pg down
[20:24] <vkottilil> next, I want to run the sample test scripts already posted on the wiki for glib2.0
[20:25] <balloons> vkottilil, ok, have you installed autopkgtest?
[20:26] <balloons> sudo apt-get install autopkgtest
[20:26] <vkottilil> balloons, I thought prepare-testbed would do that?
[20:26] <balloons> ahh
[20:27] <balloons> if your using the lp branch, it's much nicer
[20:27] <balloons> prepare testbed will setup a vm to run tests
[20:27] <balloons> once it's setup, you can run the test with run-adt-test
[20:28] <vkottilil> balloons: I am using lp branch - bzr branch lp:auto-package-testing
[20:28] <balloons> ok, are you following this? http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
[20:28] <balloons> if so, tell me where your getting stuck ;-)
[20:28] <vkottilil> yes
[20:30] <vkottilil> i finished ./bin/prepare-testbed -r raring amd64, next want to run the sample script already posted for glib2.0
[20:31] <balloons> ok, so run this:
[20:32] <balloons> ./bin/run-adt-test -r quantal -a amd64 libglib2.0-0
[20:32] <balloons> I *believe* that should work for you
[20:32] <jtaylor> you probably want raring
[20:32] <balloons> bah
[20:32] <balloons> ./bin/run-adt-test -r raring -a amd64 libglib2.0-0
[20:33] <balloons> did we loose you vkottilil_ ?
[20:33] <vkottilil_> balloons:sorry, i lost the connection
[20:34] <balloons> ./bin/run-adt-test -r raring -a amd64 libglib2.0-0
[20:34] <balloons> I believe that should work for you
[20:35] <vkottilil_> where should I put the script for glib2.0 to run it?
[20:37] <jtaylor> vkottilil_: the run-adt way would be to branch glib2.0, push your changes to your local lp space and use the -b option
[20:38] <jtaylor> vkottilil_: bzr branch lp:ubuntu/glib2.0; <edit, commit>; bzr push lp:~username/+junk/branchname; run-adt-test ... -b lp:~username/+junk/branchname glib2.0
[20:38] <vkottilil_> ok, I am not changing any thing right now, just wanted to do the whole workflow to learn it, before making changes
[20:39] <jtaylor> you can run the script locally for development of the script
[20:39] <vkottilil_> ok - thats what i was looking at
[20:40] <jtaylor> there is adt-run as mentioned in the wiki
[20:40] <jtaylor> also sadtrunner.py by jwilk
[20:40] <jtaylor> I use this awful thing for chroot tests http://paste.ubuntu.com/1430489/
[20:40] <jtaylor> https://bitbucket.org/jwilk/debian-misc/src/tip/sadt
[20:41] <jtaylor> its all just bikesheeding how to run the scripts, the script itself is what is important
[20:41] <vkottilil_> ok, great, I will look at these as a starting point;
[20:42] <vkottilil_> once I can run the already posted scripts, I can add more calls/apis from a pkg and try to run them
[20:45] <vkottilil_> thank you jtaylor, balloons.
[20:48] <balloons> ty vkottilil_ .. best of luck..
[20:49] <vkottilil_> sure, thanks
[21:08] <phillw> balloons: I'm back :) Don't worry about links and notes from todays hack-fest... I have it all logged to review once I've sorted out why I cannot test Raring with KVM....
[21:09] <balloons> phillw, no worries.. come join the fun on the pad:
[21:09] <balloons> http://pad.ubuntu.com/communitywebsite-contribute-quality
[21:09] <balloons> if you haven't seen it, feedback and editing please
[21:11] <jtaylor> can tests be symlinks to other tests?
[21:13] <phillw> balloons: I'm there :)
[21:13] <jtaylor> e.g. to reuse tests for alternatives dependencies
[21:15] <balloons> :-)
[22:02] <phillw> balloons: I can confirm that CentOS is also not affected by bug 1086974 Have you any further thoughts on what I should log it against?
[22:03] <balloons> ?
[22:03] <balloons> wrong bug phillw ?
[22:04] <phillw> oops.. that is my other one!
[22:05] <phillw> bug 1088692
[22:08] <SergioMeneses> balloons, phillw you have done a great job http://pad.ubuntu.com/communitywebsite-contribute-quality
[22:08] <balloons> phillw, lol
[22:09] <balloons> ok, so on this bug, 1088692
[22:09] <balloons> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1088692
[22:09] <balloons> your on raring, what video and drivers?
[22:09] <balloons> ohh you see the same corruption on xubuntu?
[22:10] <balloons> cent os isn't the same kernel
[22:10] <balloons> does quantal have the same issue?
[22:10] <phillw> balloons: yes, that is why I removed it being lubuntu only.
[22:10] <balloons> and vice versa.. does running kvm on quantal (installing raring) work?
[22:11] <phillw> L, O & Q run perfectly. Only R is affected.
[22:11] <phillw> and 'P'
[22:13] <balloons> yes.. but that's when the host os is raring
[22:13] <phillw> balloons: the host is Quantal.
[22:13] <balloons> what about when the host os is quantal or precise?
[22:13]  * balloons rattles head
[22:13] <balloons> ok, try host os raring, installing raring
[22:14] <phillw> I have not installed raring, as the idea of the lesson I'm to hold is that you can test raring on a machine running Quantal?
[22:14] <balloons> yes.. good stuff
[22:15] <balloons> anyways, I guess that one is on me to try then
[22:15] <phillw> I will install a raring 'real' area, but it does fly in the face of using VM's to test if you cannot!
[22:16] <phillw> There is deffinately something odd with raring.
[22:19] <phillw> I can get raring to install with the quantal version (from synaptic) of virtualbox.
[22:19] <balloons> well, it's just to cover all the bases
[22:19] <balloons> I know kvm had some stuff done to it
[22:19] <balloons> so my guess is the new package works fine
[22:19] <phillw> balloons: it has had a lot done... mainly due to ubuntu realising that KVM is at the heart of cloud computing :D
[22:20] <balloons> anyways, we'll know it a moment
[22:20] <phillw> which as Canonical are a platinum partner is "slightly" embaressing :)
[22:20] <balloons> new cd is almost synced
[22:26] <balloons> ok, kvm'd with raring
[22:27] <balloons> install seems fone
[22:27] <balloons> ohh..
[22:27] <balloons> there it is
[22:27] <balloons> :-p
[22:28] <phillw> balloons: there 'what' is?
[22:28] <balloons> the bug
[22:28] <balloons> i'll be adding some screenshots
[22:29] <phillw> thank heavens for that! I even re-installed my entire system as I'd been 'playing' with KVM owing to the bug I pasted up earlier.
[22:29] <phillw> so, a click on 'affects me' and a note stating it is present in raring would really help :D
[22:30] <balloons> already doing my friend
[22:30] <phillw> now, do we have any idea of what to report it against?
[22:33] <balloons> I hate to ping xnox on this, but he will likely be able to tell us more
[22:35] <phillw> For all I know, it could be clash with gtk2 & gtk3... it's certainly like nothing I've seen before.
[23:21] <phillw> balloons: ssh -X with a speed of 76Kb/s is painful... but I think a worthwhile exercise to try raring on a full centos version of KVM
[23:21] <balloons> haha
[23:22] <balloons> full speed ahead
[23:22] <phillw> It's on my dedicated server.... it would be much faster for you to do it!
[23:23] <phillw> it has 100 Mb/s backbone.... it's like wading through treacle :(
[23:27] <phillw> balloons: you're too young to remember bulletin boards when we were running at 300 b/s
[23:28] <balloons> 2400 baud was the first for me
[23:29] <balloons> I used 14.4k/28.8k for awhile, then 56k for a long time
[23:29] <phillw> ooh, we had 300 or, if lucky the 75/1200 was just being supported. But... happy days. In those days people wrote really 'tight' code.
[23:30] <phillw> here in the lovely countryside I get not much more than 56K .... too many miles of copper to the exchange.
[23:32] <phillw> I must have a session some time with you so you can set up stuff on the server. It's doing a really good job for teams.
[23:35] <balloons> I too have find the niceities of a always on, high speed server
[23:35] <balloons> I don't have fast or slow connection.. honestly 70k isn't slow.. but by today's standards it definitely is
[23:36] <phillw> balloons: for any things using 'X' it is painful, for downloading iso's..... well it is :'(
[23:37] <phillw> It would be faster for me to get on a couple of buses, travel to my Dad's works, download it and catch the bus back.
[23:39] <jtaylor> hurray finally also managed to get a test done
[23:40] <phillw> jtaylor: congratulations! You see, they are not *that* scary :)
[23:41] <jtaylor> phillw: that is not scary? http://paste.ubuntu.com/1430814/ ;)
[23:41] <jtaylor> (its not the one I forwarded right now, thats a lot nicer)
[23:42] <jtaylor> bug 695881 is what I did today
[23:42] <jtaylor> debian bug 695881
[23:43] <phillw> jtaylor: when you are writing stuff, it seems scary. I am a fiend for making 2 comment lines per line of code... but that's so when I look at the code 2 years later, it tells me what on earth was in my mind when I wrote it :P
[23:43] <jtaylor> phillw: yeah, that particular one is still in development, I'll comment it before the upload
[23:44] <jtaylor> the symlink crazyness is due to the package not installing the tests and python relative imports preventing just copying the tests from the source
[23:44] <phillw> jtaylor: your older self will thank you for doing so.... on that matter, you'll just have to trust me :)
[23:46] <phillw> I look back at some of the 'one off' sections of code I've written and really could not follow it without the comments.
[23:48] <jtaylor> the wiki could probably use a python dep8 test example
[23:48] <jtaylor> very many python packages can be tested the same way
[23:50] <jtaylor> e.g.: https://github.com/neurodebian/pandas/blob/debian/debian/tests/unittests
[23:50] <jtaylor> just I'd now add pys=${pys:-$(...)} so it can be reused in debian/rules too
[23:51] <phillw> jtaylor: I'm not a python person, I'm PHP, but as python / perl / php can all achieve similar results when 'chatting' to MySQL it is fortunate that they all start in 'P' for LAMP.
[23:52] <phillw> jtaylor: but, as for commenting your code?... http://forum.phillw.net/viewtopic.php?f=5&t=80