[00:00] <doko> Odd_Bloke: basically test building everything with a python dependency twice, once with the current packages, and the proposed packages, on all archs (but main only)
[00:00] <doko> and then fixing things ...
[00:01] <Odd_Bloke> doko: OK, cool.  Thanks!
[00:03] <tsimonq2> http://askubuntu.com/questions/829652/build-my-own-ubuntu-iso - putting a bounty on it tomorrow if it doesn't get answered
[00:06] <cjwatson> smoser: oh dear, that's a regression from my recent work, could you please file a bug against Launchpad itself about that?
[00:06] <cjwatson> smoser: (that oops)
[00:18] <barry> doko, Odd_Bloke i'll take a look tomorrow
[00:19] <cjwatson> Mostly I think because DistributionSourcePackage.ensure doesn't create an in-DB DSP record for publications in partner, but we may also need to make sure that packages that haven't had a fresh upload since ~2010 have such records too.
[00:20] <cjwatson> And definitely make that page not OOPS if there's no DSP, since after all the bugtask already exists.
[00:35] <nacc> doko: just sent debian a potential fix for mako
[01:00] <happyaron> pitti: it's fine for me, better if you can upload master to get 1.2.4 available in yakkety
[01:00] <happyaron> (was on long flight
[01:05] <happyaron> pitti: as for the 802.1x key issue I'm modifying the description as upstream expect only p12 being fixed, and open another report to track remaining stuff
[02:00]  * mwhudson wonders about a 'maas' autopkgtest backend
[02:16] <mako> nacc: mako is a debian bug?! ;)
[02:39] <roaksoax> mwhudson: maas you say ?
[02:42] <mwhudson> roaksoax: i did, but i am probably being silly
[02:45] <roaksoax> mwhudson: hehe ok, just wondering what crossed your mind :)
[02:45] <mwhudson> roaksoax: instead of pointing autopkgtest at nova, or qemu or schroot, why not a maas?
[05:14] <pitti> happyaron: thanks! yes, I can upload 1.2.4 (but still frozen for beta); did you already test that version?
[05:39] <nacc> mako: ha! didn't even try to tab-complete, I apologize if you got some random highlights there :)
[07:45] <tjaalton> pitti: hi, do you have autopkgtest backport for xenial somewhere?
[07:45] <tjaalton> or should I just install the yak version
[07:45] <tjaalton> probably will upgrade to it soon anyway
[07:45] <pitti> autopkgtest | 4.0.2~ubuntu16.04.1  | xenial-backports | source, all
[07:45] <tjaalton> oh
[07:45] <tjaalton> hehe
[07:45] <pitti> tjaalton: it's not the very latest version, but it should do for most stuff
[07:46] <tjaalton> cool
[07:46] <pitti> but a good reminder to update it
[07:46] <pitti> (also for trusty)
[07:46] <tjaalton> i got confused with some documentation saying to run 'autopkgtest' while xenial had adt-*, and then read the blog post
[07:48] <pitti> tjaalton: I uploaded 4.0.5 to t/x-backports now
[07:48] <tjaalton> thanks
[07:54] <mwhudson> pitti: is that tar: Unexpected EOF in archive in copyup thing still a mystery?
[07:54] <pitti> mwhudson: yes, it is
[07:54] <mwhudson> it's happened to me on more than half of my runs today
[07:54] <pitti> two free beer for the person who debugs it :)
[07:55] <mwhudson> so if there's anything i can do to help debug it i am (a) willing (b) apparently able
[07:55]  * pitti ups the ante -- plus a free hug!
[08:01] <mwhudson> pitti: hints at where to start? (for tomorrow)
[08:03] <pitti> mwhudson: since this only happens with qemu, I suspect that there is some race condition/bug with the "9p" file system in qemu (setup_shared() in virt/autopkgtest-virt-qemu); this sets up a shared mount between the guest and the host for copying around packages, results, logs etc.
[08:06] <pitti> mwhudson: and I use tar in between, as 9p sucks for lots of small files (it's liek 10x to 30x faster with a single big tar)
[08:07] <mwhudson> pitti: i see
[08:07] <pitti> mwhudson: that is done in lib/VirtSubproc.py, the copy_*
[08:07] <LocutusOfBorg> sil2100, please ping if you work on filezilla
[08:07] <LocutusOfBorg> s/ sil2100 / Adri2000
[08:08] <LocutusOfBorg> or ack an upload, I already have imported it in my personal git repo
[08:15]  * sil2100 does not ping
[08:15] <sil2100> ;)
[08:15] <sil2100> I am, however, working on the zeromq3 pyzmq autopkgtest failure however
[08:15] <sil2100> uh
[08:15] <sil2100> -however
[08:45] <LocutusOfBorg> tumbleweed, can I ask you a few questions about this page? http://people.ubuntuwire.org/~stefanor/ubuntu-activity/
[08:45] <LocutusOfBorg> I'm listed with my nick and with my name-surname
[08:45] <LocutusOfBorg> do you know why?
[08:45] <LocutusOfBorg> my launchpad account has my debian email registered
[08:52] <Adri2000> LocutusOfBorg: hi, you mean filezille for ubuntu?
[08:52] <Adri2000> filezilla
[08:53] <jtaylor> mwhudson: thanks for the docker update in xenial, seems to work in my (quite simple) setup
[08:53] <mwhudson> jtaylor: glad to hear it
[08:53] <jtaylor> have you looked at using the new --live-restore to restart the service in package upgrade
[08:53] <mwhudson> and yeah, the autopackage tests are happy
[08:53] <mwhudson> ah is that in 1.12?
[08:53] <jtaylor> I've been using it on a few machines with upstream docker and it seems to work for me
[08:54] <jtaylor> yes
[08:54] <mwhudson> tianon: hi :-)
[08:54] <LocutusOfBorg> Adri2000, also Debian
[08:55] <LocutusOfBorg> I would like to upload libfilezilla and then filezilla
[08:56] <LocutusOfBorg> if you agree I can git push
[08:57] <LocutusOfBorg> I already have the upload ready
[09:12] <LocutusOfBorg> Adri2000, back, sorry
[09:14] <Adri2000> LocutusOfBorg: sorry I'm a bit busy, but go ahead I trust you :)
[09:15] <LocutusOfBorg> uploading and git pushing
[09:15] <LocutusOfBorg> BTW can you please apply for DM?
[09:16] <LocutusOfBorg> uploaded and filezilla in deferred/1
[13:16] <smoser> cjwatson, you still need a bug filed ?
[13:18] <smoser> cjwatson, well, filed. feel free to close or dupe.
[13:18] <smoser> https://bugs.launchpad.net/launchpad/+bug/1628091
[13:23] <smoser> hey, does anyone know what group or acl i need to have to upload to parter?  at the moment i cannot accept nomination for bugs in a partner package. so i assume that related to upload. anyone know?
[13:24] <smoser> digging. must be https://launchpad.net/~canonical-partner-dev
[13:29] <xnox> stgraber, is there a trick / sample code for updating QATracker result? I called add_result, but doing .result='Passed' and .save() on the object it returns fails with invalid RPC request =(
[13:30] <xnox> just not going to submit "in progress" results any more, and will just push out pass/fail
[14:42] <bdmurray> mvo: Did you get a chance to look at those unattended-upgrades bugs?
[15:40] <stgraber> xnox: I've not used that code in years, but looks like you need a valid build object, then can do .add_result(testcase, "passed")
[15:40] <dholbach> kenvandine, happy birthday! :)
[15:40] <stgraber> xnox: doesn't require a save() since that's creating a new object as opposed to modifying one
[15:40] <kenvandine> dholbach, thanks!
[15:48] <xnox> stgraber, fair enough. Originally i was trying to testresult = build.add_result(testcase, "in progress") and then testresult.result="passed" if good else "Failed"; testresult.save() but that didn't work. Anyway, nobody else but me tests s390x anyway, so there is like zero chance of duplicate testing efforts =)
[16:02] <slangasek> stgraber: ah, you're around - TB meeting? you're listed as chairing
[16:03]  * ogra_ welcomes kenvandine to the "old farts club" and hands him a beer labeled "for grown ups" 
[16:03] <ogra_> happy birthday kenvandine !
[16:04] <josepht> indeed, Happy Birthday kenvandine
[16:38] <happyaron> pitti: thanks for the upload, tested :)
[17:21] <nacc> doko: i know very little about seabios, but i can reproduce the ftbfs. It seems like if i manually run make, it fails. If i rerun the same cc line, but append -S, then run make again, it finishes ... any idea?
[17:21] <nacc> oh no, it just fails later :)
[17:27] <nacc> doko: sorry, i am actually trying to help, but probably making more noise than helping :)
[17:29] <doko> nacc: I'm trying to ignore you ;p No, really, am at a conference, so I'm looking at irc only from time to time
[17:30] <nacc> doko: totally fine -- seabios one seems odd, as debian isn't seeing it, afaict
[17:38] <nacc> doko: ah, it might be this line
[17:38] <nacc>   movl (MainThread@GOTOFF(%ebp)), %esp
[17:44] <nacc> yes, that does seem to be it, something is being more pedantic about extra parens now
[17:44] <nacc> still fails to link, but gets further
[18:22] <nacc> doko: ok, xen ftbfs (i think you're already aware) is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166
[18:22] <coreycb> arges_, hi, would you be able to review the openstack packages in the xenial queue tomorrow?
[18:23] <arges_> coreycb: sure
[18:23] <coreycb> arges_, thanks
[18:42] <doko> apw, ogasawara: fyi, https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1628207
[19:09] <rharper> dupondje_: any chance you can test out the updated packages in the strongswan-plugin bug? https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193
[22:51] <bdmurray> xnox: Is there anything out of date with this? https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeFetcherCore.py#L80
[23:51] <nacc> ok, so i'm trying to sru a package (pollinate) back to {12,14,16}.04. I understand the versioning to use. However, in this particular case, I'm SRU'ing the yakkety version back to all 3. It seems that the way this was done in the prior SRU was to basically drop debian/changelog from the target series altogether and just append a changelog entry for the SRU. (so all 3 prior SRUs look like single
[23:52] <nacc> changelog entries after the prior yakkety version. It's confusing to do it that way, but so be it. I was wondering if that was 'expected'. Additionally, if, given that we're actually SRU'ing a jump of two upstream releases, should there be two changelog entries? Or is it sufficient for me to say 'New upstream release (LP: #...) and just provide the changelog of both in one long(er) entry?
[23:52] <nacc> i apologize if that's confusing, i can clarify it with specific examples, etc