[05:44] <cpaelzer> good Morning
[05:48] <pitti> Good morning
[05:48] <pitti> robru, Saviq: ah, makes sense
[06:53] <pitti> mwhudson: it's not, looking
[06:53] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/xenial/2016-09-16/06:46:39.log
[06:55] <mwhudson> pitti: awesome
[06:58] <pitti> so xenial/Packages_arm64 has *two* Package: entries for liboxideqt-qmlplugin
[06:59] <pitti> the regular one and some "faux" thingy: http://paste.ubuntu.com/23185246/
[06:59] <pitti> (not on any other arch)
[07:01] <pitti> so the breakage matches the time of publishing https://launchpad.net/ubuntu/+source/oxide-qt/1.17.7-0ubuntu0.16.04.1
[07:01] <pitti> cjwatson, infinity: ^ do you happen to have an idea what these "faux" packages are?
[07:02] <pitti> find -name faux-packages → nothing
[07:05] <pitti> actually, britney2 does not write the Packages_*, so that must be britney1 already
[07:08] <pitti> aah!
[07:08] <pitti> http://bazaar.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/revision/264
[07:10] <pitti> so the difference is that the previous https://launchpad.net/ubuntu/+source/oxide-qt/1.16.5-0ubuntu0.16.04.1 just didn't build on arm64 yet, and we have these crutches
[07:10] <pitti> but 1.17.7 was pushed to xenial only, *not* to yakkety yet
[07:10] <pitti> chrisccoulson: ^ fail :(
[07:11] <pitti> so I remove the fauxpkg entry as it actually should build on yakkety now, to unbreak xenial britney runs
[07:11] <pitti> it might block some yakkety progressions, but the new oxide must land in yakkety ASAP anyway to unbreak  upgrades
[07:14] <pitti> mwhudson: ok, britney 1 fauxpkg list update pushed
[07:14] <pitti> thanks for pointing out
[07:15] <mwhudson> pitti: fun times, thanks for fixing
[07:27] <pitti> mwhudson: hah, and there it goes: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html
[07:44] <chrisccoulson> pitti, oh, I did ping tyhicks about sponsoring that
[07:45] <chrisccoulson> I can't upload my own package to y, despite being able to copy it to security everywhere else
[08:25] <pitti> chrisccoulson: oh, oops :) I can upload as well
[08:29] <chrisccoulson> pitti, that would be great. It's currently sat on in https://private-fileshare.canonical.com/~chrisccoulson/
[08:29] <chrisccoulson> (sorry for breaking things)
[08:30] <pitti> chrisccoulson: no worries, the fauxpkg thing was not your fault :)
[08:31] <pitti> urgh, 485 MB orig.tar
[08:31] <chrisccoulson> oh, that seems smaller than usual
[08:31] <pitti> I guess I better check/sign/verify this in the data center :)
[08:32] <chrisccoulson> The last one was nearly 600MB. I guess some stuff got removed from the chromium tree
[08:34] <pitti> chrisccoulson: meh, can't dput from private-fileshare
[08:34] <chrisccoulson> pitti, I don't mind uploading it from somewhere else
[08:34] <pitti> chrisccoulson: nevermind, I'll just suck it up and let it upload for half an hour
[08:34] <pitti> easier than wasting human time on this :)
[08:35] <chrisccoulson> it only takes a few minutes for me to upload. I can push it to a machine that you can dput from :)
[08:35] <pitti> nah, it's fine
[08:35] <pitti> chrisccoulson: I don't actually need to upload the orig, it's already in the archive
[08:35] <pitti> so -sd is enough
[08:35] <chrisccoulson> ah yes
[08:54] <chrisccoulson> pitti, thanks for doing that
[08:55] <pitti> chrisccoulson: no problem!
[09:46] <mwhudson> how tasteless is it to debug autopkgtest problems by uploading to the archive over and over again? :)
[09:47] <mwhudson> pitti: actually iirc there's a way you can run an autopkgtest so that i can log into the system as it runs?
[09:48] <pitti> mwhudson: yes, start it with --shell
[09:48] <mwhudson> pitti: i mean on production infra
[09:48] <pitti> then you'll get a shell (or instructions how to log in) after it  fails
[09:48] <mwhudson> pitti: it works here :-)
[09:48] <mwhudson> (it's a proxy problem)
[09:48] <pitti> mwhudson: ah yes, can do that
[09:48] <mwhudson> pitti: alternatively do you know a way to mimic the proxy set up locally?
[09:49] <mwhudson> pitti: cool, i'll ping you next week then :)
[09:49] <mwhudson> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20160916_091453@/log.gz <- so close!
[09:49] <pitti> mwhudson: in principle, install squid on the host and set the firewall in the VM to only allow talking to 10.0.2.2, not anywhere else; but I haven't actually done that in pracice yet
[09:50] <mwhudson> oh yeah, firewall in the VM makes sense
[09:50] <mwhudson> anyway time to log off  :)
[11:06] <otto> I have "patches" for https://bugs.launchpad.net/ubuntu/+source/mariadb-10.0/+bug/1605493 - on what IRC channel should I poke security-sponsors for upload?
[11:15] <rbasak> otto: #ubuntu-hardened
[11:20] <ricotz> chrisccoulson, hi, could you trigger another trunk and aurora snapshot of firefox?
[11:29] <otto> rbasak: thanks
[11:31] <attente> https://www.irccloud.com/pastebin/mOwaQ8md/
[11:31] <attente> hi, i'm having trouble switching VTs. just getting a black screen
[11:32] <attente> Xorg.0.log just has that ^: https://www.irccloud.com/pastebin/mOwaQ8md/
[11:32] <attente> when switching between VT 0 and 7
[11:32] <attente> any advice for how to debug this?
[12:30] <Mirv> sorry for hijacking autopkgtest infra again
[13:07] <pitti> Mirv: heh, I just wish the KDE packages wouldn't all need an entire build..
[13:15]  * apw looks grumpily at Mirv, twice in two days
[13:18]  * pitti counters with uploading a few hundred langpacks! Mirv, your move :)
[13:18] <pitti> (our first-ever yakkety ones, how embarrassing..)
[13:19] <Unit193> Bah, who cares about !English!?
[13:20] <pitti> Unit193: on parle français dans l'équipe du bureau, par example :)
[13:20] <pitti> oh, no seb128 today..
[13:30] <semiosis> Odd_Bloke: I just tested the latest xenial vagrant box from 2016-09-14 and it still does not have the resolv.conf fix.  Can you update livecd-rootfs on the build servers to 2.408.4?  thanks!
[13:34] <Mirv> apw: one problem is that for each qt module update the autopkgtests are run three times. two times when I click "Approved" in a silo (for xenial overlay and yakkety), and the third time when it's in yakkety-proposed (assuming no new fixes were needed). the "two times" for the currenty yakkety-proposed version were done last weekend, and I actually _skipped_ running the two times again after I removed a
[13:34] <Mirv> couple of patches causing problems since the regressions I saw from Mon-Tue tests were limited to those patches. if I'd have clicked "Approve" again, it's be the sixth time now in two days of running the thousand+ autopkgtests.
[13:35] <Mirv> pitti: I'm ready to publish qtdeclarative to proposed!
[13:39] <pitti> Mirv: hm, I'll look for a typo fix in glibc
[13:39] <Mirv> :)
[13:40] <dobey> Mirv: well, since silo autopkgtests don't run against proposed, they're actually different autopkgtests anyway
[13:40] <pitti> dobey: ubuntu autopkgtest don't run against -proposed either
[13:40] <pitti> well, not against *all* of proposed anyway
[14:44] <rharper> dupondje: your debdiff, was that against network-manager-strongswan from yakkety ?  it's not applying cleanly for me
[14:46] <kenvandine> doko, now that the libphonenumber sync has landed, can you please look at MIR bug 1618178 again?
[16:02] <nacc> smoser: do you have an example time for an import? I saw you were using that -- want to compare the new binding library's performance
[16:05] <smoser> i dont. no. sorry.
[16:05] <andrewsh> guys, any idea why http://bazaar.launchpad.net/~helen-fornazier/shim/trunk/revision/108 the patches a GPLv2-ed when the package is BSD-2+OpenSSL?
[16:05] <nacc> smoser: np -- i will just run an old version and new
[16:06] <nacc> smoser: i've got the conversion mostly done, just need to check that it produces identical trees in all existing cases
[16:06] <andrewsh> cyphermox: ↑↑
[16:08] <sforshee> pitti: I've got a machine running yakkety which sometimes boots fine, other times it hangs for a while then drops to maitenance mode. When that happens it seems to be because udev isn't adding the "systemd" tag to devices. Any ideas why that might be happening?
[16:13] <cyphermox> andrewsh: might just be an oversight
[16:18] <andrewsh> cyphermox: could you please correct it?
[16:19] <andrewsh> Helen is trying to push that package in Debian, and it's been REJECTed at least once already
[16:19] <andrewsh> s/in/into/
[16:24] <doko> kenvandine: will do, but there no component mismatch yet. can you re-enabled the java package?
[16:30] <cyphermox> andrewsh: sorry, that won't work. if we update that package it will have to be signed again by Microsoft
[16:30] <cyphermox> andrewsh: it should be fine for you to do the fix in Debian directly prior to uploading
[16:31] <cyphermox> I'll keep note that it needs to be fixed, but that will wait until we next do a round of signing (which may be soonish anyway)
[16:31] <cjwatson> (it doesn't build reproducibly?)
[16:31] <cjwatson> I guess toolchain changes
[16:32] <andrewsh> cyphermox: could you email Helen some sort of an explicit statement it was a mistake so that she can refer it to the FTP masters
[16:32] <andrewsh> ?
[16:32] <andrewsh> cyphermox: also, why not just commit a change to the VCS?
[16:32] <andrewsh> (bzr or git or whatever you're using)
[16:35] <cyphermox> cjwatson: afaik it's not quite there yet, I'd have to check
[16:48] <andrewsh> cyphermox: so, what should we do?
[16:53] <nacc> powersj: rbasak: ~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety has a 'blacklist' file
[16:54] <nacc> but i guess that would affect more than just server
[16:54] <powersj> nacc how about the server-ship file
[16:54] <powersj> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.yakkety/view/head:/server-ship
[16:54] <nacc> * !libavcodec*
[16:55] <nacc> would appear to be the syntax?
[16:55] <nacc> so i think you'd add it to that blacklist, maybe?
[16:55] <nacc> might be worth an e-mail to ubuntu-devel too
[16:56] <nacc> i don't know if you also need to modify the print-server task
[16:56] <nacc> task/file
[16:57] <powersj> for folks fyi: server ISOs jumped in size by 80mb last night due to "fonts-noto-cjk" being pulled in
[16:58] <powersj> nacc, so I guess I am hung up on the fact that xenial/yakkety don't have a print-server tasksel anymore
[16:58] <powersj> so why are we carrying print related things in the first place
[16:58] <rbasak> powersj: what makes you say that?
[16:58] <powersj> tasksel --list | grep -i print
[17:00] <powersj> in-target: debconf (developer): <-- SUBST tasksel/first CHOICES_C manual, cloud-image, dns-server, lamp-server, mail-server, postgresql-server, samba-server, standard, virt-host, openssh-server, server
[17:00] <powersj> those are the choices in an install
[17:01] <rbasak> powersj: I'm not sure why it's in that list
[17:01] <rbasak> Why it's not in that list
[17:01] <nacc> yeah, that's a bit odd, it's in the seeds (it seems like)
[17:01] <rbasak> But on my Xenial system, for example, print-server does appear in /usr/share/tasksel/descs/ubuntu-tasks.desc
[17:01] <nacc> same on yakkety
[17:01] <rbasak> And yes, it's in the seeds.
[17:02] <nacc> heh
[17:02] <nacc>   /usr/share/tasksel/*.desc and /usr/local/share/tasksel/*.desc are used
[17:02] <nacc>        to define tasks.
[17:02] <nacc> is it possible tasksel needs to be taught /usr/share/tasksel/descs/ ?
[17:03] <rbasak> It might be worth looking into tasksel to understand why it's not listing that one.
[17:03] <rbasak> (as it lists others)
[17:04] <rbasak> I see it in debian-tasks.desc too. I wonder if that has anything to do with it.
[17:05] <koike> andrewsh, cyphermox, could this be corrected in the bzr? So we can fetch the corrected version to build the shim-signed package for debian?
[17:06] <koike> cyphermox, I sent a merge proposal to the ~ubuntu-core-dev/shim/trunk branch adding the openssl license, I can also change the gpl-2 to bsd if you are ok with this
[17:07] <cjwatson> nacc: the only purpose of blacklist seed entries is to cause builds to fail hard if a package shows up
[17:07] <cjwatson> nacc: it's very rarely a good idea to use them (in ten years I think libavcodec has been the only legitimate example)
[17:07] <nacc> cjwatson: ah ok!
[17:08] <powersj> good to know
[17:08] <nacc> powersj: regardless of anything else, it does seem like you found a bug in tasksel :)
[17:09] <rbasak> If the installer has not been presenting print-server in Xenial and nobody has noticed, then perhaps we should just drop the task anyway.
[17:10] <rbasak> (to fix the size problem)
[17:10] <powersj> yeah... I thought that it was gone because demand had gone down, not because of a bug lol
[17:13] <nacc> rbasak: good point
[17:16] <powersj> rbasak, do I file a bug about the oversized ISO then? and if so against what?
[17:30] <jbicha> powersj: https://launchpad.net/ubuntu/+source/ghostscript/9.19~dfsg+1-0ubuntu3
[17:35] <powersj> jbicha, thanks, rbasak has already updated bug 1621210 with our discovery
[17:44] <kenvandine> doko, i did, libphonenumber7-java is in yakkety
[17:47] <doko> ta, didn't see it yet
[18:11] <rharper> dupondje: ok, I've updated the bug (https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1578193);  I've a build of strongswan with the specified patches, and the plugin 1.4.0 together;  please give those packages a test to see if we need anything else.
[19:55] <nacc> rbasak: just fyi, your solution for the apt import is working -- having to do some careful tree munging, but it overall seems to be working well (had to transition to pygit2 at the same time for my own sanity, so it's taken me longer to implement than i had planned)
[20:04] <rbasak> \o/
[20:50] <nacc> tjaalton: x question for you -- i normally run with 2 external monitors and my internal LCD on my laptop at home. But with 16.10, it seems like xrandr is saying the maximum screen size is 8192x8192 (while my actual maximum screen size is 8960x2160). Is this something that might have changed recently? This used to work with 16.04 (all three displays at their maximum resolutions)
[20:51] <nacc> tjaalton: absolutely not urgent, so respond if/when you can
[20:58] <tjaalton> nacc: probably modesetting_drv.so being more strict about what modes are available
[22:07] <nacc> tjaalton: interesting -- it seems like all the individual display modes are allowed still. And if i turn off my lowest res monitor, i can max out the other two. It's just the virtual screen limit i am hitting?