smoser | pitti, around ? | 03:14 |
---|---|---|
smoser | i think i relize the issue with letting the udevrule go through. | 03:15 |
smoser | cloud-init wont have written the .link file to rename at the point when the udev rule processes the .link | 03:15 |
smoser | so cloud-init local *will* have to re-trigger or otherwise have the systemd.link stuff fire again | 03:16 |
smoser | how were you re-triggering with udev to get the .links processed ? | 03:19 |
cyphermox | cjwatson: yes, will SRU. thanks. I was looking hard at base-installer, not at apt-setup :/ | 03:23 |
cyphermox | or at least, not at that part of base-installer that has apt-setup keys. | 03:23 |
cyphermox | between us we might manage to really fix the overlay code. | 03:23 |
smoser | pitti, 'udevadm test-builtin net_setup_link /sys/class/net/ens4' works to show that the cloud-init written .link files do the right thing. | 03:35 |
smoser | but i think i have to re-send the hotplug event to get it renamed. | 03:35 |
=== hikiko is now known as hikiko|off | ||
=== athairus is now known as afkthairus | ||
CarlFK | https://help.ubuntu.com/lts/installation-guide/armhf/apbs04.html#preseed-apt how do I get it to not #comment out deb-src lines? (new in xenial) | 07:08 |
zyga | good morning | 07:25 |
tjaalton | wgrant: still around? I sent a soyuz question (#293230) about bumping the size of ppa:canonical-x/x-staging, llvm is taking all the space preparing next lts stack :) | 08:14 |
wgrant | how on earth | 08:15 |
wgrant | It's already 8GiB! | 08:15 |
* wgrant doubles | 08:15 | |
tjaalton | llvm is big | 08:15 |
tjaalton | thanks! | 08:15 |
mwhudson | is there a script for doing the Maintainers: Ubuntu Developers, XSBC-Original-Maintainers: thing? | 08:24 |
Laney | mwhudson: updata-maintainer | 08:24 |
Laney | with spelling that is good | 08:24 |
mwhudson | Laney: thanks | 08:26 |
mwhudson | oh wow, python, i was expecting perl :-) | 08:27 |
Laney | it was probably written this decade :P | 08:27 |
=== davmor2_ is now known as davmor2 | ||
zyga | hey mwhudson | 08:45 |
cjwatson | CarlFK: d-i apt-setup/enable-source-repositories boolean true | 09:03 |
=== marcusto_ is now known as marcustomlinson | ||
sil2100 | mvo: hey! Is it ok for me to release the currently staged changes in livecd-rootfs to yakkety? | 10:51 |
sil2100 | mvo: I have some of my changes that we'd need released to unblock image builds | 10:51 |
=== xavigarcia is now known as xavigarcia_lunch | ||
mvo | sil2100: yeah, thats fine | 10:59 |
mvo | sil2100: ogra_ also has some pending changes | 11:00 |
sil2100 | Thanks! | 11:00 |
ogra_ | mvo, oh, didnt you say you pushed them to trunk ? | 11:00 |
sil2100 | They're pushed to trunk but not released yet | 11:00 |
sil2100 | I'm releasing trunk right now if that's ok | 11:00 |
ogra_ | bah, i just upgraded my phone to tonights rc-proposed image ... no apps in the apps scope ... no matter how often i refresh | 11:01 |
ogra_ | ok, seems ten times is the charm ... | 11:01 |
=== xavigarcia_lunch is now known as xavigarcia | ||
yofel | doko: did you intentionally drop the multiarch changes from libical? | 12:09 |
doko | yofel, no, saw too late that they were only applied in experimental | 12:11 |
doko | but I didn't check if we can sync the experimental package | 12:11 |
doko | so maybe I better restore these | 12:11 |
yofel | would be nice, it's causing build failures in some kde autopktests as cmake hardcodes the lib path in some places | 12:12 |
doko | ahh, I remember | 12:15 |
doko | breakfast first | 12:16 |
yofel | doko: and thanks for merging digikam | 12:17 |
alexbligh1 | Is this the sort of thing you'd take a 14.04 SRU for (assuming my one character patch to fix it is OK): https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1578185 | 12:22 |
ubottu | Launchpad bug 1578185 in nbd (Ubuntu) "nbd-client 3.7 connects read-only to newer nbd servers" [Undecided,New] | 12:22 |
smoser | alexbligh1, if if it doesn't break working with older nbd servers' it would surely seem appropriate for sru from what that bug says. | 12:23 |
alexbligh1 | smoser, nope, it doesn't break anything. OK, I will persuade Wouter (Debian maintainer and nbd maintainer) my one line patch is a good plan :-) | 12:24 |
alexbligh1 | smoser, thx | 12:24 |
shadeslayer | chrisccoulson: hi, I was wondering if you had a moment to talk about firefox? I seem to be hitting a race condition when the configure step is a bit too slow | 12:39 |
shadeslayer | for eg. on armhf | 12:39 |
rbasak | alexbligh1: thank you for looking after this. Let me know if you need any help with sponsorship etc. | 12:40 |
shadeslayer | chrisccoulson: I was wondering if you had seen something similar? | 12:40 |
alexbligh1 | rbasak, thx - if you could tell me how to mark it as 14.04 only that would be great. | 12:40 |
rbasak | alexbligh1: is it Fix Released in Yakkety then? I can add the Trusty task for you. AIUI, that was ACL-restricted to uploaders and triagers only because people kept misunderstanding the purpose or something. | 12:42 |
rbasak | alexbligh1: done | 12:42 |
alexbligh1 | rbasak, yes it was fixed in wily when 3.10 was imported. Thanks. | 12:43 |
=== _salem is now known as salem_ | ||
roadmr | hey folks! so on xenial I get an "updates available" bubble but it's not actionable. Clicking on it does nothing, nor does the dancing update manager appar in the unity dash. I had to hunt it down manually. Is this a bug? | 13:12 |
sergiusens | cjwatson pitti hello again, is the fact that I need to do this https://github.com/ubuntu-core/snapcraft/pull/499/files for yakkety a bug in snapcraft that went unnoticed (worked all through xenial) or the new apt/python-apt in yakkety? | 13:22 |
cjwatson | sergiusens: Don't know, I'm afraid | 13:40 |
ginggs | pitti: hi, can something be done about compute's ppc64el test failure blocking nvidia-cuda-toolkit please? From what I can see, nvidia-cuda-toolkit provides an alternate build-depends which isn't even being tested. The failures have been since the switch to boost1.60. | 14:03 |
coreycb | bdmurray, arges: Hi, any chacne we could get a review for the liberty point release in bug 1569502 ? | 14:14 |
ubottu | bug 1569502 in nova (Ubuntu Wily) "[SRU] liberty point releases" [Undecided,Confirmed] https://launchpad.net/bugs/1569502 | 14:14 |
pitti | ginggs: I added a compute/ppc64el ignore hint | 14:18 |
ginggs | pitti: danke! | 14:19 |
rbasak | "dpkg: dependency problems prevent processing triggers for ufw" | 14:32 |
rbasak | Is this an apt bug? I don't see an obvious packaging deficiency or opportunity for there to be a dependency loop. | 14:32 |
rbasak | http://paste.ubuntu.com/16218132/ is my reproduction of bug 1571174 | 14:33 |
ubottu | bug 1571174 in squid3 (Ubuntu) "package squid3 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [High,Confirmed] https://launchpad.net/bugs/1571174 | 14:33 |
rbasak | It seems to me that apt should have chosen to configure python3 first. | 14:35 |
arges | coreycb: i got it | 15:24 |
pitti | rcj: cat /sys/class/tty/console/active | 15:31 |
rcj | pitti, thanks | 15:31 |
doko | yofel, https://bugs.launchpad.net/ubuntu/+source/ffmpegthumbs/+bug/1578269 (only recommended by digikam) | 15:38 |
ubottu | Launchpad bug 1578269 in ffmpegthumbs (Ubuntu) "demote ffmpegthumbs to proposed, fails to build with new ffmpeg" [Undecided,Confirmed] | 15:38 |
cjwatson | doko: why do you disable entire test suites rather than just the failing test? (survex, which I'd just started to look at upon noticing that you'd sledgehammered it) | 16:07 |
doko | cjwatson, sure, I could have done this as well. however I didn't see any failure on the local build | 16:13 |
tjaalton | doko: arm64 fails to build llvm-3.8 on trusty, log says "internal compiler error". this probably is a blocker for lts-xenial. should I file a bug against gcc-4.8? | 16:13 |
doko | tjaalton, I'm not involved with the lts uploads of clang. does this persist when you give it back? | 16:14 |
tjaalton | doko: built it on a ppa, haven't tried rebuilding | 16:15 |
tjaalton | will do that now | 16:15 |
doko | cjwatson, alsa-plugins-extra is also merged | 16:17 |
cjwatson | doko: I don't see any failure right now on the local build either (I'm investigating), but the point of a test suite is to make problems on future builds less likely | 16:17 |
doko | cjwatson, right, that's why I filed a bug report which I intend to re-open after the current transitions | 16:18 |
cjwatson | IME those bug reports get lost | 16:19 |
doko | ok, then I'll re-upload after the transition with the fix reverted | 16:21 |
cjwatson | well like I say I was working on them anyway ... | 16:22 |
doko | I only worked on these while you were bringing you kids to bed last night, and just re-started again. but it's not just ffmpeg which is blocking | 16:23 |
cjwatson | valgrind shows what the survex problem probably is | 16:26 |
cjwatson | and the freshplayerplugin problem is easily reproducible locally in a UTF-8 locale | 16:30 |
hallyn | pitti: is there a 'dh_systemd_disable' sort of thing? | 16:31 |
pitti | hallyn: there isn't, what should that do? | 16:32 |
pitti | units are disabled by default, after all | 16:32 |
hallyn | pitti: problem is, we currently have libvirt-bin.service, which is Alias=libvirtd. We're switching to debian packaging, which has libvirtd.service instead | 16:32 |
hallyn | Which I want to Alias=libvirt-bin for ahwile probably | 16:33 |
hallyn | but how should i do the renaming? | 16:33 |
hallyn | (sorry, biam) | 16:33 |
pitti | hallyn: ah, so you need to rename the enablement symlinks in the prerm? | 16:33 |
pitti | err, preinst | 16:33 |
pitti | hallyn: I think this would be a conditionalized mv in the preinst | 16:33 |
cjwatson | doko: When you said "Revert last change" in freshplayerplugin (presumably the build-dependency on libjack-dev), you don't seem to have actually done so. Should I do so since I plan to upload it anyway? | 16:38 |
hallyn | pitti: so i should do it manually using 'mv'? | 16:41 |
pitti | hallyn: I think that's better than just rm'ing it and re-creating the new ones, if you want to maintain the fact that an admin manually disabled it | 16:42 |
pitti | i. e. it should still be disabled after the upgrade | 16:43 |
hallyn | pitti: yeah right now i was just trying to stop it (as in https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/libvirt-daemon-system.preinst?h=2016-05-02/yakkety) and i manually tried 'disabling' it, but that didn't suffice | 16:45 |
hallyn | i'll try moving the files - then do i do a systemctl reload? (from inside prerm?) | 16:45 |
cjwatson | doko: Seems to make no difference to the configuration, so I'll go ahead and do that | 16:45 |
hallyn | (of course, i *could* just punt on this and keep this as delta from debian, but i'd really like to minimize that) | 16:46 |
cjwatson | doko: freshplayerplugin and survex both fixed | 16:56 |
doko | ta \o/ | 16:56 |
tjaalton | doko: rebuild fails too | 16:56 |
cjwatson | and uploading an ffmpeg patch that's supposed to fix the autopkgtest failure | 17:01 |
hallyn | pitti: gonna try http://paste.ubuntu.com/16221711/ | 17:06 |
pitti | hallyn: looks good at first sight, and also gets rid of the bare systemctl invocation (which breaks under upstart and with policy-rc.d in e. g. chroots) | 17:08 |
pitti | hallyn: FTR, if you ever have that case, please use deb-systemd-invoke, this checks policy-rc.d | 17:09 |
pitti | or just invoke-rc.d | 17:09 |
hallyn | pitti: ok, thx | 17:10 |
hallyn | actually, lemme think. we have cloud archives, so in fact what i have in that paste is not sufficent, | 17:10 |
hallyn | as it'll break if someone in 14.04 upgrades to it | 17:11 |
hallyn | i don't suppose we can hae any sort of sanity guarantees about lts-to-lts upgrades even with cloud archives? | 17:11 |
hallyn | jamespage: ^ is there going to be a cloud archive providing yakkety's libvirt to pre-15.10 users? | 17:11 |
hallyn | (i..e non-systemd-based) | 17:11 |
hallyn | zul: ^ | 17:12 |
zul | hallyn: dunno yet :) | 17:14 |
hallyn | well maybe i'll just leave it broken until we know | 17:14 |
hallyn | bc 'fixing' it also means papering over other potential bugs | 17:14 |
hallyn | pitti: so instead of checking for that symlink by hand should i be doing 'deb-systemd-invoke systemctl is_enabled libvirt-bin' ? | 17:15 |
hallyn | nah | 17:16 |
pitti | hallyn: deb-systemd-invoke is just for start/stop; enable/disable is fine, not a thing that policy-rc.d covers | 17:16 |
pitti | hallyn: but it's by and large the same as checking for the symlink directly, so mostly a matter of preference I'd say | 17:16 |
hallyn | ok - thanks | 17:17 |
pitti | hallyn: actually | 17:17 |
pitti | hallyn: deb-systemd-helper has is-enabled, enable, disable etc., and that might be better as /var/lib/systemd/deb-systemd-helper-enabled/ also needs to be updated | 17:18 |
pitti | that's the crazy Debian thing to sync enablement over upgrades, across init systems etc. | 17:18 |
pitti | this might fire back if we don't update this too | 17:19 |
hallyn | ugh | 17:19 |
pitti | hallyn: sorry, I think that might be the first time this kind of upgrade issue happens | 17:19 |
hallyn | but what about renames? | 17:19 |
hallyn | that is deb-systemd-helper enable/disable isn't quite enough... oh, but | 17:20 |
doko | wgrant, cjwatson, pitti: https://launchpadlibrarian.net/257883350/buildlog_ubuntu-yakkety-i386.slurm-llnl_15.08.10-1build1_BUILDING.txt.gz (packages modifying -dbgsym packages). is there a plan when we'll switch to the new dbgsym packages? | 17:20 |
hallyn | i can just disable, move the classical links by hand, then enable? | 17:20 |
hallyn | pitti: put another way: what the heck is under /var/lib/systemd/deb-systemd-helper-enabled/ | 17:20 |
pitti | hallyn: so I think "if deb-system-helper is-enabled <old name> then disable the old name, otherwise disable the new name | 17:20 |
pitti | hallyn: so, I'm fairly sure that just handling the links as you do it now should work | 17:21 |
pitti | as the /var/lib/helper stuff never trumps admin changes | 17:21 |
pitti | so, forget what I said | 17:21 |
hallyn | ok | 17:21 |
pitti | hallyn: the stuff in /var/lib basically tracks the distro defaults | 17:22 |
hallyn | otherwise i was thinking i'd need to deb-systemd-helper purge; move the files, deb-systemd-helper enable | 17:22 |
hallyn | ok - so those files should get dropped naturally? | 17:22 |
hallyn | i'll make a note to check them in a test - thanks pt | 17:22 |
hallyn | uh. thanks pitti | 17:22 |
pitti | this would be really ugly indeed | 17:22 |
pitti | hallyn: for testing, I think check that it upgrades correctly with an enabled and disabled service, and that installing it again works | 17:23 |
pitti | and ignore the /var stuff | 17:23 |
hallyn | ok thx | 17:23 |
=== afkthairus is now known as athairus | ||
hallyn | man sometimes ppas just take forever to publish after building... | 17:55 |
doko | ubuntu-keyboard-swedish/amd64 unsatisfiable Depends: hunspell-sv-se | 17:57 |
doko | ubuntu-keyboard-swedish/armhf unsatisfiable Depends: hunspell-sv-se | 17:57 |
doko | ubuntu-keyboard-swedish/i386 unsatisfiable Depends: hunspell-sv-se | 17:57 |
doko | sil2100, ^^^ | 17:57 |
hallyn | pitti: argh. well i can't do that in pre-inst, apparently /lib/systemd/system/libvirt-bin.service has been removed by this point | 18:18 |
pitti | hallyn: uh? that sounds wrong; preinst runs before unpack | 18:18 |
hallyn | maybe i do it in the libvirt-bin (which is otherwise just a metapackage) preinst/ | 18:18 |
pitti | no, you can't rely on the unpack order then | 18:19 |
hallyn | pitti: yeah but the libvirtd.service is in libvirt-daemon-system package; libvirt-bin.servce is in libvirt-bin package | 18:19 |
hallyn | so what to do? | 18:19 |
pitti | oh | 18:19 |
pitti | hallyn: does one depend on the other? | 18:20 |
hallyn | yeah libvirt-bin depends on libvirt-daemon-system | 18:20 |
hallyn | so, maybe it would be easier to keep libvirt-bin.service for now, and do that switch after we've gotten rid of the libvirt-bin package altogether? | 18:22 |
hallyn | so the move is at least happening within one pkg? | 18:22 |
pitti | hallyn: so you need to do it in the package which originally shipped the old name | 18:22 |
hallyn | ok, | 18:22 |
pitti | if that was libvirt-bin, its preinst needs to do that, yes | 18:22 |
pitti | even if it's empty afterwards | 18:22 |
hallyn | i can do that. bu ti'm still worried about the file being gone, | 18:23 |
pitti | but you need that empty package for upgrades anyway | 18:23 |
hallyn | because at postinst time for libvirt-daemon-ssytem it still says that libvirt-bin.service exists | 18:23 |
hallyn | so is that getting cached under /var/lib somewhere during package remove/unpack? | 18:23 |
hallyn | all right so lemme try with that in libvirt-bin.preinst. thx | 18:26 |
pitti | hallyn: dependencies get configured before postinst runs; deb contents does not get cached, now | 18:26 |
pitti | (sorry, distracted, sprint) | 18:26 |
hallyn | pitti: hold on. there is existing code there from debian's transition. i was misreading that and thinking it was my code from an earlier upstart->systemd xition | 18:27 |
hallyn | so actually mayb ei just need to tweak the version numbers there and it'll just work | 18:28 |
hallyn | pitti: in particular, http://paste.ubuntu.com/16223586/ | 18:28 |
hallyn | does that look like it would work? | 18:28 |
* hallyn tries | 18:29 | |
pitti | hallyn: that actually looks fairly good, yes | 18:31 |
hallyn | cool let's see if it works | 18:31 |
pitti | hallyn: it doesn't maintain admin changes, though | 18:31 |
pitti | hallyn: i. e. if the admin manually disabled the service, it will restart after the upgrade | 18:32 |
hallyn | hm | 18:32 |
hallyn | and i can only check that from libvirt-bin.preinst? | 18:32 |
hallyn | no, not if i use the deb-systemd helpers | 18:33 |
hallyn | so to that hunk i could add a tmpfile created if the service is enabled, and only enable it by hand... | 18:34 |
hallyn | pitti: by disabled you mean stopped or actually disabled so it won't start again? | 18:34 |
pitti | hallyn: disabled (stopped is fine) | 18:34 |
hallyn | sigh | 18:36 |
hallyn | all right i'll test it both ways. thx | 18:36 |
hallyn | pitti: meh, that doesn't work. I still get http://paste.ubuntu.com/16224784/ | 19:22 |
hallyn | so i'll do it my way in libvirt-bin.preinst | 19:22 |
hallyn | my way -> your way? but not debian's way :) | 19:22 |
doko | roaksoax, please could you have a look at https://launchpad.net/ubuntu/+source/virtualbox/5.0.20-dfsg-1/+build/9669239 ? currently blocking some transitions | 19:49 |
roaksoax | doko: ???? I've never touched virtualbox i dont think ... | 19:55 |
doko | ohh, looked at the wrong package | 19:56 |
roaksoax | :) | 19:58 |
cjwatson | doko: There is no current plan, nor am I even sure it's agreed that we will switch. | 20:25 |
cjwatson | The way that ended up in Debian is significantly less convenient to deal with for no obvious advantage, although the delta is awkward. | 20:26 |
doko | I should propose for debian policy not to modify dbgsym packages ... | 20:28 |
pitti | cjwatson: we could make the delta a bit smaller by patching debhelper to name them .ddeb instead of .deb; in theory this should then not need LP changes, or am I missing something? | 20:29 |
hallyn | pitti: nope, that (manual mv'ing in libvirt-bin.preinst) didn't work. i'll use the deb-systemd-helper to disable and leave tmpfiles for postinst to know whether to reenable | 20:31 |
hallyn | ugh | 20:31 |
cjwatson | pitti: Not sure. There's all the hairy stuff that arranges to control whether ddebs are built on an archive-by-archive basis | 20:33 |
cjwatson | Build-Debug-Symbols etc. | 20:33 |
pitti | cjwatson: oh, the parsing of /CurrentlyBuilding etc. | 20:33 |
hallyn | oh great, this is helpful for testing: | 20:38 |
hallyn | deb-systemd-helper is-enabled libvirt-bin.service | 20:38 |
hallyn | /usr/bin/deb-systemd-helper was not called from dpkg. Exiting. | 20:38 |
* hallyn needs more info on deb-systemd-helper mask/unmask | 20:45 | |
doko | AlbertA: please could you have a look at https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1578381 | 20:51 |
ubottu | Launchpad bug 1578381 in mir (Ubuntu) "mir tests fail in yakkety on amd64 and i386" [Critical,Confirmed] | 20:51 |
AlbertA | doko: 0.21? shouldn't it be 0.22? | 20:52 |
doko | AlbertA, there is no 0.22 in https://launchpad.net/ubuntu/+source/mir | 20:54 |
AlbertA | camako: bregma: ^ | 20:55 |
AlbertA | doko: I thought the ci-train was supposed to release to the transitional overlay thingy | 20:55 |
doko | AlbertA, it's my understanding that this is not yet in effect for yakkety | 20:56 |
AlbertA | doko: in any case, the test failures look intermittent: | 20:56 |
AlbertA | [ FAILED ] ClientLatency.throttled_input_rate_yields_lower_latency | 20:56 |
AlbertA | I think that test will potentially fail if there's too much load on the build machines | 20:56 |
doko | AlbertA, I can give them back and see what happens. can you save a copy of the build log locally? | 20:56 |
AlbertA | if you re-run the builds it will most likely be ok | 20:58 |
=== salem_ is now known as _salem | ||
doko | AlbertA, give back succeeded. closing the issue. ta | 21:41 |
AlbertA | doku: ack | 21:42 |
camako | AlbertA, mir 0.22 is not in xenial either | 21:43 |
camako | weird | 21:43 |
camako | or meybe expected due to the overlay | 21:44 |
roaksoax | 8 | 21:59 |
pitti | infinity: FYI, just committed bug 1577966, so happy proxying (if you run autopkgtest from git, like all the kool kids do :) ) | 22:08 |
ubottu | bug 1577966 in autopkgtest (Ubuntu) "automatically setup proxies other than apt-cacher-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1577966 | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!