=== salem_ is now known as _salem
=== sysop is now known as Guest93467
=== JanC_ is now known as JanC
[06:10] <pitti> Good morning
[06:11] <pitti> Odd_Bloke: 1629797> queue, will reply there
[06:12] <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:13] <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:14] <pitti> cyphermox: https://launchpad.net/ubuntu/+source/open-iscsi/2.0.873+git0.3b4b4500-14ubuntu5 → please let's not do that
[06:15] <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:16] <didrocks> yeah, a nice rest after an intense week I guess ;)
[06:31] <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:32] <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:38] <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:39] <dholbach> good morning
[07:07] <dholbach> @pilot in
=== 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
[07:08] <dholbach> looks like the topic is a bit long
[07:12] <slangasek> s/(16.10 )// ? :)
[07:13] <ginggs> reverse-depends/seeded-in-ubuntu are working again, can remove that
[07:18] <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:19] <pitti> Mirv: no known one -- did you get a confirmation page that the request was sent?
[07:22] <Mirv> pitti: yes
[07:23] <Mirv> http://people.ubuntu.com/~timo-jyrinki/autopkgtest.png
[07:27] <pitti> Mirv: ack, I'll have a look
[07:37] <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:38] <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:39] <pitti> it's even marked with "XXX fix this hack"
[07:54] <cpaelzer> pitti: thanks for your explanation on the netplan bug, I replied and forwarded to IBM if they really need anything
[07:55] <pitti> hey cpaelzer, guten Morgen!
[07:56] <cpaelzer> pitti: hallöchen
[07:57] <cpaelzer> my good morning today was creating an emergency GBE-over-luster-terminal fix so I skipped any good morning feelings :-/
[08:06] <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?
=== 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
[08:16] <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:17] <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:18] <pitti> Mirv: it actually wasn't visible in the queue -- that's part of the bug
[08:18] <Mirv> ok
[08:21] <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:23] <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:24] <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:30] <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:46] <sil2100> xnox: hey!
[08:46] <sil2100> xnox: do you feel you're a good person to do an upstart merge-proposal review? ;)
[08:47] <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
[09:03] <xnox> sil2100, ..... ok
[09:06] <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:10] <jbicha> LocutusOfBorg: maybe it's https://github.com/opencog/link-grammar/issues/437
[09:11] <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:15] <xnox> sil2100, it seems like it is implementing systemd-escape for the unit names the right way?
[09:32] <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:47] <caribou> nacc: looking at it, maybe I can figure out how to build with the latest llvm
[09:49] <Mirv> thank you
=== zigo is now known as Guest84780
=== hikiko is now known as hikiko|ln
[10:44] <sil2100> xnox: it's for the upstart-local-bridge basically
[10:44] <sil2100> xnox: could you take a look at it and review?
[10:45] <sil2100> We need this to land to get the systemd xenial phone switch happening
[10:56] <caribou> nacc: well, looks like debian is still building with llvm-3.6 and building with 3.7 will require sensible code change :
[10:57] <caribou> nacc: https://www.mail-archive.com/pkg-clamav-devel@lists.alioth.debian.org/msg04458.html
=== 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
[12:27] <dholbach> @pilot out
=== 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:
[12:50] <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:51] <pitti> Mirv: oh, it's a per-timestamp file, I suppose we want the latest one
[12:52] <pitti> ah, from https://bileto.ubuntu.com/#/ticket/2035
[13:04] <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:15] <pitti> Odd_Bloke: I followed up on the bug; the root cause is clear, but how to fix it (cleanly) totally isn't
[13:16] <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:17] <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:18] <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:19] <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:20] <Odd_Bloke> pitti: Cool. :)
[13:20] <pitti> oh cool, this actually works
[13:23] <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:24] <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:25] <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:26] <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:40] <infinity> xnox: Hey you, upload your staged yakkety d-i changes.
[13:40] <xnox> infinity, yo, it's in unapproved queue
[13:41] <infinity> xnox: Oh, indeed, an hour ago.  Kay.
[13:50] <Laney> hi ximion
[13:50] <Laney> fun, reproducible?
[13:51] <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:52] <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:53] <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:54] <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
=== alexisb is now known as alexisb-afk
[13:57] <jbicha> have we hit the language pack translation deadline for yakkety final yet?
[14:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <rharper> still seems obtuse
[14:09] <smoser> right
[14:10] <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:11] <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:12] <Laney> not with ldc
[14:14] <smoser> Odd_Bloke, thanks for the bug pointer
[14:15] <smoser> it just seems so hacky and randomly specific
[14:18] <rharper> the Before=dbus.socket works on my openstack instance where it was hanging
[14:20] <Odd_Bloke> Yeah, I've confirmed it works on GCE and EC2.
[14:28] <xnox> robru, when i say yakkety+xenial as target, does it mean Ubuntu Archive for both?
[14:40] <pitti> smoser: yes, around, just slowly responding due to too many parallel pings
[14:41] <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:42] <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:43] <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:44] <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:45] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <pitti> if resolved isn't running, it fails fast and punts to "dns"
[14:51] <pitti> it == nss module
[14:52] <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:55] <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:56] <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  ... ?
[15:01] <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:03] <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:04] <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:11] <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:33] <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:34] <bdmurray> sergiusens: I'm not sure I am following your response.
[15:36] <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:37] <bdmurray> sergiusens: got it
[15:40] <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:41] <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:59] <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
=== imcleod-afk is now known as imcleod
[16:09] <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:17] <xnox> robru, =(
[16:18] <robru> xnox: if you really need to do a xenial sru you can just copy from xenial overlay after publishing
[16:22] <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:23] <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:24] <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:25] <robru> slangasek: it's been on my mind for a while to allow specifying such special cases, but low priority
[16:33] <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:34] <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:35] <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:36] <robru> xnox: are you wanting to land one mp to yakkety and xenial or are you planning on doing source uploads?
[16:37] <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?
=== alexisb-afk is now known as alexisb
[16:38] <coreycb> robru, https://bileto.ubuntu.com/#/ticket/2042
[16:39] <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:40] <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:41] <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:42] <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:49] <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:51] <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:52] <slangasek> coreycb: thanks
[16:55] <bdmurray> happyaron: Your upload of fcitx in the xenial-proposed queue is missing the Launchpad-Bugs-Fixed line.
[17:02] <jbicha> bdmurray: I suggest emailing happya_ron since I believe he's out this week
[17:03] <Laney> Probably easier to reupload for him
[17:06] <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:26] <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:28] <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:29] <juliank> But it's kind of boring
[18:09] <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:33] <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:34] <nacc> mwhudson: ah perhaps as simple as --disable-neon in configure flags
[18:43] <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:44] <sil2100> bregma: hey! Silo 2020 (the unity8-desktop-session) - is that already tested and good to go?
[18:46] <bregma> sil2100, it's been waiting for ubuntu-terminal-app to get uploaded to xenial overlay
[18:48] <bregma> sil2100, that's been uploaded (as you say) let me test on my xenial machine
[18:49] <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:51] <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:52] <nacc> slangasek: regardless, the fix is found at least :) just need to decide which way to make the configure and build match :)
[19:02] <nacc> slangasek: ok, looks like there is a separate configure flag to enable runtime detection, testing that build now
[19:11] <slangasek> nacc: nice :)
[19:28] <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:30] <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:31] <smoser> yeah. we should file bug/request upstream
[19:31] <pitti> right
[19:32] <pitti> smoser: sorry, what was teh bug # again?
[19:33] <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:34] <pitti> smoser: added to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver
[20:05] <smoser> anyone able to help me out ?
[20:05] <smoser> https://packages.qa.debian.org/p/python-json-patch.html
[20:06] <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:12] <mwhudson> good morning
[20:17] <dobey> mwhudson: hi!
[20:18] <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:20] <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:21] <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:22] <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:23] <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:25] <dobey> hmm, ok
[20:27] <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:28] <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
=== adam_g` is now known as adam_g
=== salem_ is now known as _salem
[22:09] <sil2100> bregma: hey! How's 2020 testing going?
[22:29] <nacc> jgrimm: libwebp ftbfs fixed
[22:29] <jgrimm> cool
[22:41] <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:43] <nacc> doko_: --^ as well, although i expect you to not be available
[22:58] <mwhudson> nacc: was just talking to slangasek about that
[22:59] <mwhudson> nacc: it's almost certainly alignment being handled differently on the porter vs the builder