[05:00] <pitti> Good morning
[05:01] <RAOF> Woah!  It's pitti!
[05:01] <RAOF> Good morning.
[05:01] <pitti> hey RAOF, how are you?
[05:02] <RAOF> Pretty good.
[05:05] <RAOF> Had quite an energetic boxing session this morning, fixed a couple of the bugs blocking the next gnome-do release on Sunday.
[05:06] <jbicha> pitti: what do you think of http://bazaar.launchpad.net/~ubuntu-desktop/libcanberra/ubuntu/revision/141
[05:06] <jbicha> it seems to fix https://bugzilla.gnome.org/show_bug.cgi?id=667905 for me
[05:06] <ubot2`> Gnome bug 667905 in general "fails to build: libcanberra undefined references" [Critical,Unconfirmed]
[05:06] <BigWhale> Good Morning. :>
[05:07] <jbicha> good morning
[05:08] <pitti> jbicha: hmm, ldd /usr/lib/x86_64-linux-gnu/libcanberra.so.0 doesn't show libcanberra anywhere?
[05:09] <pitti> jbicha: err, "show libX11"
[05:09] <jbicha> pitti: I don't really understand library linking much, so I need someone to help fix whatever's not working :)
[05:10] <pitti> jbicha: ah, looked at the wrong library
[05:10] <pitti> $ ldd /usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0.1.8|grep X11
[05:10] <pitti> libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fc464d5a000)
[05:10] <pitti> jbicha: so, if it doesn't happen in jhbuild, I wonder whether we have a patch or otherwise misbuild of canberra-GTK3
[05:11] <pitti> the GTK2 version seems to have reasonable dependencies
[05:11] <pitti> -gtk3 depends on a ton of X stuff
[05:11] <pitti> hm, I guess it's not -gtk2, it's the base library
[05:12] <pitti> jbicha: but looks fine to me for now
[05:13] <jbicha> you're saying you don't think the patch is necessary at first glance?
[05:13] <jbicha> or the opposite
[05:19] <desrt> good morning, everyone
[05:20] <desrt> RAOF: did you see me complaining about erratic scrolling behaviour?
[05:20] <RAOF> desrt: Yes, I did.
[05:20] <desrt> am i insane or are other people reporting this as well?
[05:20] <RAOF> Other people are reporting this as well.
[05:20] <desrt> oh.  good.
[05:20] <RAOF> Do you have an external mouse plugged in, by any chance?
[05:21] <desrt> yes
[05:21] <RAOF> Yeah, I'm pretty sure that triggers it.
[05:21] <desrt> i have a thinkpad with a trackpoint and a (disabled) touchpad
[05:21] <desrt> it's on a dock
[05:21] <desrt> and i have a usb mouse plugged into the dock
[05:21] <RAOF> (Or rather, the first scroll you try after moving the external mouse will be weird)
[05:22] <RAOF> So, the buglink has fallen off the end of my scrollback, but there's a bug assigned to Chase.
[05:22] <desrt> could it be something to do with the scrolling emulation for the trackpoint?
[05:22] <desrt> ah.  utouch issue, you think?
[05:22] <RAOF> No; something to do with the new input stack.
[05:22] <desrt> right.  that was my guess.
[05:22] <desrt> okay.  glad it's in the known-issue pile :)
[05:22] <RAOF> But since he's one of three people in the world who has a good idea about the X input stack… ☺
[05:22] <desrt> let me know if you need some testing or anything
[05:23] <RAOF> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/925785 is your winning bug.
[05:23] <ubot2`> Launchpad bug 925785 in xorg-server "Starting to scroll is erratic with edge scrolling on touchpad or mouse scrollwheels" [Medium,Confirmed]
[05:24] <desrt> RAOF: something else interesting: horizontal scroll seems to be consistently backwards
[05:25] <RAOF> Fun!  That's not the case for me :)
[05:25] <RAOF> And, in return: What the hell is the GTK change which prompted http://git.gnome.org/browse/gnome-control-center/commit/?id=7f5733b454e26c882d4e707b57cd03b104f57dd2 ?  This also seems to apply to GTK2, and it broke applications (specifically,  *my* application, GNOME Do).  Why is GTK2 still receiving application-breaking changes?!
[05:25] <desrt> so xev shows scroll-left as button 7 and scroll-right as button 6
[05:26] <RAOF> I'd have thought that the button which generates left-scroll would be 6 and right-scroll be 7.
[05:26] <RAOF> Also, buttons for scroll events is a terrible hack that must be expunged :)
[05:26] <desrt> that's the same sort of logic that would cause you to expect that scrolling left scrolls left :)
[05:27] <desrt> so the story is that <Primary> was introduced because of macs
q is the same as <Control>q
[05:27] <desrt> except on macs where it's <Command>q
[05:28] <RAOF> Ok.
[05:28]  * desrt wonders why the hell bastien is writing such ridiculous code
[05:28] <RAOF> Except for the bit where binding <Primary><Alt>space fails.
[05:28] <RAOF> And binding <Control><Alt>space works.
[05:28] <desrt> fascinating.
[05:29] <desrt> how did <Primary> creep into your world?
[05:29] <RAOF> GNOME Do's keybindings.
[05:29] <tjaalton> desrt: bug 921139
[05:29] <ubot2`> Launchpad bug 921139 in xorg-server "mouse scroll left<->right inverted since 1.11" [Medium,Confirmed] https://launchpad.net/bugs/921139
[05:29] <desrt> RAOF: yes... but did someone set a <Primary> keybinding?
[05:30] <desrt> is that what gtk returns to you know for the "type what you want the new keybinding to be..." code?
[05:30] <RAOF> desrt: No.  Somebody tried to set <Ctrl><Alt>space, the KeybindingCellRenderer showed <Primary><Alt>space, and pressing <ctrl><alt>space didn't work.
[05:30] <desrt> RAOF: this sounds like a bug
[05:30] <RAOF> It does, yes.
[05:31] <RAOF> It is the same bug Bastien was working around there :)
[05:31] <RAOF> (Or, at least, it's highly likely to be the same bug)
[05:31] <desrt> RAOF: i'm still confused by exactly what the cause is
[05:31] <RAOF> Also, GTK also seems to be setting both the Hyper and Super mask for <Win key>space.
[06:09] <pitti> GunnarHj: good morning
[06:09] <GunnarHj> pitti: Moring!
[06:10] <GunnarHj> Morning
[06:10] <pitti> GunnarHj: would you mind if we drop the custom branch for language-selector, and start using ubuntu:language-selector from now on?
[06:11] <pitti> GunnarHj: I think we don't have any pending merge proposals from you any more, do we?
[06:12] <GunnarHj> pitti: Whatever you decide is fine to me. Yes, I resubmitted the latest l-s MP and added a couple of items...
[06:12] <pitti> GunnarHj: https://code.launchpad.net/~jincreator/language-selector/korean_settings/+merge/72897 is the only one outstanding
[06:13] <pitti> GunnarHj: but it seems to me that this was covered by your recent one?
[06:13]  * pitti checks what's outstanding there
[06:14] <GunnarHj> pitti: Aha, didn't know you already merged it. :)
[06:15] <GunnarHj> pitti: In that case I have nothing more. Probably the latest one covers jincreator's MP, but I haven't studied it in detail.
[06:16] <pitti> GunnarHj: hm, where did you take your fontconfig changes from?
[06:17] <pitti> GunnarHj: where your and jincreator's versions differ, I guess I should take jincreator's?
[06:17] <GunnarHj> pitti: From the "Modified configuration files ..." attachment to bug 792471
[06:17] <ubot2`> Launchpad bug 792471 in fontconfig "Change default Korean font to ttf-nanum" [Undecided,In progress] https://launchpad.net/bugs/792471
[06:18] <pitti> GunnarHj: ah, I see; anyway, there aren't too many differences anyway
[06:20] <GunnarHj> pitti: Just saw your comment on that bug. Do you think that the fontconfig MP is redundant?
[06:21] <pitti> I don't know really
[06:21] <pitti> but I thought the point of fontconfig.d/ was that fonts packages drop their own stuff there
[06:21] <pitti> so that fontconfig itself doesn't need all the font specific knowledge
[06:21] <pitti> it's currently quite messy
[06:22] <pitti> there's fontconfig, fontconfig-config, the various config.d/ from fonts-*, and to make it worse, the hacks from language-selector
[06:22] <pitti> the latter need to be dropped at some point, they are a really evil hack
[06:22] <pitti> but as nobody in the ubuntu dev team really understands fontconfig, there's little chance of getting some cleanup there
[06:24] <GunnarHj> pitti: Well, I have no own knowledge in this area to contribute with. :(  Basically I felt that since the Koreans switch to a new default set of fonts, it's important to please them so soon before the LTS release. If there is a smarter way to organize it, that should probably better been dealt with after the release.
[06:24] <pitti> yes
[06:24] <pitti> anyway, changing existing config files at that point is ok
[06:24] <pitti> I just want to avoid introducing new ones at that point
[06:24] <GunnarHj> pitti: Ok.
[06:26] <pitti> ok, 0.65 uploaded, branch retired
[06:27] <pitti> GunnarHj: btw, would you be interested in looking into the im-switch -> im-config change?
[06:28] <GunnarHj> pitti: Ok, I can take a look at it.
[06:29] <pitti> GunnarHj: it might just be a dependency change, if it's really a drop-in replacement
[06:30] <pitti> if it's not, perhaps im-config already does proper config migration
[06:30] <pitti> if it uses different config files, and doesn't migrate, we should probably leave it alone at that point
[06:30] <GunnarHj> pitti: I know it's a little more than that. They use different directories, for instance.
[06:30] <pitti> but we owe Osamu a reply at least, I think
[06:30] <pitti> GunnarHj: I really appreciate this, thanks for looking into it
[06:31] <GunnarHj> pitti: No problem. But it may take a couple of days before I'm able to get back to you about it.
[06:39] <didrocks> good morning
[06:43] <pitti> bonjour didrocks
[06:43] <didrocks> hey pitti, how was your week-end?
[06:43] <pitti> didrocks: quite nice, thanks! met a lot of friends and family in Dresden again
[06:44] <didrocks> geat, not too tired by the hours of train required? :)
[06:44] <pitti> a bit
[06:44] <pitti> didrocks: how was your's?
[06:47] <didrocks> pitti: was fine. Still waiting to get back our broken heater to the shop, so we drink a lot of tea when being in the main room :) Nothing too exciting, we had a quite week-end with this cold week-end
[06:48] <pitti> it's ice cold here, too :/
[06:48] <pitti> -17 this morning, brrr
[06:48] <didrocks> about the same here, especially with this huge wind
[08:35] <seb128> hey
[08:36] <pitti> bonjour seb128
[08:36] <seb128> hey pitti, how are you?
[08:38] <pitti> quite fine, thanks! had a nice weekend in Dresden again
[08:38] <pitti> how are you?
[08:39] <didrocks> salut seb128, levé tôt par rapport à d'habitude? :)
[08:40] <seb128> pitti, I'm great thanks, had a nice relaxing freezing w.e ;-)
[08:40] <chrisccoulson> hey seb128 pitti didrocks
[08:40] <seb128> lut didrocks, ouais, j'avais assez dormis ;-)
[08:40] <didrocks> hey chrisccoulson
[08:40] <chrisccoulson> how are you?
[08:40] <seb128> hey chrisccoulson, how are you?
[08:40] <seb128> good!
[08:40] <chrisccoulson> seb128, yeah, good thanks. how are you?
[08:46] <pitti> hey chrisccoulson, good morning
[08:47] <chrisccoulson> hi pitti, did you have a good weekend?
[08:47] <pitti> chrisccoulson: yes, I did; we went to Dresden again, and met family and friends
[08:48] <chrisccoulson> excellent :)
[08:48] <chrisccoulson> have you got lots of snow atm?
[08:48] <pitti> not that much, mostly cold
[08:55] <pitti> chrisccoulson: ah, interesting comment about using the Firefox 10 ESR version in precise
[08:56] <pitti> chrisccoulson: we'll ship 11 (and keep updating) because more users want the latest and greatest?
[09:02] <Sweetshark> Goood MoooOOOooorning Desktoppers!
[09:03] <pitti> hey Sweetshark, welcome back!
[09:03] <pitti> Sweetshark: how was your vacation?
[09:03] <pitti> you sound refreshed and full of beans!
[09:04]  * Sweetshark finds out that returning from a two week vacation is a bit like deep snow skiiing (digging through a >3000 inbox) ...
[09:06] <didrocks> good morning Sweetshark :)
[09:10] <Sweetshark> pitti: Yes, vacation was great. Diverting on the return to make an intermediate stop at bruxelles for FOSDEM was a good idea too (and a great travel experience: digging out the car from ~50cm of snow and ice, driving to albertville with it, taking the train to lyon, taking the tram to the airport, waiting at the airport in an unheated terminal for boarding at -10 degree celsius which easyjet considered perfectly normal, arriving in bruxelle
[09:12] <Sweetshark> didrocks, seb128: and I will never disrespect the french train system again. 26 Euros for a ride from Albertville to Lyon is great, esp. if the train is 30 minutes late at the starting point and still arrives on time.
[09:13] <pitti> hah, sounds like fun
[09:13] <pitti> seems we were more lucky over the weekends
[09:14] <pitti> they had a broken track due to the cold, but only 10 mins delay during the trip, but they caught up pretty well again
[09:14] <didrocks> Sweetshark: waow you were quite lucky to arrive on time, as Albertville <-> Lyon is not that fast :)
[09:15] <chrisccoulson> pitti, yeah, i'm going to blog about it today ;)
[09:17] <Sweetshark> and so many things happened over the vacation: HUD announcement (yay!), The document foundation finally founded in Berlin (Yeah!), FOSDEM being absolutely amazing (LibreOffice DevRoom bursting from all the talks packed in it).
[09:18] <seb128> Sweetshark, would be better if they were on time at the start point still ;-)
[09:18] <pitti> Sweetshark: so nice to get back from vac then :)
[09:19] <Sweetshark> seb128: it was not more off time than it might happen in germany, but here sucha ticket would be triple the price ...
[09:19] <seb128> hehe
[09:22] <didrocks> that's because Lyon rocks :) (ok, you just saw the train station I guess :))
[09:25] <Sweetshark> didrocks: indeed. i spend no more than 5 minutes on ground in lyon between arriving with the ter train and leaving with the tram to the airport having no knowledge at all how one gets to the airport (or where it is) in lyon at all.
[09:26] <didrocks> Sweetshark: the tram is nice, isn't it? getting to the airport in less than 30 minutes…
[09:26] <didrocks> (the train station/tram station is at less than 20 minutes by feet from my home)
[09:38] <Sweetshark> didrocks: yes, the tram is nice! I just wondered about the relative pricing (half the price of getting from Albertville to Lyon seemed odd).
[09:39] <didrocks> Sweetshark: yeah, it's weird. It was a one hour trip by bus before and the price of the bug for 13 €, when they launched this new service last year, they just aligned…
[09:41] <Sweetshark> didrocks: "price of the bug for 13 €"? ok, I take 1000 for that price. By when will you have all the open bugs for LO fixed? ;D
[09:42] <didrocks> s/bug/bus :p
[09:42] <Sweetshark> hehe
[09:42] <didrocks> yeah, we will become rich! :)
[09:44]  * Sweetshark would seriously consider to shell out 13K € if somebody fixes all current open LO issues in launchpad for that with no exceptions.
[09:44] <Sweetshark> (personal money that is)
[09:51] <agateau> morning! anyone from the SRU team, can you look at SRU bug #877358 ?
[09:51] <ubot2`> Launchpad bug 877358 in qt-at-spi "QtAccessibility causes crashes in several applications" [Undecided,Confirmed] https://launchpad.net/bugs/877358
[09:51] <agateau> (rah... never press Enter while editing a chat line)
[09:52] <agateau> well that should be readable enough I hope
[09:53] <pitti> agateau: I didn't accept it yet because there is already an at-spi2-core in -proposed which needs testing first
[09:54] <agateau> pitti: oh ok
[09:54] <pitti> agateau: oh, I see, it's meant to replace this?
[09:54] <pitti> http://launchpadlibrarian.net/91134355/at-spi2-core_2.2.2-0ubuntu1.2_source.changes looks rightly done, anyway (using -v
[09:55] <pitti> agateau: ok, debdifff looks fine, accepting
[09:55] <agateau> pitti: great, thanks
[09:58]  * didrocks uploaded with -v, isn't it?
[09:58] <didrocks> pitti: ^
[09:58] <pitti> yes
[09:59] <didrocks> ok :)
[10:29] <Sweetshark> seb128: did you investigate the l10n in LO broken on a release build but not in a PPA issue further?
[10:30] <seb128> Sweetshark, not really lo is complex enough that I figured it wouldn't get something useful in an hour
[10:33] <Sweetshark> pitti: requesting a "640K is _NOT_ enough for everyone"-exception for PPA builders for libreoffice. I tried hard to get the LO 3.5.0rc1 build on the PPA for the second bug hunting session, but it unfortunately failed. Not wanting to spoil my vacation, I did not check the build log at 3am then, only to find out that it failed with:
[10:33] <Sweetshark> IO error: write error during copy : No space left on device
[10:36] <pitti> urgh
[10:36] <pitti> Sweetshark: I'm afraid you need to coordinate that with infinity; we might have PPA buildss with more space
[10:59] <chrisccoulson> huh, i just wrote a patch for the icedtea plugin, and it compiled first time
[10:59] <chrisccoulson> i must have done something wrong
[11:02] <pitti> *chuckle*
[11:10] <rye> chrisccoulson, did it run?
[11:10] <chrisccoulson> rye, yes. and it fixed the crash i'm trying to fix. but it exposed another one that i also need to fix :)
[11:11] <didrocks> chrisccoulson: you should have had a "return 0" at the begining, you could then have said "yeah, I ran it and it even didn't crash!" :)
[11:11] <chrisccoulson> heh
[11:23] <chrisccoulson> seb128, we can reapply the light-themes changes btw. i fixed thunderbird by friday evening
[11:23] <seb128> chrisccoulson, thanks
[11:26] <RAOF> Wooo!  Asynchronous packagekit integration for the colour capplet.
[11:26] <rodrigo_> pitti, I was travellking last week, so didn't get a chance to ping you, so just so you know: about to finish the wip/install-langs branch
[11:27] <rodrigo_> pitti, will ping you as soon as it's ready
[11:28] <pitti> hey rodrigo_
[11:28] <pitti> rodrigo_: ah, thanks
[11:28] <pitti> rodrigo_: please tell me if the aptdaemon-pkcompat stuff doesn't work for you
[11:28] <rodrigo_> pitti, will do
[11:43] <pitti> chrisccoulson: oh, are you about to upload icedtea?
[11:43] <pitti> chrisccoulson: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html looks like a trivial problem to fix
[11:43] <chrisccoulson> pitti, no, i'm trying to fix the number 7 top crasher in firefox 10 :)
[11:44] <pitti> ok
[11:46] <chrisccoulson> oh, it's actually number 5 today :(
[11:50] <chrisccoulson> right, this had better fix it this time :)
[11:51] <rye> chrisccoulson, is it something related to single-threaded thing that once was multi-threaded in icedtea?
[11:51] <chrisccoulson> rye, http://blog.mozilla.com/luke/2012/01/24/jsruntime-is-now-officially-single-threaded/
[11:52] <chrisccoulson> someone from mozilla did open a bug in the icedtea bug tracker in november, but it's had zero responses so far
[11:52] <chrisccoulson> and the crash volume is pretty much block-worthy now ;)
[11:53] <chrisccoulson> yay, no crashes \o/
[11:53] <chrisccoulson> well, for the test case that i have here, anyway
[11:53] <chrisccoulson> i guess i should try a few more sites
[12:04] <chrisccoulson> oh, that sucks. bamfdaemon just crashed on me
[12:05] <chrisccoulson> now my launcher looks like it's pretty much hosed until i restart my session
[12:08] <dpm> chrisccoulson, I'm not sure it's the proper way, but resetting unity seems to fix it for me
[12:09] <didrocks> dpm: shouldn't be related at all
[12:09] <didrocks> dpm: or jus try to restart unity
[12:09] <didrocks> just*
[12:10] <dpm> didrocks, I didn't know, I just blindly restarted unity when bamfdaemon crashed and I started getting duplicated launchers all over the place :)
[12:11] <chrisccoulson> that's why i logged out :)
[12:11] <chrisccoulson> sometimes it's the easiest way
[12:11] <chrisccoulson> tmux to the rescue!
[12:11] <dpm> didrocks, btw, the unity upload last Friday did fix my issue with indicator menus appearing in grey instead of black. The only remaining issue is that the sound indicator volume slider's background is grey. Not sure if there is an existing bug for it, but if it's not known, I'll be happy to file it
[12:12] <didrocks> dpm: I read something about it, not sure if there is a bug or not opened on it, you should look at light-themes and ping Cimi
[12:12] <dpm> ok
[12:23] <tkamppeter> pitti, hi
[12:33] <ronoc> mvo, hey
[12:33] <ronoc> just getting around the i-session package kit port now
[12:34] <ronoc> mvo, just wondering, I don't see it on the bus, starting update-manager and did an upgrade
[12:34] <ronoc> but couldn't see org.freedesktop.packagekit on d-feet
[12:34] <ronoc> system bus i would imagine ?
[12:37] <mvo> ronoc: yeah, it should be on the system bus but iirc its auto activated
[12:37] <ronoc> mvo, oh okay cool, will try now
[12:38] <mvo> ok
[12:40] <rye> dpm, btw, reÑ unity background ' the keyboard layout display has a dark background instead of light one used earlier ' is this in the same category_
[12:42] <rye> symbols key - "'" -> "-", "_" -> "?"
[12:46] <dpm> rye, the keyboard layout display looks the same as it's ever been to me
[12:50] <mdeslaur> seb128: mind if I kill the numlock warning in gtk+3.0 and gss with fire?
[12:50] <seb128> mdeslaur, cf my comment on the bug
[12:50] <seb128> mdeslaur, hey btw ;-)
[12:51] <chrisccoulson> hah, "A new mailing list has been created for Ayatana Discussion (unity-design). If you would like to subscribe to the list,...."
[12:51] <seb128> mdeslaur, one of the upstream bug says "should be for netbooks only", they have keys with multiple usages that makes the warning useful for those?
[12:51] <chrisccoulson> errrrrrm
[12:51] <chrisccoulson> i think not :)
[12:51] <seb128> chrisccoulson, ;-)
[12:51] <mdeslaur> seb128: hi! good weekend?
[12:51] <seb128> mdeslaur, excellent! you?
[12:52] <mdeslaur> seb128: the problem is a lot of hardware lies about the state of the numlock key, it's not possible to get this right without quirking all the specific hardware
[12:53] <seb128> mdeslaur, feel free to go for it if you add your patch to the upstream bugs with a comment stating why you think it's the right thing to do ;-)
[12:53] <seb128> mdeslaur, there might be a new gtk today so maybe just commit to the vcs for gtk and don't upload
[12:53] <mdeslaur> seb128: ok, thanks
[12:53] <seb128> no need to keep the buildds busy with a second undeed build
[12:53] <seb128> mdeslaur, yw, thanks for working on those issues!
[12:54] <seb128> desktop help is greatly appreciated ;-)
[12:55] <mdeslaur> seb128: well, don't get too used to it, I only fix bugs when they annoy the crap out of me :)
[12:56] <chrisccoulson> mdeslaur, i bet i can make https://bugzilla.mozilla.org/show_bug.cgi?id=716036 annoy the crap out of you
[12:56] <ubot2`> Mozilla bug 716036 in Layout "css z-ordering renders invisible text on google search page" [Normal,Unconfirmed: ]
[12:57] <mdeslaur> chrisccoulson: I use w3m, nice try though
[12:58] <chrisccoulson> lol
[13:04] <rye> dpm, http://ubuntuone.com/3XnG7IgXW6umEwCZnj7V08
[13:05] <dpm> rye, oh that one, yes, that indeed doesn't look right
[13:05] <dpm> it displays the same for me too
[13:15] <rye> by the way - in current precise/unity sometimes i get the same window appearing as two in the alt-tab switcher - e.g. firefox, ubuntuone control panel - http://ubuntuone.com/6J4ZyQmXpH6Axx8GXSNniz - is it known?
[13:18] <seb128> rye, does it has a duplicate > on the launcher as well?
[13:19] <rye> seb128, yes
[13:19] <seb128> rye, I've noticed that too, dunno if there is a bug report, you should open a bug with ubuntu-bug unity
[13:20] <jibel> rye, bug 926385
[13:20] <ubot2`> Launchpad bug 926385 in unity "thunderbird appears twice in windows switcher" [Undecided,New] https://launchpad.net/bugs/926385
[13:21] <rye> jibel, how about we rename it to "applications appear twice in windows switcher" ?
[13:21] <rye> jibel, and i will add the picture
[13:21] <rye> heh
[13:22] <rye> what's interesting is that both of the windows are selected when alt-tabing, as if the system knows that's one object
[13:22] <jibel> rye, sure, don't hesitate to rename it to better describe the problem.
[13:22] <seb128> jibel, it's not specific to tb and not specific to the switcher ;-)
[13:22] <seb128> the title is a bit misleading
[13:23] <seb128> i.e the launcher also has a duplicate > when that happens
[13:31] <chrisccoulson> well, i got the "launcher listed twice" issue right after bamfdaemon crashed :)
[13:31] <chrisccoulson> might be a clue ;)
[13:33] <seb128> chrisccoulson, did you report the segfault issue?
[13:33] <chrisccoulson> seb128, not yet. i need to update my system before i recreate it
[13:33] <seb128> ok
[13:33] <jibel> seb128, bug 926208
[13:34] <ubot2`> Launchpad bug 926208 in bamf "bamfdaemon crashed with SIGABRT in g_assertion_message()" [High,Confirmed] https://launchpad.net/bugs/926208
[13:34] <seb128> jibel, thanks
[13:34] <seb128> we need to get Trevinho or or DBO to look at it ;-)
[13:38] <didrocks> pgraner: hey, we have a potential fix for your unity crash. It can trigger some regression on session close though (compiz segfaulting when exiting), but it should be better than what you had. Can you confirm it fixes it for you? It's in the unity-team ppa: https://launchpad.net/~unity-team/+archive/ppa
[13:40] <jibel> seb128, to reproduce the crash, open g-c-c and select different config applets until it crashes.
[13:40] <jibel> I'll update the report
[13:40] <seb128> jibel, thanks
[13:43] <pgraner> didrocks, I'll check here in a bit otp right now
[13:43] <didrocks> pgraner: thanks, keep me i touch :)
[13:43] <didrocks> in*
[13:44] <pgraner> didrocks, ack
[13:48] <seb128> mdeslaur, btw I'm not sure I like your nautilus change, having selinux support built in makes easier to use selinux for those who want that, ideally we shouldn't have to turn it off to hide the properties section
[13:49] <seb128> mdeslaur, is there a way to check if selinux is active?
[13:49] <mdeslaur> seb128: if you get one of our three selinux users to actually make selinux work properly in Precise, I'll turn it back on
[13:50] <seb128> lol
[13:50] <mdeslaur> seb128: our nautilus doesn't even have the big selinux patch that RH carries to make the information useful
[13:50] <seb128> mdeslaur, ok, fair enough ;-)
[13:59] <mdeslaur> seb128: if you set an icon for your account, are you able to get g-c-c to remove it?
[13:59] <mdeslaur> seb128: just want to confirm before filing a bug
[14:00] <seb128> mdeslaur, thanks for screwing my config :p
[14:00] <mdeslaur> seb128: lol, I guess that's a "no"? :)
[14:01] <seb128> mdeslaur, indeed :p
[14:02] <seb128> mdeslaur, https://bugzilla.gnome.org/show_bug.cgi?id=665173
[14:02] <ubot2`> Gnome bug 665173 in User Accounts "Can't reset user avatar (image)" [Normal,Resolved: notgnome]
[14:02] <seb128> mdeslaur, seems an accountsservice thing and fixed upstream, can you open a bug on launchpad, I will look at backporting the fix later
[14:02] <mdeslaur> seb128: sure, thanks
[14:03] <seb128> mdeslaur, thanks for pointing it ;-)
[14:04] <mdeslaur> seb128: you'd point it out too if you were stuck with a butterfly on your login screen :)
[14:04] <seb128> mdeslaur, I think I am, thanks to you :p
[14:04] <mdeslaur> hehe
[14:07] <mdeslaur> seb128: wow, you're fast!
[14:08] <seb128> mdeslaur, lol
[14:08] <seb128> I just got lucky, I opened the bug list as a todolist item and I noticed you just filed the bug ;-)
[14:09] <mdeslaur> hehe
[14:20] <didrocks> in*
[14:20] <didrocks> oupss ENOTGOODTERMINAL
[14:26] <Trevinho> seb128: about this bug
[14:26] <Trevinho> https://bugs.launchpad.net/ubuntu/+source/bamf/+bug/926208
[14:26] <ubot2`> Launchpad bug 926208 in bamf "bamfdaemon crashed with SIGABRT in g_assertion_message()" [High,Confirmed]
[14:26] <Trevinho> I can't reproduce it on trunk
[14:27] <seb128> Trevinho, yes?
[14:27] <Trevinho> for sure there are visual issues... :/
[14:27] <seb128> Trevinho, is trunk much different from precise?
[14:27] <Trevinho> mhmhm... I guess it is
[14:27] <Trevinho> need to checkl
[14:27] <seb128> Trevinho, is there any tarball rolling planned? did that happen for 5.2?
[14:29] <Trevinho> seb128: I'm not sure I understood what you mean :)
[14:29] <seb128> Trevinho, was there a bamf release for unity 5.2?
[14:29] <seb128> seems so
[14:29] <seb128> 0.2.108 release from the 0.2 series released 2012-02-03
[14:30] <seb128> Trevinho, so trunk changed a lot since friday or is 0.2 different from trunk? I'm trying to figure why we don't get those bug fixes from trunk in precise ;-)
[14:30] <Trevinho> mh, no it doesn't change
[14:31] <seb128> Trevinho, https://code.launchpad.net/~unity-team/bamf/trunk
[14:31] <Trevinho> I guess they're matching so...
[14:31] <seb128> Trevinho, seems to indicate that precise is trunk
[14:31] <seb128> so that bug should still be in trunk ...
[14:31] <seb128> Trevinho, do you build with different optimizations, like -O0?
[14:32] <seb128> rather than -O2
[14:32] <seb128> Trevinho, one thing which happens when you don't use -O2 is that variables get null initialized, so it can hide bugs due to improper init
[14:34] <Trevinho> seb128: I'm building it with default settings
[14:34] <Trevinho> so... I guess O2
[14:34]  * Trevinho checking
[14:35] <seb128> Trevinho, thanks
[14:35] <seb128> weird
[14:35] <seb128> Trevinho, the stacktrace is not useful on this bug to figure the issue? what debug infos would be useful?
[14:35] <Trevinho> no, I'm using O2
[14:35] <Trevinho> that stacktrace is not useful
[14:36] <Trevinho> I don't get any bamf code pointed there except the main
[14:36] <Trevinho> so.... A full stacktrace.... If you can build it from sources and exec it from there maybe you get more infos
[14:39] <Trevinho> seb128: damn... I really can't reproduce it... I'm switching gnome-control-center panel for about 50 times (also very quickly) and nothing happens
[14:39] <Trevinho> maybe I should try to use a xtest script...
[14:40] <seb128> Trevinho, no sure but I seem to have it often there when I load a custom .desktop from the dash, custom being one in my .local
[14:40] <seb128> Trevinho, I will try to get extra infos
[14:41] <Trevinho> thanks seb128
[14:43] <rodrigo_> pitti, hmm, I don't see aptdaemon-pkcompat package, should I?
[14:44] <rodrigo_> pitti, is it python-aptdaemon.pkcompat ?
[14:49] <seb128> Trevinho, right, it doesn't segfault for me either :-( but I easily get the double instance (i.e > in the launcher and alt-tab buggy) with g-c-c
[14:51] <Trevinho> yes, that's true
[14:51] <Trevinho> that totally needs a proper fix
[14:51] <Trevinho> even if... did you restart unity after updating bamf?
[14:51] <seb128> Trevinho, you get it as well?
[14:52] <seb128> Trevinho, yes
[14:53] <Trevinho> seb128: yes, but I didn't restart unity...
[14:53] <Trevinho> Anyway that should be definitively fixed
[14:53] <seb128> Trevinho, it happens easily on fresh sessions there
[14:53] <seb128> well "fresh", normal login after boot, but could be that bamf segfault and get respawned during the session
[14:54] <Trevinho> seb128: it could be possible... In fact I should check that with working bamf... I didn't notice that issue during the deveolpment
[14:54] <seb128> Trevinho, I will try to valgrind it a bit later
[14:55] <Trevinho> nice
[15:05] <ricotz> seb128, hello
[15:05] <ricotz> seb128, i hope it wasnt intentional to drop libgdk-pixbuf2.0-common.install?
[15:06] <seb128> ricotz, oh, crap, thanks
[15:06] <seb128> ricotz, no, I probably forgot to bzr add it
[15:06] <ricotz> ok
[15:06] <seb128> and bzr-builddeb is that stupid that it didn't warn me about it
[15:06] <seb128> fixing
[15:06] <ricotz> bump glib to 2.31.14 too ;)
[15:07] <ricotz> seb128, oh one more, libgdk-pixbuf2.0-dev.install the last line can be dropped
[15:07] <seb128> ricotz, configure.ac has m4_define([glib_required_version], [2.31.0])
[15:08] <seb128> ricotz, can you point to mclasen that they need to update it?
[15:09] <ricotz> ah nvm, i was thinking about the gressource stuff
[15:09] <tkamppeter> pitti, hi
[15:10] <ricotz> seb128, hmm, but the deb package want 2.31.10
[15:10] <seb128> ricotz, what version is required then?
[15:10] <ricotz> not sure
[15:11] <ricotz> i would rely on the symbols generated one
[15:11] <seb128> .10 then?
[15:16] <pitti> hello tkamppeter
[15:18] <tkamppeter> pitti, I only wanted to say that I am working on updating CUPS to 1.5.2.
[15:18] <tkamppeter> pitti, I hope you did not work on CUPS today.
[15:19] <pitti> tkamppeter: ah, a new upstream release at last?
[15:19] <pitti> tkamppeter: no, I'm not
[15:19] <tkamppeter> pitti, yes, a week ago or so I have asked Mike for releasing before our FF.
[15:20] <pitti> tkamppeter: has there ever been an 1.5.1?
[15:20] <pitti> tkamppeter: I checked for a new release about a week ago, and there wasn't any
[15:21] <tkamppeter> pitti, the release was issued Friday evening or Saturday, Mike accidentally up[loaded a 1.6.x snapshot under the name 1.5.1, so he has taken the correct snapshot and uploaded it as 1.5.2.
[15:22] <pitti> ah, heh
[15:22] <tkamppeter> So 1.5.2 is the collection of all 1.5.x changes from Oneiric FF to Precise FF.
[15:23] <pitti> tkamppeter: nice; I hope that'll get us rid of a few patches again :)
[15:23] <pitti> I need to run out for half an hour, bbl
[15:23] <tkamppeter> pitti, 6 patches so far.
[15:23] <didrocks> pgraner: any news?
[15:24] <mdeslaur> mhr3: could we get ~/.local/share/zeitgeist to be 0600 to fix LP: #926652?
[15:26] <mhr3> mdeslaur, as you commented, it's already going that
[15:26] <mdeslaur> mhr3: hrm, it doesn't seem to be working for me, I still have open permissions on precise
[15:27] <mhr3> mdeslaur, it affects just new dbs afaict
[15:27] <mdeslaur> mhr3: yeah, I was about to say that
[15:28] <ricotz> seb128, i think .10 it is then
[15:28] <mdeslaur> mhr3: I think we should fix perms on existing databases also. Is there anything else in that directory that contains private info? couldn't we make the whole directory 0600?
[15:29] <seb128> ricotz, I hope I got it right this time ;-) http://launchpadlibrarian.net/92102142/gdk-pixbuf_2.25.2-0ubuntu1_2.25.2-0ubuntu2.diff.gz
[15:29] <dobey> pitti, seb128: care to poke at https://bugs.launchpad.net/ubuntu/+bug/926391 please? :)
[15:29] <ubot2`> Launchpad bug 926391 in ubuntu "[needspackaging] rhythmbox-ubuntuone" [Undecided,New]
[15:29] <mhr3> mdeslaur, yea, i suppose that makes sense
[15:29] <mhr3> RainCT, ^^ one extra commit pls :)
[15:30] <mdeslaur> mhr3: awesome, thanks! And please change perms on existing directories also so we fix everyone who's upgrading.
[15:30] <ricotz> seb128, looks good ;-)
[15:30] <seb128> ricotz, excellent, thanks for pointing the issues!
[15:32] <RainCT> mhr3: it'll run once we bump the schema version (which we're supposed to do anyway to update the ontology)
[15:32] <RainCT> mhr3: but yeah chmoding the directory too makes sense to me
[15:33] <mhr3> RainCT, in case it's the default one... we wouln't want to screw with someone who's using custom DATA_PATH
[15:35] <RainCT> mhr3: btw, I don't have LP powers for -datahub
[15:35] <seb128> jbicha, hey
[15:36] <seb128> jbicha, I've dropped our gnome-settings-daemon patch that would have created issues with the new gnome-desktop3, you can update gnome-desktop3 to precise if you want
[15:39] <pgraner> didrocks, still otp for another hour and a half :( sorry
[15:39] <pgraner> didrocks, I'll try it right after the call
[15:39] <didrocks> pgraner: ok, thanks :)
[15:39] <mhr3> RainCT, of course you do
[15:39] <RainCT> mdeslaur: shouldn't that be s/0600/0700?
[15:39] <didrocks> pgraner: if you don't have time before my eod, please just sent me an email, I'll backport it to precise
[15:39] <pgraner> didrocks, ack will do
[15:40] <didrocks> thx :)
[15:42] <mdeslaur> RainCT: oh, yes, sorry -ENEEDCAFFEINE
[15:49] <pitti> dobey: adding to my TODO list
[15:52] <dobey> pitti: thanks!
[16:15] <rickspencer3> hey all, is there a way to figure out what is in the gi.repository for python?
[16:16] <rickspencer3> specifically, I want to import gtksourceview2, but I can't easily see what it is called in the repository
[16:16]  * didrocks uses ipython + completion
[16:16] <kenvandine> rickspencer3,  or look at /usr/share/gir-1.0
[16:17] <rickspencer3> didrocks it wasn't showing up in completion :/
[16:17] <kenvandine> there is GtkSource which is for gtk3
[16:17] <kenvandine> i don't think we have it for gk2
[16:18] <kenvandine> gtk2
[16:18] <pitti> rickspencer3: you need to install gir1.2-gtksource-3.0, then you can look in /usr/lib/girepository-1.0/
[16:18] <pitti> /usr/share/gir-1.0/ is useful as well, but requires the library's -dev package
[16:18] <rickspencer3> pj dang
[16:18] <pitti> well, it's actually much more useful, as the .gir files are a great documentation
[16:19] <pitti> rickspencer3: sorry, no, GTK2 works rather poorly with GI
[16:19] <rickspencer3> pitti, can you tell me more?
[16:19] <pitti> rickspencer3: sure, about what?
[16:19] <rickspencer3> life, the universe, everything
[16:19] <rickspencer3> or, about .gir files being documentation ;)
[16:20] <pitti> 42!
[16:20] <pitti> rickspencer3: well, I presume you'd just slap me if I call that documentation
[16:20] <pitti> rickspencer3: but it's XML, so at least it's halfway readable
[16:20] <rickspencer3> pitti, basically, anything is better than what I have now
[16:20] <pitti> rickspencer3: there's some work on turning that into nicely formatted HTML, but it's going slowly
[16:20]  * rickspencer3 considers making a .gir file browser
[16:20] <kenvandine> the gir file is probably the best docs we have
[16:21] <kenvandine> rickspencer3, google it, someone already did :)
[16:21] <pitti> rickspencer3: it documents every class, method, argument, data type, etc., as this is the input format of pygobject
[16:21] <kenvandine> i haven't tried it, but i saw a blog post recently
[16:21] <rickspencer3> *sigh*
[16:22] <rickspencer3> all the fun has drained out of all my gtk programming
[16:22] <rickspencer3> ** WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
[16:22] <rickspencer3> /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: specified class size for type `PyGtkGenericCellRenderer' is smaller than the parent type's `GtkCellRenderer' class size
[16:22] <rickspencer3>   from gtk import _gtk
[16:22] <rickspencer3> /usr/lib/python2.7/dist-packages/gtk-2.0/gtk/__init__.py:40: Warning: g_type_get_qdata: assertion `node != NULL' failed
[16:22] <rickspencer3>   from gtk import _gtk
[16:22] <rickspencer3> Segmentation fault (core dumped)
[16:22] <pitti> dobey: why COPYING? seems the whole source is LGPL?
[16:22] <rickspencer3> don't debug for me, just saying ...
[16:22] <rickspencer3> boooo
[16:23] <pitti> rickspencer3: are you perhaps trying to mix gi.repository.* and "import gtk"?
[16:23] <kenvandine> rickspencer3,  https://sourceforge.net/projects/girlook/
[16:23] <kenvandine> but i haven't tried it
[16:23] <rickspencer3> pitti, yes, I am sure I am using some gtk code somewhere
[16:23] <rickspencer3> my point was just ...
[16:23] <rickspencer3> this is not fun
[16:23] <rickspencer3> I am considering abandoning all of my Gtk code
[16:24] <rickspencer3> just shooting each of those apps in the head, and starting over
[16:24] <pitti> I'm afraid you can just use one or the other
[16:24] <pitti> rickspencer3: I can tell you how to easily find stuff that pulls in the static bindings
[16:24] <pitti> if that helps
[16:25] <rickspencer3> pitti, do tell
[16:25] <pitti> rickspencer3: what I do is
[16:25] <pitti> sudo vi /usr/share/pyshared/gi/_gobject/constants.py
[16:25] <pitti> and at the top, add
[16:25] <pitti> raise ImportError("static bindings, no no no!")
[16:26] <om26er> mvo, hey!
[16:26] <pitti> then the back trace tells you exactly which module pulls it in
[16:26] <rickspencer3> hmmm
[16:26] <pitti> rickspencer3: ^ sometimes that's not very obvious, as there might be deeply transitive imports
[16:27] <om26er> mvo, when I try to enable a ppa in software properties I get this bug 854818 in precise.. I am fully updated
[16:27] <ubot2`> Launchpad bug 854818 in software-properties "software-properties-gtk crashed with AttributeError in toggle_source_use(): 'NoneType' object has no attribute 'disabled'" [High,Triaged] https://launchpad.net/bugs/854818
[16:27] <jbicha> seb128: thanks
[16:28] <pitti> dobey: when I make some changes to the source (I'd like to add a bug ref to the changelog, and some debian/copyright formalities), will that mess up a bzr of your's?
[16:29] <pitti> dobey: if you have a bzr, I'm happy to upload it as it is
[16:30] <jbicha> pitti: hi again, did you have an opinion on the canberra thing from this morning?
[16:30] <pitti> jbicha: yes, I answered
[16:30] <pitti> jbicha: it seems fine to me
[16:30] <jbicha> my changes are fine?
[16:30] <pitti> jbicha: I got confused at first wrt. libcanberra vs. libcanberra-gtk3
[16:30] <pitti> jbicha: but it surely should affect upstream as well, unless we do some wrong building?
[16:31] <jbicha> yes, I'll ask upstream about it too, just wanted to see if my change wasn't completely crazy
[16:32] <pitti> kenvandine: hm, that doesn't look very sophisticated, though -- you'd still look at the raw XML?
[16:32] <dobey> pitti: no, no bzr; just using the auto-imported branch in ubuntu
[16:32] <jbicha> I'd like to update libgdata this week, is there any reason that wouldn't really be safe?
[16:32] <pitti> kenvandine: there's also some half-done work wrt. integrating it into gtk-doc
[16:33] <pitti> jbicha: I don't know one, I guess we need to test it with e-d-s and other rdepends
[16:33] <pitti> dobey: ack
[16:33] <jbicha> I should put gdata in the desktop PPA, then?
[16:34] <kenvandine> pitti, i use the gir file, i never tried the girlook thing
[16:34] <pitti> kenvandine: same here
[16:34] <pitti> jbicha: sounds fine; happy to test with that, I'm using e-d-s with my google accounts
[16:34] <mvo> rickspencer3: I'm so with you on this, its becoming hard work :/
[16:35] <pitti> dobey: upped
[16:35] <dobey> pitti: thanks much!
[16:40]  * didrocks is sure now mvo has a hilight on "gir" or "repository" :)
[16:40] <pitti> dobey: ... and source NEWed
[16:41] <pitti> dobey: I'll add it back to the desktop seeds
[16:41] <dobey> pitti: great!
[16:42] <dobey> i'll fire off the mail to request it be added to the ubuntuone packageset after lunch then :)
[16:43] <pitti> dobey: added
[16:43] <pitti> dobey: ^ to the package set, I mean
[16:46] <dobey> oh thanks :)
[16:46] <dobey> off to lunch now :)
[16:52] <chrisccoulson> hah, love the comments: https://crash-stats.mozilla.com/report/index/c78b1257-eeb8-4c71-9219-8634b2120205
[16:54] <pitti> heh
[16:55] <m4n1sh> didrocks: there?
[16:55] <didrocks> m4n1sh: yeah!
[16:55] <m4n1sh> you have done the packaging?
[16:55] <didrocks> m4n1sh: ready to make the first official release
[16:55] <m4n1sh> yes
[16:55] <didrocks> m4n1sh: it's done, I fixed the FTBFS here :)
[16:55] <m4n1sh> updating changelog etc
[16:56] <m4n1sh> fixed distcheck
[16:56] <m4n1sh> FTFBS due to?
[16:56] <didrocks> excellent!
[16:56] <m4n1sh> didrocks: FTFBS due to? maybe the fix might find it's way upstream
[16:57] <pitti> good night everyone!
[16:57] <m4n1sh> you need to update debian/rules to add --with-ccpanel because due to changes it does not look for ccpanel by default unless asked for
[16:57] <didrocks> pitti: have a good night pitti!
[16:57] <didrocks> m4n1sh: desktop-file-validate: command not found
[16:57] <seb128> chrisccoulson, see, launchpad comments are not that bad ;-)
[16:58] <didrocks> m4n1sh: maybe we need to detect it (if you still use it) in the configure?
[16:58] <m4n1sh> yup. I need to look at deja-dup again
[16:58] <seb128> just build-depends on desktop-file-utils?
[16:58] <m4n1sh> I didn't try building it in a chroot environ
[16:58] <seb128> pitti, 'night
[16:58] <m4n1sh> that should solve in ubuntu
[16:58] <m4n1sh> but should be fixed in the build system too
[16:58] <didrocks> seb128: I mean, upstream :p
[16:59] <m4n1sh> didrocks: also remember --with-ccpanel
[16:59] <didrocks> seb128: of course, the build-dep is already here :)
[16:59] <seb128> ;-)
[16:59] <didrocks> m4n1sh: hum, is it needed?
[16:59] <pitti> see you at the TB meeting tonight
[16:59] <m4n1sh> yes
[16:59] <didrocks> m4n1sh: it wasn't before (autodetected, isn't it?)
[16:59] <m4n1sh> didrocks: I am not sure how to pass it to configure, probably debian/rules
[16:59] <m4n1sh> didrocks: that broke distcheck
[16:59] <didrocks> m4n1sh: or my memory is fuzzy, let me check :)
[16:59] <m4n1sh> need to find a way to kill both birds with one stone
[17:00] <didrocks> m4n1sh: don't worry on the packaging :p
[17:00] <m4n1sh> just updating you
[17:00] <didrocks> ok about the added option
[17:01] <m4n1sh> that was already present
[17:01] <m4n1sh> the behaviour changed
[17:01] <didrocks> hum, what do you mean?
[17:01] <m4n1sh> by default it does not detect libgnome-control-center
[17:01] <m4n1sh> unless asked to do so
[17:02] <didrocks> that's a weird behavior
[17:02] <m4n1sh> earlier if that option was present and libgnome-control-center was not found it threw an error
[17:02] <m4n1sh> yes, I know
[17:02] <m4n1sh> that is a workaround for now
[17:02] <didrocks> why do you need that?
[17:02] <didrocks> ok
[17:02] <m4n1sh> will fix it
[17:02] <didrocks> if I have time, I'll maybe try to help you here :)
[17:02] <m4n1sh> everything is in configure.ac file
[17:03] <m4n1sh> plan to do another minor release on 13th
[17:03] <m4n1sh> to fix any bugs found
[17:03] <m4n1sh> or UI minor enhancements
[17:04] <didrocks> sure :)
[17:04]  * m4n1sh heads for dinner
[17:04] <didrocks> m4n1sh: do you have a tarball?
[17:04] <m4n1sh> didrocks: not now
[17:04]  * didrocks didn't check launchpad yet
[17:04] <didrocks> one sec :)
[17:04] <didrocks> ah
[17:04] <m4n1sh> you can make one
[17:04] <didrocks> m4n1sh: well, it's better when upstream does an official one, but ok
[17:04] <m4n1sh> lp:activity-log-manager
[17:05] <didrocks> when will you do a tarball?
[17:05] <m4n1sh> tofay in a few hours
[17:05] <m4n1sh> precise update in progress
[17:05] <didrocks> m4n1sh: oh can wait then! :)
[17:05] <m4n1sh> *today
[17:05] <didrocks> m4n1sh: please send me an email, I'll do it tomorrow morning! :)
[17:05] <m4n1sh> sure..
[17:05] <didrocks> thanks
[17:05] <m4n1sh> didrocks -at- ubuntu- ?
[17:05] <m4n1sh> right?
[17:06] <m4n1sh> anyway I'll get it from LP
[17:06] <didrocks> m4n1sh: yeah ;)
[17:06] <didrocks> the email is right (com)
[17:53] <mpt> mvo, 'Sorry, the package "%s" failed to install or upgrade.' Apart from submitting an error report, is there any advice or suggestion we could offer users after saying that?
[17:54] <ronoc> mvo, can i use the pkclient glib lib for that menuitem
[17:55] <ronoc> mvo, i went to pull in the libpackagekit-dev package
[17:55] <ronoc> inorder to get the docs and headers around that
[17:56] <ronoc> mvo, Sebastian on that bug shows the use of the python bindings seemingly around pkclient
[17:56] <ronoc> i presume i can use the C lib ?
[17:57] <mvo> ronoc: the  c lib should work too, indeed
[17:57] <mvo> ronoc: as it talks to the dbus service that aptdaemon provides
[17:57] <mvo> mpt: unfotauntely not much, removing the package maybe, but even that may fail
[17:57] <ronoc> mvo, cool excellent that should make things easier - thanks
[18:01] <ronoc> mvo, what was weird was that when i went to pull in the dev package it also pulled in package-kit, will that screw with anything
[18:01] <mpt_> mvo, and that error will keep coming up whenever they install or upgrade a package that depends on the failed package?
[18:04] <mvo> mpt_: yes
[18:04] <mvo> ronoc: *ick*
[18:04] <mpt_> hrmm.
[18:06] <ronoc> mvo, ok so i should back it out then
[18:06] <ronoc> mvo, it's kinda confusing as to what package i am to use.
[18:06] <ronoc> its package-kit but it's not package-kit if you get me
[18:07] <mvo> ronoc: this sounds like there are some dependencies in PK that are too strict
[18:07] <ronoc> ok
[18:07] <mvo> ronoc: yeah, its just a compat layer, but I understand that this is confusing :/
[18:07] <ronoc> mvo, no worries - business as usual :)
[18:07] <ronoc> ok ill back it out now
[18:09] <ronoc> mvo, this is the package i installed - libpackagekit-glib2-dev
[18:11] <mvo> ronoc: hm, it should install without the need for the full PK, odd
[18:11] <ronoc> ok i have backed out packagekit and that dev package
[18:14] <ronoc> mvo, http://paste.ubuntu.com/831661/
[18:15] <mvo> ronoc: does apt-get install --no-install-recommends libpackagekit-glib2-dev makes a difference?
[18:16] <ronoc> mvo- yep looks good
[18:17] <ronoc> mvo, http://paste.ubuntu.com/831667/
[18:17] <ronoc> all good ?
[18:17] <mvo> ronoc: yes!
[18:18] <ronoc> mvo, excellent, thanks
[18:21] <mvo> yw
[18:27] <jbicha> mpt: could you take a look at bug 926213 ? thanks
[18:27] <ubot2`> Launchpad bug 926213 in unity "Overlay should refer to "Menu Bar" not "Top Bar"" [Low,Confirmed] https://launchpad.net/bugs/926213
[19:38] <desrt> seb128: hey
[19:38] <seb128> desrt, hey
[19:38] <desrt> any news in the automake saga?
[19:39] <seb128> desrt, no, I got busy with w.e catching up and GNOME 3.3.5 today
[19:39] <seb128> desrt, and I'm sort of waiting for the Debian maintainer to update and see if the new version works or not
[19:39]  * desrt is presently in the middle of tossing a tarball over that particular fence
[19:39] <seb128> desrt, but the ecryptfs confirmed the bug I ran into locally
[19:39] <desrt> seb128: cool
[19:40] <desrt> 4f6ffd386b90e85791164794a66860aa16b7ff988f96105ea5ddc15808c776f5  dconf-0.11.5.tar.xz
[19:40] <desrt> :D
[19:41] <seb128> desrt, ;-)
[19:41] <seb128> desrt, will make didrocks happy
[19:41] <seb128> desrt, he was pondering backporting the fix for the bug you discussed the other day or waiting today
[19:42] <desrt> he works too hard
[19:42] <desrt> he found that bug on like.. friday?
[19:42] <desrt> and he can't delay his work until monday? :p
[19:43] <seb128> desrt, ;-)
[19:43] <seb128> desrt, btw danilo rolled a new intltool which has been uploaded to Ubuntu and Debian today
[19:43] <desrt> i saw that!
[19:44] <desrt> i wonder if he actually fixed the issue properly...
[19:44]  * desrt checks
[19:48] <seb128> desrt, btw while you are there, do you have any clue about charsets? ;-)
[19:48] <desrt> charsets?
[19:49] <seb128> desrt, 	g_message ("bug.vala:1: Est-ce que tes enfants sont de bons élèves? Ça va pour eux?");
[19:49] <seb128> desrt, that prints "?" rather than the non-utf8 chars
[19:49] <seb128> desrt, works if you do CHARSET=UTF-8 bin
[19:50] <desrt> what's your locale?
[19:50] <seb128> fr_FR.UTF-8 but mhr3 who reported it use en_US.UTF-8 and I confirmed on a oneiric livecd
[19:50] <desrt> let me see what happens here
[19:50] <seb128> desrt, mhr3 said
[19:50] <seb128>  <mhr3>	seb128, it will have something to do with g_get_charset returning "ANSI_X3.4-1968" as current charset, no matter how i set LC_ALL etc...
[19:51] <desrt> hum
[19:51] <seb128> desrt, I've looked a bit to it but dropped due to GNOME updates, I just wanted if you had a clue about it
[19:51] <desrt> seb128: you have my curiosity
[19:52] <seb128> desrt, the glib codes parses /usr/share/locale/locale.alias which I'm pretty sure is broken
[19:52] <desrt> seb128: the glib code that does this stuff is insanely magic
[19:52] <seb128> since that file states
[19:52] <seb128> # Note: This file is obsolete and is kept around for the time being for
[19:52] <seb128> # backward compatibility.  Nobody should rely on the names defined here.
[19:52] <seb128> # Locales should always be specified by their full name.
[19:52] <desrt> we have an internal copy of a weirdass library called libcharset
[19:52] <seb128> but I'm not convinced that's the issue
[19:52] <desrt> i'm pretty sure it's not
[19:52] <desrt> i'll look into it
[19:52] <seb128> desrt, ok thanks
[19:52]  * desrt suspects that a little bisecting will go a long way here
[19:53] <seb128> desrt, do you get the issue?
[19:53] <desrt> yup
[19:53] <seb128> great, that's a good start ;-)
[19:53] <seb128> well I tried glib 2.30 on oneiric so it's not a recent issue
[19:53] <desrt> thanks for the datapoint
[19:53] <desrt> maybe i'll just go for the direct approach then
[19:54] <desrt> btw: hit you back for one
[19:54] <desrt> do you know what is the state of the art for getting entries into /etc/resolv.conf (and keeping them there) when using static entries in /etc/network/interfaces?
[19:54] <desrt> 'uninstall resolveconf'?
[19:55] <seb128> cyphermox_, ^
[19:56] <seb128> desrt, I will delegate to our nm maintainer ;-)
[20:03] <desrt> seb128: this looks like a libc bug
[20:03] <seb128> desrt, where is doko? ;-)
[20:04] <desrt> well, hold on
[20:05] <desrt> ya.  pretty sure it's a libc bug...
[20:05] <chrisccoulson> heh
[20:05] <chrisccoulson> i need doko to review an icedtea plugin patch ;)
[20:05] <chrisccoulson> doesn't look like he's around today
[20:05] <desrt> seb128: http://paste.ubuntu.com/831818/
[20:06] <desrt> codeset: ANSI_X3.4-1968
[20:06] <desrt> glib is basically passing that value directly from what the libc tells it
[20:06] <seb128> desrt, indeed, that seems buggy
[20:07] <desrt> oh.  duh.
[20:08] <desrt> seb128: there's no bug here at all
[20:08] <desrt> you simply need to call setlocale (LC_ALL, "");
[20:08] <desrt> otherwise the locale stuff in the libc is never initialised
[20:08] <seb128> oh, doh
[20:08] <seb128> mhr3, ^
[20:08]  * desrt forgot and did NULL, which is not the same as ""
[20:09] <seb128> desrt, thanks for spotting it, I just took mhr3's testcase and overlooked that
[20:09] <desrt> seb128: i basically did the same... setlocale(,NULL); is a no-op :p
[20:19] <ricotz> seb128, the internal dependencies of librsvg really needs some overthinking, like the -dev package should pull -common and -bin
[20:19] <seb128> ricotz, why?
[20:20] <ricotz> -common includes gdk-pixbuf loader
[20:20] <seb128> right, why is that required for builds?
[20:20] <ricotz> which is needed for gnome-themes-standard now
[20:20] <ricotz> to build the gressource file
[20:20] <seb128> then g-t-s should build-depends on it?
[20:21] <ricotz> while it is using the new gdk-pixbuf-pixdata converter
[20:21] <seb128> what component is calling the command which needs the loader?
[20:21] <ricotz> themes is calling the converter with a svg
[20:23] <ricotz> but if one installs the -dev package of rsvg it seems reasonable to pull the loader since librsvg itself already depends on libgdk-pixbuf
[20:23] <ricotz> loader > -common
[20:23] <seb128> yeah, I'm fine making the dev depends on the bin
[20:23] <seb128> ups common
[20:23] <seb128> why do you need -bin?
[20:24] <ricotz> just to pull in everything
[20:24] <mhr3> desrt, seb128, but this wasn't needed in previous versions of glib iirc
[20:24] <seb128> mhr3, I would be surprised if it wasn't
[20:24] <ricotz> like libglib-dev pulls its -bin or g-i too
[20:25] <seb128> ricotz, ok, works for me
[20:25] <seb128> ricotz, I will do that
[20:25] <ricotz> thanks
[20:25] <seb128> mhr3, desrt: though I agree it seems buggy,    g_message ("Est-ce que tes enfants sont de bons élèves? Ça va pour eux?"); should display fine whatever the local is
[20:26] <seb128> it's standard utf-8 and we should default to utf-8
[20:54] <seb128> RainCT, there?
[20:54] <RainCT> seb128: yeah
[20:55] <seb128> RainCT, unping, I guess you did you gtk2 patch against 2.24.8? I'm updating to 2.24.10 and your patch doesn't apply but I guess that's because you include http://git.gnome.org/browse/gtk+/commit/gtk/gtkrecentmanager.c?h=gtk-2-24&id=400e53c568be2270d9bd3e19cc76957032959085
[20:56] <RainCT> seb128: yeah
[20:56] <seb128> RainCT, yeah, that's it, I sorted it ;-)
[20:56] <RainCT> ok, cool
[21:09] <desrt> seb128: i disagree
[21:09] <desrt> seb128: the libc is in ascii-only mode until you call setlocale()
[21:10] <desrt> we only know that we are using utf8 because of the LANG environment variable.... and the libc doesn't look at that until setlocale()
[21:10] <seb128> desrt, well I think glib should default to be utf8
[21:10] <desrt> seb128: we ask the libc "what is your output locale?"
[21:10] <desrt> and it says "ascii"
[21:10] <seb128> it's a bit of a stupid situation
[21:11] <seb128> you shouldn't have to set a locale to be able to print utf8 chars
[21:11] <desrt> i think it's a bit dumb that you have to call setlocale() in order to get the obviously-correct behaviour
[21:11] <desrt> but given that's how it works... i really don't think glib should attempt to hack around that
[21:11] <desrt> the only thing you may argue is that we should call setlocale() ourselves from inside of glib
[21:12] <seb128> glib should call setlocale() for you ;-)
[21:12] <seb128> yeah
[21:12] <desrt> and indeed, you argue that :)
[21:12] <seb128> :p
[21:12] <desrt> well
[21:12] <seb128> you know me well ;-)
[21:12] <desrt> i thought that we could do some stuff from gtkapplication
[21:12] <desrt> because every program you see does these 3 lines about setting and binding the gettext domain and setting up the loclae
[21:13] <seb128> right
[21:13] <seb128> out of some programs written by english speakers who don't notice they forgot those until a non english user try to use their software ;-)
[21:14] <desrt> like dconf-editor ;)
[21:14] <seb128> but yeah, it seems like one of those things most people copy around like autotools :p
[21:14] <seb128> especially you never know if you need to call setlocale() or bindtextdomain() or both and what they are needed for
[21:15] <seb128> that's the sort of stuff that should just be handled for you in normal applications
[21:15] <seb128> i.e gtkapplication could do it for you
[21:16] <desrt> do not disagree.
[21:16] <desrt> but it does not presently do so
[21:16] <desrt> so sucks to be you :)
[21:16] <seb128> desrt, k, fair enough ;-)
[21:20] <desrt> seb128: you have me investigating possibilities now :)
[21:20] <seb128> desrt, good! ;-)
[21:20] <kenvandine> desrt, sweet :)
[21:23]  * desrt ponders using application_id as gettext domain
[21:23]  * desrt wonders if that would work
[22:01] <seb128> kenvandine, hey
[22:02] <seb128> kenvandine, want to do the vala stable serie update when you will have a free slot? ;-)
[22:02] <pitti> kenvandine: btw, for disk space/feature planning, is it still realistic to have a gwibber in precise that uses gir and webkit-gtk3_
[22:02] <pitti> _
[22:02] <pitti> erk
[22:02] <pitti> ?
[22:03] <pitti> (accidentally switched keyboard layout)
[22:03] <kenvandine> hehe
[22:03] <kenvandine> seb128, sure
[22:03] <seb128> kenvandine, thanks ;-)
[22:03] <kenvandine> pitti, perhaps
[22:04] <kenvandine> pitti, we hit some gir issues in the keyring gir, dobey was going to look at it some more
[22:04] <kenvandine> dobey, have you had a chance?
[22:04] <seb128> kenvandine, pitti: is the u1 control panel going to switch to the qt version this cycle?
[22:04] <pitti> kenvandine: oh, haven't heard of hem
[22:04] <pitti> seb128: I dunno
[22:04] <dobey> kenvandine: sadly, i haven't. tomorrow for sure.
[22:05] <dobey> seb128: that was the plan
[22:05] <seb128> pitti, btw since you are still aorund there are a few updates to do in Debian on the etherpad if you have a free slot one of those days
[22:05] <kenvandine> dobey, cool
[22:05] <seb128> pitti, they are mostly easy one, libcroco, pango, shared-mime-info
[22:06] <pitti> seb128: added to my TODO
[22:06] <pitti> TB meeting is over, that means bedtime
[22:06] <pitti> see you all tomorrow!
[22:06] <seb128> pitti, danke
[22:06] <seb128> pitti, 'night
[22:11] <micahg> seb128: anyone working on gimp 2.6.12?
[22:11] <seb128> micahg: not that I know about, nobody active in the team in any case
[22:11] <micahg> ok
[22:33] <tjaalton> should libs using libglade be multiarchified? seems like libglade doesn't find libgnome.so, which breaks gnucash
[22:33] <tjaalton> bug 922514
[22:33] <ubot2> Launchpad bug 922514 in gnucash "<libglade> libgnome.so: cannot open shared object file" [Undecided,Confirmed] https://launchpad.net/bugs/922514
[22:39] <tjaalton> linking /usr/lib/<triplet>/libglade -> /usr/lib/libglade fixes that, so sounds like yes
[22:52] <TheMuso> jbicha: Re bug 927801, have you had working audio on this machine before? If so, when?
[22:52] <ubot2> Launchpad bug 927801 in alsa-driver "[, Realtek ALC662 rev1, Green Line Out, Rear] No sound at all" [Undecided,New] https://launchpad.net/bugs/927801
[23:42] <cyphermox_> TheMuso: hey
[23:43] <cyphermox_> on a similar note to jbicha's bug -- any idea what would cause pulseaudio to stop listing one of the cards? my desktop's main card  (HDA Intel of some sort) is listed in alsa but never shows up in pulse. no errors that I noticed anywhere, but I'll re-check
[23:48] <TheMuso> cyphermox_: First thing that comes to mind is that something is grabbing the card before pulse does...
[23:49] <TheMuso> Grrr this hud is pissing me off..
[23:49] <cyphermox_> hud?
[23:50] <TheMuso> I have to remember to hold alt down for longer than I would normally.
[23:50] <jbicha> TheMuso: actually, this week's the first I played with it and I immediately upgraded to Precise
[23:50] <cyphermox_> I didn't ever manager to make this work :)
[23:50] <TheMuso> jbicha: ah ok, I've left a comment in the bug.
[23:50] <TheMuso> cyphermox_: I am running unity trunk.
[23:50] <cyphermox_> right
[23:50] <TheMuso> cyphermox_: The appmenu parts haven't landed yet, but the hud UI is in unity trunk/.
[23:50] <cyphermox_> but I thought +archive/hud would have done the same too
[23:51] <TheMuso> Well the unity side for the hud stuff has landed.
[23:51] <cyphermox_> ah
[23:52] <cyphermox_> bah
[23:52] <cyphermox_> I already got enough of that scrolling into the left side of the screen to make the launcher pop up to worry about :)


[06:08] <knome> i don't read xubuntu-devel daily so...
[06:09] <knome> re: mail 4 days ago, xubuntu.org got hacked again?
[06:09] <knome> what's up canonical IS :(
[06:09] <knome> apparently the 12's were related?
[06:09] <knome> Tinkery, Unit193, he's been around in discord now and then
[06:10] <knome> Tinkery, https://discord.gg/AW5beSa for shimmer-related stuff if you don't mind discord
[11:28] -SwissBot:#xubuntu-devel- ::platform:: Make both iptables and nftables optional @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=a2ab4c2edcf4addf82b88ac0f7312c4e2e7bba00 (by Alex Murray)
[11:28] -SwissBot:#xubuntu-devel- ::platform:: Make nftables non-optional @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=3502dd6466e16b294c68bc450a2e6bfdbe995cae (by Alex Murray)
[11:28] -SwissBot:#xubuntu-devel- ::platform:: Merge remote-tracking branch 'alexmurray/promote-nftables-lp1887187' into jammy @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=abf5f361b93b095ee3164e20f762b4da64c71f9b (by Dimitri John Ledkov)
[12:37] <ochosi> Tinkery: hiya! I'm always happy for support with maintaining greybird. I don't have a lot of time to maintain it at the moment
[12:38] <ochosi> Tinkery: I recently merged a - still rather experimental - branch with libhandy and Gtk4 support, would be great if someone could look at that and tweak it where necessary that'd be much appreciated
[20:28] -SwissBot:#xubuntu-devel- ::platform:: Fix a typo in the explanatory text @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=13cbce14fe010f636823a82dda7edad9665e8c97 (by Steve Langasek)


[15:10] <GlenDavis[m]> And I'm back! ...As per yesterday's inquiry, I recently replaced the motherboard on my Thinkpad T430s and now my firewire device is no longer being recognized (a Mackie Onyx 1620i). I've since updated to Ubuntu Studio 22.04, but still no recognition in Studio Controls (the Mackie would normally just show up under the "Jack Master Device" dialog)... again, any advice would be greatly appreciated
[15:15] <Eickmeyer[m]> !ubuntustudio-backports | Glen Davis Add this PPA and upgrade everything to get the latest version of Studio Controls (and a bunch of other goodies). Your firewire device might require FFADO as opposed to ALSA.
[15:19] <GlenDavis[m]> Right on, I'll try that out thanks
[15:31] <GlenDavis[m]> Okay, I've added the PPA... still no recognition, even when I change the "Firewire module select" dialogue to FFADO instead of ALSA ... something else I've noticed is when I open FFADO mixer it has the following message: "logginghandler: Could not communicate with the FFADO DBus service..."
[15:43] <Eickmeyer[m]> Changing to FFADO requires a reboot
[15:52] <GlenDavis[m]> Yes, rebooted, still no device recognition
[15:55] <GlenDavis[m]> Also, JACK refuses to start when I change JACK backend from ALSA to firewire... if that indicates anything
[16:16] <Eickmeyer[m]> This is outside my expertise as I have no firewire devices.
[16:16] <Eickmeyer[m]> OvenWerks: Any ideas?
[16:33] <GlenDavis[m]> Appreciate the help... I'll keep this chat open and see what OvenWerks has to add
[22:17] <OvenWerks> The firewire port if on the MB?
[22:18] <OvenWerks> GlenDavis[m]: ls /dev/fw* should at least show /dev/fw0
[22:19] <OvenWerks> if the fw port is on a pcie board it may not be seated. If it is on the MB maybe check in the bios that it is enoabled
[22:21] <OvenWerks> If you were using the alsa stack before, it should still work. and so that would lead me to believe there is either a hardware problem of the bios (firmware) has it disabled.
[22:22] <OvenWerks> also check for the firewire modules with lsmod. You should find two of them: firewire_ohci and firewire_core
[22:24] <OvenWerks> /dev/fw0 is the firewire port on your computer and /dev/fw1 would be the audio device


[01:21] <jose> guys, is it possible to use Juju with Rackspace?
[01:23] <davecheney> jose: yes
[01:23] <jose> davecheney: where should I put the info? on the openstack part of the config
[01:23] <jose> ?
[01:24] <davecheney> depends, if rackspace looks close enough to openstack then you could try the openstack provider
[01:24] <davecheney> or you could use the ssh provider and manually provision some machines for your environment
[01:24] <jose> oh, I meant to use Rackspace automagically like it's done with AWS or HPCloud, for example
[01:38] <thumper> jose: if rackspace offers the same api endpoints as the openstack provider wants, then yes
[01:38] <thumper> jose: if it doesn't, then no
[01:38] <thumper> for using the openstack provider
[01:38] <jose> I'm not exactly sure, that's why I was asking :)
[01:38] <jose> I'll check, though
[01:38] <thumper> I'm not sure if any of the core devs have tried
[01:38] <thumper> I certainly haven't
[01:47] <lazyPower> jose: you need to use the manual provider. Rackspace doesn't have an object store.
[01:47] <jose> ack, thanks
[01:50] <thumper> lazyPower: ah.. if that is all, hopefully soonish... we will be able to
[01:51] <lazyPower> thumper: thats teh only thing off the top of my head - i dont know about their API endpoitns
[02:15] <rick_h_> thumper: lazyPower for the longest time they didn't have cloud-init enabled on the OS images and such.
[02:15] <rick_h_> thumper: lazyPower that's changed in the last few months
[02:16] <rick_h_> jose: but I use the manual provide and works well if a bit more manual than hoped
[02:16] <jose> cool, thanks rick_h_
[03:45] <AskUbuntu> MAAS and Openstack Network | http://askubuntu.com/q/482090
[04:11] <AskUbuntu> Add Nodes to MAAS for JUJU Bundle | http://askubuntu.com/q/482094
[04:49] <AskUbuntu> Where to see the complete list of juju charms available? | http://askubuntu.com/q/482103
[11:06] <sparkiegeek> is there a "preferred" way of including trademark/copyright information in a charm? specifically with regards the charm logo.
[11:24] <rbasak> jamespage: ping. Can we talk about this Trusty SRU when you have some time please?
[11:27] <jamespage> rbasak, sure - let me just eat lunch and I'll be back
[11:27] <rbasak> OK
[12:11] <pindonga> hi, while I thought I managed to fix this... I'm still having issues with the local provider: when I deploy some instances (eg, wordpress/mysql) the are kept in the pending state for a long time, and then they failed due to the template taking too long and then the second machine failing bc it couldn't clone a running template
[12:12] <pindonga> I managed to work around this by destroying the environment and starting over (now that the template is finally complete)
[12:12] <pindonga> but I thought it worth to mention
[12:24] <jamespage> rbasak, back
[12:24] <rbasak> o/
[12:25] <rbasak> jamespage: so I need to land this 1.18.4, which has ~20 bugs fixed. Trusty is on 1.18.0 at the moment.
[12:25] <rbasak> This is something that I'd want an MRE for.  I'm not sure all of them are individually SRU-worthy either.
[12:26] <rbasak> Or, any other guidance on how to proceed?
[12:26] <rbasak> Oh Trusty is on 1.18.1 I think, sorry.
[12:26] <rbasak> Still, it's a fairly big bump in terms of commits.
[12:28] <jamespage> rbasak, I agree that we need a MRE but this was pretty much nacked by pitti when I applied for it
[12:28] <jamespage> rbasak, I'd email off that thread about what we need todo now and ask again
[12:28] <jamespage> we can have a list of things that have been fixed
[12:28]  * rbasak looks
[12:29] <rbasak> Ah, I see it
[12:29] <rbasak> https://lists.ubuntu.com/archives/technical-board/2014-April/001877.html
[12:31] <rbasak> jamespage: OK, thanks. I'll prepare the tracker bug and reply to https://lists.ubuntu.com/archives/technical-board/2014-April/001924.html I think.
[14:06] <lazyPower> sparkiegeek: wrt you copyright/trademark question - yes. You can place that info in the Copyright file
[14:06] <lazyPower> there's a specific directive that marcoceppi showcased yesterday in his charm development track that shows how he denotes multiple levels of copyrighted material being included in a charm.
[14:07] <sparkiegeek> lazyPower: ok, great. Thanks
[14:56] <marcoceppi> arosales: yeah
[16:59] <Egoist> hey
[16:59] <Egoist> is there any way to pass data between instances but not by relation-set?
[17:05] <marcoceppi> Egoist: no
[17:07] <Egoist> marcoceppi: ok. But data is taken from config.yaml, is ther any way to change this file while charm is running?
[17:08] <marcoceppi> Egoist: no, you can only change configuration values from the user
[17:09] <marcoceppi> charms can't change their own or others
[17:10] <ali1234> I tried to follow http://askubuntu.com/questions/65359/how-do-i-configure-juju-for-local-usage and i got "error bootstrapping a local environment must not be done as root"
[17:10] <lazyPower> ali1234: which version of juju are you using?
[17:11] <ali1234> the version in 14.04
[17:11] <lazyPower> ali1234: that looks like your Ubuntu series. can you show me the output of juju --version
[17:11] <ali1234> yes, it is my ubuntu series. i am using the version which ships with ubuntu 14.04
[17:12] <ali1234> 1.18.1-trusty-amd64
[17:12] <lazyPower> do you have the juju-local package installed? it should have prompted you for sudo rights during the bootstrap
[17:12] <ali1234> yes
[17:12] <ali1234> i followed the instructions on askubuntu exactly
[17:13] <ali1234> it did prompt for sudo password
[17:14] <ali1234> http://paste.ubuntu.com/7634650/
[17:15] <ali1234> when i try to run it without sudo like it tells me to, it says this: http://paste.ubuntu.com/7634653/
[17:15] <sarnold> yikes
[17:16] <sarnold> check dmesg output for anything 'strange'. that's mighty odd looking...
[17:16] <ali1234> http://paste.ubuntu.com/7634668/
[17:17] <sarnold> all looks normal there
[17:30] <leftyfb> I'm trying to setup a juju local provider on my laptop here but can't seem to get it working. juju init works fine, I edit the config and change default to local, then juju bootstrap.....
[17:30] <leftyfb> juju status gives me this:
[17:30] <leftyfb> ERROR state/api: websocket.Dial wss://<IP_ADDRESS>:17070/: dial tcp <IP_ADDRESS>:17070: connection refused
[17:30] <leftyfb> mongodb is in fact running on 37017
[17:30] <leftyfb> there's no iptables rules in play
[17:31] <leftyfb> it doesn't seem like juju is creating the lxc container when bootstrapping
[17:31] <leftyfb> also seeing this in debug:
[17:31] <leftyfb> 2014-06-12 15:56:04 DEBUG juju.environs.simplestreams simplestreams.go:388 fetchData failed for "file:///home/leftyfb/.juju/local/storage/tools/streams/v1/index.sjson": stat /home/leftyfb/.juju/local/storage/tools/streams/v1/index.sjson: no such file or directory
[17:35] <Egoist> marcoceppi: change configuration values from the user -> What does it mean?
[17:35] <leftyfb> also seeing this in /var/log/machine-0.log
[17:35] <leftyfb> 2014-06-12 16:54:39 DEBUG juju.agent agent.go:384 read agent config, format "1.18"
[17:35] <leftyfb> 2014-06-12 16:54:39 ERROR juju.cmd supercommand.go:305 symlink /home/leftyfb/.juju/local/tools/machine-0/jujud /usr/local/bin/juju-run: no such file or directory
[17:37] <lazyPower> Egoist: meaning that only users can change the values defined by config.yaml
[17:37] <Egoist> lazyPower: Ok i get it. Thanks
[17:38] <lazyPower> leftyfb: looks like you're missing the simpestreams stuff that bootstrap should be fetching for you. is there a cached cloud image  in /var/cache/lxc for cloud-trusty / cloud-precise?
[17:38] <lazyPower> ali1234: i'm sorry i dont know why its throwing a stack trace at you. thats a great candidate for a bug http://launchpad.net/juju-local
[17:39] <leftyfb> lazyPower: /var/cache/lxc/trusty/rootfs-amd64 exists with what looks like a complete filesystem
[17:39] <lazyPower> leftyfb: it should be creating cloud-trusty and cloud-precise iirc
[17:40] <lazyPower> the cloud-* are the cloud images that juju uses to create your containers. It may be prudent to 'nuke from orbit' your in progress components to build the lxc containers and start over. There's a plugin at http://github.com/juju/juju-plugins that warehouse this utility and has installation instructions - its 'juju clean'
[17:41] <lazyPower> I've got to get ready for my UOS track however, good luck. I'll stop in to check on you once my session is over
[17:47] <ali1234> launchpad is kaput :(
[17:48] <leftyfb> lazyPower: that script/plugin only does 3 steps(and not sufficiently) that i've been doing over and over again trying to debug this issue.
[17:50] <sarnold> ali1234: sorry, lazyPower had the wrong url, use this one: https://bugs.launchpad.net/ubuntu/+source/juju-core/+filebug
[17:50] <lazyPower> leftyfb: https://github.com/marcoceppi/plugins/commit/1c315f40fcc6e3102b4be5a4aa11544218159fd0
[17:50] <ali1234> sarnold: i did not use the url, i used ubuntu-bug
[17:50] <ali1234> launchpad timed out while i tried to submit the report
[17:50] <sarnold> ali1234: eep.
[17:51] <marcoceppi> lazyPower: can you review/merge that?
[17:51] <ali1234> i will just do it again
[17:51] <lazyPower> marcoceppi: i'd love to but i cant merge, i can only comment.
[17:51] <marcoceppi> what, why not? Aren't you in the juju group?
[17:52] <lazyPower> WAIT
[17:52] <lazyPower> i was looking at your repo, whoops
[17:52] <marcoceppi> w/e cowboy'd it
[17:52] <lazyPower> neat
[17:53] <ali1234> cool, now i crashed apport
[17:56] <leftyfb> lazyPower: is this a typo somewhere? :
[17:56] <leftyfb> 2014-06-12 17:55:49 DEBUG juju.environs.simplestreams simplestreams.go:362 cannot load index "file:///home/leftyfb/.juju/local/storage/tools/streams/v1/index.sjson": invalid URL "file:///home/leftyfb/.juju/local/storage/tools/streams/v1/index.sjson" not found
[17:56] <leftyfb> should it be index.json , not index.sjson?
[17:57] <marcoceppi> leftyfb: it checks for both
[17:57] <leftyfb> so it does
[17:57] <leftyfb> 2014-06-12 17:55:49 DEBUG juju.environs.simplestreams simplestreams.go:388 fetchData failed for "file:///home/leftyfb/.juju/local/storage/tools/streams/v1/index.json": stat /home/leftyfb/.juju/local/storage/tools/streams/v1/index.json: no such file or directory
[17:57] <leftyfb> #leftyfb@blanchard[0]:~$ ls -l .juju/local/storage/tools/streams/v1/index.json
[17:57] <leftyfb> -rw------- 1 leftyfb leftyfb 1152 Jun 12 13:55 .juju/local/storage/tools/streams/v1/index.json
[17:58] <leftyfb> nm, looks like it writes it further down
[17:59] <leftyfb> https://pastebin.canonical.com/111613/
[18:24] <sebas5384> there's a way to select a node(machine) from maas, when deploying a service?
[18:25] <sebas5384> i'm planning to have different constraints in each node, so I would like to choose which one is going to be used
[18:25] <leftyfb> sebas5384: juju deploy mysql --to 3
[18:25] <sebas5384> leftyfb: yeah, but thats when the machine is already mapped by the juju
[18:26] <leftyfb> you can also use constraints
[18:26] <leftyfb> https://juju.ubuntu.com/docs/reference-constraints.html
[18:29] <sebas5384> leftyfb: thanks!!
[18:29] <sebas5384> that was exactly what i was looking for
[18:30] <sebas5384> maas-name and maas-tags will be the solution
[18:30] <sarnold> sebas5384: why do you want to select one specific node rather than just using e.g. cpu and memory constraints?
[18:31] <sebas5384> sarnold: because my client is going to provide the servers vms
[18:31] <sebas5384> the first battle was to implement juju and maybe maas
[18:32] <sebas5384> sarnold: IaaS is still going to be another battle for me
[18:32] <sebas5384> hehe
[18:32] <sarnold> sebas5384: ahh, okay. :) I've just been happy to say "I want a big machine" or "I want a small machine" when deploying services in our cloud
[18:32] <sebas5384> juju > maas > node > X vmware vm
[18:32] <sarnold> sebas5384: not knowing or caring how it happens is part of what I like :)
[18:32] <jcastro> marcoceppi, how long is `juju clean local` supposed to take?
[18:33] <marcoceppi> jcastro: 2-3 mins
[18:33] <jcastro> ack
[18:33] <marcoceppi> at most
[18:33] <leftyfb> jcastro: I've found if it's taking long, it's due to permissions on ~/juju
[18:33] <sebas5384> yeah sarnold! thats going to happen some day
[18:33] <leftyfb> er, ~/.juju
[18:33] <jcastro> does it log anywhere?
[18:33] <sebas5384> but first i have to prove some concepts, it's a big and political company
[18:33] <leftyfb> jcastro: nope, hit CTRL+C and you'll see the errors
[18:34] <jcastro> yep, correct!
[18:34] <leftyfb> marcoceppi: the script should use sudo or chown before trying to delete ~/.juju
[18:34] <sebas5384> juju clean ?
[18:34] <sebas5384> thats a new command?
[18:34] <marcoceppi> leftyfb: it uses sudo when it needs to
[18:34] <jcastro> is sudo juju clean a good idea?
[18:34] <marcoceppi> jcastro: no
[18:34] <leftyfb> marcoceppi: when deleting ~/.juju, it needs to
[18:35] <jcastro> I never got prompted to put in a sudo pw
[18:35] <marcoceppi> leftyfb: bugs and pull requests welcome
[18:35] <jcastro> but with the local provider .juju/local is owned by root
[18:35] <marcoceppi> jcastro: it shouldn't be anymore
[18:36] <jcastro> k, your example command is wrong too, I'll submit a PR for that tonight
[18:37] <leftyfb> i'm having bad luck with juju all around
[18:38] <leftyfb> my laptop won't bootstrap, and I just installed juju-local on the maas server in our lab here and it's stuck pending for juju-gui on machine 1 which says it's precise, even though the server is trusty.
[18:39] <leftyfb> also, according to jcastro's session the other day, using juju quickstart should put juju-gui onto machine 0 along with the bootstrap. That's not happening on the maas server
[18:40] <sebas5384> ooh!! https://github.com/juju/plugins/blob/master/juju-clean
[18:41] <lazyPower> sebas5384: you got an honorable mention in my UOS track
[18:41] <sebas5384> ooh yeah?? \o/
[18:41] <lazyPower> leftyfb: have you specified a default-series in your ~/.juju/environments.yaml?
[18:41] <lazyPower> sebas5384: yeah - wrt the vagrant plugin we'll be working on
[18:42] <sebas5384> lazyPower: \o/
[18:42] <sebas5384> great!
[18:42] <lazyPower> I feel like my track was meh, but in retrospect i'm feeling pretty beat up this week. Looking forward to recharging over the weekend.
[18:42] <lazyPower> get some Vitamin D, it wont be all rainy and blah outside
[18:42] <leftyfb> lazyPower: I didn't do so on the maas server ... to be honest I only installed juju on there to confirm that something was wrong with the setup on my laptop(confirmed)
[18:42] <sebas5384> lazyPower: i know that feeling ¬¬
[18:43] <jcastro> https://bugs.launchpad.net/juju-core/+bug/1329425
[18:43] <_mup_> Bug #1329425: Fatal out of memory error when bootstrapping on Azure <juju-core:New> <https://launchpad.net/bugs/1329425>
[18:43] <jcastro> anyone see this before?
[18:43] <lazyPower> leftyfb: ok. That should correct the container series you see - but also during bootstrap its downloading a 200mb cloud image file - so it takes a couple of minutes to complete the first time. but i'm pretty sure you're aware of this since we checked /var/cache/lxc
[18:43] <lazyPower> leftyfb: where are you in terms of debug/nuking/retrying?
[18:44] <leftyfb> lazyPower: i've nuked several times ... give me a few to move out of the lab and go nuke again and start over
[18:44] <lazyPower> ack. ping when ready
[18:44] <lazyPower> sebas5384: so, now that its been phaux announced, we need to hammer out a time to do that sync we've been pending
[18:45] <sebas5384> yeah lazyPower absolutely!
[18:46] <leftyfb> lazyPower: my nuke involves much more hulk :)
[18:46] <lazyPower> leftyfb: oh man, sounds serious
[18:47] <sebas5384> lazyPower: what about 5pm EDT ?
[18:47] <sebas5384> friday
[18:49] <lazyPower> sebas5384: sure.  I just filed it
[18:58] <sinzui> You should have searched
[18:58] <sinzui> it us the first bug in the azure-provider listing, bug 1250007
[18:58] <_mup_> Bug #1250007: Bootstrapping azure causes memory to fill <amd64> <apport-bug> <azure-provider> <saucy> <juju-core:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1250007>
[19:00] <sinzui> jcastro, Did you use the cer instead of the pem?
[19:01] <sinzui> This confusion also affects users of the python-sdk. MS is not very clear about what they expect
[19:01] <jcastro> oh, I was using the .cer, fixing and trying with the pem
[19:02] <jcastro> sinzui, that was it, I'll update the bug, it's bootstrapping fine, thanks!
[19:03] <jcastro> sinzui, I will update the docs as frankban recommends in the master bug
[19:03] <sinzui> jcastro, I learned that today, BTW. I just wrote a script to clean up the 10 terabytes of CI tests data juju left behind. I read a lot of support pages to learn that secret
[19:04] <sebas5384> hey lazyPower i watch your session! thanks for the mention! hehe
[19:05]  * lazyPower hides
[19:06] <sebas5384> was a great session lazyPower o/
[19:06] <sebas5384> sorry that i missed hehe
[19:09] <lazyPower> I did however, do something productive - i fixed a bug in the docs - https://github.com/juju/docs/pull/120
[19:10] <sebas5384> good one! that one was wrong since its there
[19:10] <sebas5384> xD
[19:10] <jcastro> sinzui, mirrors on azure sick? http://pastebin.ubuntu.com/7635108/
[19:16] <lazyPower> jcastro: oh! also - all is well with running bootstraps in paralell
[19:19] <d_`> is there a way to install juju server on a server of my choosing instead of a random server of juju's choosing?
[19:22] <jose> d_`: is this OpenStack, AWS, HPCloud, what?
[19:25] <sebas5384> juju upgrade-charm of a local charm is giving me an error, saying that it can't find the charm
[19:25] <sebas5384> what can be?
[19:25] <lazyPower> sebas5384: did you specify --repository path on the juju upgrade-charm command?
[19:26] <sebas5384> hmmm
[19:26] <sebas5384> lazyPower: no ¬¬
[19:26] <lazyPower> eg: juju upgrade-charm --repository=$HOME/charms myawesomecharm
[19:26] <lazyPower> sebas5384: i have a set of shell aliases when working with local repositories, because thats cumbersome to type
[19:26] <sebas5384> ahhh ok, i thought that was automatic
[19:26] <lazyPower> https://github.com/chuckbutler/dotfiles/blob/master/bashaliases  <- sebas5384
[19:27] <sebas5384> giving a look at lazyPower
[19:27] <lazyPower> oh hey look at that relic jrecycle in there...
[19:27]  * lazyPower updates
[19:27] <jcastro> lazyPower, mine was a config issue, filed some bugs, all set now
[19:27] <jcastro> other than getting an error with the mirrors
[19:27] <jcastro> going to wait a few minutes and try again
[19:27] <lazyPower> ahhhh hokay
[19:27] <lazyPower> boooo on mirrors being wonky
[19:27] <d_`> jose: I'm using MAAS and it's just choosing a random physical server to install on
[19:28] <d_`> we have vmware here as well
[19:28] <sebas5384> lazyPower: nice, something like the juju clean plugin
[19:28] <jcastro> he wants to specify where to deploy the bootstrap node it sounds like
[19:28] <sebas5384> i'm using Makefile for that hehe
[19:29] <sebas5384> could it be nice to have something like declaring repositories
[19:29] <sebas5384> or adding
[19:30] <sebas5384> for example in the environments.yaml file
[19:30] <sebas5384> repositories:
[19:30] <lazyPower> sebas5384: file a feature request
[19:30] <sebas5384> lazyPower: will do that :)
[19:48] <leftyfb> lazyPower: https://pastebin.canonical.com/111624/
[19:51] <sebas5384> Declaring repositories in the environments.yaml -> https://github.com/juju/juju/issues/87
[19:54] <lazyPower> leftyfb: thats really strange
[19:57] <leftyfb> lazyPower: you mean it's not broken by design? :)
[19:58] <lazyPower> leftyfb: i'm not sure what to mention here, as that issue is consistent with what the juju-clean script has thus far corrected.
[19:59] <lazyPower> but its progress now that its not complaining about simple-streams data
[20:00] <leftyfb> 2014-06-12 19:41:57 DEBUG juju.environs.simplestreams simplestreams.go:490 fetchData failed for "file:///home/leftyfb/.juju/local/storage/tools/streams/v1/mirrors.json": stat /home/leftyfb/.juju/local/storage/tools/streams/v1/mirrors.json: no such file or directory
[20:00] <leftyfb> 2014-06-12 19:41:57 DEBUG juju.environs.simplestreams simplestreams.go:567 no mirror index file found
[20:00] <leftyfb> 2014-06-12 19:41:57 DEBUG juju.environs.simplestreams simplestreams.go:548 no mirror information available for { }: mirror data for "com.ubuntu.juju:released:tools" not found
[20:00] <lazyPower> i stand corrected
[20:00] <lazyPower> i really dont know :(
[20:01] <lazyPower> leftyfb: have you pinged in #juju-dev to see if they know of any current issues similar to what you're seeing?
[20:01] <leftyfb> nope
[20:01] <lazyPower> That would be my next step, is to open a bug against this and ping with that in #juju-dev
[20:14] <mattrae_> i'm in an environment with limited internet access. when i deploy --to lxc:1, i see there is is a wget process trying to access cloud-images.ubuntu.com.. is there a right way to get around this problem in a closed environment?
[20:15] <mattrae_> here's the wget i see running http://pastebin.com/72q2BWsC
[20:15] <mattrae_> can i specify an internal location for the images perhaps?
[21:00] <marcoceppi> hazmat: have you tried the docean plugin on Mac OSX?
[21:06] <leftyfb> lazyPower: fixed it
[21:26] <thumper> do we have a collective noun for "juju environments" ?
[21:26]  * thumper was thinking "a collective of environments"
[21:26] <thumper> but perhaps that is too borg
[21:26] <marcoceppi> thumper: environments?
[21:27] <thumper> marcoceppi: that isn't a collective noun
[21:27] <thumper> think "a murder of crows"
[21:27] <thumper> "a horde of hamsters"
[21:27] <marcoceppi> a bushel of environments
[21:27] <thumper> heh
[21:27] <marcoceppi> a gaggle of environments
[21:28]  * thumper briefly thought "group"
[21:28] <thumper> but group has other meanings
[21:29] <thumper> a plethora of environments
[21:29] <thumper> a plague of environments...
[21:29] <marcoceppi> thumper: cull?
[21:29] <thumper> "a host of environments"?
[21:29] <thumper> hmm...
[21:30] <thumper> I'm trying to avoid overloaded terms...
[21:30] <thumper> so trying not to have a collective noun that relates to other well known terms
[21:30] <marcoceppi> you could call it a charm of environments
[21:30] <thumper> so I guess avoiding: host, group, insert-other-techy-term
[21:30] <thumper> that overloads the term "charm"
[21:30] <thumper> which I'm trying to avoid
[21:30] <marcoceppi> I know <3
[21:30] <thumper> :)
[21:31] <lazyPower> leftyfb: nice! what was teh fix?
[21:31] <thumper> what about "an illusion of environments"
[21:31] <thumper> apparently it is "an illusion of magicians"
[21:31] <leftyfb> https://bugs.launchpad.net/juju-core/+bug/1329480
[21:31] <_mup_> Bug #1329480: Cannot create juju-run symlink if /usr/local/bin doesn't exist <juju-core:New> <https://launchpad.net/bugs/1329480>
[21:31] <marcoceppi> thumper: howa bout "a lot of environments"
[21:31] <marcoceppi> or, better yet, alot
[21:31] <marcoceppi> just make up our own
[21:32] <lazyPower> leftyfb: interesting... i would have assumed /usr/local/bin would just exist.
[21:32] <leftyfb> devs should never assume :)
[21:32] <thumper> marcoceppi: how about "an ensemble of environments"
[21:32] <lazyPower> A Quafffel of Environments
[21:32] <thumper> leftyfb: I assumed /usr/local/bin existed
[21:32]  * thumper thinks ensemble is cute
[21:32] <lazyPower> thumper: i see whatchya did there
[21:33] <thumper> and a nod to pre-juju
[21:33] <thumper> done
[21:33] <thumper> ensemble of environments it is
[21:33] <thumper> add it to the docs!
[21:33] <thumper> it's official
[21:37] <leftyfb> is it possible using juju-gui to install to a specific container?
[21:38] <cory_fu> Is there a way to ask juju for the public IP address instead of the public-address name?
[21:39] <lazyPower> cory_fu: which provider?
[21:40] <cory_fu> I mean a general way for a charm to get the public IP as opposed to the public address
[21:41] <lazyPower> cory_fu: depending on the substrate, some respodn with just teh ip. other's i've had to run through dig +short to get the proper IP
[21:41] <cory_fu> Ok, that's what the charm is doing currently; I was just hoping there was a better way
[21:41] <lazyPower> there's an open bug on this somewhere - i'm pretty sure matt williams opened one during our sync on the DNS charm
[21:42] <leftyfb> it seems when you deploy services and then destroy them, juju-gui will leave those containers running and spin up new containers when deploying new services
[21:42] <lazyPower> leftyfb: thats correct. by design juju will not destroy the machine after the service has been destroyed.
[21:43] <leftyfb> lazyPower: and no way to re-utilize that machine for future deployments using juju-gui?
[21:43] <lazyPower> leftyfb: not using the gui, no
[21:43] <leftyfb> bug worthy?
[21:44] <lazyPower> leftyfb: there's an effort to bring machine-view to the juju-gui, which will alleviate some of this in the future, along with easing deployment of KVM/LXC units to a server for density
[21:44] <leftyfb> cool
[21:45] <lazyPower> cory_fu: i'm unable to locate the bug if one was opened. so it may not have been raised.
[21:46] <cory_fu> No biggie.  I don't think it actually mattered if I had an IP in this current case, actually, and, while it does in the other case and it would be nice to clean it up, it works currently, so...
[21:46] <lazyPower> cory_fu: wait i found it - https://bugs.launchpad.net/juju-core/+bug/1308374
[21:46] <_mup_> Bug #1308374: unit-get public-address on EC2 returns split horizon DNS <addressability> <networking> <strategy> <juju-core:Triaged> <https://launchpad.net/bugs/1308374>
[21:47] <leftyfb> lazyPower: how about specifying distro version (precise/trusty) for deployments? Everything seems to be precise even though I have default-series: trusty in my ~/.juju/environments.yaml
[21:47] <lazyPower> leftyfb: our trusty charmstore isn't very big
[21:47] <lazyPower> http://manage.jujucharms.com/charms/trusty
[21:49] <lazyPower> leftyfb: we have a rather large queue to get our existing prceise charms tested, updated to meet current charm store best practices, and unit/integration tested for inclusion into trusty - if you'd like to volunteer to help we could certainly use a helping hand - current work items are being managed in this spreadsheet - https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Aia4W3c4fbL-dGs4SVBJMGRIdnlSMWhzSmo3WE1mZ1E&usp=drive_web#gid=0
[21:50] <leftyfb> lazyPower: once I nail down juju, I might just offer some assistance in that effort
[21:51] <leftyfb> I can't even remove a service at this point
[21:51] <lazyPower> leftyfb: juju destroy-service <servicename>
[21:51] <lazyPower> juju destroy-machine #
[21:51] <leftyfb> lazyPower: yeah, it'd be nice if that worked
[21:51] <lazyPower> is the charm in an error state?
[21:51] <leftyfb>   mysql:
[21:51] <leftyfb>     charm: cs:precise/mysql-45
[21:51] <leftyfb>     exposed: false
[21:51] <leftyfb>     life: dying
[21:51] <leftyfb>     units:
[21:51] <leftyfb>       mysql/0:
[21:51] <leftyfb>         agent-state: error
[21:51] <leftyfb>         agent-state-info: 'hook failed: "start"'
[21:52] <leftyfb>         agent-version: <IP_ADDRESS>
[21:52] <leftyfb>         life: dying
[21:52] <leftyfb>         machine: "4"
[21:52] <leftyfb>         public-address: <IP_ADDRESS>
[21:52] <leftyfb> it failed to start
[21:52] <leftyfb> clicking on "resolve" or "retry" did nothing
[21:52] <lazyPower> you'll need to resolve the hook error before it will allow any of the other events to run. its goign to hang in that error state until you resolve it
[21:52] <leftyfb> with no output on the juju-gui as to what the issue was
[21:52] <leftyfb> how do I find out what's wrong?
[21:53] <lazyPower> you can inspect juju debug-log -n 500 to find the issue if the logs caught it - otherwise you'll want to investigate in running juju debug-hooks to run the hook interactively to see why it failed
[21:53] <lazyPower> leftyfb: if debug-log doesn't tell you anything - https://juju.ubuntu.com/docs/authors-hook-debug.html
[21:55] <lazyPower> leftyfb: also - note - since its in state dying, even if you resolve it successfully - your service is queued for destruction, and will promptly be destroyed once the issue has been resolved.
[21:55] <leftyfb> lazyPower: you know a customer is jumping through hoops at this point right? All I did was drag mysql to my canvas and clicked deply. Now the customer is looking through log files and searching for what a "hook-name" means
[21:56] <lazyPower> leftyfb: unfortunately - I dont have a better answer at this time.
[21:56] <leftyfb> what is the unit name?
[21:56] <leftyfb> I tried both mysql and cs:precise/mysql-45
[21:57] <lazyPower> mysql/0 - which is shown directly under units
[21:57] <lazyPower> in juju-status
[21:57] <lazyPower> for each node in a deployment, get increment by 1, so your second mysql unit if the service is scaled would be mysql/1
[21:58] <lazyPower> leftyfb: if you're deploying MySQL on the local provider - there is a known bug with the charm that will prevent it from deploying successfully
[21:58] <leftyfb> :/
[21:59] <leftyfb> it's not on the bootstrap machine if that's what you mean by local provider
[21:59] <leftyfb> if you mean a separate lxc container, then that's how it's setup at the moment .... what's the resolution?
[22:02] <lazyPower> leftyfb: LXC is a best attempt at emulating clouds on your local machine - so there are some subtle differences between it and a true cloud provider that sometimes cause unintended side effects with teh charm. I'm looking for the solution now, its been a while since i've used MySQL on the local provider.
[22:02] <leftyfb> i'm seeing possible memory exhaustion, that ring a bell?
[22:04] <lazyPower>  juju set mysql dataset-size='512M'
[22:04] <lazyPower> juju resolved -r mysql/0
[22:05] <leftyfb> that did it
[22:06] <leftyfb> i'll mess with this more tomorrow/later
[22:06] <leftyfb> thanks for the help
[22:06] <lazyPower> No problem. Sorry your first day wasn't as magical as we aim for it to be. We're here to help though leftyfb
[22:06] <leftyfb> lazyPower: it's not as bad as you think, it's not my first day with juju :)
[22:07] <leftyfb> i've messed with it working with maas, but was told local provider was the better way to play with it
[22:07] <lazyPower> leftyfb: i use both fairly regularly. I have consistently better luck with MAAS than i do the local provider - each has their own suite of perks and negatives.
[22:07] <leftyfb> 1 tip I have is for juju quickstart to be suggest more heavily
[22:08] <lazyPower> mbruzek: https://code.launchpad.net/~lazypower/charms/precise/mysql/local_provider_bug_note/+merge/223003
[22:11] <mbruzek> just a second lazyPower I am in meeting
[22:11] <lazyPower> ack, thanks for taking a look
[22:30] <mbruzek> lazyPower, +1 LGTM, I merged it