[01:22] <jbicha> Please consider ignoring autopkgtest failures for vagrant: https://bugs.debian.org/828706
[05:28] <cpaelzer> good morning
[05:53] <pitti> Good morning
[05:54] <pitti> slangasek: it is now; I guess still bug 1588566
[05:54] <pitti> slangasek: although the runs take much shorter than the 1.5 hours now after the fs reorg, they still take way too long in some cases, not sure why
[05:55] <pitti> i. e. this bug is still valid
[06:04] <pitti> xnox, infinity: aupkg01 (10.100.0.12) is AWOL again, help please?
[06:04] <pitti> jbicha: retrying gmp-ecm/armhf won't bring much: http://autopkgtest.ubuntu.com/packages/g/gmp-ecm/yakkety/armhf/
[06:05] <pitti> jbicha: 7.0 is really broken on armhf
[06:05] <pitti> (and it takes effing long too, so please don't retry too often)
[06:07] <jbicha> pitti: sorry, I was just clicking buttons :(
[06:08] <pitti> jbicha: no worries, just mentioning that this is really broken
[06:08] <pitti> if it holds up stuff, we need to override
[06:09] <pitti> but this looks like a genuine regression on 32 bit, so it should get at least a bug report
[06:09] <pitti> jbicha: welcome back, by the way! how are you?
[06:10] <jbicha> pitti: I'm doing pretty good, thanks :)
[06:57] <pitti> cjwatson, wgrant: we didn't get an export yesterday on https://translations.launchpad.net/ubuntu/xenial/+language-packs; can you please kick the cron job manually?
[07:13] <smb> Morning, I think someone needs to upload the signed grub2 updates to Trusty (proposed) still. Getting removal hints again
[07:52] <pitti> jbicha: FYI, I filed debian bug 828717 about this
[08:51] <doko> cjwatson, https://launchpad.net/ubuntu/+source/gmp-gcc4/2:6.1.0+dfsg-2ubuntu4 causes gcc-4.7 to fail to build, because libmpc-dev and libmpfr-dev become uninstallable (depending on libgmp-dev). But I assume restoring the provides isn't an option either
[08:52] <doko> https://launchpadlibrarian.net/268126150/buildlog_ubuntu-xenial-amd64.gcc-4.7_4.7.4-3ubuntu12_BUILDING.txt.gz
[08:57] <rbasak> teward: thanks
[09:43] <cjwatson> doko: I don't think restoring the Provides is a good option, no.  The sensible choices seem to be either making libmpc-dev and libmpfr-dev depend on libgmp-dev | libgmpv4-dev, or creating v4 versions of those two packages; I don't know which is better
[09:46] <cjwatson> pitti: I can ask for it, but I'd prefer to wait until the vivid export that's due to start in 45 minutes has finished (which will take a few hours).
[09:47] <pitti> cjwatson: hm, ok (the vivid one is not particularly urgent, but we need the xenial one for 16.04.1)
[09:47] <pitti> but I guess building them tomorrow should be fine
[09:48] <cjwatson> pitti: It could probably be ready by last thing today?
[09:49] <pitti> cjwatson: right; if it is, I'll start the build tonight and do the testing/upload tomorrow
[09:52] <xnox> infinity, sorry =)
[10:49] <xnox> http://people.canonical.com/~ubuntu-archive/pending-sru.html seems to be last generated during EU referendum, and hasn't been since?
[10:50] <xnox> pitti, could you please take a look as to why it is stuck? (if you have access to it)
[10:51] <pitti> xnox: I don't -- I only have ssh, and have no privs to use the console method (remember, we tried a few weeks ago)
[10:51] <pitti> xnox: I enabled crashdump on these machines, maybe there is one now
[10:51] <xnox> pitti, i'm not talking about s390x =)
[10:52] <pitti> xnox: oh sorry, I interpreted that as a pong to the above "aupkg01 is broken", sorry
[10:52] <xnox> pitti, i'm talking about pending-sru generated by sru-report being stuck =0, should be on the same machine as the rest of the archive reports? =)
[10:52] <pitti> xnox: yep, looking
[10:52] <cjwatson> xnox: I've killed the current stuck run.
[10:52] <cjwatson> pitti: ^-
[10:53] <pitti> ah, thansk
[10:53] <cjwatson> Probably got stuck during the GS2 power outage.
[11:38] <cpaelzer> is it "normal" that once I added a remote bug tracker like from ntp in this case bug 1567540 - I "loose" the ability to nominate for Series?
[11:39] <cpaelzer> if so why - and will that state be back to being able to nominate once it fetched the remote status?
[11:54] <rbasak> cpaelzer: swap debian for ubuntu in the URL.
[11:54] <rbasak> cpaelzer: it's a Launchpad UI issue.
[11:55] <cpaelzer> rbasak: thanks ... but ... I see no debian in my URL
[11:56] <cpaelzer> rbasak: the remote bug tracker is to ntp and the "browser" utl is https://bugs.launchpad.net/ntp/+bug/1567540
[11:56] <cpaelzer> rbasak: where do I need to change it?
[11:56] <rbasak> Oh, sorry.
[11:56] <rbasak> Try: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1567540
[11:57] <rbasak> Basically the URL you follow has to be part of the Ubuntu project for you to see the Nominate stuff. Note that the bar that is yellow changes.
[11:57] <cpaelzer> rbasak: dirty dark secrets - that did it - thanks
[11:57] <xnox> ..
[11:57] <xnox> how does one launch lxc armhf container on amd64?
[11:57] <xnox> using lxd2.0
[11:57] <rbasak> tjaalton: any objection to syncing cobbler in bug 1593434? You TIL.
[13:13] <tjaalton> rbasak: nope
[13:25] <rbasak> tjaalton: great, thanks.
[13:57] <pitti> tyhicks: hey, how are you?
[13:58] <pitti> tyhicks: I just saw https://tracker.debian.org/news/777985 -- most of Debian's changes towards our package sound sensible for us too, so merging should hopefully have a very small delta now?
[13:58]  * pitti is particularly interested in providing a native systemd units, as rcS init.d scripts are still problematic and we have a large patch for that downstream
[14:07] <tyhicks> pitti: hi - doing pretty well
[14:09] <tyhicks> pitti: those do sound like reasonable changes - we'll have a look at syncing
[14:10] <tyhicks> pitti: we work with intrigeri quite a bit in #apparmor so I'll ask him if I see anything odd
[14:10] <pitti> tyhicks: oh, nice
[14:53] <bdmurray> tjaalton: Could you look at fixing bug 1500751 in Trusty?
[15:04] <tjaalton> apw: ^ can you cherry-pick that for trusty too?
[15:04] <apw> tjaalton, likely :)
[15:04] <tjaalton> good :)
[15:35] <nacc> Logan: thanks! jbicha created a tag ('php7') for all those kind of bugs, I'll check on it
[15:45] <smb> tjaalton, though you did not ask whether apw *will* do so :-P
[15:46] <apw> smb, don't give away my trade secrets
[15:46] <smb> apw, oops ... sorry
[16:54] <nacc> mwhudson_: re: LP: #1569609, any ideas of how to make it get some more traction? was just reviewing LP: #1596578 and I don't think I can easily (without learning all about PHP internals) backport the change needed.
[18:34] <nacc> rbasak: re: LP: #1593434, would it make sense to SRU or (possibly instead -backport) it to 16.04? AIUI, due to at least LP: #1570891, the version in 16.04 doesn't currently work. I'm an upstream developer for cobbler, and I'd much rather see 16.04 have a more current release.
[18:36] <jbicha> nacc: "upgrade of Cobbler from 2.4.1 -> 2.6.x is not supported upstream"
[18:37] <jbicha> how bad is that going to be for those already using cobbler in Ubuntu?
[18:39] <nacc> jbicha: i'm going to figure that out now :)
[18:39] <nacc> jbicha: i've never deployed 2.4.x
[18:39] <nacc> jbicha: and no one using cobbler these days (that i've dealt with) has either :/
[18:39] <nacc> jbicha: i would argue this is similar to php5 -> php7, and other major transitions (albeit in a universe package), where we really can't migrate the configuration
[18:40] <jbicha> I haven't used cobbler at all, but I'm thinking from an sru, it might be nice to know what happens from 14.04 LTS to 16.04 LTS
[18:40] <nacc> agreed, i wouldn't suggest it formally until i figured that out
[18:40] <nacc> jbicha: hence why i also wondered if -backports made some sense, since there might not be an upgrade path and backports is op-tin
[18:41] <jbicha> oh, the upgrade from 14.04 to 16.04 needs manual work for php?
[18:42] <nacc> jbicha: if you have local configuration, i believe it doesn't apply, possibly (variables got renamed, etc)
[18:42] <jbicha> well since it's also "server" related I guess that's good precedence, if it's at least release noted
[18:42] <nacc> jbicha: the language itself is BC, but i think the configuration has moved around, etc.
[18:45] <nacc> well, mostly BC :)
[18:46] <nacc> jbicha: yeah, i plan on adding a cobbler blurb yakkety release notes
[19:44] <nacc> Logan: ok, there are definitely issues with zabbix, but i got them all fixed andwill file an SRU now
[19:44] <nacc> i was able to successfully deply the version in xenial in a container and bring up the web ui
[19:50] <rbasak> nacc: backports> yes, definitely. SRU> if it's completely broken in Xenial. Otherwise depends on severity I guess.
[19:51] <rbasak> nacc: the amount of effort required to do it right may be too much though. I guess you'll find out.
[19:56] <pitti> wgrant: I seem to have lost the combobox on https://translations.launchpad.net/ubuntu/xenial/+language-packs for marking a new full export as base for future diffs
[20:13] <nacc> rbasak: ack, thanks!
[21:13] <mwhudson_> nacc: er did you really mean to ping me about that?
[22:09] <nacc> mwhudson: you touched it last, in terms of the bug, if you had any ideas, i'd appreciate it; probably not directly yours to figure out though
[22:10] <mwhudson> nacc: oh heh
[22:10] <mwhudson> nacc: my understading is that it still requires someone on the SRU team to decide
[22:11] <nacc> mwhudson: ack, that's my understanding too; and given it's a larger request, I imagine it will take time. I'm just a bit worried because I'm not sure how to SRU more involved fixes at this point, given our code-base.
[22:11] <mwhudson> nacc: uploading something is probably a good way to encourage that to happen though
[22:11] <mwhudson> nacc: do you have/can you make a package for me to sponsor?
[22:11] <nacc> mwhudson: yeah, i can do that shortly, give me a little bit (i'll update the bug)
[22:11] <mwhudson> nacc: cool
[22:11] <nacc> mwhudson: thanks for that reminder :)
[22:12]  * mwhudson subscribes to the bug, oops
[22:13] <nacc> mwhudson: i've got a couple php7.0 SRU bugs pending too; would the right thing to do be to submit two debdiffs (one for the two known bugs w/ fixes and then another after that pulling in the new upstream?)
[22:13] <Grorco> what is the name of the software and updates package?
[22:14] <mwhudson> nacc: if the bugfixes are in the new upstream release, then aiui, no, just mention all the bugs in the changelog
[22:16] <Grorco> nevermind I figured it out
[22:17] <nacc> mwhudson: they aren't (packaging issues) -- i could also fix them in my upstream release update, but i wasn't sure if that would be appropriate or not.
[22:18] <mwhudson> nacc: ah. still, i think fixing it all at once /probably/ makes sense
[22:18] <mwhudson> nacc: just write a clear changelog entry
[22:18] <nacc> mwhudson: yep, i am happy to do it that way (and means only one upload). Will do!
[22:19] <nacc> mwhudson: thanks for the input!
[22:19] <mwhudson> nacc: i'm not an expert in predicting the SRU team's desires yet though :-)
[22:26] <Logan> nacc: cool, I approved your nomination for Xenial
[22:37] <nacc> Logan: thanks!
[22:42] <mwhudson> ubuntu@yakkety:~$ du -h `which golang-petname`
[22:42] <mwhudson> 16K	/usr/bin/golang-petname
[22:42] <mwhudson> \o/
[22:42] <sarnold> !!
[22:42] <sarnold> nice :)
[22:43] <mwhudson> now i just need to beat go-systemd's upstream heads together to get rid of a dependency loop...
[22:44] <mwhudson> and MIR golang-github-coreos-pkg-dev (related to above)
[22:58] <ret2libc> hi. https://www.youtube.com/watch?v=CgjdUkgPiZo at 36:39 he says that the appstream generator will be "in ubuntu, for ubuntu" if i hear it correctly. why not making it available for every distro?
[23:03] <Grorco> Hello I'm new to this and I'm trying to us bazaar to get a branch of software-properties-gtk and it says it doesn't exist
[23:05] <Grorco> bzr branch ubuntu:software-properties-gtk software-properties-gtk.dev is what I'm using am I doing something wrong?
[23:06] <jbicha> bzr branch lp:software-properties
[23:07] <jbicha> or apt source software-properties
[23:07] <jbicha> the ubuntu: branches are usually out-of-date these days
[23:38] <nacc> mwhudson: just an fyi, finally finished refershing the php7.0 patches, build and testing it now locally
[23:38] <nacc> mwhudson: also filed LP: #1596735 so xenial's version doesn't get ahead of yakkety's
[23:41] <mwhudson> nacc: looking
[23:52] <nacc> mwhudson: our delta is pretty trivial, i've subscribed -sponsors already, so only if you have time
[23:56] <nacc> Logan: had a quick q for you on zabbix. I noticed something kind of funky just now, in that if you install zabbix-server-mysql (or i think zabbix-proxy-mysql) and zabbix-frontend-php, you don't necessarily get php-mysql installed, even though it's a dep of the frotend package. That's because there are three alternatives and it just picks php-pgsql. But the frontend configuration wizard won't even show
[23:57] <nacc> MySQL as an option for the backing database w/o php-mysql installed. Is there any prior art for handling if pkg A is to be installed and pkg B is installed, then pkg C should be used for an alternative-dep?