[00:04] <melodie> Chipzz thanks!
[00:19] <Andy80> hi
[00:20] <Andy80> I'm sorry to ask this, but what's happening to ubuntu-devel mailing list?
[00:20] <Andy80> I'm getting TONS of email since a couple of hours
[00:20] <Andy80> and I cannot stop them
[00:20] <Andy80> I've tried unsubscribing from ubuntu-devel ml and I'm still getting them
[00:23] <ogra_> there were 10 mails today on that list
[00:24] <Andy80> really I'm getting tons of them
[00:25] <Andy80> I don't know if these are just delayed emails and I'm getting them all at once
[00:25] <Andy80> but it's being very bad
[00:25] <ogra_> sounds more like a problem with your mailserver
[00:27] <Andy80> ogra_, https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/thread.html looking at the archive it seems the emails are a lot... anyway I'm using GMail, surely I can't fix it
[00:27] <cjohnston_> Andy80: over the past couple of days the list has 'blown up' in response to a proposal that was made
[00:27] <ogra_> not sure what you define a lot
[00:28] <Andy80> ogra_, I'm getting an email every 5-10 seconds
[00:28] <ogra_> right, there was some discussion, surely not what i define a lot though
[00:28] <Andy80> I didn't check if they're duplicated or not
[00:28] <Andy80> but it looks like they're not stopping
[00:28] <cjohnston_> I'd say there has been 100+ since Thursday.  5-10 seconds though is not what I'm seeing..
[00:29] <Andy80> I just marked everything as read and archived, and now I've other 6 emails :(
[00:29] <Andy80> I'm not joking, really :(
[00:29] <cjohnston_> Andy80: try checking a couple of them and see if your just very delayed in getting the emails that I've been getting over the last few days
[00:30] <Andy80> I will try to monitor the next I get
[00:31] <geofft> Andy80: you're not the only person I've heard who's getting the mails all at once
[00:31] <Andy80> geofft, do you know if those people were using GMail aswell?
[00:31] <ogra_> i'm actually forwarding that list through gmail and have no delays
[00:32] <cjwatson> If you need sysadmin help, you'd need to try #canonical-sysadmin; the greatest access level you're likely to find here is that of list moderator, which isn't sufficient to debug this kind of thing
[00:33] <ogra_> (gets me cheap spam filtering to hook gmail in the loop)
[00:34] <Andy80> cjohnston_, thanks! If I keep getting emails I will try to ask there if anyone can investigate (maybe at the moment nobody is working, better tomorrow)
[00:35] <geofft> Andy80: I suspect so.
[00:35] <cjwatson> You might find the start of the APAC shift
[00:56] <melodie> good night
[01:10] <jbicha> I stopped receiving ubuntu-devel emails several days ago, so I resubscribed to the list but started getting the missing emails a few hours ago too (also on gmail)
[01:12] <Andy80> jbicha, it looks like a common problem then :)
[01:13] <Andy80> time to go to bed now ;)
[01:13] <Andy80> see you all!
[01:26] <lifeless> SpamapS: ^ could have been what happpened to you ?
[03:52] <SpamapS> lifeless: indeed, though I have not seen any of the old ones arrive just yet
[03:53] <SpamapS> lifeless: and they definitely stopped on my last day at canonical.. so my guess is that it was some kind of sweep for my email/name that was too broad
[03:53] <SpamapS> or I was more bitter than I remember, and I did it and forgot ;)
[03:53] <infinity> SpamapS: Hah.  Probably just overbroad.  Or you were subscribed via you canonical.com address?
[03:53] <infinity> s/you/your/
[03:54] <SpamapS> I am 99.9% sure I subscribed w/ my @ubuntu.com email
[03:54] <SpamapS> but, there was some trouble with that particular email...
[03:54] <broder> i did not, fwiw, so probably not an @ubuntu.com issue
[03:54] <SpamapS> because I used clint@ .. but my launchpad id was clint-fewbar .. so I was sort of abusing my canonical username
[03:54] <SpamapS> I resolved that before my last day, but its entirely possible the sweep and the special forwarding privileges I got were not compatible
[03:55] <infinity> SpamapS: *nod*
[03:57] <bradm> gmail decided it didn't want to talk to our mail server for a little while after we upgraded it
[04:05] <bradm> SpamapS: fwiw, your clint@ address is still subscribed, and mail is being delivered to it.
[04:06] <SpamapS> bradm: I re-subscribed earlier today
[04:06] <SpamapS> bradm: at which time the emails started flowing again
[04:06] <bradm> SpamapS: if you're not on gmail, days ago.
[04:06] <SpamapS> my MX is a barracuda run by my friend's hosting company
[04:07] <SpamapS> but again, the ubuntu-devel emails stopped basically the day I departed Canonical, so I'm pretty sure either I unsubbed, or something went wonky
[04:09] <bradm> SpamapS: you were on ubuntu-devel with your @canonical.com address
[04:13] <SpamapS> bradm: *DOH*
[04:14] <SpamapS> bradm: thanks for checking
[04:19] <bradm> SpamapS: no worries.
[05:58] <pitti_> Good morning
[07:21] <pitti> ricotz: FYI, I uploaded https://launchpad.net/ubuntu/+source/udisks2/2.0.92-0ubuntu1 to raring, with a proper port of the "mount in /media" patch
[07:28] <ricotz> pitti, alright, thanks
[08:06] <dholbach> good morning
[08:16] <Quintasan> Hello
[09:29] <tkamppeter> Is there somewhere documentation about how to participate in the sessions of the UDS?
[09:35] <Riddell> tkamppeter: http://summit.ubuntu.com/uds-1303/2013-03-05/ has links to videos and irc rooms
[09:35] <Riddell> but I can't find anything about how to use google hangouts
[09:38] <tumbleweed> tkamppeter: someone mentioned https://wiki.ubuntu.com/OnAir/BestPractices on the planet
[09:44] <Laney> "The required participants for a meeting will also be given a link to participate in the hangout"
[09:44] <Laney> hmm
[09:49] <xnox> Laney: yeah, I don't like that. I did use required participation - only to force the scheduler to be sensible.
[09:50] <xnox> as well as to subscribe other people.
[09:50] <Laney> Unfortunate constraints imposed by the technology
[09:51] <xnox> Laney: all our base are belong to G+ ?
[09:51] <Laney> something like that
[09:52] <ogra_> better than to facebook :)
[10:09] <zyga> hey
[10:09] <zyga> update-manager is borked on raring as on version 1:0.183
[10:09] <zyga> someone might want to figure out an interesting fix
[10:10] <zyga> http://pastebin.ubuntu.com/5584706/
[10:10] <zyga> dholbach: do you know who maintains update-manager after mvo left?
[10:11] <dholbach> zyga, might be good to ask mvo directly - he's still on IRC you know :)
[10:11] <zyga> mvo: ping?
[10:11] <zyga> dholbach: yeah but he's not required to be here anymore
[10:11] <zyga> pitti: perhaps you know (unless mvo is faster) ^^
[10:11] <dholbach> well he's still part of the Ubuntu and Debian projects
[10:11] <Laney> have you filed a bug?
[10:12] <zyga> Laney: filing
[10:12] <zyga> it's a bit tricky
[10:12] <zyga> since ubuntu-bug rejects the bug :)
[10:12] <zyga> as updates are available
[10:12]  * zyga thinks that's an interesting exception where we should still be able to do so
[10:13] <pitti> zyga: the two error messages look fairly self-explanatory?
[10:13] <zyga> pitti: yes, they od
[10:13] <zyga> do
[10:14] <zyga> ok, filed as https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1144058
[11:04] <ivanka> hey seb128, have you got a sec?
[11:05] <seb128> ivanka, hey, sure
[11:05] <ivanka> seb128, how do I find what blueprints are being registered for this week?
[11:05] <seb128> ivanka, https://blueprints.launchpad.net/sprints/uds-1303
[11:05] <ivanka> seb128, sorry, there is probably an email buried in my inbox but was at MWC and still trying to catch up
[11:06] <mvo> zyga: hi, sorry for the delay - its group maintained AIUI, mterry is doing quite a bit of work on it too
[11:06] <seb128> ivanka, or just check the schedule http://summit.ubuntu.com/uds-1303/2013-03-05/display?edit and http://summit.ubuntu.com/uds-1303/2013-03-06/display?edit
[11:06] <seb128> ups
[11:06] <seb128> without the edit part
[11:06] <seb128> http://summit.ubuntu.com/uds-1303/2013-03-05/display
[11:06] <seb128> ivanka, let me know if need more details
[11:06] <seb128> ivanka, do you have sessions to add? the schedule is pretty packaged already, we had to make call on stuffs to drop from the list for client
[11:07] <ivanka> thanks seb128 - that should keep me quiet for the moment
[11:07] <seb128> ivanka, the community track might have some free slots still though
[11:07] <ivanka> seb128, I will have a look, but I spoke to pmcgowan before MWC and he suggested that the focus for the first UDS will be on fixes and background stuff so I get some time to prioritise UI elements
[11:08] <seb128> ok
[11:08] <zyga> mvo: hey, thanks for getting back to me
[11:08] <ivanka> seb128, we are just getting back the usability testing results and need to look at what design changes we need to make
[11:08] <ivanka> seb128, off to check the schedule! :-)
[11:08] <seb128> ivanka, good luck!
[11:08] <seb128> ;-)
[11:11] <ivanka> hey ckpringle there is a UDS session for app development
[11:11] <ivanka> ckpringle, I am subscribing you and making your participation essential
[11:11] <ivanka> ckpringle, I shall add Christina too? Mika? Anyone else?
[11:11] <ckpringle> ivanka: I think that is the session dpm is organising, we spoke about it last week but do you know when exactly it will be?
[11:12] <ckpringle> ivanka: the three of us would be nice, if we can't all go I at least will though.
[11:16] <ivanka> ckpringle, xchat just crashed on me! OK - will add the others
[11:16] <ivanka> ckpringle, I think it is one of the early sessions http://summit.ubuntu.com/uds-1303/2013-03-05/display
[11:16] <ivanka> ckpringle, as long as the sessions don't move too much
[11:17] <ckpringle> ivanka: there is also one at 6pm
[11:17] <ckpringle> ivanka "Ubuntu touch core apps project"
[11:32] <dpm> ckpringle, ivanka, the schedule is still a bit in flux, as we're populating it right now, and some sessions will need to be reshuffled if they clash with others with the same essential participants. Let me come back to you guys later on on the design sessions
[11:33] <ivanka> dpm, I am am just assigning people to Blueprints so, if they can't attend that can still contribute discussion points.
[11:34] <dpm> ivanka, excellent, sounds good
[11:35] <ivanka> seb128, what's Ubuntu Friendly?
[11:35] <seb128> ivanka, https://friendly.ubuntu.com/what-is-ubuntu-friendly/
[11:35] <seb128> ;-)
[11:36] <ivanka> seb128, oooh nice
[11:39] <ivanka> xnox, hi
[11:39] <ivanka> dpm, who is in charge of the schedule?
[11:42] <dpm> ivanka, there is a track lead for each track in charge of the schedule. For app development I am, then seb128 and jasoncwarner_ are for client, Daviey for server... etc.
[11:42] <dpm> sorry there are 2 track leads I meant to say
[11:42] <dpm> popey and I for app development, etc, etc
[11:42] <ivanka> dpm, great, thanks
[11:42] <dpm> Let me see if I can get you the full list
[11:42] <dpm> ok
[11:43] <ivanka> dpm, sorry, I am frantically trying to catchup as I was at MWC  last week
[11:43] <dpm> ivanka, no worries, happy to help in what I can
[11:43] <ivanka> thanks dpm
[11:43] <dpm> us who weren't in MWC are also frantically catching up at the pace things are running now ;)
[11:47] <melodie> hi
[11:55] <melodie> hello
[11:56] <melodie> I am trying to learn how to use gfxboot-examples in order to get a custom /isolinux/bootsplash archive with a init file in it containing a custom 800x600 jpg image. I read the examples, but when it comes to putting this in practice I am stucked with questions (the exemple is not clear enough to me).
[11:57] <melodie> I have also read this post: https://lists.ubuntu.com/archives/ubuntu-devel/2005-December/013846.html
[11:57] <melodie> and I wonder if someone here could help me understand how to use the exemple the right way ?
[11:58] <melodie> this is in Ubuntu Precise
[12:51] <bdrung> dholbach: re bug #1140613, please unsubscribe the sponsors team and set the bug to 'fix committed'
[12:51] <bdrung> dholbach: and this package has a dependency wait
[12:52] <dholbach> hum, weird - let me have another look
[14:12] <melodie_> hi, how are the official ubuntu versions creating their isolinux/bootlogo file ?
[14:13] <melodie_> I ask because I tried https://bugs.launchpad.net/ubuntu/+source/gfxboot-examples/+bug/1077339
[14:13] <melodie_> and it fails
[14:14] <melodie_> I would just want to change the color there: http://askubuntu.com/questions/10258/how-to-change-live-cd-splash-screen
[14:15] <melodie_> same as the one who posted : I can change the first screen but not the following, even after unpacking initrd.lz and changing the ubuntu-plymouth-text "black" hexa code line
[14:15] <melodie_> and recreating it
[14:15] <melodie_> it shows only one very small second at shutdown, but none at reboot, so I supposed the guilty one is located in bootlogo (init file) ?
[14:16] <cjwatson> it's built by the gfxboot-theme-ubuntu package
[14:16] <cjwatson> gfxboot-examples is of little interest to me
[14:17] <melodie_> hello cjwatson
[14:18] <melodie_> is there a tutorial somewhere ? I have also installed gfxboot-theme-ubuntu package in my ubuntu precise host, and I seem to be unable to find a howto
[14:18] <cjwatson> no
[14:18] <cjwatson> at least not afaik
[14:19] <melodie_> :-(
[14:20] <melodie_> perhaps if I change the hex color code in a *.inc file there and use a "make" command ?
[14:21] <melodie_> I can copy the content of the gfxboot-theme-ubuntu directory to /tmp and do tests there
[14:24] <cjwatson> in general you should start from the gfxboot-theme-ubuntu source package and not from any other version of it, certainly
[14:24] <cjwatson> it's a standard-Debian-format source package so you can build it in the usual way
[14:24] <melodie_> I am not yet used to packaging
[14:25] <melodie_> is the build command as presented in the examples ? I posted here the test I did: https://bugs.launchpad.net/ubuntu/+source/gfxboot-examples/+bug/1077339/comments/1  "# make -C themes/example_07"
[14:29] <melodie_> getting gfxboot-theme-ubuntu source package now. What would be nice would be to know if there is a dedicated forum, mailing list, or chan to learn using it ?
[14:33] <melodie_> reading into common.inc file now
[14:33] <ricotz> dholbach, thanks for syncing the libreoffice deps :)
[14:34] <dholbach> ricotz, no worries
[14:37] <josepht> sorry
[14:41] <xnox> ivanka: heya. Sorry, missed your ping from 11:39, what's up? =)
[14:41] <xnox> (#ubuntu-devel is busy with planning everything today)
[14:46] <pitti> slangasek: I'd like to participate in the hangout of https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration -- what do I need to do for this? (cjohnston said to contact the track lead)
[14:46] <cjwatson> melodie_: any Debian-format source package can be built using debuild (read its man page for details); the entry point into each package's build system is always debian/rules
[14:47] <melodie_> cjwatson thanks (I will restart learning packaging soon) just now what I try to understand while reading in the source package files is how the background for the first live splash is setup
[14:47] <seb128> pitti, on this topic, I just moved it to 18utc, I hope it works for you
[14:48] <pitti> seb128: sure, I'll just skip Taekwondo
[14:48] <seb128> pitti, I want to try to have robert_ancell there and he's not going to be up much earlier I guess
[14:48] <seb128> pitti, oh, let me put it tomorrow 18utc then
[14:48] <pitti> seb128: no worries
[14:48] <melodie_> cjohnston btw, I have found someone to sponsor a openbox-menu package I did and will redo it up to date for debian next. and the mentor talks the same language as me. :)
[14:48] <seb128> pitti, well, it's the same
[14:48] <pitti> seb128: I don't plan on going anyway, too many UDS sessions
[14:48] <seb128> pitti, ok, as you want
[14:48] <melodie_> sorry
[14:49] <melodie_> I tabbed too fast: cjwatson
[14:49] <melodie_> :]
[14:53] <jbicha> I'm getting chroot problems with building armhf on nasl, I've hit retry a few times but it keeps getting stuck https://launchpad.net/ubuntu/+source/opal/3.10.10~dfsg-1/+build/4343624
[14:56] <melodie_> cjwatson this is what the project looks like once booted: http://meets.free.fr/debian/images/OBUbuntu-RC3.png
[15:00] <Laney> jbicha: yeah looks sad: https://launchpad.net/builders/nasl/+history - ping czajkowski in #launchpad
[15:05] <ckpringle> dpm: any chance we can make the core apps project earlier (currently at 7-8pm0
[15:06] <dpm> ckpringle, I will try, but there are a lot of sessions to coordinate and we're all on the same boat
[15:08] <tumbleweed> rickspencer3: are we going to have a UDS session to actually discuss whether we are dropping non-LTS releases or not? I see sessions scheduled about the details, but nothing where we'd actually make that decision and drop 13.04
[15:08] <rickspencer3> hi tumbleweed
[15:09] <rickspencer3> I'm not sure what the plan is for that
[15:10] <tumbleweed> yeah, me neither. I'm just getting concerned that some people see it as a forgone conclusion while others feel that we haven't had the UDS discussion about it yet
[15:10] <rickspencer3> I'm not certain what kind of discussion would add to what's already been discussed, tbh
[15:10] <cjwatson> heh, there really ought to be something
[15:10] <rickspencer3> cjwatson, tumbleweed what would such a session look like?
[15:10] <cjwatson> if only because if we don't we'll spend time later answering the question why not
[15:11] <cjwatson> the whole question of monthly snapshots/updates/whatever deserves a session of its own, I guess; and then there's the question of how Ubuntu Desktop's decisions affect flavours
[15:11] <rickspencer3> oh, I thought there was a session for monthly snapshots
[15:12] <tumbleweed> yes, we have that
[15:12] <rickspencer3> and I though slangasek brought one forward for the flavors
[15:12] <Laney> how does it get decided whether we do 13.04?
[15:12] <cjwatson> oh, yes, I've found it now
[15:12] <cjwatson> http://summit.ubuntu.com/uds-1303/meeting/21596/foundations-1303-monthly-snapshots/
[15:12] <Laney> especially with respect to its release schedule
[15:12] <tumbleweed> I haven't seen a flavours one yet
[15:13] <rickspencer3> Laney, aiui the current idea is that we decide some more details and then go to the techboard
[15:13]  * micahg sees 3 sessions missing, was going to pen a mail to -devel (who, when, how of rolling release)
[15:13] <Laney> well, we have Feature Freeze on Thursday for example
[15:13] <cjwatson> fwiw, as Martin said, I don't see how the techboard can make a plausible decision other than "we can't do 13.04 if Canonical isn't funding the engineering to make it happen"
[15:14] <rickspencer3> cjwatson, there is that
[15:14] <tumbleweed> there is that, but it hasn't been explicitly stated that I've seen
[15:14] <cjwatson> but we can do our best to make sure all the other things around that are as good as they can be
[15:14] <cjwatson> tumbleweed: https://lists.ubuntu.com/archives/technical-board/2013-March/001513.html
[15:14] <soren> cjwatson: Do you happen to know if we're going forward with the TB meeting this evening in spite of UDS going on?
[15:14] <micahg> cjwatson: right, but for Canonical to prematurely yank funding if Ubuntu isn't ready to roll seems implausible as well
[15:14] <tumbleweed> cjwatson: that doesn't say "canonical won't support non-LTS releases" it says people have been saynig that canonical is talking about this
[15:15]  * tumbleweed really needs to run, but I'll be back in 10 mins
[15:15] <cjwatson> tumbleweed: oh, ok, granted
[15:15] <cjwatson> soren: hm, I haven't seen an indication that we wouldn't.  that means I have a long few days :-/
[15:15] <cjwatson> I'm not sure I can make it given the demands
[15:15] <micahg> soren: UDS is tomorrow
[15:16] <soren> micahg: orly?
[15:16] <micahg> tomorrow + Wed
[15:16] <rickspencer3> soren, http://summit.ubuntu.com/
[15:16] <soren> Blimey. So it is.
[15:16]  * soren adjusts the date on his wrist watch. srsly
[15:16]  * micahg needed to catch up on the thread before penning the e-mail to devel about the missing sessions
[15:17] <soren> Stupid thing needs manual adjustment for non-31-day months. I must have gotten it wrong. :)
[15:25] <tumbleweed> cjwatson: right. so if we don't want to discuss it at the UDS, it'd help if canonical's plans were clear
[15:29] <tkamppeter> I have some questions to the online UDS. Can I participate without G+ account? Or without webcam (audio-only)?
[15:30] <melodie_> which one is the package containing debuild ?
[15:31] <Laney> melodie_: devscripts
[15:31] <melodie_> Laney thanks
[15:31] <Laney> sure
[16:19] <slangasek> mhall119: hmm, pitti asked about being included in the hangout for one of the foundations sessions... is there a particular process for how we handle who goes in which session, or is that just a matter of who we invite to the hangout at the time we set it up?
[16:20] <Laney> I saw somewhere that the 'required participants' get a link to join the hangout
[16:23] <slangasek> cjwatson, mhall119: http://summit.ubuntu.com/uds-1303/meeting/21641/community-1303-rolling-toolchain/ needs to be taken off the schedule, because doko's not available to discuss it; I've untargeted the blueprint from the sprint, is there anything else I need to do to get it off the schedule?
[16:24]  * tumbleweed heard that mentioned but haven't seen it documented anywhere
[16:24] <Laney> planet I think
[16:24]  * cjwatson has no idea I'm afraid
[16:24] <Laney> http://www.chrisjohnston.org/ubuntu/vuds
[16:25] <tumbleweed> do we have a way to get people who are talking a lot in IRC into the sessions?
[16:25] <tumbleweed> often the active participants aren't readily determinable in advance
[16:26] <Laney> you should be able to share the link out of band
[16:26] <Laney> (I guess)
[16:33] <tedg> slangasek, lool, xnox, Does it make sense to have a session on proposed solutions to manage ABI/API stability?
[16:34] <xnox> we had approx. similar one in Copenhagen, driven by steam coming to ubuntu and wanting to keep same binary around for as long as possible, ideally forever.
[16:35] <slangasek> cjwatson: haha, sorry, I meant cjohnston
[16:35] <xnox> but nothing per se, resulted from it.
[16:35] <xnox> (as far as I know)
[16:35] <xnox> tedg: isn't there already some "app development SDK/ABI/API" sessions?!
[16:35] <cjohnston> slangasek: your becoming hard to follow...  too many places lol
[16:36] <cjwatson> slangasek: ah :)
[16:36] <slangasek> Laney: right, that says "the required participants will be given a link"... I guess that means I can use summit to mark the people I want "required" in the hangout
[16:36] <tedg> xnox, I think they were mostly targetted at the individual libs instead of a general solution.  But I could have missed it.
[16:36] <cjwatson> I did wonder
[16:36] <Laney> slangasek: That's my understanding, but you have the author of the blog post here :-)
[16:36] <cjohnston> slangasek: they have to be marked as required
[16:36] <cjohnston> in summit
[16:36] <xnox> tedg: not sure, what do you have in mind for a session on proposed solutions to manage abi/api stability?
[16:36] <cjohnston> one sec
[16:36] <cjwatson> The gaming ABI session mostly ended up being about tracking ABI changes systematically so that we know when they happen and can manage them appropriately
[16:37] <slangasek> cjohnston: ok.  And I first need to mark them on the blueprint?
[16:37] <pitti> slangasek: I marked myself as "participation essential" in LP, but I understand that's not the same "required" as cjohnston means
[16:37] <tedg> xnox, I was thinking like the acc thing we discussed last week.
[16:37] <cjwatson> Since in the context of libraries we don't maintain it isn't meaningful to say "we won't change the ABI" - we need to find out when they change and keep compatibility packages around, etc.
[16:37] <tedg> xnox, And getting that to all libs.
[16:37] <cjohnston> slangasek: they need to be 'attending' via the BP.. essential on the BP doesnt matter..
[16:37] <tedg> cjwatson, I was also concerned about accidental changes, more than on purpose ones.
[16:38] <slangasek> pitti: I don't see you subscribed to https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-logind-migration at all?
[16:38] <dobey> for some upstreams it's basically impossible to do that, sadly :-/
[16:38] <cjwatson> Right, for those we can only meaningfully find out about them post hoc
[16:38] <pitti> slangasek: that's the superseded one; https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration is the real thing AFAIUI
[16:38] <slangasek> pitti: oh blast, the wrong blueprint is linked to the summit session
[16:38] <cjwatson> As long as it's before release and in time to do something about it ...
[16:39] <tedg> cjwatson, Release?  I'm unfamiliar with this term you speak of  ;-)  We could block package build if it changes unknowningly, effectively like .symbols files.
[16:39] <slangasek> cjohnston: hi, sorry - I need http://summit.ubuntu.com/uds-1303/meeting/21636/foundations-1303-logind-migration/ points to a wrong blueprint, I need to get https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration on the schedule in its place... what's the best way to do that?
[16:39] <cjwatson> tedg: Last I checked we were still doing an LTS :-P
[16:40] <cjwatson> tedg: Yes, perhaps some kind of autopkgtest or autopkgtest-like checks across the board would be helpful
[16:40] <cjwatson> So not block build (though packages can and do do that themselves) but block promotion to the release pocket?
[16:40] <tedg> Anyway, that's what I was thinking for the session.  If we had a plan there, then we could implement it on Canonical-libs first.
[16:41] <slangasek> cjohnston: https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-consolekit-logind-migration is targeted to uds-1303, but I don't see it in the system anywhere
[16:41] <tedg> cjwatson, Sure, blocking getting out into the wild.  Which step I'm not as worried about.
[16:42] <cjwatson> We could already have Canonical libraries use whatever the dh_makeshlibs option to fail on symbols file mismatches
[16:42] <cjwatson> *option is
[16:42] <tedg> And we're migrating many of them to use that.
[16:42] <cjwatson> dh_makeshlibs -- -c2
[16:42] <tedg> But it's not really full ABI stability for things like structure sizes.
[16:42] <tedg> Which are really critical in the GObject world.
[16:43] <cjwatson> Indeed.  There are various ABI checker tools around - does abicheck handle that?
[16:43] <cjohnston> slangasek: http://summit.ubuntu.com/uds-1303/2013-03-06/  1815.. isnt that the one you wnat
[16:44] <cjwatson> Or abi-compliance-checker
[16:44] <tedg> Yes, and I think that xnox was going to look into using it.
[16:44] <cjwatson> I think by now this is probably not a wheel we need to reinvent
[16:44]  * cjwatson nods
[16:44] <tedg> Basically adding a "symbols file" like thing to a package for the ABI.
[16:44] <cjwatson> Aha, that's what you meant by "acc"?  That was a bit cryptic for me.
[16:45] <cjwatson> Yep.  I approve :)
[16:45] <tedg> Sorry, yes, that's what I meant.
[16:45] <slangasek> cjohnston: yes... hmm, did something magically fix itself? :)
[16:45] <cjohnston> i dunno... im confused from trying to keepup with all of the links that kept getting posted
[16:45] <cjohnston> and im confused why its against client unless it was renamed from client
[16:46] <cjohnston> it should point to foundations and not client correct?
[16:47] <slangasek> cjohnston: it was renamed from client; it should be foundations, yes :)
[16:47] <cjohnston> and removed from the client room?
[16:47] <slangasek> cjohnston: I imagine so
[16:47] <slangasek> cjohnston: what's our hangout size limit?
[16:47] <cjwatson> (Though I'm not wild about abi-compliance-checker's configuration apparently being in XML :-/)
[16:48] <slangasek> configuration, or manifest?
[16:48] <cjwatson> Manifest
[16:48] <cjohnston> slangasek: its removed from the client room, and assigned to foundations. you should now have the ability to schedule it
[16:48] <slangasek> cjohnston: ta
[16:48] <cjwatson> Ah, it has some kind of alternative dump format too.  I haven't really looked into it deeply ...
[16:49] <cjohnston> slangasek: also, in the subnav, you will see 'review attendees'... thats where you mark people required
[16:49] <slangasek> cjohnston: yes, I know... I was halfway through that list when something reset the statuses on me ;)
[16:49] <cjohnston> hrm. ok
[16:49] <cjwatson> slangasek: Unrelatedly, I wonder if the GRUB efinet problem I'm seeing on my test system has anything to do with yours; it seems to just refuse to receive any packets ever, claiming (once I apply sufficient debugging) that the interface is uninitialised, but it can *transmit* packets just fine
[16:50] <cjwatson> It's very odd
[16:50] <pitti> Laney: can I ask you to set a britney block on pygobject? I'm about to upload 3.7.91, and while I don't know of anything that's broken I'm paranoid
[16:50] <Laney> oui
[16:50] <slangasek> cjwatson: that sounds roughly familiar
[16:50] <pitti> Laney: i. e. I'd like to wait on all reverse depends autopkgtests
[16:50] <pitti> Laney: merci mon ami :)
[16:50] <cjwatson> Specifically it's getting EFI_DEVICE_ERROR on EFI_SIMPLE_NETWORK_PROTOCOL.Receive
[16:50] <seb128> slangasek, http://summit.ubuntu.com/uds-1303/2013-03-06/display the logind one is at 18:15
[16:51] <cjwatson> slangasek: Are you still in a position to reproduce what you saw?
[16:51] <seb128> slangasek, I put it in the client track since after all we had some free slots
[16:52] <slangasek> tedg, cjwatson: so the question was whether we needed a session on ABI stability.  Does the appdev session have this covered, or do you need me to add something in the foundations track?
[16:52] <slangasek> seb128: ok
[16:52] <slangasek> cjwatson: with sufficient swapping of state into my brain, yes
[16:54] <cjwatson> slangasek: My current debugging patch is http://paste.ubuntu.com/5585573/ (note that that deliberately slows packet reception down to one poll every two seconds so that one can see what's going on); it would be interesting to apply that and see what error get_card_packet is hurling out
[16:54] <cjwatson> (That's against upstream trunk, ish, hopefully it roughly applies to 2.00)
[16:55] <cjohnston> slangasek: should http://summit.ubuntu.com/uds-1303/meeting/21603/community-1303-plusone-maintenance/ be renamed to foundations, and not against community and foundations?
[16:55] <cjwatson> slangasek: Oh, you'll need to "set debug=efinet" for that to work, so either do that in shell/configuration before doing any network operations, or build the netboot image with grub-mknetdir --debug-image=efinet
[16:55] <tedg> slangasek, I don't see one that covers this topic, I'm not 100% we need one as it seems relatively straightforward, but perhaps to coordinate?
[16:56] <slangasek> cjwatson: ok, will try to have a look today
[16:56] <cjwatson> tedg: As long as somebody from foundations is in an appdev session as a general sanity check, I think we could deal with its output later
[16:57] <slangasek> tedg: so currently I'm feeling a bit too-many-cooks on the question of abi checking; I don't think there's a lot to discuss, we just need to implement ABI checking infrastructure which doesn't really require more meetings IMHO
[16:57] <cjwatson> amen
[16:57] <tedg> Heh, sounds good to me.
[16:58] <tedg> You'll be sending out weekly TPS reports on progress right?  ;-)
[16:58] <cjohnston> +1
[16:59] <slangasek> tedg: lool, tvoss and I are already planning to provide Canonical upstreams with a best practices guide for ABI stability, and to identify the correct infrastructure to check at package upload time that ABI/API hasn't silently broken
[16:59] <cjwatson> slangasek: I think if that fails (efinet) my next step is to try to dump out and disassemble this system's UEFI somehow :-/
[16:59] <slangasek> cjwatson: fun
[16:59] <cjwatson> In order to have some freaking clue what it's doing
[16:59] <cjwatson> It's still possible that GRUB's EFI calling shims are broken, though (a) I've hand-checked them (b) you'd think we'd have noticed
[17:01] <cjohnston> slangasek: lool how does http://summit.ubuntu.com/uds-1303/track/foundations/ look
[17:01] <slangasek> cjohnston: LGTM, thanks
[17:01] <ogra_> fulkl of sessions !
[17:01] <ogra_> *full
[17:01] <cjohnston> slangasek: have I addressed all of your concerns (that I can take care of with less than 24 hours to go)
[17:02] <cjohnston> I don't know if I was able to keep up with everything in both channels
[17:03] <slangasek> cjohnston: I believe so, yes
[17:03] <cjohnston> cool. thanks
[17:03] <slangasek> cjohnston: if not, once I've fully unwound my stack in another hour, I'll let you know :-)
[17:03] <cjohnston> :-)
[17:03]  * cjohnston notes to leave in 55 minutes
[17:34] <lool> cjohnston: thanks for fixing foundations track!  :)
[17:34] <cjohnston> np
[18:23] <achiang> if i want to comment on a blueprint (asking a question i would like clarified), what is the convention for doing so? just edit the whiteboard directly, put my nick in [square brackets] then ask my question?
[18:24] <xnox> achiang: yes.
[18:24] <xnox> in chronological order =)
[18:24] <achiang> xnox: should i insert the question inline? or is there typically a q&a section?
[18:25] <xnox> achiang: wherever it's obvious, subscribed people will get a "diff" format of it anyway =)
[18:25] <achiang> xnox: thx
[19:02] <bryce> are the arm64 buildd's swamped?  I've been getting timeouts trying to get a PPA to build a patched xserver for a bug (https://launchpad.net/~bryce/+archive/lp982889/+packages) and wonder if I should keep trying or if it's a lost cause?
[19:03] <Andy80> hi guys
[19:03] <xnox> bryce: arm64 ?! wishful thinking =) or do you mean amd64 or armhf?
[19:04] <bryce> xnox, arg, yeah typo.  amd64
[19:04] <Andy80> I really don't want to annoy anyone, but.... despite the fact that I really apreciate that Unity is moving to Qt/QML (I told this 2 years ago and nobody listened), I really don't like how the decision was takes: 0 community involvement, just an announcement.
[19:05] <dobey> Andy80: #ubuntu-unity
[19:05] <xnox> bryce: it doesn't look that busy, i386 is chugging away in the ppas though.
[19:05] <xnox> damn, please revert.
[19:05] <xnox> bryce: https://launchpad.net/builders
[19:05] <Andy80> dobey, I don't want to be OT, don't worry... but this is not an #ubuntu-unity problem only... it's something bigger. It involves the whole Ubuntu development.
[19:07] <dobey> Andy80: then IRC surely isn't the place to discuss it. you can perhaps bring it up on ubuntu-devel-discuss mailing list or something
[19:07] <Andy80> dobey, ok... sorry then.
[19:09] <bryce> xnox, thanks for the link.  yes they don't look bogged down.  Would you suggest I just keep trying?  My build log isn't really very clueful about  what went wrong.
[19:22] <ScottK> Andy80: I think Unity going to Qt/QML will have less of an impact than their decision to invent their own X windows replacement.
[19:23] <jbicha> ScottK: I wish they named their display server 'UDS' instead of 'Mir' ;)
[19:25] <Andy80> ScottK, that's not the point :) (maybe it's better if I blog my thoughts....) I 100% agree with the decision they (finally) made. But I strongly disagree with the way they did it. Community was not involved at all. That's what really hurts me.
[19:26] <ScottK> Andy80: Right.  Totally agreed.
[19:26] <ScottK> First UDS, then rolling release, now this.
[19:26] <ScottK> They have no end of surprised in store, apparently.
[19:27] <Andy80> ScottK, oh wait... it's already decided for the rolling release :D ? (I agree with this too, but I totally missed the announcement :P )
[19:27] <ScottK> That's my assumption.
[19:27] <ScottK> It certainly appears to me that the call do "discuss" it is pro forma.
[19:27] <Andy80> ok
[19:28] <Andy80> I already felt this a couple of UDS ago...
[19:28] <Andy80> but I just didn't want to be "rude" bothering with them
[19:28] <ScottK> Up until now, it was reasonably possible to avoid it if your interests didn't overlap Canonical's focus.
[19:28] <ScottK> It doesn't seem so anymore.
[19:32] <jbicha> I don't think the decision is final, but it looks unlikely to me that the ones who don't want a rolling release will be organized enough to stop the ball in motion
[19:33] <jbicha> there's still opportunity to steer the ball if you have good ideas for how to best do this
[19:33] <mlankhorst> do you think it's a good idea to have a release every 6 months then ? :S
[19:34] <ScottK> I think it comes down to "We don't care about Ubuntu governance, whatever is decide/preferred, we'll control what happens via the budget for our own needs".
[19:34] <ScottK> mlankhorst: I think it's essential.
[19:35] <jbicha> mlankhorst: I don't think we're ready to do a rolling release next month and advertise it the same way we always do non-LTS releases
[19:36] <tumbleweed> jbicha: the only sane way to think of it is as no LTS releases
[19:37] <tumbleweed> no non-LTS releases even
[19:38] <jbicha> tumbleweed: ok but what's http://www.ubuntu.com/download/desktop going to say? and will we mark it as just another Ubuntu release only better or will we clearly mark it for early adopters for now?
[19:40] <tumbleweed> jbicha: "download precise here"
[19:40] <jbicha> I think I'm ok with the experiment but I'm not ok with experimenting on a million people who aren't aware of the risks; once it's been proven to work than we can relax the marketing
[19:40] <Andy80> an LTS every 2 years and rolling release the rest of the time would make sense for me. But I'm not expert in this field, so it's just for my tastes...
[19:41] <tumbleweed> the development release can only really be for enthusiasts
[19:41] <jbicha> the current site lists 12.10 above 12.04 LTS and it's not at all clear that 12.04 LTS was a better choice in this case for ~90% of people
[19:42] <jtaylor> barry, cjohnston any objects to me uploading shiboken to see what happens before ff (probably tomorrow or tuesday)?
[19:42] <tumbleweed> jbicha: a development release isn't the best choice for anyone in our target market
[19:42] <jtaylor> the thing should at least be be somewhat working, which is better than not at all
[19:42] <cjohnston> broken is broken, so it cant get worse than broken
[19:43] <jbicha> tumbleweed: tell that to the website people
[19:43] <barry> shibroken?
[19:43] <jtaylor> ^^
[19:46] <zequence> Ubuntu Studio ISO failed, and I'm having problems debugging the reason. I've recently changed the seeds http://people.canonical.com/~ubuntu-archive/livefs-build-logs/raring/ubuntustudio-dvd/20130304/livecd-20130304-amd64.out
[19:46] <zequence> It's just about to build the depency tree after having finished with ubuntu-minimal
[19:46] <dobey> jbicha: it's best not to think of "rolling release" with the word "release"
[19:47] <dobey> jbicha: there won't be an actual "release" so much. it's just that development will continually happen and people can run from the unstable archives, and the "release" will be an LTS that happens every 2 years
[19:47] <tumbleweed> there might be snapshots, which are sort of like releases, that's the only new thing
[19:48] <zequence> I haven't understood the point with snapshots. What's the difference between a snapshot and a daily?
[19:48] <dobey> well, "copy an image to another directory on the server every 30 days"
[19:48] <dobey> but doing the snapshots seems like a waste of time to me
[19:49] <tumbleweed> the point of the snapshot is to avoid having to install mountains of updates every day
[19:49] <tumbleweed> put that off to once a month
[19:49] <zequence> If a rolling release is to be a development release, it's not really a rolling release. It's just a development release
[19:49] <tumbleweed> zequence: what's a rolling release then?
[19:49] <dobey> it's not a release
[19:49] <dobey> development or otherwise
[19:49] <dobey> it's an archive of packages, and there are automated daily image builds to install from
[19:49] <zequence> tumbleweed: One where you aren't experimenting in the standard repos
[19:50] <zequence> tumbleweed: And you don't release features until they are complete
[19:50] <tumbleweed> we don't experiment ni the standard repos
[19:50] <tumbleweed> and we don't upload things until they are ready to be used
[19:51] <tumbleweed> (but yes, I assume we'll get a little more conservative with the dev release)
[19:52] <jbicha> we're going to have a delay though between landing new stuff and that getting pushed to the early adopters right?
[19:53] <tumbleweed> no
[19:53] <jbicha> oh that's scary
[19:54] <cprofitt> question, not sure if this is the right place, will Quickly still be moving forward?
[19:54] <dobey> why? it's not any different than running a version of ubuntu before it's released right now
[19:54] <jbicha> not many people will be running the PPA where we'll have to stage big transitions
[19:55] <tumbleweed> jbicha: we already stage some toolchain changes in PPAs
[19:55] <jbicha> dobey: sure but I think this new thing will pick up quite a few more users (who were happy with the non-LTS releases or happy with upgrading at Beta, etc.)
[19:55] <tumbleweed> jbicha: right, and I'm not sure that we'll be ready for them :)
[19:56] <dobey> jbicha: those people should continue to do what they were doing then, not run the rickroll archive
[19:57] <dobey> upgrade at beta, or at the next release.
[19:57] <cprofitt> will new versions of LibreOffice, etc be pushed down to the LTS?
[19:59] <cprofitt> I am one of the people who uses the non-LTS releases and I do it to stay closer to current on my applications
[19:59] <zequence> Would it be tons of work adding another repo to the rolling release, where the repo that is currently used in the development release would be something that wasn't enabled by default (and with a different name), but which developers would enable for their work, and then a default repo for users - you'd sync packages from the developer repo to the user repo, whenever something was thoroughly smoke tested and fairly complete feature wise
[19:59] <cprofitt> if LTS is going to be 'stale' on application updates for two years that would bother me
[19:59] <dobey> cprofitt: i don't think that can be answered in this channel (or in a general sense), but is something that will be answered on a per-case basis. probably a good question for Sweetshark to weigh in on though, at least for LO. and probably worth bringing up in the UDS discussion
[20:00] <dobey> zequence: you mean like how everything gets uploaded to -proposed first, like we're already doing?
[20:00] <cprofitt> thanks dobey
[20:01] <zequence> dobey: Well, yes.
[20:01] <zequence> dobey: Only, from what I gather, -proposed is not used in this way
[20:02] <tumbleweed> things migrate from -proposed when they don't decrease installability
[20:03] <jbicha> wow, it's not as much as fun to have a flavor that people aren't recommended to use and we can't really backport new GNOME stable releases to an LTS release without breaking Unity in that PPA
[20:03] <dobey> well, there was also talk of requiring that autopkgtests don't fail, before copying over, no? that would basically implement the "smoke tests" bit
[20:04] <tumbleweed> dobey: sure, but the longer we hold things out of the release pocket, the nastier disentangling the mess gets
[20:04] <dobey> certainly
[20:05] <micahg> cprofitt: anyone can request a libreoffice backport to an LTS if they do the testing and it builds
[20:06] <tumbleweed> has there ever been one before?
[20:06] <dobey> backports and updates are quite different though
[20:06] <micahg> sure, but I see libreoffice as the type of thing that you don't have to update, but can backport
[20:07] <micahg> some people don't want their office suite changing out from under them ;)
[20:07] <tumbleweed> jbicha: I hope some of the flavours can have a UDS session to talk about these issues. It sounds like you have the same problems as kubuntu
[20:08] <jbicha> micahg: bug 888665 is still the annoying blocker for a lot of backports :(
[20:09] <micahg> jbicha: infinity promised to fix eventually
[20:10] <jbicha> tumbleweed: I didn't think we had too much of a problem with the rolling idea but I thought we'd have more of a buffer between the system used by users who like the latest stuff and the system where the developers are doing their work :(
[20:11] <jbicha> those are 2 separate audiences and we're making things more unpleasant for both sets
[20:11] <tumbleweed> jbicha: you saw https://blueprints.launchpad.net/ubuntu/+spec/foundations-1303-monthly-snapshots ?
[20:18] <jbicha> something like that was more what I understood; I think doing a ~monthly release cycle is critical to having people actually use the thing
[20:19] <jbicha> and we should have a deadline each month for major features so that testers, translators and documenters have time to do their thing before it gets pushed out to the perpetual beta users
[20:19] <slangasek> jbicha: the proposal is not *at all* about doing a monthly release cycle
[20:20] <slangasek> the goal of moving to a rolling release is to reduce the release overhead.  Reimplementing the release cycle for monthlies has the exact opposite effect.
[20:21] <jbicha> there are conflicting proposals and I think recognizing a daily and monthly audience has merit
[20:23] <jbicha> I know I would rather land the huge new GNOME update at the beginning of the month to give us more time to ensure that we found all the big issues during the PPA staging time
[20:24] <jbicha> is there a successful software project that doesn't have a feature freeze?
[20:28] <slangasek> jbicha: you're missing the point.  A feature freeze precedes a release; the monthly snapshots are not going to be releases.  There is no way we're investing those kinds of resources into a monthly process.
[20:28] <seb128> jbicha, the new GNOME update shouldn't land "at the beginning of the month", they should land after GNOME stable .2 when they got testing and are somewhat stable
[20:31] <slangasek> jbicha: if you think that a monthly snapshot without the release process you describe is not useful, I encourage you to make that case; but there's just no way, given the thesis statement of "we want to do away with 6-month releases and move to a rolling release because the 6-month releases aren't benefitting us" that we would turn around and implement a once-a-month release process
[20:49] <achiang> can someone clue me in here? once qt5 gets a Mir backend (and assuming Kwin gets ported to Qt5), what more work would there be left to do in Kubuntu (at least specifically to support Mir)?
[20:53] <slangasek> achiang: a window manager / shell is deeply tied to the X protocol
[20:54] <achiang> slangasek: ah, so you're saying what i don't know about that piece of plumbing can just about fit into the grand canyon. ;)
[20:54] <achiang> slangasek: ok, that makes a lot of sense, thanks
[20:59] <kees> mdz: TB meeting soon
[20:59] <mdz> yep
[21:03] <yofel> achiang: we'll talk to martin graesslin when he shows up about that (kwin developer)
[21:04] <achiang> nod
[21:16] <superm1> yofel: so for something like xfce's window manager there needs to be a mir backend added for the underlying toolkit first (say GTK) and then additional work on top of that on the window manager itself?
[21:17] <yofel> I'm the wrong person to ask that, but it is like that usually
[21:33] <ScottK> achiang: I think the chances of kwin being ported to Mir are very, very low anytime soon.  It looks like ~everything not Unity will be a second class citizen in Ubuntu in a year.
[21:34] <ScottK> Xfce and Lxde even more so, since at least Canonical is doing work on Qt5.
[21:44] <RAOF> ScottK: You'll ~always have an X server available to you, even if we shove a Mir compositor underneath it; exactly as the previous system-compositor spec.
[21:45] <ScottK> I may be a bit lost in terminology here.
[21:45] <ScottK> Isn't the layer like compiz/kwin the compositor?
[21:46] <ScottK> So I'm not sure I understand what that means.
[21:47] <RAOF> Before Mir came along (or, at least, before we knew about it), we were going to do a wayland system compositor, with X nested inside it. So all your X servers talk to the system compositor, and it does the final display bit.
[21:48] <RAOF> The same thing will apply here - you'll ~always be able to start an X server on the system compositor, it'll run nested, and KWin won't be any the wiser.
[21:48] <ScottK> OK.
[21:48] <sarnold> "~always" :)
[21:48] <RAOF> This is something that we'll have to support for a good long while, too, since we can't magically port everything anyone wants to Mir.
[21:48] <ScottK> sarnold: Yes.  Preciselye.
[21:48] <ScottK> s/e//
[21:49] <sarnold> of course people have wanted to kill off X for as long as I've been using it
[21:49] <RAOF> sarnold: Heh, yes. I obviously can't commit to how long we'll be supporting X, but I don't see us dropping it in the next, say, decade.
[21:49] <sarnold> I'm not entirely sure how to feel here... I don't want to say goodbye to old friends like urxvt... and yet, X does have a raft-load of problems :)
[21:50] <sarnold> RAOF: man, no one _ever_ has good stock tips for the year 2023...
[21:50] <ScottK> RAOF: Well before today, I'd have rated the chances of Canonical thinking it was a good idea to write their own X windows replacement from scratch as low too.
[21:51] <superm1> RAOF: so basically these new fangled apps will connect directly to the system compositor and old X apps will connect to the nested X server?  Will it be noticable to the user that they're running X apps in a container theN?
[21:52] <RAOF> superm1: No, new fangled apps will connect to the Unity session compositor (which will connect to the system compositor), X apps running in a Unity session will connect to a rootless nested X server started by the Unity shell, and non-Mir *sessions* will start a full nested X server.
[21:53] <RAOF> superm1: Users shouldn't be able to tell that they're running X apps under Unity, and users shouldn't be able to tell that KWin's running in an X server under Mir.
[21:53] <RAOF> It'll be not dissimilar to how X apps work in OSX currently - they also do a nested rootless X server.
[21:54] <superm1> ah i see
[21:55] <mdeslaur> ScottK: what makes you think other distros won't be using Mir?
[21:55] <superm1> but if you are talking about something legacy that doesn't necssarily operate act as a session compositor, say metacity or xfce-window-manager, is that where you run into troubles then?
[21:56] <ScottK> mdeslaur: The approximately zero percent success Canonical has had convincing other distros that things like Unity are the way to go.
[21:56] <ScottK> I expect the trend to continue.
[21:57] <ScottK> If you go off and develop something in a vacuum and suggest that everyone should just eat it whole, rather than engage with the community, no one is going to listen.
[21:57] <ScottK> https://plus.google.com/115606635748721265446/posts/93zY4qfpq2X <- Kwin maintainer, fwiw.
[21:57] <dobey> ScottK: yet it's ok for people in other communities to do that. irony. :)
[21:58] <ScottK> dobey: Not a all.
[21:58] <RAOF> superm1: Well, you can't run metacity or xfce-window-manager in a Unity session. But you can still have an XFCE session - it'll just spawn a full X server, and everything will work as it does now.
[21:59] <dobey> ScottK: many of the things we use in userspace are something someone wrote in a vacuum, and then said "here, i think it's cool, maybe you want to use it"
[21:59] <dobey> heck, the linux kernel started that way. linus wrote something, and then people started contributing
[21:59] <ScottK> dobey: Sure, but not so much for huge pieces of infrastructure.
[21:59] <ScottK> two decades ago things were a bit different.
[21:59] <mdeslaur> ScottK: that's how all open source software is written...somebody bangs on something until it gets to 0.1 and is worth showing, and then releases it...
[21:59] <dobey> pulseaudio? gstreamer?
[21:59] <superm1> RAOF: oh so then it really *shouldn't* be a big deal for flavours that aren't updated to mir immediately then.  it will be more convenient and efficient when they do, but they'll get along fine for now
[22:00] <rickspencer3> hmmm
[22:00] <dobey> systemd?
[22:00] <sarnold> gnome3? :)
[22:00] <rickspencer3> I'm not sure that debating how right/wrong it is to write software in different ways is totally relevant
[22:00] <rickspencer3> I'm wondering more if the issue at hand is ensuring that Kubuntu doesn't inadvertnatly get locked out in the cold
[22:01] <ScottK> It seems like for this particular issue, the concern is more long term, but it's real.
[22:01] <dobey> i don't think kubuntu is getting locked out in the cold, per RAOF and tedg's comments
[22:01] <dobey> it seems more like xubuntu, lubuntu, etc… might more so in the future
[22:01] <rickspencer3> dobey, I think it's a legitimate concern
[22:01] <RAOF> superm1: Absolutely. Everyone can basically ignore Mir unless they want to write a display-server-compositor.
[22:01] <rickspencer3> fair enough, I think it's a concern for all the flavors
[22:01] <rickspencer3> and I think we shouldn't let it happen
[22:01] <ScottK> RAOF: Until there's a bug in Mir.
[22:02] <dobey> rickspencer3: certainly. wasn't saying it wasn't a legitimate concern.
[22:02] <rickspencer3> the point of Mir is certainly not to keep other DEs from working on Ubuntu
[22:02] <rickspencer3> that would be a *hideous* outcome
[22:02] <ScottK> Then you've got the fact that you're running emulation instead of a standard X windows and it makes it hard to know where problems are.
[22:02] <RAOF> You're not running an emulation.
[22:02] <tedg> ScottK, It's not really emulation, it's a driver for standard xorg.
[22:03] <RAOF> You're running an X server.
[22:03] <ScottK> OK.
[22:03] <RAOF> An X server, using the same drivers, that just happens to not handle the framebuffer.
[22:03] <ScottK> What handles the framebuffer then?
[22:03] <tedg> ScottK, And yes, there'll be bugs, but it'll effect a large number of folks besides other DEs.  Any X11 app really.
[22:03] <RAOF> Mir handles the framebuffer.
[22:03] <RAOF> (The Mir system compositor)
[22:04] <ScottK> And we're back to where I get confused then.
[22:04] <tedg> There's two Mir's.  A root system compositor Mir and a user session Mir.
[22:04] <ScottK> I thought Compiz/Kwin were the compositor?
[22:04] <tedg> (in the Unity case)
[22:04] <RAOF> I'm pretty sure we've got a diagram of this somewhere. Let me dig it up :)
[22:04] <tedg> ScottK, System compositor vs. user compositor.
[22:04] <ScottK> So then how does this Mir system compositor interact with the regular one?
[22:04] <tedg> ScottK, The system compositor allows effects when doing things like faster user switching.
[22:05] <ScottK> tedg: But we don't today have a system compositor, right?
[22:05] <tedg> It's basically a tree
[22:05] <tedg> No, we don't today.
[22:05] <tedg> (well, there are packages to do it with weston, but I don't think it is widely done)
[22:05] <ScottK> So something like Compiz/Kwin will have to overlay this somehow?
[22:05] <RAOF> Only the X server needs to know about the system compositor.
[22:05] <tedg> No, it'll be transparent to them.
[22:06] <tedg> Hmm, visibility descriptions probably aren't good when discussing graphics...
[22:06] <tedg> They don't need to do anything special.
[22:06]  * ScottK has found "It'll be a transparent change" to be one of the great lies of system development, but maybe this time.
[22:06] <RAOF> ScottK: You can run this right now, if you want - it's in a PPA (for Intel and ATI)
[22:07] <RAOF> Hah. Or, it *will* be, once we've finished copying everything over from the private PPA. It will be in https://launchpad.net/~mir-team/+archive/staging/+packages
[22:07] <tedg> ScottK, It will, most surly, have bumps over the next year.  But after that it should be relatively straight forward.
[22:07] <tedg> surely...
[22:08] <jcastro> RAOF: so how does the PPA work, just add it, install it ... profit?
[22:08] <ScottK> RAOF: This stuff would get a better reception if it didn't all get developed in secret first.
[22:09] <RAOF> ScottK: Not my call :/
[22:09] <ScottK> It's not just me.  Here's Martin Gräßlin's initial reaction: https://plus.google.com/115606635748721265446/posts/93zY4qfpq2X
[22:09] <ScottK> RAOF: I know.  Just saying.
[22:09] <robert_ancell> ScottK, think of the current system compositor as VT switching - we're replacing that with a real compositor that can do effects
[22:10] <ScottK> Are my VTs still going to work?
[22:10] <RAOF> Maybe.
[22:10] <RAOF> At the moment, yes.
[22:10] <robert_ancell> ScottK, not for switching between user sessions - all the graphics will be on one VT
[22:10] <dobey> i highly doubt having said "hey, we're going to write a compositing system to replace X with on Ubuntu" prior to having developed any actual code would have illicited any different reactions.
[22:10] <robert_ancell> but text consoles will remain for now
[22:10] <RAOF> We'd *like* to replace them with something a bit better. But still replace them.
[22:11] <ScottK> dobey: Sure.  Actually talking to outsiders and trying to work with them might have.
[22:16] <mdeslaur> ScottK: Mir should be quite exciting for kde, as it is compatible with android drivers AIUI, so it can be used to get kde plasma on the wide range of android hardware currently on the market
[22:17] <ScottK> Plasma Active already targets a similar hardware segment.
[22:17] <mdeslaur> ScottK: with what drivers?
[22:17] <ScottK> I'm not sure exactly where the overlap would hit.
[22:17] <ScottK> Not sure.
[22:18] <ScottK> I don't think it'll be exciting for KDE if it's Ubuntu only.
[22:20] <Niedar> I think this is the reaction that would have happened regardless of if this was done in private or not I dont think you will convince people ahead of time until there is a real result and then we will find out if it was a good idea or not
[22:23] <jcastro> RAOF: so since you didn't respond I assume I shouldn't try the PPA when builds come up? :)
[22:23] <jcastro> or will they melt my display or something
[22:23] <RAOF> jcastro: Ah, sorry. They won't melt your displays.
[22:23] <RAOF> jcastro: *probably* ☺
[22:24] <RAOF> jcastro: We have a canonical wiki page on how to set it up; basically you should only need to add a “type=mir” line to /etc/lightdm/lightdm.conf
[22:24] <jcastro> cool, is someone working to put that stuff on the ubuntu wiki?
[22:25] <RAOF> Not as far as I'm aware.
[23:56] <celso> people, i have some doubts in my vgaswitcheroo setup. can sommeone help me?