=== salem_ is now known as _salem
=== alexisb-afk is now known as alexisb
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
[02:55] <tumbleweed> doko: oops, I forgot to do it early, but I've got those FTBFS reports now
[02:55] <tumbleweed> earlier
=== salem_ is now known as _salem
[05:35] <pitti> Good morning
[05:36] <sladen> Herbst has arrived
[05:37] <pitti> massively -- non-stop rain since Friday evening here, depressing :(
[06:04] <rbasak> nacc: a tree compare of refs/{heads,tags} maybe?
[06:05] <rbasak> I'm not sure there's any easier way.
[06:14] <cpaelzer> good morning
[06:56] <tjaalton> http://qa.ubuntuwire.org/rdepends/ doesn't seem to work
[07:00] <tjaalton> the whole site is down, so reverse-depends doesn't work. is there an alternative?
[07:24] <handsome_feng> hi, Good morning everyone! I have a new package to be upload to archive,and I have file a bug in launchpad. Does anyone know who can help me? In the Topic I can't find who is the Patch Pilot. :(
[07:29] <ricotz> chrisccoulson, hi, could you retry https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+build/10930941
[07:34] <pitti> ricotz, chrisccoulson: done ^
[07:35] <ricotz> pitti, thanks!
[07:35] <pitti> ricotz: interesting that I can even see that PPA..
[07:36] <ricotz> pitti, huh, why?
[07:37] <pitti> well, aren't security updates meant to be kept private until publication?
[07:38] <ricotz> pitti, ah, I see, in this case I hope it stays that way otherwise it would take even longer to get them ;)
[07:38] <ricotz> while yakkety builds are usually still missing :\
[07:39] <pitti> this only applies to yet undisclosed vulns; for preparing new releases which are already published upstream it's totally fine and correct of course
[07:43] <ricotz> pitti, ack, the referenced USN-3076-1 is still hidden on http://www.ubuntu.com/usn/
[09:17] <Odd_Bloke> semiosis: I've been at a conference over the weekend, apologies for being AWOL. ;)  I'll look at updating livecd-rootfs now.
[09:20] <Odd_Bloke> semiosis: Done; the next xenial Vagrant box should be built with the new livecd-rootfs.
[10:43] <smb> xnox, since you have been looking at that old thing in the past, maybe you could help to sponsor the change I proposed in bug 1611277 in Yakkety. Depending on how you think about it. IMO it feels rather wrong to ignore removable devices and even if the scan then hits a cd it should not go too wrong as reading should have no usable meta-data
[10:43] <ubottu> bug 1611277 in dmraid (Ubuntu) "Kernel Shipped With Ubuntu 16.04.1 Cannot Recognize fakeRaid" [Medium,Confirmed] https://launchpad.net/bugs/1611277
[10:48] <xnox> that bug is long....
[10:49] <xnox> smb, i like your patch, and i think it should go in everywhere, including debian.
[10:51] <smb> xnox, probably yes. don't think there is anything maintained upstream anymore. Though apparently some people still use the thing
[10:56] <xnox> some have no choice =(
[11:00] <smb> yeah, likely :/
[11:01] <smb> xnox, so at least for me I have no upload rights for this neither in Debian nor Ubuntu
[11:04] <xnox> oh.
[11:04] <xnox> smb, i'll sponsor that everywhere then.
[11:06] <smb> xnox, thanks a lot. might help me a little step on my path to world-dom... I mean core-dev >:-)
=== hikiko is now known as hikiko|ln
[11:23] <mdeslaur> @pilot in
=== udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
[11:42]  * dholbach hugs mdeslaur 
[11:43]  * mdeslaur hugs dholbach 
=== hikiko|ln is now known as hikiko
[12:34] <semiosis> Odd_Bloke: thank you very much
=== _salem is now known as salem_
[14:04] <willcooke> hey alecu, dobey, semiosis
[14:04] <willcooke> err, sorry semiosis
[14:04] <willcooke> didnt mean you
[14:04] <willcooke> mean seb128
[14:04] <seb128> hey :-)
[14:04] <willcooke> dobey, I think we touched on this in the HO, but just wanted to make sure that the deps on sdk libs are addressed via your branches?
[14:06] <dobey> willcooke: yes, one of my branches changes it to "snapd | ubuntu-sdk-libs,"
[14:06] <willcooke> dobey, super, thanks!
[14:06] <willcooke> seb128, ^ good news
[14:07]  * dobey has way too many branches for too many things, at the moment
[14:07] <seb128> great
[14:41] <powersj> rbasak, re: oversized ISO, what should our next steps be?
=== muktupavels_ is now known as muktupavels
[14:47] <rbasak> powersj: I guess we need to decide how we should get the size down. That might be by reverting the ghostscript upload that bumped the size, or by dropping the print-server task from the ISO, or something else.
[14:48] <rbasak> I don't know what the implications would be in reverting the ghostscript upload. Perhaps start a conversation with Gunnar, perhaps in a new bug against ghostscript?
[14:48] <powersj> ok I can do that
[14:48] <rbasak> Also, it's probably worth checking to see if the print-server task really doesn't appear in the installer, and if so we should have a bug against that too.
[14:49] <powersj> dropping the print-server task, while not unusable due to the tasksel bug, does seem a bit of a bigger task/impact
[14:49] <powersj> ah I filed one for that already
=== JanC is now known as Guest12202
=== JanC_ is now known as JanC
[14:49] <powersj> bug 1624519
[14:49] <ubottu> bug 1624519 in tasksel (Ubuntu) "print-server task dropped" [Undecided,New] https://launchpad.net/bugs/1624519
[14:52] <rbasak> powersj: yeah, I would prefer to leave it alone.
=== dpm_ is now known as dpm
[14:53] <powersj> rbasak, one other topic, ISO testing - we should schedule something soon right?
[15:00] <rbasak> powersj: ah yes, good shout
[15:34] <nacc> rbasak: yeah, there is git-diff-tree, but for some reason the ubuntu package doesn't put that in the normal bin path?
[15:44] <juliank> nacc: git subcommands do not belong into $PATH - git diff-tree works fine, but it's fairly lowlevel so it's not advertised by the bash completion, for example.
[15:44] <nacc> juliank: ah maybe that's what i missed, thanks!
[15:45] <mdeslaur> @pilot out
=== udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:45] <nacc> juliank: kept hitting tab (as it's a git recipe on their wiki for comparing two local repos) and wasn't seeing it, but found it in the package. Thanks again for the clarification :)
[15:45] <juliank> nacc: Thing with diff-tree is that it works on tree objects - a lot of people probably don't even know those exist.
[15:46] <Unit193> slangasek: Seen the conclusion in LP 1624096?
[15:46] <ubottu> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed] https://launchpad.net/bugs/1624096
[15:46] <nacc> juliank: ack :)
[15:48] <slangasek> Unit193: I had discussed it with jderose here yesterday.  But I'm planning to work around it, which we can do a lot more quickly than we can land a new signed shim
[15:49] <Unit193> Ah sorry I didn't see it.  Thanks for the info.
[15:55] <mdeslaur> crud, the reverse-depends tool doesn't work anymore because it looks like qa.ubuntuwire.org went away
[15:56] <Laney> mdeslaur: http://ubuntuqa.tblwd.org/
[15:56] <nacc> i believe there is a failover service available
[15:56] <nacc> :)
[15:56]  * pitti uses it once to finally get that into my bash history
[15:56] <mdeslaur> Laney: awesome, thanks!
=== Laney changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | reverse-depends/seeded-in-ubuntu broken? http://ub
[15:56] <Laney> fail
[15:57] <pitti> $ reverse-depends -u http://ubuntuqa.tblwd.org/ src:udisks2
[15:57] <pitti> <head><title>404 Not Found</title></head>
[15:57] <Laney> pitti didn't follow the instructions :)
[15:58] <pitti> oh, that is an actual human-readable page, sorry :)
[15:58] <pitti> thanks!
=== Laney changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
[16:03] <juliank> I find the translation import queue a bit hard to read (it shows no imported ones, at least)? Did we get some of the new APT translation templates imported? I specifically worked things into the build system so they can be imported by launchpad (obj-*/po/{apt,libapt-pkg5.0,libapt-inst2.0,apt-utils}.pot) - would be a shame if they were not used
[16:03] <juliank> This only started fairly recently with the CMake switch in 1.3~rc1, all the older builds (those building in build/) will fail to be imported
[16:04] <juliank> The first I see is "obj-arm-linux-gnueabihf/po/apt.pot in apt in Ubuntu Yakkety" somewhere after #75, uploaded on 2016-08-12, and "Needs Review"
[16:05] <juliank> The templates currently in use must be years old
[16:21] <nacc> jgrimm: fyi, 277 commits between the yakkety openipmi upstream release and the latest upstream release :/
[16:22] <jgrimm> nacc,  bug fixes, cosmetic, features, ?
[16:22] <nacc> jgrimm: reading through them now
[16:22] <jgrimm> nacc, cool
[16:23] <nacc> "More massive restructure getting ready for the serial code."
[16:24] <nacc> definitely lots of bugfixes too
[16:36] <nacc> cpaelzer_: i see that you 'declined for yakkety', LP: #1585121. Can you help me understand what that means? ... was it nominated for yakkety at some point and then cancelled?
[16:36] <ubottu> Launchpad bug 1585121 in awstats (Ubuntu Xenial) "awstats produces regex warnings in version 7.4 with Perl 5.22 on Ubuntu 16.04 LTS" [High,In progress] https://launchpad.net/bugs/1585121
[16:38] <jgrimm> nacc, that's what it looks like
[16:39] <jgrimm> anything else we want to discuss?  jamespage is likely ready to wrap things up..
[16:39] <jgrimm> oh oopps. wrong channel. apologies.
[16:42] <cpaelzer_> hmm
[16:42] <nacc> if so i can approve that cancel to clean up the message, at least
[16:43] <cpaelzer_> nacc: yeah when doing triage with josh and robie
[16:43] <nacc> cpaelzer_: ok, so i'm good to cancel the yakkety nomination?
[16:43] <cpaelzer_> nacc: it was found that the change should already be in yakkey
[16:43] <cpaelzer_> nacc: thats why I declined, and if you agree cancel your nomination (or wherever it came from)
[16:43] <cpaelzer_> It just was a chance for me to first time ack/nack nominations
[16:44] <cpaelzer_> and this case provided both at once
[16:44] <nacc> yep
[16:44] <powersj> nacc, yeah sorry my bad
[16:44] <nacc> ok, it should be fixed now
[16:50] <nacc> cpaelzer_: i think also, LP: #1576698 can be in progress, at least for xenial?
[16:50] <ubottu> Launchpad bug 1576698 in ntp (Ubuntu Xenial) "ntpdate-debian not working" [Medium,Triaged] https://launchpad.net/bugs/1576698
[16:50] <jgrimm> nacc, can you approve nomination in 1534882?
[16:51] <nacc> jgrimm: done
[16:52] <jgrimm> nacc, thanks!
[16:52] <nacc> jgrimm: np!
[16:52] <nacc> jgrimm: re: openipmi, it's definitely not just bugfixes
[16:53] <nacc>  184 files changed, 36011 insertions(+), 10237 deletions(-)
[16:59] <nacc> rbasak: ok, let's say both y-proposed and y are present a repository. Should 'ubuntu/devel' point to y, if y is a proper descendant of y-proposed? meaning it's already been copied forward and y is current? Technically tree-wise y-proposed and y are identical in this case. I guess we'd want to work on y-proposed, though, as we'd expect the next publisehd version to show up there. I think I answered my
[16:59] <nacc> own question by asking it :)
[17:01] <ginggs> doko, what do you think about openmpi2 for yakkety?
=== alexisb is now known as alexisb-afk
[17:11] <nacc> rbasak: smoser: pushed the apt/at fixes and the ubuntu/devel change to master
[17:11] <smoser> import apt ?
[17:11] <nacc> smoser: if you want to update and try to re-import apt to see if it works for you, that'd be great
[17:11] <nacc> smoser: or i can
[17:11] <smoser> i can.
[17:11] <nacc> cool
[17:11] <smoser> that one takes a while
[17:11] <nacc> i'm updating the snap right now :)
[17:11] <nacc> yeah, it's a lot of churn :)
[17:23] <smoser> nacc, http://paste.ubuntu.com/23208016/
[17:23] <smoser> $ git clone git+ssh://smoser@git.launchpad.net/~usd-import-team/ubuntu/+source/apt
[17:23] <smoser> Cloning into 'apt'...
[17:23] <smoser> fatal: remote error: Repository '~usd-import-team/ubuntu/+source/apt' not found.
[17:24] <nacc> smoser: argh, i forgot to fix that! -- it's a bug i need to figure out how to deal with
[17:24] <nacc> workaroud for now, is to use --no-push
[17:25] <nacc> and then push manually from the git repository to that remote
[17:25] <nacc> sorry, totally blanked on that
[17:26] <nacc> it's because their internal parser, iirc, doesn't recognize git+ssh (i think)
[17:27] <smoser> so my fix for git:// wasn't completely useless, eh ?
[17:27] <smoser> :)
[17:27] <nacc> smoser: heh
[17:27] <nacc> smoser: actually, do you mind if i do the import, so i can test this?
[17:28] <smoser> sure
[17:28] <nacc> smoser: i'll ping you when it's done
[17:37] <smoser> nacc, https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/306254
[17:38] <smoser> oh wait. i geuss we can probably drop the python3-git now, right ?
[17:38] <nacc> smoser: yeah, make it python3-pygit2
[17:38] <nacc> and drop python3-git altogether
[17:39] <smoser> done
[17:40] <nacc> thanks, i'll pull that once i've got this tested -- it seems like this should work, basically i'm using git:// for fetch and git+ssh:// for push
[17:40] <nacc> i think the parser will understand that (and if it doesn't, it's a bug in pygit2)
[17:41]  * smoser adds --force
=== alexisb-afk is now known as alexisb
[18:07] <rbasak> nacc: yeah. I guess if it was yakkety-proposed, then we could upload and push, then the import would end up pointing to it automatically. So that would be cleanest.
[18:13] <nacc> rbasak: yep, that's my thinking, thanks
[18:30] <jderose> slangasek: so following up on our conversation yesterday about fallback.efi... so you're saying a potential solution is just to have /usr/lib/shim/fallback.efi.signed from `shim` copied over to /EFI/BOOT/fallback.efi on the ISO?
[18:36] <smb> xnox, grrr... (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827315)
[18:36] <ubottu> Debian bug 827315 in src:sbuild "sbuild: Does not work with gnupg 2.x installed in the chroot" [Important,Fixed]
[18:37]  * smb is trying to sbuild a yakkety package on trusty
[18:37] <slangasek> jderose: correct
[18:37] <slangasek> jderose: since the double free only happens on an error path when that file does not exist, making that file exist should work around the bug
[18:38] <teward> smb: funny story: I've been trying to as well, and it's still busted, I heard there's no timeline for that getting fixed anywhere in the past (I got very annoyed at that bug last week)
[18:38] <teward> (in Trusty)
[18:40] <sarnold> smb: I've heard yakkety's sbuild on xenial works, no idea about trusty though
[18:40] <smb> teward, yeah, reading through that debian bug it seems the "fix" is to backport sbuild...
[18:41] <teward> sarnold: it doesn't work on pre-Xenial, because of changes to sbuild and the gnupg 2.x switchover
[18:41] <sarnold> teward: ah. bummer :/
[18:41] <smb> sarnold, hm, maybe someone picked a fix there but not back to t
[18:42] <teward> sarnold: that said, I tried straight backport of Yakkety -> Trusty
[18:42] <teward> and it does absolutley nothing
[18:42] <jderose> slangasek: so is this a change that needs to be made in shim, or in the ISO mastering tools?
[18:42] <sarnold> that seems like quite a large gap to jump
[18:42] <teward> but it's a big issue, yes.
[18:42] <slangasek> jderose: shim-signed and/or grub2 (since grub-install is what handles all the other UEFI bits)
[18:42] <slangasek> cjwatson, cyphermox: ^^
[18:44] <cyphermox> yes
[18:44] <cyphermox> is the issue "just" that something crashes when fallback isn't there? because fallback.efi just by itself won't do anything very useful
[18:44] <slangasek> cyphermox: the actuall question is, should this go in shim-signed, or be in grub-installer :)
[18:44] <slangasek> sorry, grub-install
[18:45] <cyphermox> grub-install
[18:45] <cyphermox> (just like the other shim bits -- MokManager, etc.)
[18:45] <jderose> cyphermox: yes, on yakkety currently, things go haywire when trying to boot the ISO in UEFI mode with QEMU - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1624096
[18:45] <slangasek> ok
[18:45] <ubottu> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed]
[18:46] <slangasek> cyphermox: I believe you once expressed a contrary opinion in LP: #1366546, so wanted to check
[18:46] <ubottu> Launchpad bug 1366546 in shim (Ubuntu) "Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems" [Undecided,Triaged] https://launchpad.net/bugs/1366546
[18:47] <cyphermox> slangasek: I was wrong
[18:50] <cyphermox> err, on the ISO though, I'm not sure what the benefit would be to have fallback.efi except to paper over the bug in shim
[18:51] <slangasek> hmm good question
[18:52] <cyphermox> that said, I'm happy to add fallback in general, I've been bugging you about it periodically for a while :)
[18:52] <slangasek> the purpose of fallback.efi is to recover your boot config if it goes missing from nvram
[18:52] <cyphermox> yep
[18:52] <cyphermox> oh
[18:52] <slangasek> if someone inserts a bootable CD, would we like it to magically do this for you, or not? :)
[18:52] <cyphermox> yeah, I suppose that for the magic "recover my system" feature it might be good
[18:52] <cyphermox> so we'd want to ship fallback on the CD, but not boot.csv
[18:53] <cyphermox> but we'd want to ship a boot.csv in our directory, otherwise that won't work
[18:53] <slangasek> if this doesn't violate principle of least surprise for the CD to magically do this
[18:53] <slangasek> right
[18:53] <slangasek> eventually we need to add boot.csv
[18:53] <slangasek> but if it's correct to install fallback.efi, we could start doing that sooner rather than later even if the full thing isn't implemented
[18:53] <cyphermox> it seems fine
[18:54] <cyphermox> and implementing the rest is not complicated work, it just takes a bit of time to get things right
[18:54] <cyphermox> I did test it out here before
[18:59] <Unit193> jderose: Still here?
[18:59] <jderose> Unit193: yup :)
=== acheronuk is now known as acheron
=== acheron is now known as acheronuk
[19:03] <cyphermox> jderose: slangasek: updated the bug, I'll start hacking at those
[19:04] <jderose> cyphermox: awesome, thanks! i can help test, test, test as soon as there's an ISO :)
[19:12] <jderose> cyphermox: so as a quick crude test, i edited the latest yakkety daily desktop ISO, adding /BOOT/EFI/fallback.efi, and then tried installing from it with QEMU + OVMF. things aren't blowing up anymore, but it's also not bringing up the ubuntu installer pre-boot menu. it tries to PXE boot, then falls back to Shell>
[19:13] <cyphermox> ok
[19:14] <cyphermox> well presumably it was blowing up because it tried to go to fallback in the first place, that shouldn't be happening if there are other options to boot from
[19:14] <cyphermox> (and one of them should be "hey there's a grubx64.efi"
[19:15] <slangasek> cyphermox: so, perhaps fallback.efi is meant not to be there on removable media and this isn't fixable without a signing round-trip
[19:15] <cyphermox> possibly
[19:15] <cyphermox> that means I really need to go to read some shim code now
[19:15] <slangasek> (I don't remember the semantics of fallback.efi, it's been a long time since I talked to mjg59 about this)
[19:17] <cyphermox>               /* Do not print the error here - this is an acceptable case
[19:17] <cyphermox>                  * for removable media, where we genuinely don't want
[19:17] <cyphermox>                  * fallback.efi to exist.
[19:17] <jderose> slangasek: so assuming the only workable fix is a signing round trip, do you think that can happen in time for 16.10?
[19:17] <cyphermox> well, fallback might make sense on removable media for the reason we brought up earlier
[19:17] <slangasek> jderose: it's possible, yes, but would be tight
[19:18] <slangasek> cyphermox: it might "make sense" but the code may still not be designed that way
[19:18] <cyphermox> right
[19:18] <cyphermox> it is not
[19:18] <jderose> slangasek: how much beer does System76 need to send you? :P
[19:23] <jderose> slangasek: cyphermox: so does it seem to both of you that the newer shim in yakkety is the root cause of this problem, or might there be other changes in yakkety that are at play also?
[19:26] <slangasek> jderose: that seems to be the only cause
[19:33] <jderose> slangasek: so you'd expect that with a xenial guest, OVMF would try to load fallback.efi (which wouldn't kaboom because of the older shim package), then OVMF would "discover" whatever it needs to load to start the installer?
[19:34] <slangasek> jderose: OVMF doesn't try to load fallback.efi, it only loads bootx64.efi
[19:34] <slangasek> which is shim
[19:34] <jderose> slangasek: ah, gotcha... so shim itself is what then calls fallback.efi?
[19:34] <slangasek> yes
[19:35] <jderose> slangasek: perhaps a dumb question, but why does shim run fallback.efi instead of just booting the installer?
[19:36] <slangasek> jderose: because shim is a monolithic binary which has to do the right thing with no other information, and one of the things it has to do is load fallback.efi when it's present
[19:37] <jderose> slangasek: okay, thanks. it's slowly starting to make more sense to me :)
=== beisner is now known as beisner-food
=== beisner-food is now known as beisner
[20:26] <bdmurray> juliank: Could you have a look at bug 1592817?
[20:26] <ubottu> bug 1592817 in python-apt (Ubuntu) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [High,Triaged] https://launchpad.net/bugs/1592817
[20:54] <nacc> smoser: fyi, fixed the bug(s), i think. running the import now in the bg
[20:59] <xnox> smb, you need a bit newer sbuild and no host keys setup.
[20:59] <xnox> smb, use lxd container
[20:59] <xnox> or lxc given that it's trusty
[20:59] <xnox> i guess i should upload backports for sbuild
[21:00] <xnox> micahg, so i really really need ~ubuntu-backports powers =)
[21:00] <sarnold> or an SRU?
[21:01] <Unit193> xnox: Ooooh, do my pbuilder request too!
[21:03] <xnox> sarnold, i can break one or the other.
[21:03] <xnox> sarnold, actually trusty apt should be new enough, to handle no host keys as done by new enough sbuild.
[21:03]  * xnox ponders if i can do magic with debootstrap profiles too somehow.
[21:05] <xnox> Unit193, shrug no. I want to remove pbuilder & cowbuilder from the archive. official builds are done using sbuild and there is no reason not to use $ mk-sbuild <sid|yakkety|xenial>; sbuild -A -d <sid|yakkety|xenial> for years now.
[21:05] <Unit193> 1592205! (Maybe 1562358 too)  Erm, eww no.
=== salem_ is now known as _salem
=== _salem is now known as salem_
[21:56] <bdmurray> xnox: Could you have a look at bug 1623383?
[21:56] <ubottu> bug 1623383 in udev (Ubuntu) "Some restarts fail due to missing base devices" [Critical,Confirmed] https://launchpad.net/bugs/1623383
=== salem_ is now known as _salem
[22:14] <juliank> Hmm, https://wiki.ubuntu.com/Releases says yakkety will be supported until February but down the page says "Regular releases are supported for 9 months."
[22:14]  * juliank is confused
[22:15] <juliank> That seems like a copy/paste error from a non-LTS .04 release?
[22:15] <sarnold> I wonder if that came from the 'vivid' line, which has had some kind of crazy half-zombie half
[22:15] <stgraber> it's certainly supposed to be 9 months
[22:19]  * juliank calculated with 9 months in his APT stable branch planning 
[22:20] <juliank> It will be interesting to see if we come up with 1.4 apt series for the Debian stretch and next year's Ubuntu releases, or if we end up with one APT series covering 3 Ubuntu releases...
[22:20] <tsimonq2> nice catch
[22:21] <tsimonq2> look better now?
[22:27] <juliank> tsimonq2: yeah
[22:29] <juliank> Here's one thing I can guarantee: 17.04 will ship the same APT release series as stretch. 17.10 is tricky - If we got a lot of new stuff during the Debian freeze, we can do a release cycle in there, but I'd probably prefer to just move that to 18.04
[22:33] <stgraber> xnox: hmm, so "gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBA
[22:34] <stgraber> xnox: hmm, so "gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBAEFF88C22F6E216" seems to hang most of the time with gnupg2
[22:34] <stgraber> xnox: that's the cause of all those adt failures for LXC, any idea what's going on?
[22:34] <tumbleweed> you sure you aren't hitting a broken keyserver in the pool?
[22:34] <stgraber> xnox: on the exact same network, running the same with gpg1 works immediately so it's clearly a gnupg2/dirmngr thing
[22:35] <juliank> BTW: If someone wants to contribute huge features to apt for the next series, please do so in the next 1.5 months. APT is basically freezing for big stuff in 2 months. Smaller features freeze in 3 months.
[22:37] <stgraber> tumbleweed: good question and that actually just pointed me at the answer, dirmngr is completely screwed up in ipv6 mode
[22:38] <stgraber> tumbleweed: it just plain fails if you pass hkp://[ipv6] as the keyserver and if you pass a DNS record which does happen to have IPv6 addresses on an IPv6 enabled machine, it will go crazy doing weird DNS queries for a while, eventually run out of IPv6 addresses to fail and finally succeeds over IPv4
[22:38] <stgraber> obviously that assumes you have IPv4 connectivity at all, which I don't
[22:38] <juliank> stgraber: Oh, while I see that: you can use the encrypted keyserver: hkps://hkps.pool.sks-keyservers.net
[22:38] <stgraber> as for adt, that's failing because unlike gpgv1, it's not respecting http_proxy and https_proxy
[22:39]  * juliank also pins the host certificate for that keyserver
[22:39] <stgraber> xnox: so looks like there's some serious work to be done for that gpgv2 replacement to be a thing...
[22:40]  * juliank hates IPv6
[22:40]  * stgraber hates IPv4
[22:41] <juliank> I also had trouble SSHing to my IPv6 enabled xenial server thinkpad.
[22:41] <juliank> but that one is urnning networkd, so ...
[22:42] <sarnold> juliank: any chance for an apt that installs multiple packages simultaneously? :) I get a bit sad seeing 5% processor utilization during long builds, when the install stage runs and rus and runs..
[22:42] <juliank> sarnold: no chance.
[22:43] <juliank> sarnold: Well, you'd have to tell dpkg to process the stuff in parallel, not APT
[22:44] <juliank> With 1.3 in yakkety, APT just passes dpkg a directory of deb files and says: Hey, install those.
[22:44] <sarnold> juliank: yeah, I figured it'd be difficult at best..
[22:44] <sarnold> oh? does apt hint at ordering? or does dpkg sort it all out?
[22:45] <juliank> Well, some more ordering is still going on.
[22:45] <juliank> I think we have to name the files in order for dpkg to not screw up
[22:45] <sarnold> hehe
[22:45] <powersj> stgraber, are your GPG comments related to my lxc api test email?
[22:45] <juliank> because dpkg -i a.deb b.deb != dpkg -i b.deb a.deb
[22:47] <sarnold> thanks juliank :)
[22:47] <juliank> One thing I'm happy about is automated coverage checking in the APT CI: We will now be able to see if the lines we changed in a commit where covered by the test suite. This should vastly increase our trust in future SRUs.
[22:48] <juliank> (thanks to travis ci and codecov.io)
[22:49] <stgraber> powersj: yes
[22:49] <stgraber> powersj: filing a couple of critical bugs against gnupg2
[22:49] <juliank> I somehow would like to create a metric for rating apt solutions, and record anonymized APT upgrade runs on end user systems and then feed new APT releases these problems for regression checking
[22:50] <juliank> that would be nice
[22:54] <juliank> Anyway, enough for today :D
[22:57] <stgraber> powersj: bug 1625845, bug 1625848
[22:57] <ubottu> bug 1625845 in gnupg2 (Ubuntu) "dirmngr doesn't handle IPv6 properly" [Critical,Triaged] https://launchpad.net/bugs/1625845
[22:57] <ubottu> bug 1625848 in gnupg2 (Ubuntu) "gnupg2 appears to ignore http_proxy, fails to retrieve keys" [Critical,Triaged] https://launchpad.net/bugs/1625848
[22:58] <powersj> stgraber, thank you!!!
[22:58] <stgraber> slangasek: ^ FYI (I assigned to xnox for now since he seemed to be the one dealing with the gnupg2 transition)
[22:59] <stgraber> powersj: I just hope there's a fix somewhere we can pull for this, because otherwise those two bugs will be extremely painful for enterprise users, makes gpg basically unusable if you need to use a proxy or if you have IPv6 connectivity
[23:01] <powersj> agreed
[23:01] <powersj> it is nice to know the automated iso tests are finding real issues now :)
[23:02] <stgraber> powersj: well, we knew about some of this ever since gnupg2 was made the default as the autopkgtest for lxc has been failing ever since
[23:03] <stgraber> powersj: first we thought it was becaused of missing dirmngr as it wasn't installed by default, but it looks like a) it is now b) I added a dependency on it anyway
[23:03] <stgraber> powersj: that lxc change landed yesterday and autopkgtest confirmed that things are still just as bad, so I finally looked at gnupg2 a bit closer now :)
[23:04] <powersj> ah ok!
[23:04] <stgraber> can't say I'm happy with what I'm seeing though... not sure how they managed to regress so much when moving code around...
=== bschaefer_ is now known as bschaefer