| * mwhudson looks sceptically at dh_systemd_enable | 00:58 | |
| 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:22 |
| mwhudson | oh wait docker is in NEW on amd64 | 01:23 |
| seamlik | cjwatson: Thanks for dealing with Gradle's FTBFS! :) | 02:02 |
| 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... | 02:41 |
| === JanC is now known as Guest5754 | ||
| === JanC_ is now known as JanC | ||
| 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:23 |
| pitti | infinity: oh nice, glibc is green again (after the hostname.. fix) | 05:39 |
| doko | wgrant: thanks! results were better in the past, still a lot to fix :-/ | 06:08 |
| 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:12 |
| pitti | meh, brightness change is broken as well | 06:13 |
| * pitti will file bugs in a bit | 06:13 | |
| doko | pitti: brightness change works here, but it's a lot delayed after typing (x250) | 06:15 |
| doko | 87 ftbfs in main alone, and armhf and arm64 not yet tested. http://ubuntuqa.tblwd.org/ftbfs/test-rebuild-20160916-yakkety.html | 06:18 |
| sarnold | pitti: nacc reported insane load averages with sbuild | 06:21 |
| 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:27 |
| pitti | load average: 249,08, 79,27, 34,43 | 06:28 |
| pitti | holy crap | 06:28 |
| 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:29 |
| 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:30 | |
| 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:31 |
| sarnold | wow :) | 06:33 |
| 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:35 |
| sarnold | and you said it was slow.. :) | 06:36 |
| pitti | heh | 06:36 |
| pitti | also, *very* efficient RAM compression! | 06:36 |
| sarnold | :D | 06:36 |
| 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:50 |
| pitti | nothing noticeable | 06:51 |
| pitti | it's booting that sucks, so maybe setting up cgroups or non-compiler parallelism, not sure | 06:51 |
| pitti | sarnold: actually, it's 6'30'' (4.4) vs. 7'30'' (4.8), I just can't do math this morning yet | 06:53 |
| StevenK | The coffee drip isn't attached yet? | 06:55 |
| === hikiko is now known as hikiko|bbiab | ||
| pitti | StevenK: yeah, no tea IV :) | 07:33 |
| doko | apw: libecap breaks with new kernel headers | 08:05 |
| apw | bah | 08:05 |
| apw | doko, where can i see that | 08:08 |
| mwhudson | pitti: hey | 08:08 |
| 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:09 |
| 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:10 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| pitti | mwhudson: (just a wild guess, I'm not aware of that and it shouldn't actually be that way) | 08:19 |
| pitti | mwhudson: and I'd also avoid relying on it, so a "dh_systemd_start foo.socket" sounds prudent? | 08:20 |
| 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:21 |
| 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:22 |
| pitti | (but that's not really the point of setting up socket activation) | 08:23 |
| 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 | 08:24 |
| === hikiko|bbiab is now known as hikiko | ||
| 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:25 |
| alkisg | And, do PPAs already handle this? | 08:26 |
| mwhudson | (the socket, not the starting the service on install) | 08:26 |
| mwhudson | hmm | 08:39 |
| 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:40 |
| 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:41 |
| * 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:42 |
| 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:43 |
| 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 | 08:44 |
| 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 | 09:49 |
| 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:18 |
| 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:19 |
| 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:32 |
| doko | Mirv: ta | 10:41 |
| directhex | i can't debootstrap precise today :/ | 10:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| xnox | if it's downloading things, everything is ok w.r.t. keyring =) | 10:56 |
| 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:01 |
| 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) | 11:02 |
| === marcustomlinson is now known as marcustomlinson| | ||
| === marcustomlinson| is now known as marcustomlinson | ||
| seb128 | mardy, looks fine so you can land the silo now | 11:17 |
| mardy | Mirv: ^ | 11:25 |
| Mirv | mardy: ok! | 11:30 |
| 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 | 11:33 |
| === grumble is now known as rumble | ||
| === zigo is now known as Guest83601 | ||
| 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:03 |
| mardy | Mirv: is https://bileto.ubuntu.com/#/ticket/1497 going to land now, or does it need some more acks? | 12:43 |
| === hikiko is now known as hikiko|lm | ||
| === hikiko|lm is now known as hikiko|ln | ||
| acheronuk | hi. how often does this update please? http://qa.ubuntuwire.org/ftbfs/ | 12:53 |
| === rumble is now known as grumble | ||
| === _salem is now known as salem_ | ||
| 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:22 |
| 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:32 |
| 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:33 |
| 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! | 13:35 |
| === hikiko|ln is now known as hikiko | ||
| 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:40 |
| 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:41 |
| barry | pitti: yep. and yeah, i don't know. "lucky" i guess | 13:42 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| apw | rmemeber to modprobe fake-rfkill.ko as well | 13:59 |
| pitti | (insmod) | 13:59 |
| apw | that | 13:59 |
| pitti | killswitches-no-urfkill PASS | 14:01 |
| pitti | take THAT | 14:01 |
| davmor2 | pitti: oh please don't inflict their music on us | 14:03 |
| pitti | davmor2: I have two sisters; guess what always came through TWO walls when we've been teenagers :) | 14:04 |
| davmor2 | pitti: Bros | 14:06 |
| apw | pitti, you wern't the brother sandwich were you ... i feel for you | 14:06 |
| 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:07 |
| 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:08 |
| apw | pitti, no rush :/ | 14:09 |
| 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:10 |
| slangasek | mwhudson: better not to hope such things out loud if what you want is me to not notice the question ;) | 14:49 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:09 |
| mvo | bdmurray: yes, I think that is it | 15:11 |
| bdmurray | mvo: we could just stop the crash from getting to LP then, sound reasonable? | 15:12 |
| 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:13 |
| mvo | bdmurray: yeah, just a small 30sec wait and then retry to acquire the lock | 15:14 |
| === zigo_ is now known as zigo | ||
| bdmurray | mvo: Do you have time to do that? | 15:15 |
| 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:16 |
| barry | pitti: i think i figured it out | 15:18 |
| 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 :-/ | 15:19 |
| === quadrispro_ is now known as quadrispro | ||
| 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:25 |
| 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:26 |
| 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:28 |
| 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:31 |
| 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:32 |
| pitti | davmor2: broken live session should suffice already | 15:33 |
| davmor2 | pitti: no worries give me 5 then | 15:33 |
| 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:37 |
| pitti | xnox, barry: FYI: https://ci.debian.net/data/britney/failing.txt | 15:38 |
| davmor2 | pitti: added to the bug | 15:38 |
| davmor2 | that is taken on the slide right after the 3rd party drivers are normally installed | 15:39 |
| slangasek | nacc: not that I know of | 15:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| davmor2 | cyphermox, pitti: is this the magic https://www.youtube.com/watch?v=ViftZTfRSt8 ? | 15:52 |
| barry | pitti: uploaded to unstable. i'll syncpackage it over once it's imported by lp | 15:54 |
| pitti | barry: ♥ | 15:55 |
| === zigo is now known as Guest18656 | ||
| 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 | 17:20 |
| === zigo_ is now known as zigo | ||
| === doomwake is now known as 7JTABTGBN | ||
| === salem_ is now known as _salem | ||
| 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:54 |
| nacc | doko: actually, it looks it can be sync'd in yakkety, if i'm reading the .3 changelog right | 22:55 |
| nacc | yeah, debian took the ubuntu dela | 22:56 |
| nacc | *delta | 22:56 |
| Unit193 | Nice. | 22:57 |
| nacc | doko: and filed LP: #1626776, i have the fix in hand, just testing it now | 23:06 |
| ubottu | Launchpad bug 1626776 in nagios3 (Ubuntu) "nagios3: add build-arch and build-indep targets [ftbfs]" [Undecided,New] https://launchpad.net/bugs/1626776 | 23:07 |
| tsimonq2 | so how can I emulate armhf for example to solve build errors? | 23:33 |
| tsimonq2 | do I need an armhf machine? | 23:33 |
| 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:35 |
| 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:36 |
| nacc | Unit193: do you know if it's appropriate for me to `requestync` gsfonts? or should I wait for doko to handle it? | 23:39 |
| nacc | doko: ok, so pacemaker's failure is odd, as the chown in question is '-chown' in the makefile | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!