| === salem_ is now known as _salem | ||
| === sysop is now known as Guest93467 | ||
| === JanC_ is now known as JanC | ||
| pitti | Good morning | 06:10 |
|---|---|---|
| pitti | Odd_Bloke: 1629797> queue, will reply there | 06:11 |
| pitti | lamont: indeed, it seems that test was written and tested only with locally built binaries, not with binaries from the archive -- this is just broken | 06:12 |
| pitti | lamont: this was introduced in http://launchpadlibrarian.net/250336367/open-iscsi_2.0.873+git0.3b4b4500-14ubuntu1_2.0.873+git0.3b4b4500-14ubuntu2.diff.gz | 06:13 |
| pitti | cyphermox: https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu5 → please let's not do that | 06:14 |
| pitti | cyphermox: building the package to work around that broken assumption in the test is quite expensive -- also, it doesn't even work | 06:15 |
| didrocks | good morning pitti! Had a nice week-end? | 06:15 |
| pitti | didrocks: bonjour didrocks! yes, I enjoyed having a quiet day yesterday (German Reunion), last week was pretty intense :) | 06:15 |
| didrocks | yeah, a nice rest after an intense week I guess ;) | 06:16 |
| Mirv | there's zero flavors nowadays that'd have the alternate installer? | 06:31 |
| Mirv | oh yes there is, lubuntu, just not in daily build dircetory | 06:31 |
| Mirv | (because of bug #1530530 can't boot any normal Ubuntu installer, only final installation) | 06:32 |
| ubottu | bug 1530530 in gfxboot-theme-ubuntu (Ubuntu) "Installer doesn't show up on some Chromebooks: "Error setting up gfxboot"" [Medium,Confirmed] https://launchpad.net/bugs/1530530 | 06:32 |
| Mirv | doh, that uses gfxboot too, so actually the only option is still USB -> USB installation, then copying to target HDD and hacking grub. or maybe a ready made image could be copied too, and of course if gfxboot could be disabled. | 06:38 |
| dholbach | good morning | 06:39 |
| dholbach | @pilot in | 07:07 |
| === udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots: dholb | ||
| dholbach | looks like the topic is a bit long | 07:08 |
| slangasek | s/(16.10 )// ? :) | 07:12 |
| ginggs | reverse-depends/seeded-in-ubuntu are working again, can remove that | 07:13 |
| Mirv | pitti: is there an issue starting autopkgtests right now? yesterday evening was fine, but now that I'm trying to restart a test from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2035-excuses/2016-10-04_06:35:02/2035_vivid_excuses.html for bzoltan it doesn't seem to start (waited 5+ mins and tried twice) | 07:18 |
| pitti | Mirv: no known one -- did you get a confirmation page that the request was sent? | 07:19 |
| Mirv | pitti: yes | 07:22 |
| Mirv | http://people.ubuntu.com/~timo-jyrinki/autopkgtest.png | 07:23 |
| pitti | Mirv: ack, I'll have a look | 07:27 |
| pitti | cyphermox: I removed your open-iscsi upload from -proposed; I suggest talking to matsubara instead to actually fix the test -- they should *never* assume a structure in the upper tmpdirs, and never fiddle with test dependencies themselves | 07:37 |
| pitti | you will either have the distro or the locally built .debs already installed, and if not, just use apt-get install for them | 07:37 |
| pitti | cyphermox: i. e. here: http://launchpadlibrarian.net/250336367/open-iscsi_2.0.873+git0.3b4b4500-14ubuntu1_2.0.873+git0.3b4b4500-14ubuntu2.diff.gz | 07:38 |
| pitti | it's even marked with "XXX fix this hack" | 07:39 |
| cpaelzer | pitti: thanks for your explanation on the netplan bug, I replied and forwarded to IBM if they really need anything | 07:54 |
| pitti | hey cpaelzer, guten Morgen! | 07:55 |
| cpaelzer | pitti: hallöchen | 07:56 |
| cpaelzer | my good morning today was creating an emergency GBE-over-luster-terminal fix so I skipped any good morning feelings :-/ | 07:57 |
| andrewsh | https://bugs.launchpad.net/ubuntu/+source/unity/+bug/887821 is said to be fixed, yet I observe that still happening | 08:06 |
| ubottu | Launchpad bug 887821 in unity (Ubuntu) ""Show copy dialog" right click launcher entry doesn't work (on nautilus copy)" [High,Fix released] | 08:06 |
| andrewsh | who should I prod to have it looked at? | 08:06 |
| === infinity changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: dholbach | ||
| pitti | Mirv: http://autopkgtest.ubuntu.com/running#queue-ppa-vivid-amd64 → your request actually is there | 08:16 |
| pitti | Mirv: so that's another aspect of that weird rabbitmq queueing bug in xenial :( | 08:16 |
| Mirv | pitti: oh, ok, at least once it's indeed in the queue. I obviously didn't check for queues as it seemed the infra was free. | 08:17 |
| pitti | Mirv: it actually wasn't visible in the queue -- that's part of the bug | 08:18 |
| Mirv | ok | 08:18 |
| andrewsh | pitti: when do you expect to upload the second bit of the systemd fix to xenial? | 08:21 |
| pitti | andrewsh: still coordinating with sbeattie on bug 1628687 | 08:21 |
| ubottu | bug 1628687 in systemd (Ubuntu Xenial) "Assertion failure when PID 1 receives a zero-length message over notify socket" [High,In progress] https://launchpad.net/bugs/1628687 | 08:21 |
| pitti | andrewsh: I'm fine with SRUing that today, but I'm not sure if sbeattie wants to push it out of band as an USN | 08:21 |
| andrewsh | pitti: I'm asking from position of a user and a downstream (we cherry-picked fixes from the Debian package) | 08:23 |
| pitti | andrewsh: I see no rush in this (hence I'd be fine with SRUing); this is really not a big deal | 08:23 |
| andrewsh | ack | 08:24 |
| pitti | plugging one out of a dozen ways to DoS your local machine isn't going to make things any different :) | 08:24 |
| pitti | so bug, yes; security, clearly not | 08:24 |
| pitti | but given how much press echo this got, some people might think otherwise, and sbeattie might want to fix it solely to quiesce the peanut gallery :) | 08:24 |
| ara | Hello! Can any of the SRU team members approve snap-confine in xenial-proposed, please? https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=snap-confine | 08:30 |
| sil2100 | xnox: hey! | 08:46 |
| sil2100 | xnox: do you feel you're a good person to do an upstart merge-proposal review? ;) | 08:46 |
| sil2100 | xnox: I'm looking for a volunteer that knows upstart code to take a look at a branch for our xenial-touch-systemd work | 08:47 |
| xnox | sil2100, ..... ok | 09:03 |
| LocutusOfBorg | hi jbicha, any idea for the link-grammar failure in autpkgtestsuite? | 09:06 |
| jbicha | LocutusOfBorg: I wouldn't have synced it, sorry I didn't let you know in advance | 09:06 |
| jbicha | LocutusOfBorg: maybe it's https://github.com/opencog/link-grammar/issues/437 | 09:10 |
| sil2100 | xnox: https://code.launchpad.net/~vicamo/upstart/xenial-escape-systemd-strings/+merge/307140 <- this is for the xenial upstart branch, we can also propose and release that to trunk but from our POV it's not the main target | 09:11 |
| sil2100 | xnox: thanks! :) | 09:11 |
| xnox | sil2100, it seems like it is implementing systemd-escape for the unit names the right way? | 09:15 |
| pitti | Mirv, slangasek: I went through https://www.rabbitmq.com/consumer-prefetch.html and similar docs, and I belive I may have found the reason for the hidden test requests; restarted the workers now, let's see how it goes | 09:32 |
| caribou | nacc: looking at it, maybe I can figure out how to build with the latest llvm | 09:47 |
| Mirv | thank you | 09:49 |
| === zigo is now known as Guest84780 | ||
| === hikiko is now known as hikiko|ln | ||
| sil2100 | xnox: it's for the upstart-local-bridge basically | 10:44 |
| sil2100 | xnox: could you take a look at it and review? | 10:44 |
| sil2100 | We need this to land to get the systemd xenial phone switch happening | 10:45 |
| caribou | nacc: well, looks like debian is still building with llvm-3.6 and building with 3.7 will require sensible code change : | 10:56 |
| caribou | nacc: https://www.mail-archive.com/pkg-clamav-devel@lists.alioth.debian.org/msg04458.html | 10:57 |
| === zigo_ is now known as zigo | ||
| === hikiko|ln is now known as hikiko | ||
| === _salem is now known as salem_ | ||
| === marcusto_ is now known as marcustomlinson | ||
| dholbach | @pilot out | 12:27 |
| === udevbot_ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Final Beta! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: | ||
| pitti | Mirv: do you need to do something to get https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-2035-excuses/2016-10-04_06:35:02/2035_vivid_excuses.html updated? | 12:50 |
| pitti | Mirv: oh, it's a per-timestamp file, I suppose we want the latest one | 12:51 |
| pitti | ah, from https://bileto.ubuntu.com/#/ticket/2035 | 12:52 |
| sil2100 | xnox: hey! Did you have a moment to take a look at the upstart MP? ;) | 13:04 |
| xnox | sil2100, not yet. if i'll be landing it, i'll prepare a silo with said upload targetting yakkety and xenial. | 13:04 |
| pitti | Odd_Bloke: I followed up on the bug; the root cause is clear, but how to fix it (cleanly) totally isn't | 13:15 |
| ximion | Laney: asgen fails at Debian with an error in LZMA now (code 11, LZMA_PROG_ERROR), which indicates a corrupt internal state | 13:16 |
| ximion | so, there is definitely be something fishy in the zarchive code | 13:16 |
| acheronuk | why would a test such as this just time out? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/k/kwin/20161004_005822@/log.gz | 13:17 |
| Odd_Bloke | pitti: Yeah, I saw the response; thanks for looking at it. :) It's frustrating that resolved can't modify the resolution order once it's up. | 13:18 |
| pitti | Odd_Bloke: resolved isn't up yet | 13:19 |
| pitti | and even if it was, it doesn't matter -- cloud-init blocks dbus, so nothign can talk to it | 13:19 |
| pitti | Odd_Bloke: I'm trying something else | 13:19 |
| Odd_Bloke | pitti: Cool. :) | 13:20 |
| pitti | oh cool, this actually works | 13:20 |
| sil2100 | xnox: would be great - xenial or the xenial-overlay? I guess I could take the xenial package from the queue and copy it to the overlay earlier | 13:23 |
| xnox | sil2100, is there a current difference of upstart between xenial and xenial-overlay? | 13:23 |
| xnox | sil2100, where is the xenial-overlay archive? | 13:24 |
| sil2100 | xnox: no, I guess we use the main xenial upstart right now | 13:24 |
| sil2100 | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay | 13:24 |
| pitti | Odd_Bloke: followed up again with something relative unintrusive to test | 13:24 |
| sil2100 | We put packages for touch there as it's faster than waiting for it to go out as an SRU | 13:24 |
| xnox | sil2100, but also means no security support? | 13:25 |
| sil2100 | xnox: there are no xenial products anywhere so we don't really care about security support | 13:25 |
| sil2100 | And right now it's an 'in-progress' development product | 13:26 |
| Odd_Bloke | pitti: Trying now. | 13:26 |
| sil2100 | xnox: anyway, just release for normal xenial for now, I then pick up the SRU and copy to overlay to get it faster in our images for testing | 13:26 |
| infinity | xnox: Hey you, upload your staged yakkety d-i changes. | 13:40 |
| xnox | infinity, yo, it's in unapproved queue | 13:40 |
| infinity | xnox: Oh, indeed, an hour ago. Kay. | 13:41 |
| Laney | hi ximion | 13:50 |
| Laney | fun, reproducible? | 13:50 |
| ximion | Laney: maybe 60% of the times... | 13:51 |
| ximion | hmm, no | 13:51 |
| ximion | 1 out of 3 runs succeeded | 13:51 |
| ximion | only difference was compilation with the latest LDC snapshot | 13:51 |
| ximion | Laney: the post on the D newsgroup has some helpful advice, but unfortunately nothing which raised a red flag yet | 13:52 |
| smoser | pitti, around ? | 13:52 |
| rharper | smoser: we need to run *before* basic for mount, but we need after systemd-resolved for DNS resolution (this is in cloud-init.service) | 13:53 |
| rharper | the GCE Datasource triggers this when it happens as it's metadata URL is a hostname | 13:54 |
| rharper | vs. ips like in EC2 and OpenStack | 13:54 |
| === alexisb is now known as alexisb-afk | ||
| jbicha | have we hit the language pack translation deadline for yakkety final yet? | 13:57 |
| Odd_Bloke | smoser: rharper: pitti and I are working on the slow boot time issue, if that's what you're looking to chat about. | 14:00 |
| smoser | Odd_Bloke, was it slow boot on gce ? | 14:01 |
| smoser | they're related then. | 14:01 |
| Odd_Bloke | smoser: Everywhere. | 14:01 |
| smoser | well, its not everywhere. | 14:01 |
| Odd_Bloke | OK, anywhere with the GCE datasource in the list. | 14:01 |
| smoser | (fwiw, openstack does not show "slow boot" at least in serverstack, and neither does lxc) | 14:01 |
| Odd_Bloke | Or the EC2 datasource. | 14:01 |
| smoser | so the bug is bug 1629868 | 14:02 |
| ubottu | bug 1629868 in cloud-init (Ubuntu) "times out because of no dbus" [Undecided,New] https://launchpad.net/bugs/1629868 | 14:02 |
| smoser | and i'm pretty sure that htat is because cloud-init.service is now running before dns is up | 14:02 |
| Odd_Bloke | smoser: The fix that pitti has proposed is to put Before=dbus.socket in cloud-init.service. | 14:02 |
| smoser | because of a change made in bug 1611074 | 14:03 |
| ubottu | bug 1611074 in cloud-init "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Fix committed] https://launchpad.net/bugs/1611074 | 14:03 |
| smoser | Odd_Bloke, probably After= | 14:03 |
| smoser | no? | 14:03 |
| smoser | rharper, had suggested systemd-resolved.service | 14:03 |
| Odd_Bloke | smoser: Nope; systemd-resolved won't come up until well after cloud-init because of other dependencies. | 14:03 |
| Odd_Bloke | smoser: The problem is that the resolve nss module sees the DBUS socket and waits 25 seconds for a response over it. | 14:03 |
| smoser | the change that caused this was (i think) | 14:04 |
| smoser | - Move cloud-init.service to early boot: Add DefaultDependencies=no and Before=basic.target | 14:04 |
| Odd_Bloke | (Which there won't be, because dbus.service won't start until after cloud-init.service) | 14:04 |
| smoser | ah. | 14:04 |
| Odd_Bloke | Whereas if there isn't a DBUS socket, the resolve nss module fails fast. | 14:04 |
| Odd_Bloke | And we just use DNS directly. | 14:04 |
| smoser | well that is just messed up. | 14:04 |
| smoser | hm. | 14:05 |
| rharper | smoser: I reproduced the slow boot on serverstack, and it is the GCE datasource due to the attempt to resolve the hostname | 14:05 |
| smoser | before=debus.socket seems not so right. | 14:05 |
| smoser | it seems like a very specific fix for the way it happens to work right now. | 14:06 |
| smoser | rharper, why didnt i see it on friday then? | 14:06 |
| rharper | smoser: agreed; cloud-init.service *needs* DNS | 14:06 |
| smoser | in that system with the wierd clock that you saw. | 14:06 |
| Laney | ximion: GC getting in the way somehow? | 14:06 |
| smoser | it needs dns, but it does not need systemd-resolvd | 14:07 |
| Odd_Bloke | resolved is not the only way of getting DNS. | 14:07 |
| smoser | (doesn't need a caching name service) | 14:07 |
| rharper | smoser: AFAICT it's racy w.r.t when systemd-resolved comes up | 14:07 |
| smoser | so i suspect that Odd_Bloke, rharper and smoser are not really adding anything to pitti's brain | 14:07 |
| rharper | well, it seems odd to dance around the idea that we want DNS but we don't have a direct way of expressing that | 14:07 |
| smoser | so mostly i think we're just chattering without his input :) | 14:07 |
| Odd_Bloke | It shouldn't be racy; cloud-init has to complete for basic.target, and systemd-resolved happens after basic.target. | 14:07 |
| rharper | dbus.socket doesn't seem to be DNS related at all (unless you know how) | 14:07 |
| smoser | rharper, right. | 14:08 |
| smoser | its not. | 14:08 |
| smoser | the fix that Odd_Bloke suggested was to put 'before=dbus.socket' | 14:08 |
| smoser | so that when nss runs it does not see the socket | 14:08 |
| smoser | and wait for a response over it | 14:08 |
| smoser | rather it just goes on | 14:08 |
| rharper | huh | 14:08 |
| rharper | still seems obtuse | 14:09 |
| smoser | right | 14:09 |
| ximion | Laney: according to https://forum.dlang.org/post/igqwbqawrtxnigplgnka@forum.dlang.org it doesn't do that | 14:10 |
| Odd_Bloke | The last comment on https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1629797 is relevant: "Moving dbus.service into early boot would be a bold step, and I don't think such a large change is appropriate two weeks before release." | 14:10 |
| ubottu | Launchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged] | 14:10 |
| rharper | https://github.com/systemd/systemd/issues/848 | 14:11 |
| ximion | Laney: oooooooh!!! Ilya (working on numeric stuff in D) has posted some very interesting hint for the deadlocking stuff there: https://issues.dlang.org/show_bug.cgi?id=15939 | 14:11 |
| ubottu | issues.dlang.org bug 15939 in druntime "GC.collect causes deadlock in multi-threaded environment" [Blocker,New] | 14:11 |
| ximion | Laney: haven't seen deadlocks for a while though | 14:11 |
| Laney | not with ldc | 14:12 |
| smoser | Odd_Bloke, thanks for the bug pointer | 14:14 |
| smoser | it just seems so hacky and randomly specific | 14:15 |
| rharper | the Before=dbus.socket works on my openstack instance where it was hanging | 14:18 |
| Odd_Bloke | Yeah, I've confirmed it works on GCE and EC2. | 14:20 |
| xnox | robru, when i say yakkety+xenial as target, does it mean Ubuntu Archive for both? | 14:28 |
| pitti | smoser: yes, around, just slowly responding due to too many parallel pings | 14:40 |
| smoser | pitti, your suggested fix sseems to work, but it just seems somewhat random | 14:41 |
| smoser | do you disagree? | 14:41 |
| pitti | Odd_Bloke, smoser: yes, it is obtuse; we are doing this at a point where the entire early boot is blocked on cloud-init, which wants to run before networking, dbus, etc., but still use the network | 14:41 |
| pitti | smoser: it is somewhat random, yes; I just don't have a better idea right now (see the bug) | 14:42 |
| pitti | for now I'm just interested if that makes the hangs go away | 14:42 |
| smoser | we started running before basic.service so that we could run before local mounts were done (so that the ephemeral/removable things in /etc/fstab would not be already mounted at that point) | 14:42 |
| pitti | a better fix might be to move dbus.socket into late boot, but I don't know how many other things during early boot want to talk to dbus; that seems a bit too risky to do two weeks before release | 14:43 |
| smoser | i agree with that being too risky | 14:44 |
| smoser | but i dont know that i agree it'd be a better fix. | 14:44 |
| pitti | well, ideas appreciated | 14:44 |
| pitti | we can revert resolve, thus punting | 14:45 |
| pitti | .. that spec to the next cycle (and running into it again) | 14:45 |
| smoser | it seems to me that if the issue is (as i understand it) systemd-resolvd | 14:45 |
| pitti | or run dbus.service earlier, or dbus.socket later | 14:45 |
| smoser | that nss should do a better job of determining "should i try to talk to resolvd" than just saying "oh look a dbus socket!" | 14:45 |
| pitti | moving dbus.service earlier or the socket into late boot seem too intrusive | 14:46 |
| smoser | s/nss/the resolvd nss module/ | 14:46 |
| pitti | reverting resolve and punting to the next release, or running cloud-init before dbus.socket are less intrusive | 14:46 |
| pitti | smoser: well, tell me how | 14:46 |
| pitti | (also, as I said -- I just asked for testing this change to confirm it's really *that* problem -- I didn't say it was the final solution) | 14:47 |
| smoser | well, hackily, systemd-resolvd.service could otherwise advertise its "up" (via a /run/yes-im-up-now) | 14:48 |
| smoser | and nssmodule could require that before starting | 14:48 |
| smoser | or, if the dbus socket was there... | 14:48 |
| smoser | it could ask systemd: what is the status of the systemd-resolvd.service ? | 14:48 |
| smoser | and if not started, not bother | 14:48 |
| pitti | no, you can't | 14:49 |
| pitti | as that also uses dbus | 14:49 |
| pitti | so you need a side channel | 14:49 |
| smoser | the issue isnt dbus | 14:49 |
| smoser | right? | 14:49 |
| pitti | it is | 14:49 |
| smoser | the issue is the socket | 14:49 |
| smoser | wait. | 14:49 |
| pitti | well, it's "communicating over dbus" | 14:49 |
| pitti | dbus.socket is running, but dbus.service cannot start yet | 14:49 |
| smoser | communicating over dbus? or communicating over dbus to a service that is not started yet. | 14:50 |
| smoser | ok. i thought it was communication specifically targetted at the not-yet-started systemd-resolvd | 14:50 |
| smoser | rather than general dbus chatting. | 14:50 |
| pitti | no, that's not the problem | 14:50 |
| pitti | if resolved isn't running, it fails fast and punts to "dns" | 14:51 |
| pitti | it == nss module | 14:51 |
| smoser | oh. | 14:52 |
| smoser | so it *does* ask systemd over the socket about resolved's status ? | 14:52 |
| smoser | s/socket/dbus/ | 14:52 |
| pitti | yes, it tries to do a dbus call to resolved | 14:52 |
| pitti | if the destination isn't running, that's fast | 14:52 |
| pitti | but if dbus itself isn't running, the client libraries time out after 25 s | 14:52 |
| smoser | and dbus.service isnt running just because | 14:55 |
| smoser | do we have a reason that it needs basic.service ? | 14:55 |
| pitti | becase cloud-init runs before=basic.target (and lots of other things) in early boot | 14:55 |
| smoser | sorry. basic.target | 14:55 |
| smoser | do we have a *known* reason | 14:55 |
| pitti | no, see the bug -- it could be started earlier on, I just can't say if that breaks anything else | 14:55 |
| pitti | kdbus *cough* *cough* | 14:56 |
| pitti | so if we want to move dbus.service into early boot and that works for server/desktop etc. we can also try that | 14:56 |
| ogra_ | wasnt that renamed to kdbus2^Wbus1 ... ? | 14:56 |
| pitti | ogra_: yes, but bus1 is not a drop-in replacement for dbus; will still take a bit until this will actually be useful | 15:01 |
| ogra_ | like kdbus :) | 15:01 |
| pitti | well, kdbus worked great, it just wasn't accepted upstream :) | 15:01 |
| pitti | there were also some design issues about it, but playing with the dkms module was fun | 15:01 |
| bdmurray | mvo, sergiusens: Is bug 1580740 fixed in Yakkety? | 15:03 |
| ogra_ | well, i just dont get why they renamed it and not just simply changed the implementation keeping the name | 15:03 |
| ubottu | bug 1580740 in Snappy "[SRU] Cannot open a browser link from a snap that provides a link" [High,Triaged] https://launchpad.net/bugs/1580740 | 15:03 |
| smoser | pitti, is our dbus.service provided by upstream ? | 15:04 |
| smoser | wondering if we have delta there. | 15:04 |
| pitti | smoser: yes, https://cgit.freedesktop.org/dbus/dbus/tree/bus/dbus.service.in | 15:04 |
| nacc | caribou: thanks! yeah, i dug a little yesterday and realized after i pinged you that upstream only has up to 3.6 support | 15:11 |
| gQuigs | doko_: any plans to try to upgrade python for 14.04 anymore? https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1348955 | 15:11 |
| ubottu | Launchpad bug 1348955 in python2.7 (Ubuntu) "update Python for trusty" [Undecided,Confirmed] | 15:11 |
| nacc | caribou: we're seeing the ftbfs in llmv-toolchain-3.6 in y's test rebuild, hence my question | 15:11 |
| * gQuigs would really like TLS1.2 support, which would help Juju 1.25 a bit... | 15:11 | |
| sergiusens | bdmurray it is not related to snapcraft, I hope it is; it involves bits in the core snap and the desktop to be installed (hopefully pulled in by snapd) | 15:33 |
| rbasak | jamespage: in bug 1567811, could nova be impacted (ie. part of the regression risk)? If so, is nova being tested against xenial-proposed, and if not, do you have any opinion on whether this should be accepted into xenial? | 15:33 |
| ubottu | bug 1567811 in libvirt (Ubuntu Xenial) "nova-compute should depend on libvirt-bin.service instead of libvirtd.service " [Low,Fix committed] https://launchpad.net/bugs/1567811 | 15:33 |
| bdmurray | sergiusens: I'm not sure I am following your response. | 15:34 |
| sergiusens | bdmurray you asked if the aforementioned bug was fixed in yakkety, my response is, I don't know, I hope it is, I am not involved at all with that bug | 15:36 |
| sergiusens | :-) | 15:36 |
| bdmurray | sergiusens: got it | 15:37 |
| nacc | cpaelzer: i think you might have been offline, but coreycb was looking for some help getting access to a s390 node, if possible | 15:40 |
| nacc | cpaelzer: for debugging a autopkgtest on s390, iirc | 15:41 |
| coreycb | nacc, yeah that'd be great if possible :) | 15:41 |
| pitti | sbeattie: can you please let me know if you really want an USN for bug 1628687? otherwise I'll SRU it (but I don't want to go through the procedure a third time) | 15:41 |
| ubottu | bug 1628687 in systemd (Ubuntu Xenial) "Assertion failure when PID 1 receives a zero-length message over notify socket" [High,In progress] https://launchpad.net/bugs/1628687 | 15:41 |
| lamont | pitti: it would be wonderful if there was something I could tell systemd (maybe via the kernel commandline?) that would cause it to actually run "systemctl status $FOO", instead of just telling me to | 15:59 |
| === imcleod-afk is now known as imcleod | ||
| robru | xnox: no, if there is a plus sign in your series, the first series is archive and all subsequent series are overlay ppa. It says which packages target which archive in the build log | 16:09 |
| xnox | robru, =( | 16:17 |
| robru | xnox: if you really need to do a xenial sru you can just copy from xenial overlay after publishing | 16:18 |
| slangasek | robru: no, he can't | 16:22 |
| slangasek | SRUs are not supposed to build against the overlay ppa | 16:22 |
| slangasek | which may have different ABIs etc | 16:22 |
| slangasek | I think there's meant to be a toggle for this in the list of upload targets? | 16:23 |
| robru | Oh right. Well reuse the same mp for a second xenial ticket then | 16:23 |
| robru | slangasek: the toggle only works if the ticket has one series. Dual/triple tickets are always hardcoded to overlay | 16:24 |
| slangasek | right | 16:24 |
| robru | slangasek: it's been on my mind for a while to allow specifying such special cases, but low priority | 16:25 |
| slangasek | robru: considering I don't think the current dual/triple landings are a good idea anyway, I'd rather we not implement more such options that aren't being asked for :) | 16:33 |
| robru | slangasek: it is being asked for, you just saw xnox ask for it, and he isn't the first one | 16:34 |
| robru | slangasek: i think devel+stable is reasonable, but having vivid and yakkety together on the same ticket is really pushing the limits of what makes sense | 16:34 |
| slangasek | robru: I'm pretty sure xnox isn't actually asking for that. | 16:34 |
| slangasek | I'm pretty sure he just wants to do source uploads for both xenial and yakkety | 16:35 |
| slangasek | he doesn't need any of the "dual landing" branch stuff | 16:35 |
| robru | slangasek: he's frowned because he has no way to make a ticket that says yakkety archive + xenial archive | 16:35 |
| nacc | doko_: re: python-cffi ftbfs, just did a testbuild with gcc-5 and it does build/pass the tests. I'm not sure how to debug the testcase regression due to the compiler? | 16:35 |
| slangasek | robru: yes, but his use case is well served by having two tickets | 16:35 |
| robru | xnox: are you wanting to land one mp to yakkety and xenial or are you planning on doing source uploads? | 16:36 |
| coreycb | xnox, how long should I expect https://bileto.ubuntu.com to take to run autopkgtests against a ppa? | 16:37 |
| robru | coreycb: ten million years, give or take | 16:37 |
| coreycb | robru, lol, right on schedule then | 16:37 |
| robru | coreycb: what ticket? | 16:37 |
| === alexisb-afk is now known as alexisb | ||
| coreycb | robru, https://bileto.ubuntu.com/#/ticket/2042 | 16:38 |
| robru | coreycb: you have to actually lander approve it before britney will pick it up, and expect it to take a good two hours before the tests even start | 16:39 |
| coreycb | robru, gotcha, thanks for looking | 16:40 |
| robru | coreycb: oh actually the britney run time is currently 15 minutes so that's a damn miracle | 16:40 |
| coreycb | robru, ah excellent. still not the best way to debug an autopkgtest faliure though it's definitely good for testing against a ppa. | 16:41 |
| robru | coreycb: yeah so in about 15 to 30 it'll change from queued to running, and then however long your tests take, then you'll get the results. There are unfortunately a lot of delays polling the autopkgtests for the results | 16:42 |
| slangasek | coreycb: the MIR for python-pykmip as a recommends of barbican seems stalled (last reply from jamespage on 20Sep). Who can take care of this? | 16:49 |
| nacc | doko_: nm, i think in coordination with upstream, we me have found the issue | 16:51 |
| coreycb | slangasek, I'll take a look | 16:51 |
| slangasek | coreycb: thanks | 16:52 |
| bdmurray | happyaron: Your upload of fcitx in the xenial-proposed queue is missing the Launchpad-Bugs-Fixed line. | 16:55 |
| jbicha | bdmurray: I suggest emailing happya_ron since I believe he's out this week | 17:02 |
| Laney | Probably easier to reupload for him | 17:03 |
| sbeattie | pitti: if you want to take it through the SRU process instead, that's fine. I won't make you respin your SRU again. | 17:06 |
| smoser | pitti, so what do you think we should do here ? | 17:26 |
| smoser | for the dbus bug... do you think the before= is right ? | 17:26 |
| juliank | I'm thinking about doing an apt 1.3.1 release to go into the final to fix an issue with the auto-detect-proxy script which now accidentally reads from the helper's stderr as well when reading proxy line strings. | 17:28 |
| juliank | https://github.com/julian-klode/apt/commit/a789a9dfdab4898c343f34d9ded83574b85d6d44 | 17:28 |
| juliank | But it's kind of boring | 17:29 |
| jderose | pitti: on the surface, this feels like a systemd bug, but i don't have any solid evidence yet that it is in fact a systemd bug - https://bugs.launchpad.net/debian/+source/qemu/+bug/1630341 | 18:09 |
| ubottu | Launchpad bug 1630341 in qemu (Ubuntu) "yakkety: behavior change in `qemu-nbd -c $DEV $FILENAME`: doesn't automatically create partion devices" [Undecided,New] | 18:09 |
| nacc | mwhudson: fyi, i think i figured out the libwebp armhf failure. I found a reference to a similar failure earlier this year at: http://gcc.1065356.n8.nabble.com/distro-test-rebuild-using-GCC-6-td1224722.html#a1226791. Specifically the openal-soft_1:1.16.0-3 failure, which indicates that neon support is being built for, but not supported, etc. Do we want to have neon support (-mfpu=neon) in libwebp? I | 18:33 |
| nacc | have no idea, but based upon the gcc flags, I guess not? :) So we need to fix the logic to correctly detect that neon isn't actually supported by default? It seems like openal fixed this in CMakeLists.txt, but we aren't using cmake | 18:33 |
| nacc | mwhudson: ah perhaps as simple as --disable-neon in configure flags | 18:34 |
| slangasek | nacc: neon is optional on armv7, it is not part of our abi for armhf | 18:43 |
| slangasek | runtime detection of neon is ok but not hard enablement of it | 18:43 |
| sil2100 | bregma: hey! Silo 2020 (the unity8-desktop-session) - is that already tested and good to go? | 18:44 |
| bregma | sil2100, it's been waiting for ubuntu-terminal-app to get uploaded to xenial overlay | 18:46 |
| bregma | sil2100, that's been uploaded (as you say) let me test on my xenial machine | 18:48 |
| nacc | slangasek: right, but hard-disablement would be ok, right? | 18:49 |
| nacc | slangasek: as i'm not sure that i konw enough here to make neon be detected at runtime (and not sure libwebp supports that anyways) | 18:49 |
| nacc | slangasek: i know next to nothing about arm itself, so please cmiiw | 18:49 |
| slangasek | nacc: neon is the vector math instruction set; hard disabling it is like hard-disabling SSE or altivec in terms of its performance impact. But if runtime detection isn't supported in the code, hard-disabling is the right answer on armhf | 18:51 |
| nacc | slangasek: ok, i'll do some more digging to see what's possible | 18:51 |
| nacc | slangasek: regardless, the fix is found at least :) just need to decide which way to make the configure and build match :) | 18:52 |
| nacc | slangasek: ok, looks like there is a separate configure flag to enable runtime detection, testing that build now | 19:02 |
| slangasek | nacc: nice :) | 19:11 |
| pitti | sbeattie: ack, will upload it as an SRU then; thanks! | 19:28 |
| pitti | smoser: the Before= is right, it's just not very elegant | 19:28 |
| sbeattie | pitti: thank you! | 19:28 |
| smoser | pitti, shall ijust do that then ? | 19:28 |
| pitti | smoser: no objection, but I'll add a WI to the blueprint to review that for 17.04 | 19:30 |
| pitti | smoser: I think starting dbus earlier in the game is a better fix long-term, then you can remove this again | 19:30 |
| smoser | yeah. we should file bug/request upstream | 19:31 |
| pitti | right | 19:31 |
| pitti | smoser: sorry, what was teh bug # again? | 19:32 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797 | 19:33 |
| ubottu | Launchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,Triaged] | 19:33 |
| pitti | cheers | 19:33 |
| pitti | smoser: added to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver | 19:34 |
| smoser | anyone able to help me out ? | 20:05 |
| smoser | https://packages.qa.debian.org/p/python-json-patch.html | 20:05 |
| smoser | python json-patch in ubuntu and debian is at 1.19 | 20:06 |
| smoser | upstream https://github.com/stefankoegl/python-json-patch | 20:06 |
| smoser | or https://pypi.python.org/pypi/jsonpatch | 20:06 |
| smoser | seem to think the latest thing is 1.14 | 20:06 |
| smoser | am i just missing something ? | 20:06 |
| mwhudson | good morning | 20:12 |
| dobey | mwhudson: hi! | 20:17 |
| dobey | mwhudson: i have some questions about packaging of golang stuff. are you the best person to ask? | 20:18 |
| mwhudson | dobey: probably yes | 20:18 |
| dobey | mwhudson: i was looking at packaging the govendor tool, and it's not clear how to make a build use packaged golang libs, rather than the vendored bits, and how to keep it from installing the extra vendored bits to the system for others to use; curious if you know how i might be able to do that? | 20:20 |
| mwhudson | dobey: often what happens in debian seems to be repacking the orig to delete the vendored stuff | 20:20 |
| sbeattie | smoser: looks like perhaps the debian packager typoed 1.10 for 1.19? | 20:21 |
| sbeattie | err, verse vica | 20:21 |
| dobey | mwhudson: oh. yeah, i was hoping to avoid doing that. | 20:21 |
| mwhudson | dobey: override_dh_auto_configure:\n\trm -rf vendor? | 20:21 |
| mwhudson | well not exactly that i guess but ... | 20:21 |
| mwhudson | dobey: does govendor make releases or are you just grabbing things off github? | 20:22 |
| dobey | hmm, i figured that would result in debuild complaining about things. | 20:22 |
| sbeattie | smoser: especially given that unpacking the orig tarball gives files with the date of May 7, 2015, when 1.10 was released. | 20:23 |
| dobey | mwhudson: it has tags, so i presume there are releases, but i'm just working out of github tree for now (and would like to be able to set up recipe builds later) | 20:23 |
| smoser | sbeattie, but he had to work fairly hard on doing that. | 20:23 |
| smoser | $ tar tvf python-json-patch_1.19.orig.tar.xz | 20:23 |
| smoser | drwxrwxr-x root/root 0 2015-05-07 12:12 python-json-patch-1.19/ | 20:23 |
| mwhudson | you can do the repacking with the watch file, but i don't know how that interacts with getting things from git | 20:23 |
| dobey | hmm, ok | 20:25 |
| sbeattie | smoser: I agree, but diffing the 1.10 tarball from https://github.com/stefankoegl/python-json-patch/releases with the 1.19 orig tarball in the debian source gives no differences. | 20:27 |
| smoser | sbeattie, you're definitely correct | 20:28 |
| smoser | i'm just impressed as that took some determination to do | 20:28 |
| smoser | i filed bug | 20:28 |
| === adam_g` is now known as adam_g | ||
| === salem_ is now known as _salem | ||
| sil2100 | bregma: hey! How's 2020 testing going? | 22:09 |
| nacc | jgrimm: libwebp ftbfs fixed | 22:29 |
| jgrimm | cool | 22:29 |
| nacc | mwhudson: memcached's test failure. on a porter box, i don't see the issue in a chroot, but it's also using -j1, is it possible that the test fail to run parallely (I see the log has -j4) on armhf? | 22:41 |
| nacc | and, if so, is there a recommended way to indicate tests are not parallel? | 22:41 |
| nacc | doko_: --^ as well, although i expect you to not be available | 22:43 |
| mwhudson | nacc: was just talking to slangasek about that | 22:58 |
| mwhudson | nacc: it's almost certainly alignment being handled differently on the porter vs the builder | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
