[00:11] <Anja> does anyone have any idea how Qt finds its default theme on ubuntu?
=== JanC is now known as Guest54043
=== JanC_ is now known as JanC
=== JanC is now known as Guest26650
=== JanC_ is now known as JanC
=== _salem is now known as salem_
=== salem_ is now known as _salem
[05:47] <pitti> Good morning
[06:01] <pitti> mwhudson: do you have an idea about the uninstallability in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/d/docker.io/20161010_031813@/log.gz ?
[06:21] <Mirv> doko: oSoMoN: cjwatson: re bug #1630906 the upstream fix seems to start segfaults on armhf and i386, even if it fixes arm64. those autopkgtest runs have it consistent. could only CONFIG_ARM64_VA_BITS=48 be reverted in kernel 4.4?
[06:21] <ubottu> bug 1630906 in linux (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,Confirmed] https://launchpad.net/bugs/1630906
[06:34] <pishuilu> Hi,all. Who can help to upload ubiquity-slideshow pacakge to ubuntu. The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html. Thanks!
[06:40] <pitti> wgrant, cjwatson: the arm64 buildds seem to have some troubles?
[06:41] <wgrant> pitti: A bit. Investigation is underway.
[06:41] <pitti> ack, thanks
[06:41] <wgrant> pitti: But the queue is pretty clear, so I don't think it should be blocking anything?
[06:41] <wgrant> Unless I've missed something.
[06:41] <pitti> wgrant: no, it's not, I just noticed
[06:42] <pitti> wgrant: if there are some nagios/alarm bells on those, I'll stop shouting in the future
[06:42] <wgrant> pitti: We've turned off automated gardening so we can assess the remaining failure modes manually.
[06:42] <pitti> wgrant: yours are also running under 4.8 or the fixed 4.4.23 now?
[06:42] <wgrant> Since they're no longer falling over at an incredible rate with an impossible to diagnose failure.
[06:42] <wgrant> pitti: Same as yours.
[06:42] <pitti> wgrant: they both work wonderfully for my instances
[06:42] <wgrant> Right, these don't appear to be kernel issues.
[06:43] <wgrant> More general OpenStack ones.
[07:10] <mwhudson> pitti: no
[07:10] <mwhudson> pitti: i was trying to repro locally and failing
[07:10] <mwhudson> but i think my mirror was out of date
[07:13] <mwhudson> GRARARARRA "tar: Unexpected EOF in archive"
[07:34] <LocutusOfBorg> good morning folks, question:
[07:34] <LocutusOfBorg> src:daemontools has an ubuntu delta
[07:35] <LocutusOfBorg>   * Merge with debian, remaining diff:
[07:35] <LocutusOfBorg>     - add upstartification
[07:35] <LocutusOfBorg>   * Fix upstart job as not in event.d anymore (LP: #688054)
[07:35] <ubottu> Launchpad bug 688054 in daemontools (Ubuntu) "svscan is not started when the package is installed" [Undecided,Fix released] https://launchpad.net/bugs/688054
[07:35] <LocutusOfBorg> can we drop it on next debian upload?
[07:40] <pitti> LocutusOfBorg: yes, I suppose so
=== s1aden is now known as sladen
[07:46] <mwhudson> pitti: where did you suspect the tar: Unexpected EOF in archive problem was coming from again?
[07:47] <pitti> mwhudson: I suspect some bug/race condition in qemu's 9p
[07:47] <mwhudson> pitti: is there somewhere i can put a sleep or something to try to confirm/ameliorate?
[07:48] <pitti> mwhudson: no, I already tried to put sleeps, syncs etc. everywhere, didn't help
[07:48] <pitti> well, "everywhere" → I might have missed something of course
[07:48] <mwhudson> pitti: i'm getting the problem like 80% of the time
[07:49] <mwhudson> pitti: i'm wondering if it would be less painful to set up devstack and use --- nova or something :(
[07:49] <pitti> mwhudson: you could actually use ssh too
[07:49] <pitti> mwhudson: i. e. start the autopkgtest-yakkety-something.img in qemu (with -snapshot), install your ssh key, and then use the ssh runner
[07:57] <LocutusOfBorg> thanks pitti
[08:11] <mwhudson> pitti: so this command passed for me: autopkgtest -d --shell --test=docker-in-lxd -B --apt-pocket=proposed=src:docker.io --apt-upgrade docker.io --- qemu ~/adt-yakkety-amd64-cloud.img
[08:11] <mwhudson> (eventually)
[08:11] <mwhudson> pitti: can you see how that would differ from prod infrastructure?
[08:12] <pitti> mwhudson: not really, uninstallability doesn't sound like a proxy issue; I'll retry the tests, and if it still fails run it manually on the infra
[08:12] <mwhudson> pitti: thanks
[08:13] <pitti> although the last test only ran ~ 10 hours ago
[08:13] <pitti> no, ~ 5 hours
[08:13] <mwhudson> yeah
[08:13]  * pitti runs it manually right away
[08:13] <pitti> mwhudson: --test is --testname I presume
[08:14] <mwhudson> pitti: uh, that was the command i ran
[08:14] <mwhudson> i suppose it gets expanded to --testname, yeah
[08:14] <mwhudson> pitti: but running all the tests makes sense i guess
[08:14] <mwhudson> (the other one has been passing)
[08:15] <pitti> mwhudson: also, this install failure is in the lxc container, not outside
[08:15] <mwhudson> pitti: yes
[08:15] <mwhudson> i copy /etc/apt from outside to container
[08:16] <mwhudson> which is a hack, i guess,  but it works on my machine (tm) :)
[08:18] <pitti> mwhudson: I have the failure in a running instance now
[08:19] <mwhudson> pitti: can you coerce it into explaining why the uninstallable things are uninstallable?
[08:19] <pitti> mwhudson: oh, it deletes the container after the failed test, it seems
[08:19] <mwhudson> oh ups, yes it would i guess
[08:19] <mwhudson> still you should be able to re-make it
[08:20] <mwhudson> pitti: comment out defer 'lxc delete --force docker' and run debian/tests/docker-in-lxd by hand?
[08:21] <pitti> running
[08:21] <pitti> mwhudson: OOI, why does this need root?
[08:22] <mwhudson> pitti: configuring lxd requires root i think
[08:22] <pitti> E: Package 'containerd' has no installation candidate
[08:22] <pitti> E: Package 'runc' has no installation candidate
[08:22] <pitti> E: Package 'cgroupfs-mount' has no installation candidate
[08:22] <pitti> E: Package 'cgroup-lite' has no installation candidate
[08:22] <pitti> E: Package 'ubuntu-fan' has no installation candidate
[08:23] <mwhudson> pitti: that doesn't make any sense on the face of it
[08:23] <pitti> Get:9 http://ftpmaster.internal/ubuntu yakkety/universe amd64 Packages [7736 kB]
[08:23] <pitti> it does download the universe Packages, hmm
[08:24] <pitti> and I see it in /var/lib/apt/lists/ftpmaster.internal_ubuntu_dists_yakkety_universe_binary-amd64_Packages
[08:24] <mwhudson> maybe the preferences/pinning are screwed up?
[08:25] <pitti> and running apt update again then works
[08:25] <mwhudson> pitti: you ran apt update and then the install worked?
[08:26] <pitti> yes (in the container)
[08:26] <pitti> but it already ran update before
[08:27] <mwhudson> errrr
[08:28] <pitti> err, WTH
[08:28] <mwhudson> pitti: maybe deleting /var/lib/apt/lists/* before the first update?
[08:28] <pitti> mwhudson: I duplicated the apt update call now, and look what I see: http://paste.ubuntu.com/23302146/
[08:28] <mwhudson> pitti: just total guessing though
[08:28] <pitti> mwhudson: so the second time switches away from ftpmaster.interla
[08:28] <mwhudson> whuh
[08:29] <pitti> infra runs with --mirror=http://ftpmaster.internal/ubuntu
[08:29] <pitti> so it's like sources.list gets changed after the first apt update run
[08:29] <pitti> mwhudson: could that be cloud-init running in the background?
[08:30] <pitti> mwhudson: changing mirror in sources.list underneath would totally explain it
[08:30] <mwhudson> pitti: ... i ... suppose ... so?
[08:31] <mwhudson> pitti: cloud init logs have anything?
[08:31] <mwhudson> in the container i mean
[08:32] <pitti> mwhudson: do you really need ubuntu-daily:yakkety, or would images:ubuntu/yakkety/amd64/ suffice?
[08:32] <pitti> mwhudson: just running it again to check c-i logs
[08:32] <mwhudson> pitti: i imagine the images: would be fine yeah
[08:32] <pitti> # cat /etc/apt/sources.list
[08:32] <pitti> ## Note, this file is written by cloud-init on first boot of an instance
[08:32] <pitti> and it has archive.u.c.
[08:32] <mwhudson> pitti: hnnngh
[08:32] <pitti> but I think you copy in the host's /etc/apt/sources.list, which has ftpmaster.internal
[08:32] <mwhudson> pitti: yeah i did
[08:33] <mwhudson> pitti: i guess i could sleep for 60s before doing that but ...
[08:33] <pitti> Oct 10 08:32:05 docker [CLOUDINIT] handlers.py[DEBUG]: finish: modules-final: SUCCESS: running modules for final
[08:33] <pitti> mwhudson: nah -- if you wait, then poll for /var/lib/cloud/instance/boot-finished
[08:33] <mwhudson> or use the images: image which doesn't have cloud-init?
[08:33] <pitti> mwhudson: right; let me check that here
[08:34] <mwhudson> pitti: however, does this explain the actual failure?
[08:34] <pitti> mwhudson: yes, totally
[08:34] <mwhudson> ok :)
[08:34] <pitti> mwhudson: apt update ran against ftpmaster.internal, then cloud-init finishes in the middle and changes sources.list to archive.u.c.
[08:34] <pitti> for which apt has no data
[08:34] <mwhudson> oh right
[08:35] <mwhudson> i'm sure glad i didn't spend any more time figuring this out because i would never ever have figured it out on my own :)
[08:35] <pitti> mwhudson: images: is only half as big, and has a lot less crap pre-installed, so you actually have a stronger test that docker.io's dependencies are correct
[08:35] <pitti> #lxc launch ubuntu-daily:${suite} docker -p default -p docker
[08:35] <pitti> lxc launch images:ubuntu/${suite}/amd64 docker -p default -p docker
[08:35] <pitti> works fine
[08:36] <pitti> mwhudson: I suppose you want to use `dpkg --print-architecture`
[08:36] <mwhudson> ah yes
[08:36] <pitti> mwhudson: so in between poling for boot-finished and using images: I'd actually tend towards the latter, but your choice
[08:36] <mwhudson> me too
[08:37] <pitti> mwhudson: can you upload this, and I'll review/handhold through the queues?
[08:37] <pitti> what a fun bug :)
[08:37] <mwhudson> sure
[08:37] <pitti> mwhudson: thanks!
[08:40] <mwhudson> -0ubuntu15, man
[08:41] <pitti> mwhudson: getting closer to hitting the biggest natural number?
[08:41] <mwhudson> pitti: but somehow staying the same distance away
[08:46] <brendand> pitti, hey - are you aware of the issue with overlayfs that impacted autopkgtest (at least when using a qemu runner), recently?
[08:46] <pitti> brendand: no, I'm not (works fine locally), what was that about?
[08:47] <brendand> pitti, i'm right in thinking that the qemu test runner uses an overlayfs?
[08:48] <pitti> brendand: no, it uses qemu-img overlay
[08:48] <pitti> overlayfs is too brittle
[08:48] <brendand> hmm
[08:49] <pitti> doko: any objections to removing gnat-4.9? it got removed in Debian, only rdepends is spark which I'm rebuilding against libgnat-6
[08:49] <pitti> doko: (I'm currently running process-removals)
[08:49] <brendand> that was a wrong assumption then
=== stokachu_ is now known as stokachu
=== nobuto_ is now known as nobuto
[08:55] <pitti> doko: Debian also removed gcc-4.9, but this has rdepends still: gcc-4.8 (dep gcc-4.9-base, curiously) and gcc-4.9-cross; I suppose at least the latter could also be dropped?
=== ejat_ is now known as ejat
=== Ursinha_ is now known as Ursinha
=== Guest10079 is now known as zigo
[09:26] <doko> pitti: we don't have to remove it now ...
[09:27] <pitti> doko: no, not "have to", I just thought some cleanup before releasing can't hurt (I left gcc-4.9)
=== SotK_ is now known as SotK
=== shadeslayer_ is now known as shadeslayer
[10:44] <pitti> mwhudson: green ♥ : http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#docker.io
=== tsimonq2alt is now known as tsimonq2
=== hikiko is now known as hikiko|ln
[11:24] <pishuilu>  cyphermox: Hi, can you help to upload ubiquity-slideshow pacakge to ubuntu? The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html
[11:49] <cjwatson> Mirv: This is a thing you'd have to talk to the kernel team about
[11:50] <cjwatson> Mirv: #ubuntu-kernel maybe?
=== hikiko|ln is now known as hikiko
[12:27] <pishuilu> Hi,all. Who can help to upload ubiquity-slideshow pacakge to ubuntu. The url is https://code.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html. Thanks!
[12:51] <pitti> chrisccoulson: are you aware of the firefox and thunderbird FTBFSes? (stuck in -proposed for a while)
[12:58] <pitti> doko, jbicha: you synced debtags, but the Debian version drops python-debtagshw and python3-debtagshw -- do you know whether there's a replalcement? (software-center and ti-omap4-software-channel
[12:58] <pitti> ... depend on those)
[12:59] <pitti> willcooke, seb128: ^ is software-center actually still a thing? or should this get removed now, in favor of gnome-software?
[12:59] <pitti> one reverse-depends (ti-omap4-software-channel, looks obsolete too) and oneconf recommends it (can be ignored)
[13:00] <pitti> ogra_: do you know, do we actually want to keep ti-omap4-software-channel ?
[13:00] <willcooke> pitti, seb128 -  I think it can probably go now from X onwards
[13:00] <pitti> willcooke: yes, only talking about y here
[13:00] <seb128> I would keep it
[13:01] <ogra_> pitti, well, not sure ... perhaps til 12.04 gets dropped ?
[13:01] <seb128> it still support things gnome-software
[13:01] <pitti> ogra_: again, talking about y here, not precise :)
[13:01] <seb128> it still supports things gnome-software doesn't
[13:01] <seb128> does it do any harm in universe?
[13:01] <ogra_> pitti, i dont think there was ever anything else than 12.04 packages in the PPA
[13:01] <ogra_> perhaps 12.10 ... but thats EOL
[13:01] <pitti> seb128: not much right now, aside from blocking debtags in -proposed (not that urgent, but that's how I spotted it)
[13:01] <seb128> why aiming at deleting it and not any of the other stack of cruft we have here?
[13:02] <pitti> ogra_: ti-omap4-software-channel | 0.1 | yakkety/universe | source, all
[13:02] <pitti> ogra_: ^
[13:02] <seb128> why does it block it?
[13:02] <seb128> oh, I see in backlog
[13:02] <seb128> hum
[13:02] <pitti> seb128: well, my question is rather whether we actually want to release it with y, given that nobody seems to maintain it any more
[13:02] <seb128> it's still used even unmaintained
[13:02] <pitti> seb128: nevermind the debtags thing, that's just how I noticed
[13:02] <seb128> I would keep it
[13:02] <ogra_> pitti, oh, the package ... yeah, kill that with bleach
[13:02] <pitti> ogra_: ack
[13:03] <ogra_> i wasnt even aware it still is in the archive :P
[13:03] <ogra_> it is useless
[13:03] <pitti> spring^Wfall cleaning day ;)
[13:03] <ogra_> (for anything but 12.04)
[13:03] <pitti> process-removals this morning, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt now
[13:03] <pitti> (must be release week..)
[13:04] <enrico> sad to see it go. It's maintained in debian, and meh.
[13:04] <enrico> (debtags)
[13:05] <seb128> enrico, I don't think anyone is deleting it, just that the update has no python bindings binaries
[13:05] <pitti> enrico: how do you mean? I'm not talking about removing debtags, just software-center
[13:06] <enrico> ah, ok, I though you were talking about debtags. I guess the highlights gave me a partial version of the chat thread
[13:07] <enrico> sorry about the noise
[13:11] <seb128> pitti, is any flavor still using software-center btw?
[13:11] <pitti> seb128: no, it's not seeded anywhere
[13:11] <seb128> k, well your call then, it seems a bit late to delete what was a major piece of software for Ubuntu without asking first if somebody wants to take over it
[13:12] <seb128> and I think it's still nicer to use than gnome-software, more polished&reliable ... but I guess people who want polished&reliable are on the LTS and can still use it there
[13:12] <pitti> I can still do that on u-devel@, but I'm not very hopeful; we tried to port it to py3 for many years and never found a real maintainer
[13:13]  * pitti will ask
[13:13] <seb128> thanks
[13:16] <jbicha> if we're going to drop software-center because no one cares to do specific maintenance for it, let's do it at the start of a cycle rather than the end to give ~6 months for somemone to step up
[13:17] <jbicha> pitti: bug 1616379
[13:17] <ubottu> bug 1616379 in software-center (Ubuntu) "software-center depends on python-debtagshw, which is not built anymore" [High,Confirmed] https://launchpad.net/bugs/1616379
[13:18] <pitti> jbicha: ah, thanks for pointing out
[13:57] <seb128> barry, hey, small follow up to your email but the goal for those cycles was to get software-center out of the iso/in universe, I don't think anyone really carred about keeping it there
[13:57] <barry> seb128: ack
[15:02] <cpaelzer> I have recently seen a lot of auto-bug reports which aside the actual issue seem to contain an apport issue around "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe2 in position 10006: invalid continuation byte" or similar
[15:02] <cpaelzer> is that a known issue?
[15:03] <pitti> cpaelzer: not on my radar, no
[15:20] <pitti> barry: I synced python-pex, btw
[15:20] <pitti> barry: tests pass again
[15:20] <pitti> barry: also, happy thanksgiving
[15:21] <barry> pitti: saw that, thanks!  and usa thanksgiving isn't until next month :)
[15:21] <pitti> barry: oh, what's today's holiday then?
[15:21] <pitti> oh, Columbus day
[15:23] <barry> pitti: yeah, that's the official federal name of it, although there's a semi-movement to change the name to indigenous people's day
[15:51] <bdmurray> flexiondotorg: Are you working on 1623856?
[15:51] <flexiondotorg> bdmurray, Yes.
[15:52] <bdmurray> flexiondotorg: cool, thanks
[16:16] <pitti> cpaelzer: hah, I bent virt-qemu to my will now when using user/password login
[16:43] <chrisccoulson> pitti, re thunderbird - I'm looking at that now
[16:45] <chrisccoulson> Not sure what to do about firefox though. powerpc and s390 are endianness issues. And ppc64 is a crash on startup which causes the startup cache compilation to fail
=== mfisch` is now known as mfisch
[16:45] <chrisccoulson> I'm not sure I can spend time on powerpc-specific firefox issues
=== mfisch is now known as Guest10253
=== Guest10253 is now known as mfisch
[16:56] <seb128> chrisccoulson, pitti, the current release pocket version has no s390x/powerpc build either, the issue is only ppc64el there
[16:56] <seb128> it would migrate with that one
[17:08] <xnox> pitti, is there anything better than $ systemd-analyze dot ? the output is a rat's nest.
[17:10]  * xnox applies patterns
[17:32] <jderose> chiluk: FYI, the package in your PPA fixes things for my use case, thanks! https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1631474
[17:32] <ubottu> Launchpad bug 1631474 in initramfs-tools (Ubuntu) "No networking with initramfs-tools 0.122ubuntu8.3 and ip=dhcp boot option" [Undecided,In progress]
[18:58] <pitti> xnox: what do you want to do?
[18:59] <pitti> xnox: you can limit it to targets, or only show a particular part -- you ceratinly don't want the entire graph in all details
[18:59] <xnox> yeah
[19:08] <rbasak> !dmb-ping
[19:08] <ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
=== maxb_ is now known as maxb
[19:59] <smoser> am i missing something here ?
[19:59] <smoser> dhclient-script (http://paste.ubuntu.com/23304770/)
[19:59] <smoser> does
[19:59] <smoser>  ip -6 addr flush dev ${interface} scope global permanent
[20:00] <smoser> doesnt it need to do:
[20:00] <smoser> err.. sjhoot
[20:00] <smoser> it does this:
[20:00] <smoser>  p -6 addr add ${new_ip6_address}
[20:01] <smoser>  ip -6 addr add ${new_ip6_address}
[20:01] <smoser>     dev ${interface} scope global
[20:01] <smoser> when i think it needs to do
[20:01] <smoser>  ip -6 addr add ${new_ip6_address}/${new_ip6_prefix}
[20:01] <smoser>   dev ${interface} scope global
[20:02] <smoser> without the prefix, we get an address with /128
[20:02] <smoser> like:
[20:02] <smoser>  fd42:83bb:a360:8010:8fda:82f7:5cdc:fb8a/128
[20:06] <smoser> https://kb.isc.org/article/AA-01141/0/How-to-workaround-IPv6-prefix-length-issues-with-ISC-DHCP-clients.html seems relevant
[20:14] <brendand> i have a xenial system that doesn't want to update anything, even though there are clearly new versions of lots of packages in -updates. i'm particularly seeking a new version of lxd
[20:15] <brendand> -updates is definitely in sources.list
[20:15] <mwhudson> pitti: yeah, it migrated finally
[20:15] <mwhudson> and it's just waiting for sru team attention in xenial too i think
[20:15] <brendand> apt update says: http://paste.ubuntu.com/23304826/
[20:24] <rbasak> brendand: and apt-cache policy?
[20:27] <brendand> rbasak, only knows about the old version
[20:27] <brendand> i'm starting to suspect a proxy
[20:28] <smoser> well, filed this : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1632096
[20:28] <ubottu> Launchpad bug 1632096 in isc-dhcp (Ubuntu) "dhclient-script does not respect ip6_prefixlen" [Undecided,New]
[20:43] <brendand> yup, definitely a caching proxy. i'm getting an old version of http://archive.ubuntu.com/ubuntu/pool/main/l/lxd/ even with wget
[20:48] <tsimonq2> hmmmmm, am I the only person who has had problems with DNS in Yakkety?
[20:49] <tsimonq2> seems to be DNS...
[20:58] <brendand> was the 27th of may release day for xenial?
[20:58] <brendand> now it all makes 'sense' (kind of)
[20:59] <brendand> archive.ubuntu.com on this host is not the actual archive.ubuntu.com - the ip address is different
[21:00] <brendand> and when i wget on my system from the same ip as on the system that won't update, i do indeed get a version of archive.ubuntu.com from the 27th of may
[21:00] <brendand> system that won't update: 64 bytes from archive.ubuntu.com (91.189.91.15): icmp_seq=9 ttl=44 time=211 ms
[21:01] <brendand> my system: 64 bytes from yukinko.canonical.com (91.189.88.162): icmp_seq=1 ttl=62 time=11.4 ms
[21:02] <rbasak> Those are both Canonical IPs, so talk to Canonical IS I guess?
[21:02] <brendand> and here's etc/hosts : http://paste.ubuntu.com/23304972/
[21:02] <brendand> bingo
[21:03] <brendand> sigh
=== DalekSec_ is now known as DalekSec
=== salem_ is now known as _salem
=== Snow-Man_ is now known as Snow-Man