[00:04] <TheMuso> robert_ancell: So did you want to revert glib to the way it was?
[00:06] <robert_ancell> TheMuso, no, not sure what has happened there!?
[00:06] <TheMuso> robert_ancell: I am referring to your comment last night about some of the binaries being in libglib2.0-dev
[00:06] <robert_ancell> TheMuso, seb fixed it
[00:07] <TheMuso> robert_ancell: oh ok
[00:07] <robert_ancell> TheMuso, oh, and after all that I realised I had added one new binary and forgot the other one...
[00:08] <TheMuso> heh
[00:09] <robert_ancell> TheMuso, looks like seb has wiped out all my changes and done it properly :)
[00:10] <TheMuso> robert_ancell: ah ok
[00:20] <asac> Riddell: awake?
[02:33] <robert_ancell> desrt, ok if I push AM_SILENT_RULES change to dconf git?
[03:04] <desrt> robert_ancell: was there something wrong with how i was using it?
[03:06] <robert_ancell> desrt, oh it wasn't working for me.  I didn't check if you'd added it.  Might be a Maverick problem
[03:06] <desrt> robert_ancell: you need --enable-silent-rules?
[03:07] <robert_ancell> desrt, ah, right.  Can we turn it on by default?
[03:07] <robert_ancell> m4_ifdef([AM_SILENT_RULES],[AM_SILENT_RULES([yes])])
[03:07] <desrt> it's on by default if you use the autogen.sh script
[03:07] <robert_ancell> oh
[03:07] <desrt> any reason you really want it on by default?
[03:07] <desrt> easier to read build logs?
[03:07] <robert_ancell> because it's so much easier to read
[03:07] <desrt> ok
[03:08] <desrt> i'll just switch it on by default
[03:08] <desrt> i already have it hard-depending on automake 1.11
[03:08] <desrt> so no m4 ifdef required
[03:08] <robert_ancell> nice.
[03:09] <desrt> pushed
[03:11] <robert_ancell> dconf pushed to universe...
[03:12] <robert_ancell> desrt, is there anything special I need to do to make dconf work?
[03:14] <desrt> no
[03:14] <desrt> a normal 'make install' is sufficient if you have all the right env variables set for the prefix
[03:14] <desrt> which in the case of /usr is ... none at all
[03:14] <robert_ancell> ok, time to try it out and write dconf-editor...
[03:15] <desrt> you'll find that the libdconf APIs are ... uh... rather extremely incomplete
[03:15] <desrt> i think get list set and set_async work
[03:15] <desrt> if you're lucky, set_many and set_many_async may be working
[03:15] <desrt> and if you're very lucky, is_writable will always return TRUE
[03:15] <desrt> pretty much everything else will get you 'symbol not found' when linking :)
[03:15] <robert_ancell> nice
[03:16] <robert_ancell> ok, so explain to me what /usr/bin/dconf does.  It doesn't have a man page or --help
[03:16] <desrt> it's approximately in the state of the libdconf right now
[03:16] <desrt> largely unimplemented and completely undocumented, only for use by the truly insane
[03:16] <desrt> but you will find that these things work:
[03:17] <desrt> dconf set /some/path 1234
[03:17] <desrt> dconf get /some/path
[03:17] <desrt> dconf list /some/
[03:17] <desrt> er.  sorry.  not get/set
[03:17] <desrt> write/read
[03:18] <robert_ancell> dconf list /
[03:18] <robert_ancell> segfault :)
[03:18] <desrt> interesting.
[03:18] <desrt> it could be that libdconf returns NULL to mean 'nothing here'
[03:19] <desrt> i know the frontend command assumes that it will be an empty list in that case -- not NULL
[03:19] <desrt> try writing something?
[03:20] <robert_ancell> dconf set /fred 1234 gives "unknown command"
[03:20] <desrt> ya.  it's write
[03:20] <desrt> sorry about that
[03:20] <robert_ancell> dconf list now works
[03:21] <desrt> try dconf list /nothinghere/
[03:21] <robert_ancell> "/nothinghere is not a dconf dir"
[03:21] <desrt> try dconf list /nothinghere/
[03:21] <robert_ancell> sefault
[03:21] <desrt> good :)
[03:21] <desrt> that'll be easy to fix
[03:23] <robert_ancell> how does gsettings/dconf recognise when keys have migrated from gconf to dconf?
[03:23] <desrt> it doesn't
[03:23] <desrt> there is a separate migration utility that does the work
[03:23] <desrt> and there's no special marking for "this key was migrated"
[03:23] <robert_ancell> I thought you were saying at UDS there was an automatic migration
[03:23] <desrt> there is
[03:24] <desrt> but you have to write a script for it on a per-app basis
[03:24] <desrt> it runs on login
[03:24] <desrt> the program lives inside of gconf.  not sure if you are packaging it yet
[03:25] <robert_ancell> so as an app developer what do I do to gcalctool to make this script
[03:25] <desrt> it's a keyfile
[03:25] <desrt> say your GSettings schema has the id org.gnome.gcalctool
[03:25] <desrt> and it has one key called 'awesome'
[03:26] <desrt> which used to be stored in gconf at /apps/gcalctool/awesome
[03:26] <desrt> you write this into the file:
[03:26] <desrt> [org.gnome.gcalctool]
[03:26] <desrt> awesome=/apps/gcalctool/awesome
[03:26] <desrt> (end)
[03:26] <desrt> that's how i understand it, at least
[03:26] <robert_ancell> and where does that file go?
[03:26] <desrt> somewhere in /usr/share/gconf/
[03:27] <desrt> http://library.gnome.org/devel/gio/unstable/ch27s07.html
[03:28] <robert_ancell> thanks
[03:28] <robert_ancell> hmm, so we really want to run that after a package is upgraded otherwise you could:
[03:28] <robert_ancell> run gcalctool-old
[03:29] <robert_ancell> apt-get upgrade
[03:29] <robert_ancell> run gcalctool-new
[03:29] <robert_ancell> and it would have no config?  (assuming we are running the dconf backend)
[03:30] <desrt> yes.  that is true.
[03:30] <desrt> but you can't do it as a postinst
[03:30] <desrt> since it's a per-user thing
[03:30] <robert_ancell> yes
[03:30] <desrt> we had a talk at UDS about this
[03:30] <desrt> and it's looking like the user may be forced to logout of their session for dist-upgrades soon
[03:31] <desrt> and i guess the only place you'd see gcalctool-old -> gcalctool-new (as you describe) is in a dist-upgrade
[03:31] <robert_ancell> no, potentially any application that decides to migrated from gconf to gsettings in the future
[03:31] <robert_ancell> e.g. shotwell
[03:32] <desrt> but will ubuntu really be shipping an upgraded version of shotwell in a stable release?
[03:33] <robert_ancell> I guess not
[03:33] <desrt> actually
[03:33] <desrt> there's the upgrade-manager thingy in the user's session, right?
[03:33] <robert_ancell> pass
[03:33] <desrt> heh
[03:33] <desrt> it could run the program whenever it detects that stuff has been installed
[03:33] <robert_ancell> I wonder if we can modify gtk_init or similar to run it
[03:34] <robert_ancell> though really don't want to delay all apps
[03:34] <desrt> ya.  seems like a pretty bad idea
[03:34] <desrt> since i think it's probably not safe to have more than one copy of the tool running at once
[03:34] <desrt> and that would surely happen if you did it from every app
[03:34] <robert_ancell> true
[03:35] <desrt> for migration we were aiming for the method that resulted in the least amount of cruft-distribution
[03:35] <desrt> ie: well-isolated cruft that can easily be removed in the future
[03:35] <desrt> this is the best we could figure out given the constraints
[03:37] <robert_ancell> desrt, is there dconf api docs on the web?
[03:37] <desrt> zilch
[03:37] <desrt> i'll write some of those tonight, i guess
[03:37] <desrt> do you have any questions in the meantime?
[03:38] <robert_ancell> nope, I'll play around and email you anything I think of
[03:38] <desrt> k
[03:38] <desrt> i'll be around here for another hour i guess
[03:38] <desrt> gonna write the docs now, in fact
[03:39] <desrt> btw: i thought about it a bit and i think you'd do well to use a GtkTreeStore fully-populated on startup
[03:40] <desrt> populated at least with the key names -- maybe not the values at first
[03:40] <desrt> ie: lots of list() on startup
[03:40] <desrt> then monitor everything and track changes that way
[03:40] <desrt> it's not worth your effort to try to make a lazy custom GtkTreeModel
[03:41] <robert_ancell> sure
[03:43] <robert_ancell> desrt, should the editor use the engine or client api?
[03:43] <desrt> client
[03:44] <desrt> engine is really not meant to be used except by the ultra-insane
[03:44] <desrt> it's sort of humourously named to semi-reflect the gconf concept
[03:44] <desrt> and at the same time because i just didn't have a better name for it
[03:44] <desrt> but if you use the engine you have to make the dbus calls for yourself
[03:44] <desrt> that's how low-level it is :p
[03:44] <robert_ancell> ok
[03:44] <robert_ancell> what is a "resetlist"
[03:45] <desrt> i'll explain in a second
[03:45] <desrt> taking the dog out
[03:45] <desrt> for you it should be NULL
[03:45] <robert_ancell> ok, i'm just heading out for lunch
[04:50] <Amaranth> wow I think the csd/rgba gtk+ stuff has completely broken the metacity compositor
[04:53] <RAOF> Yup, I think so.
[07:26] <didrocks> good morning
[08:24] <seb128> hey there
[08:25] <didrocks> salut seb128
[08:26] <seb128> hey didrocks
[09:28] <pitti> good morning
[09:29] <pitti> seb128: just driving by, my train leaves in an hour; nice, you have a local box with the floppy issue?
[09:29] <seb128> pitti, yes
[09:29] <seb128> but I'm not on front of it now
[09:29] <seb128> I've regular access to it though
[09:29] <seb128> I can ping you next time when I'm around for debugging
[09:29] <pitti> 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] <seb128> ok
[09:30] <seb128> will GNOME is hanging I get floppy io errors printing on vt1
[09:30]  * pitti wishes everyone a nice weekend
[09:30] <seb128> pitti, thanks, have a nice weekend as well!
[09:30] <pitti> seb128: can you run ps while that happens? which processes are in 'D' state?
[09:30] <seb128> will do when I'm on the machine again later on
[09:31] <seb128> but let's debug that next week rather
[09:31] <seb128> there is also a floppy drive listed in gvfs
[09:31] <pitti> yep
[09:31] <seb128> ie in the places menus etc
[09:31] <pitti> right, i don't think we can get rid of that; there's a /dev/fd0 after all
[09:32] <pitti> the bit that we might be able to work around is the hang, not the existence
[09:32] <seb128> the kernel must have a way to check if the bios is lying
[09:32] <pitti> the existence/detection needs to be fixed in the kernel
[09:32] <pitti> linux doesn't rely on the bios for any other drive, but detects them itself
[09:32] <pitti> but perhaps floppies are harder to detect, I don't know
[09:32] <seb128> well perhaps it required trying a read
[09:33] <seb128> and they want to avoid that
[09:33] <seb128> it's noisy, slow and unconvenient
[09:33] <seb128> I will try to ask the kernel team
[09:33] <didrocks> pitti: enjoy your weekend! :)
[09:34] <pitti> can we just erase all notions of floppies from bioses, kernels, and everything else? :-)
[09:34] <seb128> lol
[09:34] <pitti> so in hardy or intrepid we spent hours on making floppies work again in the first place
[09:34] <pitti> and now we spend hours on hiding them
[09:35] <pitti> by now it'd be cheaper to buy those 5 remaining users an usb stick and be done with it :)
[09:35] <seb128> yeah :-)
[09:36] <pitti> at least the "blacklist floppy" workaround seems to work
[09:36] <seb128> well, turning the bios option works as well
[09:36] <seb128> but still only the few subscribed to the bugs will see that trick
[09:36] <seb128> thousands of users out there have their logging hanging for a while
[09:37] <pitti> ok, need to go, see you!
[09:37] <seb128> pitti, have fun, see you later!
[10:05] <huats> morning
[10:08] <didrocks> morning huats
[10:09] <huats> morning didrocks
[10:10] <seb128> lut huats
[10:10] <huats> hello seb128
[10:12] <Riddell> asac: you pinged?
[10:20] <mvo> seb128: if you need a tester for the usb vs floppy, I have a machine that is affected
[10:21] <seb128> mvo, usb vs floppy?
[10:21] <seb128> mvo, the issue there is GNOME login haging on floppy detection on boxes which have no floppy drive
[10:21] <mvo> seb128: that usb automount does not work if there is a floppy drive in the bios
[10:22] <mvo> seb128: aha, ok. I thought you were talking about the "usb-stick-no-longer-autodetected"
[10:22] <seb128> mvo, the bios seems to tell linux there is a floppy
[10:22] <seb128> mvo, I don't know about this one, bug number?
[10:22] <seb128> seems another one that should be fixed in lucid
[10:25] <mvo> seb128: give me a sec to find it
[10:26] <mvo> seb128: bug #583845
[10:26] <ubot2> 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] <rodrigo_> 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] <mvo> seb128: also appears in the forums
[10:27] <seb128> mvo, you didn't reply to my comment there
[10:27] <rodrigo_> but before merging them, I'd appreciate if there was a branch for lucid created
[10:27] <mvo> seb128: I can update the bug this afternoon, its my parents machine
[10:27] <seb128> mvo, ok, thanks
[10:27] <seb128> mvo, could you also copy the forum url on the bug?
[10:28] <seb128> rodrigo_, you have permissions to upload but not to commit?
[10:28] <rodrigo_> seb128, yes, seems so
[10:28] <seb128> weird
[10:28] <rodrigo_> seb128, let me try again
[10:29] <rodrigo_> no, no permissions
[10:29] <rodrigo_> $ bzr push lp:~ubuntu-desktop/couchdb-glib/ubuntu
[10:29] <rodrigo_> bzr: ERROR: Cannot lock LockDir(lp-69379536:///~ubuntu-desktop/couchdb-glib/ubuntu/.bzr/branchlock): Transport operation not possible: readonly transport
[10:30] <mvo> seb128: done, I will check this afternoon, it looks like its a dup of #539515
[10:30] <seb128> mvo, thanks
[10:31] <seb128> rodrigo_, is the ubuntu-desktop bzr bounded to the lucid source?
[10:31] <seb128> james_w, ^ do you know about this?
[10:31] <rodrigo_> seb128, it contains what is in lucid right now, yes
[10:32] <seb128> mvo, ok, that's the bug we were discussing before
[10:32] <seb128> rodrigo_, can you try to push to lp:ubuntu/couchdb-glib?
[10:32] <rodrigo_> seb128, hmm, but that branch is different, right? that is, it has all the source code, etc?
[10:33] <seb128> rodrigo_, right, I though you were using that
[10:33] <seb128> not sure why you get an error then
[10:33] <rodrigo_> seb128, lp:ubuntu/couchdb-glib already contains my upload packages
[10:33] <seb128> you should stop using ubuntu-desktop there
[10:34] <seb128> and just use lp:ubuntu/couchdb-glib
[10:34] <seb128> since you are not in ubuntu-desktop it doesn't make sense to store it there
[10:34] <rodrigo_> ah, ok, and use bzr-merge-upstream when doing new releases?
[10:34] <rodrigo_> although, as I said, that branch has my changes uploaded to maverick already
[10:35] <seb128> right
[10:36] <seb128> those have auto import of uploads
[10:36] <seb128> you can either commit to it
[10:36] <seb128> or let the autoimport grab the changes
[10:36] <rodrigo_> and just leave the u-desktop branch die with no updates?
[10:36] <seb128> delete it if you stop using it
[10:37] <rodrigo_> well, I like the u-desktop branch better, just has the debian/ dir and automatically gets the tarball
[10:37] <rodrigo_> usually kenvandine does the merge for me, so I can live with keeping doing that, if it's ok for you
[10:37] <seb128> well you can bzr merge-upstream http://url
[10:37] <seb128> in the other case
[10:37] <seb128> as you prefer
[10:38] <rodrigo_> ok, I prefer the ubuntu-desktop branch :)
[10:38] <rodrigo_> so, why do you have those u-desktop branches then?
[10:38] <seb128> you should perhaps move it somewhere out of ubuntu-desktop though
[10:38] <seb128> since you are not in this team
[10:38] <seb128> not sure what would be a better location though
[10:39] <seb128> rodrigo_, because it's faster to have the debian directory in bzr than the full source
[10:39] <rodrigo_> ok, I'll let kenvandine decide, since he's been managing the merges on that branch
[10:39] <seb128> ok
[10:39] <seb128> should we wait for him for your merge requests?
[10:39] <seb128> I've not worked on those so I would prefer to have him do those
[10:39] <rodrigo_> seb128, as you want, if you want to merge them, go on
[10:39] <rodrigo_> ok
[10:40] <seb128> rodrigo_, btw will you merge the new json-glib version?
[10:40] <seb128> we have 0.7.6-0ubuntu2
[10:40] <seb128> debian has 0.10.2-2
[10:40] <rodrigo_> hmm, didn't plan to, since I don't need it for couchdb-glib, but can do it if you want
[10:41] <rodrigo_> how do I merge a debian branch?
[10:41] <seb128> rodrigo_, I can do it if you want
[10:41] <rodrigo_> seb128, ah, ok, you'd better do it then :)
[10:41] <seb128> ok
[10:41] <seb128> I was just checking in case you didn't get the new version for a reason
[10:41] <rodrigo_> but, yes, how do I merge a debian branch?
[10:41] <seb128> since you are the one who did the previous update for couchdb-glib
[10:42] <rodrigo_> seb128, couchdb-glib builds fine with the json-glib from jhbuild, so I think it's ok
[10:42] <rodrigo_> let me check the version in jhbuild
[10:42] <seb128> rodrigo_, I'm not doing bzr merges for those, I will just grab what debian has and apply our changes
[10:42] <rodrigo_> ah
[10:43] <rodrigo_> 0.11.1 in jhbuild, so it's fine to upgrade
[10:43] <seb128> ok good
[10:52] <mvo> seb128: do you have problems with libgtk/metacity in maverick too? I get flicking all over the place, windows poping up etc
[10:53] <seb128> mvo, no, I'm not using maverick yet though there
[10:54] <seb128> mvo, I run it on my mini but with compiz
[10:54] <mvo> ok
[10:54] <seb128> I think bratsche made a patch for a similar issue, check with fta maybe he is the one what had the bug
[10:55] <seb128> rodrigo_, new json-glib uploaded
[11:02] <fta> mvo, bug 584287
[11:02] <ubot2> 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] <rodrigo_> seb128, cool
[11:33] <mvo> aha, nice. thanks fta
[11:43] <seb128> TheMuso, hi
[11:43] <seb128> 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] <desrt> nice glibc security update
[11:54] <desrt> update 1: arbitrary code execution from a file that only root can write to!
[11:54] <desrt> update 2: arbitrary code execution from.... executables...
[11:59] <james_w> rodrigo_: do you have "bzr launchpad-login" done on that machine? That looks like the error you get when pushing to http
[12:00] <rodrigo_> james_w, yes, I do, I can push to other branches with no problem
[12:00] <james_w> rodrigo_: would you file a bug against 'udd' then please?
[12:00] <rodrigo_> james_w, about me missing permissions on that branch?
[12:02] <james_w> rodrigo_: exactly, I'll investigate further
[12:02] <rodrigo_> ok
[12:07] <rodrigo_> james_w, 'udd'?
[12:07] <james_w> the 'udd' project on Launchpad
[12:09] <rodrigo_> ah, ok
[12:13] <rodrigo_> james_w, https://bugs.launchpad.net/udd/+bug/586767
[12:13] <ubot2> 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] <james_w> thanks rodrigo_
[12:29] <rodrigo_> seb128, what are the plans with pygi? is it going to make it to maverick?
[12:30] <seb128> rodrigo_, yes
[12:30] <seb128> I think robert_ancell was working on it
[12:31] <rodrigo_> ok
[12:31] <seb128> not sure when it will be ready though
[13:22] <seb128> mvo_, bug #574577
[13:22] <ubot2> Launchpad bug 574577 in command-not-found (Ubuntu) "spelling error: priviledge (affects: 1) (heat: 9)" [Undecided,New] https://launchpad.net/bugs/574577
[13:22] <seb128> mvo_, easy patch for you there
[13:22] <mvo_> thanks seb128
[13:22] <seb128> np ;-)
[13:29] <kenvandine> hey rodrigo_
[13:30]  * kenvandine waves good morning to everyone
[13:30] <kenvandine> rodrigo_, i read some of the scrollback, you need merges for the package branches that you already uploaded?
[13:31] <kenvandine> rodrigo_, now that you have per-package uploads it might make sense to move that branch
[13:33] <rodrigo_> kenvandine, yes, seb128 was suggesting that, although I'm ok with asking you to do the merges, if that's ok
[13:33] <kenvandine> that's fine too
[13:34] <seb128> ArneGoetje, could you look at bug #569442 when you have some time?
[13:34] <ubot2> 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] <seb128> ArneGoetje, and advice on what we should be doing
[13:35] <ArneGoetje> seb128: sure
[13:35] <seb128> ArneGoetje, thanks
[13:35] <kenvandine> rodrigo_, so couchdb-glib and evolution-couchdb?
[13:35] <rodrigo_> kenvandine, I'm working though on that branch to add the gir packages, so if you want, don't merge yet
[13:35] <kenvandine> ok
[13:35] <kenvandine> excellent :)
[13:36] <kenvandine> that is for couhdb-glib right?
[13:36] <rodrigo_> 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] <rodrigo_> yes
[13:36] <kenvandine> i can go ahead and do evolution-couchdb?
[13:36] <kenvandine> ok
[13:36] <kenvandine> i'll wait
[13:36] <rodrigo_> kenyes, as you wish
[13:36] <kenvandine> just give me a shout
[13:36] <rodrigo_> kenvandine, ok, as soon as they build ok, I'll push and ping you
[13:36] <kenvandine> thx
[13:48] <seb128> mvo_, bug #562729 has one change to review as well if you are interested
[13:48] <ubot2> 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] <seb128> mvo_, bug #562729 has one change to review as well if you are interested
[13:48] <mvo_> thanks seb128
[13:48] <seb128> ups
[13:48] <seb128> mvo_, yw
[13:48] <seb128> mvo_, sorry to bother you with those ;-)
[13:49] <mvo_> seb128: thats fine, thanks for looking at them
[13:49] <seb128> mvo_, I'm trying to clean a bit the list of patches on launchpad
[14:14] <seb128> mvo_, bug #433838
[14:14] <ubot2> 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] <seb128> mvo_, could you review this one as well, it's probably not something you want from reading mpt comments though
[14:14] <seb128> mvo_, either close it of change the tag to patch-needswork if you can
[14:14] <seb128> mvo_, thanks ;-)
[14:14] <mvo_> seb128: yeah, I think this needs to be rejected by mpt if he does not want it
[14:25] <bryceh> seb128, I see david scheduled a meeting but I see no sign of him on #ubuntu-meeting... is it being held elsewhere?
[14:26] <seb128> bryceh, the arsenal one?
[14:26] <bryceh> yeah
[14:26] <seb128> sorry, got reported
[14:26] <seb128> ara pinged us on an another channel asking if we could report
[14:26] <seb128> she didn't have time to look at the arsenal yet
[14:26] <bryceh> reported?
[14:26] <seb128> we agreed to do it another day
[14:27] <seb128> davidbarth, ^
[14:27] <bryceh> hrm, I got up early for nada
[14:27] <seb128> sorry :-(
[14:27] <bryceh> seb128, ok thanks for the info
[14:42] <mpt> 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] <seb128> mpt, hum ok, what do you suggest to get the bug out of the review queue?
[14:46] <seb128> mpt, does the change needs work or is incorrect or need a review?
[14:47] <mpt> seb128, where is this review queue and how is it composed?
[14:47] <seb128> mpt, the queue is basically all bugs in launchpad with a patch attached
[14:47] <mpt> seb128, if it's from the "patch" tag, then I guess the easiest way is to remove that tag
[14:47] <seb128> mpt, the bug can be tagged patch-needwork if it needs work
[14:47] <seb128> or incorrect
[14:48] <seb128> that would make it go out of the list
[14:48] <seb128> or is the change maybe correct but blocked on design to decide on what to do?
[14:50] <mpt> If it's from "Ubuntu Review Team" subscription, then the easiest way is to unsubscribe them
[14:50] <mpt> I have no idea whether it's correct or not. It depends what the design is!
[14:51] <seb128> https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide
[14:51] <seb128> mpt, ^
[14:52] <mpt> ah, hm
[14:52] <seb128> basically the patch either needs review, or has been reviewed
[14:52] <seb128> if it has been reviewed it should be applied or tagged needwork
[14:52] <seb128> we don't seem to have status out of this
[14:53] <mpt> On the one hand, it's brilliant that we have an effort to review unapplied patches now
[14:53] <mpt> On the other hand, the process doesn't seem to cater for this kind of case
[14:53] <seb128> right, I'm just trying to think what case that is now
[14:53] <seb128> so we can update the documentation for it
[14:53] <seb128> is that a "blocked on <something>"
[14:54] <seb128> where something is a designer comment there?
[14:55] <mpt> yeah
[14:55] <mpt> maybe patch-needsdesign
[14:55] <mpt> Are there any other cases where a patch might be blocked on something that isn't code review?
[14:56] <seb128> not that I can think of right now
[14:58] <mpt> seb128, ok, I've changed it to patch-needsdesign
[14:59] <vish> mpt: currently even the design bugs are currently being just tagged as patch-needswork
[14:59] <seb128> mpt, thanks
[14:59] <mpt> vish, "the design bugs"? Can you give an example?
[15:00] <vish> mpt: hmm , like the theme bugs  , let me find one
[15:03] <vish> 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] <seb128> vish, right, needswork means the submiter need to update the change
[15:06] <seb128> vish, there it's blocked on the reviewing side
[15:07] <vish> yup, the bug mentioned is a bit different though.. we should probably ad it to the default tag list
[15:07] <vish> add*
[15:08] <seb128> vish, I've raised the question on #ubuntu-reviews
[15:12] <vish> mpt: ah got one , Bug #160311
[15:12] <ubot2> Launchpad bug 160311 in metacity (Ubuntu) (and 5 other projects) "Resizing windows by grabbing window borders is difficult (affects: 121) (dups: 4) (heat: 650)" [Wishlist,Triaged] https://launchpad.net/bugs/160311
[15:12] <vish> but yeah , an new design specific tag would be nice
[15:12] <vish> a*
[15:15] <qense> davidbarth: Where you aware <https://blueprints.launchpad.net/ubuntu/+spec/dx-m-app-indicator> is still not accepted for the maverick series?
[15:15] <qense> It's still 'proposed'
[15:18] <vish> qense: is there an open bug for the weather-report applet to be ported to the indicators?
[15:18] <qense> vish: not that I am aware of
[15:18] <qense> but it seems likely there is one
[15:19] <vish> qense: hmm , it is among the default applets we somehow missed it for lucid
[15:19] <qense> vish: missed it for Lucid? What do you mean?
[15:19] <qense> It is a part of the calendar applet.
[15:19] <rickspencer3> seb128, chrisccoulson, hi
[15:20] <chrisccoulson> hi rickspencer3
[15:20] <vish> qense: nah , there is another one  , we can add it via  , but no one seems to have noticed it
[15:20] <seb128> hey rickspencer3
[15:20] <vish> *via "add to panel"
[15:20] <qense> vish: aha
[15:20] <qense> No, I didn't notice that. :)
[15:20] <seb128> vish, it's still there
[15:20] <rickspencer3> seb128, chrisccoulson I think we should send a heads up to the @ubuntu-devel about next week's update
[15:20] <seb128> vish, we didn't port applets but notification area icons
[15:21] <rickspencer3> and we should set up a bit of a Q+A in case we get questions
[15:21] <seb128> rickspencer3, I would wait for the ppa to be ready
[15:21] <rickspencer3> seb128, ack
[15:21] <seb128> rickspencer3, so we can do call for testing at the same time
[15:21] <rickspencer3> I started a wiki to coordinate the communication:
[15:21] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[15:21] <seb128> rickspencer3, thanks
[15:21] <rickspencer3> seb128, sounds good
[15:21] <vish> seb128: oh , ok , thanks
[15:21] <seb128> chrisccoulson sent the email about testing to ara and me today
[15:21] <rickspencer3> this is a big change, if it breaks folks, there are going to be some unhappy people out there
[15:21] <seb128> chrisccoulson, thanks btw
[15:22] <seb128> rickspencer3, it's going to break for some users
[15:22] <chrisccoulson> seb128 - you're welcome
[15:22] <chrisccoulson> i'm a bit stuck atm, our PPA just ran out of space ;)
[15:22] <seb128> rickspencer3, or some things are going to break, maybe not firefox or hopefully not it
[15:22] <seb128> chrisccoulson, did you contact #is about it?
[15:22] <chrisccoulson> i'm just about to
[15:23] <seb128> ok good
[15:23] <rickspencer3> seb128, I hope nothing breaks
[15:23] <rickspencer3> and I have all the faith in chrisccoulson
[15:23] <rickspencer3> none the less, sh*t happens
[15:23] <davidbarth> qense: i'm aware of that; it's mostly that we want to deal with that at the bug level; an extra bp is just more work to track
[15:23] <seb128> rickspencer3, well things like changing epiphany-gecko to webkit will break
[15:23] <rickspencer3> if nothing else, users are going to be surprised with a new version of FF
[15:23] <seb128> rickspencer3, epiphany-webkit is not at the same level than the gecko one
[15:23] <qense> davidbarth: ok
[15:24] <davidbarth> qense: we discussed that during the dx/desktop roundtable
[15:24] <chrisccoulson> pleasantly surprised, hopefully ;)
[15:24] <rickspencer3> right
[15:24] <seb128> but if we can make the firefox update smooth that's good
[15:24] <seb128> other side effects we will have to deal with
[15:25] <qense> davidbarth: Then I missed that point.
[15:25] <chrisccoulson> the other thing i'm still concerned about is that intrepid isn't on oldreleases yet
[15:25] <seb128> chrisccoulson, how is that a concern?
[15:25] <chrisccoulson> i don't want users to have any option of upgrading to intrepid after the migration, as the upgrade won't work
[15:25] <chrisccoulson> (not unless we also do the porting effort for intrepid too)
[15:25] <seb128> don't
[15:26] <seb128> did you try to let ask #is about that?
[15:27] <chrisccoulson> seb128 - asac suggested someone in #soyuz to talk to, although we just found out he's on vacation
[15:27] <Laney> date
[15:28] <asac> let me look at the security ppa state
[15:28] <seb128> asac, thanks
[15:28] <seb128> asac, hey btw, how are you?
[15:30] <rickspencer3> asac, https://wiki.ubuntu.com/DesktopTeam/Mozilla/FirefoxHardyJaunty
[15:36] <asac> seb128: i am in san jose ... 7+am ;)
[15:37] <asac> (currently on an interview) will check that wiki after
[15:37] <seb128> asac, oh, already awake or not yet to bed? ;-)
[15:37] <seb128> asac, good luck
[15:38] <asac> unfortunately i have a call right now ;) ... would have preferred to sleep longer ;)
[15:38] <bcurtiswx> sleep is overrated
[15:40]  * didrocks understands now why asac change a bug report status at 3AM :)
[15:40] <bcurtiswx> it's already after noon for most of you.. right?
[15:42] <asac> heh
[15:49] <seb128> didrocks, asac usually works at 3am though
[15:49] <seb128> ;-)
[15:49] <didrocks> seb128: heh :-)
[15:51] <seb128> kenvandine, hey
[15:51] <seb128> kenvandine, http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team-maverick-alpha-1.html
[15:52] <seb128> kenvandine, where do we stand for your items? alpha1 is next week, is that still on track?
[15:52] <kenvandine> i think so
[15:52]  * kenvandine updates WIs
[15:53] <seb128> kenvandine, thanks
[15:53] <kenvandine> 2 of those work items are about getting it in main for maverick
[15:54] <kenvandine> but i was told we are just putting it in the ppa for now
[15:54] <kenvandine> so i'll move those to a2
[15:54] <seb128> thanks
[15:54] <kenvandine> didrocks, is that your understanding too?
[15:54] <kenvandine> didrocks, you have one to seed the appmenu indicator for une
[15:55] <didrocks> kenvandine: sorry, chromium going crazy, trying to reload the page
[15:55] <didrocks> kenvandine: this one is for alpha2, right?
[15:56] <kenvandine> yeah
[15:56] <kenvandine> i think so
[15:56] <didrocks> kenvandine: oh, didn't choose the right place, changing it :)
[15:56] <kenvandine> well it is for alpha1 now
[15:56] <kenvandine> :)
[15:56] <kenvandine> can you move the 2 lines above it too?
[15:56] <kenvandine> :)
[15:56] <didrocks> kenvandine: the seed is for alpha2, what about yours?
[15:56] <didrocks> sure :)
[15:56] <kenvandine> thx
[15:56] <didrocks> kenvandine: done
[15:56] <kenvandine> thx
[16:04] <didrocks> seb128: FYI, I've changed slightly the place where my WI are (and rename them) with davidbarth to https://blueprints.edge.launchpad.net/ubuntu/+spec/dx-m-unity-une-integration and other dx WI
[16:04] <seb128> didrocks, ok
[16:23] <rickspencer3> tremolux, mvo_, hi, sounds like the "new apps on stable release" back end implementation is figured out
[16:23] <rickspencer3> anything we need to do before we can get started now?
[16:25] <tremolux> rickspencer3: ah, good news!  I haven't seen the details?
[16:25] <rickspencer3> wait
[16:25] <rickspencer3> I guess elmo has not totally signed off
[16:25] <tremolux> rickspencer3: where's the work happening?
[16:26] <tremolux> rickspencer3: we doing a new pocket?
[16:26] <mvo_> rickspencer3: yeah, we can start working
[16:27] <mvo_> rickspencer3: I was working on "discover what archives you are subscribed to today"
[16:29] <rickspencer3> tremolux, sounds like it's going to be built off of PPAs
[16:29] <rickspencer3> mvo_, is this in the spec?
[16:29] <rickspencer3> (in other words, I will bug you less if there is something I can read ;) )
[16:29] <tremolux> rickspencer3: gotcha, cool
[16:29] <mvo_> rickspencer3: its part of the buy-stuff spec, yes
[16:31] <rickspencer3> sweet
[16:31] <rickspencer3> thanks again you guys
[16:31] <rickspencer3> I am very happy this morning
[16:31] <rickspencer3> :)
[16:32] <seb128> "       Status: Incomplete => Expired"
[16:32] <seb128> bryceh, ^ is that new?
[16:33] <bryceh> seb128, yes
[16:33] <seb128> nice!
[16:33] <bryceh> :-)
[16:35] <bcurtiswx> which bug?
[16:35] <bcurtiswx> wait.. not a bug thing?
[17:37] <seb128> hum
[17:37] <mpt> seb128, do you know whether changing the time zone is supposed to require authentication or not?
[17:37] <seb128> chrisccoulson, do you have an estimation for firefox ppa being ready?
[17:38] <seb128> mpt, it's not for desktop users
[17:38] <seb128> mpt, we install a polkit profile which allows it
[17:38] <mpt> From System > Preferences > Time and Date it does, but from right-clicking on clock > Preferences it doesn't
[17:38] <seb128> the first one will be deprecated this cycle
[17:38] <seb128> the second one is allow in the desktop profile we install
[17:38] <chrisccoulson> seb128 - it's likely that i'm going to be uploading things in to the weekend
[17:39] <mpt> seb128, of course, I'm designing a replacement for both of them. What I want to know is whether I need to include the lock/unlock widget
[17:39] <seb128> chrisccoulson, ok, can you let me know when it's ready?
[17:39] <chrisccoulson> seb128 - yeah, no problem
[17:39] <seb128> mpt, oh, you need
[17:39] <seb128> mpt, well you need to handle the need for password in some cases
[17:39] <mpt> I can understand that you need to authenticate to change the time itself
[17:39] <mpt> just not sure about the timezone
[17:40] <mpt> Is the timezone a system thing or a user-specific thing?
[17:40] <seb128> you need permissions for that as well
[17:40] <seb128> system
[17:40] <mpt> ok, thanks seb128
[17:40] <seb128> you're welcome
[17:40] <mpt> that makes the layout easier
[18:52] <asac> chrisccoulson: on the wiki page about updating ffox ... there is one flaw: the jaunty update has to also go out together with karmic so upgrades still work
[18:53] <asac> so i think it should be hardy + jaunty + karmic
[18:53] <chrisccoulson> asac - yeah, i just realised that a few moments ago
[18:53] <asac> chrisccoulson: jaunty has 3.0?
[18:53] <chrisccoulson> i've got the jaunty update in the PPA and then started wondering how the upgrade works
[18:53] <chrisccoulson> asac - yeah, jaunty has 3.0
[18:54] <chrisccoulson> which is a bit of a pain ;)
[18:54] <asac> right.
[18:54] <asac> so yeah, then you need all three to be pushed out
[18:54] <chrisccoulson> that is a pain. i think i might cancel my holiday on monday ;)
[18:55] <asac> heh ... i remember exactly that thats life as a mozilla slave ;)
[18:55] <chrisccoulson> lol
[18:55] <asac> and never take holidays and be at home
[18:55] <asac> there always will be a firedrill in that week ;)
[18:55] <chrisccoulson> so, it's going to be difficult to get this all ready for next week, if we have to do karmic too
[18:57] <asac> chrisccoulson: when is the planned release? thu?
[18:57] <asac> or wed?
[18:57] <chrisccoulson> asac - well, 3.6.4 is scheduled for tuesday
[18:57] <asac> oh
[18:58] <chrisccoulson> i don't think we'd manage that, even without karmic ;)
[18:58] <asac> chrisccoulson: i think you should do hardy + karmic then
[18:58] <asac> in that way jaunty -> karmic upgrades still work
[18:58] <asac> and we dont support hardy -> jaunty upgrades
[18:58] <chrisccoulson> yeah, could do. i'm trying to make sure hardy -> lucid upgrades are working
[18:58] <asac> at least i asked mvo to disable hardy -> intrepid ... so for hardy there is only hardy->lucid
[18:59] <asac> mvo: did you do that?
[18:59] <chrisccoulson> and then i forgot to make sure that jaunty -> karmic upgrades still work ;)
[18:59] <asac> ;)
[18:59] <asac> chrisccoulson: yeah. so i would think you should really get karmic + hardy out if possible ... and jaunty asap
[19:00] <asac> chrisccoulson: let me know when the call for testing goes out so i can also blog about it
[19:18] <statik> hola desktoppers. i wonder if anyone could give me some tips on debugging window manager problems so that I could file a useful bug report
[19:18] <statik> i'm running maverick, and have started to have problems where most apps that I run don't have any window borders and flash constantly
[19:19] <statik> a few applications are working ok, such as terminal, x-chat, and chromium. many others have this strange flashing problem, including terminator and firefox
[19:21] <chrisccoulson> statik, that's bug 584287
[19:21] <ubot2> 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
[19:21] <statik> chrisccoulson, thanks!
[19:25] <rickspencer3> statik, thanks for using maverick!
[19:25] <rickspencer3> you da' man!
[19:25] <rickspencer3> :)
[19:26] <statik> rickspencer3, it's the only way to roll! gotta report bugs before the milestones, not after :D
[19:27] <rickspencer3> :)
[20:35] <ccheney> hmm still no air conditioning at home, hopefully the repairman will be back out later today
[20:35]  * ccheney needs to do OOo builds but doubts his system will keep from falling over under this circumstance
[20:43] <asac> Riddell: damn ... dropped the ball? already gone for weekend?
[20:44] <asac> Riddell: wanted to discuss what we can do about qt-embedded ... seems its not abi compatible, so i guess we would have to change sonames and then invent a mechanism to automatically ship everything building against qt to also build against that soname
[20:44] <asac> Riddell: any ideas?
[20:45]  * didrocks waves goodbye
[20:46] <didrocks> enjoy your week-end!
[20:46] <didrocks> (mine will be busy with Paris Ubuntu party :))
[20:49] <seb128> didrocks, thanks, have a great ubuntu party this weekend ;-)
[21:23] <asac> mvo: can you help out chrisccoulson testing ffox major version transition in combination with hardy -> lucid upgrade?
[21:24] <asac> i know you have quite sophisticated setup to test dist upgrades
[21:24] <mvo> asac: yes
[21:24] <asac> great. ... chrisccoulson ^^^ lets get mvo a present after this
[21:24] <mvo> asac, chrisccoulson: please send me a mail with the hardy ppa
[21:24] <mvo> and I can run a upgrade test against that
[21:24] <chrisccoulson> mvo - excellent, thanks. i will do that once i've got all the packages in
[21:26] <mvo> thanks
[22:02] <ccheney> my computer room temp is at 30C and rising, have to shutdown the box i normally run irc on, apparently the repairman will be out either later tonight or by tomorrow morning :-\
[22:02]  * ccheney hopes its by later today
[22:03]  * ccheney bbl
[22:04] <ccheney> main part of the house is at 28C and rising about 3C per hour it seems, had to completely turn off the AC unit due to the problems it was having
[22:25] <Riddell> asac: which qtembedded?
[22:26] <Riddell> I lose track
[22:26] <asac> Riddell: heh
[22:26] <asac> Riddell: so ... you can build qt with --for-embedded or something
[22:26] <asac> that will produce a qt that is good for without x
[22:27] <asac> unfortunately that lib has the same soname upstream, but is binary incompatible
[22:27] <asac> so i think to ship tha tin the same archive it needs a distinct soname
[22:27] <asac> however, most qt apps should just work if they are built against that
[22:28] <asac> so i think after experimenting a bit and verifying that thats the case it would be best to somehow get all qt packages build an embedded version
[22:28] <asac> of course if you have better ideas, shoot
[22:29] <asac> note: take this with a grain of salt. i didnt check this on my own, and we are still investigating. just anted to get your brain working ;)
[22:29] <asac> sand ;)
[22:29] <asac> not sure what the right phrase is ;)
[22:30] <Riddell> asac: mm, all qt apps?  if that includes KDE that's quite a lot
[22:30] <Riddell> but I'm pretty sure KDE will require X
[22:31] <Riddell> and probably most Qt apps do for something
[22:31] <Riddell> probably not a quick job to find every qt package that doesn't need X and change its packaging to build twice
[22:31] <asac> Riddell: right. could be. but we dont know yet. so what i think would be good would be an easy way to locally build
[22:31] <asac> against embedded to try
[22:32] <asac> and once we know how many work/do not work, we can see if we need to make packages or something out of it
[22:33] <asac> is there some magic debhelper for qt apps that we could use to provide such a "try locally or in ppa" feature?
[22:34] <asac> Riddell: what do you think do qt/kde apps use x for usually?
[22:34] <Riddell> qt apps is quite a wide category in terms of build systems, some are qmake, some cmake, some autotools so no one way to build them
[22:34] <asac> getting settings from an x window?
[22:34] <Riddell> some packages will be cdbs, some debhelper 7 etc
[22:34] <asac> yeah, but you probably have a cdbs .mk and debhelper plugin etc. that could be hacked?
[22:35] <asac> or are many packages still really manual?
[22:35] <Riddell> very little is manual
[22:36] <Riddell> but it's a cross of cdbs/debhlper 7 and qmake/cmake/autotools
[22:36] <Riddell> so lots of combinations of build systems
[22:38] <asac> yeah. but at least an infinite set ;)
[22:38] <asac> hehe
[22:38] <asac> ok
[22:38] <asac> didrocks: you know the gconf key for the une desktop background ?
[22:39] <asac> is that already overloaded in some gconf hook?
[22:39] <asac> e.g. do we ned to take care of the order/number to ensure that ours is used?
[22:40] <asac> err s/infin/fin/
[22:48] <ccheney> yipee, air conditioning people will be here in 30m so maybe we won't have to stay in the heat and without computers much longer :)
[22:51]  * ccheney has 5 OOo builds to do, so needs his computer back up asap