[10:09] <baptistemm> didrocks, around?
[13:00] <^arky^> hi anyone know the duplicate of this bug 510775
[13:01] <^arky^> Is seb128 around?
[13:26] <geser> like most other devs not on a weekend, try during the week
[14:32] <didrocks> baptistemm: there now
[14:33] <baptistemm> salut
[14:33] <didrocks> hello, bon dimanche ? :)
[14:34] <baptistemm> ouais je suis seul, ma copien et mon fils sont en vacances :)
[14:34] <baptistemm> donc je geek (pour une fois)
[14:34] <didrocks> héhé, ma copine est aussi partie pour quelques jours, un peu de temps libre :)
[14:34] <baptistemm> je pense que l'on va continuer en anglais :)
[14:34] <didrocks> yes ;)
[14:36] <baptistemm> I'm under the impression the cached image for background in the patch you produce in my case compressed image with compression artefact
[14:36] <baptistemm> s/you produce/you did produces/
[14:36] <baptistemm> where is stored the picture
[14:37] <didrocks> baptistemm: hum, strange. I only save the pixbuf produced by the lib
[14:37] <didrocks> baptistemm: .cache/wallpaper
[14:37] <baptistemm> okay perhaps I totally wrong
[14:37] <didrocks> baptistemm: I only save the cached image produce on the fly by libgnome-desktop if it was changed
[14:38] <didrocks> produced*
[14:38] <baptistemm> humm this is really noticable now
[14:38] <didrocks> and try to get the same format
[14:38] <baptistemm> let me put the two different pictures
[14:38] <didrocks> can you get me two screenshots?
[14:38] <didrocks> right :)
[14:38] <baptistemm> sure
[14:38] <baptistemm> If you want to look now of course
[14:39] <didrocks> baptistemm: I'll have a quick look, but treat it on Monday for sure
[14:39] <baptistemm> don't hesitate to tell me if you don't want to do that now
[14:40] <didrocks> no no, it's ok
[14:40] <didrocks> I think I have an idea
[14:40] <didrocks> is your file a jpeg?
[14:40] <baptistemm> yes
[14:40] <baptistemm> http://bmm80.free.fr/Ubuntu/
[14:41] <didrocks> hum, so, here is the code: http://paste.ubuntu.com/376204/
[14:41] <baptistemm> 26k vs 6k, sure this is compressed :)
[14:41] <didrocks> baptistemm: as you can see, I take the same format that the initial file
[14:41] <baptistemm> yeah
[14:41] <didrocks> and save the pixbuf
[14:41] <didrocks> so, for me
[14:42] <didrocks> it compress the pixbuf again :)
[14:42] <didrocks> that can explain this
[14:42] <didrocks> I have to get the format from the pixbuf
[14:43] <didrocks> (not sure if "format" is suited for a pixbuf"
[14:43] <didrocks> or use an non destructive format to save it
[14:44] <baptistemm> is it interesting to cache picture not bigger than the display resolution ?
[14:44] <didrocks> it's still interesting
[14:44] <baptistemm> I mean, my picture is the tiny one, that I use a tile wallpaper
[14:44] <baptistemm> okay
[14:44] <didrocks> just applying the transformation/resize take 0.7s on the mini
[14:44] <didrocks> with an ssd drive…
[14:45] <didrocks> and if you login into gdm, you get it twice (one for gdm, the other one once connected)
[14:45] <didrocks> do you think than saving in png systematically would be better?
[14:45] <didrocks> (not on the top for all image format)
[14:46] <baptistemm> my knowledge is near zero for that :)
[14:47] <baptistemm> actually I didn't understood where the pciture was compressed in you code
[14:47] <didrocks> baptistemm: gdk_pixbuf_save (new_pixbuf, cache_filename, gdk_pixbuf_format_get_name (format), NULL, NULL);
[14:47] <didrocks> format comming from: format = gdk_pixbuf_get_file_info (bg->filename, NULL, NULL);
[14:47] <baptistemm> ah you meant gdk_pixbuf_save do the compression
[14:48] <didrocks> so, if the original image is an jpeg, I apply jpeg compression on the gdk_pixbuf again
[14:48] <baptistemm> ah okay ...
[14:49] <didrocks> Currently only few parameters exist. JPEG images can be saved with a "quality" parameter; its value should be in the range [0,100].
[14:50] <didrocks> maybe put the quality to 100 for jpeg?
[14:50] <baptistemm> yep, I was thinking the same
[14:50] <baptistemm> or sometimes near, like 90 or 95
[14:51] <didrocks> the default value is not written into devhelp
[14:51] <didrocks> do you see something related to that?
[14:52] <baptistemm> no
[14:53] <didrocks> baptistemm: http://fr.wikipedia.org/wiki/Portable_Network_Graphics
[14:53] <didrocks> "sans perte de données"
[14:53] <didrocks> maybe saving all cached images in png can be interesting
[14:53] <didrocks> should have a look about the size
[14:54] <baptistemm> I found
[14:54] <baptistemm> this is 75
[14:54] <didrocks> baptistemm: where ? ;)
[14:54] <baptistemm> volatile int quality = 75; /* default; must be between 0 and 100 */
[14:54] <baptistemm> io-jpeg.c
[14:54] <didrocks> ok :)
[14:54] <baptistemm> in gdk-pixbuf directory in gtk
[14:55] <didrocks> I have no strong opinion tweaking the value if source == jpeg -> quality=…
[14:55] <baptistemm> yeah png would be perhaps interesting
[14:55] <didrocks> or saving everything in png
[14:55] <didrocks> (I have a png image, hence I noticed nothing ;))
[14:56] <baptistemm> (sorry to put you some challenge on weekend days :)
[14:56] <baptistemm> should I file a bug ?
[14:56] <didrocks> don't be sorry, my challenge is already to checkout launchpad :)
[14:56] <didrocks> no, that's ok, I'll fix this on Monday
[14:56] <baptistemm> checkout launchpad ???
[14:56] <baptistemm> wow
[14:57] <didrocks> and discuss with pitti and seb128 about the best solution
[14:57] <didrocks> yes, I need to extend the API for Quickly :)
[14:58] <baptistemm> okay, thanks for the help
[14:58] <baptistemm> if you have free time, I packaged devhelp 2.29.90 :)
[14:58] <didrocks> thanks for reporting that :)
[14:58] <baptistemm> it just waits for sponsoring
[14:58] <didrocks> oh, sweet, Will sponsor tomorrow
[14:59] <didrocks> (I try to not "really work" on week-end, I know this is not the right way to go ;))
[14:59] <didrocks> so, just hanging on IRC and hacking on personal projects
[15:08] <baptistemm> hey chrisccoulson
[15:08] <chrisccoulson> hey baptistemm
[15:33] <asac> baptistemm: hey
[15:33] <baptistemm> heya asaca
[15:33] <asac> baptistemm: so your issue means we need to bump the soname i think
[15:34] <asac> +#MISSING: 4.61-0ubuntu1# hci_read_inquiry_transmit_power_level@Base 4.40
[15:34] <baptistemm> yeah ;/
[15:34] <asac> did upstream bump the soname?
[15:34] <baptistemm> no
[15:34] <baptistemm> I asked on the bluez chan but noone answered
[15:34] <asac> ask on #bluez then
[15:34] <asac> ping holtman directly maybe?
[15:35] <asac> and wait a day or so ... we shouldnt upload until this is confirmed upstream and they will bump their soname
[15:35] <baptistemm> I did both
[15:35] <baptistemm> yeah
[15:35] <asac> ok
[15:35] <baptistemm> asac, if you want there is the previous release which was never uploaded :)
[15:35] <asac> if that doesnt have the issue, go ahead
[15:37] <baptistemm> I can't upload myself :)
[15:37] <asac> baptistemm: oh you say ther eis a previous release which was never sponsored?
[15:37] <asac> give it to me
[15:37] <asac> where is the debdiff + orig?
[15:38] <baptistemm> attached to a bug report, I'll give you that in a second
[15:38] <asac> kk
[15:38] <baptistemm> bug 506149
[15:39] <asac> hmm. you never attach debdiffs?
[15:41] <baptistemm> did I
[15:41] <baptistemm> ah no, I usually don't
[15:42] <baptistemm> but I can, give me 2 minutes
[15:43] <asac> no not needed
[15:43] <asac> its just that i had to act for 2 minutes to get all the bits together
[15:43] <asac> if everything is in the bug it will take me 10 seconds ;)
[15:44] <asac> baptistemm: you tested that ?
[15:44] <baptistemm> the previous version was 4.51 so the debdiff can be lengthy
[15:44] <asac> 3
[15:44] <asac> 2
[15:44] <asac> 1
[15:44] <asac> hmmm
[15:44] <asac> did you test the release? ... or do i need to test build?
[15:44] <asac> the debdiff looks good ;)
[15:45] <baptistemm> you can test it, I did some file copy but not that much
[15:45] <asac> did you test it in the sense that it builds and installs?
[15:45] <baptistemm> ha yeah, I have it installed for weeks
[15:45] <baptistemm> :)
[15:45] <asac> ok uploading/ed
[15:45] <asac> thx
[15:46]  * asac goes back to weekend fun ;)
[15:46] <baptistemm> wonderful
[15:46] <baptistemm> thanks then
[15:46] <baptistemm> have fun
[15:46] <asac> np... enjoy too (will be back in a couple of hours or so)
[15:49] <chrisccoulson> bah, my filesystem keeps eating itself
[16:55] <Amaranth> chrisccoulson: you should feed it more often
[16:55] <chrisccoulson> hey Amaranth
[16:55] <chrisccoulson> yeah, probably ;)
[16:55] <Amaranth> howdy
[16:56] <chrisccoulson> how are you these days?
[17:31] <Amaranth> chrisccoulson: busy :)
[17:45] <Lee_ubun> I'm having problems with unexpected logouts, I believe its a graphic issue. Running 9.10 - Graphic Card is: 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Devi. Can anyone help?
[17:46] <kklimonda> hmm, is this bootchart hacked or not: http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100212-4.png ?
[17:48] <chrisccoulson> kklimonda, no, how come?
[17:49] <chrisccoulson> that's actually slower than the quickest bootchart on that hardware
[17:49] <chrisccoulson> i think it's been down to just over 10s
[17:50] <kklimonda> chrisccoulson, sweet
[17:50] <kklimonda> chrisccoulson, I remember that pitti has been hacking a lot of things lately so I wasn't sure about it and the official bootcharts are broken :/
[19:38] <asac> pitti: guess your not there? what was the new langpack machine name?
[19:57] <baptistemm> asac, some advice to fix 519357?
[19:57] <baptistemm> bug 519357
[19:57] <asac> hmm
[19:59] <asac> baptistemm: are we doing anything to the conffiles in maintainer scripts?
[19:59] <asac> e.g. to init.d/bluetooth
[20:00] <baptistemm> we touched it between the two release
[20:00] <baptistemm> +s
[20:01] <baptistemm> IIRC, initially init.d/bluetooth was a traditionnal init script, and now bluetoothd is triggered by udev
[20:02] <baptistemm> /lib/udev/rules.d/97-bluetooth.rules
[20:22] <asac> baptistemm: whats the diff of the packaging that does that touching?
[20:43] <baptistemm> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/bluez/karmic/revision/28
[20:43] <baptistemm> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/bluez/karmic/revision/29
[20:43] <baptistemm> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/bluez/karmic/revision/30
[21:15] <asac> in general it shouldnt be a problem if you change config files during upgrade
[21:16] <asac> as long as you dont touch them outside of the upgrade process
[21:16] <asac> so this bug basically means that something touched the conffile for mvo
[21:16] <asac> maybe there is upstart magic now that does something bad?
[21:18] <asac> seems to be ok
[21:18] <asac> i think we have to wait for mvo to tell us more about his testcase
[21:24] <baptistemm> yeah
[21:33] <chrisccoulson> james_w - i had a quick look at the gnome-desktop issue. the second code path that can cause gnome_rr_config_apply_from_filename_with_time to return false without setting the GError is:
[21:34] <chrisccoulson> if (check_framebuffer_size (stored, screen)) {
[21:34] <chrisccoulson> if that evaluates to false there, then the funtion returns false and doesn't set the error
[21:35] <james_w> so it needs another g_set_error?
[21:36] <chrisccoulson> james_w - yeah. i have a fix for the second one somewhere here already
[21:36] <chrisccoulson> i can roll them all in to one change and push to bzr if you like
[21:36] <james_w> that would be great
[21:37] <chrisccoulson> cool, i'll do that now