[01:22] Please consider ignoring autopkgtest failures for vagrant: https://bugs.debian.org/828706 [01:22] Debian bug 828706 in src:vagrant "vagrant: autopkgtest fails if dependency has newer upstream version" [Normal,Open] === ezri is now known as dax [05:28] good morning [05:53] Good morning [05:54] slangasek: it is now; I guess still bug 1588566 [05:54] bug 1588566 in Auto Package Testing "autopkgtest results go missing for a long time after the test completes" [Undecided,In progress] https://launchpad.net/bugs/1588566 [05:54] 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] i. e. this bug is still valid [06:04] xnox, infinity: aupkg01 (10.100.0.12) is AWOL again, help please? [06:04] jbicha: retrying gmp-ecm/armhf won't bring much: http://autopkgtest.ubuntu.com/packages/g/gmp-ecm/yakkety/armhf/ [06:05] jbicha: 7.0 is really broken on armhf [06:05] (and it takes effing long too, so please don't retry too often) [06:07] pitti: sorry, I was just clicking buttons :( [06:08] jbicha: no worries, just mentioning that this is really broken [06:08] if it holds up stuff, we need to override [06:09] but this looks like a genuine regression on 32 bit, so it should get at least a bug report [06:09] jbicha: welcome back, by the way! how are you? [06:10] pitti: I'm doing pretty good, thanks :) [06:57] 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? === spineau is now known as spineau_afk [07:13] Morning, I think someone needs to upload the signed grub2 updates to Trusty (proposed) still. Getting removal hints again [07:52] jbicha: FYI, I filed debian bug 828717 about this [07:52] Debian bug 828717 in gmp-ecm "gmp-ecm: 7.0 regresses on 32 bit platforms" [Important,Open] http://bugs.debian.org/828717 === athairus is now known as afkthairus [08:51] 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] https://launchpadlibrarian.net/268126150/buildlog_ubuntu-xenial-amd64.gcc-4.7_4.7.4-3ubuntu12_BUILDING.txt.gz [08:57] teward: thanks === spineau_afk is now known as spineau [09:43] 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] 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] cjwatson: hm, ok (the vivid one is not particularly urgent, but we need the xenial one for 16.04.1) [09:47] but I guess building them tomorrow should be fine [09:48] pitti: It could probably be ready by last thing today? [09:49] cjwatson: right; if it is, I'll start the build tonight and do the testing/upload tomorrow [09:52] infinity, sorry =) === hikiko is now known as hikiko|afk === _salem is now known as salem_ [10:49] http://people.canonical.com/~ubuntu-archive/pending-sru.html seems to be last generated during EU referendum, and hasn't been since? [10:50] pitti, could you please take a look as to why it is stuck? (if you have access to it) [10:51] 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] xnox: I enabled crashdump on these machines, maybe there is one now [10:51] pitti, i'm not talking about s390x =) [10:52] xnox: oh sorry, I interpreted that as a pong to the above "aupkg01 is broken", sorry [10:52] 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] xnox: yep, looking [10:52] xnox: I've killed the current stuck run. [10:52] pitti: ^- [10:53] ah, thansk [10:53] Probably got stuck during the GS2 power outage. === salem_ is now known as _salem === _salem is now known as salem_ [11:38] 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:38] bug 1567540 in ntp (Ubuntu) "ntpd crashed with SIGABRT (was: ntp crashes everytime the network goes up or down.)" [High,Triaged] https://launchpad.net/bugs/1567540 [11:39] if so why - and will that state be back to being able to nominate once it fetched the remote status? [11:54] cpaelzer: swap debian for ubuntu in the URL. [11:54] cpaelzer: it's a Launchpad UI issue. [11:55] rbasak: thanks ... but ... I see no debian in my URL [11:56] rbasak: the remote bug tracker is to ntp and the "browser" utl is https://bugs.launchpad.net/ntp/+bug/1567540 [11:56] Launchpad bug 1567540 in ntp (Ubuntu) "ntpd crashed with SIGABRT (was: ntp crashes everytime the network goes up or down.)" [High,Triaged] [11:56] rbasak: where do I need to change it? [11:56] Oh, sorry. [11:56] Try: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1567540 [11:57] 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] rbasak: dirty dark secrets - that did it - thanks [11:57] .. [11:57] how does one launch lxc armhf container on amd64? [11:57] using lxd2.0 [11:57] tjaalton: any objection to syncing cobbler in bug 1593434? You TIL. [11:57] bug 1593434 in cobbler (Ubuntu) "Sync cobbler 2.6.6+dfsg1-12 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1593434 === hikiko|afk is now known as hikiko [13:13] rbasak: nope [13:25] tjaalton: great, thanks. [13:57] tyhicks: hey, how are you? [13:58] 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] pitti: hi - doing pretty well [14:09] pitti: those do sound like reasonable changes - we'll have a look at syncing [14:10] pitti: we work with intrigeri quite a bit in #apparmor so I'll ask him if I see anything odd === olli__ is now known as olli [14:10] tyhicks: oh, nice [14:53] tjaalton: Could you look at fixing bug 1500751 in Trusty? [14:53] bug 1500751 in initramfs-tools (Ubuntu Trusty) "Cryptsetup Keyboard not working on Xubuntu 3.19.0-30" [High,Triaged] https://launchpad.net/bugs/1500751 === willcooke_ is now known as willcooke [15:04] apw: ^ can you cherry-pick that for trusty too? [15:04] tjaalton, likely :) [15:04] good :) [15:35] Logan: thanks! jbicha created a tag ('php7') for all those kind of bugs, I'll check on it [15:45] tjaalton, though you did not ask whether apw *will* do so :-P [15:46] smb, don't give away my trade secrets [15:46] apw, oops ... sorry [16:54] 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. [16:54] Launchpad bug 1569609 in php7.0 (Ubuntu Xenial) "[SRU] microrelease exception for src:php7.0" [Wishlist,New] https://launchpad.net/bugs/1569609 [16:54] Launchpad bug 1596578 in php7.0 (Ubuntu) "zabbix issues with current php version" [Undecided,New] https://launchpad.net/bugs/1596578 [18:34] 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:34] Launchpad bug 1593434 in cobbler (Ubuntu) "Sync cobbler 2.6.6+dfsg1-12 (universe) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/1593434 [18:34] Launchpad bug 1570891 in cobbler (Ubuntu) "cobbler uses old cobblerd URL resulting in URLError" [Medium,Confirmed] https://launchpad.net/bugs/1570891 [18:36] nacc: "upgrade of Cobbler from 2.4.1 -> 2.6.x is not supported upstream" [18:37] how bad is that going to be for those already using cobbler in Ubuntu? [18:39] jbicha: i'm going to figure that out now :) [18:39] jbicha: i've never deployed 2.4.x [18:39] jbicha: and no one using cobbler these days (that i've dealt with) has either :/ [18:39] 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] 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] agreed, i wouldn't suggest it formally until i figured that out [18:40] 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] oh, the upgrade from 14.04 to 16.04 needs manual work for php? [18:42] jbicha: if you have local configuration, i believe it doesn't apply, possibly (variables got renamed, etc) [18:42] well since it's also "server" related I guess that's good precedence, if it's at least release noted [18:42] jbicha: the language itself is BC, but i think the configuration has moved around, etc. === mnepton is now known as mneptok [18:45] well, mostly BC :) [18:46] jbicha: yeah, i plan on adding a cobbler blurb yakkety release notes [19:44] Logan: ok, there are definitely issues with zabbix, but i got them all fixed andwill file an SRU now [19:44] i was able to successfully deply the version in xenial in a container and bring up the web ui [19:50] nacc: backports> yes, definitely. SRU> if it's completely broken in Xenial. Otherwise depends on severity I guess. [19:51] nacc: the amount of effort required to do it right may be too much though. I guess you'll find out. [19:56] 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 === afkthairus is now known as athairus [20:13] rbasak: ack, thanks! [21:13] nacc: er did you really mean to ping me about that? === mwhudson_ is now known as mwhudson === salem_ is now known as _salem === nobuto_ is now known as nobuto [22:09] 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] nacc: oh heh [22:10] nacc: my understading is that it still requires someone on the SRU team to decide [22:11] 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] nacc: uploading something is probably a good way to encourage that to happen though [22:11] nacc: do you have/can you make a package for me to sponsor? [22:11] mwhudson: yeah, i can do that shortly, give me a little bit (i'll update the bug) [22:11] nacc: cool [22:11] mwhudson: thanks for that reminder :) [22:12] * mwhudson subscribes to the bug, oops [22:13] 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] what is the name of the software and updates package? [22:14] nacc: if the bugfixes are in the new upstream release, then aiui, no, just mention all the bugs in the changelog [22:16] nevermind I figured it out [22:17] 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] nacc: ah. still, i think fixing it all at once /probably/ makes sense [22:18] nacc: just write a clear changelog entry [22:18] mwhudson: yep, i am happy to do it that way (and means only one upload). Will do! [22:19] mwhudson: thanks for the input! [22:19] nacc: i'm not an expert in predicting the SRU team's desires yet though :-) [22:26] nacc: cool, I approved your nomination for Xenial [22:37] Logan: thanks! [22:42] ubuntu@yakkety:~$ du -h `which golang-petname` [22:42] 16K /usr/bin/golang-petname [22:42] \o/ [22:42] !! [22:42] nice :) [22:43] now i just need to beat go-systemd's upstream heads together to get rid of a dependency loop... [22:44] and MIR golang-github-coreos-pkg-dev (related to above) [22:58] 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] 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] bzr branch ubuntu:software-properties-gtk software-properties-gtk.dev is what I'm using am I doing something wrong? [23:06] bzr branch lp:software-properties [23:07] or apt source software-properties [23:07] the ubuntu: branches are usually out-of-date these days [23:38] mwhudson: just an fyi, finally finished refershing the php7.0 patches, build and testing it now locally [23:38] mwhudson: also filed LP: #1596735 so xenial's version doesn't get ahead of yakkety's [23:38] Launchpad bug 1596735 in php7.0 (Ubuntu) "Please merge with php7.0 7.0.8-2 from Debian unstable" [Wishlist,New] https://launchpad.net/bugs/1596735 [23:41] nacc: looking [23:52] mwhudson: our delta is pretty trivial, i've subscribed -sponsors already, so only if you have time [23:56] 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] 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?