[08:49] <asac> hi
[08:49] <didrocks> hi o/
[08:50] <seb128> hello asac didrocks
[08:50] <asac> moin seb128 and didrocks
[08:50] <didrocks> hello seb128 & asac ;)
[08:51]  * asac receives a ridiculous amount of mail over weekend
[08:51] <seb128> asac: welcome to the club
[08:52] <asac> seb128: hehe ... wel, usually i read mail on weekend, so i dont notice how bad it is
[08:52] <seb128> I've been reading my emails 3 times a day to not crack under backlog today
[08:52] <seb128> it's usually not that amonth
[08:52] <seb128> I usually get 300 emails or so
[08:53] <asac> hmm. i just wanted to hvae 2 days off ;)
[08:53] <seb128> I got 878 this weekend
[08:53] <seb128> asac: you are right you deserve to relax during weekends ;-)
[08:53] <asac> with bugmail?
[08:54] <seb128> the 878?
[08:54] <seb128> it's desktop components I'm interested in, it not everything in ubuntu-desktop but just things I work on
[08:55] <asac> ;)
[08:55]  * pitti hugs asac, seb128, and didrocks
[08:55] <seb128> basically most of GNOME, but not the things other people are supposed to work, ie gnome-screensaver, etc
[08:55]  * seb128 hugs pitti
[08:55]  * asac hugs pitti back
[08:55] <pitti> yeah, I relaxed during the weekend, but this morning's email surge is horrible
[08:56]  * didrocks hugs pitti back
[08:57] <seb128> going to love users
[08:58] <seb128> didrocks: did you have a jaunty party? ;-)
[08:58] <didrocks> seb128: just a jaunty release party :-) Will publish some photo as soon as I got them
[08:58] <didrocks> the Ubuntu Party (larger public) will be the 16-17 may
[08:59] <seb128> ok
[08:59] <seb128> was the jaunty one good?
[09:00] <didrocks> yes, 30 people in a "flams", very enjoyable :)
[09:00] <didrocks> seb128: and you, no party ? ;)
[09:00] <seb128> no, sleep and relaxing ;-)
[09:00] <didrocks> that's good too ^^
[09:01] <seb128> didrocks: good comments on the jaunty milestone? ;-)
[09:01] <didrocks> if you are around Paris during the ubuntu party, do not hesitate to come
[09:01] <didrocks> seb128: I think that people were more trying to download it than already having it :)
[09:01] <seb128> ok
[09:01] <didrocks> from what I know, in forums, everything's  better than for previous release
[09:01] <didrocks> that's a good point \o/
[09:02] <seb128> 16-17 mays, I will be in Spain
[09:02] <seb128> hum no, that's just before in fact
[09:02] <didrocks> ok, thought that canonical guys were leaving just one week before
[09:02] <didrocks> yes
[09:02] <seb128> but too near to travel to Paris and back just before flying
[09:02] <didrocks> sure ^^
[09:02] <didrocks> next time :)
[09:03] <didrocks> seb128: I don't know what do you thing, but this one can be a good SRU candidate (bug #361053)
[09:03] <didrocks> think*
[09:04] <seb128> mvo: ^ could you have a look? ;-)
[09:04] <seb128> I already sponsored some SRU and did a bunch of those, I want to try catching up on bug emails today now
[09:04] <seb128> didrocks: I will have a look later if nobody else does
[09:05] <didrocks> seb128: ok, will ping you if it's the case
[09:06] <mvo> sure
[09:24] <robert_ancell> seb128: hey!
[09:24] <seb128> hello robert_ancell
[09:24] <seb128> robert_ancell: how are you?
[09:24] <pitti> robert_ancell: good evening
[09:25] <robert_ancell> seb128: I feel like I got punched in the nose :)  Hey pitti
[09:25] <seb128> robert_ancell: found things to do today? we have some bug flood after jaunty so you can probably spend the week helping on bug triage ;-)
[09:25] <pitti> robert_ancell: but you are alive!!
[09:25] <seb128> robert_ancell: ah ah
[09:25] <seb128> robert_ancell: users are great aren't they? ;-)
[09:25] <pitti> robert_ancell: I had a nose operation three years ago, I still painfully remember it
[09:25] <robert_ancell> seb128: no it was a doctor that did it to me!  And I paid for it!
[09:26] <seb128> oh?
[09:26] <robert_ancell> pitti: I think I am past the worst now so should all be good from now on...
[09:26] <robert_ancell> seb128: got my nose straightened to help with breathing
[09:26]  * seb128 is happy that nobody is touching his nose
[09:26] <pitti> robert_ancell: hah, I had pretty much the same
[09:27] <seb128> robert_ancell: ah ok
[09:27] <robert_ancell> seb128: get your nose insured :)
[09:27] <seb128> lol
[09:29] <robert_ancell> I've been triaging all day... the flood doesn't seem too bad yet
[09:30] <seb128> robert_ancell: you are probably not subscribed to enough components! ;-)
[09:30] <seb128> I expect compiz has quite some bugs though and half of those are probably driver issues
[09:31] <robert_ancell> seb128: it was more it just seemed about the normal amount of bugs - i.e. too many!!
[09:31] <seb128> right
[09:31] <seb128> oh oh
[09:32] <seb128> pitti: all the retracer just crashed, should I look to it?
[09:32] <seb128> "    from launchpadlib.errors import HTTPError
[09:32] <seb128> ImportError: No module named launchpadlib.errors"
[09:32] <seb128> what the?
[09:33] <seb128> I hate the new way of packaging python in debian and ubuntu
[09:33] <seb128> it's just no un-reliable
[09:33] <pitti> aww
[09:33] <pitti> seb128: I'll have a look
[09:33] <pitti> seb128: I just did a pull in the launchpadlib branch, I guess that broke it somehow
[09:33] <seb128> pitti: thanks
[09:33] <pitti> seb128: currently working on the script to set up the retracers (since we need one on armel, etc., and I like to have it working anyway)
[09:34] <seb128> pitti: ok
[09:38] <chrisccoulson> hi pitti
[09:38] <pitti> hey chrisccoulson, good morning! had a nice weekend?
[09:39] <chrisccoulson> not too bad thanks - i slept a lot like most weekends :)
[09:39] <chrisccoulson>  i've finished the tracker update now - i dropped the evolution plugin, as I can't make it work anyway
[09:40] <chrisccoulson> someone else tested the evolution plugin, and they couldn't make it work either
[09:40] <seb128> robert_ancell: could you have a look to bug #343707 tomorrow?
[09:41] <chrisccoulson> heh. that bug is really annoying
[09:41] <pitti> chrisccoulson: thanks, I saw the merge request; will upload ASAP
[09:42] <chrisccoulson> pitti - thanks:)
[09:42] <chrisccoulson> i'll have to do some more investigation on the evo plugin, but i'll have to ask upstream for some help with that
[09:43] <robert_ancell> seb128: no prob,  it sounds similar to bug 181553 which I fixed today
[09:43] <seb128> robert_ancell: good that you fixed this one, I think they are different issues though
[09:44] <seb128> robert_ancell: the other one could be gstreamer typefinding detecting a wrong mimetype rather or something
[09:44] <seb128> robert_ancell: it's supposed to ignore non multimedia formats quietly
[09:44] <robert_ancell> seb128: reading more you're probably right.  The bug I fixed had a symptom where it was treating a playlist as a music file
[09:46] <pitti> seb128: ronne retracers should be fixed now
[09:46] <seb128> pitti: good job!
[09:54] <seb128> robert_ancell: interesting that you edit apport crash bug titles to remove the function name
[09:55] <seb128> I found that handy to find duplicates usually
[09:56] <seb128> robert_ancell: the desktop bug triagers usually use "fix commited" for bugs fixed upstream too
[09:57] <seb128> it's not ideal but it makes easier to know what to close in the next upload
[09:57] <seb128> by just looking at the bugs list
[09:57] <robert_ancell> seb128: yeah, it's a bit of trade off that one.  I was considering having them following the description.  I've found it easier to get a overview of the bugs if the reports have descriptions of the causes of the bugs
[09:58] <seb128> right, you have a point, and ideally apport should auto-dup similar stacktraces anyway
[09:59] <seb128> I'm pondering if we should keep the function in () after the title though
[09:59] <robert_ancell> seb128: and often it can be misleading to mark purely based on stack trace - sometimes i've seen bug reports in gnome-games/gcalctool linked based on similar traces but aren't the same cause
[09:59] <seb128> right
[09:59] <robert_ancell> seb128: I agree, I'll update them in future
[10:00] <seb128> thanks
[10:00] <robert_ancell> seb128: regarding the "fix committed" - I wanted to do that but hadn't because of https://wiki.ubuntu.com/Bugs/Status - but I will definitely do that now because it has been annoying me too
[10:01] <seb128> right, different people have different workflow
[10:01] <seb128> we use fix commited in a consistant way for desktop though
[10:02] <seb128> the rational being that GNOME rolls tarball often enough
[10:02] <seb128> so it's somewhat going to land soon in ubuntu when fixed upstream anyway ;-)
[10:02] <robert_ancell> seb128: thanks,  still getting the hang of the workflow here :)
[10:02] <seb128> and it makes easier to know what bugs to close or patches to backport
[10:02] <seb128> you're weclome!
[10:02] <seb128> welcome
[10:03] <robert_ancell> seb128: that leads onto another question I wanted to ask - there's a number of upstream released I want to push (glade, gcalctool etc) that fix small bugs.  Is it worth pushing these for Jaunty?
[10:03] <robert_ancell> (I still don't quite get the post CD press process)
[10:03] <seb128> is there any bug fix there worth having in stable?
[10:04] <robert_ancell> seb128: well something like glade is really handy as it fixes some annoying bugs and I'd expect programmers to want the latest stable version.  Or do we expect users to get this from a PPA?
[10:05] <seb128> it's always a balance work benefit
[10:05] <seb128> hey bratsche
[10:05] <seb128> robert_ancell: http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[10:05] <seb128> robert_ancell: those are the stable uploads already uploaded
[10:05] <seb128> robert_ancell: you know the sru procedure?
[10:05] <robert_ancell> seb128: no
[10:06] <robert_ancell> (other than it appears to be practically impossible to push something into stable when you're not in Ubuntu as when I tried back a year or so)
[10:06] <seb128> robert_ancell: https://wiki.ubuntu.com/StableReleaseUpdates
[10:07] <seb128> robert_ancell: read that
[10:08] <seb128> robert_ancell: basically the update need to be bug fixes change only and worth the work
[10:08] <seb128> robert_ancell: ie a translation updates version is not worth the stable update work
[10:08] <seb128> (especially than translators can upload translations on rosetta without source upload)
[10:09] <seb128> the gcalctool changelog has 1 line
[10:09] <robert_ancell> seb128: ok, I did read that the other year.  So reading it says in the case of the apps I am talking about a backport is more appropriate?
[10:09] <seb128> not sure if the bug is an annoyance for users or just a small thing, if you think that's annoying enough you can do a sru
[10:10] <seb128> since GNOME has freezes etc for stable series no
[10:10] <seb128> we usually do GNOME stable updates
[10:10] <seb128> when the changes are worth an update
[10:10] <seb128> I think for glade it makes sense
[10:10] <robert_ancell> glade is a better example - there are a few cases where you can generate ui files that can't be loaded.  It's a bit confusing so it would be really nice for the users.  The work seems small from my end.
[10:11] <seb128> right, for glade it makes sense
[10:11] <seb128> the gcalctool one I'm not sure
[10:11] <seb128> it's only one change ... is that a confusing thing for many users?
[10:11] <seb128> we are still early after jaunty and karmic is not open yet
[10:11] <seb128> so it's still a good time to do some stable bug fixing
[10:11] <seb128> so it's still a good time to do some stable bug fixing
[10:12] <robert_ancell> There's another bug that I'll fix soon and I'm thinking ahead, i.e. when gcalctool 5.26.3 is released there will probably be a number of useful fixes and by that time I'd consider it useful to update
[10:13] <seb128> ok, so maybe wait for this update
[10:13] <seb128> and do the glade one meanwhile
[10:13] <robert_ancell> OK, I will do that tomorrow
[10:13] <seb128> that will do a sru exercice too ;-)
[10:13] <seb128> ok
[10:13] <seb128> so this rhythmbox bug, glade to sru and bug triage
[10:13] <seb128> you already have a busy day scheduled ;-)
[10:14] <robert_ancell> seb128: will do.  it's good to have some variety for the day!
[10:14] <seb128> indeed
[10:14]  * seb128 still fighting the bugmail backlog
[10:14] <seb128> we will need an e-d-s sru
[10:15] <pitti> gosh, I haven't even started with that yet :(
[10:15] <seb128> once people will have managed to tell us where e-d-s is crashing
[10:15] <seb128> we are getting a lot of evolution calendar hangs
[10:20] <pitti> hey sabdfl
[10:21] <sabdfl> pitti!
[10:21] <sabdfl> how was your release weekend?
[10:22] <seb128> hello sabdfl
[10:22] <sabdfl> hey seb
[10:25] <robert_ancell> seb128, pitti:  clocking off now, see you guys tomorrow
[10:25] <seb128> robert_ancell: enjoy your evening, see you tomorrow
[10:26] <pitti> robert_ancell: sleep well, and all the best for your nose!
[10:26] <robert_ancell> :O)
[10:26] <pitti> sabdfl: pretty quiet, enjoyed the sun, some bicycling, and theater :)
[10:26] <sabdfl> what did you see?
[10:26] <pitti> "What the Butler Saw"
[10:26] <pitti> brilliant English comedy
[10:27] <pitti> and back then, in 1969, probably quite a scandalous one, too
[10:27] <pitti> http://en.wikipedia.org/wiki/What_the_Butler_Saw_(play)
[10:27] <pitti> sabdfl: how about you, rocked the office with the release party? :-)
[10:28] <sabdfl> it was great
[10:28] <sabdfl> and i could speak afterwards, because there was no karaoke :-)
[10:28] <sabdfl> and nobody had to bring cotton wool
[10:28] <sabdfl> all in all, a success
[10:29] <pitti> sounds great!
[10:30] <pitti> seb128: hah, the good thing about karmic not being open yet is that SRU verification results come in very fast \o/
[10:30] <seb128> pitti: ;-)
[10:30]  * pitti currently processes the 150-odd SRU bug mails
[10:30] <mvo> yeah, the sru-verification team is rocking
[10:30] <seb128> pitti: speaking about that do you know when karmic will open?
[10:30] <pitti> seb128: when the toolchain bits are in, currently in progress
[10:31] <mnemo> is it possible to run apport-collect from an ssh shell when xorg is borked?
[10:31] <seb128> mvo, pitti: could one of you look at the brasero update waiting for sponsoring too? there is quite some users having nautilus crashing due to it right now
[10:31] <pitti> not right now, but I'll have a look at the sponsoring queue later then
[10:31] <mvo> seb128: can do
[10:31] <pitti> mnemo: apport-collect doesn't need X
[10:32]  * pitti hugs mvo
[10:32] <seb128> mvo: thanks
[10:34] <mvo> np
[10:40] <mvo> pitti: if the update-manager -proposed version could go into -updates, that would rock (verification status looks pretty good AFAICS)
[10:40] <pitti> mvo: I'm very eager to get it in (currently trawling through the sru bug mail)
[10:41] <pitti> mvo: you got some good responses and perhaps also did an auto-tester run with this?
[10:42] <mvo> pitti: I got multiple auto-test rusns (attached to the individual reports)
[10:42] <pitti> great
[10:42] <mvo> thanks, I don't want to interrupt your trawling :)
[10:45] <pitti> mvo: no problem, please do :)
[10:45] <pitti> I'm in SRU mode/mood anyway
[11:13] <pitti> mvo: congratulations for for the first package in jaunty-updates
[11:13] <pitti> mvo: shall I also copy it to karmic, or do you have the chagnes/bug closings in your karmic tree as well?
[11:14] <mpt> asac, hi, I have a question about wired networks
[11:14] <mpt> asac, in what circumstances is it useful to know the name of a wired network?
[11:15] <mpt> For example, when I plug the PC next to me into Ethernet I get a bubble with title "Auto eth0", which is quite ugly
[11:15] <mpt> What would we lose by just saying "Wired network" instead?
[11:16] <Nafallo> mpt: so how do I know if I'm using my Canonical Data Centre statical configuration, my statical configuration for Home, or actually got an automatic DHCP?
[11:17] <mpt> Nafallo, I don't know. What's a "statical configuration"?
[11:17] <Nafallo> mpt: when you don't get an IP assigned by a central server by rather set it yourself in the preferences.
[11:17] <mpt> ah
[11:18] <mpt> Nafallo, and what are the titles shown in the notification bubbles for each of those at the moment?
[11:18] <Nafallo> mpt: I would have to disconnect to check...
[11:19] <Nafallo> mpt: Bold text, name of the connection. underneath, non bold, "Connection established"
[11:19] <mpt> Nafallo, I understand that, I'm just wondering what the actual names are
[11:20] <Nafallo> mpt: so what you see as Auto eth0 could be Home or Canonical DCs or whatever...
[11:20] <mpt> Nafallo, are they what's shown in "Edit Connections..." > "Wired" > "Edit" > "Connection name:"?
[11:20] <Nafallo> yeah.
[11:20] <Nafallo> same with any name for any type of connection.
[11:20] <mpt> so were your names set manually or automatically?
[11:20] <Nafallo> which is how it should be IMO
[11:21] <Nafallo> manually for the static configs
[11:21] <Nafallo> you can change whatever connection to have a different name though...
[11:21] <Nafallo> so the "fix" for this issue would be to get Network Manager to have sane defaults I would say :-)
[11:23] <mpt> Ah, so a better name than "Auto eth0"?
[11:26] <Nafallo> yeah
[11:26] <Nafallo> if that is your issue :-)
[11:26] <Nafallo> also, the defaults for wireless is Auto $SSID
[11:27] <Nafallo> I can't see why it isn't just $SSID personally
[11:27] <proppy> mpt: if you've got 2 eth, it can be usefull to know which one is plugged
[11:27] <mpt> good point
[11:28] <proppy> (while, I agree that many desktop don't have 2xeth these days)
[11:28] <mpt> So maybe the first should be called "Ethernet", the second "Ethernet 2", the third "Ethernet 3", and so on
[11:29] <Nafallo> and nuke "Auto " from everything? :-)
[11:29] <Nafallo> (for new connections of course, don't want to touch existing configs)
[11:30] <mpt> maybe
[11:30] <mpt> Let's see what asac thinks
[11:35] <asac> mpt: names for connections make sense when you hvae multiple connections defined
[11:35] <asac> mpt: in the case of auto connections i would think that just stating "Auto Wired Connection" might make more sense.
[11:36] <asac> mpt: dropping the eth0 works well when you have only one NIC
[11:36] <asac> which is on laptops, but most desktops have two NICs i think
[11:37] <asac> so we could look into making the name logic consider whether there is more than one NIC and whether there are other wired connections defined and dropping parts of the name accordingly.
[11:40] <seb128> asac: the issue is that "eth" is a technical thing not a word users understand
[11:40] <asac> seb128: yes, i see that. i have to think a bit about it
[11:42] <asac> we could try to enumerate wired devices somehow and refer to the auto connections as "Wired Connection 1,2,.."
[11:45] <Nafallo> asac: is "Auto " actually necessary you reckon? :-)
[11:45] <asac> personally i wonder whether network management shouldnt look at this at the connection perspective at all; rather the user should manage his networking based on locations ... which would allow us to give the auto connection a name that refers to location used.
[11:46] <asac> Nafallo: not sure.
[11:47] <Nafallo> asac: I've got LOTS of Auto $SSID by now...
[11:47] <asac> Nafallo: question is if users are more likely to go and look for "manual" ways to configure connections if they see the "Auto" prefix
[11:47] <seb128> what does "auto" mean?
[11:48] <Nafallo> seb128: either it is DHCP or it is "Automagically created faff"
[11:48] <asac> auto means: all magic ;) ... encryption mode, IPs, et all
[11:48] <Nafallo> I've never actually understood which
[11:48] <proppy> I don't get Auto for network I created by hand
[11:49] <Nafallo> proppy: that's because you set the name by hand? ;-)
[11:49] <asac> yeah. you have to choose the name for those explicitly
[11:49] <proppy> Nafallo: yep, I remember setting the name by hand because of an hidden SSID
[11:49] <seb128> couldn't you display ".... automatically configured"?
[11:50] <seb128> where ... is the name
[11:50] <Nafallo> so yeah. I don't think "Auto " makes sense just because I choose an AP to connect to in the list :-)
[11:50] <Nafallo> seb128: why would you need to tell them at all? if they need to set up a static connection they will figure it out anyway :-)
[11:52] <asac> Nafallo: for APs the auto might make less sense than for wired
[11:53] <Nafallo> asac: as in "no sense" :-)
[11:53] <Nafallo> but yeah.
[11:53] <asac> Nafallo: but that name doesnt show up in menu usually
[11:53] <Nafallo> asac: really?
[11:53] <asac> while the wired name shows up in its full length
[11:53] <asac> Nafallo: do you see any Auto in the menu for wireless?
[11:54] <asac> i would think you just see that in the editor
[11:54] <Nafallo> asac: ah. you meant like that.
[11:54] <Nafallo> asac: no, but then the only wired I see are set in the connection dialog :-P
[11:54] <Nafallo> asac: so changing the default name for wired wouldn't necessarily show "Auto eth0" either :-)
[11:55] <Nafallo> INCONSISTENCY!!!
[11:55] <Nafallo> :-P
[11:56] <asac> Nafallo: well. you only see the connections if there is a link on the wired device
[11:56] <asac> so plug your thing into something that has power ;)
[11:57] <Nafallo> that made no sense to me. what do you mean?
[11:57] <Nafallo> I'm on wire at the moment.
[11:59]  * mpt looks up what a "NIC" is
[11:59] <asac> mpt: device
[11:59] <asac> network
[12:00] <mpt> ah, network interface controller
[12:00] <mvo> pitti: wooohh! thanks - I have the changes in my karmic tree, once it oppens, I will uplaod that
[12:00] <pitti> mvo: ok, I won't bother then; please upload the next wave of u-m to -proposed then
[12:00] <asac> Nafallo: not sure what you mean then
[12:01] <mpt> asac, are there any prefixes used other than "eth"? If so, what are they?
[12:01]  * mpt finds http://www.netstumbler.org/f55/whats-difference-between-eth0-wlan0-wifi0-ath0-etc-18696/
[12:01] <asac> mpt: thats a theoretically infinite set of names
[12:01] <Nafallo> asac: if you look in the connection editor, you have lots of wireless Auto $SSID. those show up in the menu as $SSID
[12:02] <Nafallo> asac: when you connect to wired you get the same names as in the connection editor. ie. "Auto eth0"
[12:02] <Nafallo> asac: that's inconsistent. I can see why it happens, but it's still fail :-P
[12:02] <Nafallo> mpt: they can have whatever name actually :-)
[12:03] <asac> mpt: its just a label for a NIC ... in the past it was used to identify certain network devices
[12:03] <Nafallo> mpt: but that requires manual intervention, so I don't think we should care :-)
[12:03] <asac> for example in /etc/network/interfaces
[12:05] <asac> mpt: the right way as i said above would be to enumerate devices and talk about them just as "Wired Device X"
[12:05] <Nafallo> Wired Interface X :-)
[12:06] <mpt> This MacBook has "Auto eth2" and no other wireless connections
[12:06] <asac> yes. thats possible
[12:06] <asac> you cannot use that number to enumerate
[12:07] <mpt> er, no other wired connections I mean
[12:10] <asac> so how about this idea:
[12:11] <asac> instead of "Auto cryptic0" ... there should be a menu entry "Auto connect(ed)"
[12:11] <asac> would that make more sense?
[12:12] <asac> thats for wired ... for wireless APs would show up in the same way as they do now
[12:12]  * asac isnt completely happy with "Auto connect" either
[12:18] <asac> mpt: so what do you think about the idea from above: move user perspective of network management away from low level stuff like "devices" and "connections" to more a high level location based POV (home, work, travel ...)
[12:19] <asac> i get the feeling that you cannot really design a UI that looks at devices/connections in a way a non-technical user will understand easily
[12:34] <mpt> asac, location handling is a whole separate issue, and there's a bunch of interesting utilities that do things like change brightness level and default printer and so on as well as network
[12:34] <mpt> I'd rather just get the names fixed for now
[12:37] <asac> mpt: sure its a different issue. but having location handling tight to networking makes a lot of sense. you could auto detect most locations through networking. so worth discussing/speccing imo
[12:38] <asac> mpt: you have a list of utilities that change networking based on location?
[12:44] <mpt> asac, http://www.symonds.id.au/marcopolo/ is one that includes a comparison with others (all Mac OS X)
[12:45] <mpt> Windows equivalents include <http://www.netsetman.com/index.php?s=nsm> and <http://milnersolutions.com/netprofiles/>
[13:10] <bratsche_> Hi seb128
[13:13] <asac> mpt: thx
[16:34] <vuntz> heh
[16:34]  * vuntz looks at the ubuntu gconf patches and sees 05_from_vuntz_gconf2-pk-default-path.patch
[16:35] <vuntz> seb128: yo?
[16:44] <seb128> lut vuntz
[16:44] <seb128> vuntz: what about it?
[16:47] <vuntz> seb128: wondering how you make all packages install their .schemas files in /usr/share/gconf/schemas.
[16:47] <seb128> vuntz: we have a dh_gconf which does that
[16:48] <vuntz> seb128: does it set the GCONF_SCHEMA_FILE_DIR env var before configure?
[16:48] <seb128> configuration is a different question than where the schemas is stored
[16:49] <seb128> no it doesn't
[16:49] <seb128> what does GCONF_SCHEMA_FILE_DIR do?
[16:49] <vuntz> it's just a way to specify where to put the .schemas files on install
[16:50] <vuntz> make install, I mean
[16:50] <seb128> ah no
[16:50] <seb128> dh_gconf just do a mv
[16:50] <vuntz> heh
[16:50] <vuntz> you're cheating
[16:50] <seb128> 		doit("mkdir -p $new_schemas_dir") unless -d $new_schemas_dir;
[16:50] <seb128> 		doit("mv $old_schemas_dir/*.schemas $new_schemas_dir/");
[16:50] <seb128> 		doit("rmdir -p --ignore-fail-on-non-empty $old_schemas_dir");
[16:50] <vuntz> ok
[16:51] <seb128> looking to do a similar change upstream or for opensuse?
[16:54] <vuntz> opensuse, at least
[16:54] <vuntz> upstream would be better, but this might break distros, I guess
[16:55] <seb128> how break?
[16:57] <vuntz> seb128: well, I don't know. This could have interesting side-effects
[16:57] <seb128> add a configure option to gconf to specify the default location
[16:57] <seb128> and let distro use it?
[16:57] <vuntz> you first need to make sure all your packages have the files in the same directory
[16:58] <vuntz> I'm pretty sure it'd break some stuff on openSUSE, eg
[16:59] <seb128> why?
[16:59] <seb128> we had schemas in etc and usr for a while
[16:59] <seb128> it didn't break anything
[16:59] <didrocks> seb128: adding an autotool option to gconf seems interesting (o/ vuntz)
[16:59] <vuntz> we do some magic stuff when upgrading a package with gconf schemas
[16:59] <seb128> each package knows where it install its schemas
[16:59] <seb128> which ones?
[17:00] <vuntz> so we don't have to call gconftool-2 --makefile-install-rule/uninstall if it's not necessary
[17:00] <seb128> I would be interested to know why ;-)
[17:00] <seb128> why? to spare some cpu cycles?
[17:00] <vuntz> yep
[17:00] <vuntz> it was pretty expensive at some point
[17:00] <seb128> I would not think it's that much ressource intensive
[17:01] <vuntz> well. Do you do that once per package or once per apt transaction?
[17:01] <seb128> once by package
[17:01] <seb128> but only for the package schemas
[17:03] <vuntz> pretty sure it's andreasn_'s fault
[17:03] <andreasn_> hm, what's up now?
[17:03] <andreasn_> whatever it is, I think it's your fault
[17:03] <didrocks> ^^
[17:04] <seb128> vuntz: being clever on whether schemas need reinstalling would probably take as much cpu as installing no?
[17:05] <seb128> vuntz: ie you need to compare all the key values and translations to make sure there is nothing worth updating
[17:05] <vuntz> andreasn_: come on. Admit it. You did it.
[17:05] <vuntz> seb128: cmp?
[17:05] <seb128> vuntz: and in 95% of the cases you have translations changes at least so you install the update
[17:05] <vuntz> right
[17:06] <vuntz> it's just that we have more updates for the same version in openSUSE than in Ubuntu
[17:06] <seb128> lol
[17:06] <vuntz> (because we rebuild packages all the time)
[17:06] <seb128> it's your rebuilding everything all the time?
[17:06] <seb128> right
[17:07] <didrocks> seb128: schema translation are embeeded in the binary package, not external?
[17:07] <vuntz> so different needs :-)
[17:10] <seb128> didrocks: there is no binary?
[17:10] <seb128> didrocks: the schemas translations are the .mo files
[17:11] <seb128> didrocks: upstream writes localized xml and we do patch to use gettext instead
[17:11] <didrocks> seb128: and those .mo files are "injected" in the package during soyuz build?
[17:12]  * didrocks can't get the big picture for how ubuntu handles localisation :) (just hope with tdeb that it will be easier :))
[17:13] <seb128> didrocks: what is tdeb?
[17:13] <seb128> didrocks: po files are imported on upload
[17:13] <mvo_> *cough* when I last looked at tdebs (a while ago) it was one tdeb per package per  language
[17:13] <didrocks> seb128: tdeb = translation deb. It's a new format for localisation on debian system. (http://people.debian.org/~codehelp/tdeb/)
[17:14] <didrocks> mvo_: it's still the case with the latest specification
[17:14] <seb128> didrocks: and export in language packs
[17:14] <mclasen> seb128: your patch to extract schema translations is a bit broken, btw
[17:14] <mvo_> that is quite a big number of additional packages then
[17:14] <seb128> didrocks: dpkg -L language-pack-gnome-fr-base
[17:14] <didrocks> seb128: so, every translation for every gconf key are in this language pack?
[17:14] <didrocks> mvo_: for sure
[17:15] <seb128> didrocks: yes, they are in the upstream mo too
[17:15] <seb128> mclasen: in what way?
[17:15] <didrocks> seb128: ok, thanks :)
[17:15] <mclasen> seb128: intltool munges the whitespace when extracting
[17:16] <mclasen> so for long descriptions, what you get from gconf doesn't match the msgid in the .mo
[17:16] <mclasen> also, you don't call bind_textdomain_codeset, so you may see some breakage depending on the locale...
[17:17] <seb128> ok, thanks for letting us know
[17:17] <mclasen> I've posted a working patch to gconf-list earlier today
[17:17] <seb128> pitti: ^ do you know about those issues?
[17:18] <vuntz> mclasen: do you know if installing .schemas files in /usr/share/gconf/schemas instead of /etc/gconf/schemas could break something on fedora?
[17:18] <vuntz> (changing the default)
[17:19] <mclasen> vuntz: it would break all the opencoded schema installation/deinstallation code, of course...
[17:19] <mclasen> since we don't have your %gconf macros yet
[17:19] <mclasen> so it would be a ton of busy work for little gain
[17:19] <vuntz> so yeah, wouldn't be fun for you
[17:19] <mclasen> which is why we  refrained from doing that so far
[17:19] <seb128> vuntz: easier way is the configure option
[17:20] <seb128> for gconf to change the default directory
[17:20] <seb128> so distros who want change just set that
[17:21] <vuntz> seb128: well, this needs some change, since right now, this is hard-coded in gconf-2.m4, which ends up in aclocal.m4 of all tarballs...
[17:22] <seb128> vuntz: ok, I see, lot of trouble for little benefit, let's wait for dconf rather ;-
[17:22] <seb128> ;-)
[17:22] <vuntz> but I guess we can do something similar to gconftool-2 --get-default-source in the m4, if we really want
[17:25] <didrocks> vuntz: hum, gconftool-2 --get-default-source gives me /etc/gconf/gconf.xml.defaults in my jaunty
[17:26] <seb128> didrocks: directory where are installed the schemas != directory where the keys are written
[17:26] <seb128> didrocks: the schemas is a source which is parsed to write the values in the gconf database
[17:27] <seb128> ie the schemas are the source and the directory is where the keys are written
[17:27] <didrocks> seb128: I understand as schemas are just used once... that's why I told vuntz that this command wouldn't help us in a the gconf m4 file
[17:27] <seb128> he said similar
[17:27] <vuntz> didrocks: this is why I said "similar to" ;-)
[17:27] <didrocks> ok, didn't get it, sorry ;-)
[17:46] <Ampelbein> ping pedro_: about bug 366723, the original upstream-version does not have a properties or delete button, it's a change we introduced in ubuntu. could you please close the upstream report about this? Also, I attached a debdiff which corrects the issue.
[17:48] <pitti> seb128: yes, I do, I saw the recent bug mail for that
[17:48] <seb128> pitti: ok
[17:48] <pitti> seb128: I'll apply the updates soon
[17:51] <pedro_> Ampelbein: alright, already closed, thanks for pinging
[18:07] <hggdh> seb128, ping and hello. Would you consider an update for evolution-exchange for bug 353187?
[18:07] <seb128> hey hggdh
[18:07] <seb128> hggdh: yes, we can sru evolution crashers
[18:07] <seb128> hggdh: do you want to work on the sru?
[18:07] <hggdh> seb128, OK, I will prepare a debdiff for it
[18:07] <seb128> thanks
[18:29] <pitti> good night everyone!
[18:30] <Nafallo> gnight pitti
[18:32] <hggdh> seb128, I should target jaunty-proposed on my update to e-e, correct?
[18:33] <seb128> hggdh: yes
[18:33] <seb128> 'night pitti
[18:41] <hggdh> seb128, done. debdiff is in bug 353187, nominated for Jaunty, ubuntu-sru subscribed
[18:41] <seb128> hggdh: thanks, I will sponsor that today after diner
[18:41] <seb128> but bbl for now dinner time ;-)
[18:41] <hggdh> seb128, bon appetit
[18:42] <seb128> hggdh: merci
[18:42] <seb128> bbl
[19:10]  * kenvandine_wk runs for a late lunch
[19:46] <dobey> vuntz: care to try my intltool branch that should fix your bug?
[20:59] <vuntz> dobey: sure, tell me how :-)
[21:01] <dobey> vuntz: bzr branch lp:~dobey/intltoolize-version-magic
[21:07] <vuntz> bzr: ERROR: Invalid url supplied to transport: "lp:~dobey/intltoolize-version-magic": No such project: intltoolize-version-magic
[21:09] <dobey> err
[21:09] <dobey> vuntz: bzr branch lp:~dobey/intltool/intltoolize-version-magic
[21:09] <dobey> sorry
[21:10] <vuntz> ah, should have guessed that
[21:11] <vuntz> hrm
[21:11] <vuntz> I guess my bzr version isn't recent enough :/
[21:11] <vuntz> bzr: ERROR: Unknown repository format: 'Bazaar RepositoryFormatKnitPack6 (bzr 1.9)\n'
[21:12] <dobey> oh
[21:12] <dobey> what version of bzr do you have?
[21:12] <vuntz> indeed, I have 1.8
[21:12] <dobey> wow that is old
[21:12] <dobey> :)
[21:12] <vuntz> maybe :-)
[21:12] <vuntz> I don't really follow versions of vcs ;-)
[21:13] <vuntz> I'll try to find the patch on lp and apply it
[21:13] <vuntz> should be enough to test
[21:15] <dobey> vuntz: https://code.edge.launchpad.net/~dobey/intltool/intltoolize-version-magic/+merge/5908 has the diff then
[21:40] <bryce> seb128: please fill out your info at https://wiki.ubuntu.com/DesktopTeam/i965Users
[21:40] <seb128> hey bryce
[21:41] <seb128> will do
[21:41] <bryce> heya seb128
[21:41] <seb128> I read the email from pitti but I don't have my laptop with me right now
[21:41] <seb128> I will do that tomorrow
[21:41] <bryce> seb128: ok, main question is do you run as 64 bit or 32 bit?
[21:41] <seb128> I can probably file the table without the laptop
[21:41] <seb128> i386
[21:41] <bryce> aha
[21:41] <seb128> that's a dell d630
[21:42] <bryce> seb128: I noticed a correlation between i386 and amd64 for seeing the freezes
[21:42] <seb128> you have an i386 and the freeze according to the table?
[21:43] <bryce> yeah I know, I'm the data point that breaks the rule
[21:44] <seb128> table updated
[21:44] <bryce> thanks!
[21:45] <seb128> ogasawara also got the freeze using the test script apparently
[21:45] <seb128> you're welcome
[21:45] <seb128> I'm looking forward getting bling back on this config ;-)
[21:45] <seb128> well I've still because I didn't upgrade compiz but I know quite some users have reported bugs about that
[21:47] <seb128> bryce: did you investigate the action or having a virtual setting?
[21:47] <bryce> ogasawara has the same model laptop as me (differing ram though).
[21:48] <seb128> bryce: because several people commented on the bug saying they don't have the issue and use a virtual setting ... could be coincidence but could be impacting on the issue too
[21:48] <bryce> I usually only see the freeze when running compiz for several hours; dunno if she runs with compiz enabled for such periods
[21:48] <bryce> I do not have a virtual option set, so did not investigate that
[21:48] <bryce> (since I can already reproduce the issue easily)
[21:48] <seb128> perhaps try to set one and see if you still get it
[21:49] <seb128> well virtual seems to workaround it not to trigger it
[21:49] <bryce> sure
[21:50] <bryce> at this point I'll try anything ;-)
[21:50] <bryce> could be circumstantial though
[21:51] <bryce> seb128: another question
[21:51] <seb128> oh, other topic, do you know if anybody cares about nvidia closed source driver issues?
[21:51] <seb128> we get quite some users complaining about vnc not refreshing in jaunty when using those
[21:51] <bryce> seb128: since a lot of bugs that are actually X bugs (crashes) get reported against gdm, could you add an apport hook for gdm that includes the X files?
[21:52] <bryce> seb128: there was a bug that ended up being vnc not having been updated to xserver 1.6
[21:52] <seb128> bryce: I guess you know how to do that so feel free to upload if you want
[21:52] <seb128> bryce: I can have a look otherwise
[21:52] <seb128> I though probably add apport hooks to quite some desktop components
[21:53] <bryce> yeah it's definitely worth learning
[21:54] <seb128> anyway if you know what to do, ie have it in xorg ready to copy feel free to do it
[21:54] <seb128> otherwise I will do that when I start on karmic updates
[21:54] <bryce> there's no hurry, it can wait until you're ready to do karmic stuff
[21:55] <bryce> you could basically just copy /usr/share/apport/package-hooks/source_xorg.py
[21:55] <bryce> you might want to add stuff to that you'd feel might be useful for debugging other kinds of gdm issues
[21:56] <seb128> well as said I've no issue with you uploading gdm so if it takes your a few minutes please do it's uploaded ;-)
[21:56] <seb128> "so it's uploaded"
[21:57]  * bryce <-- afraid of breaking gdm :-)
[21:57] <bryce> I could send you a debdiff though
[21:58] <seb128> yeah, either opening a bug or dropping me an email would be nice
[21:58] <seb128> so I know where to start and it's on my todolist
[21:58] <bryce> ok, will do
[21:58] <seb128> thanks
[21:58] <bryce> interesting, setting Virtual to 2048 2048 seems to not be freezing so far
[22:01] <seb128> bryce: interesting indeed
[22:18] <YokoZar> seb128: mind if i poke you on gnome-app-install?  I found you and mvo in the authors credits, and I'm interested in expanding it a bit so it can remove Wine applications that the user's installed
[22:18] <seb128> YokoZar: you are confusing me with somebody else there
[22:18] <YokoZar> ahh ok
[22:19] <seb128> YokoZar: glatzor is probably the Sebastian in this source
[22:19] <YokoZar> *looks again*
[22:19] <seb128> Sebastian Heinlein?
[22:19] <seb128> he's glatzor on IRC
[22:20] <YokoZar> Ahh yeah it is him thanks
[22:20] <seb128> you're welcome
[22:26] <seb128> bryce: do you know on what component is the bug about this vnc xserver 1.6 issue? or the corresponding bug number?
[22:28] <bryce> seb128: 260815