[02:15] <Viper550> You need ideas for a new update-notifier icon?
[02:28] <troy_s> No.
[02:28] <troy_s> No one has ideas.
[02:30] <Viper550> I do...
[03:13] <troy_s> *sigh*
[11:18] <darkstar> hi there
[11:19] <PingunZ> hello
[11:19] <darkstar> quite today, isn't it?
[11:20] <darkstar> Just apoproached edgy, coming from openSuse.. Is there a way to have an OSX-like desktop, the easy way?
[11:20] <darkmatter> yup
[11:20] <darkmatter> welll... kinda
[11:21] <darkmatter> theres several osx like themes
[11:21] <darkmatter> theres also
[11:21] <lizardking> darkmatter: look at gnomelook
[11:21] <darkstar> I prefer using gnome, btw
[11:21] <darkmatter> a macmenu for gtk
[11:21] <lizardking> darkmatter: I think apple style is hard to copy
[11:22] <darkstar> not a real clone of the ma style.. something more pleasant than the standard look
[11:22] <darkmatter> lizardking, not really... ony real "hardpoints" are the tabs
[11:23] <lizardking> darkmatter: yes
[11:23] <lizardking> lizardking: also gnome panels
[11:24] <darkmatter> but not that it matters... I'm not really a "mac guy"... but I con almost perfectly clone mac style (I've done it for clients)... its just not a "one click" operation
[11:24] <darkmatter> *can
[11:25] <darkstar> so should I take a look at gnome-look?
[11:25] <darkmatter> sure
[11:26] <darkstar> any suggestions? any known theme that works well according to your opinion?
[11:29] <darkmatter> hmmmm... hard to say... my themes not done (thus not worthy)... and a lot of themes  that are "done" arent... hmmmmm
[11:30] <darkstar> tell you what: I'll go taking a look. if anything pleases me i'll grab it.
[11:30] <darkstar> Thanks for your help.
[11:30] <darkstar> Have a good one.
[03:36] <darkmatter> troy_s, another thing for your consideration to add to the list of exported elements, scrollbars
[04:41] <troy_s> darkmatter: I was under the impression that we were going to try and expose everything.
[04:42] <darkmatter> yup
[04:42] <darkmatter> anyay.. been up all night.. nap time
[04:42] <darkmatter> ;)
[04:44] <troy_s> Yah
[04:44] <troy_s> nicht
[06:16] <troy_s> Builder of bikesheds -- kwwii you in?
[08:58] <Viper550> You said you were going to have trouble with getting the Usplash artwork into GFXBOOT
[09:23] <Viper550> anyone here?
[09:29] <kwwii> I am here but I am in a meeting
[09:30] <kwwii> so i am not really here
[09:30] <Viper550> Okay then, I see you got my email about me noticing that gfxboot oddity on Ubuntu CE
[09:31] <kwwii> yeah, thanks for mentioning that, i would not have noticed
[09:35] <Viper550> I'm also considering whipping up a new Ubuntu login screen using the new version of the Gnome GDM theme (with the ok/cancel buttons) as the base
[09:40] <kwwii> you mean a new gdm theme or a new login splash?
[09:41] <Viper550> gdm, that's what I said
[09:41] <msikma> hmm
[09:41] <msikma> Doesn't the latest unstable version of Ubuntu have DejaVu Condensed as default font?
[09:41] <kwwii> msikma: yes, it should
[09:42] <msikma> Does anyone know for sure?
[09:42] <msikma> If it is, then the default hinting must be set to "slight"
[09:42] <msikma> The hinting seems to not work at all on the other settings.
[09:42] <msikma> But it does work rather nicely on "slight".
[09:42] <kwwii> msikma: that is a problem with gnome
[09:42] <kwwii> msikma: I'll look into that
[09:42] <msikma> It's kind of strange how it doesn't get hinted on "medium"
[09:42] <Viper550> This new font is well, interesting
[09:43] <kwwii> msikma: yeah, seems freaky
[09:44] <Viper550> I actually kinda like it, looks more contemporary
[09:49] <kwwii> Viper550: not sure how much we are going to change the GDM for feisty
[09:50] <Viper550> I'm trying to make it as simliar to the old one as possible layout wise
[09:51] <Viper550> And from what I saw on the Wiki, you are doing most of the work on Fiesty.
[09:51] <kwwii> yeah, pretty much all of it
[09:52] <kwwii> since I am getting paid to do it
[09:52] <Viper550> O_O
[09:57] <kwwii> of course, that does not mean that others cannot help, just that in the end I'll be responsible for it (responsible to report to sabdfl that is)
[09:58] <Viper550> k then! Is there a preview app for GDM themes?
[09:59] <kwwii> not that I know of
[10:03] <Viper550> So far, I've replaced the background, the Options icon, and the "new default fonts"
[10:21] <troy_s> kwwii
[10:22] <troy_s> You in?
[10:22] <Viper550> wanna see my XML so far?
[10:22] <Viper550> p.s. troy_S: he's in a meeting


[02:39] <DPic> hey guys
[02:57] <boredandblogging> DPic: hello
[02:58] <DPic> just thought of an idea
[02:59] <DPic> "I used Linux before it was cool" as a marketing campaign. the only application i can thing of for this is making facebook, orkut, myspace, whatever groups with that as the title. 1) to say that Linux is or will be the cool thing. 2) to show off stuff like compiz
[02:59] <DPic> think*
[03:10] <boredandblogging> heh
[03:11] <boredandblogging> should have t-shirts made with that
[03:12] <DPic> should i make that a project under this team? or is that unnecessary and i can just make groups on those social networking sites
[03:20] <DPic> could you think of other ways to use that phrase?
[03:21] <boredandblogging> you don't want to leverage the existing groups? I know there are some Ubuntu groups on facebook
[03:22] <boredandblogging> not sure people won't think its a complete geek thing
[03:27] <DPic> hmm.. well i think having a group title like this won't make it a geek thing
[03:27] <DPic> and the point is to attact people who aren't the types to join our existing groups
[03:28] <DPic> t-shirts was a good idea, can you think of other ways to use it?
[03:29] <boredandblogging> not really, but the group idea is actually growing on me
[03:32] <DPic> do you think it's worth creating a project page on the wiki?
[03:33] <DPic> i'll create the groups-- do you think i should use Linux or Ubuntu? Ubuntu would probably be better since it's more mainstream and less geeky
[03:35] <boredandblogging> i'd create a page and just say what you did
[03:36] <DPic> alright
[03:37] <DPic> and do you agree that i should use Ubuntu instead of Linux?
[03:38] <DPic> "I used Ubuntu before it was cool"
[03:39] <DPic> or should i say linux?
[03:53] <boredandblogging> Ubuntu is fine
[18:34] <Mike_Feravolo> does anyone know how to report a problem with the lastest hardy update ?
[18:34] <Mike_Feravolo> I tried the mail list but it kicked back
[19:51] <Flannel> Mike_Feravolo: Launchpad and/or #ubuntu+1
[21:19] <Syntux> are there any of Marketing team available ?
[21:21] <desertc> what's up?
[21:22] <Syntux> nothing serious but http://www.flickr.com/photos/jad/2300189167/
[21:23] <desertc> eh - it's a guy on a camel
[21:23] <Syntux> it's me.
[21:23] <Syntux> with Ubuntu hat.
[21:27] <Syntux> http://syntux.net/blog/2008/02/29/ubuntu-camel-race/


[10:31] <Starhero> Anyone here?
[10:31] <rww> Starhero: yes
[10:31] <Starhero> I need some help
[10:31] <Starhero> hold on sec
[10:33] <Starhero> I am trying to fsck my drive
[10:33] <Starhero> ext 4 partition(s) on sda
[10:33] <Starhero> i am trying to do this before boot
[10:33] <Starhero> or during ...recovery doesn;t do it..
[10:34] <Nafallo> Starhero: from the topic "This is NOT a support channel, support in #ubuntu etc."
[10:34] <rww> Starhero: Ubuntu support is in #ubuntu. This channel is for operator discussion about non-core Ubuntu channels.
[10:34] <Starhero> ok sorry
[11:47] <bilalakhtar> ^ was just to show others, sorry for that
[14:33] <AlanBell> hi, are the logs broken
[14:33] <AlanBell> http://irclogs.ubuntu.com/2010/11/28/
[14:43] <jussi> AlanBell: #canonical-sysadmin (they run the bots)
[14:43] <jussi> (and probably a rt ticket)
[18:42] <guntbert> logging for #ubuntu.... seems broken since yesterday noon - who to poke?
[18:43] <guntbert> nvm, just saw the time of the last topic change .... :-)
[18:45] <tsimpson> guntbert: we have poked the relevant people already, but you know... it's a weekend
[18:46] <guntbert> tsimpson: I see - its no big issue - thx for noticing
[19:19] <IdleOne> time to go nuts now that nobody is watching
[19:27] <bilalakhtar> I saw ubuntulog become ubuntulo1
[19:27] <bilalakhtar> is that responsible?
[19:28] <tsimpson> probably not
[19:28] <bilalakhtar> s/responsible/the reason/
[19:29] <m4v> ubuntulo1 is just its alternate nick methinks
[19:32] <m4v> when it changes to ubuntulol is when you should be worried.
[21:19] <nizarus> the ubuntulo1 bot are not logging irc channels
[21:19] <guntbert> nizarus: see the /topic :-)
[21:21] <nizarus> oupss :/ thx guntbert
[21:21] <guntbert> :-)


[14:28] <genii> BobJonkman: Both photos from Saturday now uploaded to pix.ie
[15:36] <BobJonkman> genii: Did some editing on the metadata for the first. Thanx for the photos!
[15:37] <genii> :D
[15:37] <BobJonkman> http://pix.ie/ubuntuca/3588496/in/album/493054 for those of you who want to see...
[18:31] <BobJonkman2> Also uploaded the photos for Victoribuntu Hour: http://pix.ie/ubuntuca/album/493061/detailed
[18:33] <genii> Cool
[18:35] <genii> I guess Darcy is pretty busy these days, don't see much activity from him.
[18:47] <BobJonkman2> Darcy comes to the KW Ubuntu Hours when he can; I spoke to him on Sunday and he was pleased to have finished his term on the board of Kwartzlab.
[18:48] <BobJonkman2> Considering he pretty much singlehandedly revived Ubuntu-Canada in 2008-2009, (and started up Kwartzlab at the same time) I think he can use a rest
[18:50] <BobJonkman2> I was just reading about the Catalan team's rejection for re-approval because it doesn't fit neatly inside political borders.
[19:04] <genii> Weird, because they approved the Palestinian team
[20:19] <BobJonkman1> And the  Quebec Team. And the Vancouver Team. And only last year they were agitating to split Canada up into provincial teams.
[20:20] <BobJonkman1> IRC logs at http://irclogs.ubuntu.com/2014/05/20/%23ubuntu-meeting.html#t19:41
[21:12] <IdleOne> I thought they did away with approval/official teams
[21:20] <BobJonkman1> IdleOne: It's now "re-verification", same process, different name
[21:20] <IdleOne> yeah, sounds like a waste of time to me. I guess they have to have some sort of accountability to justify who gets swag
[21:21] <BobJonkman1> Sure, and that
[21:21] <BobJonkman1>  and that's fine by me. But to shut down an active LoCo with hundreds of members and a half-dozen upcoming events because rules...
[21:23] <IdleOne> so catalan gets no cd's now?
[21:23] <BobJonkman1> Anyway, it seems not everyone on the LoCo council agrees with that ruling
[21:23] <BobJonkman1> Their "re-verification" was rejected, so I expect not.
[21:23] <IdleOne> We have any extra we can send them?
[21:23] <IdleOne> I'll chip in $10 for shipping
[21:24] <IdleOne> maybe I can swing $15 if need be
[21:24] <BobJonkman1> I've got about 20 left here. I think Darcy still has most of one box (destined for the UofW CSClub)
[21:24] <BobJonkman1> And the Ubuntu-ca-london chapter got a couple of boxes of their own.
[21:25] <IdleOne> I bet if someone put out a call on the ML (not me) to see what other loco's could do to help get them some cd's and stuff. We could get a decent response.
[21:25] <BobJonkman1> Now, their approval only expired in May, so they may already have teh 10.04 disks...
[21:26] <IdleOne> right but they probably need 14.04 discs
[21:26] <BobJonkman1> Let me see if I can contact Rafael from the Ubuntu-Cat team first
[21:26] <BobJonkman1> Heh. Typo. I meant 14.04 disks.
[21:26] <IdleOne> ahh ok
[21:36] <BobJonkman1> OK, I have reached out in #ubuntu-cat but is seems everyone is AFK ATM


[01:57] <kenvandine> fginther, no joy...
[01:57] <kenvandine> EnvironmentError: Device either not connected, doesn't have adb enabled or the property system cannot be accessed. Make sure the device is booted into the operating system and that adb is working correctly.
[02:19] <fginther> kenvandine, sorry about that. One of the devices was still stuck. Trying again.
[04:25] <kenvandine> fginther, cool, thx
[05:23] <Mirv> (trying to get published but train is funky)
[05:36] <Mirv> ah, right, it's a train bug since there's a "-" in the upstream version number
[06:47] <Mirv> ^ OTA-6 fix
[07:11] <oSoMoN> ubuntu-qa: good morning! I’ve got two silos awaiting validation (16 and 26, although I haven’t marked 26 ready for QA yet but it is indeed ready), 16 was there before but 26 is much more urgent (fix for HERE maps not starting), can 26 get priority for verification once I mark it ready?
[08:05] <ogra_> jdstrand, go for it at any time :)
[08:36] <dbarth_> o/ hey any citrain guru out there?
[08:36] <dbarth_> can you confirm if adding the overaly ppa as a ppa dependency affects "desktop builds"
[08:39] <ogra_> dbarth_, with overlay means you have a mix of wily and vivid, without your vivd is plain ... if your build uses any dependency from the ppa you will get different results indeed
[08:42] <ogra_> (there are also phone specific config tweaks that could have influence if you have the respective packages installed (by accident, from a dependency or on purpose)
[08:42] <ogra_> )
[08:43] <dbarth_> hmm, so i think we need to have vivid /phone/ builds only go via citrain then
[08:43] <dbarth_> that will be safer
[08:52] <dbarth_> o/ trainguards, can i have a source upload in silo 032 please? see the comment in the silo request
[09:01] <jibel> oSoMoN, 26 approved. It also fixes problems with other apps like ureadit
[09:01] <oSoMoN> jibel, thanks! Yes, potentially all apps using an Ubuntu WebView and redefining the context menu actions were broken without that fix
[09:02] <oSoMoN> jibel, once merged I’ll rebuild silo 16
[09:02]  * sil2100 loves projects that can still dual-land
[09:02] <sil2100> This makes life so much less complicated
[09:03] <pstolowski> trainguards hello, can i get a silo for request 161?
[09:03] <sil2100> dbarth, pstolowski: on your requests now
[09:03] <sil2100> Are we low on silos?
[09:04] <pstolowski> sil2100, ah, ok, cool, i couldn't see a notification on this channel
[09:04] <sil2100> pstolowski: assigning your request, btw. do you have a wily silo for the changes as well? Or did that land already?
[09:06] <sil2100> dbarth: copying
[09:06] <sil2100> dbarth: btw. you sure a source copy is needed?
[09:07] <sil2100> You need it rebuilt against the overlay?
[09:10] <pstolowski> sil2100, i've MPs ready for wily as well, but we need to regenrate symbols for g++5, and also scopes api currently has issues at least in CI because of a boost problem
[09:10] <pstolowski> sil2100, so at the moment we have a couple of changes that will need to be landed in wily to catch up with vivid, they are not forgotten but not fully ready to land
[09:16] <abeato> sil2100, hi, I'd like to add a new package to touch image in rc-proposed
[09:16] <abeato> sil2100, the new package gets created from source package pulseaudio in silo 30
[09:17] <abeato> sil2100, which would be the procedure?
[09:23] <sil2100> pstolowski: could you later at least request a silo for the wily ones? Doesn't have to be built even
[09:23] <sil2100> We just want it as a silo at least :)
[09:24] <pstolowski> sil2100, ok, will do
[09:24] <sil2100> Thanks!
[09:25] <sil2100> dbarth: re-stating the question - you sure a source copy is required, not a binary one? Need to know since making a source copy involves me re-writing the version ;)
[09:33] <pete-woods> cihelp: hi folks. is it reasonable to enable the GCC5 PPA for jenkins builds, like it is for CI train wily builds?
[09:33] <pete-woods> at the minute it
[09:33] <pete-woods> can be impossible, depending on what you're building to get jenkins to pass your MRs because of this
[09:43] <Mirv> pete-woods: GCC5 PPA is not anymore just a PPA, it's almost all in wily archives already
[09:45] <pete-woods> Mirv: even so. this is currently hurting those who are using a "devel" branch (fortunately not myself in this instance)
[09:45] <pete-woods> as they aren't able to get verification of their MRs before merging
[09:46] <Mirv> ok, let's wait for answer then
[10:02] <sil2100> Mirv: ^ you publishing that? I don't know if I should publish your own silo ;)
[10:05] <sil2100> wgrant: hey! Since all translations seem to have been copied into place, could I request a full export from the 15.04 series?
[10:05] <dbarth> sil2100: a source copy please, yes; i want to make sure we pick up the media-hub 3.1 library, where there is a binary interface change
[10:05] <sil2100> dbarth: ACK! On it then
[10:25] <psivaa> pete-woods: (regarding the GCC5 PPA query), i'm not sure what's involved. I'd need to talk to fginther about it. Will come back to you once he's online
[10:30] <pete-woods1> psivaa: thanks :)
[10:32] <Mirv> sil2100: sure, I tend to handle those :) plus packaging changes need an ack I can do because of PPU rights
[10:33] <sil2100> :)
[10:55]  * sil2100 off for lunch and quick shopping
[10:55] <sil2100> o/
[11:12] <oSoMoN> jibel, I rebuilt and validated again silo 16, it’s ready for QA
[11:42] <jibel> oSoMoN, great, on it
[11:47] <oSoMoN> jibel, thanks!
[12:08] <jibel> oSoMoN, how do you reproduce bug 1477308 ? I cannot with the steps in the description
[12:25] <oSoMoN> jibel, it’s on desktop only: you need to e.g. watch a youtube video fullscreen, then press the media keys on your keyboard to increase/decrease the volume: this shows the volume update in a notify-osd bubble, and has the undesired side effect of leaving fullscreen mode
[12:26] <jibel> oSoMoN, yeah, sorry, I figured that out after re-reading the first sentence of the bug report
[12:32] <jibel> oSoMoN, 16 approved. Is it all for OTA6?
[12:33] <oSoMoN> jibel, would be good to have for OTA-6, yes, particularly since it contains the fix for find-in-page which is new in OTA6
[12:33] <jibel> oSoMoN, I meant after silo 16 is there anything left for OTA6? webbrowser wise
[12:34] <oSoMoN> jibel, ah, sorry, I misread you :) in theory that’s all, nothing more for OTA6
[12:34] <jibel> thanks
[12:35] <pedronis> trainguards: hi, Pat marked https://bugs.launchpad.net/ubuntu/+source/ubuntu-push/+bug/1451510 for OTA-6 and we got a community fix... the package is a bit in maintainer limbo atm,  I reviewed the code and made landing MPs, but I'm not really setup anymore for landings, can you help preparing the landings
[12:40] <Mirv> pedronis: ok, 1. who'd be the lander (tester) of it, 2. what's the exact MP to land, 3. does ubuntu-push have only one trunk, ie this could be dual landed to overlay + wily?
[12:41] <pedronis> Mirv: I made two trunks, I have two MPs one for vivid-overlay and one for wily, I can give you the URLs in a sec
[12:42] <pedronis> Mirv: vivid-overlay: https://code.launchpad.net/~pedronis/ubuntu-push/vivid-fixes/+merge/268066
[12:43] <pedronis> Mirv: wily: https://code.launchpad.net/~pedronis/ubuntu-push/fixes-to-wily/+merge/268067
[12:45] <pedronis> Mirv: tester: mainly the author of the patch: https://launchpad.net/~nikwen  nikwen here on freenode, email<EMAIL_ADDRESS>and put me in as second, when/if we have packages I'll ping him
[12:49] <Mirv> pedronis: ok both are now building https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=nikwen - obviously wily will be probably impossible to test, so focus on vivid
[12:49] <pedronis> Mirv: yup, thanks
[13:04] <tvoss> sil2100, you around?
[13:31] <sil2100> tvoss: yeah, what's up?
[13:32] <sil2100> wgrant, cjwatson: hey, can anyone of you guys request a LP pack export for ubuntu-rtm/15.04?
[13:33] <wgrant> sil2100: Sure
[13:34] <sil2100> Thank you :)
[13:34] <sil2100> I would like pitti to run langpack-o-matic once today still to see if everything works for next week
[13:43] <abeato> sil2100, I get a failure when trying to build ubuntu-touch session in silo 30
[13:43] <abeato> sil2100, silo 30 was originally a sync silo from57
[13:43] <abeato> (from silo 57)
[13:44] <abeato> sil2100, silo 57 contains ubuntu-touch-session
[13:44] <abeato> sil2100, and building it in silo 30 used to work: it took the sources for there
[13:44] <abeato> sil2100, but now silo 30 contains also a MP for trust-store
[13:45] <sil2100> abeato: ok, I don't see it in the list of packages for silo 30 - you'll have to include it there
[13:45] <abeato> sil2100, is that the cause of the failure?
[13:45] <abeato> sil2100, but can I sync it?
[13:45] <abeato> from silo 57
[13:46] <sil2100> abeato: yes, we just need to include it in the Manual Source list in the landing entry, let me do that - for syncs to work if you have multiple different packages in the silo, you need to give the explicit list of packages you might want to sync from the source silo
[13:47] <abeato> sil2100, ok, I have just reconfigured
[13:47] <sil2100> abeato: yeah, I see it appeared now :) Did you press 'Assign' again to reconfigure?
[13:47] <abeato> sil2100, yep :)
[13:47] <sil2100> Once you fully reconfigure the silo, try building ubuntu-touch-session in the build job - it should try syncing it from the source silo
[13:48] <abeato> ok, thanks
[13:48] <sil2100> (a normal build with ubuntu-touch-session as the package to rebuild)
[13:49] <abeato> yeah, it is working now :)
[13:50] <sil2100> \p/
[15:01] <greyback> trainguards: could someone please remove ubuntu-touch-session from silo0
[15:17] <sil2100> greyback_: on it in a minute!
[15:31]  * ogra_ sees sil2100 in the news
[15:32] <awe_> sil2100, can you checkout my landing request ( 170 ) when you get a chance.  This is my first request for thenew train, and I wasn't sure if I need to do anything to trigger the build, or it will just come in time?
[15:46] <sil2100> oSoMoN: again something bad..?
[15:46] <sil2100> I mean, ogra_: ^
[15:46] <sil2100> oSoMoN: sorry, bad auto-complete in irssi ;)
[15:46] <sil2100> greyback_: silo 0, right?
[15:47] <greyback_> sil2100: right
[15:47] <oSoMoN> sil2100, no worries :)
[15:50] <bfiller> sil2100: where would I find debug packages for packages in overlay ppa? (I hope they exist)
[15:50] <greyback_> bfiller: deb http://ppa.launchpad.net/ci-train-ppa-service/stable-phone-overlay/ubuntu vivid main/debug
[15:50] <bfiller> greyback_: great, ty!
[15:51] <greyback_> np
[15:51] <sil2100> bfiller: yeah, they're in the overlay itself :)
[16:00] <popey> sil2100:  is there a landing call today?
[16:00] <sil2100> popey: there was one in the morning :)
[16:01] <popey> heh okay
[16:01] <sil2100> We only do one in the morning and yesterday in teh evening
[16:01] <popey> ok
[16:01] <sil2100> popey: anything you wanted to bring up?
[16:01] <popey> no
[16:01] <sil2100> LP timeouts for me a bit, hm
[16:02] <sil2100> ogra_: what did you mean by me in the news again? Did I screw up something?
[16:02] <popey> heh, no
[16:06] <sil2100> wgrant: hey! Do you know if the LP exports are running for 15.04? :)
[16:09] <ogra_> sil2100, http://news.softpedia.com/news/canonical-is-not-moving-ubuntu-touch-to-ubuntu-15-10-any-time-soon-489291.shtml
[16:09] <ogra_> you are getting famous !
[16:13] <sil2100> Damn, why is this suddenly such a big news? Mark and Olli mentioned that on the last vUDS
[16:13] <sil2100> And I mentioned that already a few times in the past more or less
[16:21] <greyback_> sil2100: don't worry, this won't happen to you: http://arstechnica.co.uk/gaming/2015/08/nintendo-allegedly-fires-employee-for-revealing-game-localisation-secrets/
[16:22] <sil2100> Oh crap
[16:22] <sil2100> If things like this happened here, I would get fired already for my strong language regarding the gcc-5 transition
[16:23] <sil2100> Correction:
[16:23] <greyback_> heck most of us would be looking for a job
[16:23] <sil2100> For my strong language regarding the touch gcc-5 transition
[16:23] <sil2100> ;)
[16:24] <sil2100> Since seriously there was nothing wrong with how the transition was handled, but more like with how we handled touch components - but that's to be expected with everyone working in preparation for the next OTA
[16:50] <robru> Mirv: can you file a bug for that android version number? we have a lot of test cases surrounding that and I thought we fixed "upstream version has hyphen in it" already
[17:00] <robru> whoever is actually releasing these custom tarballs should be sure to set the requests to 'Landed' once they're done
[17:05] <sil2100> dbarth: hey, so the oxide-qt in silo 32 is still building... will you give it a spin once it finishes?
[17:45] <renatu> cihelp, Guys do you know if is possible to disable willy-proposed repositories while building a project in the ppa?
[17:45] <renatu> since the proposed repository is broken I can not test my packages on the device
[17:51] <psivaa> renatu: I assume you're asking about it generally and not specific to any jobs in CI?
[17:51] <psivaa> not sure if you intended to ask trainguards?
[17:51] <psivaa> (if not sorry for the alert :))
[17:52] <robru> renatu: yes this is possible but generally not advised. what issues are you having?
[17:53] <renatu> robru, I wat to test silo 34. but it is building against some libraries from proposed universe (libphonenumber) and enabling this repository on the device crash the device
[17:53] <renatu> crash the device = install some core libraries that cause the device to not boot anymore
[17:54] <robru> renatu: from what I understand, wily is sort of in a bad state anyway with the gcc5 transition being kind of in but not really. I'm not really sure that "not building against proposed" is a sane thing to do, you'll end up with binaries built against wrong libs anyway and it won't be releasable
[17:55] <robru> renatu: I was under the impression that wily images are just outright broken even without silos
[17:55] <renatu> robru, I am using a old version
[17:56] <renatu> just for development and tests
[17:56] <robru> renatu: ok well I'll disable it for now, but I don't think we can publish the silo that way
[17:57] <renatu> robru, nice, I do not intend to release it until we can test with the new wily image
[17:57] <robru> renatu: ok, it's disabled, you can try a new build
[17:59] <renatu> robru, thanks
[17:59] <robru> renatu: you're welcome
[18:00] <dobey> you really should test against proposed
[18:00] <awe_> robru,  wondering what needs to happen to get train req #170 to build packages?  This is my first new train landing...
[18:00] <dobey> building without proposed if you have c++ code, is going to result in a failed build most likely
[18:01] <dobey> awe_: after the silo has been assigned, it's the same process as previously
[18:01] <robru> awe_: yeah you just run the build job as usual
[18:01] <awe_> ah, ok
[18:01] <awe_> thanks
[18:02] <robru> awe_: there's no new train, only the spreadsheet was replaced. the new web interface is just a dumb data store, it knows nothing about building packages, just like the spreadsheet was a dumb data store that knew nothing about anything
[18:02] <dobey> (i agree it would be nice if the build/etc… links appeared on the requests page, rather than having to go to the dashboard, though)
[18:02] <awe_> robru, ack
[18:03] <robru> dobey: yes the requests page and the dashboard have a remarkable amount of overlap, I would consider merging them into one page but I'd have to consider the UX of that, could get quite cluttered quite quickly
[18:03] <dobey> yeah. it's already quite cluttered as it is :)
[18:05] <dobey> cihelp: can we possibly get the jenkins build instances to have -proposed enabled? it only makes sense, as the silo PPAs build against -proposed, and things must go through -proposed first anyway
[18:11] <renatu> robru, did not work, you can revert the changes. Now I got missing symbols on libphonumber probably because of gcc version
[18:12] <renatu> I will need to wait until the guys fix the image to continue the tests
[18:12] <renatu> thanks for your help
[18:13] <robru> renatu: you're welcome, thanks for letting me know
[18:13] <dobey> renatu: i'm surprised you have a phone booting with a current wily image on it :)
[18:14] <renatu> dobey, I am using a previous version
[18:15] <robru> heh, mixing old wily image, packages built with current wily release pocket, sounds like a world of hurt ;-)
[18:15] <dobey> renatu: i think you can probably try devel-proposed-g++5 channel instead
[18:15] <dobey> renatu: iirc, it's built with -proposed
[18:15] <renatu> let me try that
[18:15] <renatu> thanks
[18:16] <kenvandine> renatu, if you do that, you'll need the ppa reconfigured to use -proposed again
[18:17] <dobey> kenvandine: he just asked for that :)
[18:17] <robru> kenvandine: I got it
[18:17] <kenvandine> ah, i missed that part
[18:17] <kenvandine> i thought he had just had it reconfigured to not use -proposed
[18:18] <renatu> kenvandine, I tried without proposed but it fails
[18:19] <dobey> as expected :)
[18:19] <renatu> dobey, is that channel hidden? It does not appear on the list: query --device=krillin --list-channels
[18:19] <dobey> renatu: maybe
[18:19] <dobey> renatu: https://system-image.ubuntu.com/ubuntu-touch/devel-proposed-g++5/ubuntu/
[18:20] <dobey> it's in the .json too
[18:20] <dobey> so maybe you just missed it, or it's a bug
[18:21] <dobey> i just --switch-ed my mako to it
[18:22] <renatu> or the image is not available for krillin
[18:23] <renatu> dobey, I am getting this error: Channel ubuntu-touch/devel-proposed-g++5 not found on server https://system-image.ubuntu.com
[18:24] <renatu> dobey, I am flashing with: "ubuntu-device-flash touch --channel=ubuntu-touch/devel-proposed-g++5 --wipe"
[18:26] <nikwen> trainguards, silo 23 should be ready for QA now. I tested it on my mako on ubuntu-touch/rc-proposed/bq-aquaris.en and everything seems to work fine. :)
[18:27] <dobey> renatu: ubuntu-touch/devel-proposed-g++/ubuntu
[18:27] <dobey> is the full channel name
[18:27] <renatu> dobey, worked, thanks
[18:28] <dobey> hmm
[18:28] <dobey> it doesn't seem to want to boot now though
[18:29] <dobey> it installed ok, got the big ubuntu logo while it installed, but now it just keeps rebooting at the google logo for me :-/
[18:35] <renatu> dobey, yes, I got same result as the proposed image, it get suck on "bq" screen
[18:44] <nikwen> trainguards, did you see my message above?
[18:53] <robru> nikwen: hi, was on lunch, just reading now
[18:54] <nikwen> robru, don't worry. It's just the first time I've been assigned to a landing, so I wasn't sure how fast to expect a reply. ;)
[18:54] <robru> nikwen: ok I marked it as ready for qa
[18:55] <nikwen> robru: Thanks. :)
[18:55] <robru> nikwen: you're welcome
[19:03] <fginther> dobey, hi. we could try enabling -proposed on a case by case basis. Is there a branch that's giving you special grief at this time (and I'm aware that most c/c++ projects are having build issues right now)
[19:05] <dobey> fginther: not me personally. i have just seen several people complaining about it as a result of the gcc5 transition being somewhat incomplete still, and wondering why the jenkins builds aren't building against proposed, since as soon as a silo is created, they will be building against it anyway in there.
[19:21] <fginther> dobey, ah, I see. One other dev did bring it up today so it's a little higher up the radar today.
[19:23] <dobey> yeah, i saw michi e-mailed you. and he was still on complaining about it when i got on this morning :)
[19:23] <dobey> fginther: i didn't see if anyone else asked specifically to have it enabled (rather than just complaining about it being broken), so i thought i'd follow up and ask to have it enabled
[19:26] <fginther> dobey, sure, I just wanted to make sure I had the right details before going in the wrong direction :-)
[19:26] <dobey> of course :)
[21:04] <pedronis> ubuntu-qa: I now top approved the MP in https://trello.com/c/e44QrPq2/2179-168-ubuntu-landing-023-ubuntu-push-nikwen-pedronis
[21:06] <alesage> pedronis, ack


[00:13] <krytarik> VipVop: https://wiki.ubuntu.com/X/Config/SVideo , https://superuser.com/questions/24909/output-screen-to-tv-set-using-s-video - I've found these on a quick web search instead fwiw, maybe that'll help.
[00:19] <GhettoButta> Hey anyone
[00:19] <GhettoButta> new install going here
[00:20] <GhettoButta> welp off to a reboot already!
[06:37] <gnrp> hm, anyboy here can help me with bash completion?
[06:37] <gnrp> my 16.04 system out of a sudden started completing host names
[06:37] <gnrp> like I tike `ssh in` and then it will complete it to `ssh indep`, which is a hostname
[06:38] <gnrp> however, there is no bash_completion activated. all bash_completion in /etc/bashrc and in ~/.bashrc is commented out
[06:38] <gnrp> I want to get rid of this
[06:38] <gnrp> I mean, I want no bash completion except for filenames
[06:39] <guiverc> gnrp, FYI:  Xubuntu 16.04 LTS is EOL; https://xubuntu.org/release/16-04/  (end-of-life april 21, 2019)
[06:40] <gnrp> guiverc: It will get security updates until april 2021 though, no?
[06:42] <guiverc> packages from 'main' repository (ie. those common with Ubuntu desktop) do get security upgrades, you can use `ubuntu-support-status` to see effects for your actual system, however Xubuntu & 'universe' packages for 16.04 are EOL
[06:42] <gnrp> ah, I see. Only ubuntu, not xubuntu...
[06:42] <gnrp> ok, thanks for the hint. I didn't know that. Shit.
[06:42] <guiverc> it impacts all flavors except Kylin which Canonical sponsored for 5 years only with 16.04
[06:42] <guiverc> ie. not just Xubuntu
[06:43] <guiverc> read release notes, it's spelled out very plainly (rather than bloggers that often get details incorrect)
[09:11] <dre> is there a known issue when coming out of sleep / hibernation on nouveau drivers that the keyboard / text inputs can't focus?
[09:12] <dre> can still move mouse, still changes to I beam, can't click
[09:18] <fl> hello everyone! I'm trying to install a Mac Mini from a USB stick dd'd with xubuntu-20.04.1-desktop-amd64.iso, boot fs unpacking failed: Decoding failed"..
[09:19] <fl> did anyone else see this, too? I'm suprised because last week, same USB stick and same ISO ran the installer juts fine
[09:41] <brainwash> dre: on the lock screen?
[10:40] <dre> yeah
[10:40] <dre> although it seems a bit intermittent, if I "wake" with the keyboard, keyboard works
[13:17] <xu-owen82w> Hello. I have successfully installed 64-bit Xubunto 20.04 on a 2006 Core2Duo (2.33 Ghz) iMac with 4Gb RAM. It is running well  gnerally, but, only 3Gb RAM is registered/available, but I have 2 x2Gb RAM modules installd. Anybody know how to make th e4GB ready. This is a dual boot sysytem anbd I want to maintain other OS.
[13:20] <pmjdebruijn> xu-owen82w: a 64bit version should always see all the ram
[13:20] <pmjdebruijn> xu-owen82w: maybe 1G is claimed by Intel Graphics or something?
[13:21] <pmjdebruijn> may much do you see exactly?
[13:21] <pmjdebruijn> how*
[13:22] <xu-owen82w> free -m              total        used        free      shared  buff/cache   availableMem:           2977        1378         186         337        1412        1096Swap:          1906          56        1850
[13:22] <xu-owen82w> * 2977
[13:23] <xu-owen82w> inxi -b | grep MemoryInfo:      Processes: 188 Uptime: 2h 51m Memory: 2.91 GiB used: 1.43 GiB (49.3%) Shell: bash inxi: 3.0.38
[13:24] <xu-owen82w> I think it is that this iMAc has a 32-bit EFI
[13:24] <xu-owen82w> but CPU is 64 b
[13:30] <pmjdebruijn> oooooh
[13:30] <pmjdebruijn> so you didn't install 64bit xubuntu then
[13:30] <pmjdebruijn> or did you?
[13:30] <pmjdebruijn> what does uname -a say?
[13:33] <xu-owen82w>  I did (20.04 is only 64b)
[13:33] <xu-owen82w> Linux owen-iMac 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[13:34] <pmjdebruijn> so that's confirmed then
[13:34] <pmjdebruijn> grep MemTotal /proc/meminfo
[13:34] <pmjdebruijn> try that
[13:34] <pmjdebruijn> that's a bit less ambiguous
[13:34] <xu-owen82w> MemTotal:        3048820 kB
[13:35] <pmjdebruijn> that's a bit strange
[13:35] <xtao> shared graphics card memory stolen a GB?
[13:35] <pmjdebruijn> not sure what effect 32bit EFI could have
[13:36] <pmjdebruijn> xu-owen82w: but Intel graphics might be eating up some of your ram, though > 1GB is a bit much
[13:36] <pmjdebruijn> on regular PC's I think that can be constrained via EFI
[13:36] <xu-owen82w> possibly - although I thought it had a graphics card/memory... yeh 11gb seems high
[13:36] <xu-owen82w> is probably some apple weirdness thats limiting
[13:36] <pmjdebruijn> xu-owen82w: dmesg | grep -i drm
[13:36] <pmjdebruijn> please paste on pastebin
[13:39] <pmjdebruijn> but for an older system, I'd expect that to eat 256M of 512M of RAM
[13:40] <xu-owen82w> https://pastebin.pl/view/63c28f6d
[13:40] <pmjdebruijn> oh, so no intel graphics
[13:40] <pmjdebruijn> or at least not actively used
[13:41] <pmjdebruijn> dmesg | grep 'System RAM'
[13:44] <xtao> google suggests that some macs can take 2x2GB of memory but only see 3GB of it. intentially limited in hardware
[13:45] <xu-owen82w> https://pastebin.pl/view/f10cd05d
[13:45] <xu-owen82w> > . intentially limited in hardware
[13:45] <xu-owen82w> yeah I-m probably at a loss
[13:46] <xu-owen82w> I just came on here in case it had maybe been encountered or there was a known quick solution
[13:46] <xu-owen82w> >dmesg | grep 'System RAM'returns nothing -
[13:46] <xu-owen82w> >dmesg | grep 'System RAM'returns nothing -
[13:46] <xu-owen82w> >dmesg | grep 'System RAM'  returns nothing -
[13:46] <xtao> "while the processor in older model macbook pros is 64 bit the chipset used to address the memory is only 32 bit"
[13:47] <xu-owen82w> ah ok - chipset - so probably h/w restricted
[13:47] <xtao> only going by some articles i'm finding on google. but sounds plausible
[13:48] <xu-owen82w> OK.
[13:49] <xu-owen82w> Thanks for taking time - itś still going fine with 3G - but obv. would be nice to hae the extra 1G if there was a way
[13:50] <xtao> http://hints.macworld.com/article.php?story=2008013001563240 , 1st comment
[13:51] <xtao> was also looking at the bottom of the 3rd comment down on https://www.linuxquestions.org/questions/linux-mint-84/32-or-64bit-efi-4175644325-print/
[13:57] <xu-owen82w> (y) - Thanks
[22:43] <hansh> in the folder /home/hans i have a folder named "eclipse" and "eclipse-workspace" and ".eclipse", yet in Thunar when i press File -> find in this folder, and search for "ecl" it finds *nothing* , why?
[22:43] <hansh> also when i search for "*ecl*", still nothing
[22:44] <hansh> nvm figured it out, because "find in this folder" will search in whatever folder is selected, rather than the folder Thunar is currently in
[22:50] <brainwash> hansh: bug?
[22:50] <hansh> brainwash, possibly, i'm not sure
[22:50] <hansh> (im not sure if it's intended or a bug)
[22:51] <brainwash> do you get the same behavior when using detailed list view?
[22:51] <hansh> sorry something urgent g2g
[22:54] <brainwash> it's a custom action
[22:54] <brainwash> so, it will use the selection
[23:05] <hansh> brainwash, yes using "detailed list view" doesn't seem to make a difference
[23:06] <brainwash> right
[23:06] <brainwash> not a bug
[23:06] <brainwash> because it's a custom action, so it will use the current selection
[23:08] <hansh> ok, thanks for checking


[00:00] <kirkland> SpamapS: plus metadata
[00:00] <SpamapS> does facter know the ec2 public hostname? thats the tough one to get right now
[00:00] <kirkland> SpamapS: it's really easy
[00:00] <kirkland> SpamapS: wget -q -O- http://<IP_ADDRESS>/latest/meta-data/public-hostname
[00:00] <kirkland> SpamapS: if that fails, then use hostname -s
[00:00] <niemeyer> SpamapS: Heh
[00:01] <niemeyer> SpamapS: https happens to be a superset of http
[00:04] <kirkland> SpamapS: http://paste.ubuntu.com/626933/
[00:04] <kirkland> niemeyer: hmm, i'm not sure about that ... try https://ec2-50-17-174-12.compute-1.amazonaws.com:80
[00:05] <kirkland> niemeyer: ie, point https to a port that talks http
[00:05] <SpamapS> niemeyer: yes, I can see where you could also just add 'ssl=1' to the http interface..
[00:05] <kirkland> niemeyer: and the browser is unhappy
[00:05] <niemeyer> kirkland: Ok, my apologies for the imprecise wording...
[00:05] <niemeyer> HTTPS is merely an encryption wrapping on top of HTTP itself
[00:05] <kirkland> niemeyer: oh, sorry, i wasn't trying to be an ass;  i just thought for a second, "whoa, that's neat, I didn't know that!"  then tried it, and it didn't work :-)
[00:06] <kirkland> niemeyer: okay, cool
[00:06] <SpamapS> kirkland: sure, I'd like to abstract that into a tool that is like facter, but not as clunky as facter. :)
[00:06] <niemeyer> But either way, website is a much better term
[00:06] <kirkland> SpamapS: +1 from me
[00:06] <SpamapS> kirkland: I was reading facter, and one thing it gets really, really wrong, is that it only runs one process at a time.
[00:06] <kirkland> SpamapS: i posted something like this to ubuntu-devel@, if you can to comment there
[00:06] <niemeyer> and "http" would lead to all kinds of confusion regarding protocol vs. relation..
[00:06] <niemeyer> So I stand corrected.
[00:06] <SpamapS> kirkland: it runs 100+ external processes, but waits on each one before moving to the next.
[00:06] <kirkland> SpamapS: i got *reamed* in #ubuntu-devel today, though
[00:06] <SpamapS> kirkland: eh?
[00:06] <kirkland> niemeyer: okay, i've changed it to website
[00:07] <SpamapS> kirkland: I saw your post to the ml ..
[00:07] <kirkland> SpamapS: see today's log, between me, keybuk, cjwatson, and friends
[00:07] <kirkland> SpamapS: they have a few good points
[00:07] <kirkland> SpamapS: but still, i think we could use something, if it's named and documented appropriately
[00:13] <kirkland> bzr: ERROR: Invalid url supplied to transport: "lp:~kirkland/principia/oneiric/byobu-web/trunk": No such source package byobu-web.
[00:13] <kirkland> SpamapS: did you warn me about this yesterday?
[00:14] <SpamapS> kirkland: no, but its a known problem
[00:14] <SpamapS> kirkland: and being worked on
[00:14] <kirkland> SpamapS: okay... what's the solution?
[00:14] <SpamapS> kirkland: for now you have to use +junk, or upload a package naemd 'byobu-web' to a PPA somewhere
[00:14] <kirkland> SpamapS: hah, seriously?
[00:14] <kirkland> :-)
[00:14] <SpamapS> kirkland: re the conversation w/ Keybuk .. his point about DNS is *quite* good.
[00:14] <SpamapS> we could just simply stop passing around IP
[00:15] <SpamapS> The good thing about using DNS is it can be contextualized for the requester...
[00:15] <kirkland> SpamapS: mokay
[00:15] <SpamapS> It was glossed over, but I see the point
[00:51] <niemeyer> Dinner time!
[00:53] <_mup_> ensemble/expose-watch-exposed-flag r245 committed by<EMAIL_ADDRESS>[00:53] <_mup_> Fixed tests with respect to watch_exposed_flag using its callback on its first value, instead of yielding it
[00:54] <_mup_> ensemble/expose-watch-exposed-flag r246 committed by<EMAIL_ADDRESS>[00:54] <_mup_> PEP8
[01:00] <_mup_> ensemble/expose-watch-exposed-flag r248 committed by<EMAIL_ADDRESS>[01:00] <_mup_> Better comments
[01:01] <_mup_> ensemble/expose-provision-service-hierarchy r293 committed by<EMAIL_ADDRESS>[01:01] <_mup_> Merged upstream expose-watch-exposed-flag
[01:07] <kirkland> SpamapS: hmm, so my relation-set items are not showing up in 'ensemble status'
[01:08] <kirkland> No ENSEMBLE_AGENT_SOCKET/-s option found
[01:11] <SpamapS> relation-set shouldn't show in status unless a new change was made
[01:11] <SpamapS> that error though, means that the environment is screwed up somehow
[01:11] <SpamapS> kirkland: is your formula in a branch I can look at?
[01:12] <kirkland> SpamapS: lp:~kirkland/+junk/byobu-web
[01:13] <kirkland> SpamapS: thanks for your review and all your help
[01:15] <SpamapS> kirkland: no problem.. its fun. :)
[01:16] <kirkland> SpamapS: ;-)
[01:17] <SpamapS> kirkland: are you running that via debug-hooks ?
[01:17] <kirkland> SpamapS: um, no
[01:21] <SpamapS> kirkland: where are you seeing the error about ENSEMBLE_AGENT_SOCKET?
[01:27] <kirkland> SpamapS: oh, i just tried to run the relation-set by hand
[01:27] <SpamapS> kirkland: right, that won't ever work. :)
[01:27] <kirkland> SpamapS: heh
[01:28] <SpamapS> kirkland: I mean, you can make it work but you need to be on the machine, the socket is for talking to the local unit agent
[01:28] <SpamapS> kirkland: thats why debug-hooks is so pimp
[01:28] <kirkland> SpamapS: then that should probably be moved to /usr/lib/ensemble
[01:28] <SpamapS> kirkland: tried it yet?
[01:28] <kirkland> SpamapS: if it's not meant be run by hand
[01:29] <SpamapS> kirkland: not really, you can run it in a cron job.. :)
[01:29] <kirkland> SpamapS: no, how do i do that?
[01:29] <SpamapS> ensemble debug-hooks service/0
[01:29] <SpamapS> you MIGHT recognize the interface.. ;)
[01:29] <SpamapS> do that, then relate something to it
[01:31] <kirkland> SpamapS: nice ;-)
[01:34] <kirkland> SpamapS: hmm, okay, i'm missing something, conceptually here
[01:34] <SpamapS> kirkland: about to wrap up and go join the cloudcamp pre-camp cocktail party. :)
[01:35] <SpamapS> kirkland: whats up?
[01:38] <kirkland> SpamapS: meh, it can wait
[01:38] <kirkland> SpamapS: perhaps you can help me more tomorrow
[01:40] <SpamapS> kirkland: I've got 5 more minutes
[01:47] <SpamapS> alright.. I'm out.. good luck. :)
[03:35] <kirkland> just wondering if anyone's around for some more formula help
[03:38] <kirkland> okay, i've been beating my head against the wall for a while now and I'm just now realizing
[03:38] <kirkland> that I'm changing the formula in my local repository
[03:39] <kirkland> and then i'm trying to deploy it
[03:39] <kirkland> but the modified formula isn't getting deployed
[03:41] <_mup_> Bug #797493 was filed: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 >
[04:07] <kirkland> i'm getting a lot of these:
[04:07] <kirkland> 2011-06-15 02:50:48,534: hook.output@ERROR: debconf: unable to initialize frontend: Readline
[05:08] <kirkland> niemeyer: i'm disappointed to see byobu pruned from head :-(
[05:08] <kirkland> niemeyer: for tmux
[05:08] <kirkland> niemeyer: i see an obscure note about "race" conditions, but no other explanation
[05:17] <niemeyer> kirkland: We didn't intend to exclude byobu specifically, of course
[05:17] <niemeyer> kirkland: We replaced screen
[05:17] <niemeyer> kirkland: I did, actually
[05:18] <kirkland> niemeyer: right, bzr-blame told me :-)
[05:18] <niemeyer> kirkland: Because tmux behaves in a better way when facing concurrent executions
[05:18] <niemeyer> kirkland: If we fix that, we can bring screen back
[05:18] <kirkland> niemeyer: so I'd love to help you fix that so that ensemble can use screen/byobu for this
[05:18] <kirkland> niemeyer: by all means, I'm at your disposal
[05:18] <niemeyer> kirkland: Sounds good.. I have no special attachment to either in this case
[05:18] <kirkland> niemeyer: right-o;  I sorta do :-)
[05:19] <niemeyer> kirkland: Used screen for a long time.. have been experimenting with tmux lately.. can use either without worries
[05:19] <niemeyer> kirkland: Yeah, I know ;)
[05:19] <kirkland> niemeyer: it doesn't have to be now, but can you explain to me your concurrency problems?
[05:19] <niemeyer> kirkland: Will be happy to put your stuff to crank :)
[05:19] <niemeyer> kirkland: We just need to sort the race
[05:19] <niemeyer> kirkland: It's pretty simple to explain, actually
[05:19] <kirkland> niemeyer: and i'll gladly write a custom configuration file for ensemble-debug-hooks-byobu
[05:20] <niemeyer> kirkland: Given a session name, screen offers no way that I could perceive to avoid the same user from potentially getting two different sessions started
[05:20] <kirkland> niemeyer: as I'm using it now, I can see the things I want to know about a system when I'm logged into it through debug
[05:20] <kirkland> niemeyer: do you want 1 session, or 2?
[05:20] <niemeyer> kirkland: The first
[05:21] <kirkland> niemeyer: okay, so you want 1 session, call it "ensemble-debug" or something, right?
[05:21] <niemeyer> kirkland: For both
[05:21] <kirkland> niemeyer: okay, and you also want to attach to that one and only one session?
[05:22] <niemeyer> kirkland: Yes, just a non-racy way to create a named session
[05:22] <niemeyer> kirkland: If the same user executes the same command twice in different terminals, the command should fail or succeed, but it should never yield two different sessions
[05:23] <niemeyer> kirkland: We can't _join_ the session, though..
[05:23] <niemeyer> kirkland: Simply new-session + exec command in new session, without races
[05:24] <kirkland> niemeyer: to reproduce the problem you're experience in screen ...
[05:24] <kirkland> niemeyer: i'm going to create a screen session with "screen -S debug"
[05:25] <kirkland> niemeyer: okay, now I have a session
[05:25] <kirkland> niemeyer: called 'debug'
[05:25] <kirkland> niemeyer: and now I want to run a command in that sesion
[05:25] <niemeyer> Ok
[05:25] <niemeyer> kirkland: You want to create it if it doesn't exist, and run it in the single session
[05:26] <kirkland> niemeyer: okay, using the "at" command
[05:26] <kirkland> niemeyer: i mean, screen's at
[05:28] <niemeyer> kirkland: Executing the command isn't the problem.. the problem is creating the session in a non-racy way
[05:33] <kirkland> niemeyer: byobu -xRS %s-hook-debug -t shell
[05:33] <kirkland> niemeyer: that's what you were using before, right?
[05:33] <kirkland> niemeyer: and that's what you found to be racy?
[05:34] <niemeyer> kirkland: No, that'd join the session
[05:34] <kirkland> niemeyer: what were you using to create it?
[05:35] <kirkland> niemeyer: i'm trying to reproduce the race
[05:35] <niemeyer> kirkland: This is being run from a script.. it can't join the session
[05:35] <kirkland> niemeyer: right, so you create the session detached
[05:35] <niemeyer> kirkland: You don't have to reproduce the race.. any solution will do :-)
[05:35] <kirkland> niemeyer: some people create their byobu session in a cronjob at boot
[05:36] <kirkland> niemeyer: so that they can launch irssi and use byobu+irssi as their irc proxy
[05:36] <niemeyer> kirkland: Yeah, that should be fine.. the machine won't boot twice at the same time.
[05:36] <kirkland> niemeyer: if it does, I want to see it!
[05:36] <niemeyer> +1! :-)
[05:36] <kirkland> niemeyer: let me find my emails where I've helped someone do this
[05:37] <kirkland> niemeyer: it's a permutation of this:
[05:37] <kirkland>        -d -m   Start screen in "detached" mode. This creates a new session but doesn't attach to it. This is useful for system startup scripts.
[05:38] <kirkland> niemeyer: one more question... you want this session owned by root, or ubuntu?
[05:38] <kirkland> niemeyer: i've noticed both your tmux and byobu solutions use sudo to get to a shell
[05:38] <niemeyer> kirkland: Yeah
[05:38] <kirkland> niemeyer: i found a minor bug with the way that was being called
[05:38] <kirkland> niemeyer: which I'll fix as I work on this
[05:38] <niemeyer> kirkland: What was it?
[05:38] <kirkland> niemeyer: but I'm curious about the motivation and  design
[05:40] <niemeyer> kirkland: It's just a script on the server feeding a screen/tmux session
[05:40] <kirkland> niemeyer: right
[05:40] <kirkland> niemeyer: but putting the user in a root shell
[05:41] <kirkland> niemeyer: rather than an ubuntu shell
[05:41] <niemeyer> kirkland: The race comes from the fact that the session can be started by the server feeding a new shell, or by the user starting the debugging session
[05:41] <kirkland> niemeyer: is that by design?
[05:41] <kirkland> niemeyer: sorry, this is aside from the race :-)
[05:41] <niemeyer> kirkland: There are details, but that's the core idea
[05:41] <niemeyer> kirkland: It's root because the formula runs as root for good reasons
[05:41] <niemeyer> kirkland: So to emulate the same environment, we run the hook as root too
[05:41] <kirkland> niemeyer: okay
[05:42] <kirkland> niemeyer: fair enough;  that's the explanation i was looking for
[05:42] <niemeyer> kirkland: Cool.. we should document that there too
[05:52] <kirkland> niemeyer: so basically, we just need this in /etc/rc.local or an upstart boot script:
[05:53] <kirkland> byobu -d -m -S byobu.debug bash
[05:53] <kirkland> niemeyer: which will start a screen+byobu session, in detached mode at boot;  name it "byobu.debug", and run a single window called bash
[05:53] <niemeyer> [niemeyer@gopher ~]% screen -d -m -S byobu.debug bash
[05:53] <niemeyer> [niemeyer@gopher ~]% screen -d -m -S byobu.debug bash
[05:53] <niemeyer> [niemeyer@gopher ~]% screen -ls
[05:53] <niemeyer> There are screens on:
[05:53] <niemeyer>         20923.byobu.debug       (06/15/2011 01:53:33 AM)        (Detached)
[05:53] <niemeyer>         20792.byobu.debug       (06/15/2011 01:53:31 AM)        (Detached)
[05:53] <kirkland> niemeyer: obviously we can doctor this up a bit
[05:54] <kirkland> niemeyer: right, but you'd do that on boot, just once, no?
[05:54] <niemeyer> kirkland: This is done withing the script which starts the debugging session
[05:55] <niemeyer> kirkland: and by the user's ssh
[05:56] <kirkland> niemeyer: okay, so my first thought, what i've been working on here, is to start the screen debugging session at boot;  and then attach to it when/if the user decides to go into the debug_hook mode
[05:56] <niemeyer> kirkland: This has to be started by the script that starts the debugging session, or the user ssh shell, whatever comes up first
[05:56] <niemeyer> kirkland: This session is terminated when the user leaves the debugging sessoin
[05:57] <kirkland> niemeyer: okay
[05:57] <kirkland> niemeyer: so the trigger is when the user starts the debug session
[05:57] <niemeyer> kirkland: Yeah.. the problem is really how to start two sessions without races
[05:57] <kirkland> niemeyer: and if the user ssh's in (outside of the debug hook), do you want them in the debug session or not?
[05:57] <niemeyer> Erm..
[05:57] <niemeyer> a single session without races
[05:58] <niemeyer> kirkland: A single session with the given name should be created
[05:58] <niemeyer> kirkland: In tmux, that's "tmux new-session"
[05:59] <niemeyer> kirkland: It prevents the same session from being started multiple times
[06:05] <kirkland> niemeyer: hmm, perhaps still racy, but what about:
[06:05] <kirkland> niemeyer: byobu -r byobu.debug || byobu -S byobu.debug
[06:05] <kirkland> niemeyer: so reattach, if possible; if not, create
[06:06] <niemeyer> kirkland: Yeah the window even has a nice shape in the middle ;-)
[06:07] <kirkland> niemeyer: let me dig through the screen source code
[06:07] <niemeyer> kirkland: Ok.. it's very late here.. I'll really have to step out to bed now
[06:08] <kirkland> niemeyer: sure;  I am *going* to solve this for you ;-)
[06:08] <niemeyer> kirkland: but please let me know what you find.. we can switch back if there's an elegant way to do this in screen
[06:08] <niemeyer> kirkland: Awesome, thanks :-)
[06:08] <niemeyer> Night!
[06:08] <kirkland> niemeyer: night
[14:03]  * hazmat catches up on the night discussion
[14:10] <hazmat> if anyone has a moment to approve a trivial.. https://pastebin.canonical.com/48502/
[14:10] <hazmat> which fixes bug 797493
[14:10] <_mup_> Bug #797493: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 >
[14:11] <_mup_> Bug #797696 was filed: FAQ page needs updating <Ensemble:New for kim0> < https://launchpad.net/bugs/797696 >
[14:36]  * niemeyer waves
[14:52] <niemeyer> hmm.. compiz update.. let's hope it fixes some of the stability issues.
[14:53] <hazmat> niemeyer, indeed
[14:53] <hazmat> niemeyer, if you haz a moment to approve a trivial.. https://pastebin.canonical.com/48502/
[14:53] <niemeyer> hazmat: Hey man
[14:53] <niemeyer> Looking
[14:54] <hazmat> its a fix for the upgrade reporting output in bug 797493
[14:54] <_mup_> Bug #797493: unresolved revision %r in upgrade-formula error message <Ensemble:New> < https://launchpad.net/bugs/797493 >
[14:54] <niemeyer> hazmat: +1!
[14:54] <hazmat> niemeyer, just looking over the google lang performance.. i hadn't realized how much slower golang was
[14:54] <niemeyer> hazmat: How much slower than what?
[14:54] <hazmat> niemeyer, https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf
[14:55] <hazmat> java, c++, scala are the comparisons
[14:58] <niemeyer> hazmat: Ah, yeah, I've seen that paper
[14:58] <niemeyer> hazmat: Go is slower than hugely optimized C++, no questions about that :-)
[14:59] <hazmat> what was surprising was how well the naive scala did
[15:00] <niemeyer> hazmat: Also note that there's really no "Go Pro" in the paper
[15:01] <hazmat> niemeyer, right their just doing optimizations a go 'pro' developer would do
[15:01] <niemeyer> hazmat: The person doing the optimization reportedly didn't spend much time on it
[15:01] <hazmat> ah
[15:01] <niemeyer> hazmat: and was surprised when the paper was published
[15:01] <hazmat> niemeyer, i thought they solicited robP for feedback on the pro stuff
[15:02] <niemeyer> hazmat: No, it was Ian Tailor, the guy from gccgo
[15:03] <niemeyer> Taylor even
[15:03] <niemeyer> hazmat: http://j.mp/lwuiAv
[15:04] <m_3> will the bootstrap instance be unhappy if: A) I restart zookeeper on a node during install, and B) zookeeper comes back up on that node with a sun-java6-jdk instead of openjdk?
[15:04] <m_3> (trying to install sun java as part of a formula)
[15:05] <niemeyer> m_3: We haven't exercised much that kind of scenario yet
[15:05] <m_3> I'd rather do a update-alternatives which would probably effect zookeeper
[15:05] <niemeyer> m_3: Restarting ZooKeeper is supposed to work fine, and it's not hard even
[15:05] <m_3> I'll experiment...
[15:05] <niemeyer> m_3: We know about a few issues that may complicate it right now
[15:06] <niemeyer> Specifically, we get a spurious event about the session that we're not handling properly yet
[15:06] <niemeyer> m_3: The event has to be ignored..
[15:07] <kim0> hey guys, is the multiple formulas per machine feature landing soonish ? Also is this the same as, machine policy formulas or whatever its called
[15:07] <m_3> niemeyer: is there a way to mute events from that node before I do a zk restart?
[15:08] <niemeyer> m_3: mute?
[15:08] <niemeyer> m_3: What kind of event?
[15:08] <m_3> sorry, don't know the txzk infterface...
[15:09] <niemeyer> m_3: No worries.. just trying to figure what do you really mean
[15:09] <m_3> is there a way to warn the bootstrap instance before bouncing zk on a node
[15:09] <niemeyer> kim0: We're not working on it right now, so it won't land _soon_, but we don't want to take too long either
[15:10] <niemeyer> m_3: I still don't get what you mean.. it sounds a bit reversed..
[15:10] <m_3> ...so it can ignore the bad session events you mentioned
[15:10] <niemeyer> m_3: zk is _inside_ the bootstrap node
[15:12] <m_3> niemeyer: if I bounce the zk instance running on the new node you said the bootstrap instance gets spurious session events that it doesn't like
[15:13] <m_3> niemeyer: so is there a way for the new node to warn the bootstrap instance about the pending bounce of zk on the new node
[15:14] <niemeyer> m_3: Right now there's only a single zk instance, and it is inside the bootstrap node
[15:14] <m_3> niemeyer: oh wow...
[15:15] <m_3> niemeyer: I see zk instance running on new node... let me make sure I'm on the right instance
[15:16] <m_3> niemeyer: yeah, running on both
[15:18] <niemeyer> m_3: That's likely an artifact of installing the package on the second instance
[15:18] <niemeyer> m_3: Can you please investigate how zookeeper is being started on the second instance?
[15:18] <niemeyer> m_3: It's certainly not being used
[15:20] <m_3> niemeyer: ok, will do... thanks
[15:20] <hazmat> niemeyer, its because its part of the install image
[15:21] <hazmat> niemeyer, we should probably just go ahead and install java, but not zookeeper, and let cloud-init install zk
[15:21] <hazmat> that will remove the extraneous zk
[15:21] <hazmat> on the service machines
[15:21] <niemeyer> hazmat: You mean it's indeed an artifact of installing the package?
[15:21] <hazmat> niemeyer, yes
[15:21] <niemeyer> hazmat: Ok, hmm
[15:22] <hazmat> niemeyer, we don't need it on the service machines, just the python zk extension and libzk
[15:22] <niemeyer> hazmat: Your suggestion feels good
[15:22] <niemeyer> hazmat: I was going to suggest we disable starting the service, but indeed there's no reason for the package to even exist there
[15:22] <hazmat> niemeyer, has upstart grown a nice way to do that?
[15:23] <hazmat> my understanding was you need to do some sort of override file that explicitly depended on a nonexistant event
[15:23] <niemeyer> hazmat: Not sure.. I recall hearing that it would.  Either way, several services check /etc/default/* for info on whether to start or not
[15:23] <hazmat> hmm.. true
[15:25] <m_3> niemeyer, hazmat:  thanks y'all
[15:25] <hazmat> it looks like the other way (via upstart in natty) is echo manual >> /etc/init/zookeeper.override
[15:27] <hazmat> niemeyer, i think ben's is blocked on bleeding test failures in one of the service lifecycle integration branches..
[15:27] <hazmat> i had a quick look on monday.. but its going to take some more time to dig into.
[15:28] <_mup_> ensemble/trunk r254 committed by<EMAIL_ADDRESS>[15:28] <_mup_> [trivial] fix formatting for upgrade error [r=niemeyer][f=797493]
[15:28] <niemeyer> hazmat: Ok.. it'd be good to have more of that conversation happening in the open
[15:29] <niemeyer> hazmat: So that we can get a feeling of what to do about it.. I'd really like to make our tests rock solid in this milestone
[15:29] <niemeyer> hazmat: and not rely on any kind of timing
[15:30] <hazmat> niemeyer, this isn't a timing issue, the its some sort of bleeding issue.. the tests run fine looped in isolation, but full test runs are busted
[15:30] <hazmat> i suspect its the reset_logging/save_logging stuff.. because its overly ambitious in the reset, which cascades to others
[15:30] <hazmat> which depend on the default
[15:31] <niemeyer> hazmat: Have you seen Jim's branch?
[15:31] <hazmat> at least that was the case last time around
[15:31] <hazmat> niemeyer, yeah.. i've discussed it with him, there are more timing issues there.. but i think the problem is having async cb chained call stacks without an explicit control point
[15:31] <hazmat> ie. more of a design issue there
[15:32] <hazmat> i've also expressed i'd prefer to see that encapsulated better so that refactoring it to the machine agent is a bit easier
[15:32] <niemeyer> hazmat: One of the things there is that it kills reset and save_logging entirely
[15:32] <hazmat> niemeyer, ah that branch
[15:32] <hazmat> i haven't looked at it.. that might certainly help
[15:38] <_mup_> ensemble/bootstrap-shutdown-environment r250 committed by<EMAIL_ADDRESS>[15:38] <_mup_> note the shutdown prompt in the user guide
[15:41] <_mup_> ensemble/trunk r255 committed by<EMAIL_ADDRESS>[15:41] <_mup_> merge bootstrap-shutdown-environment [r=bcsaller,niemeyer][f=756685]
[15:41] <_mup_> Ensemble bootstrap and shutdown subcommands now operate on a single
[15:41] <_mup_> environment. The shutdown command also requires a user confirmation
[15:41] <_mup_> before destroying the environment.
[15:47] <kim0> The instructions to run from ppa https://ensemble.ubuntu.com/docs/getting-started.html#running-from-ppa
[15:47] <kim0> are missing a apt-get update, does this require filing a bug/branch, or is there a simpler way
[15:48] <hazmat> kim0, ugh.. mea culpa.. a trivial for that sounds good
[15:48] <kim0> hazmat: what's the workflow for a trivial fix
[15:50] <hazmat> kim0, change the files, paste a diff, ask for an +1 on the trivial
[15:51] <hazmat> kim0, after receiving such, commit the diff to trunk with a [trivial] tag in the commit msg
[15:51] <hazmat> at least that's the workflow i've been following for such
[15:52] <kim0> hazmat: http://paste.ubuntu.com/627384/
[15:52] <hazmat> kim0, looks good, +1
[15:52] <hazmat> ;-)
[15:54] <niemeyer> hazmat: +1 on the workflow.. sometimes I cowboy extremely obvious things, but I've also found useful comments from others on things I initially found obvious
[15:57] <kim0> merged
[16:00] <kim0> I'd like to contact Iain Farrel from design team, to ask for an Ensemble mascot. Now is probably a good time for one :) any +1/-1s
[16:01] <hazmat> kim0, sounds great
[16:34] <jimbaker> hazmat, is there still a timing issue in the standardize-log-testing branch?
[16:35] <hazmat> jimbaker, checking.. un momento
[16:36] <kirkland> hey guys -- any feedback on my bash-completion branch?  :-)
[16:37] <jimbaker> hazmat, it should be fixing a problem with HookContext that's causing this "bleeding"
[16:37] <jimbaker> i believe the save_logging/reset_logging simply were masking this issue
[16:39] <jimbaker> kirkland, i like the idea of completion. but i did wonder, what sort of testing is typically done around stuff like this?
[16:40] <kirkland> jimbaker: ensemble<space><tab><tab>
[16:40] <kirkland> jimbaker: the framework is there for each subcommand to have completion too
[16:40] <kirkland> jimbaker: i tried grepping "ensemble status" for that, but it's too slow
[16:41] <kirkland> jimbaker: i think i'd need to cache that output
[16:41] <kirkland> jimbaker: from a user experience perspective
[16:41] <niemeyer> kirkland: Sorry, it wasn't in my radar.. we generally use this view for reviews:
[16:41] <niemeyer> kirkland: https://ensemble.ubuntu.com/kanban/dublin.html
[16:41] <jimbaker> kirkland, yeah, that makes sense re ensemble status being too slow
[16:42] <niemeyer> kirkland: But it only gets there if there's a bug linked, in progress, and attached to the milestone
[16:42] <niemeyer> kirkland: I'll check it out today
[16:42] <niemeyer> kirkland: I think completion on status wouldn't be ideal indeed
[16:43] <niemeyer> kirkland: I'd rather not complete than wait
[16:44] <hazmat> kirkland, are you saying that grepping ensemble status -h is too slow for completion?
[16:44] <hazmat> it shouldn't be doing any work before it has parsed the cli
[16:45] <kirkland> niemeyer: right, i just tried it lightly, and it was really bad performance
[16:45] <jimbaker> my assumption was that kirkland was actually getting names from ensemble status...
[16:45] <kirkland> niemeyer: but getting the initial actions is really fast
[16:45] <kirkland> niemeyer: and it keeps me from having to go back to ensemble --help all the time to find the right commands
[16:46] <kirkland> jimbaker: no, not doing that
[16:46] <jimbaker> kirkland, ok
[16:47] <kirkland> hazmat: no, not -h
[16:49] <hazmat> kirkland, we could probably give a an additional option to status to make if faster for completion
[16:49] <hazmat> its pulling in almost the whole subgraph atm, but really we just need one node
[16:50] <hazmat> i take that back.. the connection setup would still dominate, we do need a local cache for completion
[16:51] <_mup_> ensemble/bash-completion r257 committed by<EMAIL_ADDRESS>[16:51] <_mup_> bash_completion support with some argument support
[16:52] <hazmat> assuming that is we were completing actual variable/value names
[16:53] <kirkland> hazmat: yeah, i was thinking something like that;  caching status to disk;  backgrounding an update of the cache when it's deemed expired
[16:53] <kirkland> hazmat: anyway, it's not urgent, but would make for a damn cool interface :-)
[16:55] <jimbaker> kirkland, your background process could simply listen to topology changes like any other zk client can
[16:55] <jimbaker> in terms of watching a given node
[16:56] <kirkland> jimbaker: cool;
[16:56] <jimbaker> probably better to do that way than using ensemble status (except for spiking)
[16:57] <kirkland> jimbaker: hazmat: niemeyer: in any case, we now have the framework for the bash-completion piece;  if and when we can get ensemble status instantly (or at least comb a cache of ensemble status), I'll extend the bash-completion for subcommands to leverage the status info
[16:57] <niemeyer> kirkland: Sounds good
[16:58] <niemeyer> kirkland: Completion helps for sure
[16:58] <hazmat> kirkland, we don't have any client side daemon ... its not clear to me what would do the background update, perhaps just invoking the cli again in the background with a cache option.. although having a daemon might be nice with the ssh tunnel reuse
[16:58] <kirkland> hazmat: a daemon would be one approach
[16:59] <kirkland> hazmat: another would be in the bash-completion command itself
[16:59] <kirkland> hazmat: in there, i'd test the age of the cache
[16:59] <hazmat> kirkland, indeed.. yeah. we'd need to show stale data in that case afaics
[16:59] <kirkland> hazmat: if it's not expired, then i'd use it;  and background an update
[16:59] <hazmat> or get random waits
[16:59] <kirkland> hazmat: if it is expired; i'd probably just return "null" immediately (ie, no complete) and background an update
[17:00] <kirkland> hazmat: where an update is something like 'ensemble status > $HOME/.cache/ensemble-status &'
[17:00] <SpamapS> FYI, I just updated the builder recipes for ensemble to make the bzr revno part of the upstream version.
[17:02] <SpamapS> hazmat: a local daemon that does the ssh tunnel and listens to zookeeper updates for all status info would be doable, would it not?
[17:02] <SpamapS> hazmat: we could even leverage dbus and have it spun up when needed.
[17:03] <niemeyer> Lunch time!
[17:05] <kirkland> SpamapS: do you mind trying out bzr+ssh://bazaar.launchpad.net/~kirkland/%2Bjunk/byobu-web/ ?
[17:06] <jimbaker> wouldn't such a status daemon also be useful for an indicator?
[17:06] <SpamapS> kirkland: bootstrapping.. :)
[17:07] <SpamapS> kirkland: yesterday you were saying you felt like you were missing a concept.. did you figure it out?
[17:07] <kirkland> SpamapS: sort of
[17:08] <kirkland> SpamapS: i think it was around bumping the formula revision number
[17:08] <kirkland> SpamapS: and pushing an upgrade
[17:08] <kirkland> SpamapS: i spent 4 hours making changes locally
[17:08] <kirkland> SpamapS: but not seeing those in my deployments
[17:08] <kirkland> (okay, 4 is an exaggeration :-)
[17:09] <SpamapS> DOH I hate that
[17:09] <SpamapS> I still am pretty convinced that users will despise the revno too and just wonder why we don't use a hash of the zip file or something.
[17:10] <kirkland> SpamapS: i feel like if my --repository=./ then obviously i want it upgraded every time
[17:10] <kirkland> SpamapS: agreed;  if we have to use a revno, i want it bumped automatically for me
[17:10] <kirkland> SpamapS: i don't want to think about tht
[17:10] <SpamapS> kirkland: I spent like, 30 seconds trying to write a script to do that automatically, but got annoyed with the yaml libraries available. ;)
[17:14] <kirkland> SpamapS: how good or bad is it/
[17:15] <hazmat> maybe a --force on upgrade, to bypass the version checking
[17:16] <kirkland> hazmat: sure, i'd use that (probably all the time :-)
[17:18] <hazmat> looks pretty straightforward to implement
[17:20] <kirkland> SpamapS: the only tricky part is that you have to set a password for ubuntu for the formula to be useful
[17:20] <kirkland> SpamapS: so i'm keen on finding a way of doing that, before blogging about it :-)
[17:24] <hazmat> SpamapS, we could use a md5 checksum for verifying instead of numbers, but we're playing pretty fast an loose with version numbers at that point
[17:32] <SpamapS> kirkland: right thats where config settings come.
[17:33] <SpamapS> hazmat: we've talked about this before.. --force is a nice band-aid. Users will *still* hate the revno. ;)
[17:33] <kirkland> SpamapS: right, unimplemented at this point, no?
[17:33] <SpamapS> principle of least surprise: I changed my formula, it should deploy anew.
[17:35] <SpamapS> At least warn me that you didn't deploy the same content as whats on disk locally.
[17:42] <SpamapS> kirkland: --force is unimplemented, as is the config settings (not sure which you were asking about)
[17:42] <kirkland> SpamapS: config
[17:42] <kirkland> SpamapS: i'm looking for the best work around for setting an ubuntu password
[17:42] <kirkland> SpamapS: to a configurable value
[17:42] <kirkland> SpamapS: or randomly generating it
[17:43] <kirkland> SpamapS: and getting that back to the user
[17:43] <kirkland> SpamapS: perhaps as a relation?
[17:43] <SpamapS> kirkland: randomly generate it, and log it with ensemble-log INFO level
[17:44] <SpamapS> ensemble-log --log-level INFO password=f94k1X
[17:44] <SpamapS> kirkland: I suggest pwgen for the generation btw.
[18:31] <SpamapS> kirkland: ajaxterm runs its own HTTP daemon right?
[18:31] <kirkland> SpamapS: yeah, on 8022
[18:32] <kirkland> SpamapS: which doesn't need to be opened to the world
[18:32] <kirkland> SpamapS: just to itself
[18:32] <SpamapS> kirkland: wondering if you could do some kind of SSO thing
[18:33] <kirkland> SpamapS: hmm
[18:33] <kirkland> SpamapS: openid-ish you mean?
[18:33] <kirkland> SpamapS: that would be so sexy ....
[18:34] <SpamapS> Wordpress has an openid provider plugin.. >:)
[18:46] <SpamapS> kirkland: I was going to suggest Launchpad.. but how do you know which groups to accept? ;)
[18:47] <Daviey> anyone who has signed the CoC is good cookie :)
[18:48] <kirkland> SpamapS: i figured you'd just add your LP id as part of the config
[18:48] <kirkland> SpamapS: which could be a group, maybe
[18:49] <SpamapS> Daviey: hm that reminds me I should add that as a requirement for contributing to principia.
[18:59] <Daviey> oh aye
[19:03] <kim0> I'm collecting a list of weekly happenings in the Ensemble space, preparing for a blog post
[19:03] <kim0> so far, I've collcted these http://paste.ubuntu.com/627516/
[19:04] <kim0> feel free to add any comments on any points, and add new points (perhaps recent development) that I'm not aware of
[19:06] <SpamapS> kim0: In addition to point 1, principia-tools has a script, 'promulgate', that assigns a branch as the official branch for a formula.
[19:07] <kim0> SpamapS: so a branch like lp:~kim0/+junk/drupal could now be marked as official branch for lp:principia/drupal right ?
[19:08] <kim0> cool
[19:10] <kim0> niemeyer: hazmat if anyone has any development related points I should add .. let me know .. thanks
[19:10] <niemeyer> kim0: The debug-hooks fixes have landed
[19:11] <kim0> got it
[19:11] <niemeyer> kim0: Btw, "source package branches" is an internal implementation detail rather than something that would make sense to advertise as such
[19:11] <niemeyer> kim0: I.e. principia has formulas, not source packages
[19:12] <kim0> yeah, this part I found confusing to understand
[19:12] <kim0> so I'll just say that formulas can now be referenced like lp:principia/mediawiki
[19:12] <niemeyer> kim0: It's an internal Launchpad detail.. we're reusing existing infrastructure because it's similar to what we need
[19:13] <niemeyer> kim0: The key point there is that principia is moving forward, and we not have means for tagging officially recommended branches
[19:13] <niemeyer> kim0: s/and we not/and we now/
[19:13] <kim0> awesome, I'll note that as well
[19:13] <kim0> daker: o/
[19:14] <daker> kim0: sorry i need to leave the office :/
[19:14] <kim0> daker: oh still at the office .. okie ..catch you at home :)
[19:14] <daker> :)
[19:18] <SpamapS> kim0: hopefully nobody will link +junk branches though. :)
[19:18] <kim0> haha :D
[19:19] <kim0> yeah bad example
[19:22] <niemeyer> +1 :-)
[19:24] <koolhead17> hi all
[19:24] <koolhead17> hello kim0 niemeyer
[19:24] <niemeyer> Hey koolhead17
[19:24] <kim0> koolhead17: hey hey
[19:24] <koolhead17> Daviey: hazmat and all :)
[19:25] <kim0> koolhead17: how's the ec2 playing going
[19:25] <koolhead17> kim0: having fun time :)
[19:25] <koolhead17> thanks 2 you :)
[19:25] <kim0> awesome
[19:25] <koolhead17> i make sure to run ensemble shutdown :D
[19:25] <kim0> hehe :)
[19:25] <koolhead17> niemeyer: kim0 i have a question
[19:26] <kim0> shoot
[19:26] <koolhead17> the package which is not available via apt-get
[19:26] <koolhead17> can i write formula for that?
[19:27] <kim0> SpamapS: would kick you though :)
[19:27] <hazmat> koolhead17, yes.. you can download and install from anywhere you want in the 'install' hook, however
[19:27] <kim0> I think the discussion for that is ongoing
[19:27]  * koolhead17 looks at SpamapS :)
[19:27] <koolhead17> hazmat: yeah that`s what i wanted the permission for :P
[19:27] <hazmat> such formulas probably won't be accepted for an official release of principia.. but they can be installed easily from the command line with a different namespace prefix
[19:27] <kim0> my understanding is, ofc you can, but it won't be a blessed formula
[19:28] <koolhead17> kim0:  blessed formula :D
[19:28] <hazmat> ie ensemble deploy koolhead17:wordpress
[19:28] <koolhead17> hazmat: yes i saw and checked that via EC2
[19:28] <jimbaker> bcsaller, hazmat - were you able to see if standardize-log-testing branch was helpful for looping problems?
[19:29] <bcsaller> jimbaker: I haven't merged it, you found an issue with the hook context?
[19:29] <jimbaker> bcsaller, yes, it was using processExited instead of processEnded
[19:30] <jimbaker> i think the save_logging etc stuff was masking this
[19:32] <jimbaker> bcsaller, so it may be helpful for your work, based on what hazmat was saying earlier today
[19:32] <bcsaller> I'll take a look, thanks
[19:39] <niemeyer> kim0: That's right.. it's fine to do it, it just won't be part of the core formulas
[19:41] <kim0> although if the only concern is getting security updates, I'm not sure why we can't just request the formula author to add a suitable update mechanism
[19:42] <kim0> like for drupal/drush "drush upc" would update drupal-core and all modules .. many modules are not even packaged
[19:43] <SpamapS> hazmat: should we keep pushing txaws trunk into the ensemble PPA, or backport the oneiric version?
[19:44] <hazmat> SpamapS, hmmm.. i think we're okay with trunk for the foreseeable future ... if we do make a fix to txaws, we want the ppa to capture that
[19:44] <hazmat> and most of what's happened there is just bug fixing
[19:44] <SpamapS> hazmat: at some point we need to make a stable PPA
[19:45] <SpamapS> hazmat: once we get past beta1 of oneiric maybe..
[19:45] <hazmat> SpamapS, definitely
[19:45] <SpamapS> hazmat: So that people can get teh 11.10 version of ensemble on natty/maverick/lucid
[19:50] <niemeyer> kim0: In that case, it won't be an official formula.. we can't enforce how the user will handle security updates
[19:50] <niemeyer> kim0: We can only offer the mechanisms
[19:51] <kim0> but we're already enforcing, we're saying if you dont use apt-get you wont be accepted in official
[19:51] <SpamapS> kim0: practically, drush upc is meant to do the same thing. But we don't want to take responsibility for that.
[19:52] <kim0> the formula author takes responsibility
[19:52] <SpamapS> Hence it not being "official"
[19:52] <kim0> We should only verify that the update mechannism works
[19:52] <SpamapS> Official means "we take responsibility for it working a certain way"
[19:53] <SpamapS> We don't know their security update process, we don't know how long they'll support a version.. also what if they break compatiblity with other software in a version that also fixes security? We don't do that.
[19:53] <SpamapS> kim0: It will be available, but like the thread was saying, it won't be quite as automatic to get it.
[19:54] <kim0> would users be able to query non official repos for all drupal formulas ?
[19:55] <kim0> perhaps we should allow user-rating and commenting, a la android market
[19:56] <kim0> if user formulas (non official) are not searchable/discoverable .. that pretty much kills them though
[20:03] <SpamapS> No they'll show up in searches.. with a namespace that identifies them clearly as "not official"
[20:04] <SpamapS> I like the idea of "contrib" .. "These are useful formulas but not part of Ubuntu"
[20:05] <SpamapS> kim0: I actually think these formulas are the killer app of ensemble.. and making the distinction isn't going to kill them or harm them in any way. It just signals to users what risk is involved.
[20:11] <niemeyer> kim0: We're not enforcing, in the same way we don't enforce what people put in PPAs
[20:11] <SpamapS> True, we're still speculating on what we want 'official' to mean.
[20:11] <niemeyer> kim0: There's a significant difference between "you can't create a package" and "your package is not part of main"
[20:12] <niemeyer> kim0: Most people don't care that their packages are not part of main
[20:12] <kim0> SpamapS: cool, as long as they show up in searches .. that's lovely :)
[20:12] <kim0> yeah
[20:50] <daker> back
[20:50] <daker> niemeyer: license question
[20:50] <niemeyer> daker: Sure
[20:51] <daker> my formula is based on the wp one, what should i do ?
[20:53] <SpamapS> daker: merge the latest copyright file from the wordpress formula, and then add your own copyright to it where appropriate.
[20:54] <SpamapS> daker: http://bazaar.launchpad.net/~ensemble-composers/principia/oneiric/wordpress/trunk/view/head:/copyright
[20:55] <daker> SpamapS: can you give an example on how my copyright should be ?
[20:55] <SpamapS> daker: on the next line after Copyright: Copyright 2011, Canonical Ltd., All Rights Reserved.
[20:55] <SpamapS> actually
[20:55] <SpamapS> no, add a Files: section..
[20:55] <SpamapS> Files: hooks/db-relation-changed
[20:56] <SpamapS> Copyright: 2011, Canonical Ltd., All Rights Reserved
[20:56] <SpamapS>   2011, YOUR NAME<EMAIL_ADDRESS>[20:56] <SpamapS> License: GPL-3
[20:56] <SpamapS> That should do it
[20:56] <daker> ok
[20:57] <daker> SpamapS: thanks
[20:57] <SpamapS> daker: if you totally rewrote hooks/install , you can list it there too
[21:05] <daker> SpamapS: is it good http://paste.ubuntu.com/627597/ ?
[21:07] <SpamapS> daker: you do not need to create a Files section for anything you did not change. Just let the 'File: *' handle that
[21:08] <SpamapS> daker: each Files: section needs a License: portion, but does not have to repeat the text.
[21:09] <daker> headache :/
[21:19] <daker> SpamapS: good http://paste.ubuntu.com/627606/ ?
[21:21] <SpamapS> daker: as I said, you don't have to repeat the text, just the License: GPL-3 part
[21:22] <SpamapS> daker: the format specification is the first link in that file, it might be helpful
[21:24] <SpamapS> daker: http://paste.ubuntu.com/627613/
[21:24] <SpamapS> daker: much simpler, see?
[21:24] <daker> ah ok
[21:24] <SpamapS> err, I repeated hooks/install oops ;)
[21:27] <daker> SpamapS: one last time http://paste.ubuntu.com/627614/
[21:29] <SpamapS> daker: you are missing the original Files: * section
[21:29] <SpamapS> daker: which you shouldn't be altering
[21:31] <daker> SpamapS: it will be copyrighted to ? canonical ?
[21:31] <daker> or me ?
[21:33] <SpamapS> daker: You have copyrights on anything you changed by more than a few lines.
[21:33] <SpamapS> daker: so metadata.yaml you also probably deserve copyright on.
[21:34] <SpamapS> daker: honestly you can just dump the wordpress copyright file in there, without your copyrights.. I'm more concerned with the license than the copyrights.
[21:35] <daker> SpamapS: just one more time pls http://paste.ubuntu.com/627620/
[21:39] <jimbaker> hazmat, i don't think this got through: i've been experimenting with client.connected for watch_expose_flag. this is of course the common pattern for watches
[21:41] <jimbaker> hazmat, i was trying to determine why my provisioning agent tests would fail after approximately 200 iterations or so. i was under the impression that a single poke i was doing at teardown ensured watches would always run
[21:42] <hazmat> jimbaker, a poke is just a roundtrip communication, the watch would have to have already fired for a poke to be sync point
[21:43] <jimbaker> hazmat, right. so i think there's a very small chance that a new watch is getting setup in the  background by another watch as tests terminate
[21:44] <jimbaker> hazmat, having the watch cb depend on some app state definitely is working, as you suggested
[21:45] <jimbaker> hazmat, but maybe i can try one more tack here - have the test on app state before each watch setup too
[21:47] <_mup_> ensemble/expose-provision-service-hierarchy r294 committed by<EMAIL_ADDRESS>[21:47] <_mup_> Removed unused code, comments
[21:57] <jimbaker> hazmat, no, that doesn't work
[21:58]  * niemeyer breaks
[21:59] <jimbaker> hazmat, maybe what's going on here is the following: test teardown occurs; as part of that, the zk tree is deleted; but this triggers a watch on exposed flag (because it has been exposed, and in a separate node than the topology)
[21:59] <hazmat> jimbaker, the tests are supposed to close the client, and open  a new client to tear down the tree
[21:59] <jimbaker> then the watch runs, but the client is already disconnected
[22:00] <hazmat> closing the first client, shutsdown extant watches
[22:00] <jimbaker> hazmat, ok, that theory doesn't work then :)
[22:00] <hazmat> jimbaker, you might want to verify your tests are inheriting from the state test base which has this behavior
[22:01] <jimbaker> hazmat, yes it is: class AgentTestBase(StateTestBase) ...
[22:02] <jimbaker> hazmat, so i wonder if this argues for reinstating the test on client.connected in the watch... putting it there, i looped > 1000 times, at which point i control-c
[22:04] <jimbaker> i'm controlling the callback on the agent (a new boolean agent._running), but the watch itself doesn't have access before it does exists_and_watch
[22:04] <hazmat> jimbaker, that
[22:04] <hazmat> er.. that's fine by me
[22:05] <jimbaker> hazmat, yes, i know. i think i have spent easily a number of days looking at this question raised by niemeyer  on two lines of code
[22:06] <jimbaker> so that's all good, i think we have a good answer for why it's necessary, and the best pattern to write code
[22:07] <jimbaker> hazmat, 1) have the watch be guarded by client.connected upon entry, as is our common practice; 2) have the callback be guarded on something at the app level
[22:09] <jimbaker> hazmat, anyway, i'm going to push up that change to expose-watch-exposed-flag
[22:12] <_mup_> ensemble/expose-watch-exposed-flag r249 committed by<EMAIL_ADDRESS>[22:12] <_mup_> Guard entry into the watch with client.connected for watch_exposed_flag (again)
[22:13] <hazmat> SpamapS, kirkland i took a look at the force upgrade.. it looked pretty easy initially but it ends up violating some assumptions we have that a formula id (namespace:name-revision) is unique in the deployment
[22:14] <hazmat> jimbaker, the standardize-log-testing didn't resolve the issues on bcsaller's branch.. but it looks good to me
[22:15] <jimbaker> hazmat, cool about my branch, just too bad it wasn't as powerful as i had hoped :)
[22:15] <_mup_> ensemble/expose-provision-service-hierarchy r295 committed by<EMAIL_ADDRESS>[22:15] <_mup_> Merged upstream expose-watch-exposed-flag
[22:17] <jimbaker> hazmat, feel free to grab a review of standardize-log-testing if that works for you - want to get it into trunk and need that 2nd review
[22:27] <hazmat> jimbaker, sounds good
[22:27] <SpamapS> hazmat: so maybe it would be even easier to just use the hash? ;-)
[22:28] <hazmat> SpamapS, indeed, it might at that
[22:35] <SpamapS> hazmat: anyway, thanks for looking into it
[22:36] <daker> SpamapS: can you give me your opinion http://paste.ubuntu.com/627620/ pls ?
[22:36] <SpamapS> daker: re your last one.. read it logically (not just based on what I've asked you to do). You have removed Canonical's copyrights and added your own. Thats not appropriate.
[22:37] <SpamapS> daker: the point of the file is to document what the license and copyright status of each file is. The 'Files: *' means *all files not otherwise specified*
[22:38] <daker> i am really confused :/
[22:38] <SpamapS> You should ask a question then, I am happy to answer.
[22:41] <daker> you said that i have rights on anything i have changed, and i didn't remove Canonical's copyrights
[22:42] <SpamapS> Files: *
[22:42] <SpamapS> Copyright: 2011, Adnane Belmadiaf<EMAIL_ADDRESS>[22:42] <SpamapS> License: GPL-3
[22:42] <SpamapS> No mention of Canonical there
[22:42] <SpamapS> but canonical retains all of its copyrights.
[22:42] <SpamapS> Unless you completely replaced most of the file.
[22:43] <SpamapS> At which point you would have an explicit entry that just lists you.
[22:46] <daker> SpamapS: so the Files: * section is copyrighted to canonical ?
[22:48] <_mup_> ensemble/expose-provision-service-hierarchy r296 committed by<EMAIL_ADDRESS>[22:48] <_mup_> Doc string
[22:50] <SpamapS> daker: yes, then you add a "Files" section for each file that has something other than that for its Copyright/License.
[23:26] <hazmat> jimbaker, one comment on the log stuff merge, the sleep looks a little out of place, else its pretty nice (and mp approved)
[23:32] <Daviey> Can i confirm that there is no intetion to get ensemble in main for release?
[23:37] <SpamapS> Daviey: not for 11.10, but I do intend to MIR some of its dependencies.
[23:39] <_mup_> ensemble/standardize-log-testing r259 committed by<EMAIL_ADDRESS>[23:39] <_mup_> Removed spurious sleep (shouldn't have been part of push)
[23:39] <Daviey> SpamapS: Do you have a list of those?
[23:40] <Daviey> What is the reasoning for MIR'ing them, if ensemble will remain in universe for this release?
[23:42] <SpamapS> Daviey: to spread out the load on the MIR team and give us time to get ensemble ready.
[23:42] <SpamapS> Daviey: essentially, we know we want ensemble in main for 12.04 .. but we also know it probably won't be ready.
[23:43] <_mup_> ensemble/standardize-log-testing r260 committed by<EMAIL_ADDRESS>[23:43] <_mup_> Merged trunk
[23:47] <Daviey> SpamapS: Agreed.  'Spreading the burden' doesn't make much sense IMO.  We already have to raise enough MIR's for our other commitments, which hasn't been compariable since karmic.
[23:47] <jimbaker> hazmat, i fixed up that sleep per the commit message, sorry about that!
[23:48] <jimbaker> i generally try to mark such debug statements with an XXX so they don't sneak in... but forgot this time
[23:51] <SpamapS> Daviey: Hrm, I figure raise it now because we know we'll need it then.
[23:51] <hazmat> jimbaker, sounds good
[23:57] <jimbaker> seeing trunk fail again: http://paste.ubuntu.com/627672/ (just running ./test ensemble.control)
[23:58] <niemeyer> jimbaker: Are you sure that's up to date?
[23:58] <niemeyer> jimbaker: Ah
[23:59] <niemeyer> jimbaker: find -name '*.pyc' -exec rm {} \;


[09:22] <Kilos> helloooo africa
[09:22] <Kilos> bad internet so will be in and out
[09:22] <Kilos> you all keep well
[09:23] <Kilos> hi takinbo welcome to ubuntu-africa


[01:52] <jo-erlend> LocutusOfBorg, hey, that's great! Thank you very much!:)
[09:12] <gdalusr> there seems to be a QGIS or QT packaging bug in ubuntu (atleast 18.04), when installing it in docker it crashes because it can't find libssl1.0
[09:13] <gdalusr> I assume it's masked as an issue, because on a normal desktop libssl1.0 get's installed by something else
[09:28] <gdalusr> https://stackoverflow.com/questions/42094214/why-is-qsslsocket-working-with-qt-5-3-but-not-qt-5-7-on-debian-stretch might be related
[13:51] <bluca> when a package has multiple autopkgtest tests/suites, does the CI have any facilities for running them in parallel?
[13:52] <bluca> (looking at more ways to speed up the systemd-ci autopkgtest runs)
[13:52] <ddstreet> no, but for the ubuntu ci infrastructure it wouldn't make sense to, since by default test instances are m1.small (1 cpu)
[13:53] <ddstreet> (which i've tried to increase for systemd/systemd-upstream...unsuccessfully, so far)
[13:56] <gdalusr> I wonder if it's possible to test if packages work in side docker containers, that way maybe it's easier to see missing dependencies
[13:58] <bluca> ddstreet: given autopkgtest accepts the test suite name as argument, would it be feasible to add multiple hooks/calls?
[13:58] <bluca> ie, instead of bionic-arch have bionic-arch-suitefoo bionic-arch-suitebar
[13:59] <bluca> doesn't even need to be a full matrix, just 2 sets would already help a lot
[14:00] <ddstreet> it's not possible with the current autopkgtest-cloud code, i don't think: https://code.launchpad.net/autopkgtest-cloud
[14:00] <ddstreet> IIRC, the test submissions from github don't allow specifying a test name
[14:00] <ddstreet> the autopkgtest cmd line does though
[14:00] <ddstreet> of course, the code could be changed to do it
[14:02] <ddstreet> bluca hmm i had it backwards, the github submissions do allow specifying 'testname' it appears: https://git.launchpad.net/autopkgtest-cloud/tree/webcontrol/request/submit.py
[14:02] <ddstreet> the 'validate_git_request' function is what handles the systemd ubuntu ci tests
[14:03] <bluca> so we are missing hooking that into the autopkgtest call?
[14:07] <ddstreet> bluca i'm unable to test the github test submission path, so i can't say if it works for sure or not, but reading the code it appears to pass the 'testname' param on to the autopkgtest runner, which would allow restricting the test run to a single one of the tests in the debian/tests/ dir
[14:08] <ddstreet> if the systemd github ci config was updated to add the 'testname' param it should work, i think - but i believe that would affect all PRs
[14:09] <bluca> can it be passed multiple times?
[14:09] <cpaelzer> doko: on the test rebuilds already 2/4 cases I've looked at have issues like "error: lto-no-text-in-archive: debian/lib" is that something kown/common and has a comman pattern to be resolved?
[14:10] <bluca> thinking whether we can have 2 jobs per arch with multiple suites, or if it must be one job per suite
[14:11] <ddstreet> no, it looks like it can be only used once
[14:11] <bluca> mmh bummer
[14:12] <bluca> would it be worth trying? the github actions CI already lists every job separately
[14:12] <bluca> the list would get verboser, but it already is
[14:15] <bluca> there's 14 suites, times 5 archs is quite a lot...
[14:15] <ddstreet> yeah, and i suspect Laney would not like systemd-upstream ci tests taking up 90 times more test instances than it currently does
[14:16] <bluca> eheh true
[14:16] <ddstreet> there has been resistance already to my request to just increase each instance from 1cpu to 4cpus due to resources
[14:16] <doko> cpaelzer: which ones?
[14:16] <bluca> is this running on canonical infra, or public cloud (payed by canonical)?
[14:17] <ddstreet> canonical infra
[14:17] <doko> cpaelzer: in the normal test rebuild?
[14:17] <ddstreet> it runs on the same hw as tests for our distro packages
[14:17] <bluca> I see
[14:18] <bluca> well I'll keep making improvements to the suite upstream
[14:18] <bluca> with some changes from yesterday, those suites should already take half the time they used to
[14:18] <bluca> there's some more things I can do to reduce runtime a little
[14:19] <bluca> if you can think of anything we can do cloud-side and want to experiment, let me know
[14:19] <ddstreet> yep will do, and i'll try to get back to the qemu PR, i think that'll help speed things up
[14:20] <bluca> which one?
[14:20] <ddstreet> https://github.com/systemd/systemd/pull/13409
[14:21] <ddstreet> did you get a change in for that already? i haven't looked at all since i got back from the holidays
[14:21] <bluca> no most of those should still be good
[14:21] <bluca> what I did was adding a mode to run most tests under nspawn, and to avoid rebuilding the same iamge over and over again
[14:22] <bluca> so now only half a dozen or so tests use qemu, the rest use nspawn
[14:22] <ddstreet> excellent that's good, qemu was really slowing it down
[14:22] <ddstreet> even with kvm, i'm pretty sure nspawn will be faster
[14:22] <bluca> yep that's why it's 2x as fast :)
[14:23] <bluca> but there's some tests that really need qemu
[14:23] <bluca> so your changes would be really great to ahve too
[17:00] <doko> mitya57: could you give me a hint how to disabled a build with precompiled headers in e.g. qtdeclarative-opensource-src-gles ?
[17:25] <mitya57> doko: try adding -no-pch to configure options in d/rules