[00:16] <nacc> if i have a package sync'd from debian in xenial that needs to be rebuilt (rebuild fixes a bug in xenial); would i upload that as <version>ubuntu0.1 still? Or is there a way to specify an SRU is arebuild only?
[00:24] <infinity> nacc: 1.2.3-4build0.1
[00:24] <infinity> nacc: Or just build1, if there's a higher version in yakkety.
[00:24] <nacc> infinity: thanks!
[06:05] <pitti> Good morning
[06:18] <pitti> stgraber: bonjour ! do you mind setting up zesty container builds on images.linuxcontainers.org? that would unbreak a few tests (like docker.io) which use them
[07:51] <sil2100> caribou: hey, you said once that you were asked to check the dbus fix for the systemd logind issue, right?
[07:52] <sil2100> caribou: since we seem to have a working fix now but not approved/reviewed formally by upstream yet (although it's coming from upstream) - want to give that a spin?
[07:52] <caribou> sil2100: yes, I have what looks like a similar issue, but I'm not able to reproduce using an ssh login loop
[07:53] <caribou> sil2100: where is it ? in your PPA ?
[07:53] <sil2100> caribou: I'll be preparing an official release for that soonish for zesty, but would like some more people to give it a spin
[07:53] <sil2100> caribou: yes, the bug points to which PPA to use
[07:53] <sil2100> (xenial and yakkety packages IIRC)
[07:53] <caribou> sil2100: I'll see what I can do
[07:53] <sil2100> caribou: do you have any experience in dbus code?
[11:25] <pitti> doko: apparently the new gcc in zesty breaks some stuff (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-022/+packages), yesterday's builds were still okay; but I fail to see the actual error in https://launchpadlibrarian.net/290302168/buildlog_ubuntu-zesty-i386.indicator-network_0.8.0+17.04.20161021-0ubuntu1_BUILDING.txt.gz , do you see it?
[11:25] <pitti> could also be new cmake, of course
[11:26] <pitti> LocutusOfBorg: ^ maybe you can have a look at that build log too? it's completely obtuse to me what actually fails
[11:34] <pitti> (this is architecture independent)
[11:43] <pitti> CMake Error at CMakeLists.txt:25 (include):
[11:43] <pitti>   include could not find load file:
[11:43] <pitti>     EnableCoverageReport
[11:43] <pitti> oh, that ^ LocutusOfBorg, that's your bug
[12:03] <pitti> LocutusOfBorg: filed as bug 1635613
[12:08] <LocutusOfBorg> ok wilco
[12:21] <LocutusOfBorg> pitti, got it
[12:21] <LocutusOfBorg> damn damn damn stupid extra package
[12:24] <LocutusOfBorg> pitti, fixed
[12:25] <LocutusOfBorg> will comment on the bug too
[12:27] <LocutusOfBorg> how can I force cmake-extras to not let cmake migrate on new upstream releases?
[12:27] <LocutusOfBorg> we should force some breaks cmake >= 3.6 or whatever in control file
[12:28] <LocutusOfBorg> otherwise we will forget this on cmake 3.7 again
[12:42] <sil2100> 12131
[12:42] <sil2100> Whoops
[12:42] <sarnold> that's not a very good password
[12:44] <sil2100> Darn it
[12:44]  * sil2100 quickly changes his bank account password
[12:54] <pitti> LocutusOfBorg: oh, thanks for tracking that down! I'll rebuild those packages once it gets published
[12:54] <LocutusOfBorg> thanks for notifying me
[12:55] <LocutusOfBorg> btw next time if you want an even speedier fix, just try to ping me before or after lunch, not during :)
[12:55] <LocutusOfBorg> I don't read irc while lunching :D
[12:55] <pitti> LocutusOfBorg: ok, then next time I'll use my crystal ball to anticipate FTBFS before they happen :-P
[12:55] <pitti> LocutusOfBorg: speedy enough, many thanks!
[12:56] <LocutusOfBorg> anticipating FTBFS would be awesome, do you have any patch or ETA for the implementation? will it run as a systemd unit?
[12:56] <LocutusOfBorg> systemd-ftbfsd
[12:56] <LocutusOfBorg> :D
[12:58] <pitti> LocutusOfBorg: <sheldon_cooper>I will have had have this written soon :)
[12:59] <pitti> (tempus when they discussed a time travel movie)
[12:59] <LocutusOfBorg> :) I remember
[12:59] <LocutusOfBorg> btw did you watch the last episode? you will finally know why he is always knowking thrice the door
[12:59] <pitti> LocutusOfBorg: no, 9th season isn't on netflix in Germany yet :(
[13:00]  * pitti currently spends his lunch breaks on 4th season of House of Cards
[13:00] <LocutusOfBorg> is thrice a valid word? /me is confused
[13:00] <sarnold> it is, not common but valid
[13:00] <pitti> I've seen it often enough
[13:00] <LocutusOfBorg> thanks sarnold :)
[13:36] <LocutusOfBorg> hi britney, do you mind doing some work today?
[13:48] <sil2100> britney was buys
[13:48] <sil2100> *busy
[13:48] <sil2100> I uploaded a new dbus package to -proposed earlier today and that triggered a bazillion of autopkgtests
[13:52] <LocutusOfBorg> oh, now I'll change the topic to "britney is busy? blame sil2100 " :)
[14:08] <pitti> LocutusOfBorg: works now, thanks!
[14:11] <LocutusOfBorg> yw :)
[14:13] <LocutusOfBorg> your britney is faster than mine :/
[14:26] <coreycb> infinity, bdmurray: hello, would you be able to take a look at these in one of your sru review slots next week?  nova promotion to xenial-updates for bug 1608934 and review of mistral, neutron, nova for the xenial upload queue.
[14:34] <sinzui> stgraber: regarding bug 1635639. We have lxc working with the have, but lxd still wont work. any clues?
[15:41] <stgraber> pitti: yeah, doing that now
[15:42] <stgraber> pitti: need to check if xenial's debootstrap know about zesty though
[15:42] <pitti> stgraber: argh, it doesn't have been SRUed yet
[15:42] <pitti> ... and yay at my Friday afternoon grammar :)
[15:43] <pitti> doesn't has not have will had been SRUed
[15:48] <rbasak> That's interesting. 50unattended-upgrades says ${distro_id}:${distro_codename}. Currently, that's yakkety, even though sources.list points to "devel". So unattended-upgrades won't do a "rolling release" for me on this machine as I wanted.
[17:03] <pitti> apw, cjwatson, cyphermox, slangasek, infinity: I noticed that we still have grub (1.x) in the archive; do we still actually need it for anything?
[17:04] <pitti> I noticed that it ships /sbin/update-grub, which would shadow grub2's /usr/sbin/update-grub
[17:04] <pitti> (same for grub-install)
[17:08] <pitti> stgraber: btw, I think you can/should stop building wily images
[17:11] <stgraber> pitti: yeah, I noticed those when adding zesty and removed them from Jenkins, they'll expire soon from the image servers
[17:28] <slangasek> pitti: cyphermox was doing some final analysis of whether there were still any use cases for grub1; I don't know if he finished that yet
[17:28] <slangasek> I know there were still references to grub1 in grub-installer udeb that we wanted to remove
[17:33] <cyphermox> I think I removed the already, but I'd have to look again
[17:37] <slangasek> cyphermox: once you've looked, please ack the removal request (LP: #1611740)
[18:33] <smoser> TheMuso, hey. wrt 4.4 and 4.8 and sbuild...
[18:34] <smoser> i grabbed 4.4 from xenial, rebooted into it. built the same trival package that i built yesterday on 4.8
[18:34] <smoser> $ ( cd /home/smoser/ubuntu/logs/ && grep "^Build needed" smello_0.4~ppa1_amd64-2016-10-2*)
[18:34] <smoser> smello_0.4~ppa1_amd64-2016-10-20T16:48:33Z.build:Build needed 00:02:34, 120k disc space
[18:34] <smoser> smello_0.4~ppa1_amd64-2016-10-21T18:31:17Z.build:Build needed 00:00:32, 120k disc space
[19:07] <tsimonq2> Hello. Can someone please sync the cmst from Testing to Zesty?
[19:08] <tsimonq2> !info cmst testing
[19:08] <tsimonq2> !info cmst zesty
[19:08] <tsimonq2> ^^
[19:08] <tsimonq2> I would do it, but I don't have upload access...
[19:11] <tsimonq2> Nevermind, I found the requestsync tool.
[19:12] <hjd_> tsimonq2: See also https://wiki.ubuntu.com/SyncRequestProcess :)
[19:13] <tsimonq2> hjd_: That's where I found it. ;)
[19:13] <tsimonq2> bug 1635705
[19:13] <tsimonq2> \o/
[19:15] <slangasek> xnox: 6 oldest packages in -proposed resolved or in process; max package age cut from 800+ days to 437 days; you're welcome ;)
[19:18] <hjd_> tsimonq2: Just in case you found it somewhere else.
[19:19] <hjd_> tsimonq2: Also note that the package will probably be synced automatically now that Zesty seems to have opened for development.
[19:23] <slangasek> zul: why does monasca-statsd have a 'LICENSE' file in its tree that doesn't match the copyright holder or license listed on any of the source files?
[19:24] <slangasek> zul: empty Homepage: field in debian/control, not useful?  and lintian reports a warning on debian/copyright because the names in the License: fields don't match up
[19:27] <zul> slangasek: ill have a look thanks
[19:28] <slangasek> zul: only the answer to the first question blocks NEW processing (the debian/copyright and LICENSE file don't match, so I need to know why)
[19:29] <zul> slangasek: im not sure why ill get upstream to look at it
[19:54] <Unit193> https://packages.qa.debian.org/d/debootstrap/news/20161021T194901Z.html merged-usr is default.
[19:59] <TheMuso> smoser: Yeah nice to confirm it, thanks.
[20:04] <nacc> ok, got a somewhat tricky SRU question -- LP: #1577916 works for upgrades/installs from 14.04. But if you're already on 16.04 and thus got php-fpm pulled in by the older ganglia-webfrontend package, how do I forcibly require that libapache2-mod-php be used to satisfy the dependnecy? The issue is (I think) that since php7.0-fpm already satisfies php7.0 (satisfies php), it doesn't matter the order they
[20:04] <nacc> are expressed in (libapache2-mod-php | php | php-cgi vs. php | php-cgi | libapache2-mod-php) on installation/upgrade *if* php-fpm is already installed. But if it was only installed because of ganglia-webfrontend (broken version), i'm not sure how to automatically detect that and switch the dep
[20:36] <infinity> nacc: If it doesn't work with other php implementations, your dependencies are a lie.  If it does work with others, there's no bug.
[20:36] <infinity> nacc: Not much halfway point here.
[20:39] <infinity> nacc: But to answer the more complex question, "can I tell what webserver the user has installed, and install the right PHP magically?", the answer is no.
[20:39] <infinity> nacc: So, there's a certain onus on them to get it right.
[20:40] <infinity> nacc: If apt supported Enhances, it could probably help guess a bit, but in the end, it's generally going to be the user's responsiblity to pick the right PHP for their setup.  It's always been this way.  Just that, historically, most users used apache, and most php-depending things listed the apache module first, so it JusT Worked for those people.
[20:40] <infinity> nacc: And for people who did non-Apache things, they knew how to get there.
[20:40] <infinity> nacc: So, certainly, the path of least surprise is to make sure upgrades continue that trend.
[20:41] <infinity> nacc: As for people already on 16.04 with the "wrong" deps, you can't fix that, and you shouldn't try, because "fixing" it might not be a fix.
[20:41] <infinity> nacc: As in, you might "fix" an nginx system by breaking it. :P
[20:42] <infinity> nacc: If Apache users got the inverted deps, either they've given up by now (no one sits on a broken webapp for 3 months), or they flipped the packages around correctly so it worked.
[21:43] <nacc> infinity: ack on all that
[21:45] <nacc> infinity: it *can* work with any of the deps, as described in the control file (afaict), but it requires manual changes to work with fpm in this case, and 'just works' (has apache conf hooks) for the mod-php case