[00:00] 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] and then fixing things ... [00:01] doko: OK, cool. Thanks! [00:03] http://askubuntu.com/questions/829652/build-my-own-ubuntu-iso - putting a bounty on it tomorrow if it doesn't get answered [00:06] smoser: oh dear, that's a regression from my recent work, could you please file a bug against Launchpad itself about that? [00:06] smoser: (that oops) [00:18] doko, Odd_Bloke i'll take a look tomorrow [00:19] 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] And definitely make that page not OOPS if there's no DSP, since after all the bugtask already exists. [00:35] doko: just sent debian a potential fix for mako === salem_ is now known as _salem === happyaro1 is now known as happyaron [01:00] pitti: it's fine for me, better if you can upload master to get 1.2.4 available in yakkety [01:00] (was on long flight [01:05] 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] nacc: mako is a debian bug?! ;) [02:39] mwhudson: maas you say ? [02:42] roaksoax: i did, but i am probably being silly [02:45] mwhudson: hehe ok, just wondering what crossed your mind :) [02:45] roaksoax: instead of pointing autopkgtest at nova, or qemu or schroot, why not a maas? === hikiko_ is now known as hikiko [05:14] happyaron: thanks! yes, I can upload 1.2.4 (but still frozen for beta); did you already test that version? === andrewsh_ is now known as andrewsh [05:39] mako: ha! didn't even try to tab-complete, I apologize if you got some random highlights there :) === dpm is now known as dpm-afk [07:45] pitti: hi, do you have autopkgtest backport for xenial somewhere? [07:45] or should I just install the yak version [07:45] probably will upgrade to it soon anyway [07:45] autopkgtest | 4.0.2~ubuntu16.04.1 | xenial-backports | source, all [07:45] oh [07:45] hehe [07:45] tjaalton: it's not the very latest version, but it should do for most stuff [07:46] cool [07:46] but a good reminder to update it [07:46] (also for trusty) [07:46] i got confused with some documentation saying to run 'autopkgtest' while xenial had adt-*, and then read the blog post [07:48] tjaalton: I uploaded 4.0.5 to t/x-backports now [07:48] thanks [07:54] pitti: is that tar: Unexpected EOF in archive in copyup thing still a mystery? [07:54] mwhudson: yes, it is [07:54] it's happened to me on more than half of my runs today [07:54] two free beer for the person who debugs it :) [07:55] 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] pitti: hints at where to start? (for tomorrow) [08:03] 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] 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] pitti: i see [08:07] mwhudson: that is done in lib/VirtSubproc.py, the copy_* [08:07] sil2100, please ping if you work on filezilla [08:07] s/ sil2100 / Adri2000 [08:08] or ack an upload, I already have imported it in my personal git repo [08:15] * sil2100 does not ping [08:15] ;) [08:15] I am, however, working on the zeromq3 pyzmq autopkgtest failure however [08:15] uh [08:15] -however [08:45] tumbleweed, can I ask you a few questions about this page? http://people.ubuntuwire.org/~stefanor/ubuntu-activity/ [08:45] I'm listed with my nick and with my name-surname [08:45] do you know why? [08:45] my launchpad account has my debian email registered [08:52] LocutusOfBorg: hi, you mean filezille for ubuntu? [08:52] filezilla [08:53] mwhudson: thanks for the docker update in xenial, seems to work in my (quite simple) setup [08:53] jtaylor: glad to hear it [08:53] have you looked at using the new --live-restore to restart the service in package upgrade [08:53] and yeah, the autopackage tests are happy [08:53] ah is that in 1.12? [08:53] I've been using it on a few machines with upstream docker and it seems to work for me [08:54] yes [08:54] tianon: hi :-) [08:54] Adri2000, also Debian [08:55] I would like to upload libfilezilla and then filezilla [08:56] if you agree I can git push [08:57] I already have the upload ready [09:12] Adri2000, back, sorry [09:14] LocutusOfBorg: sorry I'm a bit busy, but go ahead I trust you :) [09:15] uploading and git pushing [09:15] BTW can you please apply for DM? [09:16] uploaded and filezilla in deferred/1 === hikiko is now known as hikiko|ln === marcoceppi_ is now known as marcoceppi === maxb_ is now known as maxb === hikiko|ln is now known as hikiko === mp is now known as Guest73139 === dpm-afk is now known as dpm === _salem is now known as salem_ [13:16] cjwatson, you still need a bug filed ? === jasondotstar_ is now known as jasondotstar [13:18] cjwatson, well, filed. feel free to close or dupe. [13:18] https://bugs.launchpad.net/launchpad/+bug/1628091 [13:18] Launchpad bug 1628091 in Launchpad itself "oops when loading bug" [Undecided,New] [13:23] 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] digging. must be https://launchpad.net/~canonical-partner-dev [13:29] 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] just not going to submit "in progress" results any more, and will just push out pass/fail [14:42] mvo: Did you get a chance to look at those unattended-upgrades bugs? === PaulW2U_ is now known as PaulW2U === daniel1 is now known as Odd_Bloke [15:40] 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] kenvandine, happy birthday! :) [15:40] xnox: doesn't require a save() since that's creating a new object as opposed to modifying one [15:40] dholbach, thanks! [15:48] 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] 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] happy birthday kenvandine ! [16:04] indeed, Happy Birthday kenvandine === daniel is now known as Guest11181 === Guest11181 is now known as Odd_Bloke [16:38] pitti: thanks for the upload, tested :) === Elimin8r is now known as Elimin8er === Serge is now known as Guest37289 === xnox_ is now known as xnox === ChrisTownsend1 is now known as ChrisTownsend === superm1_ is now known as superm1 === Eleventh_Doctor is now known as Pharaoh_Atem === popey_ is now known as popey === rumble is now known as grumble === rmk` is now known as rmk === lynxman_ is now known as lynxman === sforshee` is now known as sforshee === beisner- is now known as beisner === ]reed[ is now known as [reed] === Adri2000_ is now known as Adri2000 === cjwatson_ is now known as cjwatson === giraffe is now known as Guest12963 === Elimin8r is now known as Elimin8er === lynxman_ is now known as lynxman === semiosis_ is now known as semiosis === Guest37289 is now known as hallyn [17:21] 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] oh no, it just fails later :) === juliank_ is now known as juliank === mellotron is now known as Guest56332 [17:27] doko: sorry, i am actually trying to help, but probably making more noise than helping :) === kees_ is now known as kees [17:29] 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] doko: totally fine -- seabios one seems odd, as debian isn't seeing it, afaict === rmk` is now known as rmk === Spads_ is now known as Spads === vrruiz_ is now known as rvr [17:38] doko: ah, it might be this line [17:38] movl (MainThread@GOTOFF(%ebp)), %esp [17:44] yes, that does seem to be it, something is being more pedantic about extra parens now [17:44] still fails to link, but gets further [18:22] doko: ok, xen ftbfs (i think you're already aware) is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812166 [18:22] Debian bug 812166 in xen "xen: FTBFS with GCC 6: statement is indented as if..." [Serious,Open] [18:22] arges_, hi, would you be able to review the openstack packages in the xenial queue tomorrow? [18:23] coreycb: sure [18:23] arges_, thanks === sforshee` is now known as sforshee [18:42] apw, ogasawara: fyi, https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1628207 [18:42] Launchpad bug 1628207 in gcc-5 (Ubuntu Xenial) "boot arguments passed in CONFIG_CMDLINE not being picked up by kernel with gcc-ppc64-linux-gnu v5.4.0 and v6.1.1" [High,New] === popey_ is now known as popey [19:09] 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 [19:09] Launchpad bug 1578193 in network-manager-strongswan (Ubuntu) "cannot load legacy-only plugin" [Undecided,Confirmed] === beisner- is now known as beisner === DrKranz is now known as DktrKranz === Cimi_ is now known as cimi === ivoks_ is now known as ivoks === philroche_ is now known as philroche === johnlage_ is now known as johnlage === PaulW2U is now known as Guest66500 === PaulW2U_ is now known as PaulW2U === DrKranz is now known as DktrKranz === nobuto_ is now known as nobuto === robert_ancell_ is now known as robert_ancell [22:51] 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] 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] 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] i apologize if that's confusing, i can clarify it with specific examples, etc