[09:41] <huats> morning everyone
[09:41] <huats> plop seb128
[09:41] <seb128> lut huats
[09:41] <Keybuk> seb128: a couple of bugs-of-the-day
[09:41] <Keybuk> telepathy-butterfly doesn't actually pass messages in either direction
[09:42] <Keybuk> evolution randomly sorts folders (since moving to sqlite, I've seen this)
[09:42] <seb128> Keybuk: randomly? it uses alphabetic order in a consistent way for me
[09:42] <Keybuk> seb128: the "default" sort order used to be imap order
[09:42] <Keybuk> which was arrival
[09:43] <Keybuk> now if you don't click any header, and use the default, they're basically random
[09:43] <seb128> ah you mean "randomly sort the message in a folder"
[09:43] <seb128> not the folders on the server
[09:44] <Keybuk> right, the messages in a folder
[09:45] <seb128> I would say that's not a bug
[09:45] <Keybuk> err?
[09:45] <Keybuk> it's a change in behaviour
[09:45] <seb128> the bug is rather than no sorting is selected by default
[09:45] <Keybuk> then what is this default sort _for_?
[09:45] <Keybuk> just about every mail client I've ever seen has a useful default sort order
[09:45] <Keybuk> evo had until last release
[09:46] <seb128> I agree with you, in fact I didn't notice because all my boxes sorted by date for ages
[09:46] <Keybuk> sorted by date sorts by the date header though
[09:47] <Keybuk> which is not the same as arrival time
[09:47] <Keybuk> if I sort by date, and someone's mail takes a day to arrive, it may appear above the end of the inbox
[09:47] <Keybuk> sorting by arrival (which was the previous behaviour) means it's always at the end
[09:56] <seb128_> Keybuk: it seems to be still sorting by arrival for me
[09:58] <Keybuk> scroll up?
[09:58] <Keybuk> I wiped my summary db and it still came back in random order
[09:58] <Keybuk> and checking the imap server, that's in expected order
[10:04] <Keybuk> seb128: https://chinstrap.ubuntu.com/~scott/wrongsort.png
[10:17] <seb128_> hum
[10:48] <huats> Keybuk: thanks for pointing the maintener change :)
[10:53] <Keybuk> huats: :-) not having a go, it's just a habit we're trying to rid everyone of
[10:53] <huats> I understand :)
[10:54] <huats> that is why I thank you (to help me to get the right habits)
[10:54] <huats> :)
[13:01] <lool> seb128: I think Recommends is a bit strong
[13:01] <lool> seb128: I'd rather suggest it and make sure we pull it by matters of meta packages
[13:02] <seb128> lool: that's basically the case now
[13:02] <lool> seb128: it is via gio only?
[13:04] <seb128> lool: yes
[13:05] <lool> I don't think the symbols deps allow that, but it would be nice to only pull shared-mime-info when the apps use the symbols related to mime types
[13:05] <lool> But for the general case, it's a bit too heavy to pull shared-mime-info for all glib use cases
[13:06] <davmor2> Why do I get different startup music on different systems?
[13:06] <seb128> lool: ok, so you would add recommends on shared-mime-info to every application using gio to do something using mimetype for example
[13:07] <seb128> davmor2: because you configured it differently?
[13:08] <lool> seb128: Yes; shared-mime-info itself isn't too small and pulls libxml2 which recommends xml-core which depends sgml-base
[13:08] <davmor2> seb128: No default install out of the box the all intel machine plays the old version and on my nvidia hw I get a new version which version should play on both installs?
[13:08] <lool> I'd expect libxml2 to end up on most systems, but less so shared-mime-info
[13:09] <seb128> lool: bah, I don't like that, having to figure what application use gio and add recommends on the same things all over the places for applications which don't use it but need it through gio looks suboptimal
[13:09] <seb128> davmor2: no clue about that, ask on #ubuntu-devel to themuso rather
[13:09] <lool> seb128: it's like gvfs
[13:10] <seb128> what gvfs recommends is lacking?
[13:10] <lool> seb128: All applications using gio benefit from gvfs
[13:10] <seb128> well, benefit, they work without it
[13:10] <lool> Someone could bug you that http://balh.pdf doesn't work in evince
[13:11] <seb128> evince doesn't work without shared-mime-info
[13:11] <seb128> it doesn't open a pdf since it doesn't detect the correct mimetype
[13:11] <seb128> so it's useless
[13:11] <lool> Yeah, it's worse with evince, it really needs the mime type check to succeed
[13:11] <lool> In fact I wonder whether it should try to parse application/octet-stream
[13:12] <seb128> sudo apt-get install evince should give you something which is working
[13:12] <seb128> and it doesn't right now
[13:12] <seb128> I would argue that's rc for debian ;-)
[13:13] <lool> I agree it needs to be fixed one way or the other, I just disagree with making a lib pull optional data which helps detecting mime type when it's 1% of it's abi
[13:14] <seb128> that's either that or we need to add recommends on shared-mime-info all over the place for things which don't need it directly
[13:14] <seb128> and that's what recommends are for, installing extra things which should be there on standard installations
[13:14] <seb128> people who really need minimal system can turn off recommends install
[13:15] <seb128> anyway that's somewhat a corner case on ubuntu since shared-mime-info should be installed for almost everybody, I'll not spend too much energy on that
[13:15] <seb128> I'll add an evince recommends on shared-mime-info in the next upload to close this bug
[13:16] <lool> Actually, I'd say this could be argued to be an evince bug; it's not only glib related
[13:16] <lool> it also checks MIME types supported by gdk-pixbufs
[13:17] <seb128> well, my point is that the gio api to detect mimetypes etc is useless without shared-mime-info
[13:17] <seb128> so glib is somewhat not totally functional in its standard debian installation
[13:18] <lool> It's returning a valid mime type, just not the best one
[13:18] <seb128> I would not call that a mimetype
[13:18] <lool> seb128: I think evince is actually buggy here
[13:19] <lool> It should use file name information when the mime type is octet-stream
[13:19] <seb128> it returns application/octet-stream which you don't need gio to set
[13:19] <lool> It has code to handle this case
[13:19] <seb128> right, but still an orthogonal issue imho
[13:19] <lool>         mime_type = slow ?
[13:19] <lool>                 get_mime_type_from_data (uri) :
[13:19] <lool>                 get_mime_type_from_uri (uri);
[13:19] <seb128> but it seems we will disagree on that
[13:20] <seb128> for me an api which is supposed to give you a mimetype and always return applications/octet-stream because the data used are not installed is not totally functional
[13:23] <lool> seb128: glib can tell evince whether the result is certain or not (result_uncertain param); evince chooses not to use it
[13:23] <lool> It also calls g_content_type_guess() without filename explicitely
[13:24] <seb128> lool: I don't disagree evince could to a better job but as said that's orthogonal
[13:24] <lool> seb128: Well it's very close to the gvfs example
[13:25] <seb128> I would expect the mimetype informations to be available when glib is installed to the gio api can be correctly used out of the box
[13:25] <seb128> not really, gvfs is like having a sound server, it's rather an environment thing
[13:25] <seb128> it'll give you extra possibilities
[13:26] <seb128> I would expect an api which returns a mimetype when you give it a filename to return a correct mimetype though
[13:26] <seb128> not to return a boggus one just because the mimetypes database is not installed, which is something probably not obvious for users who will run into the issue
[13:26] <lool> The gio API can be used out of the box; it just wont support any MIME type data unless you install some
[13:27] <seb128> right but it'll return bogus results
[13:27] <lool> Not really, it will tell you the results are bogus
[13:27] <seb128> and yes I consider application/octet-stream bogus when I ask a jpg mimetype
[13:28] <seb128> well, that will not tell the user why and what he has to do to fix that though
[13:29] <seb128> I'm not saying shared-mime-info is essential and should be a depends
[13:29] <seb128> but I think users will expect those informations to be available and that's what recommends are for usually
[13:30] <lool> seb128: evince could well work without the info
[13:30] <seb128> yes, not discussing that
[13:30] <lool> So what other use case in the archive to we have?
[13:31] <seb128> but as a library client, when writting "python -c "import gio; print gio.content_type_guess('example.pdf')"" I would expect the result to be application/pdf there
[13:31] <seb128> I'm taking the usecase "I'm a hacker and install libglib2.0-dev to hack on a software and I'm using debian"
[13:32] <seb128> and I expect the lib to work in full possibility and not in fallback mode because some database I don't know about didn't get installed
[13:33] <lool> seb128: I see the argument, but we tend to be overzealous with dependencies creating heavy dep trees
[13:34] <lool> We're talking about a fractional part of the API which is saying that it's not working to its best
[13:36] <lool> I'd be ok to have it as a Recommends or even Depends in the packages using this API, but I don't think that's possible with symbols right now
[13:36] <lool> If we add it as a Recommends, everybody pays the price
[13:37] <seb128> ok, I would tend to think that having things working at their best is what recommends are about
[13:37] <seb128> well, honestly on a modern box you want shared-mime-info installed, people who have such space constrains that they don't want it should probably not install recommends
[13:39] <lool> seb128: We should perhaps bring it up with upstream: should we push people into having this API working out of the box?
[13:42] <seb128> lool: I doubt upstream will recommend having their API not working correctly out of the box and they will probably tell that's a distributor choice
[13:42] <seb128> anyway that's a detail let's not spend hours on it
[13:42] <seb128> thanks for your opinion on that
[13:42] <seb128> I'll open an evince bug upstream and add the recommends there for now
[13:43] <lool> libglib2.0-0 is quite a central lib nowadays, i'm reluctant to add desktop-ish recommends to it  :-/
[13:45] <lool> seb128: I just ran germinate, this would effectively pull shared-mime-info into minimal
[13:46] <lool> shared-mime-info is in desktop, supported-misc-servers
[13:47] <lool> libglib2.0-0 is in supported, minimal
[13:49] <lool> seb128: That's quite a promotion, it would be added in virtual chroots and server installs
[13:51] <seb128> right
[13:51] <seb128> screw non GNOME users they deserve the bugs ;-)
[13:52] <seb128> anyway as said before that's a small issue
[13:59] <lool> seb128: I'm actually fighting /for/ non-GNOME users :)
[14:03] <lool> seb128: Turns out it might be possible to do it with symbols
[14:18] <mvo> seb128: bug #276728 looks like its partly a problem with gvfs (the fact that it thinks that there is a autorun part on the CD. what bit of gnome is reposnible for that?
[14:41] <seb128> mvo: nautilus
[14:42] <seb128> mvo: src/nautilus-autorun-software.c autorun() I would say
[14:43] <seb128> mvo: similar to http://bugzilla.gnome.org/show_bug.cgi?id=524270?
[15:21] <lool> seb128: I tried to add the deps to some functions, but the dependency tree of the funcs is crazy
[15:21] <lool> Because the way gfile is done, you can request content-type or not, it's just a flag
[15:21] <lool> So it's not possible to tell whether apps using the symbol are interested in the content-type or not
[15:22] <seb128> lool: ok, don't bother as said that's a detail and probably not worth the efforts
[15:22] <lool> And if I only add the dep for low level funcs, I'll have to add special machinery for glib itself which calls the functions, and wont cover all use cases
[15:22] <lool> So I could add the dep for the low level plumbing, but we'd have to handle it manually for the other cases, so I'd recommend adding it to the apps
[15:23] <seb128> alright
[15:24] <lool> But technically, we could add the dep for content_type_guess
[15:24] <lool> That would be possible
[15:25] <seb128> that's probably not worth it, you convinced me, applications should allow that nicely
[16:19] <seb128> everybody there do you think we should use the ubuntu-desktop (restricted) or desktop-bugs (open) bzr to store the list of desktop packages (names, serie for update, usual updater)?
[16:57] <crevette> hello seb128
[17:36] <Ng> is there any network monitoring in gvfs? I'm thinking of situations where you have a connection to an sftp server and change your network
[17:36] <Ng> in hardy it thinks the share is still mounted, it just doesn't work
[17:37] <Ng> we're using the sftp gvfs stuff really quite a bit now with our least technical users and there's a bunch of corner cases we have to train them to handle, such as that
[17:40] <Ng> (suggestions for a better way to have secure file sharing over the internet would be most welcome)
[17:59] <johanbr> Ng: sshfs fuse mounts time out after a few minutes if they're not available. Does gvfs not do that?
[18:00] <Ng> johanbr: I can't give a definitive answer to that, but my impression is not
[18:04] <johanbr> Ng: So maybe sshfs would work better for you?
[18:12] <Ng> johanbr: possibly, I am rather keen to try and keep things within the confines of the GUI though, since this is very specifically for non-technical users
[18:13] <johanbr> Ng: Put an icon on the desktop that runs a script to mount/unmount the share.
[18:25] <Ng> johanbr: that would just about do, yeah :)
[18:25] <Ng> johanbr: actually it would be nice if there was a real file sharing protocol suitable for use over the internets, but there isn't afaics
[18:25] <Ng> sshfs/sftp seem to have issues when it comes to stuff like locking
[18:26] <johanbr> If you're looking for something more full-featured, afs works nicely.
[18:26] <johanbr> Even if it's a bit of a pain to set up.
[18:30] <davmor2> gvfs does time out it just doesn't close the link on the desktop (i.e. there is still an icon saying it is linked)
[18:34] <Laney> Who has the power to confirm bugs on GNOME bugzilla? Some special class of triager?
[18:42] <pedro_> Laney: you need triager powers
[18:42]  * Laney nods
[18:43] <pedro_> Laney: moreover the difference between unconfirmed and new isn't that huge in gnome bugzilla
[18:43] <Laney> pedro_: Do developers tend to ignore unconfirmed bugs? I reported one which has since been confirmed several times over but it's still in the UNCONFIRMED state
[18:43] <pedro_> no they don't
[18:43] <Laney> ok
[19:40] <vuntz> where is seb128 when I need him? :-)
[20:29] <crevette> vuntz: I have its phone number if you really want to contact him
[20:29] <crevette> :)
[20:32] <Nafallo> vuntz: bathing, sort of.
[20:33] <Nafallo> ehrm. I have no idea in which window he said that...
[21:27] <mvo> tedg: g-p-m is acting funny on me: http://people.ubuntu.com/~mvo/tmp/g-p-m.png
[21:27] <mvo> (note the output of acpi below)
[21:33] <Nafallo> mvo: iz estimate damnit :-P
[21:33] <mvo> heh :)
[21:34] <mvo> and a good one too! it even has a "," in it, always a sign of precision :P
[21:35] <Nafallo> hehe
[21:43] <tedg> mvo: Have you updated to the latest package, that should have been fixed in the update.
[21:44] <mvo> tedg: I think I'm at ubuntu2 instead of ubuntu3
[21:44]  * mvo updates now
[21:45] <tedg> mvo: See, you're a day behind.  james_w was complaining about that yesterday ;)
[21:45] <mvo> ha! its just because I'm sick today (and yesterday) - that makes me slow :)