[00:58]  * mwhudson looks sceptically at dh_systemd_enable
[01:22] <mwhudson> blargh, docker.socket doesn't start at all on arm64 and docker startup hangs on 16.04
[01:22] <mwhudson> SRU verification going great
[01:23] <mwhudson> oh wait docker is in NEW on amd64
[02:02] <seamlik> cjwatson: Thanks for dealing with Gradle's FTBFS! :)
[02:41] <mwhudson> so today i found that mongodb 3.2.10~rc1 ftbfs everywhere except ppc64el (!?) and that the docker in xenial-proposed is broken
[02:41] <mwhudson> sounds like a good time to stop for a bit...
=== JanC is now known as Guest5754
=== JanC_ is now known as JanC
[05:23] <pitti> barry: I still wonder whether gcc+python-dev shouldn't still be proper depends instead of just test-depends
[05:23] <pitti> barry: don't we want to move to world-4.0 long-term? pinning it to the older version for python2 seems ok, but the < 4.0 ones will get obsolete at some point?
[05:23] <pitti> Good morning
[05:39] <pitti> infinity: oh nice, glibc is green again (after the hostname.. fix)
[06:08] <doko> wgrant: thanks! results were better in the past, still a lot to fix :-/
[06:12] <pitti> apw: is it just on my box, or is 4.8 awfully slow at boot? it's no step in particular, everything seems evenly smeared out (dmesg boot timestamps go up to 39s)
[06:12] <pitti> (ThinkPad x230)
[06:13] <pitti> meh, brightness change is broken as well
[06:13]  * pitti will file bugs in a bit
[06:15] <doko> pitti: brightness change works here, but it's a lot delayed after typing (x250)
[06:18] <doko> 87 ftbfs in main alone, and armhf and arm64 not yet tested. http://ubuntuqa.tblwd.org/ftbfs/test-rebuild-20160916-yakkety.html
[06:21] <sarnold> pitti: nacc reported insane load averages with sbuild
[06:27] <pitti> sarnold: trying that here
[06:27] <pitti> sarnold: reported in LP already, or just on IRC?
[06:27] <sarnold> pitti: afaik only on IRC
[06:28] <pitti> load average: 249,08, 79,27, 34,43
[06:28] <pitti> holy crap
[06:29] <sarnold> hah, that's 27 better! he reported 222
[06:29] <pitti> sarnold: that smells more like a simple numeric problem, though -- the machine doesn't actually "feel" slow and laggy
[06:29] <pitti> I'll compare sbuild times with 4.4 and 4.8
[06:29] <sarnold> interesting; he reported "all kinds of laggy"
[06:30] <pitti> sarnold: well, I've only run it for like 10 minutes
[06:30] <pitti> I just noticed that boot feels like Pentium with slow spinning rust
[06:30] <sarnold> ouch :)
[06:30]  * sarnold hands pitti fvwm1
[06:31] <pitti> sarnold: well, i3 here, but that actually doesn't seem to be the problem :) it's everything *up to* lightdm, i. e. you can conveniently read every starting service line (without "quiet" and "splash")
[06:31] <pitti> instead of them just zipping by
[06:33] <sarnold> wow :)
[06:35] <pitti> Build needed 00:00:00, 0k disc space
[06:35] <pitti> err, thanks sbuild
[06:35] <pitti> I suppose this also used something that broke with 4.8..
[06:36] <sarnold> and you said it was slow.. :)
[06:36] <pitti> heh
[06:36] <pitti> also, *very* efficient RAM compression!
[06:36] <sarnold> :D
[06:50] <pitti> sarnold: so, sbuilding color under 4.4 and 4.8 both took about 7'30'', no real difference there
[06:50] <sarnold> pitti: and how'd the feel interactively?
[06:51] <pitti> nothing noticeable
[06:51] <pitti> it's booting that sucks, so maybe setting up cgroups or non-compiler parallelism, not sure
[06:53] <pitti> sarnold: actually, it's 6'30'' (4.4) vs. 7'30'' (4.8), I just can't do math this morning yet
[06:55] <StevenK> The coffee drip isn't attached yet?
=== hikiko is now known as hikiko|bbiab
[07:33] <pitti> StevenK: yeah, no tea IV :)
[08:05] <doko> apw: libecap breaks with new kernel headers
[08:05] <apw> bah
[08:08] <apw> doko, where can i see that
[08:08] <mwhudson> pitti: hey
[08:09] <mwhudson> pitti: i have a package (docker.io) that fails to start its socket on xenial but it works on yakkety
[08:09] <doko> apw: sorry, http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html. so we will see this for universe only, because the main part of the test rebuild was finished when 4.8 was uploaded
[08:09] <mwhudson> pitti: do you know of anything in this neighbourhood that's changed xenial->yakkety?
[08:10] <seb128> doko, hey, would it help with the component mismatch view to change MIR bugs from previously promoted then demoted components back to fix commited to they are yellow on the svg?
[08:10] <apw> doko, ok ta
[08:13] <pitti> apw: filed as bug 1626429 and bug 1626436 FTR
[08:13] <ubottu> bug 1626429 in linux (Ubuntu) "[4.8 regression][ThinkPad X230] brightness change keys do not work any more" [Undecided,Confirmed] https://launchpad.net/bugs/1626429
[08:13] <ubottu> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Undecided,New] https://launchpad.net/bugs/1626436
[08:13] <pitti> mwhudson: you mean during package installation?
[08:13] <mwhudson> pitti: yes
[08:13] <doko> seb128: sure, but would be nice to leave a comment in the issue
[08:13] <seb128> doko, k, let me do that
[08:14] <pitti> mwhudson: I saw bug 1626166 yesterday; my suspicion is that this was some fix in dh_systemd_start
[08:14] <ubottu> bug 1626166 in lvm2 (Ubuntu Xenial) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,Triaged] https://launchpad.net/bugs/1626166
[08:14] <doko> seb128: or ask pitti to mark those with a different color =)
[08:14] <mwhudson> pitti: yeah that looks pretty similar
[08:15] <mwhudson> pitti: i don't think it's a dh_systemd thing though because the postinsts in the yakkety and xenial packages are ~the same
[08:15] <seb128> doko, that would be even better ;-)
[08:17] <pitti> mwhudson: I did notice that the .socket wasn't  actually started in the postinst; that seemed to be the obvious missing thing?
[08:17] <mwhudson> pitti: the docker.socket file is enabled (i.e. /etc/systemd/system/sockets.target.wants/docker.socket exists)
[08:17] <pitti> mwhudson: yes, enabled is fine, but that only applies to the next boot
[08:17] <mwhudson> pitti: postinst says "deb-systemd-helper enable docker.socket >/dev/null || true"
[08:17] <pitti> enabling and starting are two different and independent things
[08:17] <mwhudson> is that right?
[08:17] <mwhudson> ah ok
[08:18] <mwhudson> but it works in yakkety...
[08:18] <pitti> mwhudson: hmm, maybe daemon-reload now automatically starts enabled sockets
[08:18] <mwhudson> pitti: that would definitely explain it
[08:19] <pitti> mwhudson: (just a wild guess, I'm not aware of that and it  shouldn't actually be that way)
[08:20] <pitti> mwhudson: and I'd also avoid relying on it, so a "dh_systemd_start foo.socket" sounds prudent?
[08:21] <mwhudson> pitti: how do dh_installinit and dh_systemd_* interact?
[08:21]  * mwhudson hopes s_langasek is asleep before asking that question
[08:21] <pitti> mwhudson: the latter basically handles everything that is not a .service; like sockets, timers, targets, etc.
[08:22] <pitti> mwhudson: and yes, having two different things is a mess :)
[08:22]  * mwhudson tries to figure out where docker.socket even comes from
[08:22] <pitti> mwhudson: you can of course also just use dh_installinit and start the .service directly
[08:22] <pitti> doesn't matter much then if the .socket isn't running
[08:23] <pitti> (but that's not really the point of setting up socket activation)
[08:24] <mwhudson> that's what the current docker package in xenial-updates does (although, again, i don't quite understand what the package is doing to achieve this...)
[08:24] <mwhudson> oh, upstream
=== hikiko|bbiab is now known as hikiko
[08:25] <alkisg> To make my own repository packages display in gnome-software, do I need to add appstream metadata to it? I'm currently using reprepro, are there any tools that can help me with that?
[08:26] <alkisg> And, do PPAs already handle this?
[08:26] <mwhudson> (the socket, not the starting the service on install)
[08:39] <mwhudson> hmm
[08:40] <mwhudson> pitti: is it fair to say that if you override dh_installinit, you're going to want to override dh_systemd_enable too?
[08:40] <pitti> mwhudson: not really, no; it really depends on what kind of units you ship
[08:40] <pitti> if you only ship a SysV init plus .service pair, dh_installinit is enouguh
[08:40] <pitti> (you don't even need dh_systemd_*)
[08:41] <pitti> but if you only ship systemd units and you need a .socket, then you don't need dh_installinit
[08:41] <mwhudson> the dh_installinit override is to set --name
[08:42]  * mwhudson is having a 'surprised this ever worked' moment
[08:42] <pitti> mwhudson: oh, do you ship a debian/foo.socket?
[08:42] <mwhudson> pitti: yes
[08:42] <mwhudson> uh
[08:42] <mwhudson> no
[08:42] <mwhudson> sorry
[08:43] <mwhudson> docker.io.install installs a docker.socket file from the upstream source
[08:43] <pitti> also, no, debian/*.socket has been handled since 2013 already
[08:43] <mwhudson> the packaging change that must be at fault here
[08:44] <pitti> i-s-h added handling for debian/*.path not too long ago
[08:44] <mwhudson> is that docker 1.11 used the .install file to install the .service file
[08:44] <mwhudson> but 1.12 does this:
[08:44] <mwhudson> (xenial *)mwhudson@aeglos:/opt/opensource/deb/docker/debian-docker$ ls -l debian/*.service
[08:44] <mwhudson> lrwxrwxrwx 1 mwhudson mwhudson 38 Sep  7 14:40 debian/docker.io.docker.service -> ../contrib/init/systemd/docker.service
[09:49] <mardy> seb128: hi! Is bug 1587282 fine, or do I need to do something else to push it forward?
[09:49] <ubottu> bug 1587282 in account-plugins (Ubuntu) "create online-account plugin for cmcc mcloud" [Undecided,Triaged] https://launchpad.net/bugs/1587282
[10:18] <doko> Mirv: could you have a look at https://bugs.launchpad.net/ubuntu/+source/qtchooser/+bug/1626469 ? or tell me who should?
[10:18] <ubottu> Launchpad bug 1626469 in qtchooser (Ubuntu) "qdoc doesn't work, causes other packages fail to build" [High,Confirmed]
[10:19] <pitti> doko, barry: filed debian bug 838559 and force-badtested python-pex, FYI; so setuptools should land now (after beta freeze)
[10:19] <ubottu> Debian bug 838559 in python-pex "python-pex: tests started to fail on "Connection refused"" [Normal,Open] http://bugs.debian.org/838559
[10:32] <Mirv> doko: outdated build dependencies in those packages, mostly packages that haven't seen recent maintenance since many were updated. updated the bug report.
[10:41] <doko> Mirv: ta
[10:51] <directhex> i can't debootstrap precise today :/
[10:52] <xnox> pitti, will there be a matching release of util-linux for the v4.8 kernel? and will we get it? there is new things exposed in proc on s390x for lscpu to parse.
[10:53] <xnox> and i'm pondering if it's worth cherrypicking 9 commits into yakkety, wait for new util-linux release, or just forget about it until z-series
[10:53] <xnox> directhex, from yakkety host?
[10:53] <directhex> xnox: good guess
[10:54] <pitti> xnox: we have the latest upstream release (2.28.2); not sure if kzak wants to do another one soon
[10:54] <pitti> xnox: so if you want it in y, backporting it is
[10:54] <xnox> directhex, is http://launchpadlibrarian.net/285357737/ubuntu-keyring_2016.09.01_2016.09.19.diff.gz at fault?
[10:54] <xnox> pitti, well 2.28.2 is point release from the v2.28 branch. I want june cherrypicks from master =/
[10:55] <xnox> directhex, does $ sudo rm -f /etc/apt/trusted.gpg.d/ubuntu-keyring-*.gpg; sudo apt-key update
[10:55] <xnox> get you back into a state that allows you to bootstrap precise?
[10:55] <directhex> xnox: it complains about downloading linux-libc-dev, let me just crank up verbosity
[10:55] <xnox> ah
[10:55] <directhex> and maybe try another mirror
[10:56] <xnox> if it's downloading things, everything is ok w.r.t. keyring =)
[11:01] <xnox> pitti, cherrypicks don't look too bad http://paste.ubuntu.com/23215380/
[11:01] <pitti> xnox: ok; but please always put cherry-picks at the top of the series
[11:01] <xnox> oh, ok.
[11:02] <pitti> avoids adjusting upstream patches to downstream ones, it should be the other way aroudn (less noise and easier to upgrade to the next version)
=== marcustomlinson is now known as marcustomlinson|
=== marcustomlinson| is now known as marcustomlinson
[11:17] <seb128> mardy, looks fine so you can land the silo now
[11:25] <mardy> Mirv: ^
[11:30] <Mirv> mardy: ok!
[11:33] <caribou> Has someone found a fix for LP: #1621269 or moving /var/lib/sbuild/apt-keys out of the way a valid workaround ?
[11:33] <ubottu> Launchpad bug 1621269 in sbuild (Ubuntu Xenial) "not possible to build yakkety packages because of gpg changes" [High,Triaged] https://launchpad.net/bugs/1621269
=== grumble is now known as rumble
=== zigo is now known as Guest83601
[12:03] <doko> seb128: one more thing, could you check if the packages still build, see http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html. if it's not yet built, please ping me so that I can raise the priority
[12:03] <seb128> doko, ok, sure
[12:43] <mardy> Mirv: is https://bileto.ubuntu.com/#/ticket/1497 going to land now, or does it need some more acks?
=== hikiko is now known as hikiko|lm
=== hikiko|lm is now known as hikiko|ln
[12:53] <acheronuk> hi. how often does this update please? http://qa.ubuntuwire.org/ftbfs/
=== rumble is now known as grumble
=== _salem is now known as salem_
[13:22] <Mirv> mardy: it "is" landed but we have some trouble that yakkety stuff goes to /dev/null, instead of the UNAPPROVED queue it should be going to
[13:22] <Mirv> mardy: so therefore it's landed for vivid and xenial but not to yakkety even though publish action was done
[13:32] <xnox> caribou, i just had missing crc32c module on s390x in the d-i udeba
[13:32] <xnox> caribou, somehow, it is needed to e.g. mount ext4 filesystems.
[13:32] <xnox> caribou, given the bug on ppc64el side, i guess it affects s390x too?
[13:33] <caribou> xnox: could be, I don't have the crc32 issue on amd64; but the makedumpfile issue remains
[13:33] <caribou> xnox: do you have an LP number for this one ?
[13:35] <xnox> caribou, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1625728
[13:35] <ubottu> Launchpad bug 1625728 in linux (Ubuntu Yakkety) "fails to mount ext4 due to missing crypto-crc32 modules in the udeb" [Critical,Fix released]
[13:35] <caribou> xnox: thanks!
=== hikiko|ln is now known as hikiko
[13:40] <barry> pitti: thanks.  i did look at this briefly yesterday and it was passing locally for me, but it seems like you can reproduce it, so i'll look in more detail
[13:41] <caribou> xnox: is the fix for that bug generic to all architectures, or only for s390x ?
[13:41] <pitti> barry: wow; it fails in Debian CI, in Ubuntu CI, locally  with qemu, lxd, schroot -- what  kind of black magic did you do? :-)
[13:41] <pitti> barry: (note that just exercise.sh fails, the other three tests are fine)
[13:42] <barry> pitti: yep.  and yeah, i don't know.  "lucky" i guess
[13:49] <pitti> apw, cyphermox: do you know how I can debug bug 1626568? i. e. missing kernel symbols on insmod?
[13:49] <ubottu> bug 1626568 in network-manager (Ubuntu) "rfkill autopkgtests broken with linux 4.8: fake-rfkill.ko: Unknown symbol in module" [Undecided,New] https://launchpad.net/bugs/1626568
[13:50] <apw> pitti, is that making up its own out-of-tree module ?  or using something we are supplying
[13:50] <pitti> apw: nope, it's https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/tree/debian/tests/fake-rfkill.c
[13:50] <pitti> apw: just a fake module to test NM's rfkill handling, for nonexisting hardware
[13:51] <pitti> ooh! typical again -- "sudo modprobe rfkill" does it
[13:51] <pitti> typical: find the solution *after* asking on IRC
[13:51] <apw> pitti, right so an oot module being compiled against the kernel headers ?
[13:51] <pitti> apw: correct
[13:51] <apw> pitti, so likely a straight porting issue
[13:51] <pitti> so far that test has worked without the modprobe; so maybe rfkill went from "builtin" to "module", or fake-rfkill.c fails to declare a dependency?
[13:51] <apw> pitti, as in those changed named in the kernel
[13:52] <apw> or they are not exported or something
[13:52] <pitti> apw: nope, modprobe rfkill -> then that insmod works fine
[13:52] <pitti> now, is insmod supposed to load module dependencies? i. e. is that a problem of using insmod, or a bug in fake-rfkill.c by not declaring its dependencies?
[13:53] <apw> nope, that is a moprobe thing, and you would need to install it in the right place and depmod to sort that i think
[13:53] <pitti> apw: so somehow rfkill was already loaded with <= 4.4,  or builtin, I  suppose
[13:53] <pitti> $ modinfo debian/tests/fake-rfkill.ko
[13:53] <pitti> depends:        rfkill
[13:54] <pitti> ok, so just b/c using insmod instead of modprobe
[13:54] <apw> pitti, may have been builtin indeed
[13:54] <apw> if we can switch you to modprobe and win, life would be good
[13:54] <pitti> apw: oh, absolutely; this is *not* a kernel bug, just me being a kernel n00b :)
[13:54] <apw> or at least use modinfo and rip the depends: out and manually insmod them
[13:54] <pitti> just trying to re-fix that test
[13:55] <apw> pitti, i've marked it up as related to kernel-4.8 regardless, as it is work and fallout from this
[13:55] <pitti> apw: one can call modprobe with a file these days, that ought to load it (testing now)
[13:56] <pitti> apw: thanks, I have a handle on this now
[13:56] <pitti> sorry for the noise
[13:56] <pitti> but it would probably have taken me ages without embarrassing myself on IRC :)
[13:57] <pitti> ah no, no modprobe on a path
[13:57] <apw> pitti, hey ... this is why we have these things ... to get things sorted without people wasting their lives refinding the world
[13:57] <apw> damit
[13:57] <apw> you could drop the .ko into /updates the dkms place
[13:58] <apw> and dep mod, or use the modinfo output
[13:58] <apw> modinfo rfkill.ko | awk '/^depends:/ { print $2 }'
[13:58] <pitti> $ sudo modprobe `modinfo debian/tests/fake-rfkill.ko | sed -n '/depends:/ {s/^.*://; p}'`
[13:58] <apw> or something
[13:58] <pitti> apw: ^ poor man's modprobe-on-a-file :)
[13:58] <apw> yeah, la la la, but yes
[13:59] <apw> rmemeber to modprobe fake-rfkill.ko as well
[13:59] <pitti> (insmod)
[13:59] <apw> that
[14:01] <pitti> killswitches-no-urfkill PASS
[14:01] <pitti> take THAT
[14:03] <davmor2> pitti: oh please don't inflict their music on us
[14:04] <pitti> davmor2: I have two sisters; guess what always came through TWO walls when we've been teenagers :)
[14:06] <davmor2> pitti: Bros
[14:06] <apw> pitti, you wern't the brother sandwich were you ... i feel for you
[14:07] <davmor2> no no wait I got it nirvana
[14:07] <pitti> apw: no, youngest
[14:07] <pitti> apw: anyway, tests are happy again, pushed the fix
[14:08] <apw> pitti, yay ... thanks
[14:08] <pitti> and it seems two out of three clouds behave again as well *phew*
[14:08] <pitti> hatethisdayhatethisday
[14:08] <pitti> but it's not like we have a beta anytime soon, so 'sallgood
[14:09] <apw> pitti, no rush :/
[14:10] <davmor2> pitti: boyzone, new kidz on the block, take that and westlife and Rick Astley as you got rickrolled ;) just count yourself lucky if it was nowadays it would all be beiber
[14:49] <slangasek> mwhudson: better not to hope such things out loud if what you want is me to not notice the question ;)
[15:00] <barry> pitti: this pex thing is really hurting my brain.  first it fails locally, then it doesn't and once it stops failing locally i can't reproduce it again (locally).
[15:01] <pitti> barry: hm, so what is it actually trying to do when connecting to the network?
[15:01] <pitti> barry: am I right that these proxy vars are meant to intercept/forbid exaclty that?
[15:03] <barry> pitti: yes exactly.  it *shouldn't* try to hit the net for any modules it can resolve locally, and that's exactly why it uses textwrap (a stdlib module).  what i think is happening when it fails is that it wants the requests library.  so i add that to Depends and then it stops failing.  problem solved, right?  no, if i then *remove* that dep, it continues to not fail, even though i'm building all this in clean sid chroots each time
[15:09] <bdmurray> mvo: Could you have a look at bug 1602536? I think its just unlucky timing.
[15:09] <ubottu> bug 1602536 in unattended-upgrades (Ubuntu) "/usr/bin/unattended-upgrade:apt.cache.LockFailedException:/usr/bin/unattended-upgrade@1468:main:do_auto_remove:cache_commit:commit:_fetch_archives" [High,Confirmed] https://launchpad.net/bugs/1602536
[15:11] <mvo> bdmurray: yes, I think that is it
[15:12] <bdmurray> mvo: we could just stop the crash from getting to LP then, sound reasonable?
[15:13] <mvo> bdmurray: yeah, I think ideally it just should retry
[15:13] <mvo> bdmurray: instead of crashing
[15:13] <bdmurray> mvo: Ah, you mean retry before the next cron run?
[15:14] <mvo> bdmurray: yeah, just a small 30sec wait and then retry to acquire the lock
=== zigo_ is now known as zigo
[15:15] <bdmurray> mvo: Do you have time to do that?
[15:16] <mvo> bdmurray: its a bit tricky, I can try to squeeze some time in tomorrow moring for u-u, looks like there are two issues worth fixing
[15:18] <barry> pitti: i think i figured it out
[15:19] <seb128> Mirv, mardy, chrisccoulson, k, so on current daily when trying to add a google account from ucc->uoa the view doesn't empty anymore when scrolling but it does when trying to click on the text entry, not much better since you still can't enter your login info :-/
=== quadrispro_ is now known as quadrispro
[15:25] <pitti> cyphermox: ubuntu-drivers has no PK/dbus service etc. at all -- it basically just figures out what to install with some poking in /sys and calls apt-get install
[15:25] <pitti> cyphermox: so that shoudl already be called by a root process
[15:26] <cyphermox> well, I don't know how it's called, but if it's started by ubiquity directly, it's probably not run as root
[15:26] <cyphermox> unless there is some other priv escalation steps taken beforehand
[15:28] <cyphermox> oh, maybe it is done as root after all
[15:28] <pitti> cyphermox: why would ubiquity not run as root?
[15:28] <cyphermox> still, there's definitely another issue with the permissions given the crash I see in trying to drive NM
[15:31] <pitti> davmor2: do you still have the syslog for bug 1626108?
[15:31] <ubottu> bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New] https://launchpad.net/bugs/1626108
[15:31] <davmor2> pitti: no but I can get you one in about 10 minutes
[15:32] <davmor2> pitti: do you want syslog from broken live session, syslog from an installed system, or syslog from the installer on the installed system?
[15:33] <pitti> davmor2: broken live session should suffice already
[15:33] <davmor2> pitti: no worries give me 5 then
[15:37] <nacc> slangasek: is there a update-maintainer equivalent that would update the VCS-* field to XS-Debian-Vcs-? Would it be worth adding a tool to ubuntu-dev-tools to do that?
[15:38] <pitti> xnox, barry: FYI: https://ci.debian.net/data/britney/failing.txt
[15:38] <davmor2> pitti: added to the bug
[15:39] <davmor2> that is taken on the slide right after the 3rd party drivers are normally installed
[15:40] <slangasek> nacc: not that I know of
[15:41] <davmor2> pitti: I've left the system in that state incase you need anything else
[15:41] <rtg> pitti, regarding bug #1626394, is it sufficient to set CONFIG_ATA=y for amd64 ? Setting that also pulls in the SCSI stack. Is it _really_ required for a systemd test ?
[15:41] <ubottu> bug 1626394 in linux (Ubuntu) "4.8 dropped CONFIG_ATA=y (breaks systemd's TEST-08-ISSUE-2730 upstream test)" [Critical,Confirmed] https://launchpad.net/bugs/1626394
[15:42] <pitti> davmor2: cheers!
[15:42] <nacc> slangasek: ok, i'll see if it's something easy to add, it is a useful tool for our merge process (we already recommend update-maintainer for that part)
[15:42] <nacc> rbasak: --^
[15:42] <pitti> davmor2, cyphermox, slangasek: followed up to bug 1626108; this does not appear to be polkit related at all, we just lost the driver in the image's /pool apparently?
[15:42] <ubottu> bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New] https://launchpad.net/bugs/1626108
[15:42] <slangasek> nacc: might be a thing to add to update-maintainer itself, possibly as an optional flag?
[15:43] <nacc> slangasek: that's what i was thinking, yeah
[15:43] <rbasak> Agreed
[15:43] <rbasak> update-maintainer would become a misnomer then though.
[15:43] <slangasek> <shrug> :)
[15:43] <nacc> yeah, i wasn't sure if we'd need to rename/alias then to make it clear
[15:43] <nacc> hence, i'll try, and we'll use a MR as the point of discussion :)
[15:44] <cyphermox> pitti: huh?
[15:44] <cyphermox> pitti: /pool/restricted/i/intel-microcode/intel-microcode_3.20160714.1_amd64.deb
[15:44] <pitti> cyphermox: no, not lost
[15:44] <pitti> looked at .manifest, not .list
[15:44] <pitti> it's a version mismatch
[15:44] <cyphermox> ah, that could explain it yeah
[15:44] <cyphermox> but then today we should see if work
[15:44] <cyphermox> *it
[15:45] <pitti> cyphermox: followed up again
[15:45] <slangasek> "version mismatch"?
[15:45] <pitti> it's a version mismatch
[15:45] <pitti> slangasek, cyphermox: didn't we use to have this before? mirror on cdimage being out of date or something?
[15:46] <cyphermox> yeah, that's why I said we should see it working correctly in today's image
[15:46] <slangasek> pitti: yesterday was spent dealing with ftp mirror problems
[15:46] <slangasek> so that should be fixed now
[15:46] <pitti> ah, so the next respin should magically fix this
[15:46] <slangasek> and it's possible that this particular image was bad because I manually ran the ftp sync while builds were running
[15:47] <pitti> so, OOI, what made this look like a polkit problem?
[15:47] <cyphermox> pitti: ubiquity crashes when you try to setup wifi
[15:47] <davmor2> pitti: \o/ that would be nice
[15:48] <cyphermox> Not authorized to control networking.
[15:48] <cyphermox> (which is very wrong, because you clearly should be, and my cursory glance at the pkla files shows it should work)
[15:48] <pitti> cyphermox: so, so that's not bug 1626108 then, but something else?
[15:48] <ubottu> bug 1626108 in Ubuntu CD Images "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,In progress] https://launchpad.net/bugs/1626108
[15:48] <cyphermox> pitti: something else I noticed while testing this driver issue, I supposed it could be related
[15:49] <cyphermox> OOI, what versions do you say mismatch?
[15:49] <cyphermox> afaict the intel-microcode and bcmwl-kernel-source versions in pool/ on the CD yesterday are the right ones.
[15:49] <slangasek> cyphermox: there was a newer dkms package in the archive than in the pool
[15:49] <cyphermox> ah!
[15:49] <slangasek> cyphermox: and the image knew this and went looking
[15:49] <pitti> cyphermox: yes indeed, it also needs to work on the desktop (and if it wouldn't, I expect we'd get a lot more outcry
[15:49] <pitti> ... or not, because people can't get on the net to yell at us :)
[15:50] <cyphermox> pitti: NM works
[15:50] <cyphermox> pitti: you can drive NM from nm-applet, it just explodes when driven from the installer.
[15:50] <pitti> cyphermox: right, but nm-applet uses the same d-bus interfaces and thus PK privs
[15:50] <cyphermox> so does the ubiquity panel, afaik
[15:51] <cyphermox> everything uses the same magic.
[15:51] <pitti> so that's ubiquity-only, not ubiquity in the live-session?
[15:51] <cyphermox> ubiquity in the live session is where I noticed this
[15:52] <davmor2> cyphermox, pitti: is this the magic https://www.youtube.com/watch?v=ViftZTfRSt8 ?
[15:54] <barry> pitti: uploaded to unstable.  i'll syncpackage it over once it's imported by lp
[15:55] <pitti> barry: ♥
=== zigo is now known as Guest18656
[17:20] <bdmurray> coreycb: Could you add some more SRU information to bug 1623107?
[17:20] <ubottu> bug 1623107 in python-pylxd (Ubuntu Xenial) "[SRU] python-pylxd 2.0.5" [Undecided,New] https://launchpad.net/bugs/1623107
[17:20] <coreycb> bdmurray, sure thing
=== zigo_ is now known as zigo
=== doomwake is now known as 7JTABTGBN
=== salem_ is now known as _salem
[22:54] <nacc> doko: re: ftfbfs for gsfonts, looks to be fixed in 1:8.11+urwcyr1.0.7~pre44-4.3 current in unstable. Do you want me to submit a fresh merge or (as there are unrelated to the ftfbs issue changes) just backport the one fix to the Y level?
[22:55] <nacc> doko: actually, it looks it can be sync'd in yakkety, if i'm reading the .3 changelog right
[22:56] <nacc> yeah, debian took the ubuntu dela
[22:56] <nacc> *delta
[22:57] <Unit193> Nice.
[23:06] <nacc> doko: and filed LP: #1626776, i have the fix in hand, just testing it now
[23:07] <ubottu> Launchpad bug 1626776 in nagios3 (Ubuntu) "nagios3: add build-arch and build-indep targets [ftbfs]" [Undecided,New] https://launchpad.net/bugs/1626776
[23:33] <tsimonq2> so how can I emulate armhf for example to solve build errors?
[23:33] <tsimonq2> do I need an armhf machine?
[23:35] <nacc> tsimonq2: i think sbuild can crossbuild?
[23:35] <tsimonq2> really? how?
[23:35] <nacc> tsimonq2: with some combination of --build and --host, maybe
[23:35] <nacc> and an appropriate schroot already made
[23:35] <nacc> it seems like there is, e.g. crossbuild-essential-armhf
[23:35] <tsimonq2> nacc: have you tried this before?
[23:36] <nacc> i think i have with a different arch, but i'd have to go look
[23:36] <tsimonq2> last time I tried sbuild with armhf it didn't work :/
[23:36] <tsimonq2> ok
[23:36] <nacc> yeah, i think armhf may also be special, unfortunately, i can't recall
[23:39] <nacc> Unit193: do you know if it's appropriate for me to `requestync` gsfonts? or should I wait for doko to handle it?
[23:49] <nacc> doko: ok, so pacemaker's failure is odd, as the chown in question is '-chown' in the makefile