[04:00] <calc> anyone around who has dual head setup that can try to reproduce a bug for me?
[04:54] <pace_t_zulu> hey guys, i'd like to take a shot at bug #332253 in the epiphany-browser
[04:55] <pace_t_zulu> can someone point to the repo for epiphany-browser? right now i am using "apt-get source epiphany-browser"
[06:37] <pitti> Good morning
[07:15] <lool> hey pitti
[07:15] <lool> pitti: I think you said the UNR image didn't fit on your 1 GB USB stick, how large is it exactly?
[07:16] <pitti> lool: the current one does now (the 947 MB one)
[07:16] <lool> pitti: Could you recheck with the image we rerolled yesterday; it's 992837632 bytes
[07:16] <lool> Ah good
[07:16] <lool> pitti: I'm still curious about your dev size :)
[07:16] <pitti> lool:   storage.removable.media_size = 1028653056  (0x3d500000)  (uint64)
[07:17] <lool> Thanks
[07:17] <pitti> but don't take that as an assumption that all 1 GB sticks are exactly that large :)
[07:17] <pitti> I think we can expect 1,000,000,000 bytes, not more
[07:17] <lool> I don't, but plars says the image is too big for him
[07:18] <lool> And it's less than 1 billion bytes so I wonder what's happening
[07:18]  * pitti -> breakfast, back in 10
[07:18] <lool> Will check with him when he comes up
[07:18] <lool> guten Appetit!
[07:30] <pitti> danke :)
[08:11] <huats> hi everyone
[08:24] <pitti> hey huats
[08:24] <huats> hello pitti
[08:24] <huats> how are you ?
[08:25] <seb128> hey pitti huats
[08:25] <huats> seb128: o/
[08:43] <seb128> slomo: hi
[08:43] <chrisccoulson> hey pitti - you merged my tracker branch in to ubuntu-desktop last week for a SRU (installing the evolution plugin). Could you hold fire on uploading that (tomorrow?), as I'm working on some other fixes at the moment
[08:44] <pitti> chrisccoulson: sure, thanks
[08:44] <chrisccoulson> thanks:)
[08:44] <slomo> seb128: hi :)
[08:44] <seb128> slomo: could you have a look to bug #358426 when you have some time? it seems similar to this crash when gst-ffmpeg and ffmpeg were not in sync but seems to be different (ie the versions are in sync and the crash is still there withou gst-ffmpeg)
[08:45] <seb128> slomo: the bug has a gst_debug log, stacktrace, etc ... I'm not sure what to ask next
[08:47] <slomo> seb128: might be the other one... which version of gst-plugins-bad is in ubuntu, does it link to liblrdf0?
[08:48] <seb128> slomo: the dpkg -l | grep gstreamer log is in the bug
[08:49] <seb128> slomo: gst-plugins-bad is not installed by looking at the log
[08:49] <slomo> ok
[08:50] <seb128> slomo: the bug is an intrepid one, not jaunty too (ie 6 month old versions)
[08:50] <seb128> slomo: http://launchpadlibrarian.net/25174573/log is the gst_debug log
[08:50] <slomo> seb128: well, unless i miss anything there's no backtrace because g-s-d seems to run fine in gdb... hm, two things might be useful
[08:50] <slomo> seb128: a) GST_REGISTRY_FORK=no gdb --args g-s-d ...... might give a backtrace of the crash
[08:51] <slomo> b) GST_REGISTRY_FORK=no valgrind g-s-d .... might give something useful
[08:51] <slomo> that's a crash i've never seen before :)
[08:51] <seb128> ok thanks
[08:52] <seb128> slomo: I've asked for those now, thank you
[08:52] <slomo> np :)
[09:02] <didrocks> hey everybody o/
[09:02] <pitti> hey didrocks, bonjour
[09:02]  * pitti hugs slomo, long time no see
[09:03] <didrocks> Guten Tag pitti :)
[09:03] <seb128> lut didrocks
[09:04] <didrocks> hey seb128, quieter time just before the release?
[09:04] <seb128> didrocks: yes, using it to catch up on bug triage ;-)
[09:05] <didrocks> seb128: huge work :-)
[09:05] <seb128> indeed
[09:05] <seb128> and you? enjoying some non busy time before karmic opening and uds? ;-)
[09:07] <didrocks> seb128: not really, framasoft volonteers are rereading my book so that I can catch my french grammar mistakes and I am preparing Orsys lesson :-)
[09:07] <seb128> orsys?
[09:07] <didrocks> so, it's a continuing flow of work, no rest ;)
[09:08] <didrocks> orsys (http://www.orsys.fr/) is training company specialized in computer science firm audience
[09:09] <seb128> ah ok
[09:09] <seb128> you know how to keep busy apparently ;-)
[09:10] <didrocks> seb128: yes, and still reading the GNOME documentation :-) I also gave a shot to kde since I didn't boot it since approximately 5 years... What a change :)
[09:10] <seb128> still using it?
[09:10] <seb128> how did you like it?
[09:11] <didrocks> seb128: very pleasant to the eye, but I don't like having too many configuration options and lack of "coherence"
[09:11] <didrocks> it was just for testing :-)
[09:12] <seb128> good ;-)
[09:42] <rickspencer3> asac: seb128 pitti Riddell
[09:42] <rickspencer3> what's the word on the street?
[09:42] <pitti> hey rickspencer3
[09:42] <seb128> hey rickspencer3
[09:42] <rickspencer3> hi pitti
[09:42] <rickspencer3> hi seb128
[09:42] <seb128> things look good from here
[09:42] <pitti> All systems operate within normal parameters, Captain!
[09:42] <rickspencer3> lol
[09:42] <pitti> nothing on my radar
[09:42] <rickspencer3> bryce would be saying "she can't take much more"
[09:43] <pitti> argh, except that launchpadlib broke my shiny retracers again
[09:43] <rickspencer3> http://www.reddit.com/r/Ubuntu/comments/8ebbu/any_others_running_jaunty_on_intel_gm965gl960_try/
[09:44] <rickspencer3> pitti: arg
[09:44] <rickspencer3> the launchpad team is in the next room here, should I ask them to help?
[09:45] <pitti> nah, that's fine
[09:45] <pitti> rickspencer3: let me track it down first, produce a test case, and then you can drop that test case on their feet :)
[09:45] <pitti> launchpadlib.errors.HTTPError: HTTP Error 412: Precondition Failed
[09:45] <pitti> who could imagine to have _even better_ error messages?
[09:48] <pitti> rickspencer3: how's the war room today?
[09:54] <rickspencer3> pitti: so far so good
[09:56] <cassidy> mpt: hi. I use to add you in CC in Empathy bugs proposing a controversial UI/usuability change. Don't hesitate to tell me if that annoys you and I'll stop :)
[10:21] <asac> rickspencer3: all good in jaunty ;)
[10:26] <asac> rickspencer3: btw, i didnt get a freeze yesterday :/
[10:29] <rickspencer3> asac: you mean with the script?
[10:30] <asac> rickspencer3: i didnt run the script. just did normal use.
[10:30] <asac> rickspencer3: you have a URL to the script at hand so i can fire it up?
[10:30]  * rickspencer3 gets bug
[10:31] <rickspencer3> https://bugs.edge.launchpad.net/bugs/359392
[10:31] <rickspencer3> asac: it's repro.sh in there ^^
[10:34] <rickspencer3> asac: here's a direct link:
[10:35] <rickspencer3> http://launchpadlibrarian.net/25683477/repro.sh
[10:35] <rickspencer3> note that you need to install wmcntrl to make it work
[10:35] <rickspencer3> also, compiz needs to be enabled
[10:36] <asac> ok let me check wmcntrl
[10:41] <asac> rickspencer3: i assume that in the while loop using workspace 3 would also work (instead of 4). i only have 4 workspaces
[10:41] <rickspencer3> oh
[10:41] <rickspencer3> asac: you need to have 6 workspace, I should have mentioned
[10:42] <rickspencer3> also, your computer will be totally unusable, and it's an infinite loop
[10:42] <rickspencer3> I stop the script by logging out
[10:44] <asac> rickspencer3: so if i change the workspace it changes to to 3 its known to not work?
[10:44] <asac> let me use 6 workspaces
[10:44] <asac> atm its flipping workspaces happily
[10:44] <asac> and no freeze
[10:45] <rickspencer3> then it's working
[10:45] <rickspencer3> it usually take 2-4 minutes to freeze
[10:47] <asac> k i let it running with 6 workspaces now
[10:47] <asac> lets see
[10:50] <asac> still action ;)
[10:50] <asac> produces massive amount of heat. had to put my laptop somewhere else
[10:56] <asac> rickspencer3: still running ;)
[10:57] <asac> so no. thats probably "made for germany" ;)
[11:02] <asac> ENOTREPRODUCIBLE
[11:02] <asac> stoped this experiemtn now ;)
[11:51] <mpt> asac, https://wiki.ubuntu.com/NotifyOSD#Firefox
[11:51] <mpt> cassidy, that's fine
[11:53] <asac> mpt: isnt that the status-quo?
[11:53] <asac> ah there is instead and alternatively
[11:54] <asac> mpt: so assuming that mozilla didnt like that; do you have other approaches how we can use native notifications somehow?
[11:55] <asac> mpt: what about using indicators for downloads/updates-available, etc.
[11:55] <mpt> asac, no, I think using notification bubbles for that would be a bit worse than having no notification at all.
[11:56] <asac> but our answer can't be: just drop notifications completely
[11:56] <asac> downloads completed must be a common use-case we should unify
[11:56] <asac> what do we do with other downloaders (like transmission, etc.)
[11:57] <asac> do those display notifications?
[11:57] <mpt> That's why in <https://wiki.ubuntu.com/NotifyOSD#Transmission> I make exactly the same recommendation as for Firefox. :-)
[11:57] <asac> ah i see ;)
[11:57] <asac> found it right after saying that
[11:57] <mpt> I don't know how they've actually done it, though
[11:57] <asac> mpt: ok. but hwo about different approaches. what about indicators instead of jumping the full dialog in your face?
[11:58] <mpt> asac, what do you mean by "indicators"?
[11:58] <asac> a download indicator?
[11:58] <asac> ;)
[11:58] <asac> similar to message-indicator ;)
[11:58] <mpt> oh, a menu for downloads?
[11:59] <asac> mpt: why not. a menu where the folders that have finished downloads are indicated
[12:00] <mpt> I think that wouldn't be appropriate, because they're things you sometimes want to keep an eye on the progress of, but while a menu was open you couldn't really do anything else.
[12:00] <mpt> That's basically the Mathusalem idea.
[12:01] <mpt> A unified file copying/moving window would be nifty, and Firefox/Transmission downloads could hook into that, but that wouldn't be a menu.
[12:01] <asac> mpt: err
[12:01] <asac> currently the notification is only done when downloads have finished
[12:01] <asac> i dont want to display the progress of the downloads in the indicator
[12:01] <asac> just indicate folders with finished (but unseen) downloads
[12:02] <asac> mpt: i agree that having a unified download progress display would be something - but for the future
[12:02] <asac> for now i want to find a solution so download finished can be done in a notification bubble (because if we say that has to stop mozilla will never adapt our thing)
[12:03] <mpt> As I said, I think using a notification bubble would be worse than no notification at all.
[12:03] <asac> mpt: you said an "actionless notification bubble"
[12:03] <asac> thats why i suggested: "actionless notification bubble + indicator"
[12:03] <asac> ;)
[12:03] <mpt> Where did I say that?
[12:04] <asac> well. thats what i understood. if you didnt say that then i disagree
[12:04] <asac> getting a notification when on download finished is imporant
[12:04] <asac> popping up dialogs cant be the answer for that
[12:04] <asac> getting a notification without a way to also open those download folders with new content is worse, yes.
[12:08] <mpt> So, in order of preference (from my POV):
[12:08] <asac> personally i want to get notified when downloads finished
[12:08] <mpt> 1. have Downloads window request attention (good)
[12:08] <asac> k
[12:08] <mpt> 2. nothing (adequate)
[12:08] <mpt> 3. notification bubble (bad)
[12:08] <mpt> 4. fallback alert box (terrible)
[12:10] <asac> how can nothing be better than notification?
[12:11] <mpt> what?
[12:11] <mpt> You mean, how can it be better than a fallback alert box?
[12:12] <asac> no why is 2 better than 3 (or 3 worse than 2)
[12:12] <mpt> oh, right
[12:12] <asac> i want to be notified when download finished
[12:12] <asac> whether i can click on it or not is just secondary
[12:12] <mpt> Because a notification bubble shows you that the download has finished but does not let you respond, which would be frustrating.
[12:13] <asac> combined with making a single place on the desktop where you can access finished downloads (read: indicator) i would say that 3 is even better than 1
[12:14] <mpt> Maybe so, but I'm 90% sure there won't be such a menu, because it's not a common enough case
[12:14] <asac> preferring 2 over three really sounds like sticking your head in the ground because we couldn't get 1 :)
[12:15] <mpt> Not at all, there are quite a few browsers that do #2, even including previous versions of Firefox.
[12:15] <asac> mpt: the menu would only show if there are finished downloads.
[12:17] <mpt> Other examples include Safari, IE/Mac, and Opera.
[12:18] <asac> mpt: so as it stands now if we don't suggest anything different from 1. we will get either 4 or the old XUL notifications
[12:19] <mpt> asac, ok, so the XUL ones are about at the same level as #2
[12:19] <asac> mpt: yeah. but i wouldnt bet on it
[12:20] <asac> we might really end up that firefox starts doing 4
[12:21] <asac> also i think that downloading is almost as a similar important use case as messaging
[12:21] <asac> i know a bunch of users that download all the time, but never touched any IM client
[12:21] <asac> and frequently they have issues to find the download they just did
[12:22] <mpt> So, I'm sorry that you're stuck in the middle of this
[12:23] <mpt> But really, you're complaining to the wrong person
[12:23] <mpt> We've offered one recommended behavior, and two acceptable alternatives
[12:23] <asac> mpt: ok. who is the right one to talk about this then ;)?
[12:24] <mpt> If Mozilla doesn't like any three of those and they want a nasty experience on Ubuntu, that reflects poorly on them.
[12:27] <mpt> I'll write up the three in more detail on the wiki page
[12:27] <asac> thanks.
[12:28] <asac> fwiw, i think its unlikely we will get 4. its just discussed. in the end we will stick with ugly XUL notifications forever ... i am currently fighting to get the native actions at least in toolkit supported in a way that wont lead to 4
[12:28] <asac> native notifications
[12:28] <asac> because we need them for tbird later
[12:28] <asac> together with indicator support
[12:30] <asac> mpt: since it always pops-up it would make sense to also tell why our approach is better than growl for instance
[12:30] <asac> they always say thats how it should be done properly
[12:30] <mpt> asac, sorry, since what always pops up?
[12:30] <asac> i have no arguments because i have absolutely no idea how growl feels
[12:31] <asac> mpt: growl is always raised (pops-up) in discussions
[12:31] <asac> as an example how to do it right
[12:31] <mpt> oh, I see
[12:32] <mpt> Growl causes mis-clicking that Notify OSD avoids.
[12:33] <mpt> I.e. a Growl bubble can appear possibly on top of where you're about to click on another window.
[12:33] <mpt> and if you click the bubble, it does something else (e.g. opens a window).
[12:33] <asac> mpt: can you write that somewhere down?
[12:34] <asac> or even capture a video that shows the problem?
[12:34] <asac> did you tell that to mconnor?
[12:34] <mpt> I did tell him
[12:35] <mpt> he thinks it's a worthwhile tradeoff
[12:35] <mpt> https://wiki.ubuntu.com/NotifyOSD?action=diff&rev2=141&rev1=140
[12:36] <mpt> asac, our rationale for non-clickability is at <https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#Avoiding%20actions>
[12:36] <mpt> I'll add a mention of Growl there
[12:37] <asac> ok
[12:37] <asac> mpt: one thing left you didnt answer: why do you consider downloads a less common use-case than messages?
[12:40] <seb128> why do you need to be notified about downloads at all?
[12:41] <seb128> you are not notified about local copies
[12:42] <mpt> asac, well, I don't have statistics on it, but I'm fairly sure that most people receive e-mail + IMs (even if they don't use IM at all) more often than they download stuff
[12:44] <asac> most users use web mail
[12:44] <asac> desktop email is a dying thing and most likely only used by power-users
[12:44] <mpt> seb128, that's a good point, though I guess it's a bit easier to resume a local move/copy after hibernation than it is to resume a download
[12:44] <seb128> mpt: download should inhibit hibernation then?
[12:45] <asac> seb128: downloads take longer and copying files has its own progress dialog open
[12:45] <asac> that you dont close
[12:45] <asac> while its copying
[12:45] <seb128> asac: firefox doesn't have a download indicator?
[12:45] <seb128> I should try something else than epiphany every now and then ;-)
[12:46] <asac> seb128: i am not sure about default behaviour, but i definitly dont have the download window open during downloads
[12:46] <asac> seb128: also think about transmission
[12:46] <asac> seb128: takes long to download a huge file and its nice to be notified that its finished
[12:46] <seb128> right
[12:46] <asac> unifying how users can access finished downloads in an indicator sounds right to me
[12:46] <seb128> I think bubble are nice for those
[12:46] <seb128> I'm not sure I agree with " 1. have Downloads window request attention (good)"
[12:47] <asac> seb128: but mpt disagrees ;) ... he says that bubble is worse than nothing
[12:47] <seb128> but I hate things claiming for attention when they are not urgent
[12:47] <asac> me too
[12:47] <seb128> and I hate having dialogs opening on my screen why I don't do the action
[12:48] <seb128> bubbles seem really adapted to notify of "your download is done" now in a non intrusive way
[12:48] <asac> the more i think about it the more i think that we should have a common place on the desktop where users can click on to open finished downloads (or at least folders where te finished downloads are)
[12:48] <seb128> don't we download to the desktop by default?
[12:48] <asac> seb128: desktop is usually hidden
[12:48] <asac> seb128: by windows
[12:48] <seb128> well it's your background, it's not hard to access
[12:48] <asac> its the wrong place imo
[12:48] <seb128> it's in the places menu too
[12:49] <seb128> and you have this "show desktop" applet
[12:49] <asac> seb128: well. then there should be indication in the places menui ;)
[12:49] <asac> thats ok for me too
[12:49] <mpt> That would be nifty
[12:49] <asac> cool mpt adapts a new idea ;)
[12:49] <mpt> a Downloads place that glows or something when a download completes
[12:49] <asac> ok. lets make the places menu the downoad indiateor
[12:49] <asac> ;)
[12:49] <seb128> asac: microsoft users seem to have no difficulty to find their desktop background and abuse it a lot to me
[12:50] <asac> seb128: oh sure they have
[12:50] <asac> seb128: they have no problems to change the background
[12:50] <asac> but they have problems to see that a new file was jsut added there
[12:50] <seb128> that's because they have too much crap there ;-)
[12:51] <asac> lol
[12:51] <seb128> you would have the same issue in a download directory after some zillions downloads if you don't clean
[12:51] <asac> right
[12:51] <seb128> or you need what GNOME is discussing, a journal browsing sort of thing
[12:51] <asac> yeah. still the desktop is the wrong place to access files
[12:51] <asac> you have to close all windows and so on
[12:51] <seb128> ie have files not listed by directories but by recent changes, new documentes, etc
[12:51] <asac> accessing that through places is good
[12:51] <asac> even if its just the Desktop folder
[12:52] <seb128> I don't agree with that
[12:52] <seb128> just switch to an empty workspace or click on the show desktop button
[12:52] <asac> i dont see my mother doing that without getting personal training
[12:52] <seb128> well, note that we decided to download to desktop by default
[12:52] <mpt> hey andreasn, are you going to the Desktop Summit?
[12:52] <seb128> upstream has a Download directory in xdg-user-dirs
[12:52] <asac> seb128: right because we had not better way
[12:53] <seb128> and it's in the places menu
[12:53] <seb128> translated
[12:53] <andreasn> mpt, then one in the warm place?
[12:53] <andreasn> mpt, yes
[12:53] <seb128> asac: well, upstream has desktop/download by default...
[12:53] <mpt> andreasn, neat, are you giving a talk at all?
[12:53] <asac> seb128: dont get me wrong: i dont say that desktop is the wrong place in general
[12:53] <andreasn> mpt, and possibly UDS, I'll see if I get some cash over
[12:53] <seb128> asac: and they have a download bookmark
[12:54] <seb128> asac: we just decided to overwritte than by using the desktop for downloads
[12:54] <asac> seb128: yeah. personally i think we can either use desktop or download if we indicate finished downloads in places
[12:54] <andreasn> mpt, probably not, I think the submission for talks has passed already. Not sure what I would talk about.
[12:54] <mpt> andreasn, I realized too late that it would be a good time to talk about reducing the use of icons in Gnome
[12:54] <mpt> I saw you mentioned that in the Gnome roadmap
[12:54] <asac> seb128: sure. my suggestion is to indicate downloads in places menu somehow and if that works well we can switch to Downloads folder ... but for now we can keep Desktop as its in places too
[12:55] <andreasn> mpt, maybe it can be done as a lightning talk, but yeah, that
[12:55] <seb128> asac: alright, we just need a good idea to indicate it then ;-)
[12:55] <asac> seb128: yeah. but thats just ground work ;)
[12:55] <andreasn> 's defenitly a good goal, and we need to figure out a good way to motivate and communicate it
[12:55] <asac> for the monkeys ;)
[12:55] <seb128> bah, dropping icons, no everything is as ugly and hard to use than the fusa menu applet ;-)
[12:56] <seb128> no -> so
[12:56] <seb128> pedro__: olla
[12:57] <pedro__> salut seb128
[12:58] <andreasn> is it? I haven't used it much, I'm just attacking it from a visual design perspective and thinks it looks cleaner without the blobs of color
[12:59] <andreasn> and part of our problem right now is if a menu item gets a icon or not depend fully on if someone got around drawing it or not, and that feels a bit odd
[12:59] <seb128> pitti: I'm not convinced that bug #349948 is a gtk issue, I've seen no such issues in other dialogs
[12:59] <andreasn> garrett managed to fill all the menu items on his old industrial firefox theme though. A quite interesting experience
[13:00] <pitti> seb128: hm, it works for most labels, just not for some with particular lengths
[13:00] <pitti> seb128: but I don't mind if you reassign it back
[13:00] <seb128> andreasn: icons are easy to spot, parsing text is taking a while
[13:00] <seb128> pitti: no, it just seems weird to me, we usually have the opposite bug, it wraps too easily
[13:01] <pitti> I know :/
[13:01] <seb128> pitti: ie doesn't adapt to the dialog changes and looks ugly because the lines are wrapped too much
[13:01] <pitti> (bug 20096)
[13:01] <seb128> right
[13:02] <seb128> would be nice to get a testcase for #349948
[13:02] <seb128> andreasn: I pick the wrong items in fusa often, there is 7-8 entries without icons there, it's just too easy to be wrong from 1 line with muscle memory in the menu when you use it
[13:03] <seb128> andreasn: icons makes much easier to pick the right one
[13:09] <maxb> What happens when you unlock (by entering your password) the GNOME screenlock? Something incredibly CPU intensive seems to be occurring on Jaunty
[13:10] <chrisccoulson> does anyone know off the top of their head if g_unlink blocks until the file is removed?
[13:12] <james_w> chrisccoulson: by removed to you mean considered removed by the OS, or gone from disk?
[13:12] <james_w> I doubt very much it does the latter, but it may do the former
[13:15] <seb128> pitti: ok, I've looked at this gtk bug
[13:15] <seb128> pitti: you have code to "prevent window from being auto-resized in finish_unmount_flush_window()"
[13:16] <seb128> pitti: the issue seems that the "is now safe" label can be longer than the first one
[13:16] <pitti> right, since that looks ugly
[13:16] <pitti> can I tell the label "please go rewrap yourself"?
[13:16] <seb128> pitti: and since you prevent the dialog change, you get what you asked for
[13:17] <seb128> pitti: no, I think we are back to #20096 then
[13:17] <pitti> well, no, I want the label to wrap in its current bounds
[13:17] <pitti> and indeed it does that most of the time
[13:17] <pitti> just not with some drive labels/translations, i. e. with particular strings
[13:18] <seb128> hum ok
[13:18] <seb128> I will try to get a testcase
[13:19] <chrisccoulson> james_w - considered removed by the OS. i was just wondering at which point the function returns. say, if i call g_unlink on a file that is 2GB, is it likely to take some time to return?
[13:19] <chrisccoulson> if it takes some time, then it might explain a tracker bug i'm looking at
[13:20] <james_w> chrisccoulson: as I understand it unlink removes the pointer from the directory to the file, so it shouldn't depend on the size of the file
[13:20] <james_w> though there may be some walking the indirect blocks to mark then as uneeded
[13:21] <chrisccoulson> thanks. i might have to do some more debugging later:)
[13:22] <seb128> pitti: are you sure you have cases where the "is safe now" actually wraps?
[13:23] <james_w> chrisccoulson: what's the bug?
[13:24] <seb128> pitti: I've added a small testcase to the bug, which is basically a copy of the buggy function
[13:24] <pitti> seb128: yes, of course
[13:24] <chrisccoulson> james_w - when you force a reindex (or a reindex is forced because the index became corrupt), the existing indexes aren't removed properly on shutdown
[13:24] <pitti> seb128: thank you
[13:24] <chrisccoulson> james_w - the indexes are all g_unlink'd
[13:24] <seb128> bratsche: hello
[13:25] <BugMaN> hy seb128! :)
[13:25] <seb128> bratsche: do you think you could have a look to bug #349948 and tell us if you see something wrong there?
[13:25] <bratsche> seb128: Hey
[13:25] <bratsche> Sure.
[13:25] <seb128> hi BugMaN
[13:25] <chrisccoulson> but i noticed in the tracker code that if it doesn't shutdown within 500ms of the shutdown being requested, it just exits immediately with an error. i was wondering if it might actually be exiting before all the indexes were removed
[13:26] <chrisccoulson> james_w - i can't test that though until i get home from work
[13:28] <bratsche> seb128: Yeah I see it with your example.c.  Give me a few mins to finish something up and I'll look into this.
[13:28] <seb128> bratsche: thanks
[13:31] <james_w> chrisccoulson: ah, I was wrong
[13:31] <james_w> chrisccoulson: unlinking a 100M file with g_unlink takes over 2 seconds here
[13:32] <chrisccoulson> james_w - thanks. so that confirms my theory then - trackerd probably exits long before the indexes are deleted
[13:32] <chrisccoulson> which might explain why reindexing doesn't resolve index corruption
[13:32] <james_w> the new indexes and the old indexes are in the same directory?
[13:33] <james_w> and just being present in that directory makes them considered valid?
[13:34] <chrisccoulson> james_w - i think so. i don't know the tracker code all that well. i just have to keep reading it to try and fix bugs that people are seeing
[13:34] <chrisccoulson> when you force a reindex, the daemon shuts down, but should remove the old indexes on shutdown
[13:34] <chrisccoulson> then when it restarts, it recreates them. that doesn't seem to be what actually happens though
[13:35] <james_w> ah
[13:35] <chrisccoulson> j\ames_w - fyi - bug 361205
[13:35] <james_w> perhaps it should just mark them all invalid somehow on shutdown, then remove any invalid ones on startup
[13:37] <chrisccoulson> perhaps, but i'm not sure how to do that. the intention upstream is that they get deleted on shutdown, but that bit seems to be broken
[13:40] <james_w> yeah, but they also seem to intend the daemon to shutdown quickly, which seems to be incompatible
[13:41] <james_w> deleting on startup allows you to do potentially long-running operation when you are presumably going to be running for a while
[13:43] <james_w> it's quite worrying that it seems to corrupt its index so often, or is there something I am missing?
[13:44] <james_w> ah, they are replacing qdbm
[13:44] <james_w> still worrying though
[13:44] <chrisccoulson> james_w - yeah, upstream suspect a lot of these issues are qdbm related, and they think they will go away as it is replaced for 0.7
[13:45] <chrisccoulson> but that's never going to happen for jaunty. the corruption issues occur more frequently for some people than others. i haven't seen the issue for ages now
[13:46] <chrisccoulson> in the meantime, we just have to live with the workaround, which is to detect the corruption and then do a reindex
[14:19] <bratsche> seb128: I posted a fixed example.c to that bug.
[14:21] <seb128> bratsche: looking
[14:21] <seb128> bratsche: thanks, you rock
[14:21] <seb128> pitti: ^ reassigning the gnome-mount bug your way
[14:21] <pitti> seb128: thanks
[14:22] <seb128> pitti: thanks to bratsche for fixing it ;-)
[14:22] <bratsche> Sure, np :)
[14:22]  * pitti hugs bratsche
[14:48] <mvo> hey glatzor - do you have a opinion about my workaround for #257739 ?
[14:50] <seb128> bratsche: I'm not sure how busy you are, feel free to ignore me, but have you already read bugs about url being opened twice from about boxes in GTK or GNOME applications?
[14:50] <glatzor> hello mvo, sorry but I am not a kernel developer :)
[14:50] <glatzor> mvo, are you sure about the bug number=
[14:50] <glatzor> ?
[14:50] <mvo> not anymore ;)
[14:51] <seb128> bratsche: it's weird, that happens with most applications, ie gedit but not in gtk-demo, I don't see anything specially those do though
[14:51] <seb128> hi glatzor
[14:51] <glatzor> hello seb128 !
[14:51] <mvo> https://bugs.edge.launchpad.net/ubuntu/+source/packagekit/+bug/257639
[14:51] <mvo> glatzor: ^-- this one :)
[14:53] <Ampelbein> seb128, bratsche bug 334378
[14:53] <seb128> Ampelbein: thanks but I'm triaging gtk bugs that's why I ask about it ;-)
[14:54] <Ampelbein> oh, ok
[14:54] <seb128> Ampelbein: I'm not convinced that it's a gtk bug though since gtk-demo doesn't have it so I was not sure where to send it to GNOME
[14:55]  * bratsche pulls down the transmission source to take a peek
[14:56] <bratsche> Yeah, I just reproduced it in transmission.
[14:57] <seb128> bratsche: well, you can try in gedit or most desktop applications
[14:57] <seb128> they just use gtk_about though
[14:57] <seb128> it's a bit puzzling
[14:57] <bratsche> Yeah, weird.
[14:59] <seb128> ok, it's a gtk bug
[14:59] <seb128> or at least a gtk behaviour change
[15:00] <bratsche> Did you find a difference between gtk-demo and the other apps?
[15:00] <seb128> ld preloading the intrepid libgtk-x11 makes it work correctly
[15:00] <bratsche> Interesting.
[15:00] <tadeu_> guys, any known problem about upgrading 8.10 to 9.04 ?
[15:00] <seb128> tadeu_: hi, user questions are better placed on #ubuntu or #ubuntu+1
[15:00] <bratsche> seb128: I have a call now, but after that I can try to look into this some more probably.
[15:01] <tadeu_> seb128, ok, sorry
[15:01] <seb128> bratsche: ok thanks, no hurry I will try to figure what gtk-demo does differently
[15:01] <bratsche> Cool, thanks.
[15:01] <seb128> tadeu_: but no, no major known issue apparently
[15:22] <seb128> bratsche: ok, I figured what is the difference
[15:23] <bratsche> What is it?
[15:24] <seb128>   gtk_about_dialog_set_url_hook (activate_url, NULL, NULL);
[15:24] <seb128> activate_url does a g_print in the gtk case
[15:24] <seb128> but gtk calls the webbrowser anyway
[15:24] <bratsche> If you remove that hook then it gets called twice?
[15:24] <bratsche> Ah, I see.
[15:24] <seb128> those applications do a gtk_show_uri
[15:24] <seb128> the documentation doesn't seem clear to me
[15:25] <seb128> why do you need a gtk_about_dialog_set_url_hook() call if gtk hooks it by default to gtk_show_uri
[15:25] <seb128> and why if you set a custom handler you still get the gtk one?
[15:25] <seb128> is that supposed to be this way or a bug?
[15:25] <bratsche> This may have changed.  I'll poke around in gtk+ history after this call.
[15:25] <seb128> thanks
[15:25] <seb128> mclasen might know
[15:26] <seb128> gnome bug #566391
[15:26] <seb128> hum, no, that seems a different bug
[15:27] <mclasen> seb128: sounds like a bug
[15:27] <mclasen> two handlers at the same time, I mean
[15:27] <seb128> mclasen: ok thanks, I will open that on bugzilla then
[15:27] <mclasen> chpe recently added a default handler, so that may have messed things up
[15:28] <seb128> right, it seems that the gtk handler is called which opens a browser and those applications do that manually too
[15:28] <seb128> so you get 2 browser started
[15:32] <james_w> http://git.gnome.org/cgit/gtk+/commit/?id=405955749103dcfdf582b6ae4f053c66837a6281
[15:32] <james_w> +If you want provide your own hooks overriding the default ones, it is important
[15:32] <james_w> +to do so before setting the website and email URL properties, like this:
[15:33] <seb128> james_w: hum right, still confusing to have both hooks used
[15:33] <james_w> indeed
[15:34] <seb128> I've opened gnome bug #579838
[15:35] <seb128> james_w: the ubuntu bug has been opened 2 month before this change so that seems not due to it
[15:35] <james_w> ah, ok
[15:44] <glatzor> mvo, actually post update hook of packagekit just results in emitting an "update-changed" signal and invalidating the internal updates cache of the daemon (not the backend)
[15:44] <mvo> glatzor: does that not reopen the apt cache immediately too?
[15:47] <glatzor> mvo, depends on the running client apps. gpk-update-icon will queue a get-updates transaction when it recieves the "updates-changed" signal of packagekit
[15:47] <glatzor> so actually you should apply your patch to python-apt
[15:48] <mvo> glatzor: well, its pretty clear that the patch is just a woraround until the real problem is isolted (I suspect its in libapt itself even)
[15:49] <glatzor> mvo, but we will only see a slow down of the cache opening in the case of a lock?
[15:50] <mvo> glatzor: I think its a race, both synaptic/update-manager and PK try to open it at about the same time
[15:50] <mvo> glatzor: my theory is that PK is slightly faster and has half-rebuild the binary cache when synpatic opens it and notices that its "broken" (because its not fully generated yet)
[15:51] <mvo> glatzor: obvisouly the bug is in libapt then, but the workaround would still work because the opening would be at different times
[16:20]  * kenvandine_wk heads out for a bit of a long lunch... back in 1.5 hours :)
[16:37] <proppy> seb128: giving a try to bug #334378 http://pastebin.com/f4467e3aa
[16:38] <seb128> proppy: cool
[16:38] <proppy> seb128: recompiling gtk+ package, hope it is not duplicated work
[16:39] <seb128> not with me at least
[16:50] <asac> seb128: ffox source package is firefox-3.0 ;) firefox is the old one
[16:50] <seb128> asac: ok
[16:50] <seb128> asac: I'm surprised that you read bug emails ;-)
[16:50] <asac> seb128: hell i am reading 24/7 atm
[16:51] <asac> ;)
[16:51] <asac> my body already shivers
[16:56]  * pitti has 'nuff of them for today, too
[16:58] <proppy> seb128: rebuilt  libgtk2.0-0_2.16.1-0ubuntu3_i386.deb package and tested with gedit that it fixes the pb.
[16:59] <proppy> attached the diff to bug 334378
[16:59] <proppy> let me know if it needs more love :)
[16:59] <asac> is g_hash_table_foreach a macro or something?
[17:00] <asac> seems not. odd that it gets optimized away in a backtrace
[17:00] <proppy> maybe I should also attach the patch to the upstream (gnome) bug report ?
[17:00] <mvo> asac: I guess if the compiler knows its a empty set or something beforehand (or a single invocation)
[17:00] <seb128> proppy: could you add the diff upstream too?
[17:01] <asac> mvo: http://launchpadlibrarian.net/25841787/gdb-nm-connection-editor.txt
[17:01] <proppy> seb128: not the debdiff but the quilt patch, right ?
[17:01] <seb128> proppy: I doubt that will be sru-ed or worth an early karmic upload, having it in the next tarball will do
[17:01] <asac> look at #4
[17:01] <seb128> proppy: yes
[17:01] <asac> thats hash_table_foreach
[17:01] <seb128> gdb and -O2 builds suck
[17:02] <asac> yeah
[17:02] <mvo> asac: hrm, inlined
[17:02] <asac> mvo: hash_table_for_each is not a inline function
[17:02] <asac> i looked in the header
[17:03] <mvo> asac: the compiler probably thought differently in O2 :)
[17:03] <asac> inlining binary stuff from a .so?
[17:03] <asac> that would be neat ;)
[17:03] <asac> and its definitly _foreach because its an break because of
[17:04] <asac> GLib-CRITICAL **: g_hash_table_foreach: assertion `hash_table != NULL' failed
[17:05] <asac> anyway. i gues its just O2
[17:07] <proppy> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=579838 updated
[17:07] <seb128> proppy: thanks
[17:08] <proppy> woot this "Matthias Clasen" is lighting fast
[17:10] <proppy> oops he is here ( mclasen )
[17:17] <asac> so now all gnome has moved to git ... is there any bzr-git in sight?
[17:17] <asac> guess better ask in #bzr
[17:19] <calc> git is nice once you get used to it
[17:19] <calc> works a bit differently the than other SCMs i've used though
[17:21] <asac> calc: i know how to use git
[17:22] <asac> calc: just hoped i could use my bzr-buildpackage auto export feature still somehow
[17:22] <asac> for which i need a bzr upstream branch
[17:28] <calc> asac: ah
[17:29] <calc> asac: there is a git-buildpackage but i'm not sure if it would work in your setup
[17:29] <asac> that would mean migrating the packaging branches to git too
[17:29] <calc> oh :\
[18:17] <calc> rickspencer3: i should have an OOo 3.1.0rc2 build ready for when the karmic archive opens mid next week
[18:17] <calc> it comes out this friday then karmic opens somewhere between apr 27-30 most likely
[18:18] <rickspencer3> calc: cool
[18:18] <rickspencer3> what ppa is it in now?
[18:20] <calc> its not available yet due to some issues with the orig tarball i am working from
[18:20] <calc> it exploded in size due to a bug
[18:20] <calc> eg the debian orig.tar.gz is ~ 700MB currently :\
[18:20] <calc> i suppose i could go ahead and upload it anyway and just request LP to give me a couple extra GB of space in the ppa, heh
[18:21] <calc> it should be about half that size
[18:23] <calc> hmm actually i might have enough room currently, i'll have to see how it goes
[18:29] <kenvandine_wk> rickspencer3: the i965 wiki page... model means system model or video card model?
[18:32] <rickspencer3> kenvandine_wk: output of lspci -vvnn | grep -A2 "VGA "
[18:32] <kenvandine_wk> great
[18:32] <kenvandine_wk> which part of that?
[18:33] <rickspencer3> dunno
[18:33] <rickspencer3> that's what bryce asked for, so I guess all of it
[18:33] <rickspencer3> bryce? ^^
[18:34] <kenvandine_wk> that is to much to put in the table :)
[18:35] <lauris> hi
[18:35] <kenvandine_wk> [8086:29a2] (rev 02)
[18:35] <kenvandine_wk> i assume that
[18:35] <lauris> is there some kind of ubuntu archive with 7.10 packages available online ?
[18:37] <pitti> good night everyone, Taekwondo time
[18:38] <kenvandine_wk> good night pitti
[18:38] <kenvandine_wk> pitti: no web surfing during taekwondo :)
[18:40] <lauris> found it.
[21:43] <seb128> re
[21:44] <seb128> asac: gwibber is not really nice for beginner ;-)
[22:31] <asac> seb128: why?
[22:31] <asac> ;)
[22:32] <seb128> asac: I think I'm just too stupid to use it
[22:32] <seb128> I use the "create account", selected twitter, entered an username and password and I just get an error displayed
[22:32] <seb128> nothing in the UI, I'm not sure what is supposed to happen
[22:32] <asac> seb128: it doesnt have many features ;) ... just sending dents/tweets and reading
[22:33] <seb128> I though it was supposed to display something
[22:33] <seb128> similar to a planet with blog post or something ;-)
[22:33] <asac> seb128: if you are not subscribed anywhere, you dont see anything except your own tweet
[22:33] <seb128> I tried to do an ubuntu query which added a tab but nothing else
[22:33] <asac> seb128: try to follow me (asacasa)
[22:33] <asac> hmm
[22:33] <seb128> "HTTPError: HTTP Error 401: Unauthorized" I get too
[22:34] <seb128> is "create account" really create?
[22:34] <asac> seb128: is that latest gwibber?
[22:34] <asac> seb128: no.
[22:34] <seb128> or is it "add account" rather?
[22:34] <asac> seb128: its add account
[22:34] <asac> yeah
[22:34] <seb128> grrrr
[22:34] <seb128> sucky software
[22:34] <asac> seb128: go to http://identi.ca and setup an account ;)
[22:34] <asac> seb128: well. its new
[22:34] <seb128> why do they call create account something which is adding an existing account
[22:34] <asac> most users have accounts ;)
[22:34] <asac> thats a bug
[22:35] <seb128> what protocol do you recommend as interesting?
[22:35] <seb128> ie where should I read what users say about ubuntu?
[22:35] <seb128> identica? twitter?
[22:35] <seb128> I've no clue about all those new fancy websites
[22:37]  * seb128 kicks launchpad
[22:37] <seb128> when you enter a wrong component or something and go back it deletes what you typed
[22:38] <seb128> or is that my webbrowser?
[22:41] <dobey> seb128: there's an ubuntu group on identi.ca you can watch, that's pretty active. though it seems to be mostly people asking questions about various hardware support and features
[22:42] <jcastro> http://identi.ca/group/ubuntu
[22:42] <jcastro> there's an rss feed there seb128
[22:42] <seb128> why do I need an account to read those things?
[22:43] <jcastro> you don't on the web
[22:43] <seb128> in gwibber I mean
[22:43] <jcastro> but with a client app like gwibber you need to set it up that way
[22:43] <jcastro> there's like a million ways gwibber can improve with that stuff
[22:44] <dobey> doesn't gwibber do rss now too?
[22:44] <jcastro> yeah
[22:45] <dobey> so you can just subscribe to the rss feed in gwibber
[22:45] <dobey> instead of setting up an account and going through the identi.ca api to get it
[22:46] <jcastro> seb128: just sign up for an account so bugabundo can message you directly
[22:46]  * jcastro runs
[22:46] <dobey> haha
[22:46] <james_w> heh
[22:46] <seb128> jcastro: be careful, I might break banshee by mistake in karmic and be too busy to fix it later
[22:47] <jcastro> you can't stop the awesome
[22:48] <seb128> jcastro: I can stop the troll about CD space win though
[22:48] <seb128> jcastro: those blog post just made me have a look and see than banshee has NO USER DOCUMENTATION
[22:49] <seb128> jcastro: which is why it wins some megabytes over rhythmbox which has a manual translated in 11 languages
[22:49] <jcastro> wow
[22:49] <jcastro> I never noticed that for years until just now
[22:50] <seb128> banshee hates users apparently or something ;-)
[22:50] <jcastro> no, just freedom remember
[22:52] <seb128> jcastro: joke aside I was surprised too, but that sort of defeat the CD space argument some people have raised for banshee
[22:53] <asac> seb128: identi.ca
[22:53] <asac> seb128: you should read and write ;)
[22:54] <seb128> asac: let's see, I will start by reading, but that seems a high traffic media
[22:54] <seb128> small posts but a lot of those
[22:55] <asac> seb128: you can keep the group you follow small. also its not a problem if you miss dents. important stuff will be repeated
[22:55] <jcastro> seb128: think of yourself as a producer instead, for things like "Can someone confirm this bug?" or "looking for volunteers to test foo"
[22:55] <seb128> asac: I've been reading the backlog for the ubuntu group and it's not small ;-)
[22:56] <seb128> jcastro: I've #ubuntu-desktop for those ;-)
[22:56] <seb128> but good point
[22:56] <seb128> there might be other users which are not on IRC there ;-)
[22:56] <jcastro> it's just another medium, right
[23:06] <seb128> enough for today, see you tomorrow
[23:06] <seb128> good night eveybody
[23:06] <seb128> everybody