[05:44] <pitti> Good morning
[06:24] <sarnold> what's the deal with http://archive.ubuntu.com/ubuntu/pool/main/b/blam/ ?
[06:25] <sarnold> it's an empty directory, that seems odd.. but blam lives in universe, not main
[06:26] <infinity> sarnold: Empty directories shouldn't stick around long.
[06:27] <infinity> Oh, huh.  But that's been at the same version -- and in universe -- for years.
[06:27] <sarnold> drwxr-xr-x 2 mirror mirror 2 Sep 12  2013 pool/main/b/blam
[06:27]  * infinity scratches his head.
[06:28] <infinity> Aaand, it's not empty on ftpmaster, that's why.
[06:28] <infinity> Probably will empty out when we reap some old releases.
[06:28] <sarnold> heh, was blam in main N releases ago?
[06:29] <infinity> Dunno.
[06:29] <sarnold> $ find /srv/mirror/ubuntu/ -type d -empty | wc -l
[06:29] <sarnold> 9000
[06:29] <sarnold> heh
[06:30] <infinity> Hrm, this one actually looks like an ancient LP bug.
[06:31] <infinity> http://paste.ubuntu.com/16356171/
[06:31] <infinity> wgrant,cjwatson: ^-- whee, fun.
[06:32] <infinity> (Granted, that version should be reaped anyway, but the orig/dsc split there across directories looks very busted)
[06:32] <sarnold> blamblam? looks like a paste went awry
[06:33] <infinity> Err, yeah.  Bad paste.
[06:33] <infinity> http://paste.ubuntu.com/16356180/ <- Gooder paste.
[06:34] <wgrant> infinity, sarnold: https://bugs.launchpad.net/launchpad/+bug/117780
[06:35] <infinity> wgrant: There are no symlinks there.
[06:35] <infinity> wgrant: orig is in main, dsc/diff are in universe.
[06:35] <wgrant> infinity: Surely the orig is symlinked into universe.
[06:36] <infinity> wgrant: http://paste.ubuntu.com/16356180/ is a complete ls. :P
[06:37] <infinity> wgrant: Also, did we not kill hardy debs yet?
[06:37] <infinity> s/debs/packages/
[06:37] <infinity> Oh, we probably did.  I see no deb there.  But I bet the broken orig/dsc thing there prevented the source package from dying.
[06:38] <infinity> So it's just left behind cruft.
[06:38] <infinity> Curious how much of that sort of thing might be hanging around.
[06:38] <infinity> Maybe we should reverse-magicmirror ourselves. :P
[06:39] <wgrant> It thinks it's gone.
[06:39] <wgrant> I wrote a script once to compare the pool to the DB, but never actually ran it.
[06:39] <sarnold> :)
[06:39] <infinity> wgrant: Well, the next time we go reaping a release, maybe we should run it.
[06:39] <infinity> wgrant: And see how many GB of oops we have.
[06:40] <infinity> For now, I think it's bed time.
[06:40] <sarnold> night
[06:40] <wgrant> Quite.
[06:40] <wgrant> Oh we're in the same tz for once.
[06:41] <infinity> wgrant: Well, off by an hour, but close enough.
[06:42] <wgrant> Oh yeah.
[07:46] <pitti> doko: OOI, does Debian's amd64 gcc also default to PIE now? i. e. should a patch for https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/g/gprbuild/20160510_073641@/log.gz go to Debian too?
[07:47] <pitti> actually, I'm not sure if that's a bug in gprbuild or in gfortran
[08:05] <Laney> juliank: do you mean the patch attached to the bug?
[08:05] <Laney> if it's okay with ximion then fine by me
[08:17] <juliank> Laney: Yeah, I applied it in git now. I'm not closing that bug as the SHA1 error still exists, but the issue with appstream and friends goes away.
[08:35] <infinity> pitti: Debian's compiler doesn't default to -fPIE -pie, but it also doesn't hurt to apply -fno-pie -no-pie unrestricted in both Debian and Ubuntu when appropriate.
[08:35] <pitti> infinity: ok, thanks; that still leaves the question of whether this should be done in gfortran or gprbuild, but I'll look at that later
[08:36] <infinity> pitti: The only caveat of doing it unrestricted is that it makes the package unbackportable (the -no-pie args were only accepted as of xenial timeframe).
[08:37] <infinity> But, meh.  Backporters are never my top priority.
[08:59] <mwhudson> yes, i wish someone could  have had a crystal ball in 2012 and added it to gcc then
[09:30] <rbasak> cyphermox: are you aware of bug 1576588 and bug 1576588? They seem to be rising in heat.
[09:33] <doko> pitti, no
[09:36] <rbasak> cyphermox: the other was bug 1211110
[09:56] <Laney> barry: did you see that the libpeas split got past NEW in Debian?
[09:56] <Laney> what are your plans regarding syncing back up with that?
[10:37] <mwhudson> jamespage: hi
[10:37] <jamespage> mwhudson, hello
[10:37] <mwhudson> jamespage: did my response about openstack help at all?
[10:37] <jamespage> mwhudson, it did thanks - have that on my list to respond today
[10:37] <mwhudson> jamespage: ok
[10:38] <jamespage> mwhudson, there is alot of contention about whether openstack projects should be anything other than python...
[10:38] <mwhudson> jamespage: i'll be working tomorrow night so we could have a chat about this in about 22 hours or so if that would be useful
[10:38] <mwhudson> (it's a bit late now!)
[10:38] <jamespage> mwhudson, that would be great
[10:39] <mwhudson> jamespage: drop something in my calendar?
[10:39] <jamespage> mwhudson, +1 will do
[10:39] <mwhudson> cool
[10:39] <jamespage> mwhudson, that would be first thing my time right?
[10:39] <mwhudson> jamespage: i am 11 hours ahead of you currently
[10:40] <mwhudson> so your 9am is 8pm for me etc
[10:40] <jamespage> mwhudson, okies
[10:40] <mwhudson> before 10pm my time would be appreciated :-)
[10:44] <davmor2> mwhudson: wow you have your own timezone
[10:44] <mwhudson> davmor2: there are a few other people here
[10:44] <mwhudson> but not very many, indeed
[10:44] <mwhudson> comared to, say, https://en.wikipedia.org/wiki/UTC%2B12:45
[13:24] <barry> Laney: i did see it.  i had talked w/the debian maintainer and their approach was different but workable.  after i get a few other things done, i plan to resync for yakkety
[14:38] <rbasak> infinity: any news on bug 1571174 please?
[14:43] <Laney> barry: nice
[14:43] <Laney> barry: if there's some C/B/R needed we can probably upload those into debian
[14:43] <Laney> to sync it
[14:44] <barry> Laney: C/B/R?
[14:45] <Laney> haha
[14:45] <barry> ah
[14:45] <barry> i get it now :)
[14:45] <Laney> you probably need to deal with libpeas-1.0-0-python3loader
[14:45] <Laney> but I would imagine we can accommodate that in debian
[14:45] <barry> Laney: ack
[15:47] <cpaelzer> infinity: I'll bring up STT_GNU_IFUNC on the dpdk mailing list next week as a joint request by Ubuntu/Debian/Cisco/Brocade for a long term solution
[15:47] <cpaelzer> infinity: do you WANT to be part of that discussion (on CC) or should I keep you out of it (the default)
[16:05] <infinity> cpaelzer: I don't need to be part of it.
[16:59] <nacc> is it a known thing that the amd64 kernel builds are failing at http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/current/ ?
[17:00] <nacc> true of http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/BUILD.LOG.amd64 as well
[17:09] <fidencio> cjwatson: hey/ping
[17:10] <fidencio> cjwatson: not sure if you're the right person to ask, but I hope you can at least point me to the right person
[17:11] <fidencio> cjwatson: so, I'ĺl be working on adding support to express installation (preseed) for ubuntu on libosinfo (and consequently on gnome-boxes)
[17:11] <fidencio> cjwatson: all the released ISOs support the preseed installation or just the "server" ones?
[17:13] <cjwatson> fidencio: -> cyphermox in general for this kind of thing
[17:19] <fidencio> cjwatson: thanks, let's wait for him then.
[17:21] <mterry> pilot in
[17:21] <mterry> @pilot in
[17:42] <cholcombe> question for you systemd guys.  when you start a service with systemd does it wait for it to come up or just return immediately? i'm trying to track down a bug that only surfaces in xenial
[17:45] <rbasak> cholcombe: I think it's supposed to wait, assuming that the service definition means that it can know
[17:46] <rbasak> I'm not sure though.
[17:46] <cholcombe> rbasak, hmm ok
[17:46] <cholcombe> yeah i'm not sure either
[17:46] <cholcombe> my guess is that it would wait but i don't know for sure
[17:46] <rbasak> The real question is: in your case, how would it know?
[17:48] <cholcombe> rbasak, good question.  I'll check gluster's systemd file and see what they're doing in there
[17:50] <rbasak> cholcombe: BTW, it's fairly common for daemons to "daemonize" before they're ready and thus lead to a race condition. I've seen it in a few cases.
[17:51] <cholcombe> i believe that's what is going on.  My code depends on systemd bringing up gluster correctly and it works fine in trusty.  Testing in xenial shows some kinda weird race condition where my code tries to do things before gluster is finished coming up
[17:53] <cyphermox> fidencio: all installs support preseeding.
[17:55] <fidencio> cyphermox: okay, all installers, even the live medias, support preseeding
[17:56] <cyphermox> yes
[17:57] <fidencio> cyphermox: super, thanks!
[17:57] <cyphermox> fidencio: on the "live" setups, you want to boot with 'only-ubiquity automatic-ubiquity' on the kernel command-line probably, that turns on the bare-bones just-do-preseed UI
[17:58] <cyphermox> it will still pause to ask any questions that you haven't preseeded, but should otherwise run unattended
[18:00] <fidencio> cyphermox: hmm. interesting. and do you know whether I can face some issues passing 'only-ubiquity automatic-ubiquity' on the kernel cmd line on "non live" setups?
[18:02] <cyphermox> fidencio: it should be safe, if you don't start ubiquity it won't matter
[18:03] <fidencio> cyphermox: right. I'll try to come up with something. Hope you don't mind with me coming back asking for help :-)
[18:04] <cyphermox> not at all. #ubuntu-installer is also a good place for general installer-related questions
[18:04] <fidencio> cyphermox: super, I'll join the channel
[18:04] <fidencio> cyphermox: thanks a lot for your help
[19:06] <cking> mterry, mind you can peek at the ZFS MIR again? bug 1532198
[19:07] <cking> bah, programming in x86 has messed up my head, I meant to say "do you mind peeking at.."
[19:07] <mterry> cking, sure
[19:10] <mterry> cking, looks good to me
[19:11] <cking> mterry, thanks, I can get one of the kt to upload it into -propsed for me and let it go through the SRU process then
[19:11] <mterry> cking, not yakkety?  :)
[19:12] <cking> that to..
[19:12] <mterry> MIR bugs don't care about SRUs  :)
[19:12] <cking> mterry, ah, i forgot that, I don't do MIRs that often
[19:13] <mterry> cking, I mean, *I* personally like SRUs, but yeah, once a release is out, we can't promote anything in old releases
[19:13] <mterry> but cool!  With the promise of an upload I'll go ahead and mark the bug fix committed
[19:13] <mterry> cking, ^
[19:15] <mterry> cking, on that note actually, you mention SRUing your dep8 patch for spl-linux, but yakkety would be sufficient.   Less paperwork
[19:16] <cking> mterry, ack, OK
[19:25] <cking> mterry, for the spl, the SRU for the dep8 would be useful to catch any regressions if we make subsequent fixes to SPL over the next 5 years
[19:25] <mterry> fair.  dep8s are great  :)
[19:27] <cking> yeah, I love catching bugs before they get passed -propsed ;-)
[19:36] <doko> pitti, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71072
[20:04] <coreycb> arges, bdmurray: hello, just a friendly alert to let you know we have a brand new mitaka stable point release for neutron* in the xenial queue
[20:05] <arges> coreycb: ok i'll take a look
[20:05] <coreycb> arges, thanks
[20:07] <arges> coreycb: why is the bug invalid 1580674
[20:07] <arges> bug 1580674
[20:09] <coreycb> arges, I just fixed that up
[20:15] <arges> coreycb: why is it invalid in yakkety
[20:15] <arges> coreycb: we can't upload a newer version in xenial than yakkety
[20:16] <coreycb> arges, gah
[20:16] <coreycb> arges, let me get this into yakkety first
[20:20] <coreycb> arges, we'll fix that up and let you know once it's done.  I forgot we're in a weird point in the release where yakkety is basically mitaka for now.
[20:37] <pitti> doko: gnat upstream bug> thanks
[20:39] <doko> pitti, yes, but we need a proper test case
[20:39] <doko> anyway, th gnat transition is still blocked, but doesn't block anything else
[20:57] <mterry> @pilot off
[20:57] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[20:57] <mterry> @pilot out
[21:53] <barry> smoser: you should see a fix for LP: #1560134 show up in yakkety after the normal sausage making