[00:04] robert_ancell: So did you want to revert glib to the way it was? [00:06] TheMuso, no, not sure what has happened there!? [00:06] robert_ancell: I am referring to your comment last night about some of the binaries being in libglib2.0-dev [00:06] TheMuso, seb fixed it [00:07] robert_ancell: oh ok [00:07] TheMuso, oh, and after all that I realised I had added one new binary and forgot the other one... [00:08] heh [00:09] TheMuso, looks like seb has wiped out all my changes and done it properly :) [00:10] robert_ancell: ah ok [00:20] Riddell: awake? [02:33] desrt, ok if I push AM_SILENT_RULES change to dconf git? [03:04] robert_ancell: was there something wrong with how i was using it? [03:06] desrt, oh it wasn't working for me. I didn't check if you'd added it. Might be a Maverick problem [03:06] robert_ancell: you need --enable-silent-rules? [03:07] desrt, ah, right. Can we turn it on by default? [03:07] m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])]) [03:07] it's on by default if you use the autogen.sh script [03:07] oh [03:07] any reason you really want it on by default? [03:07] easier to read build logs? [03:07] because it's so much easier to read [03:07] ok [03:08] i'll just switch it on by default [03:08] i already have it hard-depending on automake 1.11 [03:08] so no m4 ifdef required [03:08] nice. [03:09] pushed [03:11] dconf pushed to universe... [03:12] desrt, is there anything special I need to do to make dconf work? [03:14] no [03:14] a normal 'make install' is sufficient if you have all the right env variables set for the prefix [03:14] which in the case of /usr is ... none at all [03:14] ok, time to try it out and write dconf-editor... [03:15] you'll find that the libdconf APIs are ... uh... rather extremely incomplete [03:15] i think get list set and set_async work [03:15] if you're lucky, set_many and set_many_async may be working [03:15] and if you're very lucky, is_writable will always return TRUE [03:15] pretty much everything else will get you 'symbol not found' when linking :) [03:15] nice [03:16] ok, so explain to me what /usr/bin/dconf does. It doesn't have a man page or --help [03:16] it's approximately in the state of the libdconf right now [03:16] largely unimplemented and completely undocumented, only for use by the truly insane [03:16] but you will find that these things work: [03:17] dconf set /some/path 1234 [03:17] dconf get /some/path [03:17] dconf list /some/ [03:17] er. sorry. not get/set [03:17] write/read [03:18] dconf list / [03:18] segfault :) [03:18] interesting. [03:18] it could be that libdconf returns NULL to mean 'nothing here' [03:19] i know the frontend command assumes that it will be an empty list in that case -- not NULL [03:19] try writing something? [03:20] dconf set /fred 1234 gives "unknown command" [03:20] ya. it's write [03:20] sorry about that [03:20] dconf list now works [03:21] try dconf list /nothinghere/ [03:21] "/nothinghere is not a dconf dir" [03:21] try dconf list /nothinghere/ [03:21] sefault [03:21] good :) [03:21] that'll be easy to fix [03:23] how does gsettings/dconf recognise when keys have migrated from gconf to dconf? [03:23] it doesn't [03:23] there is a separate migration utility that does the work [03:23] and there's no special marking for "this key was migrated" [03:23] I thought you were saying at UDS there was an automatic migration [03:23] there is [03:24] but you have to write a script for it on a per-app basis [03:24] it runs on login [03:24] the program lives inside of gconf. not sure if you are packaging it yet [03:25] so as an app developer what do I do to gcalctool to make this script [03:25] it's a keyfile [03:25] say your GSettings schema has the id org.gnome.gcalctool [03:25] and it has one key called 'awesome' [03:26] which used to be stored in gconf at /apps/gcalctool/awesome [03:26] you write this into the file: [03:26] [org.gnome.gcalctool] [03:26] awesome=/apps/gcalctool/awesome [03:26] (end) [03:26] that's how i understand it, at least [03:26] and where does that file go? [03:26] somewhere in /usr/share/gconf/ [03:27] http://library.gnome.org/devel/gio/unstable/ch27s07.html [03:28] thanks [03:28] hmm, so we really want to run that after a package is upgraded otherwise you could: [03:28] run gcalctool-old [03:29] apt-get upgrade [03:29] run gcalctool-new [03:29] and it would have no config? (assuming we are running the dconf backend) [03:30] yes. that is true. [03:30] but you can't do it as a postinst [03:30] since it's a per-user thing [03:30] yes [03:30] we had a talk at UDS about this [03:30] and it's looking like the user may be forced to logout of their session for dist-upgrades soon [03:31] and i guess the only place you'd see gcalctool-old -> gcalctool-new (as you describe) is in a dist-upgrade [03:31] no, potentially any application that decides to migrated from gconf to gsettings in the future [03:31] e.g. shotwell [03:32] but will ubuntu really be shipping an upgraded version of shotwell in a stable release? [03:33] I guess not [03:33] actually [03:33] there's the upgrade-manager thingy in the user's session, right? [03:33] pass [03:33] heh [03:33] it could run the program whenever it detects that stuff has been installed [03:33] I wonder if we can modify gtk_init or similar to run it [03:34] though really don't want to delay all apps [03:34] ya. seems like a pretty bad idea [03:34] since i think it's probably not safe to have more than one copy of the tool running at once [03:34] and that would surely happen if you did it from every app [03:34] true [03:35] for migration we were aiming for the method that resulted in the least amount of cruft-distribution [03:35] ie: well-isolated cruft that can easily be removed in the future [03:35] this is the best we could figure out given the constraints [03:37] desrt, is there dconf api docs on the web? [03:37] zilch [03:37] i'll write some of those tonight, i guess [03:37] do you have any questions in the meantime? [03:38] nope, I'll play around and email you anything I think of [03:38] k [03:38] i'll be around here for another hour i guess [03:38] gonna write the docs now, in fact [03:39] btw: i thought about it a bit and i think you'd do well to use a GtkTreeStore fully-populated on startup [03:40] populated at least with the key names -- maybe not the values at first [03:40] ie: lots of list() on startup [03:40] then monitor everything and track changes that way [03:40] it's not worth your effort to try to make a lazy custom GtkTreeModel [03:41] sure [03:43] desrt, should the editor use the engine or client api? [03:43] client [03:44] engine is really not meant to be used except by the ultra-insane [03:44] it's sort of humourously named to semi-reflect the gconf concept [03:44] and at the same time because i just didn't have a better name for it [03:44] but if you use the engine you have to make the dbus calls for yourself [03:44] that's how low-level it is :p [03:44] ok [03:44] what is a "resetlist" [03:45] i'll explain in a second [03:45] taking the dog out [03:45] for you it should be NULL [03:45] ok, i'm just heading out for lunch [04:50] wow I think the csd/rgba gtk+ stuff has completely broken the metacity compositor [04:53] Yup, I think so. [07:26] good morning [08:24] hey there [08:25] salut seb128 [08:26] hey didrocks === almaisan-away is now known as al-maisan [09:28] good morning [09:29] seb128: just driving by, my train leaves in an hour; nice, you have a local box with the floppy issue? [09:29] pitti, yes [09:29] but I'm not on front of it now [09:29] I've regular access to it though [09:29] I can ping you next time when I'm around for debugging [09:29] seb128: happy to have a look next week; I'll do alpha-1 and some oem stuff, but looking at this floppy issue for an hour should at least tell us where the problem is [09:30] ok [09:30] will GNOME is hanging I get floppy io errors printing on vt1 [09:30] * pitti wishes everyone a nice weekend [09:30] pitti, thanks, have a nice weekend as well! [09:30] seb128: can you run ps while that happens? which processes are in 'D' state? [09:30] will do when I'm on the machine again later on [09:31] but let's debug that next week rather [09:31] there is also a floppy drive listed in gvfs [09:31] yep [09:31] ie in the places menus etc [09:31] right, i don't think we can get rid of that; there's a /dev/fd0 after all [09:32] the bit that we might be able to work around is the hang, not the existence [09:32] the kernel must have a way to check if the bios is lying [09:32] the existence/detection needs to be fixed in the kernel [09:32] linux doesn't rely on the bios for any other drive, but detects them itself [09:32] but perhaps floppies are harder to detect, I don't know [09:32] well perhaps it required trying a read [09:33] and they want to avoid that [09:33] it's noisy, slow and unconvenient [09:33] I will try to ask the kernel team [09:33] pitti: enjoy your weekend! :) [09:34] can we just erase all notions of floppies from bioses, kernels, and everything else? :-) [09:34] lol [09:34] so in hardy or intrepid we spent hours on making floppies work again in the first place [09:34] and now we spend hours on hiding them [09:35] by now it'd be cheaper to buy those 5 remaining users an usb stick and be done with it :) [09:35] yeah :-) [09:36] at least the "blacklist floppy" workaround seems to work [09:36] well, turning the bios option works as well [09:36] but still only the few subscribed to the bugs will see that trick [09:36] thousands of users out there have their logging hanging for a while [09:37] ok, need to go, see you! [09:37] pitti, have fun, see you later! [10:05] morning [10:08] morning huats [10:09] morning didrocks [10:10] lut huats [10:10] hello seb128 [10:12] asac: you pinged? [10:20] seb128: if you need a tester for the usb vs floppy, I have a machine that is affected [10:21] mvo, usb vs floppy? [10:21] mvo, the issue there is GNOME login haging on floppy detection on boxes which have no floppy drive [10:21] seb128: that usb automount does not work if there is a floppy drive in the bios [10:22] seb128: aha, ok. I thought you were talking about the "usb-stick-no-longer-autodetected" [10:22] mvo, the bios seems to tell linux there is a floppy [10:22] mvo, I don't know about this one, bug number? [10:22] seems another one that should be fixed in lucid [10:25] seb128: give me a sec to find it [10:26] seb128: bug #583845 [10:26] Launchpad bug 583845 in gvfs (Ubuntu) "Does not detect hotplugged storage device (8.04 -> 10.04 upgraded) (affects: 1) (heat: 8)" [Low,New] https://launchpad.net/bugs/583845 [10:26] can someone please merge these 2 branches (https://code.launchpad.net/~rodrigo-moya/ubuntu/maverick/couchdb-glib/0-6-91-release and https://code.launchpad.net/~rodrigo-moya/ubuntu/maverick/evolution-couchdb/0-4-91-release), the packages are already uploaded to maverick [10:26] seb128: also appears in the forums [10:27] mvo, you didn't reply to my comment there [10:27] but before merging them, I'd appreciate if there was a branch for lucid created [10:27] seb128: I can update the bug this afternoon, its my parents machine [10:27] mvo, ok, thanks [10:27] mvo, could you also copy the forum url on the bug? [10:28] rodrigo_, you have permissions to upload but not to commit? [10:28] seb128, yes, seems so [10:28] weird [10:28] seb128, let me try again [10:29] no, no permissions [10:29] $ bzr push lp:~ubuntu-desktop/couchdb-glib/ubuntu [10:29] bzr: ERROR: Cannot lock LockDir(lp-69379536:///~ubuntu-desktop/couchdb-glib/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport [10:30] seb128: done, I will check this afternoon, it looks like its a dup of #539515 [10:30] mvo, thanks [10:31] rodrigo_, is the ubuntu-desktop bzr bounded to the lucid source? [10:31] james_w, ^ do you know about this? [10:31] seb128, it contains what is in lucid right now, yes [10:32] mvo, ok, that's the bug we were discussing before [10:32] rodrigo_, can you try to push to lp:ubuntu/couchdb-glib? [10:32] seb128, hmm, but that branch is different, right? that is, it has all the source code, etc? [10:33] rodrigo_, right, I though you were using that [10:33] not sure why you get an error then [10:33] seb128, lp:ubuntu/couchdb-glib already contains my upload packages [10:33] you should stop using ubuntu-desktop there [10:34] and just use lp:ubuntu/couchdb-glib [10:34] since you are not in ubuntu-desktop it doesn't make sense to store it there [10:34] ah, ok, and use bzr-merge-upstream when doing new releases? [10:34] although, as I said, that branch has my changes uploaded to maverick already [10:35] right [10:36] those have auto import of uploads [10:36] you can either commit to it [10:36] or let the autoimport grab the changes [10:36] and just leave the u-desktop branch die with no updates? [10:36] delete it if you stop using it [10:37] well, I like the u-desktop branch better, just has the debian/ dir and automatically gets the tarball [10:37] usually kenvandine does the merge for me, so I can live with keeping doing that, if it's ok for you [10:37] well you can bzr merge-upstream http://url [10:37] in the other case [10:37] as you prefer [10:38] ok, I prefer the ubuntu-desktop branch :) [10:38] so, why do you have those u-desktop branches then? [10:38] you should perhaps move it somewhere out of ubuntu-desktop though [10:38] since you are not in this team [10:38] not sure what would be a better location though [10:39] rodrigo_, because it's faster to have the debian directory in bzr than the full source [10:39] ok, I'll let kenvandine decide, since he's been managing the merges on that branch [10:39] ok [10:39] should we wait for him for your merge requests? [10:39] I've not worked on those so I would prefer to have him do those [10:39] seb128, as you want, if you want to merge them, go on [10:39] ok [10:40] rodrigo_, btw will you merge the new json-glib version? [10:40] we have 0.7.6-0ubuntu2 [10:40] debian has 0.10.2-2 [10:40] hmm, didn't plan to, since I don't need it for couchdb-glib, but can do it if you want [10:41] how do I merge a debian branch? [10:41] rodrigo_, I can do it if you want [10:41] seb128, ah, ok, you'd better do it then :) [10:41] ok [10:41] I was just checking in case you didn't get the new version for a reason [10:41] but, yes, how do I merge a debian branch? [10:41] since you are the one who did the previous update for couchdb-glib [10:42] seb128, couchdb-glib builds fine with the json-glib from jhbuild, so I think it's ok [10:42] let me check the version in jhbuild [10:42] rodrigo_, I'm not doing bzr merges for those, I will just grab what debian has and apply our changes [10:42] ah [10:43] 0.11.1 in jhbuild, so it's fine to upgrade [10:43] ok good === bdrung__ is now known as bdrung [10:52] seb128: do you have problems with libgtk/metacity in maverick too? I get flicking all over the place, windows poping up etc [10:53] mvo, no, I'm not using maverick yet though there [10:54] mvo, I run it on my mini but with compiz [10:54] ok [10:54] I think bratsche made a patch for a similar issue, check with fta maybe he is the one what had the bug [10:55] rodrigo_, new json-glib uploaded [11:02] mvo, bug 584287 [11:02] Launchpad bug 584287 in metacity (Ubuntu) "Unexpected X error (BadDrawable) causing metacity to abort in maverick (affects: 5) (dups: 1) (heat: 42)" [Undecided,Confirmed] https://launchpad.net/bugs/584287 [11:19] seb128, cool [11:33] aha, nice. thanks fta [11:43] TheMuso, hi [11:43] TheMuso, could you give an hand with merges for maverick? it seems you are done with your list now and a bit less busy than some other team members for alpha1 and alpha2 [11:53] nice glibc security update [11:54] update 1: arbitrary code execution from a file that only root can write to! [11:54] update 2: arbitrary code execution from.... executables... [11:59] rodrigo_: do you have "bzr launchpad-login" done on that machine? That looks like the error you get when pushing to http [12:00] james_w, yes, I do, I can push to other branches with no problem [12:00] rodrigo_: would you file a bug against 'udd' then please? [12:00] james_w, about me missing permissions on that branch? [12:02] rodrigo_: exactly, I'll investigate further [12:02] ok === MacSlow is now known as MacSlow|lunch [12:07] james_w, 'udd'? [12:07] the 'udd' project on Launchpad [12:09] ah, ok [12:13] james_w, https://bugs.launchpad.net/udd/+bug/586767 [12:13] Launchpad bug 586767 in udd "Don't have permissions to push to lp:~ubuntu-desktop/couchdb-glib/ubuntu but has upload permissions (affects: 1)" [Undecided,New] [12:13] thanks rodrigo_ [12:29] seb128, what are the plans with pygi? is it going to make it to maverick? [12:30] rodrigo_, yes [12:30] I think robert_ancell was working on it [12:31] ok [12:31] not sure when it will be ready though === MacSlow|lunch is now known as MacSlow [13:22] mvo_, bug #574577 [13:22] Launchpad bug 574577 in command-not-found (Ubuntu) "spelling error: priviledge (affects: 1) (heat: 9)" [Undecided,New] https://launchpad.net/bugs/574577 [13:22] mvo_, easy patch for you there [13:22] thanks seb128 [13:22] np ;-) [13:29] hey rodrigo_ [13:30] * kenvandine waves good morning to everyone === al-maisan is now known as almaisan-away [13:30] rodrigo_, i read some of the scrollback, you need merges for the package branches that you already uploaded? [13:31] rodrigo_, now that you have per-package uploads it might make sense to move that branch === ayan-afk is now known as ayana === ayana is now known as ayan [13:33] kenvandine, yes, seb128 was suggesting that, although I'm ok with asking you to do the merges, if that's ok [13:33] that's fine too [13:34] ArneGoetje, could you look at bug #569442 when you have some time? [13:34] Launchpad bug 569442 in ttf-wqy-zenhei (Ubuntu) (and 1 other project) "After upgradeing to Lucid, unexpectedly-using bitmap font in Japanese Environment (upgrading regression) (affects: 3) (heat: 22)" [Undecided,New] https://launchpad.net/bugs/569442 [13:35] ArneGoetje, and advice on what we should be doing [13:35] seb128: sure [13:35] ArneGoetje, thanks [13:35] rodrigo_, so couchdb-glib and evolution-couchdb? [13:35] kenvandine, I'm working though on that branch to add the gir packages, so if you want, don't merge yet [13:35] ok [13:35] excellent :) [13:36] that is for couhdb-glib right? [13:36] kenvandine, you can merge evo-couchdb one, if you want, but I guess it's better to wait for the couchdb-glib changes [13:36] yes [13:36] i can go ahead and do evolution-couchdb? [13:36] ok [13:36] i'll wait [13:36] kenyes, as you wish [13:36] just give me a shout [13:36] kenvandine, ok, as soon as they build ok, I'll push and ping you [13:36] thx [13:48] mvo_, bug #562729 has one change to review as well if you are interested [13:48] Launchpad bug 562729 in gdebi (Ubuntu) (and 1 other project) "gdebi: could not show link: operation not supported (affects: 2) (heat: 14)" [Undecided,Confirmed] https://launchpad.net/bugs/562729 [13:48] mvo_, bug #562729 has one change to review as well if you are interested [13:48] thanks seb128 [13:48] ups [13:48] mvo_, yw [13:48] mvo_, sorry to bother you with those ;-) [13:49] seb128: thats fine, thanks for looking at them [13:49] mvo_, I'm trying to clean a bit the list of patches on launchpad [14:14] mvo_, bug #433838 [14:14] Launchpad bug 433838 in software-center (Ubuntu) "Use an icon in the location bar (affects: 1) (heat: 10)" [Low,New] https://launchpad.net/bugs/433838 [14:14] mvo_, could you review this one as well, it's probably not something you want from reading mpt comments though [14:14] mvo_, either close it of change the tag to patch-needswork if you can [14:14] mvo_, thanks ;-) [14:14] seb128: yeah, I think this needs to be rejected by mpt if he does not want it [14:25] seb128, I see david scheduled a meeting but I see no sign of him on #ubuntu-meeting... is it being held elsewhere? [14:26] bryceh, the arsenal one? [14:26] yeah [14:26] sorry, got reported [14:26] ara pinged us on an another channel asking if we could report [14:26] she didn't have time to look at the arsenal yet [14:26] reported? [14:26] we agreed to do it another day [14:27] davidbarth, ^ [14:27] hrm, I got up early for nada [14:27] sorry :-( [14:27] seb128, ok thanks for the info [14:42] seb128, that bug's waiting on design work, not code review. It doesn't have to be me who does the design work, though. [14:46] mpt, hum ok, what do you suggest to get the bug out of the review queue? [14:46] mpt, does the change needs work or is incorrect or need a review? [14:47] seb128, where is this review queue and how is it composed? [14:47] mpt, the queue is basically all bugs in launchpad with a patch attached [14:47] seb128, if it's from the "patch" tag, then I guess the easiest way is to remove that tag [14:47] mpt, the bug can be tagged patch-needwork if it needs work [14:47] or incorrect [14:48] that would make it go out of the list [14:48] or is the change maybe correct but blocked on design to decide on what to do? === br-away is now known as bratsche [14:50] If it's from "Ubuntu Review Team" subscription, then the easiest way is to unsubscribe them [14:50] I have no idea whether it's correct or not. It depends what the design is! [14:51] https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide [14:51] mpt, ^ [14:52] ah, hm [14:52] basically the patch either needs review, or has been reviewed [14:52] if it has been reviewed it should be applied or tagged needwork [14:52] we don't seem to have status out of this [14:53] On the one hand, it's brilliant that we have an effort to review unapplied patches now [14:53] On the other hand, the process doesn't seem to cater for this kind of case [14:53] right, I'm just trying to think what case that is now [14:53] so we can update the documentation for it [14:53] is that a "blocked on " [14:54] where something is a designer comment there? [14:55] yeah [14:55] maybe patch-needsdesign [14:55] Are there any other cases where a patch might be blocked on something that isn't code review? [14:56] not that I can think of right now [14:58] seb128, ok, I've changed it to patch-needsdesign [14:59] mpt: currently even the design bugs are currently being just tagged as patch-needswork [14:59] mpt, thanks [14:59] vish, "the design bugs"? Can you give an example? [15:00] mpt: hmm , like the theme bugs , let me find one [15:03] mpt: darn it , i cant find one right now ! , but thats what i have been using , usually i check with kwwii and if he doesnt like it had been using the patch-needswork tag [15:06] vish, right, needswork means the submiter need to update the change [15:06]