[03:01] <Logan> is there any reason why my MP [1] isn't showing up in the Sponsoring Overview [2]?
[03:01] <Logan> [1] https://code.launchpad.net/~logan/ubuntu/wily/python-idna/2.0/+merge/260031
[03:01] <Logan> [2] http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html
[05:06] <pitti> Good morning
[06:09] <Mirv> Logan: just time, now it's there
[06:10] <Logan> ah, thanks :)
[06:51] <dholbach> good morning
[07:05] <didrocks> @pilot in
[07:12]  * dholbach hugs didrocks
[07:12]  * didrocks hugs dholbach back
[07:56] <didrocks> Mirv: do you need an ubuntu-touch.wily upload now or prefer to wait?
[08:11] <Mirv> didrocks: the two MP:s would be good to land now already
[08:12] <Mirv> didrocks: thanks for merging them
[08:13] <didrocks> Mirv: yw! ok, uploading
[08:14] <Mirv> excellent!
[09:31] <Laney> cjwatson: Does archive_base/default in germinate-update-metapackage's update.cfg support multiple archives like /arch does (per g-u-m(1))?
[09:47] <cjwatson> Laney: Yes.
[09:47] <Laney> cjwatson: Ta. Wasn't entirely clear to me from the manpage
[09:47] <Laney> ogra_: Maybe this is useful to you
[09:48] <ogra_> Laney, you mean to the phone people :)
[09:49] <Laney> teflon hands
[09:49] <ogra_> hah
[09:50] <Laney> who wants this information?
[09:50] <ogra_> cjwatson, what Laney wants is a seed for the vivid+overlay phone PPA ... i wonder if that actually makes sense now that we will use that setup long term
[09:50] <ogra_> Laney, if only i knew :) i guess for the interim thats still me
[09:51] <Laney> Well you've just seen confusion with the seed branches; I was wondering if we could avoid that
[09:51] <ogra_> long term the phone team needs to grow some core-devs or we need to make it easy for sponsos
[09:52] <ogra_> +r
[09:52] <cjwatson> ogra_,Laney: I'd suggest just treating that as a continuation of ubuntu-phone.vivid
[09:52] <cjwatson> Laney: manpage> bug welcome
[09:52] <Laney> nod
[09:52] <cjwatson> (or git mp if you want to be experimental)
[09:52] <cjwatson> I can find out if I get useful mail! :-)
[09:53] <Laney> I'll put it on the list, got a few things to do first though
[10:07] <didrocks> @pilot out
[10:12] <rbasak> pitti: I'm stealing the apache2 merge. I trust that's OK?
[10:12] <pitti> rbasak: it's okay, plus "thank you!" :-)
[10:12] <pitti> rbasak: I earned tons of merges from drive-by systemd fixes, some library transition rebuilds and other stuff, always happy to lose some of them :)
[10:13] <mitya57> Mirv: do you know if Stephen's suggestion in https://codereview.qt-project.org/112053 (the last comment) will fix LP: #1457840?
[10:30] <jamespage> please could an  archive admin bump python3-cryptography and python3-hacking to main for wily - they are binary only movements - cheers!
[10:31] <pitti> jamespage: yep, will do, they are on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[10:32] <jamespage> pitti, indeed they are - just nudging as working an SRU that I'd like to land into wily first - but I'm blocked on dependency chain right now
[10:32] <jamespage> (and thanks)
[10:32] <pitti> lputils.PackageMissing: Could not find binaries for 'python3-cryptography/None' in wily-proposed
[10:32] <pitti> le huh?
[10:33] <pitti> oh, nevermind -- these binaries themselves aren't in -proposed
[10:34] <pitti> jamespage: done
[10:35] <jamespage> pitti, ta
[11:08] <xnox> doko_: gcc's 5.1 -fno-semantic-interposition causes testsuite failure in libvirt
[11:08] <xnox> were you considering to enable it by default?
[11:11] <doko_> xnox, is there an open issue? no, I'd like to avoid diverting from upstream
[11:12] <xnox> doko_: ok. at the moment only discussing it on libvirt mailing list.
[11:13] <xnox> the option seems very nice. but not sure about the fallout amount, especially since it appears to manifest at runtime, rather than build-time warning or some such.
[11:13] <xnox> doko_: also created mailing list.
[11:23] <mdeslaur> @pilot in
[11:27] <mpt> diwic, hi. Is the HDMI audio situation still as you described in <http://voices.canonical.com/david.henningsson/2012/04/14/audio-over-hdmi-and-displayport-in-ubuntu-12-04/>, where you can’t tell whether audio should go to an HDMI-connected display?
[11:29] <doko_> xnox, well, turning this on by default would be wrong
[11:29]  * dholbach hugs mdeslaur
[11:30] <xnox> doko_: yeah, also binutils breaks.
[11:32] <diwic> mpt, most of the stuff still holds
[11:33] <diwic> mpt, even for newer stuff like haswell and broadwell, there are usually several audio ports
[11:33] <diwic> mpt, but I guess slightly more often the vendors are polite enough to mark two out of the tree as unused
[11:33] <diwic> mpt, I'm not sure that answers your question - could you be more specific?
[11:36]  * mdeslaur hugs dholbach
[11:57] <sladen> nd the other 16 square metres,...?
[11:57] <sladen> meh
[12:08] <rbasak> pitti: you might be interested in bug 1457957. I tagged it systemd-boot as it's a consequence of the switch, but it's perhaps an upstream issue to keep up.
[12:14] <pitti> rbasak: thanks for the heads-up. I followed up
[12:25] <mpt> diwic, for the pocket PC, when you connect a phone to an MHL display, normally you’ll want audio to be played through that display’s speakers. If that isn’t automatic, we’ll need more settings UI than if it is automatic.
[12:26] <ogra_> mpt, and how do you know that MHL display is a display with physical speakers attached ?
[12:26] <ogra_> a normal monitor with MHL wont tell you ... and will most likely not have any speakers
[12:27] <ogra_> (a TV with MHL wont tell you either but that will at least have builtin speakers)
[12:29] <rbasak> pitti: thanks. Also bug 1457886 - probably invalid since kernel commandline is used (and permitted to be used) for anything, including for plymouth(?) to pay attention to the "splash" argument?
[12:29] <mpt> ogra_, yay, it’s nice to know that new hardware interfaces repeat the mistakes of their predecessors :-]
[12:29] <rbasak> pitti: I'm not confident enough in the internals there to triage that though, although I think I know what's going on.
[12:30] <ogra_> mpt, heh, yeah ... well, i dont think the designers of the EDID specification thought about routing audio through video cables when they designed EDID back when VGA was a thing :)
[12:31] <ogra_> but even if the EDID info could tell you that the display is audio capable you wont know if there are actual pysical speakers
[12:31] <mpt> Yeah, it’s not like any displays had built-in speakers in 1994
[12:34] <diwic> mpt, to sum up, the problems are two-fold here - one is that we have some "unused" HDMI ports that the driver reports as being there but unconnected. That can likely be fixed on a per-hardware basis, so if we do a pocket PC we can put in a driver patch for that.
[12:34] <pitti> rbasak: this looks like serious PEBCAK; I followed up and subscribed, but probably non-sense
[12:34] <diwic> mpt, what ogra_ is talking about is harder, i e, figuring out whether or not there are speakers on an HDMI (or DP, or MHL) connection.
[12:34] <diwic> mpt, that said I'm not very familiar with MHL at all.
[12:35] <ogra_> i thionk you shoould keep audio on the phone spakers for now
[12:35] <mpt> diwic, so, we will need UI for whether to use the display’s speakers or not
[12:35] <ogra_> and rather offer a UI to the user to switch back and forth
[12:36] <ogra_> or a popup pn MHL connection asking if you want to re-route the sound to the display
[12:36] <rbasak> pitti: I was under the impression that the kernel gave /sbin/init the kernel commandline in argv too? Maybe not. Anyway, my uncertainty is why I referred to you. Thanks :)
[12:36] <pitti> rbasak: it looks like he tried something like init="/sbin/init splash"
[12:36] <diwic> mpt, like the unity-system-settings in v14.04 desktop already does, so I'm assuming your talking about something else?
[12:37] <pitti> rbasak: ah, it indeed seems to do that (everything after init=)
[12:37] <pitti> rbasak: but then I still fail to understand what the problem is
[12:37] <mpt> diwic, yes, ubuntu-system-settings on the phone
[12:38] <diwic> mpt, ok
[12:42] <rbasak> pitti: what the problem is> yeah - inits are designed to get random stuff from the kernel commandline, and random stuff uses the kernel commandline. So traditionally not-understood arguments are just ignored and that should be fine.
[13:25] <cyphermox> good morning!
[13:27] <mdeslaur> hi cyphermox
[13:27] <cyphermox> hey mdeslaur
[13:47] <smoser> Laney, gnome-terminal "Apply fix from Ed Catamur to wait on the server instead of the client in --disable-factory mode. This is compatible with previous versions of gnome-terminal." .
[13:47] <smoser> that changed the default behavior of gnome-terminal to block. was that intended ?
[13:47] <Laney> only if you pass --disable-factory
[13:47] <Laney> yes
[13:47] <smoser> for me it blocks always
[13:48] <Laney> it shouldn't go into that path then, if it does then that's a bug
[13:48] <Laney> will look shortly
[13:48] <smoser> ie, just with 'gnome-terminal'
[13:52] <Laney> smoser: ah right, I think I messed up a conditional, thanks for noticing!
[13:55] <smoser> Laney, thanks for bringing 'disable-factory' back.
[13:55] <smoser> i do like it.
[14:00] <Laney> smoser: np - I'm surprised that quite a lot of people seem to use it
[14:00] <Laney> I thought it would just be pleasing like 5 geeks :)
[14:00] <Laney> can you try lp:~ubuntu-desktop/gnome-terminal/ubuntu ?
[14:00] <larsu> smoser, Laney: gnome-terminal (without arguments) is supposed to block until you close that terminal, no?
[14:00] <Laney> not upstream
[14:00] <larsu> same with gedit
[14:01] <Laney> I only intended to override their behaviour when you give --disable-factory
[14:02] <Laney> We could do it always but I didn't think about that yet
[14:05] <larsu> I was pretty sure that this is what it does upstream. Discussed this with desrt countless times
[14:06] <larsu> let me see
[14:09] <smoser> larsu, that would be sane behavior. but 'disable-factory' became necessary probably in the 12.04 time frame.
[14:09] <smoser> otherwise 'gnome-terminal' would talk to the factory, create a window, and return immediately.
[14:09] <smoser> then, upstream removed 'disable-factory'.
[14:10] <larsu> smoser: it seems to do that upstream, but that's totally wrong. It should block until the tab/window it opened is closed
[14:10] <smoser> larsu, well, arbitrarily changing back and forth in ubuntu is not helpful to people.
[14:11] <Laney> OK, I'm not trying to fix that now though, we can work that through upstream
[14:11] <larsu> smoser: ya, Laney is working hard on keeping compatibility, but it's not easy. Lots of upstream changes and *many* use cases
[14:11] <smoser> and differing with upstream isnt either. i personally think the behavior of "block unless otherwise told to" is better. but that is different than it is in 14.04, 14.10 and upstream.
[14:12] <smoser> just for random bit of information... https://gist.github.com/smoser/1ee3f2b223717625c5f4
[14:13] <smoser> that is my garbage "xvim" which launches ggnome-terminal -e vim. and blocks even without --disable-factory (ie, you have to have that in 14.10 if you want pentadactyl ctrl-i to work or something like that).
[14:18] <larsu> crazy. I'll look into it upstream
[14:22] <doko> infinity, gccgo, did we have any successful builds in wily?
[15:04] <infinity> doko: Not a lot of go packages to test that theory with, but the tree I can spot (nuntium, lxd, and docker.io) haven't built successfully since vivid, no.
[15:06] <Mirv> mitya57: I think modifying that patch alone didn't help alone as the other patches make the switch from pie to pic and our core problem was the reduce relocations breaking unity8. but I can't now remember whether I tried to enable the two other patches only while not setting the reduce relocations option. and I guess I should try gcc5 too even before it's made the default so that it's known whether we'll need some linker expert
[15:07] <Mirv> mitya57: sorry for the delay, my afternoon got quite swamped suddenly
[15:23] <mdeslaur> @pilot out
[16:02] <ptrz> how would I go about getting the libnice package updated?
[16:03] <ptrz> it's going to have to be newer for the next major Pidgin release. The current libnice repo head builds and checks on 15.04.
[16:05] <infinity> pitti: TB meeting?
[16:05] <pitti> infinity: whoops, thanks
[16:05] <pitti> that late already
[16:34] <ptrz> how would I go about getting the libnice package updated?
[16:34] <ptrz> it's going to have to be newer for the next major Pidgin release. The current libnice repo head builds and checks on 15.04.
[16:45] <mitya57> Mirv: ok
[16:46] <mitya57> Yes, testing with gcc5 will be nice. If it remains broken, maybe we should bother upstream.
[17:24] <elopio> I'm having this problem with bzr: https://bugs.launchpad.net/bzr/+bug/1458946
[17:24] <elopio> any idea what that means?
[17:37] <smoser> elopio, i just came here to complain about same thing.
[17:38] <smoser> i think it only occurs if you're launchpad-login'ed
[17:38] <elopio> it's good I'm not alone.
[17:39] <pitti> slangasek, stgraber: just FYI and a chuckle: debian bug 786902
[17:42] <smoser> elopio, but it seems its likely on server side rather than package
[17:45] <smoser> elopio, it seems that canonical IS is working on this.
[17:45] <smoser> should be fixed soon-ish.
[17:47] <elopio> thanks for the update smoser.
[17:50] <smoser> elopio, seems "fixed for me" at the moment.
[17:50] <elopio> smoser: works here too. I'll update the bug.
[17:57] <slangasek> pitti: yeah, are you chuckling about the orphaning in general or about the suggestion that we switch to one written in python? ;-P
[17:58] <infinity> Oh dear lord, pleast not a python rewrite.
[17:59] <ogra_> lol
[18:01] <slangasek> infinity: too late! http://cumulusnetworks.com/blog/ifupdown2/
[18:17] <infinity> slangasek: Oh, I'm well aware of it, I was not aware that anyone took it seriously.
[18:17] <cyphermox> in theory there is code for it.
[18:44] <pitti> slangasek: more like "no time any more to maintain one implementation, so let's make two!" :/
[18:45] <slangasek> ;)
[18:45] <pitti> more seriously, this actually does sound a bit worrying