[00:11] seb128 - it seems that the issue with my FN+F8 keys not working on my laptop is a BIOS issue [00:11] and a deliberate one by dell ;) [00:11] so, you might want to remember that if you ever consider updating your BIOS [00:13] chrisccoulson, ok thanks [00:14] chrisccoulson, I read the comment this afternoon saying it was a win7 thing [00:14] seb128 - yeah, it sucks [00:14] i suppose i'll just have to put up with the keys not working, and complain to dell [00:15] they could have implemented the win 7 behaviour with a driver rather than screwing it up on all platforms really [00:15] yeah [00:16] chrisccoulson: what did FN+F8 do? [00:16] mdeslaur, it switches video modes on most laptops [00:16] chrisccoulson: ah! my thinkpad is FN+f7 [00:17] chrisccoulson: that used to be implemented in hardware on your laptop? [00:17] but dell have re-mapped that key combination in their newer BIOSes to produce the same scancodes as pressing Super+P [00:17] ugh [00:17] wth didn't they just do that with a driver [00:18] they use the new key combination in win 7 to open a display settings dialog rather than flipping video modes [00:18] it seems weird to change that in the BIOS though [00:18] chrisccoulson: did they break winxp/vista by doing that? [00:19] what a weird thing to do [00:21] mdeslaur, the new behaviour is specific to win 7 [00:21] but https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/539477/comments/12 explains why it affects lucid too [00:21] Ubuntu bug 539477 in linux "Fn+F8 key combination doesn't work on Dell E5500" [Undecided,Invalid] [00:22] chrisccoulson: ah! that makes sense [00:22] huh, interesting [00:41] is apport attaching crash files to bug reports now? [00:46] chrisccoulson: I *think* so. [00:46] RAOF - ah, i wasn't aware of that. i've been deleting them ;) [00:47] thinking that users were attaching them manually... [00:47] You mean .crash files? No, those would be manual. But I think apport is now actually attaching the files that it's meant to be attaching :) [00:51] RAOF - i was actually referring to the .crash files [00:51] it seems that those are now automatically added too [00:52] eg, bug 544687 [00:52] Launchpad bug 544687 in gdm "gdm-simple-slave crashed with SIGSEGV in _fini()" [Undecided,New] https://launchpad.net/bugs/544687 [00:54] Hm. [00:55] I wonder why apport is attaching that? [00:55] chrisccoulson, I doubt it does or that's a bug [00:55] that's not wanted for sure [00:55] seb128 - it's being added to all new crash reports today [00:56] it's a bug for pitti [00:56] ok, i'll ping him in the morning [00:56] (if he hasn't already seen the scrollback by then) [06:44] Gah. Evolution and firefox are fighting over which process should have the highest resident size. [06:54] Good morning [07:21] good morning pitti [07:21] bonjour didrocks! [07:21] how are you this morning? [07:23] pitti: I'm fine, thanks. Ready for a not so crazy day, I hope :) [07:23] and you? [07:27] didrocks: still a bit tired, but alright; today I really feel my muscles :) [07:28] * pitti feels like a 70 year old [07:29] due to yesterday Taekwondo? [07:38] didrocks: no, still from Sunday's training camp [07:38] I usually feel it most two days after [07:38] didrocks: (sorry, I'm not ignoring you, I just was stuck a bit in mutt) [07:39] pitti: no pb, I'm back to gconftool's mess :) [07:40] didrocks: are you using fork(), setgid(), setuid() now? [07:40] pitti: I'm trying to use Also note that modifying the environment from the child setup function may not have the intended effect, since it will get overridden by a non-NULL env argument to the g_spawn... functions. [07:40] oupss, wrong paste :) [07:40] I'm trying to use the definition of that ^ ;) (GSpawnChildSetupFunc) [07:40] which is a parameter from g_spawn_… [07:41] should do it, just have to find some code example [07:45] hello [07:57] baptistemm: hey o/ [07:57] salut didrocks [07:58] pitti: ok, got it. Last thing to find is why gconftool-2 --direct -g /desktop/gnome/sound/event_sounds --config-source "xml:readwrite:/var/lib/gdm/.gconf" returns me a different value from gconftool-2 -g /desktop/gnome/sound/event_sounds even after shutting down the daemon (under the gdm user of course) [08:02] didrocks: oh, why do you have to specify --config-source explicitly? [08:02] pitti: it's compulsory with --direct [08:02] didrocks: and if you have to, why don't you have to do it with -g as well? [08:02] didrocks: ah, I see [08:02] hi pitti [08:02] I guess there is something in the gdm default path which could interfere [08:03] ahah, we user .gconf.path to include defaults [08:03] user* [08:03] use* [08:03] :) [08:03] which has a higher priority than $(HOME)/.gconf [08:14] didrocks: that sounds like a bug? [08:14] (the priority) [08:15] pitti: we put the mandatory and default in this path file. My guess is that we should rather use $(HOME)/.gconf.path.defaults and $(HOME)/.gconf.path.mandatory [08:15] (see /usr/share/gconf/default.path) [08:18] didrocks: i. e. should /var/lib/gdm/.gconf.path have /var/lib/gdm/.gconf as well? [08:19] pitti: we can either do that, or not using .gconf.path and split the values between $(HOME)/.gconf.path.defaults and $(HOME)/.gconf.path.mandatory [08:19] but both of those are shipped in .debs, thus they shouldn't be writable [08:21] pitti: right, user/sysadmin shouldn't touch them [08:21] pitti: so, I add at the right place /var/lib/gdm/.gconf to /var/lib/gdm/.gconf.path for you? [08:22] ccheney: hello! any news re OOo upload to fix #516727 ? [08:22] didrocks: "for me"? :-) [08:22] didrocks: I'm not that familiar with gconf source configuration, you know much more about it [08:22] pitti: "in your opinion", that's a French bad translation :) [08:22] didrocks: but it sounds pplausible to me [08:23] can do that, it's easy [08:23] /var/lib/gdm/.gconf should override /var/lib/.gconf.defaults [08:23] right [08:23] but not the mandatory settings [08:23] right [08:25] ok, it's working ;) that was the last strange remaining thing \o/ [08:25] hey mvo [08:25] didrocks: sweet! [08:25] mvo: guten Morgen! [08:28] morning Pitti and mvo [08:28] hey didrocks, pitti, glatzor [08:28] glatzor: hallo! [08:28] good morning [08:32] mvo, I looked at the debconf forwarding issue once again [08:33] mvo, see lp:~aptdaemon-developers/aptdaemon/fix-455861 [08:34] mvo, it is possible to delay a new connection attemp by just returning True from the accept_connection method. I lowered the priority of the accept_connection callback compared to the io handlers [08:40] glatzor: oh, cool! I check it out. I would really like to write a test-case for this, but I'm not sure how to simulate it properly [08:40] hey seb128! have you noticed that gnome-menus FTBFS ? [08:42] hello mvo, yes I got emails about that but I didn't look at it yet, I will do that today if you don't beat me to it [08:42] brb session restart after daily updates [08:44] Good morning didrocks! [08:45] RAOF: good morning! [08:46] re [08:47] mvo, did you look at the issue yet? [08:47] mvo, I uploaded your gtk patch yesterday btw [08:47] seb128: I think it may be a missing b-d [08:48] seb128: let me test-build w [08:48] mvo, don't bother, I will have a look now, I've some experience with gir builds by now [08:48] seb128: I have a test-version now running in pbuilder [08:49] seb128: it may just be a missing b-d on git1.0-glib-2.0 [08:49] mvo, ok thank you! [08:49] pitti, hey [08:49] np, I let you know if it was it [08:49] seb128: I only care because it shows up in red in my upgrade test output ;) [08:49] pitti, did you made apport add .crash to bugs on purpose or is that a bug? [08:49] mvo, oh it does? [08:49] seb128: well, because gnome-menu is not build [08:49] mvo, the current version is not installable? [08:50] seb128: I saw the scrollback; I didn't, looks like a recent LP change; filed as bug 544843 [08:50] Launchpad bug 544843 in malone "Bug reports with +storeblob now attach the raw file" [Undecided,New] https://launchpad.net/bugs/544843 [08:50] seb128: its the fix you did with the file-overwrite [08:50] pitti, thank you! [08:50] de rien [08:50] mvo, oh right [08:50] seb128: that is in ubuntu3 but because of the ftbfs its not inthe archive yet [08:50] mvo, ok, let me know how test build goes, I will do an upload today anyway to fix another issue [08:50] seb128: (thanks for this btw and THANKS for the gtk patch !) [08:50] didrocks: How's UNE going? From the lucid-bugs wiki page it looks like it's going ok. I've been busy (and will likely remain busy) with other things; do you need more help with UNE? [08:50] pitti, any objection to drop the icon translation from the cache? ie have the non translated value listed [08:51] seb128: ok, should I just commit to bzr then and wait for this upload? or upload anyway? (either way is fine for me) [08:51] seb128: no, not at all; I'm not even sure why we translate it at all [08:51] mvo, thank YOU for the patch, I just reviewed and uploaded ;-) [08:51] pitti, ok good, I will fix that today [08:51] mvo, commit to bzr I will do some other changes in a few minutes [08:51] seb128: oh, thanks! (otherwise I can do it later today) [08:51] :) tiny tiny patch, need to buy beer for upstream to accept it [08:51] pitti, np [08:51] * pitti currently knee-deep in g-s-d keyboard code [08:52] pitti, good luck with that [08:52] brave man! [08:52] pitti, did you notice that usbmuxd + gvfs have upstream changes to fix the afc and gphoto double mount issue? [08:52] seb128: yes, I read it yesterday [08:52] I set the bug to "in progress" now, now high on my todo list [08:53] pitti, ok thanks [08:55] pitti, about apport API, do you know if usb_devices() fine works, because bug report (bug 544549 for instance) don't have it. Perhaps I'm not using it properly [08:55] Launchpad bug 544549 in bluez "test bug for apport (dup-of: 543764)" [Undecided,New] https://launchpad.net/bugs/544549 [08:55] Launchpad bug 543764 in bluez "test apport hook for bluez" [Undecided,New] https://launchpad.net/bugs/543764 [08:55] seb128: commited (the gnome-menus fix) [08:56] baptistemm: this works fine here: python -c 'from apport.hookutils import *; print usb_devices()' [08:56] http://bazaar.launchpad.net/~bmillemathias/apport/bluez-support/annotate/head:/source_bluez.py [08:56] baptistemm: it's just a convenience wrapper for lsusb -v [08:57] ah so it doesn't attach the output automatically, I have to get the output and attach it [08:57] * seb128 hugs mvo [08:57] mvo, you rock, thanks! [08:57] RAOF: I'm annoyed by one or two bugs that we should really fix, apart from that, the remaining one are just "good to fix", but not compulsory. So, it's mainly ok. But I'm busy with other things and also triage a big flow of UNE bugs report [08:58] RAOF, bryceh: is there an easy way to match gpu lock bugs to avoid filling duplicates? [08:59] ie to know if the lock bug I got is the same than one of those already opened [08:59] seb128: It's not obvious , no. [09:00] seb128: Part of the problem there is that the GPU dump we *get* is often that of a freshly-reset GPU [09:00] RAOF, also seems quite some of those are closed as false positives bugs, how do you detect if that's the case or a real issue? [09:02] I haven't noticed a lot of bugs closed as false-positives, but there's an *awful* lot of bugs which are basically “Why are you presenting this error popup to me?"” [09:03] how do gpu locks look like usually? [09:03] basically what I did is suspend undocked and woke up docked with lid closed and external screen [09:03] which gives no active screen [09:03] at which point I did a switch to vt1 and back to vt7 [09:03] which actives the display usually [09:03] and got the gdm screen [09:04] and after login I got a gpu lock apport bug and an xorg crash bug [09:04] I think the crash is what did send me back to gdm [09:04] That's probably bug #535640; we've been duplicating a lot of gpu locks against that. [09:04] Launchpad bug 535640 in xserver-xorg-video-intel "[gm45] GPU lockup de05bf80bf83cd22541cb55f1a2ee99e (xorg crash when opening the laptop lid)" [Unknown,Confirmed] https://launchpad.net/bugs/535640 [09:04] I'm not sure if the gpu lock bug is a real one and worth sending to launchpad [09:05] the crash is bug #447159 [09:05] Launchpad bug 447159 in xserver-xorg-video-intel "[i945gm] Xorg assert failure: X: ../../src/i830_batchbuffer.h:79: intel_batch_emit_dword: Assertion `pI830->batch_ptr != ((void *)0)' failed." [Medium,Confirmed] https://launchpad.net/bugs/447159 [09:05] Sarvatt's traced that back to a patch that we accidentally dropped in the .33 drm backport. [09:06] ah nice, so it's likely to be fixed before lucid? [09:06] Yes. [09:06] good [09:07] did you ping any of the kernel team guys about it? [09:07] yeah we're getting a lot more triggerings of the X freeze apport hook than we expected [09:08] I milestoned the crash I listed before btw [09:08] Yes; smb's been pinged as our backup apw [09:08] it has over an hundred affected users [09:08] and is still happening on lucid [09:08] at least, the good news is it's become tons easier for users to report these things compared with before [09:09] bryceh, RAOF: ok thanks [09:09] indeed I've been wondering if we should shut off the apport hook, it's ruining our stats! ;-) [09:09] bryceh: Sarvatt & I have been bashing at that today; today's graph should look much better :) [09:09] well if you feel you collected enough bugs now you can probably turn it off [09:09] RAOF, I think we need to figure out ways we can put in more heuristics so things automatically dupe [09:09] RAOF, awesome [09:10] also you can make extra use of bug patterns to autoduplicate things [09:10] seb128, yeah I think we'll discuss it at the desktop team meeting [09:10] bryceh: can't think of how, i did over 40 there and its too random [09:10] bryceh: Right. That might work better with a .34 kernel, where we can guarantee that the gpu error log actually has the right state. [09:10] Sarvatt, RAOF: Ooh, nice drop in the curve! http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg [09:11] the info i needed to dupe all of those was scattered in 6 or 7 different places [09:11] Sarvatt, RAOF: well I'll leave it to your guys' judgment on if leaving the freeze apport hook might benefit us in gaining more interesting freeze bugs, or if at this point it just is gathering more and more dupes [09:12] iirc we shut this stuff off at release anyway [09:13] We might want to switch it off until the lid fix is back in; it seems that it requires nothing more than shutting the lid, which users do *all the time* :) [09:14] can you bug pattern this one in some way? [09:15] jcastro, ping me back when you're up, thanks :) [09:15] baptistemm, you should just ask your question so he can reply even if you are not there [09:15] Possibly. It'll be difficult to do something without false-positives. [09:16] seb128, I suspect if we had enough understanding to craft a bug pattern, we'd know enough to amend the apport script to not file them in the first place [09:16] ok [09:16] But I guess if the other option is to turn it off entirely, then hiding some bugs in false-positive duplicates wouldn't be too bad. [09:17] oh man, opening your graph killed my system bryceh, lost a huge email I had typed up for kernel-team about drm bugs :( :( [09:18] bryceh: We could possibly dupe based on the contents of IPEHR=0x01800020 in i915_error_state. [09:18] Sarvatt, drat... sorry... hope your browser doesn't have a bug reading svg [09:20] mvo, uh we have to be careful. debconf 1.5.29 breaks our forwarding [09:20] glatzor: uhh, how? [09:20] * RAOF → run [09:20] mvo, it requires a read-write lock on the file based databases. which will fail for a non-root running debconf-communicate [09:21] RAOF, have fun, see you later [09:21] glatzor: sounds like we need to file a bug about that [09:21] glatzor: or at least get a --no-locking switch or something [09:21] mvo, I was wondering why my debconf test scripts weren't working anymore on debian [09:25] bryceh: I think they are a bad idea personally for most cases, *all* 965 reports were for the same hang, most Gxx ones were as well but the remaining ones didn't have enough info to consider it a dupe even though it had the same symptoms because they filed it after rebooting a few times. the 2 arrandale ones are upstreamable though [09:26] Sarvatt, sorry, lost context. "they" == svg graphs? bug patterns? [09:27] in reference to [05:13:12] +Sarvatt, RAOF: well I'll leave it to your guys' judgment on if leaving the freeze apport hook might benefit us in gaining more interesting freeze bugs, or if at this point it just is gathering more and more dupes [09:28] it did let us find that that patch was dropped from the kernel unknowingly though :) [09:28] Sarvatt, ah you are in favor of turning the freeze handler off? [09:30] * bryceh waves to tseliot [09:31] mvo, bug #544890 [09:31] Launchpad bug 544890 in grub2 "conffile prompt about grub-pc on upgrade" [Undecided,New] https://launchpad.net/bugs/544890 [09:31] mvo, not sure how,if you track those [09:31] glatzor: I would like to add a "rebuild_apt_xapian_index" dbus handler into aptdaemon - or would you prefer to set this to a different daemon? ie apt-x-i itself or a s-c- daemon? [09:31] seb128: thanks, it seem to be pretty common [09:31] hey bryceh [09:31] seb128: haha, that is a fun diff [09:32] mvo, that's the one I mentioned previous week, I got it on the mini which I use as a textbox, ie I'm sure I didn't change grub there [09:32] seb128: not sure about this one in particular, but grub conffiles [09:32] textbox -> testbox [09:32] seb128: ok [09:32] bryceh, Sarvatt: do you guys happen to know if this is valid? [09:32] (**) Option "xkb_layout" "us,de" [09:32] i. e. having multiple layouts in /etc/default/console-setup -> udev -> X [09:32] seb128: its odd, I do not see this one in my upgrade tests, but I suspect it might be something that d-i is doing to the file [09:32] * pitti tries to find out whether this is an udev rule, X, or libxklavier bug [09:33] mvo, context, I've 3 lucid installs on this machine [09:33] mvo, ie, I'm using the "make space and install lucid" ubiquity option [09:33] mvo, so it might do extra "detecting other oses and updating grub" [09:33] sorry pitti, I'm not sure [09:37] pitti: yep its valid [09:37] Sarvatt: xorg-server itself doesn't seem to parse it at all [09:38] mvo, the post update script is not sufficient? Or do you want to replace it with a dbus call? [09:38] Sarvatt: out of interest, how did you determine that? reading libxkbsomething? [09:39] glatzor: I want to have a way in software-center to trigger a rebuild of the full apt-xapian-index if I notice that its outdated (apt cache and DB size do not match for example) [09:39] Sarvatt: I'm using http://paste.ubuntu.com/399784/ for testing [09:40] Sarvatt: (context: that's the format that the installer uses for non-latin keyboard layouts, since you always need a latin one for typing URLs, keyboard shortcuts, and the like) [09:41] mvo, but which user should be allowed to rebuild the cache? allow all? [09:43] glatzor: my gut feeling is allow-admon without password [09:44] glatzor: admin group users, we could add a throttle to minimize abuse (e.g. not more often than every 5 min). [09:44] Sarvatt: oh, I know -- xkl_config_rec_get_from_server() just reads it from the root window property, and that seems ot be wrong: [09:45] _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", "terminate:ctrl_alt_bksp,grp:shifts_toggle" [09:45] bryceh, Sarvatt: ^ do you know how this root prop is set? [09:48] pitti, sorry no not offhand [09:48] it's still happening in an xterm session, so it's not g-s-d [09:49] bryceh: ok, thanks [09:50] ah, if I start raw X, it's correct [09:50] * pitti directs blame towards gdm [09:50] why does it always turns to be gdm being to blame? ;-) [09:51] it's the only thing between starting X and starting xterm which could modify _XKB_RULES_NAMES :) [09:51] right [09:51] just pointing it's too often buggy [09:51] tell me about it .. [09:51] it's just supposed to take your password and open your session [09:52] and both the backup property and the real property become wrong [09:56] mvo, btw the gtk patch you attached has an extra buggy hook to it [09:56] oh [09:56] what is buggy? [09:56] mvo, it includes the diff from an another change about single,double click [09:56] seb128: yeah, found the culprit in gdm [09:56] pitti, \o/ [09:57] so it is a fix in gdm and g-s-d after all.. [09:57] seb128: meh, I thought I had remove that, its part of out gtk package, i used that for the initial testing [09:58] mvo, it was in the diff there, the patch failed to apply and I started cursing you before noticing it was just the change being listed there :p [09:58] *lalala* [09:58] mvo, it's all good don't worry ;-) [09:59] I will upload a fixed diff (you talk about the upstream report, right?) [09:59] mvo, yes [09:59] chrisccoulson, hey [09:59] hey seb128, how are you? [10:00] chrisccoulson, good! what about you? [10:00] seb128 - i'm good, but quite tired this morning. my daughter kept waking last night [10:00] mvo, I suck [10:01] mvo, it was the launchpad patch apparently I just checked [10:01] mvo, ignore my comment ;-) [10:01] seb128: oh, ok :) [10:01] seb128: I will just delete it [10:01] chrisccoulson, oh, is she not feeling well or just not wanting to sleep? [10:01] seb128: what was the bugnumber again (sorry I suck at this) [10:01] mvo, do nothing that has been uploaded so it's all good [10:01] ok [10:01] seb128 - i think she just doesn't want to sleep ;) [10:02] chrisccoulson, I see, luck you ;-) [10:02] lucky [10:02] chrisccoulson: how old is she? [10:02] mvo, would updating the package cache be to expensive? [10:02] mvo - she's 4 months old now [10:02] glatzor: how do you mean? update it on every apt-get update run? [10:02] hey chrisccoulson, good morningn [10:02] mvo, right. running both actions [10:02] chrisccoulson: sweet :) and lots of sleepless nights I'm sure [10:03] glatzor: its relatively expensive, I would prefer not to do that every time on apt-get update [10:03] hey pitti - how are you? [10:04] chrisccoulson: I'm fine, thanks! just a bit frustrated how utterly broken our keyboard config stuff still is.. [10:04] mvo - she's actually normally quite good through the night now. we put her to bed at about 8pm and she wakes normally at around 6am [10:04] glatzor: the use case is that a just added PPA (or other repository) has the meta-data available immediately. but for a normal apt-get update on stable that just changes a bunch of versions no re-indexing should be done [10:04] pitti - yeah, i was watching the bug mails yesterday [10:04] i see you're having fun ;) [10:04] glatzor: maybe I need to invstigate the "--update" hook in a-x-i again, that was added recently and if its not a big slowdown (it should not) then adding it on each apt-get update may be feasible [10:04] chrisccoulson: woah, impressive [10:14] mvo, the bug is fixed in debconf svn. [10:15] cool [10:21] Guys I have a weird issue involving gdm every third or fourth boot gdm isn't started. This means that I have to log in and manually restart gdm from the cli and then it works fine for another 3-4 times [10:34] it's nice to see that the usual pre-release discussions have started up on the u-d-d mailing list now [10:35] "f Luicd ia a LTS...... Then I sgrongly urge a few exta betas and a delayed release date" [10:35] chrisccoulson, lol [10:36] he didn't even spell "Lucid" correctly [10:36] chrisccoulson, amongst other words [10:38] heh ;) [10:38] yeah, those aren't typos from me ;) [10:40] it amazes me when people recommend delaying release dates who I don't think have been at all involved with development [10:41] indeed - especially when they don't even back up their suggestion with concrete examples of problems [10:41] my fingers wish to strangle [10:41] "i think you should delay the release just for the fun of it" ;) [10:48] chrisccoulson, bikeshed painters [10:53] pitti, can you quickly review gnome-menus r62 and tell me if you are ok with it? [10:53] pitti, when you have a minute, no hurry === ogra_ is now known as ogra [11:38] re [11:38] seb128: sorry, was off IRC, debugging gdm (fixed that part now \o/) [11:38] * pitti looks [11:39] seb128: looks great [11:39] pitti: I've made the rebase, but still not pushed for gdm, I can push a "almost working version" now to avoid you doing the same in the bzr branch [11:40] didrocks: for now I'm working in upstream git [11:40] pitti: oh oki, no pb so :) [11:40] didrocks: I want to work on g-s-d, and once the entire chain works, I'll commit to the packaging bzr [11:41] pitti: ok :) [11:42] pitti, ok thanks [12:02] good morning everyone, i am going to be afk this morning... might be back in time for the meeting [12:04] * kenvandine waves [12:05] hey kenvandine [12:11] hey kenvandine [12:35] I guess this does not really belongs here, but my mom was pretty confused when I upgraded her system and the buttons where all on the wrong side. I guess she is not a target user or something, just as a data point [12:36] pitti, there? [12:36] hi seb128 [12:36] mvo, hehe, same here [12:37] pitti, ok, so I just told didrocks that I think it's time to drop the gdmsetup change for this cycle [12:37] :( [12:37] pitti, http://paste.ubuntu.com/399813/ [12:37] seb128: I thought it'd work now? [12:37] pitti, look at the current change [12:38] hm, I'd structure it more generically (not SetSoundEnabled(), but SetGconfValue()) [12:38] pitti, it's rather that it start looking complicated and hackish [12:38] and it's still not working from gdm [12:39] (but working for a test program) [12:39] I'm wondering if we should keep spending time on that [12:39] or declare that gconf sucks to much for that and delay to next cycle now [12:40] we could just disable the startup sound from gdm entirely by default :-P [12:40] I suggested that to rickspencer3 during the meeting weeks ago [12:40] but he said "no change to the default experience" [12:40] the scary things are stuff like that: // --shutdown take into account the resuid/resgid and HOME whereas --get --set take the euid/egid [12:40] I took time to find and I guess the remaining bug in gdm we have should be related to that [12:41] didrocks: oh, g_spawn()'s child_setup_func looks interesting, that probably saves you the explicit fork() [12:42] didrocks: you should just use setgid() and setuid() there, FWIW [12:42] but anyway, setting all three in setresuid() shuold work as well [12:42] pitti: right, at least, it was an experience that taught me that :) [12:42] it shouldn't be the cause of the bug [12:42] didrocks, it's weird that it works in your test program though [12:42] didrocks: it's nt something simple like not having a correct $PATH in the daemon or so, I figure? [12:43] seb128: right, that's why I'm fighting since this morning on that. I really though it was a config issue somewhere or a typo [12:43] I wonder if we could make the button layout in metacity part of the theme, that would solve the problem nicely by just changing for this one speicifc theme [12:43] pitti: no, the process is launched, the output ("value") is just empty, with a 0 return code [12:44] mvo, themes don't allow to do that [12:44] * mvo nods [12:44] what I want to do is patch the capplet to set the key [12:44] default being upstream one [12:44] add a key to the .index [12:44] mvo: seb128: did you read: http://blogs.gnome.org/metacity/2010/03/21/theme-based-button-layouts/ on that? [12:44] seb128: cool idea [12:44] and make the capplet the gconf key [12:44] didrocks: wrap it in strace -o /tmp/trace -f ? [12:44] didrocks, oh no I didn't, when I asked upstream some weeks ago he said that was not possible to do from the theme [12:45] didrocks: so, how do _you_ feel about how we should go forward with this, since you're doing the work? Fix up for lucid, or postpone? [12:45] seb128: not sure the metacity blog is syndicated to planet GNOME [12:46] pitti: I agree that in any case it's hackish. Of course, this will be frustrating but sometimes we should maybe be wise and avoid such solution to not make the result unstable [12:46] didrocks: it's not. it's in news.gnome.org [12:46] didrocks: I'm asking because I don't want to say "let's drop this" and make you feel like you wasted hours on this in vain [12:46] didrocks, pitti: well if we can figure quickly was is wrong and land that soon it's maybe worth trying [12:46] pitti: as I told to seb128, I spent a lot of time on that and it's some kind of rollback, but I can accept it, even if the work feels useless [12:46] it looks like 90% there now, after all [12:46] but I feel we are wasting days there [12:47] didrocks, let me have a quick other go to trying to figure what is wrong [12:47] seb128: they were already spent, though, so it depends on how much more effort it is to make it work [12:48] seb128: ok, thanks :) [12:48] pitti, the issue is that you can't know that before have it solved [12:48]