[06:10] <BeagleBug_97> Hi, is there any guide on installing a real-time patch on Ubuntu 14.04 kernel running on BeagleBoard xM?
[06:14] <BeagleBug_97> I found this one : https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
[06:14] <BeagleBug_97> But how do I leverage the rt features for an ARM processor?
[15:52] <yossarianuk> hi - not sure who i spoke to in here weeks ago
[15:53] <yossarianuk> I was asking about the OSS snd modules in the kernel (the fact that Ubuntu removes them completely) and that I am unable to play some old games unless i recompile the kernel
[15:53] <yossarianuk> I created a bug report - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1434842
[15:53] <yossarianuk> cheers
[17:56] <infinity> yossarianuk: It's a situation where no one can really win, unfortunately.
[17:57] <infinity> yossarianuk: IIRC, compiling OSS (even as modules) leaves some scaffolding in the kernel that makes it misbehave slightly on modern systems.
[17:58] <yossarianuk> infinity: but surely if the modules are disabled by default it won't hurt ?  other distros (like most of them) have them in the kernel but disabled by default
[18:02] <infinity> yossarianuk: So, the userspace shims entirely fail to work in some cases, but maybe these cases involved having one or two things compiled in.  We can certainly look at it again.
[18:02] <infinity> apw: Can we investigate if it's possible to build OSS *entirely* as modules with no taint on vmlinuz and then just blacklist them all?
[18:04] <yossarianuk> cool - its one issue I have with ubuntu... Debian (wheezy) opensuse , Fedora and Arch do have access to the module...
[18:05] <infinity> yossarianuk: No promises or anything.  But looking through the last few times it was disabled, accidentally enabled, and disabled again, there were always a few =y bits.  If it's possible for the whole thing to be =m, *and* that influences vmlinux in no way, then I don't see the harm.
[18:06] <infinity> apw: ^
[18:39] <yossarianuk> infinity: thank you very much !
[18:40] <yossarianuk> infinity: any effort is welcomed....
[18:42] <apw> infinity, indeed
[18:47] <apw> infinity, i guess with our new blacklist generator we could do that to them
[19:30] <yossarianuk> well thanks for whoever looks into this - i'm going to test kubuntu 15.04 - will file bug reports if i find any


[12:28] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Set up the AdGuard Home Ubuntu Appliance @ https://ubuntu.com//blog/set-up-the-adguard-home-ubuntu-appliance
[14:35] -SwissBot:#ubuntu-news- ::Planet:: Stuart Langridge: IoT devices and Android and disappointment @ https://www.kryogenix.org/days/2020/08/18/iot-devices-and-android-and-disappointment/
[14:53] -SwissBot:#ubuntu-news- ::Fridge:: Ubuntu Weekly Newsletter Issue 644 @ http://fridge.ubuntu.com/2020/08/17/ubuntu-weekly-newsletter-issue-644/ (by guiverc)


[04:59] <pitti> Good morning
[08:04] <willcooke> morning
[08:05] <Laney> hey hey
[08:05] <seb128> good morning desktopers!
[08:16] <Laney> hey seb128
[08:16] <Laney> how goes
[08:20] <pitti> hey Laney, bonjour seb128
[08:20] <Laney> hey pitti!
[08:21] <Laney> how are you?
[08:23] <pitti> Laney: quite fine, thanks! I recovered from the long weekend's lack of sleep :) how about yourself?
[08:24] <Laney> ooh, what did you get up to?
[08:24] <seb128> hey Laney pitti, wie gehts?
[08:24] <seb128> Laney, doing good thanks ;-)
[08:24] <Laney> I'm good thanks, climbing and making some blackberry and pear gin were last night's activities
[08:24] <seb128> pitti, did you party all w.e? ;-)
[08:25] <pitti> seb128: at least stayed up late (until ~ 1 to 3 am) Thu/Fri/Sat, and got up relatively early :)
[08:25] <seb128> I see
[08:25] <Laney> kids these days
[08:25] <Laney> makes me tired just reading that
[08:25] <seb128> the trick is to sleep in the morning those days ;-)
[08:26] <pitti> seb128: my parents celebrated their 60th birthday, and we visited some friends on Thu/Fri
[08:26] <seb128> nice
[08:51] <Laney> seb128: if you've got a minute could you look at NEWing gnome-desktop3 please?
[08:51] <seb128> Laney, sure
[08:53] <Laney> merci
[08:59] <seb128> de rien !
[09:11] <seb128> bah, somebody approved the buggy lightdm upload from robert_ancell
[09:12] <seb128> jdstrand, just as a fyi, seems like robert_ancell reverted your lightdm 1.11.9-0ubuntu2 upload (I guess outdated vcs), I emailed him earlier about that while the upload was in the queue but it got approved now ... I guess he's going to fix that tomorro
[09:12] <Laney> bah
[09:12] <Laney> can block it in proposed
[09:13] <Laney> done
[09:13] <seb128> Laney, thanks
[09:13] <Laney> we could reapply the diff and upload again
[09:14] <seb128> I wonder if those freeze make sense, obviously things get flagged through without review anyway
[09:14] <seb128> I guess I could ;-)
[09:14] <seb128> let me have a look
[09:14] <Laney> doing it
[09:14] <seb128> who is doing it?
[09:14] <seb128> oh, you
[09:14] <seb128> ok
[09:14] <seb128> thanks ;-)
[09:14] <Laney> wait
[09:14] <Laney> if you do it I could review ;-)
[09:14] <seb128> k
[09:14] <seb128> let me do it then
[09:15] <seb128> gnome-desktop NEW review first
[09:15] <Laney> okay
[09:15] <seb128> it's going to be easy, no worry
[09:16] <seb128> k, gnome-desktop NEWed, lightdm next
[09:17] <dgadomski> hello everyone
[09:17] <seb128> hey dgadomski
[09:18] <dgadomski> I have an idea to fix https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1125442
[09:18] <seb128> dgadomski, you might want to talk to Trevinho or bregma, they work on that code
[09:18] <dgadomski> I think about storing last focused window while changing viewports and then restoring it after returning to this viewport instead of picking the default one
[09:19] <dgadomski> thanks seb128
[09:19] <seb128> yw
[09:19] <dgadomski> Trevinho, bregma: do you have a minute to discuss this?
[09:20] <seb128> it's a bit early for bregma, he's -3/-4 I think
[09:20] <seb128> Trevinho might be around, he often has shifted hours though
[09:21] <dgadomski> seb128: thanks, I will be around in case they show up
[09:22] <seb128> yw!
[09:22] <seb128> Laney, you might want to mark the gnome-desktop mp as merge to get it out of the sponsoring queue
[09:22] <Laney> kay
[09:22] <seb128> thanks
[09:22] <Laney> I need to actually merge it first
[09:22] <seb128> you plan to merge it?
[09:22] <Laney> to the ubuntu-desktop branch
[09:22] <seb128> if that's udd let just the importer do it?
[09:23] <Laney> don't we have one there?
[09:23] <seb128> oh, why wasn't it mp against that one?
[09:23] <seb128> let me check, I was unsure but I guess we have since we have a delta for gnome-desktop3
[09:23] <Laney> nah there isn't one
[09:23] <seb128> k
[09:24] <Laney> oh no
[09:24] <Laney> there is!
[09:24] <Laney> it's obsolete though
[09:24] <Laney> might as well delete it I reckon
[09:31] <seb128> Laney, lightdm uploaded
[09:33] <Laney> ty
[09:33] <seb128> yw!
[09:34]  * Laney debdiffs against ubuntu2
[09:38] <Laney> alright, looks good
[09:39] <Laney> remind me to unblock in a publisher run or so if I forget
[09:41] <seb128> k, thanks
[09:53] <Laney> attente_: Do you remember the bug I had in China where I couldn't input Chinese in my non-Unity session?
[09:53] <Laney> I just remembered about it - did you come up with the fix? We should maybe get that in if so
[09:54] <Laney> nihao xiaomao
[09:57] <darkxst> hey Laney, seb128
[09:57] <seb128> hey darkxst
[09:58] <Laney> what's up
[10:01] <darkxst> Laney, usual mid-week stuff, though I did sneak in a morning mtb ride, and got back 10mins before the massive storms hit!
[10:03] <Laney> sneaky
[10:04] <Laney> we're having one of the warmest and driest Septembers ever apparently
[10:05] <darkxst> we have had a pretty warm september, but then it dropped to 6 during the storms!
[10:07] <Laney> wouldn't mind a decent storm
[10:07] <Laney> #ubuntu-storm-fans
[10:08] <darkxst> Laney, I saw trees falling while riding in the forest ;)
[10:08] <darkxst> and that was before it hit
[10:09] <Laney> "crap, better get home fast"
[10:12]  * willcooke loves a good storm
[10:13] <willcooke> one of the good things about working from home - I can go outside in the weather without being judged ;)
[10:15] <seb128> Laney, did you have any opinion on try to get the new empathy in utopic?
[10:16] <Laney> not atm
[10:17] <Laney> do we have any empathy users in the team?
[10:17] <seb128> I played a bit with the update and it seems to work fine
[10:17] <seb128> but I don't use it on daily basis
[10:17] <seb128> I do have accounts configured/contacts though
[10:17] <Laney> with messaging menu and online accoutns and sip and ...?
[10:17] <seb128> no sip
[10:18] <seb128> but messaging menu, online accounts, etc
[10:18] <darkxst> I played with it as well, but don't generally use it either
[10:18] <Laney> canonical voip works with it
[10:18] <Laney> I use that on the rare occasions I need to voip
[10:18] <seb128> I don't even know how canonical voip works
[10:18] <seb128> I never asked for my credentials
[10:18] <Laney> haha
[10:18] <larsu> pidgin!
[10:18] <seb128> hey larsu!
[10:18] <Laney> you can call<EMAIL_ADDRESS>in empathy
[10:18] <larsu> seb128: hey. Sorry, I'm buried in qml since this morning
[10:18] <Laney> to use the conf call line
[10:18] <seb128> I was using pidgin
[10:19] <Laney> it's quite reasonable actually
[10:19] <seb128> but nowadays I'm mostly using hangouts and fb chat
[10:19] <larsu> I don
[10:19] <seb128> Laney, it's world open or is there any acl?
[10:19] <Laney> you should have a username and password
[10:19] <larsu> oops, enter madness: I don't use empathy at all anymore either
[10:20] <Laney> it should get a telegram plugin
[10:20] <Laney> I'd probably use that
[10:20] <Laney> aaaanyway
[10:21] <Laney> seb128: did you review the packaging?
[10:21] <Laney> can you upload to the desktop ppa?
[10:21] <seb128> Laney, do you plan to backport the evince fix for that segfault or did you just triage a duplicate?
[10:21] <Laney> I was writing the changelog when you pinged me about empathy :P
[10:21] <seb128> Laney, I had a glance, was waiting for the mr to be up to do a real review, which is the case now
[10:22] <Laney> 'kay
[10:22] <seb128> Laney, k ;-)
[10:22] <Laney> well, I feel open to the idea
[10:29] <seb128> Laney, k, I reviewed the merge request/commented
[10:30] <seb128> there is one build-depends error to fix, looks good otherwise
[10:30] <seb128> darkxst, ^ (empathy), would be nice if you guys could make it a ffe as well
[10:39] <darkxst> seb128, I have no idea where the powerpc change in rules came from
[10:39] <bregma> dgadomski, if you miss Trevinho you can always comment on the bug, or propose a code merge if you're a comfortable with coding
[10:42] <darkxst> ricotz ^ do you know?
[10:43] <darkxst> I can only assume it was merged from debian at some point? since we don't care about powerpc on the ppa's
[10:45] <seb128> that would be a bit weird
[10:46] <seb128> since that to enable ubuntu-online-account
[10:46] <seb128> that's*
[10:46] <seb128> debian doesn't use uoa afaikl
[10:47] <darkxst> seb128, yes, and we don't either
[10:48] <seb128> yet somebody put that in the rules?
[10:49] <darkxst> :q
[10:49] <ricotz> it is part of empathy 3.8.4-1ubuntu1 which the ppa package is currently based on
[10:50] <Laney> darkxst: shall I interpret your comment on bug #1363721 as saying that the g-c-c panel for a-l-m isn't necesasry?
[10:51] <Laney> (because it looks as if you can build a-l-m without it)
[10:51] <darkxst> Laney, yes
[10:51] <ricotz> darkxst, how did you rebase the package?
[10:51] <darkxst> ricotz, Noskcaj did that merge
[10:52] <ricotz> ok, any way look at 3.8.4-1ubuntu1
[10:52] <darkxst> (I only fixed up the disabled patches
[10:52] <seb128> darkxst, ricotz: ok, that powerpc snippet got cleaned out during the utopic cycle, it shouldn't be there
[10:52] <seb128> e.g just drop those lines
[10:52] <darkxst> seb128, ok, will drop it
[10:52] <seb128> thanks!
[10:55] <darkxst> Laney, we don't ship a-l-m, but if its installed we have the standalone binary come up in search results
[10:55] <Laney> yeah
[10:55] <Laney> you can just turn off the g-c-c panel in the build
[10:55] <darkxst> Laney, its not a panel though is it?
[10:56] <Laney> it is
[10:56] <Laney> look in u-c-c
[10:56] <darkxst> Laney, it was shipped as an external panel
[10:56] <darkxst> pre-u-c-c I think?
[10:57] <Laney> we've had it for a while
[10:57] <dgadomski> bregma: thanks, I can prepare a fix, but I first wanted to discuss my approach
[10:57] <Laney> but it's a normal external panel, doesn't pop up a separate window or anything
[11:02] <darkxst> Laney, if a-l-m is building an external panel for g-c-c then that can be disabled, we don't need it
[11:02] <Laney> that is exactly what my upload does
[11:03] <darkxst> Laney, ok good
[11:03] <darkxst> I mainly kept the external panel stuff in g-c-c for backups
[11:03] <darkxst> i.e dejadup
[11:20] <dgadomski> bregma: I have added a comment with the description of my approach for Trevinho, if you would like to take a look I will appreciate your opinion as well
[11:24] <darkxst> Laney, should I push the rebuilds for gnome-desktop that I have upload for? or will you just do a mass copy?
[11:26] <seb128> Laney, where did you subscribe me to the daily CD emails? I want to opt out
[11:27] <Laney> I WANT OUT!
[11:27] <Laney> it's in code, lemme do it
[11:27] <Laney> well, a config file in cdimage
[11:27] <seb128> thanks
[11:27] <Laney> darkxst: you mean bzr?
[11:29] <darkxst> Laney, no upload, there are not packaging branches for things like mutter, gnome-panel etc
[11:29] <Laney> then just upload them and mark it in the bug
[11:29] <Laney> like put an [x] in the description or whatever
[11:29] <darkxst> ok
[12:12] <pitti> Laney: just to be sure, are you on the gnome-desktop3 transition? need a hand?
[12:12] <Laney> pitti: doing it now
[12:13] <Laney> I'm leaving the merges of g-s-d and g-c-c
[12:13] <Laney> so if you fancy reviewing those ;-)
[12:13] <pitti> Laney: thanks (just looking at -proposed to clean up a bit)
[12:13] <Laney> no pressure though, I'll do them this afternoon if not
[12:13] <Laney> (ppa:darkxst/gnome-desktop)
[12:14] <pitti> Laney: uh, 3.8 -> 3.12, does that have an approved FFE?
[12:14] <pitti> Laney: oh, I suppose that's easier now with ubuntu-{settings-daemon,control-center}
[12:15] <Laney> oh yeah that was always part of the plan, it's mostly decoupled these days
[12:15] <pitti> ack
[12:16] <Laney> although I forgot that edubuntu ships these bits ... (however they are LTS-only these days)
[12:20] <pitti>  gnome-settings-daemon | <IP_ADDRESS>-0ubuntu15   | ubuntu-rtm/14.09 | source, amd64, armhf, i386
[12:20] <pitti> Laney: ^ that's ... worrying (and strange)
[12:20] <seb128> pitti, why?
[12:20] <pitti> I wouldn't have expected g-s-d to be on the phone
[12:21] <seb128> it's not
[12:21] <pitti> if at all, u-s-d
[12:21] <seb128> but unity-schemas is built from unity
[12:21] <seb128> which is needed by unity8
[12:21] <Laney> some things are there because of touch-meta -> desktop-next
[12:21] <Laney> or other dep chains
[12:21] <seb128> which brings unity7 in
[12:21] <seb128> which depends on desktop components
[12:21] <Laney> if you check seeded-in-ubuntu you can see which images it ends up on
[12:22] <Laney> which ... does show it on desktop-next ...
[12:22] <pitti> seb128: well yes, but unity7 should still use u-s-d, not g-s-d?
[12:22] <seb128> pitti, g-s-d/u-s-d gsettings schemas are shared and in gnome-settings-daemon-schemas which is built by g-s-d
[12:22] <seb128> so u-s-d depends on a g-s-d binary
[12:22] <seb128> so g-s-d needs to follow u-s-d
[12:22] <pitti> aah
[12:23] <seb128> we meant to reverse that
[12:23] <seb128> build the schemas from u-s-d
[12:23] <seb128> but didn't get to do it this cycle
[12:23] <pitti> seb128: that means it's not low-risk to update g-s-d from 3.8 to 3.12?
[12:23] <seb128> we need to make sure there is no schemas incompatible changes indeed
[12:23] <Laney> check the schemas diff, Tim said he took care to make sure there aren't any dropped or changed keys
[12:23] <seb128> but I think the GNOME team checked for that/added back the keys that were deprecated
[12:24] <pitti> ack, I'll watch out for that
[12:24] <seb128> danke
[12:24] <pitti> Laney: I'll review the g-s-d merge
[12:24] <darkxst> yes I reverted all schema keys that were reverted
[12:24] <Laney> excellent, thanks
[12:24] <Laney> darkxst: can you update your usd branch to have version ubuntu3 please?
[12:24] <Laney> I'm going to change that for the upload
[12:25] <pitti> darkxst: do you have https://launchpad.net/~darkxst/+archive/ubuntu/gnome-desktop/+sourcepub/4435403/+listing-archive-extra in some branch, or should I copy over the debian/ dir and commit that as merge?
[12:27] <darkxst> pitti, see bug 1372346
[12:27] <pitti> darkxst: ah, splendid; thanks
[12:27] <Laney> okay, that's all uploaded (apart from g-s-d/g-c-c), I'll sort out the vcs after lunch
[12:27] <Laney> hopefully someone will accept them so that we get some builds
[12:28] <pitti> Laney: I'll do g-s-d; then you can accept wiht your release hat on :)
[12:28] <Laney> sounds good
[12:28]  * Laney finds a victim for g-c-c
[12:28] <Laney> not really, /me goes to lunch :P
[12:28] <Laney> biab
[12:29] <jdstrand> seb128: ack, thanks
[12:29] <jdstrand> for some reason I always forget to do the vcs on lightdm. I'm not sure why. some weird mental block...
[12:30] <seb128> jdstrand, hey, yw! I uploaded the fix so we should be fine
[12:30] <darkxst> Laney, will fix u-s-d version, then i'm off to bed
[12:31] <darkxst> Laney, actually the branch is ubuntu3, was only the ppa that was bumped
[12:32] <jdstrand> seb128: very much appreciated
[12:32] <seb128> no worry!
[12:33] <pitti> darkxst: OOI, what happened to debian/gnome-update-wallpaper-cache.c…?
[12:33] <darkxst> pitti, its not needed anymore, g-s-d runs in the installer these days
[12:34] <pitti> darkxst: I thought that was for generating a pre-scaled background image in ~/.cache, to avoid having to scale the selected bg image during boot?
[12:34] <seb128> pitti, g-s-d runs on ubiquity and the cached version is copied after the installation
[12:35] <pitti> ack
[12:35] <darkxst> pitti, well yes, but g-s-d didnt used to run on ubiquity
[12:43] <pitti> darkxst, seb128: reviewed, one question in https://code.launchpad.net/~darkxst/ubuntu/utopic/gnome-settings-daemon/lp1372346/+merge/236308
[12:52] <darkxst> pitti, pretty sure the input source switcher helper doesnt exist in u-s-d
[12:52] <pitti> /usr/lib/unity-settings-daemon/usd-test-input-helper
[12:52] <pitti> not sure what that is
[12:53] <pitti> darkxst: ah, I guess I could just grep the code, hang on
[12:54] <pitti> darkxst: right; thanks
[12:57] <pitti> Laney: I'm reviewing g-c-c too now, FYI; test-building/test-booting
[13:23] <Sweetshark> seb128: friendly ping about libreoffice upload ...
[13:24] <seb128> Sweetshark, oh, where is that again?
[13:24] <seb128> Sweetshark, you should use the sponsoring queue or drop me email for those, IRC pings don't stick ;-)
[13:25] <seb128> dpm, hey, want to review https://code.launchpad.net/~seb128/gallery-app/some-translations-tweaks/+merge/236511? not sure what we should do we the translate upstream/in ubuntu, does it make sense to make those project use X-Ubuntu-Use-Langpack?
[13:27] <Sweetshark> seb128: http://people.canonical.com/~bjoern/utopic/4.3.2/ <- here they are
[13:27] <seb128> Sweetshark, thanks
[13:30] <dgadomski> Trevinho: thanks (bug 1125442), I will try to implement it on the core level
[13:30] <Trevinho> dgadomski: thank you, let me know if you need some assistance, questions or anything else
[13:31] <pitti> Laney: g-c-c and g-s-d waiting in unapproved: )
[13:31] <Laney> hey
[13:31] <Laney> pitti: thanks
[13:31] <Laney> queue looking nice and fat now
[13:32] <dpm> seb128, I'm not sure, tbh. As far as I know, the plan is to migrate the system apps that are .debs to .clicks, but bfiller should know more.
[13:32] <seb128> dpm, but those changes shouldn't hurt even if that case, if we share translations between upstream and Ubuntu?
[13:34] <dpm> seb128, that's fine by me, I'll +1, but ultimately the MP will need to be top-approved by someone in bfiller's team
[13:34] <seb128> dpm, right, going to ping them as well
[13:35] <seb128> dpm, but I wanted to check with you about the X-Ubuntu-Use-Langpacks
[13:36] <dpm> seb128, so in summary, it's ok to use them for gallery, but just wanted to mention that at some point translations might need to be moved to the upstream click, if the app happens to migrate to click (and until we have click support in langpacks, or a better mechanism)
[13:37] <seb128> dpm, right, which is why I updated the pot as well
[13:37] <seb128> but meanwhile it's going to avoid us having to fight with outdated templates
[13:37] <seb128> dpm, do you know if anyone is planning to work on making launchpad support updating the pot server side for us?
[13:38] <seb128> seems like it would be an investment that would pay back
[13:38] <dpm> seb128, I fully agree. I cannot say for certain, but from the little I know and my experience with LP, no one is.
[13:39] <dpm> we've discussed updating the templates in the ci train, though
[13:39] <seb128> dpm, can you just raise it as a concern/don't you guys have stakeholder meetings? ;-)
[13:40] <dpm> seb128, I've not been a stakeholder in LP for a few years :)
[13:40] <seb128> Sweetshark, libreoffice uploaded, sorry for the delay, up to the release team next
[13:40] <dpm> seb128, but yeah, it's something in my radar, not sure yet about the best solution
[13:41] <dpm> well, I know the solution, just don't know how to make it happen without anyone available to work on it :)
[13:41] <seb128> dpm, well, as an UE manager you can probably flag things you see as impacting our ability to deliver in some ways? ;-)
[13:42] <seb128> dpm, anyway, we are going to keep dancing around those issues until we find resources to properly address them
[13:42] <seb128> which is fine, but it would probably pay back to have somebody spending a week on launchpad and fix it for good
[13:43] <seb128> rather than keeping running into "damn, outdated, need to mp, chase people, get things merged, to land, etc"
[13:46] <dpm> seb128, yeah, I've had exactly that discussion with LP devs a few years back, and I've been chasing people for ages too. In any case, we agree. I can only promise I'll re-raise it and try to do my best to find out a way to fix it.
[13:46] <seb128> dpm, thanks
[13:48] <Sweetshark> seb128: np, thanks so much for uploading.
[13:48] <seb128> yw!
[14:18] <Laney> tkamppeter: do you know your foo2zjs sync reverts the recommends→suggests change in the previous ubuntu upload?
[14:19] <tkamppeter> Laney, forgot abot that. I will check and ask the Debian guy whether he could overtake the change.
[14:20] <Laney> kay, thanks, rejecting meanwhile
[14:27] <tkamppeter> Laney, I will try to get the change be accepted by Debian and if yes I will sync again, otherwise only overtake the lcms2 fix.
[14:28] <Laney> You could just merge and keep the tix change
[14:28] <tkamppeter> Laney, some packages of trhe printing stack cannot be synced due to policy differences in Debian and Ubuntu.
[14:34] <Laney> Since you synced foo2zjs already I don't think that applies here :)
[14:36] <FJKong> seb128: could you take a look at https://bugs.launchpad.net/ubuntukylin/+bug/1365208 is this a bug?
[14:36] <FJKong> seb128: restart menu item will disappear on both ubuntu and ubuntu-kylin
[14:39] <Laney> haha
[14:40] <Laney> I see that
[14:40] <FJKong> Laney: it is very weird..
[15:27] <willcooke> righty ho
[15:27] <willcooke> going to start the meeting in a couple of mins using meetingology
[15:27] <desrt> meetingology?
[15:27] <willcooke> going to *try* I should say
[15:27] <willcooke> desrt, be prepared to be amazed
[15:28] <willcooke> I don't know, maybe sit down or something
[15:28] <willcooke> it's a bot to take minutes for us
[15:28] <Laney> we should have a vote on something
[15:28] <Laney> that feature man
[15:28] <willcooke> let's put that to the vote
[15:29] <seb128> FJKong, sure, I can have a look
[15:29] <FJKong> seb128: ok
[15:30] <willcooke> #startmeeting Desktop Weekly Meeting 2014-09-30
[15:30] <meetingology> Meeting started Tue Sep 30 15:30:41 2014 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:30] <meetingology> Available commands: action commands idea info link nick
[15:30] <willcooke> Roll call:  attente_, desrt, FJkong, happyaron, laney, larsu, qengho, seb128, sweetshark, tkamppeter
[15:31] <desrt> hihi
[15:31]  * Sweetshark reporting in.
[15:31] <seb128> hey
[15:31] <willcooke> I'm going to set the topic to each person in turn
[15:31] <brookswarner> hi willcooke seb128
[15:31] <willcooke> attente_, we'll come back to you at the end :)
[15:32]  * Sweetshark thinks we should vote on "buy Bjoern a private helicopter". its the usual testcase for meetbot votes.
[15:32] <willcooke> #topic desrt
[15:32] <willcooke> desrt, you're up first
[15:32] <desrt> hi.  not a super-productive week.  mostly did reviewing and worked on a few minor API additions for glib
[15:32] <desrt> spent some time visiting a friend in the hospital...
[15:33] <desrt> not much else to say -- too bad for our first fancy meeting with the bot :)
[15:33] <willcooke> :)
[15:33] <willcooke> thank desrt
[15:33] <willcooke> *thanks
[15:33] <willcooke> #topic FJKong
[15:33] <willcooke> FJKong, you're up
[15:33] <FJKong> * Dash pinyin search, talked to bregma bregma targets for 15.04, he suggest we discuess it at DC Sprint
[15:33] <FJKong> * Bug #1365208, tested uk and ubuntu, bug confirmed
[15:33] <FJKong> * feature of searching on google for gnome-terminal, kylin still not accept it yet
[15:33] <FJKong> * wiki page is done,  Ubuntu Membership Board meeting is at October 2nd, 2014 at 22:00:00 UTC in #ubuntu-meeting
[15:33] <FJKong> * Visa: all material are done, interview at Oct 6
[15:33] <FJKong> to be done:
[15:33] <FJKong> * do research on lib for remap pinyin and Chinese
[15:34] <FJKong> * when should remap, and when should  just pass the string untouched?
[15:34] <FJKong> * National Day Holidays
[15:34] <FJKong>  eof
[15:34] <willcooke> thanks FJKong - good luck with the Ubuntu membership and the visa interview :)
[15:34] <willcooke> #topic happyaron
[15:34] <FJKong> willcooke: thanks
[15:34] <willcooke> happyaron, are you about?
[15:34]  * willcooke expects not - given that its late
[15:35] <FJKong> 23:34 I think he is sleeping
[15:35] <willcooke> if you are, we'll come back to you happyaron
[15:35] <FJKong> not like me
[15:35] <willcooke> yeah I think so too
[15:35] <willcooke> :)
[15:35] <willcooke> ok..
[15:35] <willcooke> #topic Laney
[15:35] <willcooke> Laney, you're up
[15:35] <Laney> • Lots of FFe reviews, queue reviews, accepts, unblocks & so on
[15:35] <Laney> • Patch piloted yesterday
[15:35] <Laney> • Drove (with Tim) the gnome-desktop3 transition, will see where we are in a little bit when the builds & publisher shake out
[15:35] <Laney> • GStreamer, evince updates
[15:35] <Laney> • a-l-m bugfix for duplicate Security & Privacy icons
[15:35] <Laney> • Fix FTBFS & do some multi-arching in Debian as a result of the new gobject-introspection. Should be complete there now.
[15:35] <Laney> ⚓
[15:36] <desrt> Laney: thanks for the unicode
[15:36] <willcooke> :D
[15:36] <Laney> (d-conf update too)
[15:36] <Laney> you're welcome
[15:36] <willcooke> Good stuff, thanks a lot Laney
[15:36] <Laney> I got moved down the list which gave me time to find a nice one
[15:36] <willcooke> #topic larsu
[15:37] <willcooke> larsu, how goes?
[15:37] <larsu> unproductive week for me as well due to sickness last week :/
[15:37] <larsu> I finally finished the Icon stuff in uitk today
[15:38] <larsu> which makes unity8 tests pass so that they can finally start using it
[15:38] <larsu> which gives them hack-free rectangular icons
[15:38] <larsu> (same for system settings)
[15:38] <larsu> seb128: we should be able to remove the "width: height" thing you added to that MR
[15:38] <seb128> system settings is already using it
[15:38] <willcooke> excellent!
[15:38] <seb128> oh, nice
[15:38] <seb128> btw the settings icon is wrongly shapped on the device for some reason
[15:38] <seb128> let's see if your update fixes it
[15:39] <larsu> otherwise I did some bug triage, but really didn't get much else done on the couch last week
[15:39] <willcooke> hope you're feeling better larsu
[15:39] <larsu> seb128: I hope. It was quite a bit of meddling around. I think a qml expert should do this next time
[15:39]  * larsu couldn't find one sadly
[15:39] <Laney> and now i
[15:39] <seb128> larsu, thanks for stepping up and doing it!
[15:39] <willcooke> #topic qengho
[15:39] <Laney> and now it is you*
[15:39] <larsu> willcooke: ya, much better now. Thanks!
[15:40] <seb128> larsu, ask Laney next time, he's a big fish and a toolkit expert
[15:40] <larsu> will do :)
[15:40] <willcooke> XD
[15:40] <willcooke> qengho, your turn
[15:40] <Laney> teach a man to fish
[15:41] <desrt> man down!
[15:41] <willcooke> he's marked as away
[15:41] <willcooke> ok, moving on
[15:41] <willcooke> #topic seb128
[15:41] <willcooke> seb128, your turn
[15:42] <seb128> ubuntu-system-settings for touch
[15:42] <seb128> ∘ update the storage panel to be able to read icons info for scopes
[15:42] <seb128> ∘ made the trust store applications name show translated
[15:42] <seb128> ∘ fixed some scrolling issues
[15:42] <seb128> ∘ tweaked the storage backend to better handle the krillin partitions
[15:42] <seb128> ∘ reviews
[15:42] <seb128> • fixed an UI bug in gallery
[15:42] <seb128> • small bugfix upload for lightdm
[15:42] <seb128> • some desktop bugfixes
[15:42] <seb128> • tested the gnome-desktop transition before it got uploaded
[15:42] <seb128> • reviewed/tested empathy upgrade
[15:42] <seb128> • some sponsoring
[15:42] <seb128> • usual share of bugs triaging and desktop discussions

[15:42] <willcooke> Thanks a lot seb128
[15:42] <willcooke> #topic Sweetshark
[15:43] <willcooke> Sweetshark, how goes LibreOffice
[15:43] <Sweetshark> • first added, then removed mergedlibs because of fdo#84315
[15:43] <Sweetshark> • finalized LibreOffice <IP_ADDRESS> (some upstream guidance there too: releng was on vacation, we had someone step in for the first time)
[15:43] <Sweetshark> • wrote a integration test for fdo#84315 in Python upstream -- sadly exposing JVM bootstrap issues on in the Pyyhon test stuff
[15:43] <Sweetshark> • will look into rewriting the same in Java now
[15:43] <Sweetshark> • code dumped the docker/saltstack based tinderbox infra framework at https://gerrit.libreoffice.org/gitweb?p=tb3-docker.git;a=summary
[15:43] <Sweetshark> • upcoming week: bisect the mergedlibs thing, if test is there, see if we still can get mergedlibs back, for context:
[15:43] <Sweetshark> • • libmerged reduced cold startup from 3 seconds to 2 seconds on a SSD, see my ad-hoc measurements at http://nabble.documentfoundation.org/minutes-of-ESC-call-td4123642.html
[15:43] <Sweetshark> • • some people reported cold startup of ~13 seconds on spinning disc hardware, I assume mergedlibs to be very measurable there
[15:43] <Sweetshark> EOF
[15:43] <Sweetshark> whops - that looks like a utf-8 fail ;)
[15:44] <willcooke> thanks Sweetshark
[15:44] <willcooke> #topic tkamppeter
[15:44] <willcooke> tkamppeter, what's new in printing?
[15:45] <tkamppeter> - cups-filters: Released 1.0.59 upstream and in Utopic, with several bug fixes on color management, the latest ippusbxd, and a PPD for IPP Everywhere (PWG Raster) printers.
[15:45] <tkamppeter> - Dialog with Brother about their work on IPP Everywhere printers and them testing Ubuntu's IPP Everywhere printer support
[15:45] <tkamppeter> - Bought an add-on module which should make IPP Everywhere printers out of HP lasers.
[15:45]  * willcooke is excited about the dialogue with Brother
[15:46] <willcooke> You will probably remember tkamppeter and I had some meetings with printer makers a little while ago, and this is the first fruit of those meetings.
[15:46] <willcooke> thanks tkamppeter
[15:46] <tkamppeter> Got knowledge of http://www.mopria.org/ which seems simply some marketing of IPP Everywhere printers but not coming from the PWG who created IPP Everywhere.
[15:47] <willcooke> :/
[15:48] <willcooke> #topic robert_ancell
[15:48] <willcooke> Worked on:
[15:48] <willcooke> - Released lightdm 1.12.0
[15:48] <willcooke> - Bug triage, fixing
[15:48] <willcooke> - Away on holiday for two days
[15:48] <willcooke> Currently working on:
[15:48] <willcooke> - Preparing LightDM 1.10.2 SRU
[15:48] <willcooke> - Bug fixing for utopic release
[15:48] <willcooke> Not blocked on anything.
[15:48] <willcooke> #topic TheMuso
[15:48] <willcooke> TheMuso
[15:48] <willcooke> * SPent most of this week trying to come up with a report on our Section 508 compliance WRT the Ubuntu desktop, however vague queries are vague so I could only give a general overview on where we stand.
[15:48] <willcooke> * Spent some time doing a little upstream work for the speech dispatcher project, getting a release out the door. Going forward I may want to spend more time on this given it would be beneficial for the phone as the TTS server that is used for TTS related things including accessibility.
[15:48] <willcooke> * Reviewed my revisions to the accessibility wiki documentation to see if I had missed anything obvious, could probably use some improvement, will be updating soon.
[15:48] <willcooke> #topic attente_
[15:48] <willcooke> Heyhey attente_ :)
[15:48] <willcooke> your turn
[15:49] <attente_> hi willcooke :)
[15:49] <attente_> i've been in the hospital for the past ~2 weeks, but almost back to full health and i think i'm scheduled for discharge this weekend
[15:49] <desrt> attente_: hi :)
[15:49] <attente_> Laney, i remember that bug, but wasn't able to get a working xmonad session, if you can test this branch, https://code.launchpad.net/~attente/unity-control-center/non-gnome-unity-ibus-support, it might make it work again
[15:49] <larsu> attente_: hi!
[15:49] <attente_> i'm the friend that desrt has been visiting in hospital
[15:49] <seb128> attente_, hey, nice to read that you are doing better!
[15:49] <attente_> thanks!
[15:49] <willcooke> attente_, very very happy to hear that you are on the mend.  Take it easy buddy
[15:50] <willcooke> #topic Any other business
[15:50] <willcooke> #vote should we buy Sweetshark a helicopter
[15:50] <meetingology> Please vote on: should we buy Sweetshark a helicopter
[15:50] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[15:51] <willcooke> -1
[15:51] <meetingology> -1 received from willcooke
[15:51] <desrt> +0.5
[15:51] <attente_> haha
[15:51] <meetingology> +0.5 received from desrt
[15:51] <Laney> -1000 # for laney please
[15:51] <meetingology> -1000 # for laney please received from Laney
[15:51] <desrt> hm.  vote isn't going too well
[15:52] <willcooke> voting ends in 5 seconds
[15:52] <Sweetshark> +0 abstain -- I might be considered biased otherwise.
[15:52] <meetingology> +0 abstain -- I might be considered biased otherwise. received from Sweetshark
[15:52] <desrt> Sweetshark: +0 or -0?
[15:52] <willcooke> #endvote
[15:52] <meetingology> Voting ended on: should we buy Sweetshark a helicopter
[15:52] <meetingology> Votes for:0 Votes against:2 Abstentions:2
[15:52] <meetingology> Motion denied
[15:52] <willcooke> Well, I can't say I'm surprised
[15:52] <willcooke> better luck next time Sweetshark
[15:52] <desrt> i voted for!
[15:52] <desrt> (weakly)
[15:53] <willcooke> Anything else from anyone before we end?
[15:53]  * desrt guesses that the +0.5 was parsed as "+0" followed by some junk
[15:53]  * willcooke waits 1 minute
[15:53] <Laney> https://medium.com/travel-adventure/what-its-like-to-fly-the-23-000-singapore-airlines-suites-class-17d9f3fee0d
[15:53] <Laney> that
[15:53] <willcooke> O_o
[15:54] <desrt> Laney: new standard for company travel?
[15:54] <desrt> maybe we ought to have a vote on this one ;)
[15:54] <willcooke> #endmeeting
[15:54] <meetingology> Meeting ended Tue Sep 30 15:54:38 2014 UTC.
[15:54] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2014/ubuntu-desktop.2014-09-30-15.30.moin.txt
[15:54] <willcooke> right, thanks a lot guys
[15:54] <willcooke> I think the bot is a good thing
[15:55] <seb128> thanks
[15:55] <Sweetshark> meetingology is certainly the better meetbot. When we voted on my helicopter on #libreoffice-qa it crashed the meetbot there ...
[15:55] <meetingology> Sweetshark: Error: "is" is not a valid command.
[15:55] <willcooke> haha - you were saying?
[15:55] <seb128> willcooke, does it give us better logging or something?
[15:55] <desrt> Sweetshark: reevaluate your opinion yet? :)
[15:55] <willcooke> seb128, it means I don't have to grep my IRC logs for robert_ancell and TheMuso
[15:55] <seb128> willcooke, out of the voting I didn't notice we used it much in fact?
[15:55] <willcooke> I email them a dump of the log, and now it's a URL with some sort of organisation
[15:56] <Laney> It makes a little webpage
[15:56] <Laney> and it can set the channel topic if the bot has permissions ...
[15:56] <desrt> ya -- the logging is clearly the most useful part -- particularly for those who cannot attend
[15:56] <willcooke> logs don't like unicode though
[15:57] <desrt> strictly speaking, irc has no particular encoding....
[15:57] <desrt> most of the world has decided that this means that everyone ought to use utf8
[15:57] <desrt> bot disagrees, apparently
[15:57] <willcooke> it's holding out for emoji
[15:57] <desrt> actually, it may be the fault of your browser
[15:57] <willcooke> 🚽
[15:58] <desrt> this is just a text file, so if it was served without any encoding hints, your browser picks one by default
[15:59] <Sweetshark> desrt: looks like the page has an "encoding: windows-1252" hint -- which is ... *cough* oldschool.
[16:33] <Laney> seb128: can you tag&push lp:~darkxst/unity/lp1372346 please?
[16:33] <Laney> just a no change rebuild
[16:34] <seb128> Laney, bzr merge, debcommit -r, push?
[16:35] <Laney> should be bzr branch; bzr tag; bzr push lp:unity
[16:35] <seb128> I never used bzr tag
[16:35] <seb128> should I specify the version?
[16:35] <seb128> or is it clever?
[16:35] <Laney> it knows to use the changelog revision by default
[16:36] <seb128> Created tag 7.3.1+14.10.20140915-0ubuntu2.
[16:36] <seb128> seems ok
[16:36] <Laney> good old bzr
[16:36] <seb128> k, done
[16:36] <Laney> great
[16:36] <Laney> ta
[16:36] <seb128> yw
[16:36]  * Laney watches for a cheese/ppc build
[16:37] <seb128> http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3875
[17:04] <Laney> see you later!
[17:05] <willcooke> later yall
[17:09] <seb128> Laney, have a nice evening!
[18:09] <excalibr> someone commented that the installer bug that wipes user's hard drives still not fixed in utopic final beta iso though it's marked as fix released in the bug report https://launchpad.net/ubuntu/+source/ubiquity/+bug/1265192
[19:14] <robert_ancell> jdstrand, in lightdm should debian/patches/*_apparmor-*.patch just be applied to trunk, i.e. they are no more Ubuntu specific than the current apparmor config in trunk?
[19:14] <robert_ancell> Also, could you do MPs for changes like this in the future?
[19:25] <jdstrand> robert_ancell: re MPs> yeah, you've asked me to do that in the past and I actually thought about it this time, then got distracted (sorry)
[19:26] <jdstrand> robert_ancell: feel free to apply 07_apparmor-chrome.patch and 08_apparmor-updates.patch
[19:26] <jdstrand> robert_ancell: 06_apparmor-unix.patch you may not want to apply since only Ubuntu has unix rules for apparmor
[19:27] <jdstrand> robert_ancell: on the other hand, distros can patch them out, so it is up to you
[19:27] <jdstrand> (only Ubuntu 14.10 has unix rules)
[19:27] <jdstrand> they same could've been said for dbus and 13.10 and signal/ptrace for 14.04
[19:28] <robert_ancell> jdstrand, are they going upstream? The current lightdm trunk is for lightdm 1.14 which will be for 15.04
[19:28] <jdstrand> so, up to you how you want to handle it
[19:28] <jdstrand> robert_ancell: yes, they are all going upstream. I don't know when they will be accepted
[19:29]  * jdstrand notes we are upstream for apparmor userspace, but upstream in this context I took to mean upstream kernel
[19:29] <robert_ancell> jdstrand, do you have a bug link?
[19:29] <robert_ancell> ah
[19:30] <jdstrand> robert_ancell: it will work fine with a 2.9 apparmor parser if the kernel doesn't support it. I think suse will have 2.9 in their next release, but their upcoming release and debian will have the 2.8 parser
[19:30] <jdstrand> if you aren't going to apply these, probably want to carry dbus, signal and ptrace as patches too
[19:31] <robert_ancell> OK, I'll just make a note that we require apparmor 2.9 and debian can patch out those changes
[19:31] <jdstrand> cool, thanks
[19:31] <jdstrand> it isn't like it is difficult. the Debian apparmor team is aware of this stuff
[19:31] <jdstrand> but, we are upstreaming all this stuff


[00:18] <TheMuso> psusi: ah ok
[00:26] <psusi> TheMuso, so umm... what exactly does that patch fix?
[00:27] <TheMuso> psusi: I'd have to read the patch again to clearly remember... One of my first changelog entries for parted should explain it.
[00:38] <psusi> TheMuso, the description in the changelog says " dmraid.patch: Ensure that device-mapper devices for dmraid arrays do not have extra nodes created needlessly, as well as making sure that partition nodes for dmraid devices are not probed."  I can't figure that out.  What nodes were being created under what conditions?
[00:40] <TheMuso> psusi: At the time, every dmraid device node that was created that parted dealt with, had additional nodes created to represent partitions, I think. This code was written over 3 years ago, so of course things may have changed. I understood why at the time. :)
[00:40] <TheMuso> psusi: I guess the best experiment is to take out my patch, play with dmraid stuff and parted, and see what happens.
[01:16] <psusi> TheMuso, k.. guess I'll try that...
[01:18] <TheMuso> If I continued dmraid related code maintenance, I'm sure I'd still know. I think that a ${node}p1 node was being created for every dmraid related node at the time, including partitino nodes, which is why the patch also stops dmraid partition nodes from beinb probed.
[01:18] <TheMuso> Now that I think, it was to do with probing. For some reason parted thought that every dmraid node had a partition table of some kind... beats me why
[01:20] <psusi> hrm... now this is weird... gnome-power-manager is running, but doesn't seem to actually be used.. it looks like we use upowerd to suspend, so what the heck is gnome-power-manager doing?
[01:25] <RAOF> Display blanking, automated “suspend when low battery” stuff?
[01:50] <psusi> RAOF, doesn't appear to be.. looks like upower is doing that these days... which explains bug #578542
[01:51] <psusi> I sent g-p-m a SIGSTOP and clicked suspend on the menu and it worked normally
[01:53] <RAOF> psusi: That's orthogonal to what I said.  That's neither ‘suspend when battery low’ nor ‘dim screen on inactivity’. :)
[01:55] <RAOF> Those are policy decisions rather than implementation methods.
[02:05] <psusi> ahh...
[02:06] <psusi> so where is the darn screen saver being started and the screen locked?  hrm...
[02:32] <psusi> hrm.. can you use dbus-send to manually emit an org.freedesktop.UPower signal?
[02:32] <psusi> or better yet, find out what is listening for that signal?
[02:45] <RAOF> psusi: I don't think you can track what's listening to the signal.  I think dbus-send should be able to fanangle a signal for you, though.
[02:47] <psusi> RAOF, I thought so but I can't seem to figure it out... I don't quite understand the arguments it wants, specifically what the difference is between --dest=, <destination object path> and <message name>..
[02:48] <RAOF> Heh.
[02:48] <RAOF> Say hello to DBus!
[02:48] <RAOF> --dest= is the *interface* that the signal you want to send is from.
[02:49] <RAOF> Oooh, actually, no.
[02:49] <RAOF> You shouldn't need --dest, because you're not sending it anywhere specific.
[02:50] <RAOF> <destination object path> should be the object path of the object you want to raise the signal _on_
[02:51] <RAOF> <message name> should be the signal you want to raise, namely the fully-qualified signal from the interface (org.freedesktop.UPower.$INTERFACE.$SIGNAL)
[02:51] <psusi> so org/freedesktop/UPower and org.freedesktop.UPower.Sleeping?
[02:51] <psusi> err, what's $INTERFACE?
[02:52] <RAOF> Sounds like $INTERFACE is ""
[02:52] <RAOF> So you'd want to send org.freedesktop.UPower.Sleeping
[02:53] <RAOF> But if UPower had multiple interfaces (o.f.UPower.Bar.Sleeping, o.f.UPower.Baz.Sleeping, for example) you'd stick in the fully qualified thingy.
[02:53] <psusi> process 19675: arguments to dbus_message_new_signal() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1289.
[02:58] <RAOF> Sounds like you've got the wrong object path?
[02:59]  * RAOF fires up d-feet
[02:59] <psusi> d-feet?
[03:00] <RAOF> …and immediately notices he doesn't have a UPower interface.
[03:00] <RAOF> Oh, man.  You're debugging DBus issues and you don't know about d-feet?  Sorry!
[03:01] <RAOF> It's a DBus browser.  It can't raise signals, but it does enumerate the bus and such.
[03:01] <RAOF> Oh, of course.  It's on the system bus.
[03:05] <RAOF> So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me.
[03:05] <RAOF> So “dbus-send --system /org/freedeskop/UPower org.freedesktop.UPower.Sleeping” works for me.
[03:09] <psusi> DOH!
[03:09] <psusi> I wasn't using the leading / before org
[03:12] <RAOF> It also doesn't trigger anything obvious for me :)
[03:13] <psusi> me neither... hrm...
[03:13] <psusi> so there's no way to monitor who is interested in the signal?
[03:20] <psusi> hrm... this doesn't seem to do anything either: dbus-send --type=method_call --dest=org.freedesktop.UPower --system /org/freedeskop/UPower org.freedesktop.UPower.Suspend
[03:25] <RAOF> Wheras that was very happy to suspend my system.
[03:25] <RAOF> And, of course, did not result in gnome-screensaver coming back with a screen lock.
[03:26] <psusi> hrm.. it works when I use d-feet to call it and yea, doesn't lock the screen
[03:26] <psusi> hrm...
[03:32] <RAOF> In hindsight, I knew that; I needed to fix a bug where Do wouldn't lock the screen before suspend because it was calling UPower directly.
[03:32] <psusi> so what on earth DOES lock the screen?
[03:44] <RAOF> Well, in Do we call out to gnome-screensaver ourselves.
[04:01] <psusi> bingo... indicator-session... session-service.c:machine_sleep()
[04:02] <psusi> now I wonder why the gconf key for g-p-m to lock or not is still there when it doesn't handle that function?  hrm..
[06:09] <abhinav_> is there a command to delete a branch from the repository ?
[06:09] <abhinav_> in bazaar
[06:10] <RAOF> rm -r?
[06:11] <abhinav_> so bazaar will know that the branch is gone, if I do that ?
[06:11] <RAOF> Yes.
[06:11] <abhinav_> oh ok. thanks
[06:11] <RAOF> * For some values of “yes”.
[06:12] <RAOF> What exactly do you want to do?  Free disk space?  Strip out some unwanted stuff from a repository?  Clean your source trees?
[06:13] <abhinav_> yeah. I was experimenting something in a branch. I do not want to merge those changes,
[06:14] <RAOF> Oh.  Then just don't merge those changes :)
[06:14] <nigelb> lol, rm -r
[06:15] <abhinav_> yeah, but that branch is pretty useless now. deleting it should not be any harm ?
[06:15] <RAOF> The repository is just a performance optimisation.  It doesn't actually have any semantic meaning.
[06:16] <RAOF> So, while those commits will remain in your local repository, they won't get pushed anywhere (unless you push something that refers to them, but you'd need to merge them for that to happen).
[06:16] <RAOF> Your local repository will be a couple of KB larger than it would otherwise be :)
[06:16] <abhinav_> ah ok. that's fine :)
[06:17] <RAOF> Mmmm, “About 8 hours remaining”.  dpkg really, really likes unpacking onto btrfs, doesn't it :)
[08:04] <abhinav_> why does dch -i add maverick at the top of the changelog entry, even though I am working on natty package ?
[08:04] <dholbach> good morning
[08:04] <abhinav_> good morning :)
[08:05] <micahg> abhinav_: you can pass -Dnatty to work on a natty package (I'm assuming you're on maverick)
[08:05] <abhinav_> yes, I am on maverick
[08:08] <abhinav_> I have already saved the changelog. I suppose I can edit it and write natty instead of maverick.
[08:10] <micahg> abhinav_: yeah, if you start with UNRELEASED, you can use -D to add the series later, but now you'll have to just edit it
[08:10] <abhinav_> ok thanks :-)
[08:13] <abhinav_> well actually I am working on a bug fix of tomcat6, as I see in the changelog, all the entries say "unstable" instead of maverick or natty
[08:13] <micahg> abhinav_: that's because it comes from Debian
[08:13] <abhinav_> ohsix, so I should write unstable too ?
[08:14] <abhinav_> *sorry
[08:14] <micahg> abhinav_: no
[08:14] <ohsix> tell debian about it,  no?
[08:15] <micahg> well, the patch should be upstreamed to Debian if appropriate, but that's another question :)
[08:16] <ohsix> i can never remember if unstable or testing is the one to expect breakage
[08:16] <ohsix> (lots of, not some)
[08:16] <abhinav_> hmm , I have the patch ready :-), Its my first bug-fix, so I have not much idea about the process
[08:16] <abhinav_> but the package is tomcat6-6.0.28, I believe same is available in maverick repositories
[08:17] <micahg> abhinav_: https://wiki.ubuntu.com/SponsorshipProcess
[08:37] <zanaga> what is the correct way of requesting a sync from debian that replaces a package from a different source? I just want to get this stuff filed for the next release cycle.. Regarding LP#378240
[08:56] <pitti> Good morning
[08:56] <pitti> slangasek: sure, no prob
[09:42]  * SpamapS_ gulps
[09:42] <SpamapS_> 933 upgraded, 66 newly installed, 1 to remove and 1 not upgraded.
[09:42] <SpamapS_> Need to get 977 MB/977 MB of archives.
[09:42]  * SpamapS answers yes... here we go!
[09:51] <pitti> slangasek: gtk 2 uploaded
[10:11] <abhinav_> where can I get some help on gtk# ?
[10:17] <RAOF> abhinav_: #mono on gimpnet is a reasonable place for gtk# help.
[10:18] <abhinav_> RAOF: thanks. I will ping there :)
[10:18] <RAOF> abhinav_: But mainly what I use is the python & C gtk doc; gtk# is a fairly obvious translation to C#.  Code-completion helps, too :)
[10:19] <abhinav_> yes, I don't know. I need some help with the TreeView, but the functionality that I am looking for does not seem to be available as per the documentation
[10:30] <dpm> hey mvo, good morning. A translator has found some encoding problems in apt translations in Launchpad. Before I can help him I wanted to ask you: how are apt translations handled? Are translations from LP ever exported and committed to the code, or do translations come exclusively from upstream in Debian?
[10:31] <kirkland`> didrocks: hi
[10:31] <kirkland`> didrocks: how do i make the unity search thing look for stuff in my $HOME/bin?
[10:32] <didrocks> kirkland: hey, the search is only based on desktop files
[10:32] <didrocks> so put a desktop file in your XDG path
[10:32] <kirkland> didrocks: dang
[10:32] <didrocks> we'll have an alt + F2 soon
[10:32] <kirkland> didrocks: i just want to run a wrapper script
[10:32] <soren> \o/
[10:32] <kirkland> didrocks: like i used to do with alt-F2
[10:32]  * soren misses Alt-F2
[10:33] <kirkland> didrocks: oh, okay, as long as alt-f2 comes back, that'll be fine
[10:33] <didrocks> kirkland: you'll have one if I find the time to code it :)
[10:33] <didrocks> yeah
[10:33] <kirkland> didrocks: cool, thanks
[10:33] <didrocks> yw :)
[10:33] <nigelb> bdrung_: Thought you might have liked to see http://stopabusingsiprefixes.org/stopabusing.html
[10:33] <kirkland> didrocks: if you're writing this, could you make sure that the alt-f2 path contains $HOME/bin?
[10:34] <nigelb> Ubuntu is lame.
[10:34] <nigelb> Maybe, but at least they have a sensible units policy.
[10:34] <didrocks> kirkland: it will respect the PATH
[10:34] <nigelb> bdrung_: direct quote ^^
[10:34] <didrocks> sounds less hackish :)
[10:35] <mvo> dpm: they come exclusively from upstream
[10:36] <mvo> dpm: what language(s) are affected?
[10:36] <bdrung_> nigelb: :) sadly the upstream authors with power refuse to do something regarding this bikeshed topic
[10:36] <kirkland> didrocks: okay
[10:36] <nigelb> bdrung_: oh, ouch :(
[10:37] <bdrung_> nigelb: https://bugzilla.gnome.org/show_bug.cgi?id=640432
[10:37] <dpm> mvo, thanks for confirming. Slovenian: look at the squares in the suggestions on https://translations.launchpad.net/ubuntu/natty/+source/apt/+pots/apt-all/sl/+translate (note that the translators have already corrected it in LP) - due to message sharing, I'm not sure if these translations were imported from a natty, lucid or maverick upload
[10:38] <nigelb> bdrung_: oh dear.  Its bad when someone says, "flame" in the beginning of the bug
[10:39] <mvo> dpm: thanks, I check it ou
[10:39] <mvo> t
[10:40] <dpm> thanks :)
[11:23] <dpm> mvo, it's translations questions day today! :-) Here's another one: do you happen to know who handles translations for gdebi, and how/where they are done?
[11:24] <mdz> pitti, is there a problem with the retracer? I'm seeing 16-hour-old bugs like 730243 are not retraced yet
[11:30] <mdz> dbarth, I noticed the above because I got a compiz crash and saw there were plenty of others coming in like it (unity-window-decorator crashed with SIGSEGV in g_closure_invoke())
[11:31] <dbarth> mdz: the decorator issue is on our radar
[11:32] <dbarth> mdz: smpillaz has made more fixes for it, and i'm seeing with didrocks when he can release that
[11:33] <mdz> dbarth, ok
[11:34] <seb128> mdz, let me check on the retracers
[11:39] <seb128> mdz, the amd64 had a lock set but was not running, the log had no error though so I just restarted it to see
[11:39] <mdz> seb128, ok, thanks
[11:40] <seb128> mdz, you're welcome
[11:40] <mdz> seb128, did you see the new global bugpatterns code which is now in natty? you can write bug patterns which are not specific to a package, e.g. to catch crashes from a library which bubble up to many different apps
[11:44] <seb128> mdz, no I didn't see it before and I didn't realize that matching was specific to components
[11:45] <mdz> seb128, in the past, you had to put bug patterns into a file named after the package, and we would only check for patterns which applied to the package where the bug was being reported
[11:45] <mdz> so if you had a libdbusmenu bug which caused crashes in gnome-terminal and nautilus, you would have to add separate bugpatterns for those (and any other app using libdbusmenu)
[11:46] <mdz> now you can just write one which will (e.g.) match on the stack trace, regardless of which program crashed
[11:51] <seb128> mdz, ok, I thought we had a pattern for this XAllocId ret != invalid crash for example
[11:51] <seb128> but that's might be why it didn't seem to work ;-)
[11:51] <seb128> mdz, thanks for working on that
[11:52] <seb128> mdz, btw your bug got retraced
[11:52] <mdz> seb128, in some places we suppressed the bugs in other ways, e.g. in a general hook or in apt
[11:52] <mdz> seb128, I'm not familiar with the XAllocId issue and I don't see that string in the existing bug patterns; is it an active problem?
[11:52] <mdz> maybe it would be a good test case :-)
[11:59] <seb128> mdz,
[11:59] <seb128> <!-- Converted from libxcb.xml -->
[11:59] <seb128>     <pattern url="http://launchpad.net/bugs/507062">
[11:59] <seb128>         <re key="AssertionMessage">_XAllocID:.*ret.*inval_id</re>
[11:59] <seb128> mdz, I was speaking about this one
[11:59] <cjwatson> on merges.ubuntu.com: I've tracked down what was causing the failure, prepared a backport of the relevant dpkg fix, and filed a ticket for our sysadmins to deploy that
[12:00] <cjwatson> there may still be some work needed to avoid it running out of disk during the next run
[12:00] <mdz> seb128, ah, I should have searched with -i. ;-)
[12:00] <mdz> seb128, so that pattern will only get checked for bugs which are about to be reported on libxcb
[12:00] <cjwatson> (Debian #594440 bit our eucalyptus package)
[12:01] <seb128> mdz, ok, that explains why we keep getting bugs reported against random binaries crashing this way
[12:01] <mdz> seb128, er...actually pitti converted it to be package-independent already :-)
[12:02] <pitti> mdz: retracers> checking; they crash very often these days
[12:03] <mdz> pitti, I did the bugpatterns conversion based on r178, and there was no libxcb.xml in that version. did I make a bad merge or something?
[12:03] <seb128> pitti, I sorted the retracers
[12:03] <mdz> I don't see a mention of libxcb in the commit log, other than yours...
[12:03] <pitti> mdz: I guess it was PEBCAK on my end, and I forgot to bzr add back then
[12:03] <seb128> pitti, it's weird, it had a lock from yesterday and no error in the log
[12:04] <seb128> pitti, removed the lock and it's fine
[12:04] <pitti> seb128: amd64 is running, but i386 is locked and not running
[12:04] <seb128> it's running
[12:04] <debfx> cjwatson: on the weekend I painfully noticed that all kde-l10n-* packages are also missing from the kubuntu package set
[12:04] <pitti> seb128: i386? I don't see it running
[12:04] <seb128> pitti, ok, it might have had the same issue, the log had been updated recently when I checked on i386
[12:04] <seb128> pitti, no, the timestamp was recent on i386
[12:04] <debfx> cjwatson: I'd really appreciate if you could add them and the ones I emailed you
[12:04]  * pitti starts manually and checks
[12:05] <seb128> amd64 was from yesterday and I restarted it
[12:05] <seb128> which worked
[12:05] <pitti> seb128: bah, same "huge wadl HTML output spew" issue :/
[12:06] <pitti> cache purged, restarted
[12:07] <seb128> pitti, danke
[12:11] <artfwo> seb128, I noticed you've just made bug 730528 affect libappindicator, but https://bugs.launchpad.net/libappindicator page is empty and states that libappindicator is not configured in order for Launchpad - how's that?
[12:11] <seb128> artfwo, I guess they didn't create a new component out of indicator-application when the source was splitted out
[12:12] <seb128> artfwo, I basically just said "also affect component" and used what was suggested
[12:12] <artfwo> ah, I see
[12:12] <artfwo> thanks
[12:12] <seb128> artfwo, I will check with kenvandine and ted if libappindicator should work as a project or if they want to use indicator-application
[12:13] <artfwo> seb128, until than is it okay to use "also affects libappindicator" for upstream related bugs?
[12:13] <artfwo> s/than/then
[12:13] <seb128> it's fine, either libappindicator or indicator-application
[12:13] <seb128> both will reach the same people
[12:19] <cjwatson> debfx: I've done the ones you mailed me, but hmm, making a wildcard exception isn't supported by my current code AFAIK
[12:19] <cjwatson> and there's no way I'm maintaining that package list by hand
[12:28] <cjwatson> debfx: I think this is a matter for fixing the code that generates the package sets, not for making exceptions
[12:29] <cjwatson> (it's my problem either way, but just to let you know)
[12:39] <lamont> how does one reset the password on the gnome keyring?  wifely one is annoyed at the computer today
[12:41] <debfx> cjwatson: ok
[12:43] <seb128> lamont, reset?
[12:43] <lamont> change
[12:44] <seb128> you mean the password to unlock the keyring?
[12:44] <seb128> you can do that using seahorse
[12:45] <seb128> but it's the same as your login one by default and should be updated when passdw is used to change it
[12:51] <lamont> ah, ok.
[12:51] <lamont> that now all makes sense
[12:52] <lamont> OTOH, password is coming from libnss-db, not via passwd command. so seahorse to change it is the right way, yes?
[13:01] <cjwatson> debfx: fixed now, along with everything else in your supported seed
[13:26] <cnd> do I need to request for an archive admin to review a package in the new queue, or will that be done automatically?
[13:27] <debfx> cjwatson: that was fast, thanks
[13:41] <cjwatson> cnd: you only need to request if you have a good reason to want to jump the queue
[13:41] <cnd> cjwatson, ok, I assume it will be handled in due time then
[13:41] <cnd> thanks
[14:07] <chrisccoulson> @pilot in
[14:07] <chrisccoulson> \o/
[14:10] <pitti> chrisccoulson: happy piloting
[14:13] <debfx> cjwatson: I think the kubuntu mobile seed isn't part of the package set anymore
[14:15] <c2tarun> I got this error while building a package http://paste.kde.org/6690/, when looked into file I found this line creating the problem http://paste.kde.org/6689/
[14:16] <c2tarun> I need help with the second argument passed in the function, what does it mean? is it typecasting?
[14:22] <mr_pouit> c2tarun: GTK_DISABLE_DEPRECATED is set, and GtkFunction is deprecated since gtk+ 2.24.
[14:22] <cjwatson> debfx: probably not.  should it be the same set or a new one?
[14:23] <c2tarun> mr_pouit: sorry :( what does it mean?
[14:26] <debfx> cjwatson: for example plasma-mobile was in the kubuntu set before. imho it doesn't make sense to create a new one
[14:30] <cjwatson> pitti: please note my changes to bug 723016, since it looks like it was you who turned it from a merge request into a sync request
[14:31] <pitti> cjwatson: right, sorry; comment 1 seemed to indicate a sync request; reverted my changes
[14:31] <cjwatson> yeah, I think that may have been non-jargon use of "sync"
[14:48] <ari-tczew> pitti: thank you very much for sponsoring!
[14:48] <pitti> ari-tczew: you're welcome, thanks for working on the merge!
[14:48] <ari-tczew> ;-)
[14:54] <doko> mterry: would you have time on a quick component-mismatches cleanup today? would like to do that before starting the rebuild test
[14:55] <mterry> doko, I suppose?  you mean processing MIRs or something else?
[14:57] <doko> mterry: there are no MIR's yet, I assume we could hunt down tkamppeter for the printing stuff, and maybe ScottK for the perl stuff
[14:58] <mterry> doko, but yeah, I can help
[14:58] <doko> otp now, later ...
[15:00] <cjwatson> barry: FYI, I've started looking at that Wubi bug
[15:01] <cjwatson> barry: I'm wondering if the use of grub4dos-derived code here is fundamentally misguided (it's *extremely* hard to debug) - it might be simpler to arrange to load GRUB 2 from NTLDR directly
[15:03] <ari-tczew> doko: where can I find every fresh archive rebuild?
[15:07] <barry> cjwatson: sounds good.  let me know if you have something you'd like me to test.  i'm patch piloting today
[15:21] <tkamppeter> doko, what is the problem with the printing stuff?
[15:23] <doko> tkamppeter: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt  all the cmap-* stuff
[15:23] <doko> mterry: could you address the zope.fixers MIR?
[15:24] <tkamppeter> doko, do they all need to get MIRed?
[15:26] <doko> tkamppeter: yes, unless you remove them from gs-cjk-resource b-d's. or demote gs-cjk-resource
[15:26] <tkamppeter> doko, seems that these files are fonts for Ghostscript being able to display documents in CJK languages.
[15:26] <doko> tkamppeter: then please write a short MIR, and have a look at the packages
[15:27] <tkamppeter> I have MIRed gs-cjk-resource recently as I have merged GS from Debian.
[15:28] <tkamppeter> OK, Is it OK to make one MIR for all? They are pure data, so no security problems possible.
[15:30] <tkamppeter> doko: ^^
[15:31] <doko> tkamppeter: sure, as long as you review the package
[15:31] <doko> (s)
[15:32] <mterry> doko, ack re: zope.fixers
[15:33] <doko> TheMuso: you did sync libffado.  but MIR's for libconfig and dbus-c++ are missing
[15:33] <doko> mterry: thanks
[15:34] <doko> Riddell: kdesvn: kdesvn-kio-plugins libsvnqt6
[15:34] <doko>    [Reverse-Depends: kdesdk, kdesvn-kio-plugins]
[15:34] <doko> didrocks, seb128, pitti:  o libquvi: libquvi-dev libquvi-doc libquvi0
[15:34] <doko>    [Reverse-Depends: Rescued from libquvi, libquvi-dev]
[15:34] <doko>    [Reverse-Build-Depends: totem-pl-parser]
[15:34] <doko> MIR?
[15:35] <doko> I'll look at the lintian related libperl-* stuff
[15:37] <seb128> doko, bug #722591
[15:37] <seb128> ?
[15:37] <hallyn> soren: hey, my upload rights for vmbuilder are not yet in effect - would you mind uploading people.canonical.com:~serge/vm-builder_0.12.4+bzr463.tgz  ?
[15:38] <doko> oops
[15:38] <doko> seb128: well, then fix it?
[15:39] <seb128> doko, there was no review from the mir team yet
[15:39] <doko> mterry: ^^^ please?
[15:39] <seb128> doko, what needs fixing? pitti just pointed some issues but said they were not blockers
[15:39] <seb128> doko, it's assigned to kees
[15:39] <doko> ahh, ok, anyway, it's assigned to kees
[15:44] <barry> @pilot in
[15:44] <pitti> wow, three pilots?
[15:45] <barry> sure, why not? :)
[15:45] <micahg> barry: hi, can you help me with a test case for a python exception for an SRU?
[15:46] <barry> micahg: sure
[15:46] <barry> micahg: do you have an issue #?
[15:46] <micahg> barry: bug 702990
[15:46] <psusi> pitti: oh boy, I think this was your area so maybe you can help.. I've been trying to run down a bug about why the gconf keys for g-p-m to NOT lock the screen and run the screen saver no longer work.  If I understood all the code I poured through last night, it looks like gpm has had its interface for initiating suspend removed and that is now handled by UPower now, is that correct?
[15:48] <psusi> pitti: my theory is that the correct solution is to rejigger gpm to monitor the suspending signal from UPower and lock/ss if configured to do so, and the code to lock/ss needs removed from indicator-session, does that sound reasonable?
[15:49] <cjwatson> hmm,/wg 20
[15:49] <cjwatson> oops
[15:49] <barry> micahg: i'm not sure exactly what you're looking for.  a unittest for wireshark that exposes the problem?  a recipe some human could perform to show the problem has been fixed?  something else?
[15:50] <micahg> barry: idk, I'd like to SRU this so we can continue to fakesync security updates from squeeze, is something like this fragile and likely to break anything?
[15:51] <micahg> oh, there's no debdiff, let me fix that
[15:52] <barry> micahg: changing string exceptions to class exceptions can indeed break things, or it could be perfectly safe ;).  it depends on how the code uses the exceptions.  if it's primarily just raising and catching them, you should be safe.  if it does some kinds of introspection (i.e. checking the type) then you could be broken if that code wasn't also changed
[15:52] <barry> of course, as the issue points out, string exceptions could have lots of reliability problems too, if not done right
[15:52] <barry> cool.  a debdiff will help
[15:55] <ari-tczew> micahg: did you see it? bug 730413
[15:55] <micahg> ari-tczew: yes, I chatted with udienz already, thanks
[15:56]  * micahg has a little bug cleanup work later though
[15:58] <micahg> barry: diff attached
[15:59] <barry> micahg: omg.  yeah, those old string exceptions are completely broken, even in a python that supports string exceptions. :)
[16:00] <micahg> barry: so, is it possible to safely SRU?
[16:01] <barry> micahg: it's difficult to tell without a full code review.  e.g. are those string exceptions caught anywhere?  i'd be *very* surprised if the code had an 'except' that expected to catch those, 'cause it'd essentially be impossible.  i guess what i'm saying is that i can't see how the patch could make anything worse :)
[16:01] <pitti> psusi: hm, g-p-m didn't change since maverick
[16:01] <barry> micahg: is that good enough? ;)
[16:01] <pitti> psusi: but yes, I believe the "initiate suspend" etc. stuff moved to gnome-session a while ago
[16:01] <micahg> barry: umm, let's see
[16:02] <micahg> pitti: what do you think about the above wireshark SRU bug and barry's comments?
[16:03] <barry> micahg, pitti i suppose it's also possible that some code which would not otherwise catch the string exceptions, could start catching those new class exceptions.  but it seems very weird that you'd write an except clause for which you would specifically not want to catch those string exceptions.
[16:04] <barry> micahg, pitti if that makes sense. ;)
[16:04] <pitti> yes, it does
[16:04] <barry> micahg, pitti so again, short of a full code audit, it doesn't seem like this patch can make things worse
[16:04] <pitti> string exceptions are not a thing you'd ever want to catch and handle
[16:05] <barry> most definitely not, though it *was* possible if done right
[16:05] <pitti> seems okay to me
[16:06] <pitti> and it's a standalone GUI app, i. e. not something that is used as a library and needs to maintain a stable public api
[16:06] <barry> i suppose if you wanted to be really really safe, you could definite a local exception class that inherits from BaseException.  that way 'except Exception' wouldn't catch it.
[16:06] <barry> pitti: in that case, i think the patch is fine
[16:06] <micahg> pitti: so, what's the process for SRU since I don't have a test case?  the goal is to be able to continue to fakesync security updates from squeeze
[16:08] <pitti> micahg: primarily "make sure that the program still works", by running through some standard use cases with it
[16:08] <micahg> pitti: ok, can do, thansk
[16:08] <micahg> *thanks
[16:13] <psusi> pitti: yea, this has been going on at least since lucid
[16:15] <psusi> pitti: it looks like idicator-session is what provides the menu on the pannel, and that appears to lock the screen, start the screen saver, and then send the Suspend message to UPower to actually suspend the system.  I think gpm used to be the thing that supplied the Suspend method and in response, it would lock the screen if configured to do so, but it looks like since UPower was introduced, this is no longer the case
[16:17] <ari-tczew> pitti: can we drop changes with Break: udev ?
[16:17] <pitti> ari-tczew: yes, lucid's udev is much newer already
[16:17] <ari-tczew> pitti: ok thanks
[16:33] <ScottK> doko: I'm very unlikely to have time to work on MIRs this week.
[16:34] <doko> yeah, I know, trying to keep other people busy ...
[16:35] <amitk> njpatel: do you already know of a unity bug where the app panel doesn't auto disappear?
[16:36] <amitk> njpatel: and the bug where search just doesn't work?
[16:36] <njpatel> amitk, when you fullscreen? Is this on multiple monitors?
[16:36] <njpatel> amitk, re:search, do you have unity-place-files and unity-place-applications installed?
[16:37] <amitk> njpatel: yes, 2 monitors
[16:37] <njpatel> amitk, then, yeah, it's known hopefully fixed this week
[16:38] <amitk> njpatel: for some reason those two were not installed (I've been upgrading natty since alpha 2)
[16:38] <njpatel> weird :/ You'll need to restart unity after installing them (unity --replace from a terminal should do it)
[16:42] <amitk> njpatel: much better, thx
[16:42] <abhinav-> asac: http://gwibber.com/develop/ won't open ?
[16:44] <njpatel> np :)
[16:56] <SpamapS> zul: so, you're thinking the mysql maintainer scripts / upstart job need reworking, right?
[16:56] <zul> SpamapS: thats what i was thinking
[16:56] <tseliot> cjwatson: do you know if it's ok to install 2 alternatives (as in update-alternatives) in the same package? Is the debian policy against this?
[16:58] <SpamapS> zul: so I think we should just follow dh_installinit's model and let the preinst stop, and the postinst start...
[16:58] <SpamapS> zul: on a slightly related note, did you see that mysql 5.5.10 will have a libmysqlclient.so.18 ?
[16:59] <zul> SpamapS: cool beans
[16:59] <zul> SpamapS: yeah i saw that, that....will be fun
[17:08] <SpamapS> zul: I suspect this bit is the issue...
[17:08] <SpamapS> # to be sure
[17:08] <SpamapS> stop_server
[17:09] <chrisccoulson> cjwatson, is there a reason that metacity isn't in the ubuntu-desktop package set? i seem to recall it was at some point
[17:09] <chrisccoulson> (although, i could be mistaken there) ;)
[17:09] <RoAkSoAx> hggdh: Daviey bug #711587 comment #3
[17:14] <Daviey> RoAkSoAx, looking
[17:14] <cjwatson> tseliot: I can't think of a reason not to, I suppose
[17:15] <cjwatson> chrisccoulson: probably build-dependencies from rest-of-world
[17:15] <cjwatson> or just dependencies perhaps
[17:15] <cjwatson> ubiquity depending on it might well pull it up
[17:15] <tseliot> cjwatson: ok, thanks
[17:15] <cjwatson> chrisccoulson: I can make an exception for it if you're requesting it
[17:16] <Daviey> RoAkSoAx, Reading your comment, isn't this now a powernap bug rather than euca?
[17:16] <RoAkSoAx> Daviey: is not a bug in PowerNap :)
[17:17] <RoAkSoAx> Daviey: the thing is that before, PowerNap by default always run monitoring /sbin/init which cause to never perform any action to the machine and Eucalyptus never had any "issues" because it only told powernap "sleep now"
[17:18] <chrisccoulson> cjwatson, i would like that, if you can do that
[17:18] <RoAkSoAx> Daviey: so in fact, the relationship between powernap and eucalyptus before, was that powernap did nothing than run all the time waiting for a command from eucalyptus
[17:18] <RoAkSoAx> Daviey: now, since powernap has evolved, other things need to be considered when configuring it to work with euca
[17:19] <RoAkSoAx> so this is rather "best-practices" when working together
[17:19] <kirkland> RoAkSoAx: honestly, Eucalyptus wants powernap to stay out of their way
[17:19] <cjwatson> chrisccoulson: done
[17:19] <kirkland> RoAkSoAx: all they want to do is call powernap-now
[17:19] <chrisccoulson> cjwatson, excellent, thanks :)
[17:19] <Daviey> RoAkSoAx, Yeah.... so either, powernap needs to revert to the previous behaviour ... or have a config.d/ where euca can throw in a /sbin/init as it's process... Can't think of another decent fix
[17:19] <Daviey> RoAkSoAx, Can you?
[17:19] <kirkland> RoAkSoAx: they don't want to leverage the flexibility of powernap, and that saddens me
[17:19] <kirkland> RoAkSoAx: but so be it
[17:19] <kirkland> RoAkSoAx: that's how they want to do it
[17:19] <RoAkSoAx> kirkland: ah I was planning to email you my findings in a little bit more detail
[17:20] <kirkland> RoAkSoAx: okay
[17:20] <kirkland> RoAkSoAx: you can do that
[17:20] <Daviey> RoAkSoAx, TBH... remember that this is a point release of euca... so expecting them to add new functionality is somewhat unfair
[17:20] <kirkland> RoAkSoAx: Daviey's suggestion is reasonable
[17:21] <RoAkSoAx> Daviey: I don't really want functionality added to euca just now, but it is just "recommended PowerNap config when runnning with euca"
[17:21] <hggdh> actually a bit more than that
[17:22] <hggdh> the current powernap config may cause problems with euca, so one of them should be adjusted. Given that it is just euca that gives us problems, we should adjust it there
[17:22] <Daviey> RoAkSoAx, I'd recommend adding a config.d for powernap... That seems the least intrusive, and still enables powernap to be more useful in other scenarios
[17:23] <RoAkSoAx> Daviey: yeah maybe it indeed is. Let me finish writing the email so that you can have a clearer picture of whats happening :)
[17:24] <Daviey> RoAkSoAx, coolio
[17:24]  * Daviey wonders if he /really/ just said coolio. :/
[17:25] <ogra> it had a british accent
[17:25] <ogra> so its ok :)
[17:26] <dholbach> Daviey, I think after 15 years it's OK to refer to one hit wonders again ;-)
[17:27] <Daviey> heh
[17:28] <mterry> doko, so I'm finally getting to zope.fixers, and I'm having some problems with python3 and the control file.  I fixed some low-hanging fruit like enabling the test suite, but substitution variables in debian/control are bugging me.  python3:Versions isn't being defined by dh_python3.  Do you know why that would be?   Here's the current control file I'm working with: http://pastebin.ubuntu.com/577070/
[17:28] <doko> mterry: ugh, sorry, I did interpret your ack as an ok
[17:30] <doko> mterry: please go ahead and upload if possible
[17:31] <GunnarHj> ScottK: Uploaded at last; thanks! :-)
[17:31] <GunnarHj> ScottK: Seems like those l-s and gdm changes didn't fit well either for -updates or -backports, and that I was granted an exception. Is it so, and if it is, are the related procedures optimal?
[17:32] <ScottK> I think backports was best.  It's just a difficult situation since it's such a core package.  Not sure how much better it could have been.
[17:34] <mterry> barry, hello!  Got a sec?
[17:38] <Daviey> RoAkSoAx, Thought about adding powernap support for openstack?
[17:39] <barry> mterry: sure thing
[17:39] <RoAkSoAx> Daviey: well I haven't yet seen OpenStack architecture so idk :). kirkland ideas?
[17:41] <mterry> barry, look up a bit, I was asking doko about python3:Versions issues I was having with python3-zope.fixers.  It's not being defined by dh_python3 it seems?  Nor is Suggests or Provides...
[17:41] <kirkland> Daviey: we discussed it in San Antonio
[17:41] <kirkland> Daviey: the crowd was quite keen on the idea, as i recall
[17:42] <barry> mterry: let me ask over in #debian-python
[17:43] <mterry> ooh, new channel.  I'll join too
[17:43] <barry> mterry: it's on oftc not freenode.  but if you join, do you want to just re-ask over there?
[17:43] <mterry> ok
[17:44] <barry> mterry: awesome.  i'll follow along
[17:46] <Daviey> kirkland, yeah... as RoAkSoAx is working on powernap - wondered if it was a potential upstream contribution he'd like to undertake.
[17:46] <kirkland> Daviey: RoAkSoAx: strong +1 from me
[18:11] <abhinav-> barry, thanks for the review of the Tomboy merge proposal :)
[18:11] <abhinav-> TheMuso, has communicated to the upstream about the patch https://bugzilla.gnome.org/show_bug.cgi?id=588730
[18:12] <barry> abhinav-: np!  thanks for nice improvement.  hopefully my review is helpful?
[18:12] <abhinav-> yes
[18:12] <abhinav-> that was quite detailed and I learnt to notice fine details before submitting patches :)
[18:12] <GunnarHj> ScottK: I see. Of course it would have been possible to do it the other way, i.e. starting with the latest Natty revision and revert changes that don't work in Lucid/Maverick. But since that would have involved stuff that I know almost nothing about (Python 2.7 -> 2.6, quite a few dependencies, etc.) I chose to add the changes I wanted to see backported. Maybe an experienced developer would have done it otherwise.
[18:13] <barry> abhinav-: :)  sounds like the tomboy devs are receptive to the improvement!  nicely done
[18:13] <ScottK> GunnarHj: I think it was a reasonable approach.
[18:14] <abhinav-> barry, however, I have replaced the messagebox with a message and a button inside the tomboy itself.  i am still looking on ways to improve it.
[18:14] <GunnarHj> ScottK: Ok. Anyway, glad it could be done. Thx again.
[18:15] <abhinav-> soren, I was wondering, should I submit the new changes as a new merge proposal (in a new branch) or just push through this branch only ?
[18:15] <barry> abhinav-: cool
[18:16] <barry> abhinav-: no sure that comment was directed at me, but you can always just update your current branch and push the update.  the merge proposal will adjust.  unless the change is totally different, in which case, you can push a new branch and supersede the merge proposal with the new branch
[18:18] <abhinav-> barry, ok. thanks for the help and guidance. after yours and dholbach's session, I have got a start in ubuntu development :)
[18:19] <barry> abhinav-: yay!  do feel free to ask any questions about udd
[18:19] <abhinav-> yup sure :)
[18:25] <chrisccoulson> @pilot out
[18:38] <RoAkSoAx> kirkland: Daviey email sent
[18:53] <Daviey> wow RoAkSoAx, you like the long emails :)
[18:57] <cnd> Riddell, did you know there's a *HUGE* debian-changes-4:4.7.2-0ubuntu1 file in qt4-x11?
[18:57] <cnd> 1,113,501 lines
[18:57] <cnd> seems like something is off
[19:00] <doko> cnd, Riddell: if if plan to fix that, please wait until today's gcc-4.5 is built on armel, or add a versioned b-d
[19:00] <doko> ogra: ^^^
[19:01] <cnd> doko, I'll keep that in mind
[19:01] <doko> and ogra did want to revert something ...
[19:13] <psusi> say umm... don't you have to dereference or free the connection pointer you get from dbus_g_bus_get()?
[19:16] <cjwatson> the documentation says "Returns a connection to the given bus. The connection is a global variable shared with other callers of this function."
[19:16] <psusi> so that's a no then? ;)
[19:16] <cjwatson> it's a "let Colin finish typing"
[19:17]  * psusi will get this gnome stuff figured out yet
[19:17] <janimo> cnd, that is probably because of upstream changes between 4.7.1 and 4.7.2 which are in that diff
[19:18] <cnd> janimo, shouldn't the source package have been updated with the upstream changes?
[19:18] <cjwatson> looking at the source, dbus_g_bus_get doesn't take a reference
[19:18] <cjwatson> wait, does it
[19:19] <cjwatson> dbus_g_connection_unref is a typed shim through to dbus_connection_unref
[19:20] <cjwatson> and dbus_g_bus_get calls dbus_bus_get which takes a reference to the connection
[19:21] <cjwatson> psusi: so the answer is, yes, you should dbus_g_connection_unref the return value of dbus_g_bus_get when you're finished with it
[19:21] <cjwatson> it may be a global variable but it still has a reference count
[19:21] <cjwatson> AFAICS
[19:22] <cjwatson> and it's only global in the same way that dbus_bus_get returns a global, and its documentation says "The caller of this function owns a reference to the bus."
[19:22] <debfx> doko: the new gcc upload makes virtualbox-ose ftbfs: http://paste.ubuntu.com/577138/
[19:23] <debfx> should I open a bug report?
[19:24] <doko> debfx: please do so, with the preprocessed source attached
[19:24] <psusi> cjwatson: hrm.. then it is a bug that gpm-manager.c in g-p-m doesn't do that?
[19:30] <doko> debfx: do you prepare the report?
[19:32] <debfx> doko: I'm on it, what preprocessed source should I attach?
[19:32] <doko> .i
[19:32] <doko> build it with -save-temps
[19:33] <janimo> cnd, yes. But I have the impression the diffs LP outputs are for the whole package not just debian/ diffs
[19:33] <cnd> janimo, I'm looking at one of the patches in debian/patches
[19:34] <cnd> it's an autogenerated patch from dh
[19:34] <janimo> cnd, in that case I take back what I said
[19:34] <cnd> it makes me wonder if the qt 4.7.2 merge is correct, since it often suggests that you've updated the tarball but not the package
[19:34] <cnd> so the autogenerated patch ends up undoing all the changes
[19:35] <janimo> cnd, now I see that patch too, indeed quite large
[19:37] <janimo> cnd, did you see regressions because of that patch?
[19:37] <cnd> janimo, no, I went to check the source
[19:38] <cnd> and fix an issue with the xi 2.1 multitouch patch
[19:38] <cnd> when I saw that huge thing
[19:40] <debfx> doko: bug #730860
[19:40] <janimo> cnd, the first lines in it suggest it is autogenerated as a summary of upstream changes, but I don't know why it is included there
[19:41] <doko> debfx: amd64 only?
[19:41] <janimo> one of the Kubuntu folk may know, Riddell is away this week AFAIK
[19:41] <janimo> ScottK, ^
[19:41] <debfx> doko: haven't tested i386 yet
[19:42] <cnd> janimo, the header of the patch is just autogenerated
[19:47] <cjwatson> psusi: I guess so.  it may not be serious
[19:48] <cjwatson> cnd: dpkg-source is what autogenerates the patch, not dh.
[19:48] <cjwatson> (FYI)
[19:49] <cnd> cjwatson, since you stepped into the conversation :), do you have any ideas as to how a 1+ million line patch could be generated?
[19:57] <debfx> cnd: that patch should be dropped
[19:57] <cnd> debfx, yes, but it's not as easy as just saying it should be :)
[19:57] <cnd> the question is: how did it get there in the first place
[19:58] <cnd> and is the package being built correctly
[19:59] <debfx> cnd: either it's some 4.7.1 vs 4.7.2 mixup or the build process changed some files that weren't cleaned properly
[20:00] <debfx> I've looked at the diffstat, there is nothing we want to keep
[20:00] <cnd> debfx, yeah, so I'm thinking we need to wait till Riddell can take a look, since he's the one who updated to 4.7.2
[20:00] <cnd> just to be sure
[20:02] <psusi> hrm... I think I need to add an argument to org.freedesktop.UPower.Sleeping to say whether it's hibernate or suspend... hrm... now to figure out how to extract such an argument from a GVariant...
[20:07] <bryceh_> @pilot in
[20:09] <micahg> wow, 4 patch pilots in one day :)
[20:09] <bryceh_> heh
[20:10]  * micahg guesses it makes sense
[20:10] <bryceh_> suspect a couple just forgot to log out
[20:11] <micahg> Is there an AA to apply some overrides
[20:11] <bryceh_> AA?
[20:11] <micahg> archive adin
[20:11] <micahg> *admin
[20:11] <bryceh_> not me, bug cjwatson might still be around
[20:11] <bryceh_> er, s/bug/but/
[20:14] <ScottK> janimo: debfx is probably your best bet if Riddell isn't around.
[20:14] <janimo> ScottK, ok
[20:14] <janimo> cnd, ^ :)
[20:15] <cnd> debfx, janimo: are either of you familiar with qt4-x11?
[20:15] <cnd> I really don't know the regular maintainers of the package
[20:15] <cnd> I just provided one patch
[20:15] <cnd> so if you guys are the regular maintainers, then by all means have at it :)
[20:15] <janimo> cnd, me too :)
[20:16] <micahg> ScottK: can you apply archive overrides?
[20:16] <ScottK> micahg: No.
[20:18] <debfx> cnd: yes, what needs to be done? :)
[20:20] <sbeattie> micahg: best to ask in #ubuntu-release.
[20:31] <cnd> debfx, just figure out what's up with that odd debian patch
[20:32] <cnd> make sure qt is building correctly
[20:34] <psusi> oh boy, lots of patch pilots.. I wonder if my fixes to dmraid and parted will get merged today...
[20:43] <psusi> does this look about right to register for a dbus signal? http://pastebin.ubuntu.com/577165/
[20:48] <debfx_> rsalveti: do you have patches for the packages that broke by switching to gles in qt? bug #707794
[21:12] <rsalveti> debfx: not yet
[21:13] <rsalveti> but plan to help porting all those packages
[21:26] <MeltingKeyboard> Anything I can do to help?
[21:26] <MeltingKeyboard> where would I look to find stuff to do?
[21:27] <doko> TheMuso: ping
[21:28] <doko> mterry: you accepted the wrong ones \o/ ;-P
[21:29] <mterry> doko, yeah, sorry  :)
[21:29] <mterry> those perl packages were delightfully well-maintained though
[21:30] <arand> MeltingKeyboard: Harvest might be one place to look: http://harvest.ubuntu.com/ , I'm not completely sure what you're asking about though
[21:31] <MeltingKeyboard> ok
[21:31] <MeltingKeyboard> I will look there
[21:31] <MeltingKeyboard> I was just wondering if there was something I could help with with the new release date looming
[21:31] <MeltingKeyboard> thanks
[21:32] <doko> mterry: so the missing symbols files are the only complaints?
[21:33] <mterry> doko, and dbus-c++ is orphaned in debian.  Doesn't inspire confidence
[21:34] <doko> mterry: sure, but we had it in main before
[21:34] <mterry> doko, it was in main as part of another package, whose maintainer presumably took care of it, right?
[21:34] <mterry> now no one claims to
[21:35] <doko> and makes ubuntustudio uninstallable
[21:36] <doko> or was it for mythbuntu?
[21:36] <arand> MeltingKeyboard: https://wiki.ubuntu.com/UbuntuDevelopment is a more general overview. It may be a good idea to pick a specific area and engage the relevant people with your specific ideas about what you would help with.
[21:39] <barry> @pilot out
[21:44] <soren> abhinav-: Sorry, what's the context?
[22:11] <apachelogger> cjwatson: can I somehow get the pid of a process using libpipeline?
[22:54] <doko> mterry: one is missing, which I didn't see.  please could you look at bug #729907 too?


[05:07] <int_ua> What launchpad users have the right to review strings?
[05:07] <int_ua> I'm a member of ukrainian team but I can't find a way to review deja-dup translations


[05:52] <nullack> ping persia
[05:53]  * persia much prefers contentful pings
[05:53] <nullack> persia : do you know about debian packaging?
[05:54] <persia> nullack: Yes.  Why?
[12:35] <salty-horse> hi. I can't seem to turn on restricted drivers in intrepid. after clicking "install and turn on", a progress bar appears with a message that it's downloading the driver, and when the focus returns to the main dialog the driver still has a red circle near it
[12:35] <salty-horse> is there a command line tool for restricted drivers management, so I could see any errors that pop up?
[21:42] <tgm4883_laptop> slangasek, can mythbuntu get a 20-sep-2008 daily alt build


[01:52] <stokachu> when did config option 'use-https' get removed from swift-proxy?
[02:07] <stokachu> i think there needs to be some sort of deprecation process for removing existing charm config options
[02:08] <rick_h_> stokachu: the old revision is available still?
[02:08] <stokachu> rick_h_: yea but the installer doesn't have a way to lock into a revision currently
[02:08] <stokachu> probably need to add that on our end
[02:09] <rick_h_> ah
[02:09] <rick_h_> not to argue with you and such that removal of options of charms, expecially promulgated ones, should be standardized to some extent.
[02:09] <rick_h_> but we keep the history so that you can lock revisions and know it'll always work like pinned packages
[08:05] <yaell> Hi guys I need some help. I am trying to add a new container to an existing machine on a maas environment using the command : juju add-machine lxc:1 but I always get the same error message :container failed to start. Does anyone have an idea why this is happening?
[09:05] <gnuoy> gsamfira, are you about at the dev kilo summi
[09:05] <gnuoy> t
[09:05] <gnuoy> ?
[09:05] <gnuoy> I'm having some synctool problems
[11:10] <_1_Sid> QUESTION: hello everybody. i think juju is great. i was wondering if it was also usable for deploying and managing virtual machines on different computers across the network? I would love to manage our VM with the juju GUI.
[11:26] <yaell>  Hi guys I need some help. I am trying to add a new container to an existing machine on a maas environment using the command : juju add-machine lxc:1 but I always get the same error message :container failed to start. Does anyone have an idea why this is happening?
[15:21] <ayr-ton> Theres some plans out there to a agentless juju-master? Like ansible? Recently I run through a problem with my state machine and then I lose access to my agents.
[15:33] <lazyPower> ayr-ton: i dont believe there are any plans to go agentless, no.
[15:33] <lazyPower> that is an unfortunate side-effect of when your bootstrap node goes away, as it handles the proxying to hosts
[15:34] <jrwren> isn't that why we will be supporting HA for bootstrap node?
[15:35] <lazyPower> jrwren: we already support HA Bootstrap nodes
[15:35] <jrwren> lazyPower: ah. in that case, isn't that why we support HA for bootstrap nodes?
[15:35] <lazyPower> juju ensure-availability -  ensure the availability of Juju state servers
[15:36] <lazyPower> That is correct, however its up to the user performing the orchestration to enable this, as its not default behavior.
[15:36] <marcoceppi> also, it won't help if the juju-agent on the node goes away
[15:36] <lazyPower> ^ and that
[15:44] <ayr-ton> lazyPower, other problem is when a juju agent change ip or something like that. I run through that because of some new rules from management guys.
[15:45] <ayr-ton> My state machine is on, but all the agents are with new ips =/
[15:45] <jrwren> i've never run on a cloud where a host changes its IP. ouch.
[15:45] <ayr-ton> and also, my state machine.
[15:45] <lazyPower> ayr-ton: the agent i do believe transmits the IP change back to the bootstrap node, i've had machines reboot on AWS, get a new address and I didn't notice any change in availability
[15:45] <ayr-ton> jrwren, Is because I'm using manual envs.
[15:45] <lazyPower> ah, i'm not 100% sure on the manual provider - that's a good question - let me follow up on that one
[15:46] <marcoceppi> ayr-ton: have you tried restarting the agents on those machines?
[15:46] <ayr-ton> lazyPower, And, if the juju master change IP, how to get connection with it again.
[15:46] <ayr-ton> marcoceppi, yep
[15:46] <ayr-ton> with it again?*
[15:47] <ayr-ton> Part with this problem is, when I make a juju status, I can't contact the juju master, because it have a new ip/domain.
[15:48] <rbasak> sinzui: bug 1390133
[15:48] <mup> Bug #1390133: Information about Vivid is not available in Precise <distro-info (Ubuntu):New> <https://launchpad.net/bugs/1390133>
[15:48] <sinzui> thank you rbasak
[15:48] <rbasak> We'll see what happens.
[15:49] <mgz> thanks rbasak
[15:49] <rbasak> Can chase later if nobody responds.
[15:49] <rbasak> AIUI, distro-info-data should be kept up-to-date on all supported releases.
[15:49] <rbasak> Though it might just be Juju that depends on that right now.
[15:52] <lazyPower> ayr-ton: I'm not getting an immediate answer, but I'll be more than happy to follow up with you
[15:52] <lazyPower> ayr-ton: in the event you log out, is there another method I can use to reach out with the answer? If so, hit me with a private message and i'll reach out there.
[16:09] <lazyPower> ayr-ton: i have a solution to triage this, but its some manual effort. We don''t expect the IP's to change out from under the machines - but there are a few config files to edit to repoint agents @ the state server, and to hook your client back up to teh state server.
[16:19] <ayr-ton> lazyPower, a /memoserv
[16:19] <ayr-ton> I normally always online because of the znc.
[16:19] <ayr-ton> lazyPower, So I will reply somehow.
[16:20] <lazyPower> ayr-ton: ack - i'm doing a writeup now for future reference
[16:20] <ayr-ton> lazyPower, Where I need to change the confs? I can test now.
[16:22] <lazyPower> ayr-ton: i'm still cycling on the writeup but here's a quick save with the info: https://gist.github.com/chuckbutler/542b9a62321f3e806daa
[16:26] <ayr-ton> ok
[16:27] <ayr-ton> Interesting. I will test this :D
[16:30] <ayr-ton> Solves my problem x)
[16:31] <lazyPower> gnarly
[16:31] <ayr-ton> lazyPower, http://askubuntu.com/questions/540209/ip-domainname-of-juju-master-or-slaves-changes
[16:31] <ayr-ton> Thank you (:
[16:31] <lazyPower> ayr-ton: i'll get an answer posted shortly as soon as i'm done with this writeup
[16:31] <ayr-ton> lazyPower, I already posted. And I put credits to you.
[16:31] <ayr-ton> Thank you very much.
[16:32] <lazyPower> No problem :)
[16:47] <lazyPower> ayr-ton: thanks for taking the time to drop that on AU - we'll give ya a nice little karma bump for going the extra mile
[17:36] <rbasak> sinzui: 1.20.11 now in trusty-proposed. Go! :)
[17:36] <rbasak> sinzui: also any comment on the distro-info bug?
[17:36] <rbasak> Oh, still building.
[17:37] <sinzui> rbasak, thank you, I do want to add a comment about the precise issue
[17:56] <ayr-ton> lazyPower, No problem to drop this on AU. Thank you for the karma x)
[19:18] <jose> aisrael: ping
[19:18] <aisrael> jose: pong
[19:19] <jose> aisrael: still working on reviewing that 00-setup MP?
[19:21] <aisrael> The mongodb one? Trying to, but I'm running into an issue with it in my local environment.
[19:22] <aisrael> bandwith-related, I think, as it's trying to deploy multiple charms and it's timing out while juju-deployer runs.
[19:24] <jose> aisrael: I
[19:24] <jose> I'm gonna try and deploy on EC2*
[19:25] <jose> though it was a simple permissions change
[19:26] <aisrael> jose: It is. The issue I'm hitting is unrelated to the charm specifically.
[19:42] <jose> tvansteenburgh: ping
[19:42] <tvansteenburgh> jose: pong
[19:42] <jose> tvansteenburgh: question about bundletester, is there a way to specify machine constraints?
[19:43] <jose> I have credits for t1.micros on EC2 and defaults are m1.smalls, they cost
[19:43] <tvansteenburgh> jose:	 as a matter of fact, i'm working on that right now
[19:43] <jose> \o/
[19:43] <jose> for now I'm bootstrapping first and then running, so it catches bootstrap constraints
[19:43] <tvansteenburgh> jose: i'll ping you when it's available, may be this afternoon
[19:43] <jose> awesome, thanks!
[19:44] <tvansteenburgh> np!
[21:12] <mhall119> arosales: marcoceppi: jose: how is the UOS session recruitment going?
[21:18] <arosales> mhall119: I am behind :-/
[21:54] <mhall119> arosales: assign it to jcastro (who's not online to refuse) :)
[21:55] <arosales> mhall119: I like the way you think. He is on vacation this week too
[21:55] <arosales> mhall119: but I will sync up with pat and sure the cloud sessions are set
[21:55] <arosales> if any folks here are interested in having a UOS session give me a ping
[21:56] <arosales> if you want to talk about a new workload on Ubuntu, or workshop using Juju to deploy workloads on ubuntu let me know
[21:56] <mhall119> on vacation? not at ODS?
[21:57] <mhall119> arosales: I do hope that LXD will have at least a session or two
[21:57] <arosales> mhall119: me too :-)
[21:57]  * arosales has already been bugging ubuntu server folks on that on.
[22:05] <arosales> mhall119: https://lists.linuxcontainers.org/pipermail/lxc-devel/2014-November/010817.html was a good post
[22:05] <arosales> mhall119: I am guessing you already saw that though, but just in case . . .
[22:23] <mhall119> yes, but a video is worth a million words (based on word->picture ration and framerates)
[22:37] <themonk> lazyPower, Hi
[22:46] <themonk> can anyone help me with this step, File a bug against charms at https://launchpad.net/charms/+filebug This is used to track the progress of your charm.
[22:46] <themonk> what should i write in summery?
[22:48] <themonk> In what package did you find this bug?
[23:35] <jose> mhall119: asked a couple people around, probably things will be scheduled by the beginning of next week knowing how things are


[00:09] <mparillo> You can search for adding persistence to a live USB.
[06:04] <user|83> why we have kubuntu if we have ubuntu
[06:06] <user|83> ?
[06:06] <user|83> ?
[06:09] <JackFrost> Because Ubuntu is GNOME, and that's just not right for the Kubuntu folks.
[07:11] <noaXess> morning... where i can find information about kernel builds for kubuntu or even ubuntu? waitiung for 6.6.7 ;)
[08:39] <Your_Dog> ugh i installed something and after restart my kde is now unresponsive
[08:39] <Your_Dog> it was ubuntu restricted addons
[10:05] <Your_Dog> ok found the asshole error: gstreamer-1.0/libgstvideoscale.so: cannot open shared object file: Too many open files
[11:07] <Your_Dog> ugh didnt really fix the issue but the system is useable now, man what a PITA what i just did
[11:07] <Your_Dog> makes me favor systems that relies fully on snap or flatpak
[13:03] <matt_> hhh
[13:03] <matt_> ,
[13:03] <matt_> .
[13:03] <matt_> l
[13:03] <matt_> l
[13:03] <matt_> l
[13:10] <BluesKaj> Hi all
[15:17] <Your_Dog> ok i didnt solve the problem, for some reason qt + mpv doesn't work now but it turns out there is phonon vlc plugin
[15:17] <Your_Dog> that does the job better
[15:17] <Your_Dog> vlc is so based