[06:06] <pitti> Good morning
[06:08] <ricotz> good morning
[06:08] <ricotz> this one needs some attention https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
[06:21] <seb128> doko, hey, I noticed your merged packagekit 1.0 again ;-) ... do you plan to port/fix aptdaemon?
[06:22] <pitti> wasn't the bigger blocker click?
[06:22] <seb128> doko, also it breaks click still
[06:23] <seb128> pitti, we sort of agreed that it would be ok to break them for a while because they don't plan to base any product on y
[06:23] <pitti> ah, ok
[06:23] <seb128> but we should sync up again with them to make sure it's still ok
[06:23] <pitti> and moving to snaps at some point, I figure
[06:23] <seb128> yes
[06:24] <seb128> wth
[06:24] <seb128> why is autopkgtest for aptdaemon 1.1.1+bzr982-0ubuntu14: amd64: Ignored failure,
[06:24] <doko> seb128, hrm, thought it would be safe after the lts ...
[06:24] <seb128> that failure should absolutly not be ignored
[06:24] <seb128> it's an abi break that makes it fail to import packagekit
[06:25] <pitti> aptdaemon's tests have been failing for a long time in xenial already
[06:26] <seb128> well in that case they rightly fail
[06:26] <pitti> would be good to fix them indeed, so that they become useful again to detect regressions
[06:26] <pitti> i. e. to succeed in yakkety-release
[06:26] <seb128> right
[06:26] <pitti> (or even xenial)
[06:26] <seb128> meanwhile can we make sure it's blocked in proposed?
[06:27] <pitti> seb128: easiest is to have a bug against packagekit and tag it block-proposed
[06:28] <pitti> I don't want to remove the force-badtest, as this would hold up a lot of unrelated stuff then
[06:28] <doko> hmm, click has an older version in -proposed than in -release?
[06:29] <seb128> weird
[06:30] <seb128> doko, pitti, anyway, https://errors.ubuntu.com/problem/0cbdb94861b90a2bf18c183fb3031ed81f6bb5a7 is one of the issues with aptdaemon/new packagekit
[06:30] <seb128>   File "/usr/lib/python3/dist-packages/aptdaemon/worker/pkworker.py", line 175, in __init__
[06:30] <seb128>     pk.RoleEnum.GET_DEPENDS,
[06:30] <seb128> AttributeError: type object 'PkRoleEnum' has no attribute 'GET_DEPENDS'
[06:32] <seb128> pitti, ^ I've tagged bug #1496292 as block-proposed
[06:32] <ubottu> bug 1496292 in aptdaemon (Ubuntu) "/usr/sbin/aptd:AttributeError:/usr/sbin/aptd@39:main:__init__:__init__" [High,New] https://launchpad.net/bugs/1496292
[06:32] <seb128> is that enough for making sure it sticks there?
[06:33] <pitti> seb128: it needs a packagekit task
[06:34] <seb128> pitti, oh right, thanks, done
[07:02] <seb128> slangasek, infinity, could you maybe have a look to https://launchpadlibrarian.net/259212950/lsb_9.20160110_9.20160110ubuntu1.debdiff from bug #1536353
[07:02] <ubottu> bug 1536353 in lsb (Ubuntu) "[regression] Printer drivers install is broken as lsb package is not available anymore" [Medium,Fix committed] https://launchpad.net/bugs/1536353
[07:10] <Saviq> pitti, morning, could you please expedite https://launchpad.net/ubuntu/yakkety/+queue?queue_text=mir into yakkety? thank you
[07:15]  * seb128 wonders why Saviq wants pitti only to look at that, but ok
[07:16] <Saviq> seb128, because I missed you on this list https://launchpad.net/~ubuntu-archive/+members ;)
[07:16] <Saviq> and Mirv told me to choose the friendliest member ;D
[07:16] <seb128> Saviq, well, usually better to just ask on the channel first
[07:16] <seb128> you can nag individual when nobody replies
[07:16] <seb128> lol
[07:16] <pitti> Saviq: is it really necessary to micro-split the packages that way?
[07:16] <Saviq> sry, first time /me doing this
[07:17] <pitti> they seem to have similar dependencies and each new package just ships a single new driver
[07:18] <Saviq> pitti, I'm afraid I can't answer that, but they've been split up more and more as they went, I'm sure there were some reasons for that
[07:18] <doko> seb128, mvo attached a patch
[07:18] <Saviq> RAOF, if still here, can you comment on why mir is split up into so many packages?
[07:19] <pitti> anyway, debs look okayish, accepted
[07:19] <Saviq> pitti, thank you
[07:19] <seb128> doko, nice, I wonder how you manage to bribe him to spend time out of snappy :p
[07:20] <seb128> doko, can you test/upload the patch?
[07:20] <mvo> seb128: s/bribe/threatened/
[07:20] <seb128> I've no yakkety system and no plan to start y work before a while, too much lts/snappy work
[07:20]  * seb128 hugs mvo
[07:20]  * mvo hugs seb128
[07:22] <Saviq> this is a nice channel
[07:22] <Saviq> snuggly!
[07:22]  * pitti introduces seb128 to the magic of lxd
[07:22] <seb128> doko, mvo, that enum issue was the reports we get from the time the new version was in proposed, I'm not sure those are the only uncompatible change in pkgkit1 that might bite aptdaemon
[07:22]  * seb128 introduces pitti to the limitation of his 80G ssd
[07:22] <pitti> seb128: "lxc launch images:ubuntu/yakkety/amd64" :)
[07:23] <seb128> ENOSPACE
[07:23] <seb128> I'm fighting constently with 1G free space
[07:23]  * seb128 needs to laptop refresh
[07:23] <pitti> oh, wow
[07:23] <seb128> my config is 6 years old
[07:24] <RAOF> Saviq: So many packages?
[07:25] <Saviq> RAOF, <pitti> Saviq: is it really necessary to micro-split the packages that way? (that's re: mir)
[07:25] <pitti> ok, armhf autopkgtests are now limping along on 4 lxd slaves in scalingstack, but they commit suicide every hour or so
[07:26] <pitti> I might have to disable armhf autopkgtests until the CI lab comes back
[07:27] <RAOF> pitti: Oh, you were referring to the new graphics-mesa-kms9 vs graphics-mesa-x9?
[07:28] <pitti> RAOF: and -android9
[07:30] <RAOF> -android9 pulls in android dependencies?
[07:31] <RAOF> Merging -kms9 and -x9 would be painless; *technically* they have different dependencies, but in practise libGL pulls in X anyway...
[07:33] <pitti> RAOF: do -android{5,8,9} have different deps?
[07:33] <RAOF> pitti: No, but they're all superceded.
[07:34] <pitti> RAOF: ah, so those will be NBS? good
[07:35] <RAOF> Or, rather, we've got 2 ABIs in play - client platform ABI and server platform ABI; there'll be exactly one mir-platform-graphics-* for each platform, and exactly one mir-client-platform-* for each platform.
[07:35] <RAOF> All the old ones will be NBS, and removable.
[07:36] <mvo> seb128: you could simply change the ssd and keep the laptop ;) ?
[07:37] <pitti> seb128: purging stuff like ~/.launchpadlib or .local/share/ubuntuimages also works wonders, I freed like 10 G the other day
[07:45] <Saviq> uh oh
[07:45] <Saviq> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-i386/Packages  503  OUT OF DISK SPACE
[07:46] <Saviq> that's not a local error is it?
[07:46] <pitti> where do you see this?
[07:46] <Saviq> pitti, apt-get update
[07:47] <Saviq> and unless zfs went awry, I've 80G free locally
[07:48] <Saviq> hmm wait
[07:48] <Saviq> this could be apt-cacher-ng
[07:48] <Saviq> that definitely makes more sense
[07:48] <Saviq> pitti, my fault
[08:09] <seb128> mvo, I guess I could, but the laptop is a bit bulky and old and 4G ram, time for a proper refresh ;-)
[08:10] <seb128> pitti, right, I do a proper round of cruft cleaning every now and then and go back to 10G, then download some isos, do some pbuilding etc and I'm back to needing to watch free space ... just need a bigger disk, it's about time ;-)
[08:11] <pitti> happy shopping then :)
[08:20] <mvo> seb128: :) sure, it was only half serious
=== salem_ is now known as _salem
[08:22] <seb128> but that was a side discussion anyway, it's just that I don't feel like that I've the bandwith to do xenial+yakkety+snappy+... work, and yakkety is at the bottom of my priority list atm, so please don't count on me for the packagekit/aptdaemon thing
[08:22] <Laney> we did plan on doing it at some point this cycle
[08:22] <Laney> but thanks to doko for taking it on :)
[08:23] <seb128> yeah :-)
[08:23] <Saviq> pitti, any idea why the mir you accepted isn't available in proposed still?
[08:24] <seb128> Saviq, you are using an outdated mirror?
[08:24] <Saviq> archive.ubuntu.com ;?
[08:24] <Saviq> and so do silos?
[08:24] <pitti> Saviq: rmadison says it's there
[08:24] <seb128> maybe the publisher is not done yet?
[08:24] <Saviq> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+packages
[08:24] <pitti> mir-platform-graphics-mesa-x9    | 0.22.1+16.04.20160516.2-0ubuntu2 | yakkety-proposed          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[08:25] <seb128> Saviq, retry your build?
[08:25] <jtaylor> hmm appstreamcli in xenial blocks apt update and eats 100% cpu for apparently ever since today
[08:26] <jtaylor> known issue?
[08:26] <Laney> https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712
[08:26] <ubottu> Launchpad bug 1579712 in appstream (Ubuntu Xenial) "Refresh hangs indefinitely, appstreamcli using 100% CPU" [High,Fix committed]
[08:26] <jtaylor> ah
[08:26] <jtaylor> oh its much older, weird I only see it today
[08:27] <Saviq> seb128, can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+build/9776460 please - that one doesn't have a direct dep so not a dep wait, but fails because of a dep chain
[08:28] <seb128> Saviq, done
[08:40] <Saviq> seb128, ok seems I complained just when it got published
[08:41] <seb128> Saviq, rmadison is your friend ;-)
[08:46]  * mgedmin would appreciate some attention for https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1548425
[08:46] <ubottu> Launchpad bug 1548425 in update-manager (Ubuntu) "update-manager crashed with AttributeError in check_hovering(): 'tuple' object has no attribute 'get_tags'" [Medium,Incomplete]
[09:07] <seb128> mgedmin, it's just a warning right? I can't reproduce here...
[09:08] <seb128> mgedmin, maybe you can get mvo interested in reviewing the patch though
[09:24] <seb128> mgedmin, but weird, "python3 -c "from gi.repository import Gtk; text=Gtk.TextView(); print(text.get_iter_at_location(0,0))"" returns
[09:24] <seb128> <Gtk.TextIter object at 0xb539465c (GtkTextIter at 0x8e836e0)>
[09:24] <seb128> here
[09:24] <seb128> not a tuple
[09:31] <mvo> seb128, mgedmin: looks fine, if it works +1, the GI api changes are a bit annyoing :/
[09:31] <seb128> mvo, mgedmin, well as said I can't confirm the bug and ^ returns an iter for me
[09:34] <seb128> mvo, mgedmin, OH
[09:34] <seb128> libgtk-3-0 3.19.9-0ubuntu1~xenial2 [origin: LP-PPA-gnome3-team-gnome3-staging]
[09:34] <seb128> so I guess the api changed with gtk 3.19
[09:34] <seb128> *great*
[09:35] <seb128> that explains it
[09:35] <seb128> Laney, ^ more fun when we update gtk
[09:35] <Unit193> s/when/if/ by the sounds of it.
[09:36] <doko> sil2100, https://launchpad.net/ubuntu/+source/click looks like you copied old versions
[09:37] <sil2100> doko: hey, yeah... cjwatson noticed that already, looks like this package somehow went through my checks
[09:37] <sil2100> Ah, I know why
[09:37] <sil2100> Since the xenial-overlay actually had a lower version than xenial itself, which is what I didn't expect :|
[09:37] <sil2100> doko: could you drop it from proposed?
[09:40] <sil2100> I actually expected it to just get rejected, since it's a lower version
[09:58] <pitti> xnox: upstart autopkgtest times out after "ok 25 - with single-line script that writes 1 line to stdout" on the infra and also in local qemu; this is new from the y-proposed version
[10:06] <mgedmin> gah!
[10:06] <xnox> pitti, what about xenial-proposed -> does that one hang too, or no?
[10:06] <mgedmin> yeah, I'm on ubuntu-gnome with the staging ppa :/
[10:07] <pitti> xnox: no, that seems fine; and y-release apparently too
[10:07] <xnox> pitti, ok.
[10:07] <pitti> xnox: well, it failed of course, but didn't hang that way
[10:09] <pitti> cyphermox: ok to steal your sysvinit merge?
[10:49] <doko> sil2100, done
[10:56] <pitti> caribou: when sponsoring things like bug 1390061, can you please insist on the reporter forwarding the fix to Debian too? (or do it yourself)
[10:56] <ubottu> bug 1390061 in bash-completion (Ubuntu Wily) "bash-completion tilde expansion every time" [Medium,In progress] https://launchpad.net/bugs/1390061
[10:56] <pitti> having to drag these fixes in Ubuntu is annoying, and it's relevant for Debian too
[10:56] <pitti> caribou: stealing the bash-completion merge FYI, as it's blocking sysvinit and util-linux merges
[10:58] <sil2100> doko: thank you
[11:12] <doko> nacc, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  dh-php wants to pull in xml2. either a MIR is needed or the dependency removed
=== Guest65617 is now known as alvesadrian
=== alvesadrian is now known as adrian-
=== adrian- is now known as adrian1
=== adrian1 is now known as adrian121
=== adrian121 is now known as alvesadrian
[11:47] <doko> seb128, Laney: suitesparse gained a dependency on metis (needs a MIR, or suitesparse needs again building with the internal metis)
[11:47] <seb128> doko, doesn't seem something that has to do with desktop
[11:47] <seb128> unsure what suiteparse is
[11:47] <seb128> never touched it
[11:49] <doko> seb128, suitesparse is owned by desktop packages
[11:49] <Laney> used by libreoffice
[11:50] <seb128> k, well as said earlier I've no slot of y-work at the moment
[11:50] <seb128> so feel free to find somebody else interested
=== hikiko is now known as hikiko|ln
[12:23] <caribou> pitti: ok ,will do. sorry for that
[12:31] <stokachu> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stokachu
[12:32] <caribou> pitti: you didn't forward the bug to debian ? 'cause I'll ask seyeong to do it
[12:33] <ChrisTownsend> pitti: Hey, I have some britney runs for silo-031 that seem like they are stuck (or missing): https://requests.ci-train.ubuntu.com/#/ticket/1425
[12:34] <ChrisTownsend> pitti: I was told to ping you for investigation.
=== hikiko|ln is now known as hikiko
[12:50] <pitti> ChrisTownsend: prodded, running now: http://autopkgtest.ubuntu.com/running.shtml#pkg-content-hub
[12:51] <ChrisTownsend> pitti: Thanks.  And the yakkety one's are just in the queue waiting, right?
[13:01] <seb128> xnox, https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu24/+build/9737266 ... build is ongoing since yesterday, is that stucked?
[13:02] <xnox> seb128, yes. will retry.
[13:02] <seb128> xnox, I guess it's bug #1576914
[13:02] <ubottu> bug 1576914 in upstart (Ubuntu) "upstart,libnih ftbfs on s390x with linux 4.4.0-21.37" [Undecided,New] https://launchpad.net/bugs/1576914
[13:02] <seb128> ?
[13:16] <xnox> pitti, https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563
[13:16] <ubottu> Launchpad bug 1583563 in multipath-tools (Ubuntu) "System will not start with multipathd enabled" [High,Confirmed]
[13:16] <xnox> looks very fishy =(
=== chuck__ is now known as zul
=== Guest67500 is now known as adrian
[14:00] <Saviq> pitti, this seems stuck, doesn't it http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8 ?
[14:01] <Saviq> "Running for:	3 h 4 min 13 s"
[14:02] <smoser> pitti, around ?
[14:09] <cyphermox> pitti: yeah, have fun!
[14:10] <cyphermox> sorry, I had some internet troubles
=== _salem is now known as salem_
[14:21] <nacc> doko: ack, will investigate, must be a new dep in dh-php in debian
[14:49] <pitti> smoser: hello
[14:49] <pitti> Saviq: there was an outage of lcy01, so it had to retry a few times
[14:52] <pitti> Laney: meh, lcy01 and bos01 now both dieing? what's that, a strike?
[14:52] <smoser> ah.great.
[14:52] <smoser> pitti, so i was looking at Odd_Bloke 's cloud-image slow boot from yesterday
[14:53] <smoser> i modified cloud-init-local.service to have this
[14:53] <smoser>  http://paste.ubuntu.com/16522550/
[14:54] <smoser> and then after boot
[14:54] <smoser> $ grep . /run/cloud-init/pre-local*
[14:54] <smoser>  /run/cloud-init/pre-local:4.73 1.23
[14:54] <smoser>  /run/cloud-init/pre-local-python:27.13 22.84
[14:55] <smoser> so the 'python3 -c' line took 24 seconds to start up, and copy /proc/uptime to /run/cloud-init/
[14:58] <pitti> smoser: ooh, I know
[14:58] <pitti> smoser: that's yakkety, right?
[14:58] <smoser> yes
[14:58] <pitti> smoser: debian bug 822431
[14:58] <ubottu> Debian bug 822431 in python3.5 "python3.5: regression in -11: always calls getrandom() at start, causing long hang after boot" [Important,Open] http://bugs.debian.org/822431
[14:58] <pitti> smoser: this bit me in autopkgtest as well
[14:58] <pitti> smoser: use this workaround: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=abfc34e2a0f
[14:59] <pitti> smoser: i. e. call it with PYTHONHASHSEED=0
[14:59] <pitti> smoser: and it'll be blazing fast again
[14:59] <pitti> this issue is an utter nuisance
[14:59] <pitti> basically every python3 during early boot blocks for ages
[15:00] <pitti> I don't understand why hashes need to be cryptographically randomized
[15:01] <pitti> and python would block on that
[15:01] <pitti> in pretty much every language dictionaries are even predictable (although their "order" might change between compilers and versions of course)
[15:02] <smoser> pitti, ok. i'm trying that. by changing /usr/bin/cloud-init's #! to be
[15:02] <smoser>  /usr/bin/env PYTHONHASHSEED=0 python3
[15:02] <pitti> you can use #!/usr/bin/env .. that
[15:04] <pitti> at least there's a lot of discussion in the upstream python bug, so hopefully this gets fixed after all and the debian bug "wontfix" will be dropped
[15:06] <Odd_Bloke> Great bug, 10/10.
[15:06] <Odd_Bloke> Would encounter again.
[15:08] <pitti> Odd_Bloke: sorry, can't parse that
[15:08] <smoser> huh. why doesnt that work above ?
[15:09] <smoser> cat >my.py<<EOF
[15:09] <smoser> #!/usr/bin/env PYTHONHASHSEED=0 python3
[15:09] <smoser> print("hello python 3")
[15:09] <smoser> EOF
[15:09] <smoser> chmod 755 ./my.py
[15:09] <pitti> Odd_Bloke: but yes, I spent an entire afternoon tracking this down; in retrospect it should have been much faster, but after the fact everythign is obvious :)
[15:09] <Odd_Bloke> pitti: (https://xkcd.com/325/)
[15:10] <smoser> a++++ would read provided link again
[15:10] <Odd_Bloke> pitti: Yeah, I probably didn't help by planting the networking seed in your mind. :p
[15:11] <pitti> smoser: hmm, indeed, hashbangs don't work like that; perhaps just add Environment=PYTHONHASH=0 to the uit?
[15:11] <pitti> unit too
[15:11] <smoser> yeah. have to add it to each though
[15:12] <smoser> what am i missing .. why dont sheang work like that. and what is it trying to do
[15:12] <JanC> pitti: IIRC that was added after somebody illustrated a DDoS against Python's hashtables?
[15:12] <smoser> oh. it endlessly loops env
[15:12] <pitti> smoser: sounds like the rest of the file gets fed to env, not python3 or so
[15:13] <smoser> yeah. i'll modify the Environment
[15:13] <smoser> but i didnt' want to have to touch all of them.
[15:14] <pitti> it's hopefully not a permanent change
[15:14] <pitti> if upstream adds the NONBLOCK flag back to the getrandom() call, the world should be a brighter place again
[15:16] <JanC> I suppose it's mostly useful where Python has to handle arbitrary data from untrusted users, e.g. in some internet services/apps
[15:17] <pitti> JanC: that sounds curious; happen to have a link?
[15:17] <pitti> I can't imagine how an unreliable hash order would be a security feature
[15:17] <pitti> "unpredicable"
[15:18] <Odd_Bloke> pitti: http://bugs.python.org/issue13703
[15:18] <Odd_Bloke> pitti: Which points to https://mail.python.org/pipermail/python-dev/2011-December/115116.html
[15:19] <JanC> pitti: if you can predict the hashes, you can submit data that computes to the same hash, I suppose...
[15:19]  * pitti stashes that for later reading, thanks!
[15:20] <smoser> pitti, what did i do wrong: http://paste.ubuntu.com/16523164/
[15:20] <JanC> which of course makes hashtable lookups very slow
[15:21] <pitti> smoser: PYTHONHASHSEED (sorry, typoed in my last reply)
[15:22] <herrkin> hello, I have a problem with a modem that wont switch to modem mode
[15:22] <herrkin> I have several modems to test but there is one that is very stupid, some times it just stays in mass storage mode and wont switch
[15:22] <Odd_Bloke> herrkin: This channel is for development of Ubuntu itself; you probably want #ubuntu or #ubuntu-server. :)
[15:22] <herrkin> is this the correct place to discuss abut it?
[15:23] <herrkin> Odd_Bloke, the problem is with usb_modeswitch I think
[15:23] <herrkin> its part of ubuntu
[15:26] <Odd_Bloke> herrkin: Sure, but the venue for questions about _using_ Ubuntu belong in #ubuntu or #ubuntu-server.  There will be more people in those channels who may have run across the issues you are seeing, so you have a better chance of finding help. :)
[15:26] <herrkin> ok let me see.
[15:26] <herrkin> thanks
[15:41] <pitti> xnox: I have a change to procps to make; should I steal your merge while I'm at it, or are you already at it?
[15:42] <pitti> apw: do you know if /etc/init.d/ondemand is still a thing that we need with current kernels?
[15:42] <pitti> apw: it's the only thing that's left from initscripts that we actually use; I'm working on dropping deps to initscripts so that we stop installing it by default, and wonder if I should put an equivalent unit into systemd or not
[15:43] <smoser> pitti, something else is at play here.
[15:43] <apw> pitti, we use that to boot in performance and drop back to something less batter sucking ... and the kenrel is still in performance by default
[15:43] <smoser> $ pastebinit /lib/systemd/system/cloud-init-local.service
[15:43] <smoser> http://paste.ubuntu.com/16523968/
[15:44] <pitti> apw: I had assumed the kernel would drive the CPU to full steam while it's actualy busy doing something (like on boot)
[15:44] <smoser> $ tail -n 10 /usr/bin/cloud-init | pastebinit
[15:44] <smoser> http://paste.ubuntu.com/16523984/
[15:44] <pitti> apw: i. e. I wonder why we are the only distro doing somethign like that
[15:45] <apw> pitti, it was something that keybuk drove in, and it has never been revisited since
[15:45] <pitti> apw: anyway, it's simple to port; I'll probably use a Type=idle so that it goes to ondemand as soon as boot is done, istead of a static "1 minute", I just wondered if the kernel still needs that kind of help
[15:45] <smoser>  http://paste.ubuntu.com/16524007/
[15:45] <xnox> pitti, please steal
[15:46] <smoser> so i suspect that something in the cloud-init's imports is messing up the PYTHONHASH or something so it goes back to slow.
[15:46] <apw> pitti, yeah it is pretty unclear for sure, would you file a bug on linux to review that and let me know, i will find someone to think about it
[15:46] <apw> pitti, but in the short term, making it an idle systemd unit sounds much better anyhow
[15:47] <apw> a i know it makes my lappy hot during boot :/
[15:49] <pitti> apw: ok, so port to a unit in the short-term, and revisit if defaulting to "ondemand" works better now (after all, some 10 years have passed..)
[15:49] <pitti> maybe 8
[15:50] <apw> indeed
[15:50] <Odd_Bloke> smoser: If you want to test the imports, you could (probably) move them all in to that if statement after the startup time is written out.
[15:51] <smoser> yeah
[15:52] <pitti> apw: bug 1584124 -- does that have enough context/
[15:53] <ubottu> bug 1584124 in systemd (Ubuntu) "revisit /etc/init.d/ondemand" [Wishlist,Triaged] https://launchpad.net/bugs/1584124
[15:53] <pitti> ?
[16:00] <pitti> xnox: procps> ugh, a 100 kB Ubuntu diff? fun; well, I asked for it, I got it :)
[16:40] <Odd_Bloke> pitti: doko: Is there an Ubuntu bug open anywhere for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822431?  This is really serious for cloud images, because they all use Python 3 near the start of boot (via cloud-init).
[16:40] <ubottu> Debian bug 822431 in python3.5 "python3.5: regression in -11: always calls getrandom() at start, causing long hang after boot" [Important,Open]
=== Guest59880 is now known as adrian
[16:41] <Odd_Bloke> (I've seen a 7 minute hang as a result of it on an OpenStack cloud)
[16:53] <cpaelzer> Hi, I know there are always all kind of super-skilled people around - for those of you who love gcc/ld to its darkest depth - you might take a look at http://stackoverflow.com/questions/37351699/how-to-create-both-so-files-for-two-circular-depending-libraries - there seem to be no good answer to that out there yet so I asked it openly
[16:53] <cpaelzer> I'm giving up on it for now and let the weekend try to distract me from it :-)
[17:02] <smoser> pitti, just for a summary of above using PYTHONHASH does not seem to affect all things.
[17:02] <smoser> for example, 'import tempfile' does
[17:02] <smoser>  from random import Random as _Random
[17:03] <smoser> and that seems hits the same first boot hang even with PYTHONHASH set.
[17:05] <Odd_Bloke> smoser: What do you see without that set at all?
[17:06] <smoser> ?
[17:06] <Odd_Bloke> smoser: Because I suspect you are working around the Python _startup_ issue, and then hitting a separate (but very much related) random module issue.
[17:06] <smoser> yeah. i think so too
[17:06] <smoser> i can take out the Environment and see
[17:12] <Odd_Bloke> smoser: I've filed https://bugs.launchpad.net/cloud-images/+bug/1584147 (which also affects cloud-init).
[17:12] <ubottu> Launchpad bug 1584147 in cloud-init (Ubuntu) "cloud-init hangs on boot as Python waits for sufficient randomness to start" [Undecided,New]
[17:13] <smoser> Odd_Bloke, so setting PYTHONHASH *does* help.
[17:13] <smoser> at least in a single test here
[17:13] <smoser> but clearly doesnt make it all magic
[17:15] <Odd_Bloke> smoser: I've added a comment with a high-level summary of what you've discovered; please feel free to flesh out with details. :)
[19:31] <TJ-> Why would "Failed to connect to Mir: Failed to connect to server socket: No such file or directory" be reported when executing an X application from the terminal, launched by another (sudo) user, with e.g. "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/<user>/.Xauthority xclock" - do we need to copy more of the target users' native environment? any in particular? presumably this is some kind of fallback
[19:31] <TJ-> if the X session isn't found?
[19:32] <dobey> where are you trying to do that?
[19:33] <TJ-> from a VT. On my system (Ubuntu+Unity) it works fine. On another system using, I think, Lubuntu, it gets that error. Obviously Mir isn't installed, but it feels like a fallback if the X server/session for the target user cannot be located
[19:35] <dobey> well i'm pretty sure xclock doesn't link to libmir
[19:35] <sarnold> TJ-: I got that same error message trying to run evince via ssh -X https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1573300
[19:35] <ubottu> Launchpad bug 1573300 in evince (Ubuntu) "ssh -X X11 forwarding doesn't work" [High,Incomplete]
[19:35] <TJ-> no, it's something in the underlying libraries obviously. I've not pulled the sources of the libraries as yet to search for the string
[19:35] <sarnold> TJ-: I never got around to debugging this thing :/
[19:36] <dobey> well, xclock is a pure x app
[19:36] <TJ-> sarnold: right; I've seen some similar reports but no bug reports as yet.
[19:36] <dobey> it doesn't link to gtk+ or qt, and the X libs don't link to mir
[19:36] <sarnold> xclock is a genius test case :) pretty simple, no churn
[19:36] <TJ-> dobey: xclock is just an example
[19:36] <TJ-> this is about the session-level env I think
[19:37] <dobey> TJ-: sure, i'm just trying to figure out what could possibly cause something that does link to mir, to be run in that case
[19:37] <dobey> and i just don't see anything
[19:37] <TJ-> I suspect its the XDG_* vars
[19:38] <dobey> eh?
[19:39] <TJ-> looks like bug 1463263
[19:39] <ubottu> bug 1463263 in Ubuntu "ssh-based X11 forwarding not working in 15.04 following upgrade from 14.10" [Undecided,Confirmed] https://launchpad.net/bugs/1463263
[19:39] <dobey> TJ-: why not strace and follow the forks/threads to see what else gets run?
[19:39] <TJ-> dobey: I suspect the failing Lubuntu system doesn't have those XDG_ vars that this Ubuntu has in each user's session
[19:39] <TJ-> dobey: I don't have direct access to the failing system right now
[19:40] <dobey> i don't understand what's failing exactly. you ssh to a remote system and then try to run something on that remote system's own local display?
[19:40] <TJ-> interesting that bug has the quote "The "gdk_mir_display_open" error is just GDK/GTK trying to use Mir because it found no X11 server ($DISPLAY is blank)."
[19:40] <TJ-> dobey: No, ssh is sarnold's issue :)
[19:41] <dobey> *shrug* ssh -X works fine here
[19:42] <TJ-> dobey: 2 completely unrelated separate systems here, trying to use the same mechanism to cause a (yad) window to be displayed in "user1" X session, triggered by "user2" non-GUI script doing "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/user2/.Xauthority yad ...args..." ... I use xclock just to test it
[19:43] <TJ-> user2 has sudoers NOPASSWD rights to /usr/bin/env so no user prompting is required
[19:43] <sarnold> TJ-: are perms on /home /home/user2/ and /home/user2/.Xauthority all correct?
[19:44] <TJ-> the background to this is some automated scripts the bring up a public Internet connection (wifi) and then a secure VPN, and inform the user whats' going on and, if the public internet is detected to have a captive portal, uses that mechanism with xdg-open http://some.domain/ to cause "user1" to see the captive portal login page
[19:45] <TJ-> sarnold: yes, totally separate, and thatts why 'sudo' is being used, to ensure access to the files
[19:45] <TJ-> I'll be in front of the Lubuntu system on Sunday, but hopefully I can get some background on this before then
[19:48] <dobey> TJ-: and the user was definitely logged in on the remote machine?
[19:49] <TJ-> interesting  bug 1433165 suggests it could be triggered by an apparmor profile
[19:49] <ubottu> bug 1433165 in evince (Ubuntu) "evince fails to run due to a gdk_mir_display_open" [High,Confirmed] https://launchpad.net/bugs/1433165
[19:51] <TJ-> dobey: yes, it's complicated, but user1 is the UID 1000 default user account ... user2 is a 2nd account used to contain the scripts and execute them such that user1 cannot mess them up. user2 has certain sudoers NOPASSWD permissions to run a few system commands via sudo with no need of user interaction
[19:52] <TJ-> As I said, this looks to be partially due to the failing system being Lubuntu, so potentially a few things are different in the session env
[19:54] <dobey> TJ-: as i said, i think you should strace to see where the actual failure happens. xclock and sudo don't link to libmirclient, so they can't possibly be trying to open a mir socket (unless of course the xclock is actually a link to some other app, which does link to libmirclient).
[20:00] <TJ-> it'll be the gtk/gdk libraries I presume
[20:00] <stokachu> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | 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 | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[20:03] <TJ-> aahhhh gdk/mir/gdkmirdisplay.c
[20:04] <dobey> well yes, obviously gtk+ has support for mir
[20:04] <dobey> but that doesn't explain your issue with xclock
[20:04] <dobey> xclock does not use gtk+
[20:04] <dobey> or gdk
[20:06] <sarnold> there is a surprising number of libraries there though http://paste.ubuntu.com/16534039/
[20:06] <sarnold> my guesses, libfreetype, libfontconfig
[20:07] <sarnold> also why xclock needs a bloody xml parser .. *sigh*
[20:08] <TJ-> ignore xclock, that is misleading. The first of several real commands that fails is xdg-open (synaptic is another one) ... xdg-open is a shell script that runs different programs based on the DE. for LXDE it used pcmanfm which is linked to gtk
[20:08] <dobey> sarnold: apt-cache rdepends libmirclient9 doesn't show fontconfig or freetype as needing it
[20:08] <sarnold> dobey: ldd
[20:08] <sarnold> oh I see, read too fast
[20:08] <sarnold> or rather, read too poorly :)
[20:09] <dobey> TJ-: well if it's misleading, that's your fault. you said it didn't work and gave you that mir error. if that's not true, why did you say it? :)
[20:09] <TJ-> that explains the error message, but it'll take some time to work backwards to figure out what is missing in the environment that caused the code to fall through to the mir code
[20:10] <dobey> well, it couldn't connect to the X display
[20:11] <TJ-> dobey: I gave it as an example of a quick test we tried to minimize the externals. But, the actual scripts use xdg-open yad and others, so tracing xdg-open now I know where the error is coming from, will actually help us find a workaround
[20:19] <Saviq> who has access to snakefruit and could follow https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests to re-run the unity8 tests with --all-proposed? it's trying to build old unity8 with new unity-api and that won't work
[20:19] <Saviq> the unity8 tests for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api I meant
[20:19] <Saviq> as we're in a chicken'n'egg situation
[20:20] <sarnold> Saviq: just curious does that mean one of the packages is missing a version dependency of some sort?
[20:22] <Saviq> sarnold, we never came up with the right way to encode those dependencies, we have a unity8 B-D: unity-api-dev >> $version
[20:23] <Saviq> and a new unity-api-dev can break unity8 build
[20:23] <lpotter> well... my update to xenial went better than the last time I tried...
[20:24] <dobey> Saviq: it's only an issue becasue autopkgtests rebuild unity8 right?
[20:24] <Saviq> dobey, bits of it still, yes
[20:24] <Saviq> we're thinking how to avoid that
[20:24] <Saviq> now that I think of it if we build-depended on a virtual package provided by unity-api-dev (is it even supported to B-D on a virtual package?), it would make it better
[20:25] <Saviq> because a "breaking" unity-api-dev wouldn't Provide that any more
[20:25] <dobey> hmm, well, unity8 seems to be flagged as always failing on yakkety, at least in my pay-service silo: https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-056/excuses.html
[20:26] <Saviq> dobey, yeah but it's uninstallable
[20:26] <Saviq> because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[20:26] <dobey> but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html doesn't show that any more
[20:26] <dobey> err
[20:26] <dobey> s/more/where/
[20:26] <Saviq> i.e. https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-058/excuses.html
[20:27] <Saviq> unity8-common/amd64 unsatisfiable Depends: unity-scopes-impl-12
[20:27] <Saviq> and that is provided by unity-scope-shell, depending on the above unity-scopes-api, which regressed unity8... you know the drill...
[20:28] <Saviq> *unity-scopes-shell
[20:28] <Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[20:49] <Logan> hmm, any core devs around who want to trigger a no-change rebuild on portaudio19?
[20:49] <Logan> see: https://launchpad.net/ubuntu/+source/espeakup/1:0.71-27/+build/9779375
[20:49] <Logan> (it needs to be rebuilt against the pie-by-default compiler)
[21:19] <Logan> slangasek, maybe?
[21:19]  * slangasek tries to look busy
[21:19] <Logan> :P :P
[21:21] <slangasek> sbeattie: ^^ shouldn't portaudio19 have turned up in your list of libs for PIE no-change rebuilding?
[21:23] <Logan> tsk tsk
[21:25] <slangasek> Logan: portaudio19 uploaded
[21:25] <Logan> cheers!
=== salem_ is now known as _salem
=== nacc is now known as Guest64822
=== nacc_ is now known as nacc
=== JanC is now known as Guest59129
=== JanC_ is now known as JanC
[23:46] <rlaager> stgraber: Can you test the proposed fix in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1567558
[23:46] <ubottu> Launchpad bug 1567558 in zfs-linux (Ubuntu Yakkety) "ZFS is confused by user namespaces (uid/gid mapping) when used with acltype=posixac" [Undecided,Confirmed]
[23:53] <sarnold> rlaager: cool :D