[04:42] <pitti> Good morning
[04:42] <sarnold> good morning pitti :) sure sign that it's time to be done working, hehe
[04:43] <sarnold> that was a nice networking email, certainly a lot to take in in one go..
[04:45] <pitti> hey sarnold
[04:45] <pitti> sarnold: the netplan stuff?
[04:58] <pitti> infinity: would you mind marking https://launchpad.net/ubuntu/wily as obsolete?
[04:58] <pitti> cjwatson: ^ I think that's the reason for the ddeb-retriever spam
[06:16] <infinity> pitti: Not yet.
[06:16] <infinity> pitti: I'm doing some removals first.
[06:40] <infinity> pitti: I'll sort it out in the morning.
[06:40] <pitti> infinity: thanks
[06:55] <Saviq> pitti, morning, I know I'm becoming a bore, but could you please have a look at autopkgtest results here https://requests.ci-train.ubuntu.com/#/ticket/1575 - it seems some of the runs have disappeared - the two regressions in yakkety need a restart with all-proposed
[07:01] <pitti> Saviq: done
[07:02] <Saviq> pitti, thank you, glad it doesn't take you too long - any idea why the disappearing runs?
[07:02] <pitti> Saviq: might still be bug 1588566 -- this keeps getting pushed down my todo list, sorry
[07:03] <Saviq> ack
[07:13] <tjaalton> did the installer create a separate /boot at some point in the history?
[07:14] <tjaalton> by default
[07:14] <pitti> with some scenarios, like lvm or encrypted root
[07:15] <pitti> or presumably zfs now, as AFAIK you cannot boot from that yet
[07:15] <tjaalton> seems to work fine :)
[07:15] <tjaalton> anyway, trying to "argue" with a friend who's pissed because /boot is "always" too small
[07:15] <tjaalton> when upgrading
[07:16] <pitti> because we do a bad job at removing old kernels?
[07:16] <tjaalton> yeah
[07:16] <pitti> my wife's stock 14.04 install has the same problem, for some reason the auto-removal doesn't work
[07:17] <pitti> so no size of /boot will ever be large enough for that, the root cause is our kernel inflation
[07:17] <tjaalton> right
[07:17] <sarnold> pitti: yeah, netplan :) very ambitious :)
[07:17] <tjaalton> this is a desktop machine, probably installed with the alternate-installer at some point in the history
[08:38] <tjaalton> yeah, the installer gives the impression that lvm is more flexible, when in fact it causes issues like this :)
[08:41] <doko> xnox, please could you merge netcfg (and fix the GCC 6 build issue)?
[08:55] <doko> coreycb, please could you fix the python-taskflow ftbfs?
[10:18] <Saviq> pitti, what do we do with missing s390x deps https://requests.ci-train.ubuntu.com/static/britney/ticket-1575/landing-073-yakkety/excuses.html ? Mirv mentioned you discussed this with robru yesterday?
[10:49] <xnox> Saviq, I thought it should be available, no?
[10:50] <Saviq> xnox, it's the upstart removal fallout I believe
[10:51] <xnox> oh, ok. yeah, cause package is available.
[10:51] <xnox> doko, ack
[11:05] <pitti> Saviq: I suppose we need to remove ubuntu-system-settings/s390x?
[11:07] <pitti> Saviq: err, there are no ubuntu-system-settings s390x binaries in Ubuntu
[11:07] <pitti> I suppose the PPA builds it for some reason
[11:07] <Saviq> pitti, we might need to, if there's no other way, but that will be a gift that keeps on givin'... don't we have a plan to break this dependency chain somewhere?
[11:07] <Saviq> pitti, probably because it doesn't have a build-dep on anything that's not on s390x any more...
[11:08] <rockyh> hi!
[11:09] <rockyh> I would like to report an apparent mismatch between some outputs in w, who and uptime commands
[11:09] <rockyh> this is my situation: http://paste.ubuntu.com/21877593/
[11:09] <pitti> Saviq: but it also was not built in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+packages on s390s
[11:09] <pitti> Saviq: I think yesterday's problem was that there was some stale s390x binary in some PPA; robru cleaned it up for a different case
[11:09] <rockyh> both w and uptime indicate 5 users; but w lists just 2 users
[11:09] <rockyh> and who does the same
[11:09] <Saviq> pitti, looks built https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-073/+sourcepub/6764432/+listing-archive-extra ?
[11:10] <pitti> not sure what exactly he did
[11:10] <rockyh> (my system is Xubuntu 14.04)
[11:10] <rockyh> (the commands give the same results when launched with or without sudo)
[11:10] <pitti> Saviq: argh yes, I looked at the vivid build, sorry
[11:11] <Saviq> pitti, so yeah, if it's not in yakkety, can you please remove the PPA build for s390x and I'll work to add a B-D to ubuntu-system-settings to prevent it from building on s390x
[11:14] <pitti> Saviq: done
[11:14] <Saviq> pitti, thanks
[11:16] <pitti> I retried unity8 against all of -proposed in ubuntu several times, doesn't help
[11:16] <pitti> the qmlui tests keep being broken
[11:26] <Laney> pitti: that is apparently https://launchpad.net/bugs/1607686
[11:27] <pitti> Laney: ah, thanks
[11:29] <Mirv> pitti: yep unity8 should be fixed soon, then I'd just need a word from Kubuntu people that they are ok overriding their remaining failures (functionally no-one has complained about anything, even though people are running it)
[11:30] <Mirv> it'd be nice to get forward with the proposed migration
[11:41] <coreycb> doko, sure I'll take a look
[11:51] <coreycb> doko, I'm not seeing a python-taskflow ftbfs. did you mean python-eventlet?
[11:51] <doko> coreycb, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160705-gcc6-yakkety.html
[11:52] <coreycb> doko, gotcha, thanks
[11:52] <doko> coreycb, but let me retry ...
[11:54] <coreycb> doko, I just hit the same errors on amd64.  I'll work on fixing that up.
[12:05] <sveinse> Is this the spot to ask packaing questions? I'm trying to package a cmake based library. However dpkg-gensymbols complains about new symbols appearing, such as "_ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED0Ev@Base 2.1.2". I suppose there is a dep missing, and I tried googling it, but without any results. Is this known to anyone here?
[12:09] <rbasak> sveinse: see dpkg-gensymbols.
[12:26] <sveinse> rbasak: Yes. I have no clue thou if I can simply add it to the debian/*.symbols file without any side effects. Should I?
[12:30] <jbicha> pitti: update_excuses stopped updating again
[12:57] <rockyh> sorry if before I wrote in the middle of another discussion. Now I retry to expose my problem
[12:57] <rockyh> I am running a Xubuntu 14.04 system. I found some mismatches between the number of "users" printed in the output of "uptime" and the *actual* number of users locally connected to the system
[12:58] <rockyh> here I pasted the outputs I got: http://paste.ubuntu.com/21877593/
[12:58] <rockyh> as you can see, both w and uptime indicate that 5 users are connected, but both w and who show just 2 users
[12:59] <rockyh> and there are actually 2 users: one who made a login from the GUI, and one from ssh
[12:59] <rockyh> I didn't use nor screen neither tmux
[13:00] <rockyh> thanks to the help of users in the #ubuntu channel, Ubuntu 16.04 seems to behave in a different way. So I would like to ask: why is there this mismatch?
[13:01] <rockyh> (I mean that probably in Ubuntu 16.04 both w and who would have correctly shown 5 user logins)
[13:04] <rockyh> there can be some errors in the implementation of uptime in *ubuntu 14.04?
[13:12] <Odd_Bloke> rockyh: This is still really a question for #ubuntu; could you re-join there and we can discuss it?
[13:32] <rockyh> Odd_Bloke: they suggested me to write here
[13:33] <rockyh> Odd_Bloke: anyway, sure, I just re-joined #ubuntu
[13:46] <Laney> looks like britney is crashing
[13:50] <zaytsev> doko: hello, thought i would ask here instead of empty #ubuntu-toolchain -> llvm-3.8 has recently landed in trusty-updates, but it seems that openmp is not in?
[13:51] <zaytsev> doko: when i try to compile anything with omp.h & -fopenmp it fails, and there is no libomp-dev like in xenial present
[13:52] <doko> zaytsev, please ask tjaalton about llvm in trusty
[13:53] <zaytsev> doko: thank you! tjaalton ^^^ any comments? thanks!
[13:56] <zaytsev> tjaalton: i see in rules you left the following in - --with-clang-default-openmp-runtime=libomp - but libomp hasn't been backported / nowhere to be found :-/
[14:01] <tjaalton> zaytsev: ok, need to drop that then
[14:01] <Laney> pitti: did you change anything in britney today?
[14:03] <zaytsev> tjaalton: means we ain't gonna get omp? fair enough... i'll turn off omp for llvm on our trusty boxes then.
[14:04] <tjaalton> zaytsev: it's backported only for hwe lts stack (mesa)
[14:09] <zaytsev> tjaalton: sure, i understand. still.. do you think maybe hadcoding libgomp as a default runtime could work?
[14:10] <tjaalton> no idea
[14:11] <LocutusOfBorg> oh britney, why you so sad?
[14:17] <mterry> Laney, I may have a hack for unity-greeter's prompt box.   Doesn't seem to work for the session chooser, but looking at that next
[14:17] <Laney> mterry: !!!!
[14:18] <Laney> hacks are good at this stage
[14:19] <mterry> Laney, it basically sets the prompt box's "resize_mode", which is a deprecated value.  And if that deprecated value is set, gtk skips the new resize logic patch you linked
[14:19] <Laney> "might introduce obscure bugs if used"
[14:19] <Laney> haha
[14:20] <Laney> so you have to queue a resize yourself manually or something?
[14:23] <mterry> Laney, no... I'm settingn the resize_mode to "immediate" and it seems to work without other changes
[14:23] <mterry> Laney, one line hack so far -- but session chooser may be another thing
[14:42] <pitti> Laney, jbicha: eek, thanks for pointing out; fixed
[14:43] <pitti> Laney: yes, I did an upstream update to fix the missing architecture build excuses in the HTML
[14:46] <Laney> pitti: I already fixed it
[14:46] <Laney> hopefully
[14:46] <Laney> it's copying stuff now
[14:46] <Laney> oh, you force pushed over that
[14:46] <pitti> Laney: sorry, mid-air collision
[14:47] <Laney> it wasn't mid air - that was pushed and already running
[14:47] <pitti> I fixed the iteration over block-bugs
[14:47] <Laney> same
[14:47] <Laney> oh well
[14:47] <pitti> it's the one thing we don't test, as we don't have a mock for Launchpad -- I guess it's time to write one
[14:47] <Laney> suggest pull before push next time
[14:48] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html just updated
[14:48] <pitti> Laney: yeah, sorry, that was too quick
[14:49] <Laney> pitti: you can just supply a Blocks file for testing?
[14:49] <Laney> pitti: also, can you make the runner script run git reset -q please?
[14:49] <Laney> ubuntu-archive's mailbox is getting spammed :)
[14:49] <pitti> sure
[14:49] <Laney> would do it, but EPERM
[14:53] <pitti> Laney: done
[14:54] <Laney> danke!
[14:56] <Laney> mterry: I filed bug #1608908 earler, btw
[14:56] <Laney> nothing new in there, but a place to hang your fixes
[14:56] <Laney> :)
[14:56] <mterry> k
[15:06] <ricotz> doko, hi, please take a look at the patch changes https://paste.debian.net/plain/786589
[15:08] <pitti> Laney: I did a round of cleaning up on all the armhf and s390x boxes, and refreshed the armhf lxd ones as well; should hopefully hold up until end of next week :)
[15:09] <pitti> Laney: i. e. on armhf lxc sometimes leaks containers, or lxc-start/lxc-stop gets stuck etc., but it's ok to pile up a few of those
[15:14] <semiosis> infinity: hello & good morning!  any movement on bug 1605795 since we last spoke?  just checking in :)
[15:14] <semiosis> Odd_Bloke: ^^
[15:17] <Laney> pitti: ah, nice - how do you see the lxd stuff?
[15:17] <Laney> I'm on the controller
[15:17]  * Laney hasn't used that before
[15:29] <pitti> Laney: it's autopkgtest-lxd-worker/0
[15:29] <pitti> Laney: instead of cloud-worker
[15:30] <Laney> pitti: you just kill the workers in the same way?
[15:31] <pitti> Laney: yes, other than that they use a remote lxd instead of ssh they are the same
[15:31] <Laney> ok
[15:31] <Laney> I thought you were saying you went a poked lxd directly
[15:31] <pitti> check "lxc remote list" and e. g. "lxc list lxd-armhf-236:
[15:33] <pitti> Laney: the remotes are still horribly brittle  though, so I don't actually expect this to get much work done
[15:33] <pitti> Laney: so this is still an experiment
[15:33] <Laney> but you still have the static lxc ones, so that should be okay
[15:35] <pitti> right
[15:42]  * pitti waves good bye, holiday o'clock -- see you all in two weeks!
[15:43] <Laney> see you pitti, have fun!
[15:43] <pitti> thanks!
[15:43]  * pitti disconnects from the hive, argh
[16:00] <slangasek> infinity, kees, stgraber: TB meeting?
[16:00] <stgraber> slangasek: thanks for the reminder
[16:42] <infinity> slangasek: Ungh.  A little timezone challenged this morning.
[17:18] <mterry> Laney, so...  I have a fix for the prompt & the session list.  But after going into the session list and back out again, there is a tiny visual glitch when switching between users.  I'm inclined to not care about that.  Haven't had luck fixing it yet.  Might just push as-is, especially if gtk3.20 is about to land
[20:18] <Laney> mterry: That's fine, it sounds small enough to deal with later if necessary
[20:18] <Laney> thanks a bunch for figuring it out
[20:19] <mterry> Laney, uploaded in -proposed already
[20:19] <mterry> you're welcome!  didn't want people to yell at me for a broken unity-greeter  :P
[20:20] <Laney> GTK's blocked on an MIR and one or two other uploads anyway, but yeah :)
[20:21] <mterry> working on that MIR right now
[20:22]  * Laney remembers to subscribe the team
[20:22] <Laney> I unsubscribed it when I un-MIRed
[20:24] <jbicha> Laney: did you see that vte is stuck in proposed because pcre2 is in universe?
[20:24] <jbicha> Laney: but it looks like the dependency isn't even used now https://git.gnome.org/browse/vte/commit/?h=vte-0-44&id=ce94be
[20:25] <Laney> jbicha: nope
[20:30] <jbicha> yeah, it builds fine without pcre2
[20:30] <Laney> I know, it's just new API
[20:31] <Laney> need to turn it off in gnome-terminal too
[20:36] <jbicha> Laney: could you do a no-change rebuild of webkit2gtk for gtk 3.20?
[20:37] <Laney> it's on the list
[20:38] <Laney> guess I could do it now though
[20:42] <Laney> jbicha: I did it
[20:42] <Laney> now before you give me any additional work, goodnight!
[20:42] <Laney> :)
[20:43] <jbicha> Laney: see ya :)