/srv/irclogs.ubuntu.com/2016/10/03/#ubuntu-devel.txt

=== King_InuYasha is now known as Son_Goku
=== marcusto_ is now known as marcustomlinson
=== zigo is now known as Guest24756
=== Guest24756 is now known as zigo
Odd_BlokeI'm seeing (Python) socket.getaddrinfo calls which are unsuccessful (i.e. "socket.gaierror: [Errno -2] Name or service not known") take 25 seconds during boot (in cloud-init), where successful ones are near-instantaneous.  I'm not really sure how to proceed in working out what's going on; does anyone have any ideas?09:55
Odd_Bloke(More details of my investigation in https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797)09:55
ubottuLaunchpad bug 1629797 in cloud-init (Ubuntu) "cloud-init seems to take most of yakkety slow boot time" [Undecided,New]09:55
rbasakOdd_Bloke: any network interfaces configured at that point?10:33
rbasakOdd_Bloke: I wonder if the host is dropping DNS requests where on other hosts a "address unreachable" is returned immediately.10:34
rbasakIn which case perhaps the default or configured nameservers are wrong.10:35
Odd_Blokerbasak: So my assumption is that networking setup is somewhat sensible, because a successful query immediately after a failed one behaves as expected.10:40
Odd_Blokerbasak: How can I check what's configured?  Is /etc/resolv.conf canonical?10:40
rbasakOdd_Bloke: it's only roughly canonical. It might point to 127.0.0.1 or something, stuff may not use it (Python is likely to use it though) and processes have to explicitly reload after it changes (unless that has changed in the last few years).10:42
rbasakOdd_Bloke: could you perhaps arrange for a tcpdump to be running in the background from an early boot command? Not sure how that could hook in before an interface is up though.10:43
Odd_BlokeOK, so it looks like 127.0.0.53 is not in resolv.conf when this resolution is happening: http://paste.ubuntu.com/23269725/10:48
Odd_Bloke(127.0.0.53 being systemd-resolved)10:48
Odd_BlokeAnd a `systemd-analyze plot` does show systemd-resolved coming up after cloud-init completes; let's see if I can change that.10:52
rbasakIs that the real root cause though?11:02
rbasakIf it is 169.254.169.254 timing out, then why is that there?11:03
Laney@pilot in11:03
=== 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: Laney
* Laney quivers at the queue11:03
Odd_Blokerbasak: 169.254.169.254 is the metadata service in EC2 and GCE; that's returned by the DHCP server on GCE where I'm testing.11:06
Laney@pilot out11: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:
Laneywill do that in a minute...11:07
tsimonq2argh I missed a pilot /o\11:07
Odd_BlokeChecking what I see in resolv.conf on xenial (where this problem is not exhibited).11:07
tsimonq2Laney: you still around? can you still sponsor something?11:08
rbasakOdd_Bloke: OK, but either GCE should be responding to *all* DNS queries to that address promptly, or cloud-init and/or cloud images should not be configuring the system to send *all* DNS queries there, or cloud-init should arrange not to send generic DNS queries that will timeout there and also make sure the system also does not do so.11:08
Laneytsimonq2: 03/10 12:07:18 <Laney> will do that in a minute...11:08
tsimonq2Laney: oh that's what you meant, ok sorry11:08
rbasakOdd_Bloke: relying on systemd-resolved sounds like a crutch to me.11:09
Odd_Blokerbasak: So my hypothesis is that maybe on xenial DNS is configured system-wide to fail fast but on yakkety the assumption is that systemd-resolved will always be there, and systemd-resolved is configured to fail fast.11:09
rbasakOdd_Bloke: sure, I agree that sounds likely. I'm just saying that it doesn't sound like the root cause.11:09
Odd_BlokeSo I see just 169.254.169.254 in resolv.conf on xenial, where we don't have this issue.11:11
Odd_BlokeI'm not able to easily check that changing the ordering fixes the issue, because having cloud-init After systemd-resolved causes a dependency cycle.11:17
rbasakI would treat systemd-resolved as a red herring, and focus on finding out what DNS queries are timing out, why they are timing out, why the system is configured to make the queries even though they will time out, and how to get them to not time out despite or regardless of systemd-resolved.11:19
Odd_BlokeYeah, 127.0.0.53 is after 169.254.169.254 in /etc/resolv.conf, so I think I'm actually seeing fast failures from the same DNS server that seems to be giving slow ones during boot.11:21
=== hikiko is now known as hikiko|ln
Laneyok11:32
Laneytsimonq2: go go go11:32
Laney@pilot in11:32
=== 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: Laney
tsimonq2Laney: https://bugs.launchpad.net/ubuntu/+source/hardinfo/+bug/162960111:39
ubottuLaunchpad bug 1629601 in hardinfo (Ubuntu) "FTBFS due to build flags introduced in vivid" [High,In progress]11:39
tsimonq2that11:39
tsimonq2the only FTBFS left in the lubuntu packageset11:39
tsimonq2I have to go, be back in a few hours o/11:39
Odd_Blokerbasak: http://paste.ubuntu.com/23269859/ is the diff of nsswitch.conf between xenial and yakkety; it introduces "resolve" for hosts, which is provided by libnss-resolve: "nss module to resolve names via systemd-resolved".  Removing "resolve" fixes the boot time issue. \o/11:44
Odd_BlokeHmm, there's a new systemd package with changes to do with nss-resolve; let's see if that fixes this.11:47
Laneytsimonq2: that looks weird, but maybe?11:53
Laneyxnox: you had your fingerprints on that one ^, want to sponsor?11:53
tsimonq2Laney: Martin Pitt was gonna sponsor, but it seems he didn't get the time11:54
tsimonq2including him, there's a total of three acks11:55
tsimonq2it's just that nobody uploaded11:55
Laney:)11:55
tsimonq2if somebody could just upload already... ;)11:57
Laneyjust avoiding having to review it if someone else has :P11:57
Laneyif I have to I'll look11:57
tsimonq2well it has been reviewed11:57
tsimonq2not my changelog entry though :P11:58
tsimonq2ok I really have to go12:00
tsimonq2o/12:00
Odd_Blokepitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1629797 is severely affecting boot time of all cloud instances; would you be able to take a look (at least to confirm that my root-causing is correct)?12:09
ubottuLaunchpad bug 1629797 in systemd (Ubuntu) "resolve service in nsswitch.conf adds 25 seconds to failed lookups before systemd-resolved is up" [Undecided,New]12:09
=== hikiko|ln is now known as hikiko
rbasakOdd_Bloke: I still have the same opinion. That's not the root cause. The root cause is the *reason* the DNS requests are timing out, not that switching to systemd-resolved exposes it.12:33
rbasakAh12:34
rbasakYou might be saying that DNS requests aren't actually going out, because systemd-resolved is unavailable?12:35
Laneyjbicha: are you handling https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/899878 ?12:35
ubottuLaunchpad bug 899878 in software-center (Ubuntu Trusty) "Software center have hardcoded colors and shows white font on white bg" [Low,In progress]12:35
rbasakIn that case, yes, I guess that cloud-init needs to interact with nsswitch/systemd-resolved somehow to arrange for its queries to work.12:35
jbichaLaney: yes12:36
Laneyjbicha: ok, thanks, will unsubscribe sponsors then12:37
jbichaok12:37
Laneydone12:37
Odd_Blokerbasak: I think they're going out, but after the resolve service has spent a while waiting for resolved to appear (or something like that).12:47
rbasakOdd_Bloke: ironic given that one of the benefits of systemd-resolved is to consolidate timeouts!12:54
Odd_Bloke^_^13:10
=== _salem is now known as salem_
sakrecoerhi everyone, since the last member with upload rights left us a bit impromptu, ubuntu studio has been struggling with this FFe/UIFe https://bugs.launchpad.net/ubuntustudio/+bug/162469013:27
ubottuLaunchpad bug 1624690 in ubuntustudio-lightdm-theme (Ubuntu) "[UIFe/FFe] Please upload ubuntustudio-default-settings" [Undecided,New]13:27
sakrecoernow we finaly have all the pieces required, and i am wondering if anyone here could help us get this through before RC..13:28
lamontcjwatson: pitti: I am at a loss to understand how the open-iscsi test that is failing ever worked...13:31
lamontas best I can tell, it tries to install a deb that never gets built13:32
cjwatsonPass, I think that postdates my fiddling with it13:33
lamontwondering if you could throw the current xenial bits against an autopkgtest clone?  (as opposed to -proposed)13:34
Odd_Blokecjwatson: ISTR that in the past when we've needed a new kernel module in builders we've had to ask for it (because we can't modprobe).  Am I remembering correctly?13:42
cjwatsonOdd_Bloke: Correct, that's quite a complicated thing to do.  What's the requirement.13:43
cjwatson?13:43
Odd_Blokecjwatson: overlayfs.13:43
cjwatsonWe do it in lp:~canonical-sysadmins/canonical-is-charms/launchpad-buildd-image-modifier13:43
cjwatsonI think.13:44
cjwatsonDo you remember what the last one was?13:44
cjwatsonOh no, I remember, we do it in lp:launchpad-buildd.13:45
cjwatsonHackily.13:45
cjwatsonFeel free to propose a merge against that (debian/launchpad-buildd.init) and we can discuss it.13:46
Odd_Blokecjwatson: Will do; thanks!13:46
LStrangerhello there13:49
LStrangerI'm on concern of https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/1336521 - how to solve problem for users of Trusty and Xenial? I understand, next release could receive a fix soon, but many users use LTS releases, and that bug is important usability bug.13:53
ubottuLaunchpad bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed]13:53
rbasakstokachu: I've been asked to help you out with some upcoming Juju-related uploads. What do you need, exactly?14:01
stokachurbasak: nothing at this moment14:03
stokachuwaiting to hear back from juju qa14:03
rbasakstokachu: ah, OK. I'll wait for a ping from you then - thanks.14:04
stokachuthanks, you should also have a email i cc'd you on14:04
rbasakReceived, thanks. That was helpful in giving me the background but it wasn't clear to me if that implied that I was supposed to do something or not. Thank you for clarifying :)14:05
stokachu:) np14:05
willcookedoko_, hey.  Can you tell me if this is in good enough state to be reviewed... https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1625074    If not, I will chase people to get whatever is needed done14:16
ubottuLaunchpad bug 1625074 in ubuntu-terminal-app (Ubuntu) "[MIR] ubuntu-terminal-app" [High,Incomplete]14:16
stokachurbasak: referring to recent juju email, is it better to wait for yakkety (or newer) to contain the proper logic for handling 32bit packages in xenial? or since its a packaging issue we can upload yakkety as is and handle the logic in xenial seperately?15:05
rbasakstokachu: that's probably a question for the SRU team member who'll be accepting this into Xenial. AIUI, the usual "must be in the development release first" requirement is solely to prevent future user-visible regressions on release upgrades. I'm not sure I follow whether that rationale would be impacted in this case.15:14
Laney@pilot out15:14
=== 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:
stokachurbasak: yea im not sure either, but if it was me I would want it in yakkety before pulling it into xenial15:19
stokachuslangasek: question for you when you're available15:20
slangasekstokachu: hullo15:20
stokachuslangasek: o/, so background: juju is dropping 32bit support in yakkety which they want to also drop in xenial15:21
slangasekstokachu: I don't care about having the juju 32-bit-package-removal package glue in yakkety, provided this gets done before yakkety release15:21
stokachudo i ask that they put that xenial logic in yakkety berore uploading?15:21
slangasekand provided you think the SRU process gives you adequate testing15:21
stokachuslangasek: for me I would feel better that they glue was in there before I do another upload to yakkety15:22
stokachui'd like to have all the unknowns worked out without having to do multiple yakkety uploads15:22
slangasekstokachu: well, for yakkety you can just drop the 32-bit builds completely15:22
slangasekand it's appropriate to then have them added to the 'obsolete packages' list in update-manager so that do-release-upgrade will remove them for you on upgrade to yakkety, just in case15:23
stokachuok15:24
stokachuso they've completed the dropping of 32bit packages, ill make sure it gets added to obsolte packages in update-manager15:26
stokachuthen work with them to handle the logic in xenial15:26
=== mfisch` is now known as mfisch
=== mfisch is now known as Guest7223
=== Guest7223 is now known as mfisch
naccrbasak: i had an idea this morning for how to integrate MRs into the git workflow -- if you're around, I'd like to bounce them off of you16:35
naccjgrimm: fyi, now that python-oslo.privsep's MIR has been approved (LP: #1616764), cinder, nova, nova-lxd should all migrate and drop off the ftbfs list16:59
ubottuLaunchpad bug 1616764 in python-oslo.privsep (Ubuntu) "[MIR] python-oslo.privsep" [High,Fix committed] https://launchpad.net/bugs/161676416:59
jgrimmnacc, cool cool16:59
nacccoreycb: i assume you saw that python-taskflow grew a (new?) dep on python-pydotplus which is in universe?16:59
nacccoreycb: so it's stuck in -proposed16:59
coreycbnacc, <insert bad word>  I'll take a look, thanks :)17:00
nacccoreycb: thanks!17:00
coreycbnacc, I was going to take a pass through our stuck in proposed today anyway, so off I go to do that17:01
nacccoreycb: 2x thanks then :)17:01
coreycb:)17:01
coreycbxnox, have any tips for getting an s390 machine to test out autopkgtest changes?18:34
nacccoreycb: cpaelzer may be able to help, when he's back online, too19:06
naccjgrimm: --^19:06
coreycbnacc, thanks that would be great19:22
=== 7ITAAO17J is now known as pfsmorigo
nacccoreycb: let me look if it's documented anywhere20:07
coreycbnacc, thanks, and if not,  I can follow up tomorrow20:10
naccpowersj: --^ or maybe you know?20:12
ngaioOn today's (and previous) daily images I'm running into an infinite loop with glxinfo such that no desktop shows on login. Which package should I report this against so it has a fighting chance of being fixed by release?20:22
dobeyngaio: final freeze is in two days, so unless you have a patch already, i wouldn't get hopes too high of it being fixed20:38
dobeyngaio: but probably should be filed against whatever package provides glxinfo, or your drivers.20:39
xnoxcoreycb, if you are a coredev go to https://bileto.ubuntu.com/ create a ppa, upload, and it will be built & tested on s390x.20:42
xnoxcoreycb, or open a bugreport with debdiffs/things to look into20:42
slangasekxnox: hmm, that seems like the wrong acl, nah?  should be open to all ubuntu-dev, not just core-dev :)20:42
ngaiodobey, running an Nvidia Quadro 1000M here (2011 era), and given it's from the live CD it must be using the free drivers20:43
ngaiodobey, so you suggest I file it against nouveau?20:43
xnoxslangasek, enoclue. I think any can create the ppa, but a core-dev is needed to dput in any _source.changes.20:47
dobeyngaio: sounds reasonable, yes20:47
xnoxslangasek, if building from "source packages" rather than branches.20:47
xnoxbut maybe that has been changed.20:47
ngaiodobey, thank you20:47
dobeyxnox: doesn't need to be a coredev, but it's currently only coredevs and trainguards that can upload directly to silo PPAs20:48
xnoxack.20:48
xnoxcoreycb, i'm happy to sponsor things into a silo =)20:49
dobeyand you need to be in some other group to create requests on bileto20:49
robrudobey: xnox: core dev can do anything20:50
slangasekxnox: ahh right, hmm I wonder if all of ubuntu-dev should be allowed there or not... probably so but we might have to check for assumptions20:52
xnoxslangasek, not until launchpad ppa copies with new binaries end up in new queue.....20:53
slangasekxnox: right, that20:53
dobeyrobru: right; was just clarifying that it's not only core devs that can do what was requested.20:53
robruslangasek: also not until we get some kind of ACLs to that tickets aren't world-writable20:53
slangasekxnox: otoh new binaries == packaging diff; the acl for upload to ppa doesn't have to match the acl for publishing20:53
slangasekrobru: I don't see a clear reason why we should trust ubuntu-core-dev with write access to tickets, but not ubuntu-dev?20:53
robruslangasek: because ubuntu-dev is an order of magnitude larger than ubuntu-core-dev? (isn't it?)20:54
dobeyrobru: but why does that matter?20:54
slangasekrobru: it is, but the only trust boundary here is about which /particular/ packages they're trusted to upload to the Ubuntu archive20:55
robrudobey: because anybody who can access bileto can edit all tickets? the more people that is the more we have to trust all of them20:55
dobeyrobru: well you're already trusting them by running the software they uploaded to the archive, i guess? :)20:56
robruslangasek: so you're saying you're fine with all of ~ubuntu-dev having write access to all tickets? I've been worried about the security of this for awhile...20:56
slangasekrobru: I'm saying I'm equally ok with ubuntu-dev and ubuntu-core-dev having access; I may be missing the nuances of why the write access is a problem, but if it's a problem for ubuntu-dev I think it's a problem also for ubuntu-core-dev :)20:56
slangasekbecause the average ubuntu-core-dev is no more in touch with bileto process than the average ubuntu-dev20:57
dobeyrobru: i mean, they can just straight skip ci train and upload to the archive without any problem20:57
robruslangasek: I guess I'm just not very familiar with what ubuntu-dev is but just in general the more people who have write access to bileto the more worried about it's insecurity I become.20:57
dobeyit's too bad each silo ppa can't reasonably be owned by a different team20:58
robrudobey: yes that's a feature I've had on my mind for a while.20:58
slangasekcoreycb: why does nova-lxd not have autopkgtests?20:58
dobeyrobru: can you not make tickets themselves only be writable by the creator of the ticket and any additional people in the irc nicks field?20:59
dobeyrobru: maybe make that field be launchpad usernames instead of irc nicks?20:59
robrudobey: no, because irc nicks can be trivially spoofed. I need to add a field in the db for team ownership of the ticket.21:00
dobeyrobru: sure, but i mean if they were validated as usernames against lp, and only those people could modify the ticket (and thus add more usernames), that seems like it would be a "decent enough" ACL implementation21:01
slangasekxnox: robru has reminded me that if you can put to bileto, you can make changes to the *upstream* source and push it to the archive without bileto saying boo; so yeah, the more restrictive acl seems necessary21:02
dobeyrobru: you could even steal the little ajax widget to search for people on launchpad :)21:02
robrudobey: I'd rather not change the semantics of the irc nicks field because that field is currently only used to ping people in the #ubuntu-ci-eng channel and changing those from irc nicks to lp names would break irc pings for a lot of people21:03
dobeyrobru: oh ok. well another field then, and auto-fill irc nicks from the LP info :)21:03
jbicharobru: LP has an IRC field?21:04
robrujbicha: yes, in your account you can list your IRC nicks on various networks, but it's just a string field and anybody can put anything there. bileto checks for freenode nicks of ticket creators and records that in the ticket, it's purely for notification purposes, as it is trivially spoofed21:04
robrujbicha: https://launchpad.net/~jbicha yours is listed for irc.ubuntu.com21:05
jbicharight21:05
dobeyrobru: i guess you'll have to port queuebot to telegram, and send message to people there. irc is old and busted21:07
robrudobey: sigh, yes.21:07
nacccaribou: can you give me some context for the dependency of clamav on llvm-3.6 (as opposed to 3.8 (which i think is what llvm-dev is currently pointing to) or 3.9)?21:09
nacccaribou: i'm asking because llvm-toolchain-3.6 ftbfs in y (testcase failures), and the only reason its in main is clamav21:16
=== imcleod is now known as imcleod-afk
cjwatsondobey,robru: Now that landing PPAs are ephemeral, I think you could probably reasonably use Archive.newComponentUploader or something to grant upload access to the landers of each individual ticket.22:11
cjwatson(Though only if you knew the landers' Launchpad usernames.)22:11
robrucjwatson: would that work for teams?22:12
cjwatsonSure22:12
cjwatsonYou'd probably still want the option to have more than one person-or-team though22:13
robrucjwatson: so newComponentUploader grants upload rights to a person or team on just one archive without adding that team as a member of the ppa-owning team?22:13
robrucjwatson: i wasn't aware it was possible to have upload rights to a ppa without being a member of the owning team22:15
cjwatsonrobru: Right, it's an obscure API-only feature but it works fine.22:18
robrucjwatson: thanks, I'll note that down so i don't forget22:18
cjwatsonThe component will have to be 'main', of course.  (Or equivalently you can use newPocketUploader with pocket='Release'.)22:19
cjwatsonSince it's obscure and API-only it hasn't been polished much, hence the slightly weird options :)22:19
cjwatsonI never suggested it for non-ephemeral landing PPAs because it doesn't show up in the web UI so added uploaders would be liable to be forgotten about.22:20
slangasekwow :)22:26
robruAh22:27
tsimonq2ooh new Kubuntu dev :D22:28
bdmurrayxnox: Have you had a chance to retest bug 1620525?22:50
ubottubug 1620525 in linux (Ubuntu Yakkety) "sbuild with overlayfs fails in yakkety" [Critical,Triaged] https://launchpad.net/bugs/162052522:50
xnoxi switched to unionfs =)22:52
xnoxlet's see.22:52
xnoxbdmurray, i think it works now on xenial.22:54
xnoxwill retest with a yakkety kernel on yakkety too.22:54
bdmurrayxnox: thanks22:54
LStrangerOh, some people woke up so may be I can get some answer. :) I'm on concern of https://bugs.launchpad.net/ubuntu/+source/openbox/+bug/1336521 - how to solve problem for users of Trusty and Xenial? I understand, next release could receive a fix soon, but many users use LTS releases, and that bug is important usability bug.22:58
ubottuLaunchpad bug 1336521 in pcmanfm (Ubuntu) "Application Startup Notify fully ignored" [Undecided,Confirmed]22:58
LStrangerMaintainer in Debian promiced to push update into sid and stable soon but as for Ubuntu I have no idea whom to ask about LTS updates.23:00
bdmurrayIs there a related debian bug report?23:01
sarnoldLStranger: best would be to take a fix from the debian developer, prepare a debdiff for the ubuntu packages, build them locally, make sure it works, then post the debdiff to the bug and ask a sponsor to build it for everyone23:02
LStrangerYes, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838326 is it.23:02
ubottuDebian bug 838326 in openbox "Openbox does not support startup notifications." [Important,Open]23:02
xnoxbdmurray, yakkety is bad23:04
xnoxwait i might be wrong23:04
LStrangerIn fact, I rebuilt the package for Trusty and use it, so I'm positive it works, and it should so for Xenial, not checked it yet but relevant place in Openbox haven't changed. I'll check it, sure, tomorrow I think.23:06
bdmurrayLStranger: you might have a look at the following wiki page https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.  Specifically, a test case would be helpful.23:07
LStrangerbdmurray: oh, thank you, will do.23:08
xnoxbdmurray, all is good on yakkety too.23:17
coreycbslangasek, I agree nova-lxd needs autopkgtests.  we're planning to put some focus on improving autopkgtests next for all openstack core packages next cycle.23:39
slangasekcoreycb: ok, great :)23:40
coreycbxnox, awesome thanks I'll try that out tomorrow23:40

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!