[00:39] <kscloud> Hey, can someone clue me in as to whether there is a debug command line option for USC? I'm getting a segmentation fault.
[00:41] <jbicha> kscloud: are you using the ubuntu-desktop ppa?
[00:42] <kscloud> I think so.
[00:43] <jbicha> that's a known bug with webkit 1.7.4; perhaps it will be fixed when the next webkit build happens in a few hours
[00:43] <kscloud> Oh, okay, I was worried it might be something much worse.
[00:57] <TheMuso> jbicha: Is there an ubuntu-desktop branch for gnome-shell for oneiric?
[00:57] <TheMuso> jbicha: I thought you would use that instead if there was one.
[01:00] <TheMuso> Hrm seems not, at least according to the packaging metadata.
[01:13] <jbicha> TheMuso: no I don't have a published branch for oneiric but I do have one now for oneiric
[01:14] <TheMuso> jbicha: Np, anyway please see my review comments, I think you forgot the SRU paperwork...
[01:20] <micahg> jbicha: I was going to ask why there's an ubuntu-desktop branch for gnome-shell, it's not in main, nor maintained by the desktop team
[01:38] <jbicha> micahg: because it's part of desktop-extras and a packaging-only branch makes things a lot easier
[01:38] <jbicha> if there's a better place for me to keep it, I can do it...
[01:39] <micahg> jbicha: desktop-extras packages shouldn't be in ubuntu-desktop IMHO, it's bikeshedding and kinda defeats the purpose of having a separate packageset that others can apply for
[01:41] <jbicha> but where should I put it? should I create a separate desktop-extras team?
[01:42] <micahg> hmm..we should already have a team, give me a minute
[01:42] <jbicha> there is a gnome3 team...
[01:43] <micahg> hmm, I have to look into this, it seems we're missing the desktop-extras team
[01:44] <micahg> jbicha: even that isn't necessarily a good solution as it's still bikeshedding (MOTU and ubuntu-mozilla-uploaders wouldn't be able to commit)
[01:47] <jbicha> why doesn't motu have branches? and would adding motu to a potential desktop-extras team be bad?
[01:52] <stgraber> I'd strongly recommend using the UDD branches as that way LP uses the same way to check for upload rights
[01:56] <jbicha> how do those branches work? uploading automatically updates the UDD branch but what if it was already updated?
[01:57] <jbicha> and I had this annoying problem: https://answers.launchpad.net/bzr-builddeb/+question/171856
[01:57] <stgraber> you can push changes to these branches, the changes get imported into the branch only if there isn't a tag matching the current upload with an identical content
[01:57] <stgraber> ah yeah, quilt can be a bit annoying, I seem to remember someone blogging about how to deal with that though
[01:58] <jbicha> ok, I'll try that; packaging-only branches are so nice though :)
[02:01] <stgraber> jbicha: you may also be interested in bzr's lightweight checkouts to avoid pulling the whole upstream history
[02:02] <TheMuso> THe Ubuntu desktop team uses packaging only branches, so if GNOME shell is not maintained by us, then I guess packaging branches are fine.
[02:02] <TheMuso> UDD branches that is.
[02:03] <stgraber> TheMuso: yeah, we're talking about what's part of desktop-extras so the new package set where non ubuntu desktop team members can be part of
[02:03] <micahg> jbicha: I thought about possibly adding MOTU as well, but IIRC, we refused to define the packageset by component, so I'm reluctant to add MOTU
[02:04] <stgraber> TheMuso: it seems wrong to say "we have the new shiny package set to make it easier for people who want to help with gnome components" but at the same time say that you need to save your changes in the ~ubuntu-desktop branches which these new contributors won't have access to :)
[02:05] <TheMuso> Yup this is true.
[02:06] <jbicha> stgraber: my main problem isn't the lightweight checkout issue (although that's annoying) but merging new versions is more painful & the packaging branches encourage/force using quilt patches
[02:08] <micahg> umm, shouldn't you be using quilt patches regardless?
[02:09] <TheMuso> There was the mess of the .pc directory, but afaik thats fixed.
[02:11] <micahg> jbicha: also, why did you break out the -common package in the SRU, that's not normally done
[02:11] <micahg> ah, I see why now in the bug, but still, IANA SRU team member, but sounds like something that won't fly
[02:12] <jbicha> micahg: I thought it was worth a try and it makes the breaks/replaces a bit easier
[02:13] <micahg> why do we need the breaks/replaces at all?  we shouldn't be pulling in new packaging changes in an SRU unless they're needed for the new version itself
[02:15] <micahg> oh, for precise, meh, that's the price of SRUing I guess...safer to have the diff than break the stable release IMHO
[02:15] <micahg> but I encourage you to speak to an SRU team member about it
[02:16] <RAOF> This SRU team member would be skeptical of breaking out a -common package in an SRU; what's the bug?
[02:16] <jbicha> bug 921343
[02:16] <ubot2`> Launchpad bug 921343 in gnome-shell "[SRU] Update gnome-shell to <IP_ADDRESS> on Oneiric" [Undecided,New] https://launchpad.net/bugs/921343
[02:16] <micahg> https://code.launchpad.net/~jbicha/ubuntu/oneiric/gnome-shell/oneiric-<IP_ADDRESS>/+merge/89781
[02:22] <RAOF> Hm.  That looks like it might be the least-bad solution.
[02:22] <TheMuso> Thats what I thought...
[02:23] <RAOF> jbicha: It looks like that package merge won't work properly, though.  Have you actually added all the relevant files to bzr?  Particularly I don't see how gnome-shell-common isn't an empty package, and I don't see the referenced patches.
[02:23] <TheMuso> whoops
[02:27]  * micahg would think a control.in file with the breaks/replaces version set based on distro would be least-bad
[02:31] <jbicha> RAOF: pushed revision 48 with the missing files
[02:31] <jbicha> micahg: hmm?
[02:32] <micahg> Debian breaks/replaces on their version, ubuntu breaks/replaces on upstream-0.1~ (so if we're importing/merging from Debian, we're covered)
[02:36] <TheMuso> If everybody is happy, I'm happy to upload...
[02:37]  * micahg defers to RAOF
[02:39] <RAOF> I'm not a fan of control.in magic; I'm ok with the -common split.
[02:42] <TheMuso> Ok, will upload then.
[02:42] <TheMuso> jbicha: Thanks for the paperwork.
[05:47] <pitti> Good morning
[05:47] <pitti> kenvandine: I used a MP for unity-2d, I cannot commit to the branch
[05:48] <pitti> kenvandine: you can work off lp:~pitti/unity-2d/fix-gsettings-migration if you want, that's the current archive version
[05:52] <pitti> desrt: wow, got accepted as a foundation member -- that was fast
[05:57] <BigWhale> Good morning.
[06:03] <pitti> hey BigWhale
[06:04] <BigWhale> surprisingly it is not dark outside ... only ~60 days until spring.
[06:04] <pitti> still pitch black here
[06:07] <BigWhale> not so much here ...
[06:08] <BigWhale> pitti, where are you from?
[06:08] <pitti> BigWhale: Augsburg, south Germany
[06:08] <BigWhale> not that far away
[06:08] <pitti> where are you?
[06:09] <BigWhale> Slovenia
[06:10] <pitti> right, sounds like you should be 30 or 45 minutes closer to the sun :)
[06:10] <pitti> shoudl be a similar longitude like Prague
[06:11] <BigWhale> I'm around 46.4N, 15.56E :>
[06:12] <BigWhale> Wolfram alpha really gives quick and useful answers sometimes. :)
[06:12] <pitti> right, 10° 54' E
[06:13] <pitti> so, should be a delta of 20 minutes
[06:13] <pitti> BigWhale: heh, looked in http://en.wikipedia.org/wiki/Augsburg :)
[06:14] <BigWhale> I actually googled and google's first result was wolfram alpha.
[06:14] <BigWhale> Ok, I have to get ready... today is office time... which means no slacking off writing some silly open source code. :>
[06:27] <RAOF> Man, a 20 hour PPA queue? :(
[06:27] <BigWhale> RAOF, same thing happened to me last time ... yeah. Everyone is building something. :/
[06:38] <rickspencer3> good morning all
[06:38] <pitti> hey rickspencer3
[06:50]  * bryce waves
[06:56] <didrocks> good mornng
[06:56] <didrocks> morning*
[06:57] <rickspencer3> good morning didrocks
[06:57] <rickspencer3> good evening bryce
[06:57] <rickspencer3> bryce, brilliant move with the xorg-xserver package copy thing
[06:57] <RAOF> Good evening/morning all ;)
[06:57] <didrocks> bonjour rickspencer3
[06:57] <rickspencer3> RAOF, you too!
[06:57] <pitti> hey didrocks
[06:57] <rickspencer3> way to maintain momentum for everyone
[06:57] <didrocks> guten morgen pitti
[07:00] <bryce> rickspencer3, heya, yep it worked quite well.  Can't take credit for it though.
[07:00] <rickspencer3> pitti, jasoncwarner_, Sweetshark, I hate to be a downer, but I noticed the same few packages here the last few days:
[07:00] <rickspencer3> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[07:00] <rickspencer3> all armel :/
[07:00] <bryce> koffice?  anyone still use that?
[07:01] <rickspencer3> oops, not all armel, just LO
[07:01] <pitti> rickspencer3: LibO armhf is in progress (arm team is workign on this)
[07:01] <pitti> rickspencer3: calligra is the new koffice, kubuntu team said they are on it
[07:02] <rickspencer3> pitti, ok
[07:03] <rickspencer3> A2 is next week, so it would be could for Kubuntu and ARM if they had these resolved soon, I think ;)
[07:03] <pitti> calligra looks odd
[07:03] <pitti> calligra-libs conflicts with koffice-libs, but of koffice depends on koffice-libs
[07:04] <pitti> rickspencer3: I haven't really looked into it
[07:04] <rickspencer3> pitti, I normally wouldn't have said anything, but it seems to have been dangling for some days
[07:04] <rickspencer3> I've gotten used to issues being resolved within hours ;)
[07:04] <rickspencer3> my expectations are now completely out of control
[07:04] <rickspencer3> :)
[07:06] <rickspencer3> hey didrocks, out of curiosity, are we going to get any new Unity features between now and Alpha 2?
[07:07] <didrocks> rickspencer3: no, this week was planned to get a compiz release only
[07:07] <didrocks> rickspencer3: but there are some issues around it
[07:07] <pitti> RAOF: thanks for fixing -173!
[07:07] <pitti> didrocks: no HUD next week? :-)
[07:07] <didrocks> rickspencer3: next Monday, freeze of unity trunk
[07:08]  * pitti just read sabdfl's blog post
[07:08] <didrocks> and so, hopefully, release on thursday
[07:08] <didrocks> just post alpha2 release :)
[09:08] <seb128> hey
[09:09] <didrocks> salut seb128
[09:09] <seb128> lut didrocks, ca va ?
[09:10] <didrocks> ça va, et toi?
[09:13] <seb128> ca va bien ;-)
[09:20] <pitti> bonjour seb128
[09:20] <seb128> hey pitti, wie gehts?
[09:20] <pitti> seb128: gut, danke!
[09:34] <seb128> pitti, you are on amd64 right? could you try if the webkit update in the ppa fixes s-c segfaulting on start?
[09:34] <pitti> seb128: u-desktop PPA?
[09:34] <seb128> pitti, ppa:ubuntu-desktop/ppa
[09:34] <pitti> on current precise, s-c starts up
[09:34] <pitti> installing PPA now
[09:35] <seb128> pitti, it was segfaulting with 1.7.4, we backported a fix in the current ppa version
[09:35] <seb128> that was basically the blocker bug for upload to the archive
[09:38] <pitti> seb128: dist-upgraded, got new webkit 1.7.4-0ubuntu1~build5
[09:38] <pitti> s-c starts up fine
[09:38] <pitti> anything particualr I should try in s-c?
[09:38] <seb128> pitti, no, the patch was supposed to fix the issue so that's confirming, thanks ;-)
[09:39] <pitti> the comboboxes in the top bar (All apps, Installed) have a broken menu
[09:39] <pitti> well, they have a pitch black background
[09:39] <pitti> but that seems unrelated
[09:42] <pitti> mvo: http://imagebin.org/195416 -> known? want a bug for this?
[09:51] <mvo> pitti: not known, thanks!
[09:51] <pitti> mvo: I'll file a bug then?
[09:51] <mvo> pitti: but it looks like its a side-effect of something else, its fine in oneiric
[09:51] <mvo> pitti: yes, please do
[09:52] <pitti> mvo: I just installed webkit from the desktop PPA; is it remotely possible that this is due to webkit? or is that a normal GTK widget?
[09:52] <mvo> pitti: its a normal widget, I have it here as well in my box with the normal webkit
[09:52] <pitti> ack, filing
[09:52] <mvo> pitti: is webkit fixed? it used to crash when used in a offscreen window
[09:52] <pitti> mvo: starts fine for me now
[09:55] <pitti> filed bug 921477
[09:55] <ubot2`> Launchpad bug 921477 in software-center "drop down menus from app toolbar have black background" [Undecided,New] https://launchpad.net/bugs/921477
[10:03] <seb128> mvo, we backported the upstream patch to not use buggy calls on offscreen widgets
[10:03] <mvo> seb128: \o/
[10:26] <czajkowski> mvo: morning I was wondering if you knwo why I'd see this message on an upgrade on precise http://pastebin.ubuntu.com/815871/
[10:30] <rix1234> Hi all...What script is called when a user logouts from a session? I am using Ubuntu 10.10
[10:31] <pitti> rix1234: no script in particular; gnome-session signals all programs that it's going to shutdown, and then closes the session
[10:33] <rix1234> pitti, i am using multiseat on ubuntu 10.10. The problem is when user logouts, he doesnt get the login screen again...can u please help...
[10:34] <pitti> rix1234: what do you mean by "multiseat"?
[10:38] <mvo> czajkowski: thanks! I have a look
[10:39] <czajkowski> mvo: cheers I dont mind logging the bug, just not sure against what
[10:39] <mvo> czajkowski: probably app-install-data-ubuntu - it would be nice if you could include the two files as a attachment there too
[10:39] <seb128> -rw-r----- 1 syslog adm  313M janv. 25 11:39 /var/log/kern.log
[10:39] <mvo> czajkowski: what is odd is that I don't get the error myself, do you use a different locale maybe? I wonder if its that
[10:39] <seb128> hum is that normal?
[10:40] <mvo> seb128: impressive
[10:40] <seb128> shouldn't that log be rotated or something?
[10:40] <pitti> seb128: it shuold
[10:40] <pitti> -rw-r----- 1 syslog adm 1457226 Jan 22 10:24 /var/log/kern.log.1
[10:40] <pitti> -rw-r----- 1 syslog adm 670292 Jan 25 09:33 /var/log/kern.log
[10:40] <mvo> seb128: mine is much smaller and its rotated for me
[10:40] <pitti> seb128: is it really just from today?
[10:40] <pitti> seb128: check the first line in kern.log, it has a timestamp
[10:40] <seb128> it starts with
[10:40] <seb128> Jan 22 12:32:32 localhost kernel: [ 4271.719955] cfg80211: All devices are disconnected, going to restore regulatory settings
[10:40] <pitti> that seems fine, rotation-wise
[10:41] <seb128> ok, kernel is really verbose then
[10:41] <pitti> so apparently something got very talkative today?
[10:41] <seb128> I will drop that from the logviewer ui
[10:41] <seb128> the gtk widget doesn't like loading some hundred mbs text
[10:41] <czajkowski> mvo: I dont get it this morning either I use GB locale?
[10:41] <pitti> seb128: mine is 670 kB, which is not exactly small, but certainly far away from 300 MB
[10:41] <pitti> do you see a lot of repetition there?
[10:42] <seb128> Jan 25 10:57:26 localhost kernel: [ 3201.475561] Valid eCryptfs headers not foun
[10:42] <seb128> d in file header region or xattr region
[10:42] <seb128> Jan 25 10:57:26 localhost kernel: [ 3201.475564] Either the lower file is not in
[10:42] <seb128>  a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrou
[10:42] <seb128> gh mode is not enabled; returning -EIO
[10:42] <seb128> pitti, it's filed from those it seems
[10:42] <pitti> yeah, I get the ecryptfs stuff, too, all the time
[10:42] <mvo> czajkowski: thanks! so if you run "sudo update-software-center" it does not show this message anymore?
[10:42] <seb128> pitti, it's maybe proportional to the disk use and I used the disk a lot compared to you?
[10:43] <pitti> maybe
[10:43] <czajkowski> mvo: checking now
[10:44] <czajkowski> mvo: there it is again but says it was updated http://pastebin.ubuntu.com/816297/
[10:44] <mvo> czajkowski: thanks, could you pastebin the file please? pastebin '/usr/share/app-install/desktop/rar.desktop'
[10:45] <czajkowski> mvo: http://pastebin.ubuntu.com/816298/
[10:46] <mvo> czajkowski: odd, that looks correct
[10:46] <czajkowski> it was never going to be simple was it :)
[10:47] <mvo> oh, excellent, I can reproduce it now
[10:47] <czajkowski> oh good!
[10:47] <czajkowski> I dont feel like such an utter tool!
[11:22] <czajkowski> always helpful when nautilus crashes for no reason and you try and fill in the summary box and have no idea what you've done to make it crash
[11:24] <czajkowski> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/909143
[11:24] <ubot2`> Launchpad bug 909143 in nautilus "nautilus crashed with signal 7 in g_simple_async_result_complete()" [Medium,Confirmed]
[11:24] <czajkowski> at least it filled it in
[11:27] <seb128> czajkowski, did you try to open a file which has no handler?
[11:28] <czajkowski> I tried to play a movie file which told me it dint have the files it needed to watch which it did yesterday
[11:31] <seb128> czajkowski, ok thanks
[12:47] <jml> hello all
[12:48] <jml> I'm trying to get a functional Ubuntu VM on my iMac. It's going well so far, but I can't seem to convince Ubuntu to run at the full 2560x1440 resolution
[12:48] <jml> even after installing guest additions (which get me from max 1024x768 to 1600x1200)
[12:52] <jml> http://askubuntu.com/questions/98393/how-do-i-get-2560x1440-resolution-within-virtualbox-on-a-mac (for those who'd prefer points)
[12:53] <jml> ok.  I thought I had tried that.
[13:21] <nessita> mvo: hi there! wanted to check if this is a known issue in softwarecenter: http://pastebin.ubuntu.com/816405/
[13:25] <mvo> nessita: thanks for the notification! I fixed it this morning
[13:30] <nessita> mvo: awesome :-)
[13:30] <seb128> mvo, hey
[13:30] <mvo> hey seb128
[13:30] <nessita> that's the advantage of being in that time zone! you do stuff before the rest :-P
[13:30] <nessita> hola seb128
[13:30] <seb128> mvo, can you try the updated webkit from the ppa with s-c and give you thumb up or down for precise upload?
[13:30] <seb128> nessita, hey, how are you?
[13:30] <nessita> great, thanks
[13:30] <mvo> seb128: if it works for you and pitti that is good enough for me
[13:30] <nessita> a little puzzled by gtk3, but good
[13:31] <mvo> just "a little" ? ;)
[13:31] <seb128> mvo, ok, you got asked before upload, if there are other issues I deny responsability :p
[13:31] <pitti> upload! upload!
[13:31] <seb128> ;-)
[13:31] <pitti> (better than on a Friday)
[13:31] <pitti> seb128: gnome-terminal and apt-get work fine, what more do you need *duck*
[13:31] <seb128> yeah, I'm a strong believer of the no fridays upload rule
[13:32] <seb128> pitti, who use apt-get when you got dselect? ;-)
[13:32]  * seb128 hides from mvo
[13:32] <jbicha> seb128: new webkit works here
[13:32] <seb128> jbicha, thanks
[13:32]  * pitti uses ar p foo.deb data.tar.gz | sudo tar -C / -x
[13:32] <pitti> is that not how it's supposed to work?
[13:32] <jbicha> I prefer Saturday updates myself ;)
[13:32] <pitti> hey jbicha
[13:33] <pitti> jbicha: I followed up to the Debian bug about freerdp and committed two small fixes, FYI
[13:33] <mvo> pitti: I'm about to fix that, new apt is >< close
[13:34] <seb128> pitti, jbicha: is somebody working on getting freerdp 1.0 in?
[13:34] <pitti> mvo: how can that break ar and tar? :-)
[13:34] <pitti> seb128: http://anonscm.debian.org/gitweb/?p=collab-maint/freerdp.git
[13:35] <seb128> pitti, excellent, thanks ;-)
[13:35] <pitti> whoops, pushed my other commit
[13:35] <mvo> pitti: heh :)
[13:35] <seb128> pitti, I had it on my list of "try to look at it if it turns out nobody has interest in it"
[13:35] <seb128> but I'm glad I don't have to do it :p
[13:35] <pitti> jbicha: meh, so they didn't bump the soname for the final release?
[13:35] <pitti> that's the only thing that holds it back AFAICS
[13:36] <jbicha> pitti: nope, I opened this for it: https://github.com/FreeRDP/FreeRDP/issues/366
[13:36] <pitti> seb128, jbicha: we just have one rdepends, so if needs be, we could deal with it
[13:37] <seb128> yeah, one rdepends seems like an easy breaks use
[13:37] <pitti> I wonder if there is a new version of remmina-plugin-rdp which works with 1.0
[13:39] <jbicha> pitti: perhaps http://sourceforge.net/projects/remmina/files/0.9/
[13:40] <jbicha> oh, nm, it's 2012 not 2011
[13:40] <pitti> it's a year old
[13:40] <pitti> http://sourceforge.net/tracker/index.php?func=detail&aid=3440035&group_id=278330&atid=1181674
[13:40] <pitti> http://ftbeowulf.wordpress.com/2011/11/01/uds-free-rdp-and-remina/
[13:41] <pitti> so, seems it's underway, but not there yet
[13:41] <ubot2`> pitti: Error: <Bugtracker.plugin.Sourceforge instance at 0xa5a310c> bug 3440035 not found
[13:41] <jbicha> I guess we'd need a git snapshot or bug them to make a release https://github.com/FreeRDP/Remmina
[13:42] <pitti> ah, if git head works, that sounds doable
[13:42] <pitti> but now that 1.0 is out, I guess they want to roll a release
[13:42] <seb128> pitti, speaking of remmina or freedrp with the "roll a release"?
[13:42] <pitti> remmina
[13:43] <seb128> pitti, check your email
[13:43] <seb128> pitti, sorry I though you were Cced on that discussion
[13:43] <seb128> pitti, I fwd you an email about remmina and rdp 1.0
[13:44] <pitti> ah, sweet
[13:44] <seb128> pitti, the remmina guys basically work on a schedule to match the precise release, they should have their 1.0 on time for the lts
[13:44] <seb128> but it's not there yet
[13:45] <pitti> jbicha: so I guess we could add a Breaks: remmina-plugin-rdp (<< 1.0) to libfreerdp0?
[13:46] <seb128> pitti, feel free to reply to the email, there was only one reply so far from robert_ancell to say that we want the new reminna but we just need to make sure it matches our quality standards and is there on time
[13:46] <pitti> then this could get to experimental, and through MIR again
[14:06] <dobey> davidcalle: ping. you volunteered to make music lens work with rhythmbox at UDS. any news on that?
[14:08] <debfx> Kaleo: the qt patch kubuntu_92_qml_memory_leak.diff (bug #723956) causes crashes in qtcreator and bug #831663 has a similar backtrace
[14:08] <ubot2`> Launchpad bug 723956 in unity-2d "[dash] memory usage increases slowly - memory leak?" [Critical,Fix released] https://launchpad.net/bugs/723956
[14:08] <ubot2`> Launchpad bug 831663 in unity-2d "unity-2d-places crashed with SIGSEGV in QMetaObject::metacall()" [Critical,Confirmed] https://launchpad.net/bugs/831663
[14:08] <davidcalle> dobey, working on it. I have a working python one, I'm porting it to Vala with the help of mhr3.
[14:08] <debfx> Kaleo: since upstream has rejected it and warned about crashes I'm inclined to drop it
[14:09] <mhr3> davidcalle, where my "help" consists of saying "please port it to vala"? :D
[14:09] <dobey> davidcalle: cool. where is the code?
[14:10] <davidcalle> mhr3, wait until tomorrow ;)
[14:10] <davidcalle> dobey, python or vala?
[14:11] <dobey> davidcalle: yes :)
[14:11] <davidcalle> dobey, yes to python?
[14:11] <dobey> davidcalle: both
[14:13] <davidcalle> dobey, ok, let me push the python to Launchpad. The Vala is not ready, except if you just want a bin you can use to display your Rhythmbox library in a terminal ;)
[14:14] <DBO> is nvidia-current-updates no longer a valid thing in Prancing Pony?
[14:14] <dobey> davidcalle: code is code. even if it's not finished you should be pushing commits to launchpad when you make changes
[14:15] <Sarvatt> DBO: it just got missed in the transition, tseliot just uploaded the update
[14:15] <davidcalle> dobey, right.
[14:15] <DBO> Sarvatt, is there a practical difference right now?
[14:15] <Sarvatt> no, there only is after a release
[14:15]  * tseliot nods
[14:15] <DBO> super duper
[14:15]  * DBO switches
[14:16] <DBO> oh did the iommu thing get fixed?
[14:16] <Sarvatt> yep 3.2.0-10 afaik
[14:16] <DBO> sweet
[14:17] <davidcalle> dobey, https://code.launchpad.net/~davidc3/+junk/rhythmbox-precise/
[14:59] <Kaleo> debfx: please drop it :)
[14:59] <Kaleo> debfx: it's a shit patch
[14:59]  * ogra_ looks for his nose-clamp
[15:07] <mandel> guys, we are implementing proxy support for ubuntuone and we wanted to store the creds for auth proxies. We have though about using the keyring, this is the right things to do, isn't it?
[15:09] <mdeslaur> mandel: aren't you simply using the system proxy settings and credentials?
[15:10] <mandel> mdeslaur, well, we use the system proxy settings, that is true, but where do we get the credentials for a proxy that requires auth
[15:10] <mandel> ??
[15:11] <mdeslaur> mandel: when someone configures the system proxy, they typically configure it as username:password@host
[15:12] <mdeslaur> mandel: there's an upstream bug to make it better though: https://bugzilla.gnome.org/show_bug.cgi?id=646354
[15:12] <ubot2`> Gnome bug 646354 in Network "Network proxy has no proxy authorization" [Normal,New]
[15:14] <kenvandine> didrocks, unity and indicator-appmenu needs a rebuild in the unity-team-hud ppa, want me to do an upload?  or do you have packaging branches for those somewhere?
[15:15] <didrocks> kenvandine: I can push a packaging branch to you
[15:15] <kenvandine> cool
[15:15] <didrocks> as there are cherry-pick
[15:15] <mandel> mdeslaur, uh, that is a little ugly but I'm sure we can work with that :)
[15:15] <kenvandine> do you have indicator-appmenu too?
[15:16] <mdeslaur> mandel: I agree it's pretty ugly, but I guess you should be consistent will all the other desktop apps that use the proxy setting
[15:16] <mandel> mdeslaur, well, we certainly prefer to be consistent then
[15:16] <didrocks> kenvandine: no, just apt-get source for this one
[15:16] <kenvandine> ok
[15:17] <didrocks> kenvandine: lp:~ubuntu-desktop/unity/hud-ubuntu
[15:17] <mdeslaur> that being said, I haven't personally used a proxy since 1996, so I'm not quite sure how the others handle it :P
[15:17] <kenvandine> thx
[15:17] <didrocks> yw :)
[15:17] <kenvandine> didrocks, i had to add -Wno-error=deprecated-declarations in unity's CMakeLists.txt to get it to build
[15:18] <kenvandine> in precise
[15:18] <kenvandine> seems it's a pita to work around setting CXXFLAGS with cmake
[15:18] <didrocks> kenvandine: yeah, there is a new deprecation for the last 2 days
[15:19] <didrocks> kenvandine: seems my bot rejected some merges because of that :)
[15:19] <alecu> mdeslaur, by "username:password@host" you surely mean in the http_proxy env var, and not in the gnome proxy settings nor gsettings.
[15:19] <kenvandine> didrocks, is there a better way besides patching CMakeLists.txt?
[15:19] <alecu> mandel, ^
[15:19] <mandel> alecu, got you in a little alarm :)
[15:19] <didrocks> kenvandine: removing -Werror from CXXFLAGS doesn't work? It used to last time I did
[15:19] <kenvandine> nope
[15:19] <mdeslaur> alecu: AFAIK, that's the way you set it in gnome also, no?
[15:19] <kenvandine> it seemed to just ignore that
[15:20] <didrocks> oh weird
[15:20] <kenvandine> not in the rules file anyway :/
[15:20] <kenvandine> seb128 told me last time he just patched it, so i went with it :)
[15:20] <alecu> mdeslaur, gnome used to have a dialog to set the username and password; now it's gone, but the gsettings keys still remain.
[15:21] <didrocks> kenvandine: can't really check right now, but I did something similar and it worked, anyway, thanks for the notice, it will surely be fixed with the release if people wants to get more branches in :)
[15:22] <mdeslaur> alecu: upstream bug seems to indicate the preferred way is to enter username:password@host in the g-c-c dialog
[15:22] <mdeslaur> alecu: are you saying g-c-c will split them out into separate gsettings keys?
[15:23] <alecu> mdeslaur, no, I'm just saying that the gsettings keys are still there (though empty).
[15:23] <mdeslaur> alecu: awesome
[15:24] <mdeslaur> mandel: so, proxy support is b0rked on the desktop
[15:24] <mdeslaur> mandel: so do as you wish
[15:24] <kenvandine> yay... there is already a pending build for indicator-appmenu in the ppa :)
[15:24] <alecu> "gsettings list-recursively org.gnome.system.proxy" shows both authentication-user and authentication-password
[15:25] <mdeslaur> alecu: so I guess applications have to parse those keys, _and_ parse the user:pass@ syntax
[15:25] <mdeslaur> awesome
[15:26] <alecu> awesome indeed :-)
[15:26] <mdeslaur> mandel: ^
[15:28] <alecu> mandel, mdeslaur: still, if the user sets a proxy host/port without setting the credentials, the webclient library will find out that credentials are needed, and the app should prompt the user for those.
[15:28] <alecu> mandel, mdeslaur: if the user then enter the credentials in the dialog provided by the app, they should be stored somewhere...
[15:28] <alecu> either those gsetting keys or the keyring.
[15:29] <alecu> since I'm not keen on storing credentials in plaintext on gsettings, the keyring makes much more sense.
[15:29] <debfx> Kaleo: ok, will do
[15:29] <alecu> I can see that chrome is storing credentials there (not sure if proxy creds too), so I wonder if there's a standard way to store proxy creds in the keyring. Or if we should propose some.
[15:30] <mdeslaur> alecu: I'm not keen on storing separate proxy credentials for each app...is there a standard way to do it?
[15:30] <Kaleo> debfx: thanks!
[15:31] <alecu> mdeslaur, don't know yet. That's why we (mandel, me) are asking here :-)
[15:31] <mdeslaur> alecu: oh, hehe, sorry
[15:32] <alecu> mdeslaur, we'll probably continue by trying a few apps with a proxy requesting credentials and watching them store the credentials somewhere.
[15:34] <alecu> mdeslaur, thanks for your input too. btw: can you paste the link to that upstream bug you mentioned?
[15:34] <mdeslaur> alecu: https://bugzilla.gnome.org/show_bug.cgi?id=646354
[15:34] <ubot2`> Gnome bug 646354 in Network "Network proxy has no proxy authorization" [Normal,New]
[15:34] <alecu> mdeslaur, thanks!
[15:34] <mdeslaur> alecu: and stuff like this: http://askubuntu.com/questions/65828/how-can-i-configure-proxy-authentication
[15:38] <alecu> I'll tell mandel about all this after the net-split. mdeslaur: thanks again.
[15:39] <alecu> mandel, here's the backlog: http://pastebin.ubuntu.com/816557/
[15:40] <mandel> alecu, thx got it, stupid network :P
[15:44] <dobey> alecu, mandel: aren't the proxy passwords stored in keyring now?
[15:44] <mandel> dobey, AFAIK they are not, but I'm stupid :)
[15:48] <seb128> re
[15:48] <seb128> desrt, hey, got what I was saying?
[15:51] <desrt> seb128: that you hate gnome? ;(
[15:51] <seb128> desrt, no
[15:51] <seb128>  desrt, is that a bug of yours? http://pastebin.ubuntu.com/816567/ or saw it before?
[15:51] <seb128> desrt, I get that in nautilus for a bit, I think it might be due to glib
[15:52] <seb128> or "for a bit", "it started recently"
[15:52] <desrt> looks unrelated to glib
[15:53] <desrt> gapplication is in the backtrace, sure, but only in the same way that g_main_loop_run() would be...
[15:53] <seb128> well the nautilus code is one call to "g_application_run()"
[15:53] <desrt> ya.  that's generally how it should be done.
[15:54] <dobey> alecu, mandel, mdeslaur: it appears that maybe gnome3 stuff doesn't support authenticated proxies yet :(
[15:54] <seb128> desrt, well, so why does it hit an invalid read?
[15:54] <mandel> dobey, cute!
[15:54] <desrt> seb128: it hits the invalid read in GtkTimeline...
[15:54] <mdeslaur> dobey: awesome++
[15:54] <seb128> desrt, doh, I can't read today it seems
[15:55] <desrt> seb128: :)
[15:55] <seb128> desrt, sorry for the noise ;-)
[15:55] <desrt> seb128: that's accessing the pirv structure of the timeline rather direcdtly
[15:56] <desrt> seb128: so i'd guess it's either a use-after-free or someone passing a completely invalid thing to gtk_timeline_run_frame()
[15:56] <desrt> hum.  that's internal to gtktimeline
[15:56] <seb128> desrt, ok, I'm a bit puzzled by the valgrind log
[15:56] <desrt> seb128: hum.  i think if you unref a timeline while it is running then it is likely to cause what you see here
[15:56] <seb128> desrt, I'm surprised that there is no nautilus code lines before the gtktimeline one
[15:56] <desrt> seb128: it's because it's a mainloop dispatch
[15:57] <desrt> gtk_timeline_start() sets up a timeout to call the frame update function
[15:57] <desrt> which is what you're seeing called
[15:57] <desrt> meanwhile, the timeline has clearly stopped existing in the meantime
[15:57] <desrt> it looks to me like someone in unref() the timeline while it is running
[15:57] <desrt> *is
[15:57] <seb128> desrt, thanks
[15:57] <desrt> it's not entirely clear if that should be valid or not...
[15:58] <seb128> now if only valgrind was not spammed by libpixman errors that would help to get an useful log
[15:58] <seb128> ==18574== Conditional jump or move depends on uninitialised value(s)
[15:58] <seb128> ==18574==    at 0x5223A10: sse2_combine_over_u (pixman-sse2.c:620)
[15:58] <seb128> ==18574==    by 0x5210068: delegate_combine_32 (pixman-implementation.c:174)
[15:58] <seb128> ==18574==    by 0xE989257: ???
[15:58] <desrt> supressions, dude :)
[15:58] <desrt> actually, i'm not so sure anymore
[15:58] <seb128> desrt, I need to learn how to do that ;-)
[15:58] <desrt> it looks like the source gets destroyed on finalize
[15:59] <gord> seb128, hey, so it turns out totem is sending out an <alt> key-press every 30 seconds to inhibit the screensaver - obviously messes with HUD. sound like something we can distro patch out?
[15:59] <desrt> is it always the same place?
[15:59] <desrt> like, always sse2_combine_over_u ?
[16:00] <seb128> gord, we probably can yes
[16:00] <seb128> desrt, yes
[16:00] <gord> seb128, cool, i'll get a patch going
[16:01] <desrt> seb128: so you need a supression like
[16:01] <desrt> {
[16:01] <desrt>   pixman stupid problem
[16:01] <dobey> desrt: hey. you might know this. is there really no way to handle authenticated proxies in the new gio/gsettings proxy related stuff, and every app has to handle it manually themselves?
[16:01] <desrt>   Memcheck:Value4
[16:01] <desrt>   fun:sse2_combine_over_u
[16:01] <desrt> }
[16:02] <desrt> you may need to change value4 for value8 or value16 or value1 or so
[16:02] <desrt> it's an annoying thing that valgrind doesn't tell you the size of the read that caused the invalid conditional jump :/
[16:02] <desrt> actually
[16:02] <desrt> Memcheck:Cond is probably the correct one for that case
[16:02] <desrt> now that i think about it
[16:03] <seb128> desrt, thanks, trying
[16:08] <seb128> desrt, that did it, thanks
[16:09] <desrt> seb128: so back to the drawing board on the original problem :)
[16:13] <seb128> desrt, yeah, trying to get a stracktrace
[16:13] <desrt> seb128: i can't see any problem within gtktimeline itself
[16:13] <dobey> desrt: do you know anything about proxy support in gnome3?
[16:13] <desrt> seb128: can you give me a bit more context from the crash?
[16:14] <desrt> dobey: i know you should make sure glib-networking is installed if you want it to work properly
[16:14] <desrt> that's about it, though :)
[16:14] <dobey> eh
[16:14] <desrt> seb128: ie: the 'reason' part of the complaint
[16:14] <desrt> (ie: recently freed, or not recently freed, etc)
[16:15] <dobey> desrt: actually, that does help. thanks :)
[16:15] <seb128> desrt, not really, I didn't hit the issue on real user
[16:15] <seb128> desrt, though I often get a g_critical about a g_timer call, I should have noted it
[16:16] <seb128> desrt, I was just valgrinding nautilus for another bug and spotted that error in the log
[16:16] <seb128> desrt, so I figured I would take the opportunity to at least record it in a bug report
[16:16] <desrt> seb128: gonna need more info, i'm afraid :)
[16:17] <desrt> seb128: where did http://pastebin.ubuntu.com/816567/ come from?
[16:17] <seb128> desrt, valgrind nautilus
[16:17] <desrt> seb128: you copy/pasted bits of it out, right?
[16:17] <seb128> I get it every time I run nautilus under valgrind
[16:17] <seb128> desrt, no, that's all I get
[16:17] <desrt> let me see if i can get it to happen here, then
[16:17] <desrt> oh.  weird?
[16:18] <desrt> i wonder if valgrind has again become less useful
[16:21] <seb128> desrt, http://pastebin.ubuntu.com/816616/
[16:21] <seb128> it's a full valgrind log
[16:21] <desrt> ==6230==  Address 0x103f9664 is 84 bytes inside a block of size 88 free'd
[16:21] <desrt> ==6230==    at 0x4C2882E: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
[16:21] <desrt> ==6230==    by 0x858F79A: g_type_free_instance (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3110.0)
[16:21] <desrt> ==6230==    by 0x85938A2: g_value_unset (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3110.0)
[16:21] <desrt> ==6230==    by 0x858802A: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3110.0)
[16:21] <desrt> ==6230==    by 0x85881B1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.3110.0)
[16:21] <desrt> ==6230==    by 0x654D406: gtk_timeline_run_frame (gtktimeline.c:337)
[16:22] <desrt> this is the part i was looking for :)
[16:22] <seb128> desrt, I don't get that here :-(
[16:22] <desrt> seb128: i think you need --leak-check=full
[16:23] <desrt> makes it slower but you get much better output
[16:23] <desrt> anyway.  figured out the problem now.
[16:24] <seb128> desrt, do you want a bug report and on what component?
[16:24] <desrt> i'll report it.  i already have a patch
[16:24] <desrt> thanks for the poke
[16:24] <seb128> desrt, thanks for looking into it
[16:25] <seb128> desrt, ok, better with the standard options
[16:25] <seb128> GLib-CRITICAL **: g_timer_stop: assertion `timer != NULL' failed
[16:25] <seb128> ==19657== Invalid read of size 4
[16:25] <seb128> ==19657==    at 0x4A38E47: g_type_check_instance (gtype.c:4070)
[16:25] <seb128> ==19657==    by 0x3FEFFFFF: ???
[16:25] <seb128> ==19657==  Address 0x10043318 is 0 bytes inside a block of size 60 free'd
[16:25] <seb128> ==19657==    at 0x402906C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
[16:25] <seb128>
[16:25] <seb128> desrt, so yeah, my not useful log is because rather than using my normal alias I tweaked the command to try to get ride of the pixman stuff :p
[16:26] <desrt> oh :p
[16:26] <desrt> want to test a patch?
[16:26] <seb128> desrt, sure
[16:26] <desrt> let me make sure it compiles first :)
[16:26] <seb128> desrt, can you give me the bugzilla bug number when you get it?
[16:27] <desrt> yup
[16:27] <seb128> thanks
[16:28] <jbicha> pitti: actually freerdp's soname was updated, do we still need a breaks against remmina?
[16:28] <pitti> jbicha: oh, it was between beta and final?
[16:28] <pitti> jbicha: no, if there's a libfreerdp1 now, we don't of course
[16:29] <jbicha> I don't know but it helps if I read the lintian errors ;)
[16:30] <pitti> jbicha: heh
[16:30] <pitti> jbicha: so, with that fixed it seems all good to me
[16:38] <desrt> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=668675
[16:38] <ubot2`> Gnome bug 668675 in general "GtkTimeline: protect the timeline from unref" [Normal,Unconfirmed]
[16:39] <desrt> seb128: seems to fix it for me locally
[16:48] <pitti> good night everyone
[16:49] <seb128> 'night pitti
[16:49] <desrt> pitti: ciao
[16:50] <desrt> seb128: looks like release team is going to bring back some sort of dependency tracking/control for next cycle
[16:50] <didrocks> have a good night pitti
[16:50] <seb128> desrt, \o/
[16:51] <desrt> i don't know what the form will be... but anything is better than nothing :p
[17:16] <DBO> does anyone know if it would be evil to do this: XFixesQueryExtension(m_X11Display, &_xfixes_event_base, &_xfixes_error_base); multiple times?
[17:17] <mterry> kenvandine, thanks for fixing the indicator path stuff for unity-greeter, was just about to roll my own patch
[17:17] <mterry> kenvandine, did you merge-request that?
[17:17] <kenvandine> i did
[17:17] <kenvandine> mterry, it was a must have for the libindicator abi bump
[17:17] <mterry> cool, thanks
[17:17] <kenvandine> np
[17:17] <mterry> agreed
[17:38] <seb128> desrt, your gtk fix seems to work for me as well
[17:38] <seb128> desrt, sorry it took a while, I got sidetracked in other things ;-)
[17:39] <desrt> no worries.  it didn't get any review upstream yet either :)
[17:44] <RainCT> agateau_: Hey, around? :)
[17:44] <agateau_> RainCT: yep, not for long though
[17:45] <RainCT> agateau_: Just wanted to ask what's the API for recent documents in GTK/Qt since I can't seem to find it :/.
[17:45] <RainCT> s/GTK/KDE
[17:47] <agateau_> RainCT: I don't think there is a specific Qt-only API,
[17:47] <agateau_> RainCT: KDE apps uses the KRecentDocument API
[17:47] <agateau_> RainCT: http://api.kde.org/4.x-api/kdelibs-apidocs/kio/html/classKRecentDocument.html
[17:48] <RainCT> agateau_: Thanks. What's some example app that uses this, Kate?
[17:48] <agateau_> RainCT: this stores files in ~/.kde/share/apps/RecentDocuments
[17:48] <agateau_> RainCT: yes, any app which uses the KDE file dialog
[17:50] <RainCT> agateau_: ok, thanks :)
[17:50] <RainCT> oh it uses .desktop files.. weird :p
[17:54]  * didrocks waves good evening
[18:08] <jono> hey folks
[18:08] <jono> I just upgraded Precise and see no indicators - anyone else having this issue?
[18:08] <jono> I saw there was a bunch of indicator updates
[18:10] <RainCT> agateau_: if you're still around, do you know what an usual value for maximumItems() is?
[18:54] <dobey> jono: indicators working for me after latest upgrades on precise, and a reboot, on my laptop.
[19:55] <micahg_> umm, just got this after I tried restarting the panel after it crashed: http://paste.ubuntu.com/816878/
[19:56] <micahg> right now I have no unity panel, this is on an oneiric machine
[20:15]  * micahg wonders if any unity people are here
[20:35] <mterry> micahg, unity people are best found in #ubuntu-unity
[20:35] <micahg> mterry: I'm there and tried with no luck
[21:12] <OwaisL_> I upgraded Unity from staging ppa today and indicators are gone from the panel.
[21:12] <OwaisL_> anyone else experiencing this?
[21:17] <dobey> DBO: if I have a shell script which runs "java foo.jar" and a .desktop file for the shell script, is there any way to make bamf resolve to that .desktop file for that java app?
[23:17] <micahg> gah, a 7hr webkit build :(
[23:24] <TheMuso> micahg: I feel your pain, I went through something similar when I was working on openjdk recently.
[23:38] <micahg> I'm just lamenting it building on amd64 on crested
[23:38] <TheMuso> Ah.


[13:46] <mgariepy> morning all
[16:32] <Jzarecta> highvoltage: hi, so I talked with eric about the PPA and basically we lack much resources so you are free to create PPA but we are not able to do this work for the moment.
[16:42] <JZA> highvoltage: ping
[18:56] <highvoltage> * edubuntu meeting starting in 5 minutes
[19:00] <mhall119|work> no, pygame session is happening in 5
[19:00] <mhall119|work> you can't ask me to chose between them
[19:00] <highvoltage> you don't have to choose
[19:00] <highvoltage> you can just do both :D
[19:01] <highvoltage> I'm not sure how useful I'll be, I'm not feeling too well today I think I'll go to sleep directly afterwards
[19:01] <highvoltage> let's move over...
[19:03] <highvoltage> sbalneav: meeping
[19:37] <sbalneav> highvol/win 9
[19:37] <alkisg> irssi sucks :D
[19:39]  * stgraber would have done alt+9, thanks to irssi's key bindings
[19:42] <highvoltage> yeah me too.
[19:42] <highvoltage> well the same keybindings would work for alkisg in pidgin as well :)
[19:43] <alkisg> Except that mouse clicking is easier than window counting.... :D
[19:45] <highvoltage> oops, speaking of windows, I'm not supposed to be in this one...
[19:54] <sbalneav> back here
[19:54] <sbalneav> So, is there no bottom panel any more by default?
[19:54]  * alkisg had some problems with fat clients and local storage (usb sticks, cds, local disks)... should I mention that in #ubuntu-meeting? or here?
[19:55] <sbalneav> Looking at the "brand" page, doesn't seem to be.
[19:55] <highvoltage> sbalneav: hmm, I didn't notice it because I don't usually have a bottom panel
[19:55] <highvoltage> sbalneav: I wonder where the window list will be then
[19:55] <highvoltage> (mine is usually at the top with everything else, but it doesn't seem to be in the screenshots)
[19:55] <highvoltage> sbalneav: peerhaps there's a big dock surprise coming too :)
[19:55] <sbalneav> I haven't done a gconftool-2 --recursive-unset /apps/panels for a while.
[20:00] <JZA> highvoltage: hi
[20:00] <highvoltage> hi JZA
[20:00] <JZA> highvoltage: did you got my msg about PPA?
[20:00] <highvoltage> JZA: I did indeed, I think it's something we should work on for Ubuntu 10.10
[20:01] <JZA> ok
[20:02] <highvoltage> JZA: and maybe even keep it ppa-only. I guess we'll have to discuss the details. it will depend on how complicated it's going to be to maintain and whether we'll have enough interested people to maintain it
[20:02] <highvoltage> JZA: for Lucid the deadlines are already quite tight, but at least there aren't any freezes on PPA's so we can work on that any time
[20:03] <JZA> highvoltage: wouldnt the deb be enough to just put it on the repo?
[20:03] <highvoltage> JZA: I ran it and looked at the features list... I was just wondering whether the changes could be implemented in OOo with a plugin instead?
[20:03] <JZA> highvoltage: no
[20:04] <JZA> highvoltage: we take code out of OOo
[20:04] <JZA> highvoltage: extensions are about putting code in OOo
[20:04] <sbalneav> heh, from LaserJock:
[20:04] <sbalneav> 'I don't see how deep purple background with dark window background is "light"'
[20:04] <highvoltage> LaserJock FTW
[20:05] <sbalneav> I was a little more brusque.  He said "So out with brown and in with purple"?
[20:05] <sbalneav> I said:
[20:05] <sbalneav> "Yeah, we seem to be sticking with "colours you can see in puke""
[20:05] <highvoltage> JZA: a debian package is enough to have it included in a ppa, having it in the archives comes with smoe more responsibility
[20:06] <sbalneav> That's the last negative thing I'll say :)
[20:06]  * sbalneav zips mouth
[20:06] <JZA> highvoltage: I guess thats where mhall119|work will help us with
[20:06] <sbalneav> So, I can probably host another bug day.....
[20:06]  * sbalneav looks at calendar
[20:06] <highvoltage> sbalneav: no matter how wonderful or terrible they make the default theme I'm going to change it to what I want it to look like anyway
[20:07] <highvoltage> JZA: *nod*
[20:07] <sbalneav> Wednesday the 10'ths looking good.
[20:07] <sbalneav> I'll post something to the list.
[20:08] <highvoltage> JZA: obviously it would be nice to ultimately have it in the archives, so perhaps at some points we should look at automated daily builds and a strategy for having security updates, etc for when we're ready to get it in the archives. I'll poke some OOo package maintainers, they might be able to look at it some time and also give some tips
[20:08] <highvoltage> sbalneav: it does indeed
[20:09]  * stgraber is scared about having twice the worst package to maintain in the archive ;)
[20:09] <sbalneav> Which of us went to London to work on the new art?
[20:10] <sbalneav> stgraber: what package is that, and corollory question, which is the worst?
[20:11] <highvoltage> stgraber: which is why I tend to think that it's probably going to stay PPA-only for a while :)
[20:12] <highvoltage> stgraber: at least it would be easier for ubuntu users to instaall if it's in a PPA
[20:12] <highvoltage> (sorry for all the duplicate letters- stupid wireless keyboard's fault)
[20:13] <highvoltage> I guess the mozilla stuff and gnome must be in the same level of nightmarish as OOo
[20:13] <stgraber> sbalneav: I did
[20:14] <stgraber> sbalneav: that'd be OpenOffice.org as it always fail for weird reasons on some architectures and takes over 13 hours to build, for a hundreds of megs of sources and tens of binary packages :)
[20:14] <alkisg> stgraber: got any thoughts on why I can't use local devices on fat clients ("not authorized"), or any advice on how would I debug that?
[20:14] <stgraber> sbalneav: I flew to London on Saturday, spent Sunday and Monday there and flew to Switzerland on Tuesday (I'm currently in Europe at the moment)
[20:15] <sbalneav> stgraber: Cool
[20:15] <stgraber> alkisg: I'd say it may be a polkit issue though I don't really know how to debug that (and I'm 7000km away from one of my thin clients or LTSP setup :))
[20:15] <sbalneav> stgraber: ah, yeah, I'd agree.  oo.o would be a bear.
[20:16] <alkisg> stgraber: thanks.... I'm afraid it might be that the user is put in the fuse group *after* logon, so a logoff would be needed to take effect, which can't happen :-/
[20:19] <alkisg> Ugh, ltspfsd can't be removed for fat clients, as ltsp-client depends on it
[20:23] <stgraber> alkisg: well, as fat clients can be converted back to thin clients using a simple env variable, I'd like to still have ltspfsd around :)
[20:23] <alkisg> stgraber: Sure, I just wanted to test if it works without it
[21:27] <nubae> alkisg: re: fatclient, check my source... there is something in there to enable local devices and take enable it in polkit
[21:27] <alkisg> Ah, nice, /me looks... (I hope that works for polkit-1 in karmic+...)
[21:31] <alkisg> Nah, no /usr/share/PolicyKit folder in my Lucid
[21:32] <stgraber> alkisg: /usr/share/polkit-1/ ?
[21:32] <alkisg> It's hal specific anyway, should be deprecated now, but I'll look..
[21:39] <alkisg> stgraber: changing every "no" to "yes" in /usr/share/polkit-1/actions/org.freedesktop.udisks.policy enabled me to mount a usb stick. I'll try to finetune it - what do we want? To patch that file on the runtime depending on DENY_LOCALDEV_* ?
[21:40] <alkisg> Or just enable any user to mount anything?
[21:41] <stgraber> would be great if we could make that match DENY_LOCALDEV
[21:41] <alkisg> k, I'll give it a shot tomorrow.
[21:42] <alkisg> I'll also try to prevent ltspfsd from starting for fat clients...
[21:42] <alkisg> (ah, it's *our* source, so we could just check for /etc/ltsp/ltsp_fat_chroot :P)
[21:43] <alkisg> Nah for LTSP_FATCLIENT
[21:43] <stgraber> nope, having /etc/ltsp/ltsp_fat_root doesn't mean you're running a fat client. It means the default is fat client
[21:43] <stgraber> you should let ltspfsd run as usual but simply not mount anything in the local session when it's a fat client
[21:43] <alkisg> Why not save the resources?
[21:44] <stgraber> because I want them to be mounted on the remote server !
[21:44] <alkisg> ...and completely prevent it from running?
[21:44] <stgraber> otherwise ltsp-remoteapps won't work properly
[21:44] <alkisg> k
[21:44] <stgraber> If I start a remote openoffice, I'm expecting to have /media working as it should
[21:44] <alkisg> I'll take a look but I'm not experienced with that part of the code, so if you could take care of that instead, that would be best...