[08:27] <huats> morning everyone
[08:33] <huats> hello crevette
[08:33] <crevette> salut huats
[09:30] <pochu> seb128: vino done
[09:31] <seb128> pochu: right, I've nothing it got uploaded, probably thanks to dholbach who did some sponsoring ;-)
[09:31] <pochu> yeah :)
[09:39] <seb128> mvo:
[09:39] <seb128> $ gnome-keyboard-properties
[09:39] <seb128> (gnome-keyboard-properties:14180): GLib-GObject-WARNING **: invalid (NULL) pointer instance
[09:39] <seb128> (gnome-keyboard-properties:14180): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed
[09:39] <seb128> mvo: those warnings were not there before you update
[09:40] <seb128> mvo: I get them when starting gnome-keyboard-properties
[09:40] <mvo> seb128: hrm, I don't get those
[09:41] <mvo> seb128: could you please give me your gconf keyboard settings? I will try to reproduce
[09:42] <seb128> mvo: http://people.ubuntu.com/~seb128/gconf.log
[09:43] <seb128> mvo: the stacktrace
[09:43] <seb128> #5  0xb7ac1838 in IA__g_type_check_instance (type_instance=0x0) at /build/buildd/glib2.0-2.18.0/gobject/gtype.c:3814
[09:43] <seb128> #6  0xb7abc559 in IA__g_signal_connect_data (instance=0x0, detailed_signal=0x805a9e1 "clicked",
[09:43] <seb128>     c_handler=0x8051bd0 <make_default>, data=0x88d1a00, destroy_data=0, connect_flags=0)
[09:43] <seb128>     at /build/buildd/glib2.0-2.18.0/gobject/gsignal.c:2235
[09:43] <seb128> #7  0x08051a1f in setup_xkb_tabs (dialog=0x88d1a00, changeset=0x0) at gnome-keyboard-properties-xkb.c:319
[09:50] <seb128> mvo: frame 7 is
[09:50] <seb128> 319		g_signal_connect (G_OBJECT (WID ("button_make_default")),
[09:51] <mvo> seb128: thanks, I have it here now too
[09:52] <seb128> mvo: ok, my fault, I've fixed it :-p
[09:52] <mvo> oh?
[09:52] <seb128> mvo: I did apt-get install gnome-control-center to try the new version but that didn't upgrade capplets-data which has the required glade changes
[09:53] <mvo> right, that sounds like a bad dependency
[09:53]  * mvo fixes in bzr
[09:54] <mvo> seb128: hm, currently the dependency on capplet-data is gnome:version
[09:55] <mvo> seb128: is there a risk in making it binary:version ?
[09:55] <seb128> mvo: I guess it's really a corner case, don't bother
[09:55]  * mvo nods
[09:55] <mvo> seb128: can you make it crask after the update?
[09:55] <seb128> mvo: the issue is that strict versionning between arch all and any breaks installability on !i386
[09:55] <mvo> right
[09:56] <seb128> mvo: no, but I think it's due to tjaalton changes, maybe partial upgrade there too, ie the new xbd-data not installed or something
[10:24] <mvo> seb128: I keep an eye on the issue, I just found and fixed one crash, but it does not really match the signature of the other bugreport. I will keep looking
[10:24] <seb128> mvo: ok
[10:24] <seb128> mvo: thanks
[10:25] <andreasn> seb128: are you in charge of the rhythmbox package?
[10:26] <seb128> andreasn: yes
[10:26] <andreasn> seb128: I just realized why the icon looks like crap in the Applications menu
[10:27] <andreasn> it lacks a 24x24 size in icons/hicolor
[10:29] <andreasn> ah, same thing upstream it seems
[10:30] <andreasn> if I sent you a 24x24 icon, could you fix it? I want to submit it upstream as well, but maybe it's too late
[10:30] <pochu> seb128: bug 268470, I guess it needs a feature freeze exception
[10:30] <pochu> soren: ^
[10:31] <seb128> pochu: no, it's a GNOME requirement so it should be alright
[10:32] <pochu> great :)
[10:32] <seb128> andreasn: that should be fixed in the svn snapshot I uploaded to intrepid yesterday?
[10:32] <andreasn> oh, cool
[10:33] <andreasn> I tested the latest Alpha of Ubuntu, but if it's fixed already I can sleep calmly at nights again :(
[10:33] <andreasn> :) I mean
[10:59] <pochu> brb
[11:18] <pochu> hmm, vinagre + scaling doesn't work here
[11:19] <pochu> (vinagre:31774): GdkGLExt-WARNING **: Window system doesn't support OpenGL.
[11:19] <pochu> err
[11:19] <pochu> glxgears doesn't either!
[11:20] <pochu> Xlib:  extension "GLX" missing on display ":0.0".
[11:20] <pochu> heh, glxinfo segfaults
[11:20] <pochu> tjaalton: ^ this is an intel GMA 965, any idea?
[11:21] <seb128> pochu: do you have some nvidia-*177 installed?
[11:21] <seb128> pochu: sudo apt-get remove nvidia-glx-177
[11:22] <pochu> seb128: yeah, that's installed. removing it, thanks
[11:22] <tjaalton> pochu: right, broken nvidia-kernel-common upload which pulled nvidia-glx..
[11:22] <pochu> so no need to report it, I guess :)
[11:23] <pochu> brb
[11:23] <pochu> thanks folks
[11:24] <seb128> pochu: you're welcome
[11:25] <pochu> yay, scaling rocks!
[11:25] <pochu> but it doesn't work with compositing...
[11:25] <pochu> "Scaling does not work properly on composited windows. Disable the visual effects and try again."
[11:31] <pochu> seb128: bug 268484
[11:31] <seb128> pochu: cool thanks
[11:33] <pochu> seb128: no problem!
[12:03] <glatzor> mvo, there is currently some discussion about a software online repo at #PackageKit
[12:03] <glatzor> mvo, perhaps we could finally target something for 9.04
[12:03] <glatzor> mvo, hughsie will try to get some more information from the redhat guys about the amber project
[12:21] <_8472> Hi, is there any chance to enable in Gnome this kind of METACITY setting "automatically give focus to newly created windows" ? I'm already searching for it for some time, but still no success. Always have found similar answer, it's not in Gnome ....... , but i don't like this answer. thx in advance
[13:00] <lool> seb128: poppler 0.8.7-1 is in incoming or so
[13:00] <seb128> lool: right I noticed, will sync it thanks
[14:54] <glatzor> mpt, hello.
[14:55] <glatzor> mpt, you did some work on specifing the maintenace level of a package. Could you please point me to the wiki page?
[14:55] <glatzor> mpt, I would like to get this into packagekit too, but cannot find the page anymore
[14:56] <mpt> glatzor, sure, https://wiki.ubuntu.com/PackageMaintainednessPresentation
[14:57] <glatzor> mpt, great!
[14:57] <glatzor> mpt, have you found any time recently to work on your package management idea?
[14:58] <mpt> glatzor, it's not on my to-do list at the moment, but I'm quite hopeful it will be for the Jackalope
[14:58] <glatzor> mpt, RedHat and Novell are both working on an online software catalog.
[14:59] <mpt> muahahaha
[14:59] <glatzor> mpt, I would like to get this finally for Debian and Ubuntu
[15:00] <glatzor> mpt, AFAIK they plan to make use of the packagekit browser plugin to allow to easily install, remove or run the software
[15:00] <glatzor> (RedHat)
[15:03] <lool> Hey can you people still mount USB keys?
[15:03] <lool> I just tried a regular one with vfat and it wouldn't mount in nautilus
[15:04] <glatzor> mpt, http://benjiweber.co.uk/blog/?p=10
[15:05] <glatzor> mpt, there are screenshots from the novell thing. but they use a java application :(
[15:05] <glatzor> mpt, http://blogs.gnome.org/hughsie/2008/09/09/packagekit-web-plugin/
[15:06] <glatzor> mpt, here is a screenshot of the packagekit plugin.
[15:07] <mpt> a Java application powering a Web site, no less
[15:08] <mpt> oh, the packagekit one is a Web site too
[15:13] <glatzor> mpt, the screenshot is just a demo of the plugin. the project of Redhat is called amber.
[15:13] <glatzor> mpt, perhaps I can setup a local server soon
[15:15] <mpt> glatzor, plug-in for what?
[15:16] <james_w> Hey all. What sets XDG_SESSION_COOKIE?
[15:17] <james_w> some users are seeing problems when it is not available over an "ssh -X" connection
[15:18] <glatzor> mpt, the packagekit web plugin is  the small white box that you can see on the screenshots
[15:18] <glatzor> mpt, it allows to interact with the local package manager.
[15:19] <mpt> I don't understand why it's a Web site in the first place
[15:19] <glatzor> mpt, it represents the installation status and allow to install, run or remove an application
[15:19] <glatzor> mpt, because you make use of non-static and large data
[15:19] <mpt> so?
[15:19] <glatzor> mpt, only think of screenshots
[15:19] <mpt> Web browsers aren't the only programs that can do HTTP.
[15:20] <glatzor> mpt, sure there is still wget :)
[15:20] <mpt> Putting it in a Web browser just makes it half as efficient and offers 100 more wrong things to click.
[15:21] <glatzor> mpt, but how do you want to communicate the requirement to be "online" in a better way?
[15:23] <mpt> With a message, inside the package manager, asking you to either connect to the Internet or insert an appropriate disc
[15:24] <glatzor> mpt, sorry, I have to leave. My break is over. and the patients are waiting for their medicine. see you!
[15:24] <mpt> ok :-)
[15:24] <mpt> (glatzor's a doctor?)
[15:42] <tedg> lool: Worked for me a couple weeks ago...
[15:42] <lool> Yeah for me too
[15:43] <tedg> james_w: It's a cookie to keep track of individual sessions.  It's used by stuff like policykit and consolekit.  I would imagine that it wouldn't work over an ssh connection anyway as DBus is not being routed across that session.
[15:44] <james_w> tedg: yeah, this is consolekit
[15:44] <tedg> james_w: Probably an app bug that it doesn't work gracefully without having it.
[15:45] <james_w> bug 231246
[15:59] <lool> tedg, seb128 call
[15:59] <tedg> lool: There
[16:00] <lool> MacSlow: too
[16:00] <seb128> lool: yeah, I was just going to call ;-)
[16:00] <seb128> lool: I didn't know you were joining, good ;-)
[16:00]  * MacSlow is in 
[16:01] <tedg> james_w: I guess perhaps the admin tools shouldn't require the local console?  Seems, at least in the LTSP case, that shouldn't be required.
[16:01] <james_w> tedg: yeah, I'm not sure if this is the actual problem, or just a red-herring
[16:04] <MacSlow> lool, tedg, seb128: also maybe join #advisoryboard on irc.gimp.org
[16:41] <gicmo> seb128: gvfs-trashd is seriously FUBAR
[16:41] <seb128> gicmo: indeed
[16:41] <seb128> gicmo: we have over 60 crash duplicates now in launchpad
[16:42] <gicmo> seb128: ok, I really need to look at this
[16:43] <gicmo> seb128: can you point me at one?
[16:43] <gicmo> I mean bug report in lp
[16:43] <seb128> gicmo: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/252174
[16:43] <gicmo>  wtf, in g_main_context_dispatch?!
[16:44] <seb128> gicmo: the top of the stacktrace is missing and I didn't manage to know why, we already talked about that
[16:44] <seb128> gicmo: see http://bugzilla.gnome.org/show_bug.cgi?id=547568 which could be the same issue
[16:45] <gicmo> seb128: Ill see what I can do
[16:45] <seb128> gicmo: http://bugzilla.gnome.org/show_bug.cgi?id=547726 too
[16:45] <seb128> gicmo: valgrind has a "==28416== Jump to the invalid address stated on the next line" error
[16:47] <gicmo> wtf is trash doing that others dont
[16:48] <gicmo> I mean its only trash, crashing all the fucking time
[16:48] <gicmo> and hadess branched gvfs without asking me
[16:48] <gicmo> to commit his stupid cd text xattr patch
[16:48] <gicmo> super duper
[16:50] <gicmo> seb128: you remember when did this start?
[16:50] <seb128> gicmo: the version where the monitors have been splitted
[16:52] <gicmo> oh, who'd guessed that now ;-)
[17:05] <gicmo> seb128: yo
[17:06] <gicmo> seb128: soo, walters told me, and he is right, it looks like its doing dbus stuff from different threads
[17:07] <seb128> gicmo: oh
[17:07] <gicmo> in do_mount
[17:07] <seb128> gicmo: read http://bugzilla.gnome.org/show_bug.cgi?id=551337 on that topic
[17:13] <gicmo> seb128: so, we call enumerate_root_trashdir () in the trash backend on a second thread
[17:13] <gicmo> which causes g_daemon_vfs_init () to be called
[17:13] <gicmo> http://launchpadlibrarian.net/16686194/stacktrace-gvfsd-trash.log
[17:13] <gicmo> see #11 0x00007f398b088f50 in g_daemon_vfs_init (vfs=0x227cf20)
[17:13] <gicmo> which then loads the proxy monitors
[17:14] <gicmo> and dbus stuff etc
[17:14] <gicmo> seb128: <davidz> gicmo: does this crash happen with GIO_USE_VFS=local ?
[17:14] <gicmo> seb128: maybe we can start the gvfsd-thrash daemon with  GIO_USE_VFS=local  and see if it goes away
[17:15] <gicmo> can we reproduce that reliable?
[17:15] <seb128> gicmo: ugly workaround?
[17:15] <gicmo> seb128: just trying to find out if that is the cause at all
[17:15] <seb128> gicmo: no, it happens randomly once a day or something
[17:15] <gicmo> teh suck
[17:15] <gicmo> its prolly a race
[17:15] <seb128> gicmo: but your "don't use dbus in different threads" seems a good explanation
[17:16] <seb128> gicmo: did you read the bug I just pointed?
[17:16] <seb128> gicmo: in fact that's an another issue
[17:17] <gicmo> seb128: its another one, but quite interesting as well
[17:21] <gicmo> trashdir = 0x227f930 "/home/username/.local/share/Trash"
[17:21] <gicmo>  	topdir = 0x2283620 "/home/username/.local/share"
[17:21] <gicmo> wtf
[17:21] <gicmo> who calls himself username?
[17:22] <walters> i wonder if launchpad automatically replaces /home/<whatever>/ with username
[17:22] <seb128> ;-)
[17:22] <seb128> walters: no
[17:23] <gicmo> walters: that be nice though
[17:23] <seb128> right
[17:23] <walters> yeah, would make sense for privacy
[17:23] <gicmo> walters: so, I guess its crashing at   vfs->async_bus = dbus_bus_get_private (DBUS_BUS_SESSION, NULL);
[17:24] <gicmo> which we call on thread 2
[17:24] <gicmo> I am pretty sure that we already called dbus_bus_get on thread 1 before because we already have talked to the daemon over dbus
[17:24] <gicmo> walters: any idea if that is illegal?
[17:25] <walters> what i would say is that all code should have a good idea of what thread it is going to run on
[17:25] <walters> if code was intended to be run from the main thread it's going to be a problem
[17:26] <walters> just calling dbus_bus_get_private from a thread should be OK; it will hand you back a new connection and that should be safe
[17:27] <gicmo> hmm
[17:28] <gicmo> then maybe the dbus code that gets pulled in froom the volume proxy monitors the the clurprt
[17:28] <gicmo> curlprit
[17:36] <seb128> gicmo: any informations which would be useful to provide?
[17:42] <pochu> 18:22 <   walters> i wonder if launchpad automatically replaces /home/<whatever>/ with username
[17:42] <pochu> that's done by apport, bug 192786
[17:44] <walters> makes sense
[17:44] <pochu> the bug report is funny, btw :)
[17:45] <walters> yeah, totem is definitely a source of amusing bug reports
[17:46] <walters> one thought i had on this is to simply make bug reports non-public by default; i.e. you have to have an account on the system to access them
[17:46] <walters> that at least somewhat mitigates the slashdot effect
[17:46] <walters> s/bug report/stack traces/ i mean
[17:48] <pochu> crashes are private until someone with access to them marks them as public
[17:48] <walters> ah, ok
[17:48] <pochu> is it just my keyboard or keyboard shortcuts are case-sensitive?
[17:58] <gicmo> seb128:well trying to run the daemon with GIO_USE_VOLUME_MONITOR=unix and see if that helps could be of use
[17:58] <gicmo> but oh well
[18:01] <seb128> gicmo: is that going to provide useful informations?
[18:01] <seb128> gicmo: I can do that, but if that turns to workaround the bug what do we do next? ;-)
[18:01] <gicmo> walters:
[18:02] <gicmo> hmm might it be that its _g_dbus_connection_integrate_with_main () being called from the thread oder something
[18:02] <gicmo> I am just blindly guessing here
[18:03] <walters> gicmo: that sounds very likely to break
[18:04] <gicmo> also, using mainloop integration causes stuff to be dispached from the mainloop (thread 1), right?
[18:10] <gicmo> the proxy monitors also do a dbus_connection_send_with_reply_and_block ()
[18:10] <gicmo> which will happen on thread 2
[18:10] <gicmo> we call IsSupported () on org.gtk.Private.RemoteVolumeMonitor
[18:13] <seb128> gicmo: maybe take that discussion on #gnome-hackers?
[18:13] <seb128> gicmo: higher change to have people jumping in there ;-)
[18:14] <gicmo> well, I am pretty sure doing dbus_connection_send_with_reply_and_block () on a second thread is kinda bad
[18:16] <gicmo> easiest fix would be to force gvfs/gio being initilized from the main thread
[18:31] <seb128> gicmo: could be worth to discussing in with davidz anyway, since he did some of the changes he might be wanting to fix it too ;-)
[19:04] <directhex> nice job on that pidgin/empathy usability report
[20:11] <crevette> hello
[20:14] <crevette>  I have an error with packageKit ppa, should I report it upstream or on lp ?
[20:17] <pochu> hi crevette!
[20:17] <pochu> crevette: if it's with the ppa, report it to glatzor
[20:18] <crevette> hey pochu
[20:19] <james_w> crevette: hey, if you jump in #packagekit then I can have a look for you
[20:19] <crevette> let's jump
[21:47] <mvo> james_w: seb128 had this idea about bzr-buildpackage --upload that would automatically add a tag to the upload and do a dput, what do you think? is that something worth adding a whishlist bug for bzr-buildpackage?
[21:47]  * mvo likes the idea
[21:48] <james_w> mvo: yeah, it's something that I would like to do
[21:48] <mvo> is lack of time the problem?
[21:48] <james_w> however, I haven't thought through how to handle dput/dupload, multiple hosts, extra options, etc.
[21:48] <james_w> not so much
[21:49] <james_w> it's not high priority for this cycle, but I will have time to do it for the next one
[21:49] <james_w> it's more a lack of experience, as I hardly ever upload, and when I do it's very basic
[21:50] <mvo> then seb128 is the right person, he uploads a lot :)
[21:50] <seb128> ah ah
[21:50] <mvo> *A LOT*
[21:50] <james_w> :-)
[21:50] <seb128> mvo: I upload often but don't use bzr when you don't make me do it ;-)
[21:50] <mvo> you will like it someday :P
[21:51] <seb128> the thing just hate me
[21:51] <seb128> every time an upload should take 10 seconds it takes 10 minutes ;-)
[21:53] <seb128> mvo: joke aside this one was alright but I think I'll not like the extra steps to edit patches
[21:53] <james_w> which extra steps?
[21:53] <seb128> james_w: there is only the debian directory in bzr, how do I use cdbs-edit-patches?
[21:54] <mvo> yeah, that is something that is currently not ideal
[21:54] <mvo> I would love to have bzr-edit-patch or somesuch that exports the tarball, runs cdbs-edit-aptch (or dpatch-edit-patch or quilt) in there and on exit adds the patch to bzr
[21:55] <mvo> and auto detectin of --merge and --native would rock!
[21:56] <mvo> (well, bzr-buildpackage rocks already, but that would make it rock even more)
[21:56] <james_w> "bzr bd-do 'dpatch-edit-patch 01-foo'"
[21:57] <james_w> "bzr bd-do" to get a shell to do whatever you want
[21:57] <james_w> you need to "bzr add" afterwards, I haven't decided if that should be automatic yet
[21:58] <james_w> the name is completely non-obvious as well
[21:58] <mvo> oh, nice
[21:58]  * mvo hugs james_w
[21:58] <james_w> it's just cribbed from svn-buildpackage
[21:59] <james_w> I'm not a fan of debian-only though, the branches I create will be full source
[21:59] <seb128> bzr: ERROR: unknown command "bd-do"
[21:59]  * mvo needs to go to bed
[21:59] <NCommander> seb128, I'm testing gtkmm now
[22:00]  * seb128 installs bzr-buildpackage
[22:00] <seb128> NCommander: 2.13.8? ;-)
[22:00] <james_w> ah :-)
[22:00] <NCommander> seb128, ARGH
[22:00]  * NCommander swears
[22:00] <seb128> NCommander: new pangomm too
[22:00]  * NCommander twitches
[22:00] <NCommander> You just like inflicting pain on me
[22:01] <seb128> james_w: cool, that works, thanks for the hint ;-)
[22:01] <NCommander> seb128, rolling them now
[22:01] <NCommander> seb128, please commit them for me onto pkg-gnome once I roll the changeset
[22:02] <seb128> NCommander: oh, you like to complain apparently, http://download.gnome.org/sources/libgweather/2.23/libgweather-2.23.92.tar.gz for you
[22:02] <crevette> hey
[22:02] <NCommander> seb128, :-P!
[22:02] <seb128> NCommander: they added python binding and it's using cdbs *g*
[22:02] <NCommander> I'm rolling gtkmm now
[22:02] <NCommander> ....
[22:02] <NCommander> You'll get gtkmm and pangomm from me for now :-P
[22:02] <seb128> ;-)
[22:02] <seb128> lut crevette
[22:02] <james_w> seb128: no problem, glad it didn't hate you :-)
[22:03] <crevette> hey seb128
[22:03] <crevette> seb128: is it too late to upgrade nemiver to latest version, we're still in 0.5.2
[22:03] <seb128> NCommander: those updates are no good for debian yet, they don't have cairo 1.7 and gtk 2.14
[22:04] <NCommander> Ok
[22:04] <NCommander> I thought gtk at the very least was in experimental
[22:04] <seb128> crevette: version are frozen
[22:04] <seb128> NCommander: no
[22:04] <NCommander> seb128, building gtkmm now
[22:04] <crevette> I seen bluez-gnome is old too
[22:04] <seb128> crevette: you need to ask for a freeze exception, should be easy to get
[22:05] <crevette> okay
[22:05] <crevette> don't have much time now, we'll see this week end
[22:05] <NCommander> seb128, will you commit pangomm for me?
[22:05] <seb128> NCommander: where?
[22:05] <NCommander> seb128, 127.0.0.1, it will go to my PPA if it builds
[22:05] <seb128> NCommander: debian can't update, the new version requires a new pango which requires a new cairo
[22:05] <NCommander> seb128, Oh!
[22:06]  * NCommander hasn't even looked at the build-deps for pangomm yet
[22:06] <pochu> seb128: don't you handle freeze exceptions for GNOME packages in universe? ;)
[22:06] <seb128> pochu: that's not a GNOME packages, that's a random GNOMish application, can't handle every of those
[22:07] <pochu> oh, ok
[22:07] <seb128> pochu: you are welcome to ask for the freeze exception though ;-)
[22:07] <NCommander> seb128, gtkmm still needs to be updated in Debian once all its build-deps are in place
[22:07] <pochu> you could just ack it ;)
[22:08] <seb128> pochu: I'm not in the corresponding motu team to do that
[22:08] <seb128> pochu: and GNOME packages don't need freeze exception btw since GNOME has a standing exception ;-)
[22:11] <NCommander> seb128, rolled pangomm, testing now
[22:13] <pochu> seb128: I'm referring to this mail, in which the MOTU council delegates the power of ack'ing feature freeze requests for GNOME packages to you: https://lists.ubuntu.com/archives/ubuntu-motu/2008-September/004648.html
[22:13] <NCommander> seb128, /usr/share/gnome-pkg-tools/1/rules/check-dist.mk:19: Unknown distribution: intrepid
[22:13] <NCommander> Is that a gnome bug?
[22:13] <NCommander> er, known
[22:13] <seb128> pochu: ah, they did that again this cycle ;-)
[22:13] <pochu> :)
[22:13] <seb128> NCommander: that's a debian thing to not upload experimental packages to unstable, you can ignore it on ubuntu
[22:14] <NCommander> seb128, I was just not sure if I just never noticed it before, or if it was new since my reinstall
[22:14] <NCommander> seb128, pangomm builds and installs fine, on its way to my PPA
[22:14] <seb128> pochu: ok, if you try a debian update and it builds fine I can do syncs for you
[22:14] <seb128> NCommander: good
[22:14] <seb128> NCommander: you didn't notice before
[22:16] <NCommander> seb128, pangomm installs in a chroot, but since the updated gtkmm isn't available just yet, it won't install on a production system since gtkmm has rdepends
[22:16] <NCommander> (attempting to deconfigure gtkmm, unable because gnome-*)
[22:16] <seb128> right
[22:16] <NCommander> I'm just waiting for gtkmm's new version to finish building
[22:16] <seb128> I doubt the pangomm will break things and there is no such much using gtkmm anyway
[22:25] <NCommander> seb128, gtkmm builds fine
[22:27] <seb128> NCommander: good, so it's sponsoring time ;-)
[22:27] <NCommander> seb128, they're both in my PPA
[22:28] <NCommander> Launchpad is crawling for me
[22:29] <NCommander> seb128, https://edge.launchpad.net/~sonicmctails/+archive
[22:30] <seb128> NCommander: btw gtkmm also has a new version
[22:31] <NCommander> seb128, I uploaded the new version
[22:31] <NCommander> seb128, it just hasn't popped up yet
[22:31] <NCommander> (I rolled both pangomm and gtkmm)
[22:31] <seb128> excellent ;-)
[22:31] <NCommander> See, I do amazing work sometimes
[22:31] <NCommander> seb128, pangomm built on all PPA archs, gtkmm hasn't shown up yet -_-;
[22:32] <NCommander> uh oh
[22:32] <NCommander> Rejected: dm:manphiz@gmail.com may not upload/NMU source package pangomm
[22:32] <NCommander> WTF O_o;
[22:33] <seb128> NCommander: that's a debian error right?
[22:33] <NCommander> yeah
[22:33] <NCommander> I've never gotten that one before
[22:33] <seb128> NCommander: well, that's probably the first time a dm try to upload one of the packages you maintain
[22:33] <NCommander> whoops
[22:34] <NCommander> I don't think I set Uploaders: >.>;
[22:34] <NCommander> Probably why it was rejected
[22:34] <seb128> could be yes
[22:35]  * NCommander needs people to do backport uploading for me
[22:36] <seb128> NCommander: trying to ask on #ubuntu-motu?
[22:36] <NCommander> Only core-dev can upload for backports
[22:36] <NCommander> And really only backports should
[22:37] <seb128> NCommander: I think technically you should have bumped the pangomm shlibs
[22:38] <seb128> I'll upload anyway, nothing is using it yet
[22:38] <NCommander> seb128, which shlibs, the soname didn't change
[22:38] <seb128> NCommander: soname and shlibs are different things
[22:38] <seb128> NCommander: shlibs should be updated every time something is added to the api
[22:39] <seb128> when the soname change the package name change
[22:39] <seb128> the shlibs is what is used to build depends
[22:39] <NCommander> hrm
[22:39] <NCommander> wait
[22:39] <seb128> if the current shlib version is 2.13.7 and a package build using pangomm
[22:39] <NCommander> did you already upload?
[22:39] <seb128> it'll get a depends on (>= 2.13.7)
[22:40] <NCommander> Oh
[22:40] <seb128> not if 2.13.8 has an new symbol
[22:40] <NCommander> I thought you meant the .shlibs file
[22:40] <seb128> the application might not run on 2.13.7 and require this symbol
[22:40] <NCommander> Sorry, I thought I lost my mine
[22:40] <NCommander> *mind
[22:40] <seb128> NCommander: no, I mean shver in debian/rules
[22:40] <NCommander> d'oh
[22:40] <seb128> NCommander: and no I didn't upload
[22:40] <NCommander> I completely forgot about that
[22:40] <seb128> do you want to fix it?
[22:40] <NCommander> On my non-CDBS packages, I have a rule that autodetermines that
[22:40] <NCommander> I can't reupload to my PPA, it will reject due to the same version
[22:41] <seb128> I'll just edit the debian/rules for you
[22:41] <NCommander> THank you
[22:41] <seb128> ok?
[22:41] <NCommander> Yeah
[22:41] <seb128> cool
[22:41] <NCommander> Sorry, that completely slipped my mind
[22:41] <NCommander> Don't do gtkmm then, it probably needs that too
[22:41] <seb128> that's alright ;-)
[22:41] <seb128> I'll do the same change if required
[22:41] <NCommander> SHVER := 1:2.13.5 - gtkmm really needs it
[22:41] <NCommander> I completely forgot that existed
[22:42]  * NCommander holds head in shame
[22:43] <pochu> NCommander: you may want to read https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols if you haven't done it yet
[22:44] <NCommander> pochu, I'm aware of it (its a good read), but I don't usually use cdbs myself, so all my packages have some shell magic to pull the shvers out of configure.in
[22:44] <NCommander> pochu, so it becomes set it and forget it
[22:46] <seb128> NCommander: you can't pull the shvers out of the configure.in
[22:47] <seb128> NCommander: the shver is a debian package version
[22:47] <NCommander> seb128, er ... maybe it checked libtool or something. TBI, I don't remember. Its in the default dh_make last time I checked
[22:47]  * NCommander shrugs
[22:47] <seb128> NCommander: you can pull the soname automatically though
[22:47] <NCommander> seb128, yeah, maybe I'm mistaken :-/
[22:47] <seb128> use the libtool age and revision numbers
[22:47]  * NCommander is not fully caffinated yet
[22:49] <NCommander> brb, reboot time
[22:49] <seb128> NCommander: pangomm upload, gtkmm not good
[22:50] <seb128> NCommander: the configure.in requires new libglib, libgtk, etc versions and you don't upgrade the build-depends
[23:07] <seb128> vuntz: still around?
[23:16] <vuntz> seb128: yep
[23:17] <seb128> vuntz:
 seb128: is "Adjust date and time" from the context menu of the clock applet screwed for you as it is for me?
 I can't set a time higher than "11:29:29"
[23:17] <seb128> vuntz: have you already seen bugs like this?
[23:17] <seb128> vuntz: I can confirm it there
[23:17] <vuntz> that's funny :-)
[23:18] <seb128> vuntz: and you have no 2.23 install to try right? ;-)
[23:18] <vuntz> I have one that's semi broken until I reboot
[23:19] <vuntz> does it fail when you set the time or is it just that you can't put a number higher than 29?
[23:19] <seb128> vuntz: I type 16 in the hours and do tab and it changes to 11
[23:19] <james_w> yup, you can set the time
[23:20] <vuntz> works in 2.22
[23:20] <seb128> right
[23:20]  * vuntz tries in jhbuild
[23:20] <james_w> time-admin is similar, and as that auto-sets the time once you unlock if you wait to long before closing you get your time set to 13:something
[23:20] <seb128> I'm wondering if that's a bug in GTK
[23:22] <vuntz> bah, PK issue. Can't try in jhbuild either
[23:22] <seb128> ok
[23:22] <seb128> no fun for you then ;-)
[23:23] <vuntz> well, I should just reboot
[23:23] <vuntz> it's just that I have so many things open...
[23:23] <seb128> vuntz: don't bother, I was just curious to know if that happens on !ubuntu
[23:23] <seb128> let me know next time you reboot
[23:24] <vuntz> seb128: in 2 months? ;-)
[23:24] <seb128> vuntz: if you want, I'll probably find somebody else to ask before that though ;-)
[23:26] <seb128> vuntz: and fix the "gnome-panel doesn't browse the drives after mounting those"
[23:27] <vuntz> seb128: yeah, thinking about it
[23:27] <vuntz> trying to fix my phone first ;-)
[23:29] <james_w> <property name="adjustment">23 0 23 1 12 12</property>
[23:31] <seb128> james_w: where?
[23:31] <james_w> that's the glade file for the panel applet part
[23:31] <james_w> the time-admin one specifies an adjustment in a separate part of xml that looks right, I can't decode that one
[23:32] <seb128> hum
[23:32] <seb128> good hint
[23:33] <seb128> 11 29 29 is the value set by default in the glade
[23:34] <james_w> I don't see where
[23:34] <seb128> glade-3 clock.glade
[23:35] <seb128> it displays 11:29:29 too
[23:35] <james_w> ah
[23:35] <james_w> nice spot
[23:35] <seb128> either a glade or gtk bug
[23:35] <seb128> imho
[23:36] <seb128> the gnome-panel 2.22.2 .glade had the same syntax
[23:36] <seb128> so either libglade or libgtk I would say
[23:36] <james_w> the adjustment appears to be specified correctly
[23:37] <james_w> and the initial value should be 23:59:59
[23:38] <seb128> right
[23:40] <seb128> ok
[23:40] <seb128> iz gtk bug
[23:40] <seb128> $ LD_PRELOAD=deb/usr/lib/libgtk-x11-2.0.so.0 glade-3 gnome-panel-2.23.92/applets/clock/clock.glade
[23:40] <seb128> using libgtk2.0-0_2.12.9-2ubuntu2_i386.deb works correctly
[23:43] <james_w> cool
[23:45] <james_w> http://bugzilla.gnome.org/show_bug.cgi?id=551740 is the forwarded time-admin one
[23:46] <seb128> james_w: feel free to reassign to gtk
[23:46] <james_w> I don't feel I can write a good summary of the problem at this point
[23:55] <seb128> ah
[23:55] <seb128> it's an application bug in fact
[23:55] <seb128> * GtkAdjustment now enforces that values are restricted to the
[23:55] <seb128>   range [lower, upper - page_size]. This has always been the documented
[23:55] <seb128>   behaviour, and the recommended practice is to set page_size to 0
[23:55] <seb128>   when using adjustments for simple scalar values, like in a slider
[23:55] <seb128>   or spin button.
[23:56] <seb128> that's in the new GTK README
[23:56] <seb128> those value are upper - page_size
[23:57] <james_w> ah, nice catch
[23:57] <james_w> would you like me to write up patches?
[23:57] <seb128> I'll do a patch for gnome-panel
[23:57] <james_w> ok, cool
[23:57] <seb128> feel free to do one for time-admin if you want
[23:57] <james_w> yeah
[23:57] <seb128> thanks ;-)
[23:57] <james_w> I'll be glad when g-s-t goes though
[23:58] <seb128> so many bugs there