[07:34] <LLStarks> kenvandine. hi, i have a question. why haven't you put your gtk work in a ppa? building from bazaar makes wide testing a bit unwieldy.
[07:36] <crimsun> do I see a volunteer to package it? :-)
[07:36] <LLStarks> i would, but i'd **** up the dependencies
[07:36] <LLStarks> also, my debian packaging is quite primitive.
[07:39] <crimsun> well, that's what #debian-mentors (oftc) and #ubuntu-motu (freenode) are for :-)
[07:45] <LLStarks> thanks.
[07:47] <LLStarks> but my point stands, i don't see rgba passing the alpha 2 smell test without a ppa that doesn't thoroughly break lucid. pulling from branches is too exotic even though i'm full capable of doing it.
[07:51] <\vish> LLStarks: https://launchpad.net/~ubuntu-desktop/+archive/ppa?field.series_filter=lucid  doesnt have the upto date package?
[07:52] <\vish> iirc that was the ppa meant for the rgba testing and was announced in th edesktop ML
[07:53] <LLStarks> as far as i know, rgba is not in main
[07:54] <LLStarks> nor can i confirm that lingering nautilus or gksu problems have been resolved.
[07:55] <LLStarks> i could check the bug again
[08:05] <RAOF> Last time I checked that gtk broke almost everything I cared about, all the way down to emacs.
[08:12] <LLStarks> it was bad enough that ppa-purge couldn't fix it. god bless 10 minute reinstalls and /home partitions.
[18:34] <LLStarks> ?
[18:45] <mozart373> could anyone please help me get jackd running, I ran the alsa info script, and I can't find anything in the forums that describes the exact problem I have
[18:45] <mozart373> http://www.alsa-project.org/db/?f=5ad845791169f42a46d876152ff8c59e05d0b812
[18:47] <mozart373> sorry, wrong channel apparently... btw am I invisible? nobody responds


[02:09] <jbicha> stgraber: ubuntu-docs should build on precise now
[02:09] <jbicha> sorry for the delay
[02:11] <stgraber> jbicha: ok, looking now
[02:49] <stgraber> jbicha: uploaded
[03:03] <jbicha> looks around for an SRU team member to accept ubuntu-docs
[03:04] <ScottK> bdmurray: "sru-release: comment on bugs when releasing packages to -updates and unsubscribe the SRU team from those bugs" <-- don't we want to be subscribed in case of regression comments?
[03:04] <ScottK> jbicha: I'll look.
[03:05] <jbicha> ScottK: thanks
[03:08] <ScottK> jbicha: Needs the bug foo in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template before it can be accepted.
[03:08] <ScottK> Need to have some way of knowing if it passes muster.
[03:11] <jbicha> aw, I hoped I could slide one by :|
[03:15] <ScottK> I'd suggest the test case is verifying selected updates are present.  Just to make sure the right thing got uploaded. You could give a couple of examples.
[03:18] <ScottK> jbicha: I went ahead and accepted based on you'll fix the bug.  Please don't let me down.
[03:19] <jbicha> I'm working on it, language packs have their own separate validation process though
[03:26] <ScottK> Sure, but we still have to have something.
[03:48] <ScottK> OK.  I think that's enough damage to the SRU queue for one night.
[04:11] <ScottK> Whoever's doing stuff with the queue, it'd be nice to get the python2.7 SRU accepted...
[04:11] <ScottK> Easy diff , test case, and everything.
[04:39] <infinity> ScottK: I admit nothing.
[05:45] <ScottK> infinity: Thanks for nothing then.
[05:53] <infinity> ScottK: ;)
[13:13] <stgraber> hmm, who accepted lxc into -proposed?
[13:13] <stgraber> 0.7.5-3ubuntu61 should have been copied to -updates with sysvinit before letting 0.7.5-3ubuntu62 in...
[13:14] <stgraber> as it now reset the testing period of lxc and so when sysvinit will be copied (in 2 days), it's going to break lxc for all precise users
[13:14] <stgraber> though the fix in 0.7.5-3ubuntu62 is quite trivial, so I guess the regression testing period for that one can be shorten and both sysvinit and lxc still be released at the same time
[13:16] <ScottK> stgraber: It was me.  If you don't want something accepted, I guess I don't know why you uploaded it.
[13:17] <stgraber> I didn't upload it
[13:17] <stgraber> I uploaded 0.7.5-3ubuntu61
[13:17] <ScottK> I see.    If there's an existing package in -proposed and you upload a new one, that should probably mean you want the existing SRU replaced.
[13:20] <stgraber> the new upload also didn't use -v so the bug list for the package on pending-sru is also wrong (doesn't list bug 974584). I'll make sure to manually track the lxc SRU and nag whoever's on duty when sysvinit reaches 7 days and both should be copied
[13:20] <ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
[13:20] <stgraber> I'm testing 0.7.5-3ubuntu62 now to make sure it actually works as expected
[13:31] <stgraber> ScottK: I commented in bug 974584, so hopefully whoever is on SRU duty will notice and copy both. In theory that should be during bdmurray's shift so I should be around.
[13:31] <ubot2> Launchpad bug 974584 in sysvinit "Semaphores cannot be created in lxc container" [High,Fix committed] https://launchpad.net/bugs/974584
[13:31] <ScottK> Great.  Sorry for the confusion.
[14:00] <bdrung> hi. vlc is in -proposed since one week without someone reporting a regression (lp: #1025713). is it time to get it into -security/-updates?
[14:01] <cjwatson> brendand: http://people.canonical.com/~ubuntu-archive/pending-sru.html says (a) lots of bugs still verification-needed and (b) 7-day aging period not quite up
[14:01] <cjwatson> er
[14:01] <cjwatson> bdrung: ^-
[14:02] <jdstrand> cjwatson: are you actively looking at installation-guide? I have an untested preliminary patch to use xml2po from gnome-doc-utils. I'm happy to let you do it, but I can also do it
[14:02] <cjwatson> jdstrand: Yes, I've just uploaded a fix
[14:03] <jdstrand> sweet, that'll save me some time
[14:03] <jdstrand> cjwatson: thanks!
[14:03] <cjwatson> jdstrand: It didn't actually need poxml at all really since we don't ship any translations
[14:03] <jdstrand> even better
[14:03] <cjwatson> Which has been vaguely on my to-do list since warty and therefore will probably never happen ;-)
[14:03] <jdstrand> hehe
[14:04] <cjwatson> Sorry to steal the bug but I needed to update i-g anyway :)
[14:04] <jdstrand> cjwatson: no, that is totally fine. I only spent about 20 minutes on it last night
[14:05] <bdrung> cjwatson: VLC has a preliminary MRE
[14:09]  * cjwatson has no context except what's on the web page :)
[14:09] <cjwatson> (internet-poor at the moment)
[14:28] <bdmurray> ScottK: regarding sru-release that is what was discussed in the sru team call and the comment includes information regarding reporting a new bug and tagging it regression-updates a tag to which SRU team members can or are subscribed
[14:32] <ScottK> bdmurray: OK.  Thanks.
[16:29] <balloons> do we normally only retain the last milestone images?
[16:29] <balloons> I mean to say, I can't download alpha one from quantal using http://cdimage.ubuntu.com/releases/quantal/
[16:29] <balloons> only alpha 3 is listed
[16:30] <slangasek> balloons: correct
[16:31] <slangasek> the images still exist, but aren't on the website anymore
[16:31] <balloons> slangasek, interesting..it would just be a link right?
[16:31] <slangasek> how do you mean?
[16:31] <slangasek> the images are not on the server that provides the website
[16:31] <slangasek> they get archived off
[16:32] <balloons> ahh..
[16:32] <balloons> ok, so if I wanted to see if we regressed on an issue from alpha2 -> alpha 3, what do I do?
[16:32] <slangasek> good question
[16:32] <slangasek> so this is ringing bells with me, that there was some previous discussion about keeping the milestone images around longer
[16:33] <slangasek> but I don't remember who I had that conversation with and what the outcome was
[16:33] <ogra_> we should keep them public until release really
[16:33] <slangasek> we never have because of space considerations on the webservers
[16:33] <ogra_> yep, i understand the tech reason :) just saying
[16:33] <balloons> :-) yes, space is a concern
[16:34] <balloons> but I think the milestones are worth keeping about.. at least during the dev cycle of the current release
[16:35] <ogra_> though iirc rick suggested in the "no more freezes" thread that we should actually keep all daily images around in that scenario ...
[16:35] <slangasek> balloons: yes, we did not have room to do that at all
[16:35] <slangasek> I don't know if we have room now
[16:35] <ogra_> so there should at least be more HW in the pipe for providing such a setup
[16:36] <slangasek> pgraner: was it you that was asking about keeping multiple milestone images around during the devel cycle?
[16:36] <slangasek> whatever discussion we had about this didn't translate to an update on the milestone process
[16:38] <balloons> Well, I think we could possibly get some help for hosting if needed..
[16:38] <balloons> slangasek, atm, if I wanted an alpha 2 image, does it exist anywhere?
[16:38] <slangasek> it exists but isn't somewhere you can get to it
[16:39] <slangasek> I can cheat and repost it temporarily to cdimage.u.c, I think
[16:40] <slangasek> balloons: http://cdimage.ubuntu.com/releases/quantal/alpha-2/ shortly
[16:40] <Daviey> s3 storage would be perfect for this :)
[16:41] <balloons> slangasek, if we had a mirror willing to host, could we provide official gpg and md5's for the images and link out to the mirror do you think?
[16:42] <balloons> slangasek, :-) ty
[16:42] <skaet> slangasek,  Laney and I talked about leaving A2
[16:42] <slangasek> skaet: well, I didn't get the memo ;)
[16:42] <jdstrand> fyi, I'm back to tending to kde in component-mismatches
[16:44] <skaet> slangasek,   if space permits,  I'm +1 on keeping all the milestones up and accessible during the cycle.   We do need to change the checklists on the subject though ;)
[16:45] <ogra_> at least we should keep $current_milestone-1
[16:46] <ogra_> not sure having A1 around makes sense if we are at A3 already
[16:48] <skaet> ogra_   thought we were going to keep $current_milestone-1 around, but it appears glitch happened.   in terms  older ones - possibly useful to narrow down when a bug may bug may have been introduced, but am not fussed if we don't either.
[16:48] <ogra_> yeah
[16:49] <balloons> I'm not sure how the no alpha's or milestones discussion goes with this, but having those points in time to help pinpoint issues is useful. In this case, I want to check out alpha 2
[16:50] <balloons> ogra_ I'm sure can speak to it.. pinning down things like kernel regressions it's helpful to have old versions around to see when the regression started for testing :-)
[16:51] <ogra_> balloons, indeed, but yu wont have the iterations between the milestones around anyway and A1 is traditionally pretty crappy
[16:51] <ogra_> ("just good enough to have the installer work" usually)
[16:54] <skaet> ogra_,   traditions have been changing...   your ARM bias is showing   ;)
[16:54] <ogra_> nah, has nothing to do with arm but with achievability without losing actual development time
[16:55] <balloons> :-) I want all the milestones, to help ensure we given the community the tools needed to help us test; specifically when we have regressions. It is very often the case people encounter problems with a specific milestone that didn't previously exist, but without the images it's harder to verify and pin that down..
[16:55] <ogra_> it usually takes the time before A1 to actually even make the bits installable and get the installer in initial shape for a new release
[16:55] <balloons> obviously automagically iterating through daily images for regression testing would be amazing.. heh, we should start somewhere
[16:55] <ogra_> there is no time to make it shiny at that point of the cycle
[16:56] <ogra_> if you want it better, A1 should be released at A2 time
[16:56] <ogra_> ro we should double up the amount of developers :)
[16:56] <ogra_> *or
[16:57] <balloons> ogra_, lol, double devs.. that would make it take until alpha 3!
[17:07]  * skaet just updated https://wiki.ubuntu.com/MilestoneProcess checklist to make it explicit to keep prior milestone around.
[17:07] <balloons> thanks everyone!


[16:27] <slvn_> Hello
[16:27] <slvn_> I have a Nexus 10, where I put UbuntuTouch (#303)
[16:28] <slvn_> I have cross compiled the lib SDL, using a chroot armhf, and I am trying to run an application SDL on this device
[16:29] <slvn_> I have changed the call "mir_connect_sync(NULL, ...)" to "mir_connect_sync("/tmp/mir_socket")
[16:29] <slvn_> so that is connect correctl (call to connection_is_valid returns true)
[16:30] <slvn_> and I have switch the internal configuration of SDL to use openg es 2.0  ... to avoid the lib crashing
[16:31] <slvn_> my test programm executes correctly, but nothing is displayed on the screen !
[16:31] <slvn_> Any Idea ?


[15:34] <OvenWerks> Eickmeyer: I am thinking to disallow setting pulse connections unless jack is running
[15:38] <OvenWerks> That seems... yucky
[15:39] <OvenWerks> I think I will instead show: disconnected, old choice, each device we know about with only ports 1 and 2, system with 1 to 18 as now?
[15:40]  * OvenWerks thinks thinking out loud can be helpful  :)
[15:41] <OvenWerks> I will add an aditional entry that says: please start jack for the real list of ports
[15:44] <OvenWerks> So the first entry would be: no connection, then the users last choice (if different from none) and make this one active, then a warning that jack is not active and the ports can not be seen.
[17:51] <Eickmeyer> OvenWerks: That sounds good.


[06:55] <dholbach> good morning
[07:36] <dholbach> hola dpm
[07:36] <dpm> morning dholbach
[07:42] <elfy> morning all
[07:43] <elfy> dholbach: sorry - but I've been doing that bug reporting thing again for the community pages  ... https://bugs.launchpad.net/ubuntu-community-website/+bug/1250747
[07:43] <ubot2> Launchpad bug 1250747 in Ubuntu Community Website "Error on http://community.ubuntu.com/contribute/ " [Undecided,New]
[07:44] <dholbach> elfy, it needs to be read in the context of the whole paragraph
[07:44] <dholbach> help docs team: review forums threads, see if they can be added as guides to the help wiki
[07:44] <dholbach> that's at least how I understand it
[07:45] <dholbach> I didn't write this piece of text
[07:45] <elfy> lol
[07:45] <dholbach> why do you laugh?
[07:45] <elfy> I didn't write it either :)
[07:45] <elfy> don't get defensive :)
[07:46] <elfy> I don't read it like that at all, when I read that section I get : Find something, read the forum, check it, add it to wiki
[07:46] <dholbach> I just wanted to make clear that I may be the "go to person" for the page, but don't want to take credit for writing all the text :)
[07:47] <elfy> I suppose I can sort of see what it's aimed at, but perhaps it's not conveying it that way
[07:47] <dholbach> so how do you understand it?
[07:48] <elfy> dholbach: oh - I know you didn't write it all :) you just happen to be the person I see in the morning when I notice these things
[07:48] <elfy> dholbach: at first glance there are all these links to wiki/docs with a random forum link in the middle
[07:49] <elfy> it 'appears' to be a reference to a dead attempt to get good information from the forum to the wiki
[07:49] <dholbach> elfy, via https://help.ubuntu.com/community/WikiGuide it refers to https://wiki.ubuntu.com/DocumentationTeam/Wiki/Tasks which specifically mentions the forums how to section
[07:49] <dholbach> yes
[07:50] <dholbach> so if we can refine the text blurb on community.u.c and link to the right places, we might make it make sense after all :)
[07:50] <elfy> I'll have a look at those links when I'm back from work then. Once I've done that I might be able to discern what the comm page is trying to say and will make a note on the bug
[07:51] <elfy> how does that sound?
[07:52] <dholbach> sounds great to me :)
[07:58] <elfy> I shall go back to muttering about work now - cya later :)
[08:01] <dholbach> thanks elfy
[15:07] <dholbach> hey jono
[15:11] <jono> hey dholbach!
[17:00] <dholbach> all right my friends - I'm off for today! see you tomorrow! hugs!
[17:22] <jono> jose, ping?
[17:24] <jcastro> hey jono
[17:25] <jcastro> I am having gtalk plugin issues, is there a way I can be dialed in via normal phone for the press room thing?
[17:26] <jono> jcastro, we are not doing it today
[17:26] <jcastro> thanks!
[17:26] <jcastro> it's still on the calendar btw
[17:26] <jono> I am just providing a summary of the recent sprint
[17:26] <jono> ok, will delete
[17:26] <jono> mhall119, can you notify everyone that we are not doing it
[17:26] <jono> thanks!
[17:29] <mhall119> sure
[17:30] <mhall119> man, does google calendar not have an option to cancel just one event in a series?
[17:31] <cjohnston> it does
[17:32] <cjohnston> delete then it asks you
[18:56] <jcastro> hey jono popey mhall119
[18:56] <jcastro> did you guys see the Moto G?
[18:56] <jcastro> $179, fully unlocked
[18:56] <jcastro> man, if we could get UT on there ....
[18:57] <mhall119> G?
[18:57] <mhall119> no, havne't seen that yet
[18:57] <jcastro> http://motorola-blog.blogspot.com/2013/11/introducing-moto-g-exceptional-phone-at.html
[18:57] <jcastro> it's a stripped down moto X
[18:57] <jcastro> but you can get them in colors and stuff
[18:57] <jcastro> I am thinking .... ORANGE.
[19:07] <mhall119> is it as easily hackable as the Nexus devices?
[19:08] <jcastro> no clue
[19:08] <mhall119> pre-Google Motorola was notorious for locking their devices up
[19:08] <jcastro> my job is to drop a bomb like this and then escape out the back
[19:08] <mhall119> damn you jcastro!
[19:08]  * mhall119 shakes fist in the air
[19:12] <bkerensa> I have the Moto X... I don't know how awesome a stripped down one would be
[19:12] <bkerensa> The battery life on the Moto X though is hands down amazing
[19:16] <popey> jcastro: http://www.bbc.co.uk/programmes/p01l3ljq
[19:17] <popey> also jcastro http://www.bbc.co.uk/programmes/b00pgv4j
[21:21] <jose> jono: sorry, was at school, what's up?
[22:23] <jono> jose, its ok, all sorted
[22:23] <jono> thanks!
[22:23] <jose> great then, no worries :)