[00:06] <stgraber> ogra_: hey, you're on slashdot now ;)
[00:06] <ogra_> yep, just linked my blog there
=== freeflying_away is now known as freeflying
[00:11] <mdeslaur> ogra_: dude, rainbows and unicorns from now on :)
[00:11] <ogra_> haha
[00:13] <slangasek> I personally don't want rainbows on my computer
[00:15] <StevenK> slangasek: But you don't object to unicorns?
[00:15] <mdeslaur> slangasek: that's ok, rainbows are level 5, so they don't get installed by default
[01:20] <gaughen> slangasek, I missed a rainbow and unicorn discussion? I'm so sneaking a rainbow onto your laptop next time I see you.
[01:20] <slangasek> heh
=== freeflying is now known as freeflying_away
=== jono is now known as ubuntu-goldfish
=== freeflying_away is now known as freeflying
=== thegodfather is now known as fabbione
[05:15] <Mirv> rsalveti: ok (for the qtbase patch)
[06:02] <pitti> Good morning
=== doko_ is now known as doko
[08:17] <arun_> Hello to the devs
[08:17] <arun_> and the lurks xD
=== iahmad is now known as iahmad|afk
[08:30] <sabgenton> are the trusty builds usable at the moment (fun enough)
[08:30] <sabgenton> ?
=== iahmad|afk is now known as iahmad
[09:08] <zyga> good morning
=== freeflying is now known as freeflying_away
=== freeflying_away is now known as freeflying
[09:58] <pete-woods> didrocks: good morning! If I want to land a new(ish) package (https://launchpad.net/unity-voice) are you still the go-to guy?
[09:59] <didrocks> pete-woods: yeah, please get a landing ask added for tracking it (with a rationale ;))
[09:59] <didrocks> pete-woods: and then, we'll take care of it
[10:00] <pete-woods> didrocks: is that in the spreadsheet thingy?
[10:01] <didrocks> pete-woods: right!
[10:01] <pete-woods> okay, thanks!
[10:01] <didrocks> yw ;)
[10:03] <pete-woods> hmm, no write permissions, manager get!
[10:04] <didrocks> pete-woods: time to make them working! :)
[10:24] <xnox> rsalveti: yes it does. At the moment apart from limited RAM, it also limits available heap which may need increasing. I didn't figure out how to "trigger" stuck or what is causing it.
=== Ursinha-afk is now known as Ursinha
[11:05] <tseliot> pitti: hey, I've just uploaded nvidia-settings, as you requested, but it ended up in NEW
[11:06] <sveinse> Is there a one-line tool to install the build depends from the list in debian/control ?
[11:07] <pitti> tseliot: ah, so it's possible to make them versionless?
[11:07] <tseliot> pitti: yep. If there are compatibility issues, I'll just patch the code. I did it in the past
[11:09] <pitti> tseliot: nice! so this needs to C:/R:/P: the old versioned ones until after 14.04
[11:10] <pitti> tseliot: ah, I guess we still need transitional packages as well, but fortunately we can drop them all in some 5 months
[11:10] <tseliot> pitti: yes, the transitional packages are there and the package also C:/R:/P: the nvidia-settings-binary virtual package
[11:23] <pitti> tseliot: after that we'll remove nvidia-settings-* sources, right?
[11:23] <tseliot> pitti: that's the hope
[11:23] <pitti> tseliot: so glad about dropping python-gtk2 :) (what does the UI use? is that C?)
[11:24] <pitti> tseliot: would you mind fixing the package descriptions for the transitional packages?
[11:24] <pitti> tseliot: +Package: nvidia-settings-319-updates
[11:24] <tseliot> pitti: nvidia-settings is C and GTK+ (2)
[11:24] <pitti> +Description: Transitional package for nvidia-settings-319-updates
[11:24] <pitti> tseliot: it should be a transitional package for nvidia-settings, i. e. please specify the "target" package name, not the package's own name
[11:24] <pitti> (just a nitpick)
[11:25] <pitti> tseliot: and we need one for -310 as well
[11:25] <pitti> (two, for -updates)
[11:25] <pitti> tseliot: I guess you can probably drop the control.in magic then (not relevant for NEWing, just jumped my eye)
[11:25] <tseliot> pitti: and for nvidia-settings-313-updates, nvidia-settings-experimental-304 and nvidia-settings-updates too, I assume
[11:26] <pitti> tseliot: ah, I don't see these in the trusty source lists, but they might be in precise or PPAs?
[11:26] <tseliot> pitti: definitely in precise. I can see them in trusty if I call apt-cache search nvidia-settings
[11:27] <pitti> tseliot: looks good otherwise; shall I reject and you reupload with the transitional fixes?
[11:27] <tseliot> pitti: yes, please reject
[11:28] <pitti> tseliot: done
[11:32] <tseliot> pitti: would something like this be ok (I'll drop the control.in in a later release)? http://paste.ubuntu.com/6442329/
[11:33] <pitti> tseliot: LGTM
[11:33] <tseliot> pitti: ok, let me reupload
[11:33] <pitti> tseliot: these old versions all provide nvidia-settings-binary, right?
[11:33] <tseliot> pitti: I think so but let me check
[11:34] <pitti> tseliot: e. g. nvidia-settings-experimental-304 doesn't
[11:34] <tseliot> pitti: it's a transitional package
[11:34] <pitti> tseliot: so that needs an explicit C/R
[11:34] <pitti> ah
[11:35] <pitti> indeed, to nvidia-settings-304-updates
[11:35] <pitti> tseliot: ok, sorry for the noise
[11:35] <tseliot> pitti: all the nvidia-settings packages in trusty http://paste.ubuntu.com/6442345/
[11:36] <tseliot> everything seems ok
=== _salem is now known as salem_
=== brainwash_ is now known as brainwash
=== MacSlow is now known as MacSlow|lunch
[12:04] <tseliot> pitti: it's in new again
[12:06] <pitti> tseliot: splendid, thanks! accepted
[12:10] <tseliot> pitti: thanks!
=== pete-woods is now known as pete-woods|lunch
[12:39] <seb128> Laney, mardy: I tried e-d-s 3.10 from https://launchpad.net/~laney/+archive/gnome-transition/ with uoa, that doesn't work nicely :/
[12:40] <seb128> Laney, mardy: the first thing that happens after adding a google account is a notification saying that the account has been desactivated and that you need to grant access again ... which seems to happen when you start evolution as well
[12:40] <seb128> Laney, mardy: I never managed to have my calendar working either, it's showing in evolution but stucked on "loading" and never loading any content, the indicator is empty as well
[12:41] <mardy> seb128: so, I think that the first issue is actually the correct behaviour: the first time you use EDS, you need to authorize it
[12:42] <mardy> seb128: because it's using its own application key for Oauth
[12:42] <seb128> mardy, the UI saying that your account has been desactived, when you just added it, feels weird
[12:42] <seb128> could we serialize ask for it before ending the account adding?
[12:42] <mardy> seb128: mmm... are you sure? It should just say that it needs to be authorized
[12:42] <mardy> seb128: that would be nice
[12:43] <mardy> seb128: yes, I think we could do that
[12:44] <Laney> yeah the calendar doesn't work for me either
[12:44] <Laney> email does though, which is an improvement on before
[12:44] <mardy> seb128: can you please file a couple of bugs?
[12:45] <seb128> mardy, sure, on what component? uoa for the UI/workflow one? e-d-s upstream for the calendar?
[12:46] <mardy> seb128: gnome-control-center-signon for the UI, EDS for the calendar
[12:48] <mardy> seb128: BTW, is there something broken with autolanding? In the last few days I updated a few projects, got the new code to trunk, but I cannot find any new packages in the archives
[12:48] <mardy> seb128: like this one: https://code.launchpad.net/account-plugins
[12:49] <mardy> (it adds Windows Live support to e-d-s)
[12:50] <Saviq> slangasek, hey, just noticed one, potentially easy fix for cross-building, but I still can't wrap my head around what needs to be done there ;)
[12:50] <seb128> mardy, thanks
[12:50] <Saviq> slangasek, unity8 depends on qt5-default, which provides /usr/lib/arm-linux-gnueabihf/qtchooser/default.conf
[12:51] <seb128> mardy, the notification says that "the application no longer has access to..." (just checked the wording), which is weird when you just created the account
[12:51] <Saviq> slangasek, but for the cross-build to work, it should install qt5-default:amd64 instead, so that it provides
[12:51] <Saviq> /usr/lib/x86_64-linux-gnu/qtchooser/default.conf
[12:51] <seb128> mardy, @landings: they stopped happening automatically, somebody needs to do a landing ask nowadays ... they did that to limit regressions because saucy and it's still the rule
[12:52] <seb128> mardy, you need an entry on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
[12:52] <Saviq> slangasek, but qt5-default:amd64 pulls in qtbase5-dev:amd64, which conflicts with otherwise-needed qtbase5-dev:armhf
[12:53] <Saviq> slangasek, so what do we do for qt5-default:amd64 to be pulled in, but for it not to be pulling in qt5base-dev:amd64?
[12:53] <mardy> seb128: mmm... will it be forever like this, or will landings return automatic soon?
[12:56] <xnox> Saviq: i mangled local config files for qt to make it "work"  thus avoiding installing qt5-default package at all.
[12:56] <xnox> (well qmake et al)
[12:56] <seb128> mardy, they are redesign the system, it's not going back to full automatic but it should be light way to ask for landing
[12:56] <Saviq> xnox, well, sure, it's as easy as exporting QT_SELECT
[12:56] <seb128> mardy, they idea is to control better what is landing and when so they can keep touch images under control
[12:56] <xnox> Saviq: and CMake needs fixes to find correct multi-arch paths, which I should really fix up and upload into archive.
[12:57] <Saviq> xnox, I recently sent a unity8-cross-build-recap to slangasek, let me fwd it to you
[12:57] <mardy> seb128: OK, thanks, I'll request access to the document then
[12:57] <xnox> Saviq: i think you can get away with Build-Depends: qt5-defaults:any
[12:57] <seb128> mardy, thanks
[12:58] <Saviq> xnox, can I? that might pull in :amd64, sure, but then would pull qtbase5-dev:amd64 as well
[12:58] <Saviq> xnox, when we need :armhf for that
[12:58] <xnox> Saviq: you cannot specify ":armhf", but you can specify "qtbase5-dev" as a build-dep.
[12:58] <mardy> seb128: actually, to whom should I request access to edit this document?
[12:59] <xnox> Saviq: hm, maybe i got this wrong. let me look at the actual packages.
[12:59] <Saviq> xnox, sure, we do already, but how will that help with qt5-default:amd64 pulling qtbase5-dev:amd64?
[13:01] <seb128> mardy, the managers and techleads should have access ... so ask your manager, or just go ask on #ubuntu-ci-eng if you can get write rights (that's the channel for the CI work)
[13:01] <xnox> Saviq: wait, can you not instead of qt5-default build-depend on: qtbase5-dev-tools:native, qtbase5-dev ?
[13:01] <xnox> Saviq: with appropriate config, cause it's the qtbase5-dev-tools that provide the "moc" utility.
[13:02] <Saviq> xnox, you tell me ;)
[13:02] <Saviq> xnox, I need moc, qdbusxml2cpp at least
[13:02] <xnox> Saviq: imho qt5-default package is evil, as it's not co-installable for cross-compilation, nor co-installable for qt4/qt5 compilations.
[13:03] <Saviq> xnox, qt5-default is just the easiest, 'cause then I don't need to hunt for the binary
[13:03] <xnox> Saviq: =)
[13:03] <xnox> Saviq: yeah, so qtbase5-dev-tools has syncqt, uic, moc, qdbusxml2cpp qdbuscpp2xml rcc qdoc
[13:03] <Saviq> xnox, seems to be coinstallable for cross-compilation at least
[13:04] <xnox> Saviq: well at one point in time it had conflicts. E.g. sudo apt-get install qt5-qmake:amd64 qt5-qmake:armhf, conflict with each other.
=== MacSlow|lunch is now known as MacSlow
[13:07] <Saviq> xnox, the only thing that conflicted now for me was qtbase5-dev:armhf and :amd64
[13:07] <Saviq> xnox, biab, otp
[13:08] <xnox> Saviq: for cross, one should build-depend on dpkg-cross and use the CMake toolchain file /etc/dpkg-cross/cmake/CMakeCross.txt
[13:08] <xnox> Saviq: which actually finds the correct pkg-config =)
[13:08] <xnox> Saviq: and corrects library search paths.
[13:08] <Saviq> xnox, that's new :)
[13:08] <xnox> Saviq: that has been available from way before this new thing MultiArchCross.cmake
[13:09] <xnox> Saviq: I guess the two should merge, and it would be nice for upstream to ship that file.
[13:09] <xnox> Saviq: where are your sources which I can play around with? or is it pure unity8 src package as in the archive at the moment?
[13:09] <Saviq> xnox, lp:unity8 yeah
[13:10] <Saviq> xnox, everything else that was needed is in my email
[13:10] <xnox> Saviq: gotcha.
[13:11] <xnox> Saviq: here is my poor mans solution to cross-compile https://wiki.ubuntu.com/Touch/CrossCompile
[13:12] <xnox> Saviq: if one is using chroot, one can avoid co-installing libapparmor1 for example.
[13:18] <Saviq> xnox, oh yeah I'm doing sbuild of course
[13:18] <xnox> cool =)
[13:19]  * xnox waiting for mk-sbuild --target=armhf trusty to complete
[13:19] <Saviq> xnox, I wonder, how can we make CMAKE_TOOLCHAIN_FILE=/etc/dpkg-cross/cmake/CMakeCross.txt more automagic?
[13:19] <geser> ogra_: I hope you know what you have started with your mail to the ubuntu-devel ML about Mint: http://www.golem.de/news/sicherheit-mit-linux-mint-wuerde-ich-kein-onlinebanking-machen-1311-102830.html
[13:21] <ogra_> geser, no,  i didnt notice that i'm standing in the middle of a shitstorm since two days :P
[13:21] <xnox> Saviq: debhelper already does many magic stuff for cross-case, so dh can be taught to add that. As long as it works for many / most cmake packages.
[13:21] <xnox> Saviq: but it needs an extra build-dep. Not sure if dpkg-cross is build-essential enough in cross-cases.
[13:21] <ogra_> geser, sadly golem refuses to also link my response to their article it seems http://ograblog.wordpress.com/2013/11/18/lots-of-canonical-in-my-mouth/
[13:25] <ogra_> geser, like omgubuntu, phronix or other news sites do ... http://news.softpedia.com/news/Ubuntu-Developer-Says-Mint-Controversy-Might-Help-Them-Fix-the-Security-Updates-Problem-401422.shtml is the only one that picked it up ...
=== pete-woods|lunch is now known as pete-woods
[13:28] <highvoltage> that whole issue is such a nontroversy. any rational person would always agree with ogra_ no matter what he says.
[13:29] <ogra_> thanks :)
[13:33] <seb128> ogra_, ignore the trolls, that one is not even a good troll ;-)
[13:36] <ogra_> seb128, well, what bothers me is that news sites i used trust suddenly seem to lose all objectivity and refuse the opportunity to to state my opinion even though they report about me ... (golem and heise are two i regulary read, heise hasnt picked up on it yet, but golems ignorance towards me is pretty disappointing)
[13:39] <seb128> ogra_, having a good troll probably bring them more readers :/
[13:39] <ogra_> definitely
[13:39] <ogra_> i totally understand the intend and process ... but it would still be nicer if they could also show my POV
[13:41] <highvoltage> ogra_: if they twist your words to mean something completely different to what you said then their intent was definiely not in good spirit
[13:43] <ogra_> no, indeed not, but pushing an update with "Canonicasl developer responded" would at least give them another few clicks ... and at least pretend some objectivity
[13:49] <sladen> ogra_: s/maintained one for/maintained one of/
[13:50] <xnox> ogra_: I only read BBC News and New York Times. Neither of which are yet to miss-quote you =)
[13:51] <ogra_> xnox, damn ... so much about my career in the TV ad business ... still not enough popularity
[13:52] <sladen> now where's a link to those Canonical TV ads when you need one
[13:52] <ogra_> lol
[13:52] <ogra_> sladen, thanks, fixed..  btw
=== olli_ is now known as olli
[13:54] <Saviq> xnox, if you manage to reduce the steps needed to cross-build u8, please let me know :)
[13:59] <rsalveti> xnox: right, I'm trying to disable a few services to see what is causing it, at least to isolate it a bit more
[13:59] <rsalveti> Mirv: thanks
[13:59] <rsalveti> Mirv: I can sponsor the upload, but need to check with the landing team
[14:00] <rsalveti> seems xnox just uploaded it, so cool
[14:00] <rsalveti> xnox: did you coordinate the landing with the landing team?
[14:00] <rsalveti> xnox: as I know they were working on landing mir and a few other big blocks yesterday
[14:00] <Mirv> rsalveti: yeah, it got uploaded already
[14:01] <Mirv> it probably flew past the landing chart as such
[14:01] <slangasek> xnox: hi, coming to http://summit.ubuntu.com/uds-1311/meeting/22028/core-1311-dmraid2mdadm/ ?
[14:02] <xnox> slangasek: yes. it looks like i'll have to setup the hangout?
[14:02] <rsalveti> Mirv: right, well, it's already in, so let's hope it'll not cause any issue :-)
[14:02] <slangasek> xnox: no, it's set up and waiting for you
[14:02] <xnox> slangasek: one hour too early?
[14:02] <slangasek> orly
[14:02]  * slangasek checks his clock
[14:03] <slangasek> oh hah, plenaries this hour
[14:03] <seb128> right
[14:03] <seb128> slangasek, you almost scared me for a minute there ;-)
[14:03] <slangasek> ok, nevermind then :-)
[14:03] <xnox> slangasek: yeah, i think summit should "pre-star" the plenaries.
[14:03] <xnox> for everyone.
[14:22] <arges> cjwatson: hey. I know you spoke with jpds about this already. would you like me to handle the SRU for bug 901700? thanks
[14:22] <ubottu> bug 901700 in netcfg (Ubuntu Precise) "netcfg segfauts when preseeding 12.04 LTS" [High,Triaged] https://launchpad.net/bugs/901700
[14:22] <cjwatson> arges: Oh, if you like and if you can readily test it, I certainly wouldn't object to having it taken off my hands :-)
[14:23] <arges> cjwatson: sure, I'll handle it then. : )
[14:23] <cjwatson> Brilliant, thanks
=== sraue_ is now known as sraue
[14:50] <seb128> mardy, https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1252751
[14:50] <ubottu> Ubuntu bug 1252751 in gnome-control-center-signon (Ubuntu) "when adding an account, should register apps as well" [Undecided,New]
[14:50] <seb128> mardy, https://bugzilla.gnome.org/show_bug.cgi?id=712687
[14:50] <ubottu> Gnome bug 712687 in Calendar "Ubuntu online accounts support doesn't work with calendars" [Normal,Unconfirmed]
[14:50] <seb128> Laney, ^
[14:51] <mardy> seb128: thanks!
[14:51] <Laney> cheers
=== pete-woods is now known as pete-woods|afk
[14:52] <Laney> seb128: maybe we should leave it off
[14:52] <seb128> Laney, yeah, but I still would like to see it fixed before the LTS...
[14:52] <Laney> indeed
[14:52] <roaksoax> apw: ping
[14:53] <roaksoax> apw: do you maintain avahi?
[14:53] <seb128> roaksoax, I don't think we have an official avahi maintainer, it's mostly in low maintainance mode/maintained in Debian, why?
[14:53] <apw> roaksoax, not especially, i have recently fixed it for kernel feature missmatches
[14:53] <apw> roaksoax, need something?
[14:54] <roaksoax> apw: I'm about to sponsor this http://people.canonical.com/~serge/avahi-nproc.debdiff
[14:54] <roaksoax> seb128: ^^
[14:54] <roaksoax> just wan't to make sure people is ok with us doing that
[14:54] <apw> not an issue for me indeed
[14:54] <roaksoax> since we need it sru'd into saucy
[14:54] <roaksoax> apw: thanks!
[14:54] <Laney> isi t upstreamed?
[14:56] <seb128> roaksoax, ^ what Laney asked, we should have an upstream bug reference in the patch there
[14:56] <Laney> patch headers ;-)
[14:56] <roaksoax> hehe ok
[14:58] <fishor> any devs for sound subsystem here? (pulseaudio/alsa) ... i tried to find some one upstream, but no answers for a week. Now to the issue: internal mic in my laptop has too match boost, if i set on on maximum noise will go to the capture limits.  It make troubles for VoIP apps. I can blacklist it in alsa driver and provide patch for it... but before i do it i would like to know if there other options
=== sraue_ is now known as sraue
[15:22] <bregma> should Trusty packages be using Standards-Version 3.9.5 now?
[15:31] <mitya57> bregma: Yes, but keep in mind that a Lintian version with 3.9.5 support is not yet released.
[15:32] <bregma> mitya57, upstream in Debian or here in Ubuntu?
[15:33]  * bregma is used to lintian complaining about future Standards-Version in Ubuntu
[15:33] <mitya57> Lintian is mostly in sync now.
[15:33] <mitya57> So we'll quickly merge the new lintian when it's released.
[15:34]  * mitya57 notices that the latest lintian FTBFS
=== salem_ is now known as _salem
[15:51] <ev> heads up: we're going to be discussing how the CI engine is going to be rearchitected, starting in 10 minutes. If you'd like a speaking slot in the hangout, let me know.
[15:53] <cjwatson> oww, now I have to rebase grub2/debian/patches/install_signed.patch across to a rewrite of grub-install in C
[15:53] <cjwatson> I guess it'll be neater on the other side :-)
[15:56] <ev> http://summit.ubuntu.com/uds-1311/meeting/22092/core-1311-ci-airline/ being the URL for that
=== bdrung_ is now known as bdrung
=== adam_g is now known as adam_g_afk
=== Sp4rKy_ is now known as Sp4rKy
=== _salem is now known as salem_
=== jamespag` is now known as jamespage
=== masACC is now known as maswan
=== cyphermox_ is now known as cyphermox
=== pgraner` is now known as pgraner
=== tlyu_ is now known as tlyu
=== kees_ is now known as kees
=== SpamapS_ is now known as SpamapS
[17:35] <hero> hello
[17:35] <hero> I get an error when trying to compile gtk3;
[17:35] <hero>  could someone help ?
[17:37] <hero> http://paste.ubuntu.com/6443915/
=== debfx_ is now known as debfx
[18:43] <vermahim> hi, i am using ubuntu 13.10, i am looking for a software(preferably small in terms of code) which is written(or majority of code) in C/C++, please help me out
[18:54] <kenvandine> xnox, ping
[18:55] <xnox> kenvandine: hi!
[18:55] <kenvandine> boost1.54 is held in proposed because boost-mpi-source1.54 has depends binaries from boost1.54
[18:55] <kenvandine> specific versions
[18:55] <kenvandine>  libboost1.54-dev (= ${binary:Version}),
[18:56] <kenvandine> xnox, i assume a no change upload would fix it
[18:56] <xnox> vermahim: well, upstart for C, and unity8/mir e.g. C++.
[18:56] <kenvandine> but that seems fragile...
[18:56] <kenvandine> xnox, i see you recently touched it... so i pinged you :)
[18:56] <xnox> kenvandine: we split boost packages into main and universe ones because of mpi. And it should alway be uploaded in a matching pair.
[18:56] <kenvandine> ok, so that was expected :)
[18:56] <xnox> kenvandine: if it's held up, then it was a mistake. sorry about that. Let me check.
[18:56] <kenvandine> there was an upload yesterday
[18:57] <kenvandine> doko did an upload
[18:57] <xnox> kenvandine: and he should know better =)))))
[18:57] <kenvandine> hehe :)
[18:57] <cjwatson> yeah, looks like doko forgot about the split-source thing here
[18:57] <xnox> kenvandine: i'll fix it.
[18:57] <kenvandine> xnox, mind uploading a fix?
[18:57] <kenvandine> thx!
[18:57] <kenvandine> robru, ^^
[18:57] <kenvandine> robru, once that is gets rhough, we'll be able to build that stack
[18:58] <kenvandine> s/rhough/through/
[18:58] <xnox> kenvandine: after the sessions end. I'll fix it. so you will have it today.
[18:58] <kenvandine> thx
[18:58] <robru> xnox, thanks for fixing boost
[18:58] <robru> kenvandine, alright
[18:59] <vermahim> xnox: please provide the link for unity8/mir
[18:59] <vermahim> code
[19:01] <xnox> vermahim: bzr branch lp:upstart; bzr branch lp:unity8; bzr branch lp:mir
[19:01] <xnox> vermahim: or http://pad.lv/c/unity8 http://pad.lv/c/upstart http://pad.lv/c/mir
[19:07] <slangasek> ScottK: hi, able to join us? https://plus.google.com/hangouts/_/72cpjem29pg1ifaht4etlvkqc0
=== salem_ is now known as _salem
=== dpm is now known as dpm-afk
[20:49] <ScottK> slangasek: I thought the meeting was in like 10 minutes from now.
[20:49] <slangasek> ScottK: hmm, nope :/
[20:50] <ScottK> The time says 2013-11-19 19:05..20:00
[20:50] <slangasek> ScottK: so the one big question we couldn't answer... you've said that qt5 alignment is "not an issue" for 14.04, just to confirm, that means Kubuntu is not moving to Qt5 this cycle, right?
[20:50] <ScottK> Isn't that now?
[20:50] <slangasek> ScottK: no, it's currently 20:50 UTC
[20:51] <ScottK> Sigh.
[20:51] <ScottK> We anticipate packaging some parts of KDE Frameworks 5 this cycle, but not doing any fundamental switching.
[20:51] <slangasek> ok
[20:52] <ScottK> I don't know what the upstream version requirement will be.
[20:52] <ScottK> This is even less than we did for KDE 4 in Hardy.
[20:52]  * slangasek nods
[20:53] <infinity> ScottK: You actually remember hardy?
[20:53]  * infinity barely remembers last month.
[20:53] <ScottK> infinity: I have scars.
[20:53] <lifeless> the halycon days
[20:55] <ScottK> slangasek: I'm told (reading my backscroll) that 5.2 is what's needed for KF5.
[20:55] <ScottK> So we want 5.2, but we wouldn't fall over dead if we didn't get it.
=== mwhudson- is now known as mwhudson
[20:56] <slangasek> ScottK: ok - 5.2 is also what's targeted for the phone
[20:57] <ScottK> I'm listening to the session now.  I didnt' get annoyed yet.
[21:04]  * xnox giggles.
[21:04] <xnox> ScottK: are you shipping Framework5 for 14.04?
[21:05] <ScottK> xnox: Possibly some of it.
[21:05] <ScottK> Beta versions.
[21:06] <ScottK> We may just land them in backports to avoid having to be stuck with them.
[21:07] <xnox> ScottK: i see, but to do that you'd want 5.2 to be in.
[21:10] <ScottK> Yes.
[21:10] <ScottK> So I think we agree on what version we want.
[21:19]  * robru shakes fist at mterry!!!
[21:20] <mterry> robru, :(  what did I do?
[21:20] <robru> mterry, your merge *just* landed on unity-system-compositor, which conflicted with my own.
[21:20] <mterry> robru, hah!  I win
[21:20] <robru> mterry, jerk!
[21:20] <mterry> robru, what are you doing in usc?   /me peeks
[21:21] <robru> mterry, bad boost deps. https://code.launchpad.net/~robru/unity-system-compositor/drop-libboost-all-dev/+merge/195860
[21:21] <robru> mterry, but then I also did wrap-and-sort and it made a big ugly diff that conflicted with your really badly
[21:21] <mterry> robru, I see.  If what I'm looking at is right, please don't re-introduce xmir dep on u-s-c
[21:22] <mterry> robru, I moved that to new tiny package ubuntu-desktop-mir
[21:24] <robru> mterry, pushed a new commit, can you check it's sane?
[21:25] <mterry> robru, what's the beef with libboost-all-dev?  Just that it's lazy?
[21:25] <mterry> robru, yeah looks fine, thanks!
[21:26] <mterry> robru, I guess I'll approve then
[21:26] <robru> mterry, well it's explicitely forbidden from main, which means when we eventually converge this change will be a prerequisite of the MIR, however the reason it came up today is because there was a minor boost transition that caused this to fail, specifically because of the -all-dev
[21:26] <jtaylor> were is the best place to ask about the vagrant cloud images?
[21:26] <utlemming> jtaylor: here works...whats up?
[21:26] <robru> mterry, thanks for the approve.
[21:26] <jtaylor> using virtualbox as provider the /vagrat folder blocks forever with the saucy images
[21:27] <jtaylor> precise images work
[21:27] <utlemming> jtaylor: I have seen that happen from time to time, but haven't had a chance to dig on that. Can you file a bug against it with supporting evidence? i.e. strace cat /vagrant/foobar?
[21:28] <jtaylor> utlemming: busy loop on getdents(...)
[21:29] <jtaylor> against which package should I file it?
[21:29] <utlemming> virtualbox itself...that is a problem with the the vfs that they present
[21:29] <jtaylor> actually cating a file works
[21:29] <jtaylor> but ls blocks
[21:29] <utlemming> odd
[21:36] <jtaylor> utlemming: bug 1252872
[21:36] <ubottu> bug 1252872 in virtualbox (Ubuntu) "saucy vagrant image shared folder 'ls' blocks" [Undecided,New] https://launchpad.net/bugs/1252872
[21:37] <utlemming> jtaylor: are you using our version of virtualbox or the one from upstream?
[21:37] <jtaylor> packaged virtualbox
[21:37] <jtaylor> 4.2.16-dfsg-3
[21:38] <utlemming> it would be interesting  to find out if you were to user the upstream what happens
[21:38] <jtaylor> I can try
[21:41] <jtaylor> hm vagrant in saucy does not support vbox 4.3 :/
[21:41] <jtaylor> but that should be fixed upstream
[21:48] <jtaylor> utlemming: same with latest vbox 4.3
[21:49] <utlemming> jtaylor: ack
[21:56] <jtaylor> I'll use a raring image in the meantime then
[22:02] <jtaylor> utlemming: trusty images have the same issue
[22:02] <utlemming> lovely
[22:16] <xnox> robru: i should have uploaded into archive, then mterry would conflict as well ;-)
[22:16] <robru> xnox, hahaha. well it's merged now and building in PPA, should hit archive soon
[22:17] <xnox> mterry: libboost-all-dev is (a) in universe (b) non-multiarch:sam (thus no cross-compilation) (c) causes un-neccesory FTBFS if boost is not in sync with boost-mpi-source (d) makes the build longer (e) causes the package not suitable for main inclusion.
[22:18] <mterry> xnox, makes sense  :)
[22:19] <xnox> =)
=== tkamppeter_ is now known as tkamppeter
=== bradm_ is now known as bradm
[23:08] <RAOF> Bah!
[23:08] <RAOF> vUDS hangouts on air tell me of all sorts of things that I could usefully have contributed to if they weren't on at 3am last night?
[23:10] <slangasek> RAOF: that's ok, we gave you all the work items
[23:10] <slangasek> I can haz system compositor?
[23:10] <RAOF> Indeed.
[23:10] <RAOF> That's *exactly*  what I'm listening to.
[23:10] <slangasek> :-)
[23:11] <RAOF> Yes, the plan is indeed to be able to run a Mir compositor in the initrd :)
[23:12] <RAOF> Good, good. You've argued yourselves 'round to the correct solution.
[23:12] <RAOF> Actually, we *do* have a partial Mir backend for plymouth.
[23:13] <slangasek> ok, where is it?
[23:13] <slangasek> I don't have anything that I can include in the plymouth package
[23:13] <slangasek> I'd love to do that, but so far I've been told everything is proof of concept
[23:13] <slangasek> as for including Mir in the initrd, the final conclusion of the session is that we'd rather not do any of the graphics stuff from the initrd, and just boot to the rootfs as fast as possible
[23:15]  * RAOF goes hunting for plymouth backend
[23:15] <infinity> slangasek: Does this mean we'll continue to have two different paths for encrypted root versus not?
[23:15] <slangasek> infinity: for the nonce
[23:16] <infinity> slangasek: I hate that the plymouth-in-initrd codepath is so poorly tested in contrast to the default.
[23:16] <slangasek> no it's not
[23:16] <RAOF> slangasek: https://code.launchpad.net/~rocket-scientists/plymouth/mir should work, I think.
[23:16] <slangasek> it's the only path I test before upload :-P
[23:16] <infinity> slangasek: Poorly exericed for corner cases that affect people who aren't Steve? :P
[23:16] <slangasek> RAOF: are you willing to turn that into an MP on the package?
[23:16] <infinity> exercised, too.
[23:16] <RAOF> slangasek: Sure, in the near future.
[23:17] <slangasek> RAOF: great :)
[23:17] <slangasek> anyway, plymouth-in-initrd becomes even hairier if we start using a mir backend... because while plymouth goes away and releases the framebuffer after boot, the system compositor would not
[23:17] <slangasek> at least, not by definition
[23:18] <infinity> I'm sure this was all covered in the session, but won't bringing up Mir take even longer than the already irritatingly long process of bringing up plymouth on a kms framebuffer?
[23:18] <slangasek> so then we either cope with never freeing the initramfs, which is a fair chunk of memory, or the system compositor needs to re-exec seamlessly
[23:18] <RAOF> Yeah; we need to re-exec the system compositor.
[23:18] <slangasek> infinity: "it depends"
[23:19] <RAOF> That should fall out naturally from our other goals.
[23:19] <slangasek> infinity: currently, waiting for the framebuffer device on Touch is probably slower
[23:20] <slangasek> RAOF: right; but it needs to be implemented before we can change plymouth's backend
[23:20] <RAOF> Indeed it does.
[23:20] <slangasek> and I'm very enthusiastic about getting to that point, since it means we no longer have to kill plymouth when lightdm starts
[23:20] <slangasek> and plymouth can continue to display/prompt as needed
[23:20] <slangasek> yay compositing :)
[23:21] <RAOF> :)
[23:22] <RAOF> Ah, I love that bit of a UDS session. “So, I think we know what needs to be done… who's going to do it?”
[23:27] <stgraber> that's usually the point at which we start throwing work items at everyone who should have been in the session and instead tried to escape it
[23:30] <infinity> I guess I should show up to more sessions.
=== freeflying is now known as freeflying_away
[23:46] <sergiusens> slangasek, hey, this is the wrong channel; but can you do a review for me or forward me to someone friendly? http://mentors.debian.net/package/golang-gocheck-dev
[23:49] <slangasek> hmm
[23:49] <slangasek> I wonder if that's something doko would be comfortable reviewing?
[23:50] <slangasek> afaik we don't have very strong policy around go packages yet, so there are probably only a handful of people who would feel comfortable reviewing - doko is one, the golang package maintainer is another
[23:51] <sergiusens> slangasek, is that stapelberg?
[23:51] <slangasek> sergiusens: yes
[23:51] <sergiusens> makes sense, I used his dh-golang and followed his wiki :-)
[23:51] <sergiusens> thanks
[23:52] <sergiusens> I'll see how I can reach out to him
[23:53] <infinity> If running it doesn't then proceed to go and download the actual package from an S3 bucket, you're miles ahead on quality from other Go packages I can mention...
[23:53] <jkitchen> hahahaha
[23:53] <slangasek> sergiusens: his email address is in the Maintainer: field :)