[07:22] <dholbach> good morning
[07:22] <pitti> hey dholbach, wie gehts? gut nach Hause gekommen?
[07:23] <dholbach> ja, sehr gut - und bei dir? allet schick?
[07:24] <dholbach> pitti, autopkgtest in Debian sind ja SUPER Neuigkeiten
[07:25] <pitti> dholbach: jau, hatte eine ruhige Rueckfahrt
[07:25] <pitti> dholbach: indeed!
[07:26] <dholbach> and makes it more probable for our patches to go into Debian too
[07:43] <Noskcaj> dholbach, pitti: you do realise no oe else can understand german, so not fair to us
[07:44] <dholbach> Noskcaj, we just said "hi - did you get back home alright?"
[07:44] <dholbach> nothing to worry about
[07:44] <dholbach> and there's always google translate :)
[07:44] <Noskcaj> ok
[07:44] <Noskcaj> just confusing for the rest of us
[07:45] <dholbach> it's nothing to get confused about - there've been many attempts to switch Ubuntu's main language to French in the past ;-)
[07:45] <popey> \o/ Esperanto!
[07:45] <dholbach> or that :)
[07:45] <popey> (morning)
[07:46] <dholbach> popey, that'd be "mateno" then ;-)
[07:50]  * dholbach just learned the first piece of Esperanto vocabulary
[07:50] <dholbach> somebody at UDS told me they learned Esperanto right now and went to Esperanto group meetings
[07:50] <dholbach> can't quite remember who it was though - maybe desrt?
[07:50] <pitti> yes, I think so
[07:51] <dholbach> if you change the language give me some time to prepare ;-)
[08:24] <dholbach> pitti, experimental has a new libxml2 which we could sync, but it fails to build in raring (http://paste.ubuntu.com/1334247/) - does that to you look like an issue which should be fixed in debian/ubuntu or upstream possibly? do you know if the issue is because of a new compiler or flag we use?
[08:25] <pitti> dholbach: hm, doesn't immediately ring a bell here; it could be due to our slightly changed linker behaviour (linking order); worth trying with binutils-gold in debian?
[08:26] <dholbach> pitti, do you have a pointer on how I would go about doing that?
[08:27] <pitti> dholbach: just installing binutils-gold should divert it to get used by default
[08:27] <dholbach> perfect thanks
[08:37] <dholbach> pitti, with binutils-gold in debian we're happy it seems
[08:42] <dholbach> pitti, I'll ask doko about it
[08:52]  * pitti will watch on #u-devel, to learn about this error
[10:27] <balloons> good morning all
[11:19] <xnox> can I store a test artifact in jenkins and retrieve it / compare it in a second run?
[11:20] <xnox> pitti: can I have a blanket DEP-8 tests? E.g. one thing james and I wanted to implement was running upstart check-conf on all upstart jobs.
[11:21] <pitti> xnox: what is a blanket dep-8 test?
[11:22] <pitti> xnox: oh, you could add test dependencies to all packages providing upstart jobs and then put those in debian/tests/check-package-jobs or so
[11:22] <pitti> xnox: or you put a check-conf test in all those packages
[11:23] <pitti> xnox: the third option is to not implement those as autopkgtest, but as image post-install tests
[11:25] <xnox> I understand second & third. I don't know which packages have upstart jobs though. It's non-obvious to detect.
[11:25] <pitti> xnox: grep Contents.gz for /etc/init/*.conf ?
[11:25] <xnox> pitti: do I have network to the mirror with a DEP-8 test? I could parse the contents file -> get list of interesting packages -> test them.
[11:26] <xnox> pitti: yeah, I mean I don't know the set at upstart package upload & the set changes independ on upstart.
[11:26] <pitti> you do have access to archive.u.c.
[11:26]  * xnox \0/
[11:26] <pitti> however, this seems a bit out of scope for an autopkgtest to mem
[11:27] <xnox> pitti: and blanket DEP-8 test - is something like dpkg-trigger where package $a provides tests for other packages =)
[11:27] <pitti> this really sounds more like the scope of UTAH
[11:27] <pitti> or iso post-inst tests
[11:28] <xnox> but there are upstart jobs outside of ISOs, e.g. in universe.
[11:28] <pitti> but anyway, you have apt (and apt-get source) in those tests, so go wild :)
[11:28] <pitti> you could retrieve Contents.gz, grep, then apt-get download the debs, extract them, and run checks on their jobs
[11:28] <xnox> yeah, james wanted an email notification of each new or change upstart job uploaded into the archive for a personal inspection.
[11:29]  * xnox wonders how slow / long that will be.
[11:29] <xnox> probably better as a "normal" test / job.
[11:31] <xnox> pitti: now another autopkgtest. I want to use abi-compliance-checker which will generate abi/api compatibility report. But in order to declare a library compatible it needs to compare the old report with a new one.
[11:31] <xnox> pitti: hence the earlier question of storing test artifacts in jenkins and compare them - with a second job?
[11:32] <xnox> pitti: I want something like this for Ubuntu:
[11:32] <xnox> http://upstream-tracker.org/compat_reports/mysql++/3.0.9_to_3.1.0/compat_report.html
[11:34] <xnox> Hmmm... if I ship them in the library package, I can then do the grp Contents.gz -> download -> test cycle =) as with upstart.
[11:34] <xnox> ..
[11:35] <pitti> xnox: I don't know whether/how a report can access earlier artifacts, but I wouldn't rely on that
[11:35] <pitti> I think it's better to do what the kernel does with its ABI files and store the last report in the package itself
[11:35] <xnox> So, how do you automatically add a job per package? E.g. do you have a cron-job that senses and ads adt-* jobs?
[11:35] <xnox> pitti: ack.
[11:36] <pitti> xnox: yes, https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-trigger/ scans the Sources.gz index for the XS-Testsuite: autopkgtest header
[11:36] <xnox> hah - the dep8 test could be compare -proposed with -release =)
[11:38] <pitti> that could already be done at package build time, though
[11:38] <xnox> pitti: awesome, thanks. I'll need to invest time in doing this =)
[11:38] <pitti> i. e. you keep the last official API in debian/local/api somewhere, and fail the package build on a mismatch
[11:38] <pitti> much more upstream-ish
[11:40] <xnox> pitti: that's what symbols files are for. The abi-compiance-checker does more than that though, for abi detection it needs the compiled libraries, and you don't have it for all architectures at source package built time. Only in the deb.
[11:42] <xnox> pitti: where is the code for quantal-adt-trigger?
[11:42] <pitti> http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/files/head:/jenkins/
[11:45] <xnox> it works =)
[11:45] <xnox> pitti: thanks a lot pitti.
[11:45] <pitti> no worries, thanks!
[12:48] <dholbach> pitti, xnox, for now I just filed https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1075146
[12:49] <xnox> dholbach: ack.
[12:50] <xnox> dholbach: If I were you, I'd sync in into raring-proposed. Then it would appear on all the FTBFS reports that +1 maintenance team looks at as well as britney reports etc.
[12:50] <xnox> dholbach: since it can't build, it would not propagate into raring-release nor affect any reverse-depends as they will keep on using binaries from raring-release.
[12:51] <dholbach> xnox, I was considering it but didn't want to get other people stuck because of it - I'm quite clueless to why it breaks
[12:54] <xnox> dholbach: indeed it is rather peculiar.
[14:28] <mvo> xnox: hi, silly(?) question, how can I test ubiquity bzr in a VM? I tried booting a live-cd in the VM and run it there with "sudo UQUITIY_PLUGIN_PATH=./ubiquity/plugins PYTHONPATH=. UBIQUITY_GLADE=./gtk/ui ./bin/ubiquity" but it seems like its picking up on the live-cd version of the code, not my branch - any hints you could give me?
[14:31] <xnox> mvo: that will not be enough.
[14:31] <xnox> mvo: we changed paths on the installed system.
[14:31] <xnox> mvo: what I do is this: on the host $ bzr bd
[14:31] <xnox> that will do the right thing.
[14:32] <xnox> mvo: copy the debs into /var/www; apt-ftparchive packages ./ there and install updated packages in the VM.
[14:32] <xnox> mvo: if it's just a single file, I simply wget it from the host and override the version in the guest.
[14:32] <xnox> mvo: that will be quicker.
[14:33] <xnox> and just run a system one.
[14:33] <xnox> mvo: stop lightdm ; stop ubiquity ; pkill -9 X ; start ubiquity
[14:33] <mvo> xnox: thanks, that is helpful feedback
[14:33] <xnox> to "restart" ubiquity after code changes in the VM.
[14:34] <stgraber> we really should fix the pkill -9 X part ;)
[14:34] <stgraber> (add a proper SIGTERM handler in ubiquity-dm that cleans up everything including X)
[14:35] <xnox> mvo: also these testing hints are documented at the very bottom of https://wiki.ubuntu.com/Ubiquity in case you need to look this up later.
[14:43] <mvo> xnox: thanks again !
[15:19] <balloons> ohh mvo xnox.. good stuff to know :-)
[23:52] <phillw> infinity: do you have a few minutes to help me with SRU for Chromium updates? I'm getting the general gist of it, but have a few questions :)
[23:53] <infinity> phillw: ?
[23:53] <phillw> infinity: you're posted as duty SRU person for mondays :P
[23:54] <infinity> phillw: True.  Though, chromium tends to have people handling its SRUs already.  What are you doing, exactly?
[23:55] <phillw> infinity: there are now Chromium updates landing, nor have there been for quite a while.
[23:55] <phillw> s/now/no/
[23:55] <phillw> the 'team' doing so has dissolved.
[23:56] <infinity> Well, sure, it hasn't had an update since late September.  Still, you might want to discuss it with micahg, and have him look at what you're working on.
[23:56] <phillw> thanks,