[07:58] <didrocks> morning mvo & tseliot
[07:58] <tseliot> morning didrocks :-)
[07:59] <mvo> hey didrocks and tseliot
[07:59] <mvo> didrocks: the sponsoring for naitulis-sendto is still open?
[08:00] <tseliot> hey mvo
[08:01] <didrocks> mvo: yes, seb128 told me you will love sponsor it :)
[08:02] <mvo> didrocks: heh :) sure
[08:12] <pitti> Good morning
[08:26] <didrocks> Guten Tag pitti
[08:26] <pitti> hey didrocks
[08:43] <pitti> hey tseliot
[08:43] <tseliot> hey pitti :-)
[08:44] <seb128> hello pitti tseliot
[08:44] <tseliot> hi seb128
[08:47] <mvo> didrocks: I will do the sponsoring once I sorted some issues with the new python, I got some errors during this mornings update and it seems like all my packages (well, all python packages) needs updates in how setup.py is used.
[08:52] <davidbarth> pitti: guten morgen
[08:52] <pitti> hey davidbarth
[08:52] <pitti> bonjour
[08:52] <davidbarth> pitti: there is a new release notify-osd ready for jaunty
[08:53] <crevette> hello
[08:53] <crevette> if someone was kind enough to test the latest bluez release (4.32) in my ppa, the previous one was crashy
[08:53] <pitti> davidbarth: nice; do you think it has time until this afternoon? I'd like to teach kenvandine_wk how to handle this
[08:54] <davidbarth> pitti: sure, i still have a few gsd/gpm patches to update, this afternoon will be perfect
[08:55] <davidbarth> crevette: bluez or also the bluez-gnome part?
[08:55] <crevette> my ppa is https://edge.launchpad.net/~bmillemathias/+archive/ppa, I 'd like to have some feedback before asking FFE, I tested on my side, but I think it worth some test
[08:55] <crevette> davidbarth, only bluez
[08:55] <crevette> bluez-gnome is dead
[08:55] <davidbarth> uh!?
[08:55] <crevette> it is going to be replace by gnome-bluetooth
[08:56] <crevette> heay kind of tricky
[08:56] <crevette> http://www.hadess.net/2009/02/we-have-fork.html
[08:56] <davidbarth> crevette: what about the thing in the panel that uses libnotify notifications? is it also in the new bluez?
[08:56] <crevette> davidbarth, bluez-gnome
[08:56] <davidbarth> but that's not going to be shipped in Jaunty?
[08:58] <crevette> I don't know
[08:58] <crevette> I need to see that with hadess
[09:00] <crevette> davidbarth, you're the guy working on new notification system right?
[09:00] <davidbarth> crevette: yes, one of them that is
[09:01] <davidbarth> and so if we provide patches for bluez-gnome, i'd like to be sure that we're patching the right package... ;)
[09:01] <crevette> davidbarth, the code is almost the same I guess
[09:01] <davidbarth> crevette: what would be the alternative package to check then? packages in your PPA?
[09:02] <crevette> davidbarth, I guess we can continue with bluez-gnome for jaunty if there is no release before
[09:03] <crevette> davidbarth, there is no alternative package (I guess you're talking about gnome-bluetooth), hmm
[09:03] <crevette> actually gnome-bluetooth already existbut it does another purpose, it does Obex file sharing
[09:03] <crevette> but now it is deprecated in favoor of gnome-user-shaer
[09:04] <crevette> (bluetooth on GNOME is kind of difficult to track)
[09:04] <crevette> :)
[09:04] <davidbarth> crevette: dunno; between seb128, bastien and you, when will you be selecting what goes into jaunty?
[09:04] <crevette> bastien is from RH so I guess I won't take decision for ubuntu :)
[09:05] <crevette> and I'm not a core developer so but I think someone needs to see that with Bastien
[09:07] <davidbarth> crevette: ok, i'll ask cody (bratsche) to take a look at gnome-bluetooth too; but for the moment we're staying with bluez-gnome for our patches
[09:07] <davidbarth> crevette: thanks for warning me of the possible shift
[09:07] <crevette> hey no problem :)
[09:07] <crevette> davidbarth, about our patch you'd be interested with gnome-user-share also wich use actions in notification
[09:07] <crevette> I know that because I did the patch upstream :)
[09:10] <davidbarth> crevette: ;) good to know; it's one of the tricky interaction cases that mpt is on
[09:10] <crevette> why ? honnestly I don't know the details of the new notification implementation
[09:15] <davidbarth> crevette: because it both makes sense to request user feedback when accepting a file upload for security reasons, but at the same time it's a bit like receiving a mail: you may want to defer the time when you actually want to read it
[09:16] <crevette> the notification is displayed once the file is received actually
[09:16] <crevette> and you have 2 action, display the file or reveal it in the file manager
[09:16] <crevette> actions
[09:21] <davidbarth> crevette: interesting, we'll probably get back to you on that then; but we're not there yet. thanks
[09:21] <crevette> okay
[09:21] <mpt> crevette, for that I suggest having a "Received Files" or similar window that lists the files you've received so you can open/reveal them at your leisure
[09:21] <mpt> That would also work better for the case where you receive half a dozen files in quick succession
[09:22] <didrocks> mvo: ok, no problem :)
[09:22] <mpt> instead of having a cascade of bubbles
[09:22] <mpt> they would just be items in the window.
[09:23] <didrocks> mvo: I didn't have to change anything in setup.py for my previous upload (gnome-python) to make it builds with the new python version. Just change some paths in *.install files for {dist,site}packages
[09:23] <crevette> just my opinion, the notification bubble is not large enough
[09:24] <mpt> crevette, there's a similar example here: https://wiki.ubuntu.com/NotificationDesignGuidelines#Normal%20window
[09:30] <mvo> didrocks: its using autotools (configure) instead of distutils it seems, I think thats the explaination
[09:35] <crevette> mvo, hello, would you mind merging https://code.edge.launchpad.net/~bmillemathias/utils/ubuntu-bluez-4.x/+merge/3982 ? I don't know if I did the right values (like the reviewer)
[09:38] <didrocks> mvo: yeah, that's right. distutils have been patched. Can you write somewhere in the wiki what you do so that we can use it again for other packages in the same configuration, please?
[09:43] <mvo> didrocks: I try to talk to doko about it, I think its something that should go to ubuntu-devel-announce
[09:44] <mvo> crevette: give me a sec, I have a look
[09:44] <mvo> crevette: https://code.edge.launchpad.net/~ubuntu-dev/utils/bluez-4.x <- says "this branch has not been pushed yet"
[09:45] <mvo> crevette: what did you base your merge on? I need to know what to checkout :)
[09:48] <didrocks> where can I push nautilus-sento-universe package? in some kind of ~ubuntu-deskop-universe? :/
[09:50] <crevette> mvo, perhaps I didn't understand the process of merging, I just wanted you to push the latest commit of https://code.edge.launchpad.net/~bmillemathias/utils/ubuntu-bluez-4.x to lp:~ubuntu-dev/utils/bluez-4.x
[09:50] <crevette> mvo, but actually you can wait as 4.31 won't be packaged, as it is too crashy
[09:52] <mvo> crevette: oh, I think the confusion is that there is a "bluez-4.x" and "ubuntu-bluez-4.x" branch
[09:53] <mvo> crevette: and one of them is not pushed
[09:53] <mvo> superm1: could you remove https://code.edge.launchpad.net/~ubuntu-dev/utils/bluez-4.x ? LP says the branch is not pushed yet and it looks like https://code.edge.launchpad.net/~ubuntu-dev/utils/ubuntu-bluez-4.x is the right one?
[10:28] <crevette> davidbarth, apparently we will have a release of gnome-bluetooth soon, so I think it can replace bluez-gnome
[10:52] <didrocks> mvo: thanks for the sponsoring :)
[10:53] <didrocks> mvo & seb128_ (hi seb!): an idea on that: where can I push nautilus-sento-universe package? in some kind of ~ubuntu-deskop-universe? :/
[10:54] <seb128_> didrocks: because there is no corresponding product on launchpad?
[10:55] <didrocks> seb128_: didn't check yet, but I was just wondering about *where* to push. MOTU will not be available to push in ~ubuntu-desktop bzr repository and will ping you for that
[10:55] <didrocks> s/available/able
[10:55] <seb128_> didrocks: don't use bzr?
[10:56] <didrocks> seb128_: so, let's say we only use bzr for desktop team for packages in main ?
[10:56] <seb128_> right
[10:56] <seb128_> or talk to mvo he's the one promoting bzr for everything ;-)
[10:56] <didrocks> seb128_: ok :)
[10:57] <mvo> bzr
[10:57] <mvo> !
[10:57]  * mvo leaves for lunch and lets seb128_ sort out the porblme ,)
[10:58] <didrocks> seb128_: FYI, I updated eel, but I have a question. There are some library changes (dropping symbols), but no soname changes (only minor version change). What to do? cf http://paste.ubuntu.com/125208/
[10:58] <james_w> didrocks: you could put it under ~ubuntu-dev
[10:59] <didrocks> james_w: I just didn't understand if it was still experimental or if we have commit rights on it? (and it's updated automagically if someone is not using bzr?)
[10:59] <seb128_> didrocks: nothing, they don't assure abi stability for this library
[10:59] <seb128_> didrocks: it's deprecated anyway nautilus stopped using, etc, it's just for applications not updated yet
[11:00] <davidbarth> crevette: ok, so i'll be watching closely
[11:00] <didrocks> seb128_: ok, but the "normal" process is to bump soname in this case, right? (if they don't say "we don't bother" ;))
[11:00] <seb128_> yes
[11:00] <seb128_> hey pedro_!
[11:00] <james_w> didrocks: nothing is changing there
[11:00] <james_w> didrocks: it works the same way as pushing under ~ubuntu-desktop
[11:00] <didrocks> seb128_: so, I will open the sponsoring request in the afternoon
[11:00] <pedro_> hello seb128_!
[11:01] <seb128_> didrocks: ok good
[11:01] <seb128_> pedro_: you were on holidays? I was starting to wonder what happened to you, good to see you back ;-)
[11:01] <didrocks> james_w: ok, so, it's not updated if someone don't use bzr, for the moment, right?
[11:01]  * didrocks is sure that james_w has an hilight on bzr ;)
[11:02] <pedro_> seb128_: yeah even the bots need to take those :-P. thanks you, it's nice to be back
[11:02] <james_w> didrocks: correct
[11:02]  * pedro_ feels like new
[11:02] <james_w> the fist one :-)
[11:02] <didrocks> james_w: :-)
[11:02] <didrocks> james_w: ok, thanks :)
[11:02] <seb128_> pedro_: enjoyed your holidays?
[11:02]  * seb128_ hugs pedro_
[11:03] <pedro_> seb128_: yup, went to the south with my parents, haven't taken holidays with them since mm 4 years or so, so it was amazing :-)
[11:03]  * pedro_ hugs seb128_ back
[11:04] <seb128_> pedro_: sounds excellent!
[11:05] <seb128_> pedro_: mark all bug emails as read or you will spend the week catching up with that backlog
[11:06] <pedro_> seb128_: ok! will do it
[11:08] <pitti> hey pedro_, welcome back
[11:08] <pedro_> hello pitti!, thanks you :-)
[11:08] <pitti> seb128_: I think we need to sponsor those netbook screen size fixes by Thursday (UIF)
[11:08] <pitti> seb128_: I'm grabbing the pidgin one now, FYI (just to avoid clashes)
[11:09] <seb128_> pitti: ok thanks, I'm busy with the new GNOME, tarballs due today
[11:09] <pitti> seb128_: ok; if I touch something GNOMEish, I'll ask you before then
[11:09] <seb128_> pitti: thanks
[11:09] <pitti> seb128_: just uploaded policykit-gnome (but I don't think that's affected by your updates)
[11:10] <seb128> no it's not
[12:09] <didrocks> seb128: bug #336657 when you will have some time :)
[12:26] <seb128> didrocks: ok, want other updates?
[12:36] <didrocks> seb128: with pleasure :)
[12:37] <didrocks> seb128: btw, I can't remember if you found a workaround for gnome-python-extras and the doc, or if we wait for usptream to respond about the html doc?
[12:38] <seb128> didrocks: workaround is to not install those files for now
[12:38] <seb128> didrocks: http://download.gnome.org/sources/yelp/2.25/yelp-2.25.1.tar.gz
[12:38] <seb128> didrocks: http://download.gnome.org/sources/glibmm/2.19/glibmm-2.19.3.tar.gz
[12:40] <didrocks> seb128: ok, begin some work on them. For gnome-python-extras, do you want that I propose a new version excluding the html doc for the right .install file?
[12:40] <seb128> didrocks: open the bug upstream first, I'm not sure if we should wait for a new version or not
[12:40] <didrocks> seb128: oki
[12:41]  * didrocks is fidding its "Contribution page" for UDS sponsoring first :)
[12:41] <didrocks> feeding*
[12:47] <seb128> mvo: do you think you could review bug #327465 this week? it's a sponsoring request waiting for a while and it would be nice to have it reviewed before the interface freeze this week
[12:50] <Ng> seb128: so am I the only person with weird ssh-agent borkages in jaunty? :)
[12:50] <seb128> Ng: yes
[12:51] <seb128> we didn't get ssh agent complains since the distro sprint some weeks ago
[12:51] <seb128> and it's working fine on all my boxes
[12:52] <Ng> seb128: does $SSH_AGENT_PID point at seahorse-agent or ssh-agent?
[12:52] <seb128> seahorse
[12:52] <Ng> mine is pointing at ssh-agent, but even with use-ssh-agent disabled in Xsession.options it still didn't seem to all work properly
[12:52] <seb128> hum
[12:52] <seb128> "/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --execute x-session-manager"
[12:52] <seb128> in fact
[12:52] <Ng> I'm convinced I shouldn't have both running
[12:52] <seb128> $ echo $SSH_AUTH_SOCK
[12:53] <seb128> /tmp/keyring-i1WBlI/socket.ssh
[12:53] <Ng> yeah I have that process to
[12:54] <Ng> according to lsof, no process has my socket.ssh open
[12:57] <mvo> seb128: I have a look now
[12:57] <seb128> mvo: thanks
[12:58] <seb128> Ng: gnome-keyring has mine open, maybe yours crashed or something?
[12:59] <Ng> I just rebooted with use-ssh-agent disabled and it's generally still all not working
[12:59] <seb128> I would blame something in your user config
[12:59] <Ng> as soon as I log in and fire up ssh I get asked to unlock a keyring (should have happened when I log in), ssh says it failed to read the auth details from the socket, and asks for my password
[12:59] <seb128> but dunno what ;-)
[13:00] <Ng> I would be blaming the software for breaking on what was previously a working config ;)
[13:00] <seb128> right
[13:00] <seb128> but you might have something which trigger the issue
[13:00] <seb128> no clue what that is though
[13:00] <Ng> it must be unlocking the keyring to some extent because NM doesn't prompt for wifi passwords
[13:00] <seb128> open a bug on bugzilla.gnome.org if you want they are pretty responsive usually
[13:03] <Ng> seb128: k, ta
[13:08] <Ng> seb128: huh, do you have two seahorse-agents running?
[13:10] <seb128> Ng: not sure, I've some dbus... lines and one seahorse-agent line, doesn't matter for ssh since seahorse doesn't do ssh anyway
[13:11]  * kenvandine_wk waves
[13:12] <mvo> james_w: with jauntys bzr-buildpackage, I'M unable to build lp:~ubuntu-desktop/gnome-control-center/ubuntu - it seems like the tarball is unpacked to the wrong level, do you have any idea?
[13:12] <james_w> mvo: python2.6 hates me
[13:13] <mvo> james_w: heh :) not just you ;)
[13:13] <james_w> I can't get python2.6 installed to debug either
[13:13] <mvo> I spend my morning updating all the setup.py, debian/rules for my stuff
[13:13] <james_w> I'm going to switch to a chroot to to that in a minute, once I've finished my current task
[13:13] <mvo> james_w: what errors do you get? have you talked to doko about them yet?
[13:14] <james_w> mvo: no errors
[13:14] <mvo> james_w: no rush :)
[13:14] <james_w> silent breakage
[13:14] <mvo> woah
[13:14] <mvo> even better :(
[13:14] <james_w> asac: was debugging it earlier in #ubuntu-devel
[13:14] <james_w> using "python2.5 /usr/bin/bzr" apparently works
[13:14] <asac> mvo: i repointed my link to python2.5 for now
[13:15] <asac> works well again
[13:15] <asac> but since you need to work on python2.6 not sure if its an option for you
[13:16]  * asac feels scared about libc update arriving ;)
[13:16] <asac> wish me luck
[13:17] <mvo> asac: thanks! not a good option, but good to know
[13:17] <mvo> james_w: thanks, I just checked the backlog and found it
[13:18] <asac> mvo: command-not-found and gnome-app-install failed to upgrade
[13:18] <asac> ;)
[13:18] <mvo> hu?
[13:18] <asac> oh
[13:18] <Ng> seb128: yeah gnome-keyring-daemon is segfaulting
[13:18] <mvo> asac: could you please give me details
[13:18] <asac> i think thats because of the link ;)
[13:18] <asac> mvo: ValueError: /usr/bin/python does not match the python default version. It must be reset to point to python2.6
[13:18] <seb128> Ng: good, use apport to report the crash ;-)
[13:18] <mvo> asac: the joy of the python world
[13:18] <asac> ;)
[13:19] <mvo> asac: *no comment*
[13:19] <asac> i always felt that using python everywhere reduces the overall quality of desktop ;)
[13:19]  * Ng wonders why apport isn't whining at him these days
[13:19]  * asac hides
[13:21] <Ng> I'm also not really sure if I want to upload the guts of my keyring daemon to launchpad :/
[13:22] <seb128> Ng: use sudo apport-retrace .crash locally and open a bug attaching the clean stacktrace
[13:22] <Ng> ah nice
[13:22] <Ng> thanks
[13:23] <seb128> Ng: you can try to use gdb and give the first function there so we can look if that's a duplicate quickly
[13:24] <Ng> unhelpfully the first function is in a -dbg package I don't have installed
[13:24] <Ng> (I assume, it's showing up as ???)
[13:24] <Ng> the second is egg_secure_realloc ()
[13:26] <seb128> Ng: could be bug #332342
[13:28] <Ng> hmm, it looks a bit different
[13:28] <seb128> Ng: open a new bug then
[13:28] <Ng> will do :)
[13:28] <pitti> davidbarth: hm, is there a new LP project page for notify-osd now? it's apparenlty not "notify-osd" :)
[13:28] <mvo> seb128: I replied to the sponsoring bug, patches does not apply cleanly anymore and bzr-builddeb does not like me anymore ,)
[13:29] <pitti> kenvandine_wk: davidbarth has a new notify-osd upstream version; this is a bzr-maintained package, and would be an excellent exercise/mentoring matter
[13:29] <seb128> mvo: ok thanks and sorry for the nag about this one
[13:29] <davidbarth> pitti: it is: https://launchpad.net/notify-osd
[13:29] <pitti> kenvandine_wk: I need some lunch first, can we do that in an hour or two?
[13:29] <kenvandine_wk> pitti: great!
[13:29] <mvo> seb128: np, thanks for the reminder
[13:29] <kenvandine_wk> yes
[13:30] <mvo> (and sorry for my lack o fattention)
[13:30] <pitti> davidbarth: ah, apparently I mistyped then
[13:31] <seb128> pitti: bug #336640
[13:32] <seb128> pitti: shouldn't the retracer clean the coredump.gz in such cases?
[13:33] <pitti> seb128: I guess it should, yes
[13:34] <pitti> seb128: in other news, launchpadlib just started to work on ronne \o/
[13:34] <seb128> cool!
[13:34] <pitti> thus we can move from p-lp-bugs to launchpadlib
[13:34] <seb128> yeah!
[13:34] <pitti> but I need some lunch first, 14:30 already...
[13:34] <seb128> pitti: enjoy your lunch
[13:34] <huats> hello everyone !
[13:38] <seb128> lut huats
[13:39] <seb128> huats: how are you?
[13:39] <huats> seb128: better
[13:39] <seb128> good!
[13:39] <james_w> huats: salut!
[13:39] <huats> not completly healer
[13:39] <huats> but better :)
[13:39] <huats> thanks seb128
[13:39] <huats> what about you ?
[13:39] <huats> hey james_w !
[13:39] <seb128> I'm good thanks
[13:40] <huats> seb128: don't bother to speak in english with james_w, he speaks a perfect french...
[13:40] <james_w> huats: would you be able to take a look at pywebkitgtk today?
[13:40] <huats> james_w: it is on my todo list
[13:40] <james_w> huats: excellent
[13:40] <james_w> huats: http://bugzilla.gnome.org/show_bug.cgi?id=573753 might be of interest to you
[13:40] <huats> james_w: I am trying to tackle it today or tomorrow..
[13:41] <huats> james_w: I have a look too
[13:45] <crevette> davidbarth, bratsche is working for canonical ?
[13:45] <bratsche> crevette: Hi.  Yes.
[13:45] <crevette> ah okay
[13:45] <crevette> hello bratsche
[13:46] <bratsche> crevette: Hey
[13:47] <bratsche> I can't seem to get my phone and laptop to work with bluetooth, so I'm not sure if I can test any patch I can come up with here. :/
[13:47] <crevette> bratsche, you're assigned to test bluetooth ?
[13:47] <crevette> :)
[13:47] <bratsche> I'm assigned to patch bluez-gnome for the notify stuff.
[13:48] <bratsche> So unless someone else has some bluetooth hardware to test with, I think I'm just going to have to take a shot in the dark on this one and hope it works right. :/
[13:51] <crevette> bratsche, what is the brand of you phone ?
[13:53] <bratsche> G1
[14:04] <asac> mvo: you are the kvm expert. how can i quickly get a hardy kvm image that just works?
[14:07] <mvo> asac: ubuntu-vm-builder kvm hardy --rootsize=20000
[14:07] <mvo> asac: but I think there are also pre-build ones around, give me a sec
[14:12] <asac> mvo: good. and how do i get X setup? is all ready for use?
[14:12] <mvo> asac: oh, that is a minimal one
[14:12] <mvo> asac: hm, I could upload you one of mines with X setup etc
[14:12] <asac> mvo: are those private?
[14:12] <asac> mvo: how hard is it?
[14:13] <asac> can i just go there and say: sudo apt-get install ubuntu-desktop?
[14:13] <asac> mvo: do you know how well that works on amd64?
[14:14]  * asac trashes a fedora VM to get some space
[14:15] <mvo> asac: with the latest updates it works fwell for me
[14:16] <mvo> asac: with the ubuntu-vm-builder ones you can just do apt-get install ubuntu-desktop?
[14:16] <mvo> (no ? at the end :)
[14:16] <asac> hah
[14:16] <asac> ok
[14:16] <asac> i will try that asap
[14:17]  * Ng being stupid, where is it pitti's pool of debsyms packages lives?
[14:17] <asac> Ng: its ddebs.ubuntu.com
[14:17] <Ng> ta
[14:19] <pitti> Ng: https://wiki.ubuntu.com/DebuggingProgramCrash has some documentation
[14:20] <Ng> thanks
[14:20] <Ng> erk, it exploded a little over libc6
[14:20] <Ng> do those ddebs lag a little?
[14:20] <pitti> Ng: yes, they do, a couple of hours
[14:21] <Ng> ok. I sucked in a new libc6 just before lunch, so I'll check back on this later :)
[14:21] <pitti> Ng: ddebs.u.c. is a horrible hack, but the best we can get without proper soyuz support :/
[14:21] <Ng> heh
[14:21] <Ng> hack or not, it's a truly fantastic idea
[14:36] <superm1> mvo, sure. trashed.
[14:37] <mvo> superm1: thanks
[14:39] <superm1> mvo, i seem to think the last few uploads might not have been put into bzr when sponsored to the normal tree.  they were uploaded as a diff rather than a merge request, but they should have been fairly minimal
[14:43] <mvo> superm1: thanks, I will remember that when doing a merge
[14:44] <pitti> seb128: ok if I sponsor bug 336518?
[14:44] <seb128> pitti: yes, thank you
[14:48] <pitti> seb128: ok if I sponsor bug 336657 ?
[14:48] <seb128> pitti: yes, thank you ;-)
[14:54] <didrocks> pitti: hope you will like it :)
[14:55] <pitti> didrocks: at some point we should move the bzr to ~ubuntu-desktop, but I won't worry about this for now
[14:56] <didrocks> pitti: ? if you accept the sponsoring, you can then bzr push to ~ubuntu-desktop, that's the goal :) When the branch is created, I generally ask for merge as I can't write into it
[14:56] <pitti> didrocks: ok, will do
[14:59] <pitti> didrocks: do you know the "UNRELEASED"/dch -r/debcommit -r schema?
[14:59] <didrocks> pitti: sincerely, no. I only debcommit the change at the end
[15:00] <pitti> didrocks: so:
[15:00] <pitti> - only commit one change at a time, not an entire heap
[15:00] <pitti> however, the change should be consistent
[15:01] <pitti> so, in your case, it was correct (since changing build-deps goes along with updating upstream version)
[15:01] <pitti> didrocks: while you are working on a new upload, keep the changelog target as UNRELEASED, not jaunty
[15:01] <pitti> once you think that you did enough work and it should be uploaded, do
[15:01] <pitti> dch -r
[15:01] <pitti> -> changes UNRELEASED to jaunty
[15:01] <pitti> and
[15:01] <pitti> debcommit -r
[15:02] <pitti> -> commits the UNRELEASED->jaunty change to bzr, and adds a version number tag
[15:02] <pitti> didrocks: that makes it easy to reconstruct previous uploaded versions from the bzr history
[15:02] <didrocks> hum, I don't get it, there will be 2 log revision for each upload?
[15:02] <pitti> didrocks: also, if you check out a branch, you immediately see whether there are commited changes which aren't uploaded yet (UNRELEASED) or whether you have to use dch -i to start a new changelog version (jaunty)
[15:03] <pitti> didrocks: no, there will be one commit for each change to the package, and one commit per upload
[15:04] <didrocks> pitti: for each "consistent change", I have to tell it in the changelog, no?
[15:05] <pitti> didrocks: right
[15:05] <pitti> didrocks: and "debcommit" will grab the changelog entry from debian/changelog, and use it as bzr changelog
[15:05] <pitti> didrocks: look at  http://bazaar.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/
[15:05] <pitti> didrocks: there you see individual changes, and which revisions got uploaded as which package version
[15:06] <didrocks> pitti: let me check this (slow ;))
[15:06] <pitti> didrocks: bzr get lp:~ubuntu-desktop/eel/ubuntu/
[15:06] <pitti> didrocks: and check bzr log
[15:06] <didrocks> pitti: that's what I am currently doing :)
[15:06] <pitti> and look at
[15:06] <pitti> bzr diff -c 5
[15:07] <pitti> whoops
[15:07] <pitti> I messed up
[15:07] <didrocks> yeah, I corrected it myself ^^
[15:07] <pitti> there was a vcs-bzr already
[15:08] <pitti> but a wrong one
[15:08] <didrocks> really? I put it :/
[15:08] <pitti> upstream project is called eel, not eel2
[15:09] <didrocks> oh, crap, I did it offline and didn't check atm on launchpad
[15:09] <pitti> didrocks: please rm -r above checkout
[15:10] <pitti> didrocks: fixed, please bzr get it again
[15:10] <pitti> meh!
[15:10] <pitti> I HATE HATE HATE control.in
[15:11] <didrocks> pitti: normal, when you aren't get used to them :)
[15:12] <pitti> didrocks: ok, please get it again (or use bzr pull --overwrite)
[15:12] <didrocks> pitti: how can you fix this? bzr uncommit and then --force_overwrite ?
[15:12] <pitti> it should finally be good now
[15:13] <pitti> didrocks: right
[15:14] <pitti> didrocks: ok, uploaded; thanks!
[15:14] <didrocks> pitti: thanks a lot for the explantion. I understood from the jockey's example
[15:14] <didrocks> pitti: just one question
[15:14] <pitti> didrocks: please go into your branch and do bzr pull lp:~ubuntu-desktop/eel/ubuntu/, so that your branch becomes consistent with the ubuntu-desktop one
[15:15] <pitti> didrocks: from now on, sponsoring from your brnach will be very easy
[15:15] <didrocks> pitti: is there an option for dch to put UNRELEASED when dch -v... or dch -a... ?
[15:15] <pitti> didrocks: usually you just need it with -i
[15:15] <pitti> I use dch -iDUNRELEASED
[15:15] <pitti> didrocks: yes, -D
[15:16] <didrocks> pitti: thanks. I push it now :)
[15:17] <didrocks> pitti: so, I will change https://wiki.ubuntu.com/DesktopTeam/Bzr. The "one feature = one commit" is great for cherrypicking
[15:17] <pitti> didrocks: oh, didn't know about that page; thanks
[15:17] <pitti> didrocks: yes, it is indeed
[15:18] <pitti> didrocks: I'll look at that page, too, since I haven't used bzr-builddeb so far
[15:19] <didrocks> pitti: if there is any other mistake I put in this page, you can ping me :)
[15:39] <calc> seb128: i saw a comment from a gvfs developer that claims that touching files on smb should work now as of gvfs 1.1.1 but still doesn't seem to work on Ubuntu
[15:39] <seb128> calc: where did you read that comment?
[15:39] <calc> seb128: https://bugzilla.redhat.com/show_bug.cgi?id=479199#c28
[15:40] <calc> seb128: it came up during the discussion of the truncate bug in gvfs
[15:40] <seb128> ok, dunno about that
[15:40] <seb128> did you try over fuse or over smb?
[15:42] <calc> yea it still gives operation not supported as of our current 1.1.6
[15:42] <pitti> seb128: ok if I sponsor bug 327933 ?
[15:42] <seb128> pitti: yes ;-)
[15:43] <seb128> pitti: thanks for all the sponsoring ;-)
[15:43]  * seb128 hugs pitti
[15:43] <pitti> I'm just in the mood
[15:43] <pitti> seb128: I was actually trying to sponsor all the netbook screen size fixes, but I did one, left evo for you, and the rest already seems to have been done..
[15:44] <seb128> pitti: right, I did some previous week
[15:44] <pitti> seb128: just for the record, eel2 is in bzr now (from didrocks' branch)
[15:44] <pitti> seb128: are you okay with having more packages in bzr officially?
[15:44] <seb128> pitti: right
[15:44] <pitti> seb128: gnome-python is same situation (about to push didrocks' branch to ~ubuntu-desktop)
[15:45] <pitti> or shall we not have an official branch, and just leave didrocks to use his for his own purposes?
[15:45] <seb128> pitti: as said didrocks is adding each package he's working on to bzr following mvo recommendation so I try using it too now
[15:45] <seb128> pitti: add those to the ubuntu-desktop team
[15:45] <seb128> that's handy for review and sponsoring ;-)
[15:45] <pitti> seb128: ok, so we agree :)
[15:45]  * pitti hugs seb128
[15:45] <seb128> the thing I don't like is having to update patches, etc
[15:46] <seb128> and it makes harder to diff the configure.ac between version
[15:46] <seb128> but those are minor details, I need to update my workflow
[15:46] <pitti> what does that have to do with bzr?
[15:46]  * seb128 hugs pitti
[15:46] <pitti> seb128: configure.ac diff -> isn't that just debdiff old.dsc new.dsc | filterdiff -i configure.ac ?
[15:47] <seb128> pitti: well, you have the debian directory in bzr only so you can't run diff or cdbs-edit-patch directly, you have to unpack the new version somewhere
[15:47] <pitti> yes, I usually unpack it in the source directory, just as a non-bzr'ed source
[15:47] <seb128> pitti: right, I'm used to diff before starting the update to know what build-depends I need to update
[15:47] <mvo> bzr bd-do 'cdbs-edit-patch' is quite nice
[15:47] <mvo> (bzr bd-do 'cdbs-edit-patch 01_my_new_patch')
[15:47]  * pitti really ought to learn bzr bd soon
[15:47] <seb128> mvo: indeed
[15:48] <pitti> didrocks: seems you didn't import 2.22.3-0ubuntu3 into your branch
[15:48] <seb128> I also like bzr-buildpackage downloading the orig etc directly ;-)
[15:48] <pitti> didrocks: can you please do so and tell me when you are done?
[15:48] <pitti> seb128: it can do that? nice
[15:48]  * pitti defers gnome-python sponsoring until didrocks updated his branch
[15:49] <seb128> pitti: it does that by default, sponsoring is: bzr get url; cd ubuntu; bzr-buildpackage
[15:49] <seb128> it does download and start the build, nothing to do ;-)
[15:51] <phomes> Any reason mobile-broadband-provider-info is not being updated? Current version (20081015) lacks one of the major danish providers and support questions for this are frequently popping up
[15:52] <didrocks> pitti, seb128 : about the diff of configure.{ac,in}, I give some clue with bzr in the bzr desktop team branch
[15:53] <didrocks> (sorry, I am backlogging)
[15:53] <seb128> phomes: wrong channel to ask about mobile
[15:53] <phomes> seb128: sorry. Thought this would be desktop :(
[15:53] <pitti> seb128: wow, that's cool; it automatically gets/renames the orig.tar.gz from upstream, etc.
[15:53] <seb128> pitti: indeed!
[15:54] <mvo> bzr-buildpackage == love
[15:54]  * mvo hugs james_w
[15:54] <james_w> when it doesn't hate you :-)
[15:54] <pitti> bah, and I still spent time finding and downloading/renaming new tarballs
[15:54]  * pitti hugs james_w
[15:54] <mvo> group hug!
[15:55]  * didrocks hugs james_w too for bzr-buildpackage :)
[15:55] <pitti> james_w, didrocks: I don't quite understand the "building a source package" section on https://wiki.ubuntu.com/DesktopTeam/Bzr
[15:55] <pitti> why would bd-do give me a subshell which I have to exit with 1?
[15:56] <james_w> "bzr bd -S"
[15:56] <didrocks> pitti: it's not uptodate, I need to change it with bzr bd -S
[15:56]  * james_w edits the page
[15:56] <pitti> ah
[15:56] <james_w> in Jaunty you can now do
[15:56] <james_w> bzr bd -- --any --debuild --option
[15:56] <james_w> the "--" denotes where bzr should stop parsing options, anything after that is passed directly to debuild
[15:57] <pitti> james_w: with bd -S or bd -- -S I get a ton of "ignoring deletion..." warnings and an error
[15:57] <james_w> odd
[15:57] <calc> seb128: bug 336761 :)
[15:57] <pitti> james_w: I didn't unpack the orig.tar.gz, I just have debian/
[15:57] <pitti> james_w: do I need to?
[15:58] <james_w> pitti: try "bzr bd --merge -S"
[15:58] <seb128> calc: you know you could open your bugs directly to the upstream bug tracker for efficiency
[15:58] <didrocks> pitti: oh, didn't see this version :/ someone didn't gave a look at this bug (or me, probably :/). Doing that now
[15:58] <mvo> I think the page should contain info how to add .bzr-builddeb/default.conf and what it should look like too
[15:59] <didrocks> pitti: do you want me to uncommit until the change and then import the new changes to, or just integrate the change with a new commit?
[15:59] <pitti> didrocks: just new commit, that's fine
[15:59] <pitti> didrocks: grab the diff from launchpad (you know that feature?)
[15:59] <pitti> and apply it (you'll need to fix the changelog conflict, though)
[16:00] <pitti> james_w: same problem
[16:00] <pitti> james_w: it says
[16:00] <james_w> pitti: odd, which branch are you building?
[16:00] <pitti> Purging the build dir: ../build-area/gnome-python-2.25.90
[16:00] <pitti> Exporting to ../build-area/gnome-python-2.25.90 in merge mode
[16:00] <didrocks> pitti: hum, I usually only go to https://edge.launchpad.net/ubuntu/+source/gnome-python and dowload the diff.gz, is there some black magic? :)
[16:00] <pitti> but it doesn't actually seem to build the source from there, perhaps?
[16:00] <kenvandine_wk> seb128: i proposed patches for  328596 and 331571
[16:01] <seb128> bug #328596
[16:01] <kenvandine_wk> seb128: both evo, please review when you can
[16:01] <seb128> bug #331571
[16:01] <pitti> didrocks: yes, http://launchpadlibrarian.net/23159955/gnome-python_2.22.3-0ubuntu2_2.22.3-0ubuntu3.diff.gz
[16:01] <didrocks> pitti: the changes is already integrated
[16:01] <pitti> didrocks: that's what I mean
[16:01]  * kenvandine_wk dials into meeting
[16:01] <pitti> didrocks: then your bzr is missing the changelog
[16:01] <pitti> seb128: I'll comment on kenvandine_wk's patches, too
[16:01] <didrocks> pitti: that's because I have done myself :)
[16:01] <didrocks> pitti: but the change is the same
[16:01] <didrocks> pitti: I just copy the changelog and remove this on my changelog
[16:02] <pitti> didrocks: ok; please make sure that your branch reflects the exact reality of the archive, though (I'll check with debdiff! :-) )
[16:02] <pitti> james_w: lp:~didrocks/gnome-python/ubuntu/
[16:02] <james_w> pitti: ah, are you on an up-to-date jaunty? i.e. python --version == 2.6?
[16:03] <pitti> james_w: I think I see the problem:
[16:03] <pitti> $ ls ../build-area/gnome-python-2.25.90/
[16:03] <calc> seb128: there is one open more or less, but they claim to already have fixed the bug so i thought it might be something you broke? :)
[16:03] <pitti> debian  gnome-python-2.25.90
[16:03] <pitti> james_w: when I do this manually, I use tar xzf ../foo_orig.tar.gz --strip-components=1
[16:03] <pitti> james_w: yes, jaunty du jour, with python 2.6
[16:03] <calc> seb128: tomas in the redhat bug tracker is apparently the guy who worked on the smb support from what the gnome bug would indicate
[16:04] <james_w> pitti: bug 336686
[16:04] <didrocks> pitti: it's about the change on "Modify debian/*.install to support both python 2.5 (site-packages dir) and 2.6 (dist-packages dir) python packages". I have done this, but apparently, doko has done the same thing concurrently, I change removed it from the changelog and put the new one between
[16:04] <calc> seb128: i added the meta bug to the ubuntu bug but not as the official upstream bug link since it seems to not really be specifically about that issue
[16:04] <pitti> james_w: ah, I see
[16:04] <seb128> calc: thomas works for redhat and on gvfs yes, still GNOME bugs should go to bugzilla.gnome.org
[16:05] <calc> ok
[16:05] <seb128> kenvandine_wk: commented on #328596
[16:05] <calc> seb128: do you know if tomas is on irc somewhere (eg gnome irc, etc)?
[16:05] <seb128> calc: irc.gnome.org #nautilus, upstream are there, alex is the main upstream hacker, thomas is tbzatek
[16:06] <seb128> hpj is the guy working on the fuse code usually
[16:06] <calc> ok, i'll go there and see if they have any tests they want me to run, he mentioned he had heard there was an issue before but didn't have enough details to track it down
[16:06] <james_w> pitti: sorry about that, should be fixed very soon
[16:06] <pitti> james_w: no problem; if it's known, all is well :)
[16:06]  * pitti hugs james_w
[16:07] <mnemo> I just ran into this really weird bug that locks up my whole machine (and it repros using the live CD as well)... can anyone confirm this bug? --> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/336771
[16:08] <seb128> kenvandine_wk: commented on the other bug too, the "return enable" on the first function line is weird
[16:09] <didrocks> pitti: you can now bzr pull --overwrite (to avoid tag conflicts)
[16:10] <didrocks> pitti: I told doko to be careful next time with sponsorship before uploading a new version (I opened the bug a long long time ago, then, had to make some modification later as it was not sponsored and had python 2.6 transition in the meantime)
[16:10] <pitti> didrocks: thanks
[16:10] <pitti> didrocks: I guess with such large transitions things like that will always happen; I think we just need to get along with those
[16:11] <pitti> didrocks: with LP's automatically produced diffs, it's reasonably easy to fix
[16:11] <didrocks> pitti: yes, the bad thing is that we both fixed exactly the same thing :)
[16:14] <didrocks> pitti: you may have a debian/control.in difference has doko used one more time than I a debian/rules clean (and gnome.mk removes "uploaders < ... days")
[16:15] <pitti> didrocks: that's fine
[16:15] <didrocks> I am just worrying about the workflow of people don't using bzr to populate the bzr corresponding branch, that can be extra work...
[16:22] <didrocks> pitti: when there is only "one change" (like in last eel version), do you still prefer to have 2 commits? one with UNRELEASED and the new one for releasing it to jaunty with debcommit?
[16:22] <pitti> davidbarth: hm, seems that the packaging branch and notify-osd_0.9.orig.tar.gz have a different version of icons/avatar.png ? that breaks source package building (binary diff)
[16:22] <pitti> didrocks: yes
[16:22] <pitti> didrocks: because you (1) always start with UNRELEASED when committing something new
[16:22] <pitti> and you might decide to do another fix after that one
[16:23] <pitti> and (2) you always want the uploads to stand out from bzr log and get tagged, etc.
[16:23] <pitti> davidbarth: ah, it's not in the orig.tar.gz at all
[16:23] <didrocks> pitti: and when there is no change, just use new upstream tarball, bump version for a rebuild due to new library dependency change? :)
[16:24] <pitti> didrocks: you always need a changelog
[16:25] <didrocks> pitti: yes, but you only change this file. So, one commit with UNRELEASED and another one, with no change but UNRELEASED -> jaunty
[16:25] <pitti> davidbarth: can I safely remove it from the upload, or do I need to repack the orig.tar.gz to include it?
[16:26] <seb128> brb trying updates
[16:26] <davidbarth> pitti: on a call, brb
[16:31] <seb128> Ng: your gnome-keyring issue might be fixed with the new 2.25.92 version just uploaded if you want to give it a try later
[16:31] <Ng> seb128: yeah I was just reading a comment somewhere about that fixing some crashers :)
[16:33] <davidbarth> pitti: you can, i removed it following your advice
[16:34] <davidbarth> pitti: sorry if there are some consistency issues between the two
[16:34] <pitti> davidbarth: ok, thanks; then it apparently needs to be removed from bzr as well
[16:39] <kenvandine_wk> seb128: i updated that patch, i missed a line when i was deleting that stuff
[16:39] <kenvandine_wk> s/that/some/
[16:43] <ember> hey
[16:44] <ember> thanks for the sponsor pitti
[16:45] <pitti> ember: you're welcome
[16:45] <ember> seb128 should brasero conflict with n-c-b? jaunty have this bug #336164
[16:46] <seb128> ember: would make sense
[16:46] <seb128> kenvandine_wk: ok
[16:46] <ember> ok i will add that on the next upload
[16:46] <ember> thanks
[16:49] <pitti> kenvandine_wk: replied to bug 331571, thanks!
[16:51] <pitti> tedg: is it planned to hide the pidgin tray icon if indicator-applet is running?
[16:51] <pitti> tedg: since the applet already has "Pidgin" in the menu, and toggles the pidgin window
[16:51] <kenvandine_wk> pitti: i am on the fence on that... because you can do many other things from that icon
[16:51] <kenvandine_wk> it isn't just for status
[16:51] <tedg> pitti: I don't know that we can make them dependent.
[16:51] <tedg> pitti: But I've hidden mine and am happy with it.
[16:51] <pitti> well, asked the other way round then
[16:52] <pitti> why does it need to show up in indicator-applet then, when it has its own?
[16:52] <kenvandine_wk> tedg: i patched evo to hide for only non-stracciatella sessions
[16:52] <seb128> I still don't get the point of this indicator
[16:52] <seb128> it's sitting there and not listing any of the messages I get
[16:52] <tedg> There's also the issue of it being hidden means that on KDE folks can't see it at all (as there's no indicator-applet yet)
[16:52] <pitti> at the moment it doesn't really do anything useful indeed
[16:52]  * kenvandine_wk finds it useful
[16:53] <tedg> It has most of the messages I get in it.
[16:53] <kenvandine_wk> tedg: question though... should the applet show me  messages in evo, or just something to take me to evo?
[16:53] <kenvandine_wk> tedg: i would assume it would work more like pidgin
[16:53] <pitti> tedg: right, for me too (ICQ), but since the ICQ window always pops up automatically anyway, it's easier to focus that than to go through the applet
[16:53] <tedg> kenvandine_wk: It needs to show a count for Evo, which it isn't reliable at yet.  I need to do another release.
[16:53] <kenvandine_wk> instead it is like a shortcut
[16:53] <kenvandine_wk> tedg: reliable... i have never seen it :)
[16:53] <kenvandine_wk> a count would be good
[16:53] <tedg> kenvandine_wk: It won't show each message, that's likely to be too many for most people.
[16:54] <kenvandine_wk> yeah... would kill me... but i thought some sort of status
[16:54] <kenvandine_wk> so  count is great
[16:54] <tedg> I haven't pushed the ICQ patch for Pidgin-libnotify because it still shows notifications when the conversation is focused.
[16:55] <tedg> Which is annoying.  But it does show pings, etc.
[17:01] <mvo> mpt: most of the stuff we discussed in the call are in bzr now, did you have any opinion on a new first-run text in u-m ? it was mentioned in the call IIRC that we might want to think about explaining why it was auto-opening
[17:03] <mpt> mvo, I just managed to install Jaunty and saw it. :-) nicely done
[17:04] <asac> seb128: do you know where the gnome font config is applied codewise? is that in pango or higher (gtk, gnome)?
[17:05] <mpt> mvo, I don't think the text can really do any more without getting too wordy. The only things I think could be improved are the missing full stops, version number, and apostrophe
[17:06] <seb128> asac: gnome-settings-daemon read the gconf config and set an xsettings for that
[17:07] <seb128> asac: not sure where the xsettings get applied between gtk, pango, cairo, fontconfig, etc
[17:07] <asac> seb128: thanks ... will see if i can find something from there
[17:09] <mvo> mpt: ok, fair enough. about the missing full stops etc, what exactly do you mean? I can see full stops in my text here
[17:12] <mpt> mvo, I mean full stops at the end of "Welcome to Ubuntu." and "Software updates are available for this computer.", "don’t" instead of "don't", and 'choose “Update Manager”' instead of 'choose "Update Manager"'
[17:12] <mpt> the fiddly stuff :-)
[17:13] <mvo> heh :)
[17:13] <mvo> I see
[17:13] <mpt> mvo, also "since Ubuntu Jaunty alpha 5 was released" instead of "since Ubuntu was released"
[17:13] <mpt> I don't know how easy that is to do
[17:13] <mvo> mpt: that may have to wait for the next release, especially if you want milestone information :/
[17:13]  * kenvandine_wk -> lunch
[17:15] <mvo> mpt: I will attack the full stops and correct char stuff tomorrow morning and then I see what I can do regarding the "since version" info
[17:15] <mpt> mvo, thank you very much
[17:15] <mvo> cheers
[17:21] <mpt> mvo, to clarify, that should be "since Ubuntu 9.04 was released" at the final release
[17:21] <mpt> mvo, it seems to me that string should be somewhere system-ish so that it can be used by things like an About window in future too
[17:28] <asac> mvo: gehtse zum call?
[17:28] <asac> oops /msg forgotten ;)
[18:01] <didrocks> seb128: hum, quilt is too smart for me. It can apply a patch in yelp even if the context has changed: http://paste.ubuntu.com/125388/
[18:01] <didrocks> it shouldn't seeing "gnome-doc-utils" version changes
[18:03] <seb128> didrocks: dunno
[18:04] <didrocks> seb128: ok, you will tell me "why bother? it's work and that's what you want"
[18:04] <pitti> seb128: shall I apply/upload bug 336679, or do you want to grab it while updating for new gnome?
[18:04] <didrocks> I will back home and cry, so :)
[18:04] <seb128> pitti: I just uploaded a new version some minutes ago
[18:04] <seb128> pitti: feel free to upload, I just tend to wait for next tarballs for such details
[18:05] <pitti> seb128: ok, then I'll assign it to me and do it after UIF
[18:05] <pitti> (more pressing things to do until then)
[18:05] <seb128> enough to do to not play backport patch drop changes every few days
[18:05] <pitti> ah, no, I'll just sub u-main-sponsors
[18:05] <seb128> I would advice just waiting for the next tarball
[18:05] <pitti> then it doesn't get lost
[18:05] <pitti> seb128: okay, understood
[18:05] <seb128> well feel free to sponsor but I don't think the bug is worth spending sponsoring efforts
[18:06] <seb128> that will be fixed in GNOME 2.26
[18:08] <seb128> didrocks: I will be away for sport and dinner soon but if you want to do some extra updates feel free to do vino and vinagre
[18:09] <didrocks> seb128: ok, I take them, have a good sport time/dinner :)
[18:09] <seb128> thanks
[21:14] <seb128> good evening there
[21:14] <seb128> asomething: hey, want to do the evolution* updates?
[21:15] <didrocks> re seb128
[21:15] <seb128> didrocks: I will look at your vino sponsoring request
[21:15] <didrocks> seb128: ok, do I keep the 07_rosetta_translations_update.patch in yelp?
[21:15] <seb128> didrocks: if you are done with your updates and want some others let me know
[21:16] <seb128> didrocks: you can drop it it doesn't apply, we will update it before beta as usual
[21:16] <didrocks> seb128: hum, I applied new translations
[21:16] <asomething> seb128: sure thing, but I will not be able to get to it today
[21:16] <seb128> didrocks: that works too, you asked a new export?
[21:16] <didrocks> seb128: why this package don't use LP integrated translation?
[21:16] <seb128> didrocks: because translated xml are built during the build and not at runtime
[21:17] <seb128> didrocks: it doesn't fetch the translations at runtime but load localized xml version which are generated during the build
[21:17] <seb128> not sure if I'm clear ...
[21:18] <didrocks> seb128: no no, understood :) you are clear
[21:18] <seb128> good ;-)
[21:18] <seb128> you are welcome to work on changes to use gettext if you want
[21:18] <didrocks> seb128: FYI, yelp need gnome-doc-utils 0.15.2, Can I update it?
[21:18] <didrocks> seb128: why not, (not tonight but tomorrow, I will have a look at it)
[21:19] <seb128> didrocks: sure
[21:19] <seb128> didrocks: work on updates first, you can keep the "use gettext at runtime" for later, that might be non-trivial
[21:20] <didrocks> seb128: ok, I just note it somewhere to keep that in minde
[21:20] <didrocks> vinagre is on the way
[21:20] <seb128> ok good
[21:21] <seb128> asomething: ok, I might do it since I've some other evolution changes to try and sponsor, look to the current version before starting ;-)
[21:22] <asomething> seb128: i'll check in tomorrow and see if it's still needed
[21:22] <seb128> ok
[21:56] <Ampelbein> seb128: hi, could you have a look at bug #336938 ?
[21:56] <seb128> Ampelbein: hey, sorry I just uploaded the new version ...
[21:56] <Ampelbein> oh.
[21:56] <seb128> Ampelbein: better to ask on the channel before doing updates
[21:56] <Ampelbein> ok.
[21:56] <seb128> or to open a bug before saying you work on it
[21:57] <Ampelbein> yeah, i looked at open bugs and did not find it, so i opened it and started. but no problem.
[21:58] <seb128> Ampelbein: you were not around for a while, I will ping you for the next seahorse* updates if you are interested to work on those again
[21:58] <Ampelbein> yeah, i had some personal issues to deal with but now i'm back again ready to help.
[21:58] <seb128> Ampelbein: speaking about bugs there is 3 seahorse bugs which have an upstream task closed if you want to look at those ;-)
[22:00] <Ampelbein> looking. (i assume you don't mean those already set to fix commited?
[22:01] <seb128> no, in the advanced search you can filter on bugs which are closed upstream it's in the bottom of page options
[22:01] <seb128> there is 3 bugs which have been closed as NOTABUG or NOTGNOME there
[22:13] <Ampelbein> seb128: ok, looked through the bugs. bug #289516 is fixed with .92, #235663 would be "won't fix" or "invalid" (which i tend to set it), same with #238954. as for #302451 i would tend to discuss with upstream the idea you had of changing the displayed text.
[22:13] <seb128> Ampelbein: ok good
[22:13] <seb128> thanks for triaging those ;-)
[22:13] <seb128> Ampelbein: do you want an another update to work on?
[22:14] <Ampelbein> would be nice, yes.
[22:14] <seb128> Ampelbein: http://download.gnome.org/sources/gnome-system-monitor/2.26/gnome-system-monitor-2.26.0.tar.gz
[22:15] <Ampelbein> ok
[22:30] <Ampelbein> seb128: bug #336946 ready for review. (please excuse errors i made, haven't done updates awhile now ;-)
[22:30] <seb128> Ampelbein: looking
[22:36] <seb128> Ampelbein: the update is good I'm sponsoring it now
[22:37] <Ampelbein> ty
[22:39] <calc> yipee new gvfs :)
[22:39]  * calc hugs seb128 
[22:39] <calc> that makes my life much easier for testing the new truncate fix :)
[22:45] <didrocks> seb128: I reverted the changes to LP translation and removed the patch (it FTBFS, even if the new one is present during the build itself, not patch apply… this is strange for translations. It seems to be related to stylesheets ^^)
[22:46] <seb128> didrocks: how did you update the patch exactly?
[22:46] <didrocks> seb128: I followed huats advice: go to https://translations.edge.launchpad.net/ubuntu/jaunty/+source/yelp/+pots/yelp/+export, download translations
[22:46] <didrocks> select everything in po format
[22:47] <didrocks> then, quilt push ... rm po/ ...   cp translation to po/
[22:47] <didrocks> and quilt refresh :)
[22:47] <didrocks> saying that, I am wondering if some files are removed in po/ which are not in the template
[22:47] <seb128> the rm po is not a good idea there
[22:48] <didrocks> yeah
[22:48] <seb128> why did you do that?
[22:48] <didrocks> writting it is better to realize :)
[22:48] <seb128> and does translation uses the same naming?
[22:48] <didrocks> because huats told me everything was in the "download translations" package :)
[22:48] <seb128> when I did that previously I did rename all the files I think
[22:48] <seb128> and just copied *.po po
[22:48] <seb128> which overwritte the upstream version
[22:48] <didrocks> ok, I will try this just now
[22:49] <seb128> without removing anything else there
[22:49] <Ampelbein> seb128: is there another update to do?
[22:49] <didrocks> seb128: there are some kind of "translation makefile", right?
[22:50] <seb128> didrocks: there is a makefile it's not really translation specific
[22:50] <seb128> Ampelbein: not right now
[22:51] <seb128> didrocks: did you do the glibmm update yet?
[22:51] <Ampelbein> k
[22:51] <didrocks> seb128: yes bug #336940
[22:51] <seb128> didrocks: you did, I just looked to launchpad ;-)
[22:51] <didrocks> seb128: and gnome-doc-utils too ;)
[22:51] <didrocks> bug #336947
[22:52] <didrocks> seb128: do you think I am a slacker? :p
[22:52] <seb128> didrocks: yeah, I was wrong ;-)
[22:53] <seb128> didrocks: I was trying to find a reminder update for Ampelbein
[22:59] <calc> seb128: i think the new gvfs-fuse sftp/truncate fixes may have helped fix issue with OOo :)
[23:01] <calc> seb128: of course there also appears to be issue with OOo so I may end up disabling gvfs support in OOo native and relying on fuse support
[23:02] <calc> seb128: i saved from OOo to ~/.gvfs/long/path/to/sftp/location/ and it worked though which is really good news :)
[23:02] <seb128> indeed
[23:02] <didrocks> seb128: :p
[23:02] <seb128> didrocks: dpkg-source: erreur: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
[23:03] <didrocks> seb128: oh, ok, sorry to have done them :)
[23:03] <didrocks> now, let's see if yelp is more friendly
[23:03] <calc> hmm no luck its still broken, apparently i was just lucky somehow
[23:09] <didrocks> seb128: I must admit I am used to have ubuntu only package :/ fixed, can you bzr pull --overwrite please?
[23:09] <seb128> didrocks: what do you mean?
[23:10] <didrocks> seb128: I didn't checked the maintainer field as I am used to encounter with the desktop team many "already modified in ubuntu" packages
[23:10] <seb128> ah ok
[23:10] <didrocks> seb128: I put core-dev for this one, do I have to put desktop team?
[23:10] <seb128> no that's ok
[23:11] <didrocks> ok, so, juste bzr pull --overwrite
[23:11] <didrocks> just*
[23:11] <seb128> didrocks: you forgot to update the SHVER in the rules
[23:11] <seb128> the abi changed
[23:11] <seb128> they wrapped new gio functions in this version so the shlibs needs to be updated
[23:11] <didrocks> seb128: the abi changed, but there are only added symbols…
[23:11] <seb128> right, which is what the shlibs is about
[23:12] <seb128> the shlibs is the version of the current abi
[23:12] <didrocks> seb128: I don't get when there is an SHVER or when there is no SHVER. Some lib packages have and others don't have it?
[23:12] <seb128> the soname change when you break compatibility
[23:12] <seb128> didrocks: libraries have a shlibs
[23:12] <seb128> SHVER is an implementation details
[23:12] <seb128> you can also have a .shlibs
[23:13] <seb128> or modify the dh_makeshlibs argument in rules
[23:13] <seb128> the shlibs is the current version of the abi
[23:13] <seb128> ie every time a function is added the shlibs is added
[23:13] <didrocks> ok, I write that down somewhere. Each time, there is something to change either, the SHVER, .shlibs, and dh_makeshlibs argument, seing what is presented in the package
[23:13] <seb128> if no function has been added since the first version packaged you might have no shlibs since there is no version restriction
[23:14] <seb128> and some packages use .symbols now which have a better granularity
[23:14] <seb128> in which case you need to update the .symbols and have no shlibs
[23:15] <didrocks> seb128: ok. I will try to not forget next time. I must admit packaging library is still quite obscure to me, but I will get used to it :)
[23:18] <didrocks> seb128: the SHVER/other ways can be found where when objdump or nm to library?
[23:21] <didrocks> seb128: new version pushed
[23:21] <seb128> didrocks: there is a wiki page about libraries updates which explain that
[23:22] <didrocks> seb128: https://wiki.ubuntu.com/MOTU/School/LibraryPackaging? I didn't find SHVER in it
[23:23] <didrocks> seb128: but yes, I will try to find it where the corresponding value is put in the lib. I think it should be writtent somewhere in the session :)
[23:23] <seb128> didrocks: no https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols
[23:24] <didrocks> seb128: ok, I see at the end of the page
[23:27] <didrocks> seb128: yelp done too, cf bug #336981
[23:27] <seb128> ok
[23:28] <didrocks> I think/hope everything's you gave me is ok now :)
[23:29] <seb128> should be
[23:37] <didrocks> time to go to bed, good night seb128 :-)
[23:38] <seb128> didrocks: 'night
[23:40] <calc> actually it seems that something weird keeps OOo from saving properly the first time and only the lock file is created but the second time it is attempted to save it works