[00:02] <Riddell> Sweetshark: https://bugs.launchpad.net/qt/+bug/914033
[00:02] <ubot2`> Launchpad bug 914033 in qt4-x11 "threading crashes in qt with kde theme" [Undecided,New]
[08:08] <cyphermox> jasoncwarner_: cjk input in unity dash?
[08:09] <jasoncwarner_> https://bugs.launchpad.net/ubuntu/oneiric/+source/ibus/+bug/880876
[08:09] <ubot2`> Launchpad bug 880876 in unity "Unity causes ibus to not work correctly (spaces incorrectly placed)" [High,Confirmed]
[08:15] <seb128> jasoncwarner_, cyphermox: so the ibus fix I uploaded before holidays is not enough?
[08:15] <cyphermox> maybe not, I'll try it here now
[08:18] <cyphermox> seb128: jasoncwarner_: indeed, I can reproduce the bug still
[08:18] <cyphermox> (in unity)
[08:19] <BigWhale> Good Morning
[08:22] <BigWhale> What is the preferred position for dialog buttons in Ubuntu? OK and CANCEL grouped together with OK being on the right side?
[08:24] <seb128> cyphermox, jasoncwarner_: http://launchpadlibrarian.net/87652650/ibus_1.4.0-1ubuntu2_1.4.0-1ubuntu3.diff.gz is the fix I uploaded
[08:24] <cyphermox> yup, the patch is applied
[08:25] <cyphermox> I checked in case it was somehow dropped in the merge, but it seems not
[08:40] <seb128> TheMuso`, do you think you could take on bug #880886 from rodrigo?
[08:40] <ubot2`> Launchpad bug 880886 in gnome-control-center "Doesn't associated with mnemonic_widget property or accessibility related properties with some preference tool dialogs in GNOME Control Center application" [Undecided,New] https://launchpad.net/bugs/880886
[08:40] <seb128> TheMuso`, seems a simple "check gtkbuilder files for a11y properties"
[08:47] <seb128> mvo, hey
[08:48] <seb128> mvo, could you roll an ubuntu-system-service to fix bug #877088 when you have some time?
[08:48] <ubot2`> Launchpad bug 877088 in ubuntu-system-service "Network proxy setting does not set apt.conf from the second time" [Low,In progress] https://launchpad.net/bugs/877088
[08:48] <seb128> mvo, i.e it's fixed in the vcs, just need an update to precise
[09:08] <seb128> rodrigo_, hey
[09:14] <rodrigo_> hi seb128
[09:14] <seb128> rodrigo_, how are you?
[09:14] <seb128> rodrigo_, congrats for your new job ;-)
[09:14] <rodrigo_> seb128, I'm fine, and you?
[09:14] <rodrigo_> seb128, thanks!
[09:14] <seb128> I'm great thanks
[09:29] <Riddell> Sweetshark: around today?
[09:30] <Sweetshark> yes,
[09:30] <Sweetshark> saw the bug, whatssup with it?
[09:41] <pitti> ubuntuone--syncdaemon --help
[09:41] <pitti>  --im_ok_with_being_root_pretty_please_let_me_be_root
[09:41] <pitti> WTH :)
[09:41] <pitti> dobey: ^ that's you, isn't it :)
[09:42] <Sweetshark> add a --funroll-loops ... that always helps
[09:51] <pitti> dobey: input on bug 906462 greatly appreciated; I'm happy to work on a patch/branch, but would like to confirm that we can disable it by default
[09:51] <ubot2`> Launchpad bug 906462 in ubuntuone-client "ubuntuone sync daemon is writing IDLE messages to the log every 2 minutes" [High,Triaged] https://launchpad.net/bugs/906462
[09:53] <tkamppeter> pitti, hi
[09:53] <ricotz> jbicha, hi, i am not sure if this a good idea yet, but since the cogl break it is probably fine now and should be quite 1.9.4 already
[09:53] <pitti> hello tkamppeter
[09:55] <seb128> robert_ancell, https://docs.google.com/a/canonical.com/document/d/1ILTJDiDCd25Npt2AmgzF8aOnZZECxTfM0hvsbWT2BxA/edit?ndplr=1 section 2.6
[09:56] <tkamppeter> pitti, it is about the USB backend of CUPS.
[09:57] <tkamppeter> pitti, as you perhaps know, Mike Sweet did not accept our libusb/usblp hybrid patch and suggested to deprecate usblp which we did in Oneiric by blacklisting.
[09:58] <tkamppeter> pitti, now I get many bug reports about problems communicating with USB printers.
[09:58] <pitti> tkamppeter: i. e. the libusb backend doesn't work properly?
[09:58] <tkamppeter> pitti, now we need a solution to make the libusb-based CUPS backend working as well as the former usblp-based one.
[09:59] <tkamppeter> pitti, especially the libusb-based backend does not support bi-di at all, what the usblp-based one does.
[10:00] <ricotz> hello
[10:00] <tkamppeter> pitti, for precise we would need to get it at least working as well as the usblp-based backend, later on packet mode should be added to remove HP's necessity to supply their own "hp" backend.
[10:01] <ricotz> seb128, i pushed a new rhythmbox snapshot to my staging ppa which is merged with debian, and it is running fine, but no changelog :(
[10:01] <tkamppeter> pitti, Mike Sweet is not willing to work on that as it is not in the interest of Apple (libusb is Linux-only AFAIK).
[10:01] <seb128> ricotz, ok, I can sponsor that for you
[10:01] <pitti> tkamppeter: what kind of USB backend do they use in MacOS?
[10:01] <seb128> ricotz, I guess you are not interested to write the changelog? :-)
[10:02] <ricotz> seb128, sorry, currently not, just wanted to point you there
[10:02] <tkamppeter> pitti, what we need is some libusb expert, preferably at Canonical, to review and improve the code of the libusb-based USB CUPS backend.
[10:02] <seb128> ricotz, no worry, thanks
[10:03] <ricotz> seb128, please notice the glib patch which is needed for 2.31
[10:03] <pitti> tkamppeter: hm, I don't think we have any in C :(
[10:03] <seb128> ricotz, ok
[10:03] <tkamppeter> pitti, there is a separate source file for the Mac-OS-X version of the USB CUPS backend in the backend/ directory but I did not look into it.
[10:03] <pitti> tkamppeter: why was the usblp one removed, because the kernel module is deprecated, right?
[10:04] <tkamppeter> pitti, mostly because our hybrid backend was not accepted upstream and Mike answered my suggestion with deprecating usblp.
[10:04] <tkamppeter> pitti, in addition libusb gives more flexibility, like the possibility to use packet mode.
[10:05] <tkamppeter> pitti, and for me as distro maintainer, I could simplify auto-setup code as I need to only   take into account libusb to detect and identify USB printers.
[10:06] <ricotz> seb128, please use the version string with "git" so the debian breaks/conflicts are working
[10:06] <tkamppeter> pitti, note that udev-config-printer (the Plug'n'Print) has awkward code to search and identify printers always with both methods.
[10:07] <pitti> tkamppeter: right, I thought that's why we blacklisted usblp, so that we could drop the hybrid one and only use libusb
[10:08] <tkamppeter> pitti, and now we need a libusb expert to make the libusb backend doing everything the usblp backend is capable of.
[10:10] <tkamppeter> pitti, looking into changelogs of libusb seems that Canonical's libusb competence is having a package sync bot ...
[10:10] <pitti> tkamppeter: that's pretty much correct
[10:11] <tkamppeter> pitti, is there someone at Canonical who develops on software which uses libusb to give Ubuntu certain additional USB functionality?
[10:11] <pitti> bryce: when sponsoring patches like in bug 645974, can you please make sure that they get reported/forwarded upstream? thanks
[10:11] <ubot2`> Launchpad bug 645974 in pm-utils "xfs handling on battery not working correctly" [Low,Fix released] https://launchpad.net/bugs/645974
[10:13] <pitti> tkamppeter: note that cups uses a very ancient libusb (0.1), there is not even an upstream for this any more
[10:13] <pitti> tkamppeter: libusb-1.0-0-dev is much more modern, and perhaps even supports bidi
[10:13] <pitti> tkamppeter: but I'd say that any effort on improving libusb 0.1 is just wasted
[10:14] <pitti> tkamppeter: I checked the rdepends, there is no canonical project using libusb :/
[10:16] <tkamppeter> pitti, I was also rather expecting that the USB backend code needs to be improved, not the code of libusb, probably all libusb versions are bi-di capable, as most devices (like scanners) used bi-di all the time.
[10:17] <tkamppeter> pitti, but advancing the backend to the new libusb would be a good idea anyway, only that this will not automatically introduce bi-di to it.
[10:17] <mvo> seb128: sure, done
[10:17] <pitti> tkamppeter: ah, ok
[10:20] <seb128> mvo, danke
[10:20] <seb128> ricotz, so basically getting your ppa version, tweaking the changelog and upload should work?
[10:21] <seb128> pitti, recycled https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-control-center-cleanup for the g-c-c design changes we discussed yesterday
[10:21] <pitti> ah, good
[10:23] <seb128> robert_ancell, didrocks, mterry, agateau: ^ you get work items there
[10:23] <ricotz> seb128, yes
[10:23] <mterry> yay
[10:23] <seb128> ricotz, thanks
[10:24] <pitti> bryce: sent upstream now, and committed to debian git
[10:25] <jbicha> we're still undecided about whether precise with get g-c-c 3.4 or 3.2?
[10:26] <seb128> jbicha, 3.2
[10:26] <Riddell> Sweetshark: does libreoffice still need the patch as a SRU?
[10:26] <seb128> jbicha, 3.4 would move keybindings to gsettings which would mean requiring to port compiz to gsettings because they share that
[10:27] <Riddell> Sweetshark: or only qt?
[10:27] <jbicha> Compiz isn't going to gsettings this cycle either?
[10:27] <seb128> jbicha, no, we have enough stability issues, we want to focus on fixing bugs
[10:28] <seb128> not spend the cycle landing a new backend to then spend the end of the cycle debugging it
[10:28] <seb128> you know how it goes with compiz...
[10:28] <seb128> well maybe it wouldn't be that bad, but still we don't want to focus on bug fixing only
[10:30] <ricotz> seb128, this might be interesting to you https://bugzilla.gnome.org/show_bug.cgi?id=639875
[10:30] <ubot2`> Gnome bug 639875 in GtkNotebook "crashes when unparenting a tab from a window (drag-n-drop it outside of it)" [Critical,Resolved: fixed]
[10:31] <jbicha> then I guess gnome-shell 3.4 will have to stay in the PPA then
[10:31] <seb128> ricotz, thanks
[10:31] <seb128> jbicha, yeah, it's a bit unfortunate since it means we will maybe have again a situation where the ppa will break unity
[10:32] <ricotz> jbicha, note to properly work g-s/mutter will need g-c-c/g-s-d too :\
[10:33] <ricotz> jbicha, you can give them a try and see what it breaks (staging ppa)
[10:33] <jbicha> the breakage should be minimal, perhaps only the keyboard shortcuts panel of g-c-c
[10:34] <ricotz> yes
[10:38] <seb128> jbicha, well, still not cool
[10:38] <seb128> it means unity keybindings wouldn't be possible to update from g-c-c
[10:40] <jbicha> well compiz had a gsettings port months ago but I guess it didn't work well enough
[10:41] <jbicha> anyway, bye for now :)
[10:43] <seb128> jbicha, it's supposed to work, still it's quite some change, and we were reluctant to update g-c-c and g-s-d to new versions for the lts for GNOME stability reasons
[10:43] <seb128> jbicha, bye ;-)
[10:45] <BigWhale> This is how they name a function "Gtk.RadioButton.new_with_label_from_widget" and then they expect people to have lines within 80 characters ...
[10:45] <tkamppeter> pitti, any idea about the libusb-based backend problem?
[10:46] <BigWhale> I asked this before, but everyeone were still sleeping: What is the preferred position for dialog buttons in Ubuntu? OK and CANCEL grouped together with OK being on the right side?
[10:46] <pitti> tkamppeter: I'm afraid not :( this is again a case of orphaned piece of software :(
[10:46] <pitti> tkamppeter: so I guess we can just keep what we have right now, and possibly get rid of the hybrid backend to make things easier
[10:48] <tkamppeter> pitti, ignoring all the bug reports?
[10:48] <pitti> tkamppeter: well, if you have a better idea..
[10:48] <tkamppeter> pitti, we have already dropped the hybrid backend. We are working with the upstream libusb-based backend.
[10:49] <tkamppeter> pitti, the move of deprecating usblp and dropping the hybrid backend introduced the problems.
[10:58] <Riddell> Sweetshark: nudge
[12:23] <BigWhale> What is the equivalent to GdkPixbuf in Gtk3? :/
[12:24] <BigWhale> ok, just ignore me
[14:00] <dobey> pitti: not really me, no. ubuntuone-foundations team, but the idea sounds plausible
[14:21] <Riddell> Sweetshark: nudge
[14:39] <Sweetshark> Riddell: pong
[14:41] <Riddell> Sweetshark: yo, does libreoffice need the patch backported?
[14:46] <Sweetshark> Riddell: rechecking
[14:47] <Sweetshark> Riddell: http://cgit.freedesktop.org/libreoffice/libs-gui/commit/vcl/unx/kde4/main.cxx?h=libreoffice-3-4-4&id=4c2b93d96689f62c24ebdb2d4e87ac08d51ed53a <- is already in 3.4.4 (which we have in oneiric)
[14:47] <Sweetshark> Riddell: and we will SRU 3.4.5 rsn
[14:48] <Riddell> Sweetshark: ok so just qt that needs the SRU
[15:41] <dobey> mterry: hey. can you poke at https://bugs.launchpad.net/ubuntu/+source/dirspec/+bug/913908 ? should be pretty easy to deal with i think :)
[15:41] <ubot2`> Launchpad bug 913908 in dirspec "[MIR] dirspec" [Undecided,New]
[15:44] <mterry> dobey, you need more than GLib's access functions for those directories?
[15:48] <dobey> mterry: we need to not use glib to get those directories, and we need it to be cross-platform. also, there are a *lot* of packages using python-xdg, so would be useful to move them off it, either to dirspec or to glib, as appropriate
[15:52] <mterry> dobey, and python-xdg is dead?
[15:53] <dobey> mterry: it is unmaintained, still sat in fd.o cvs, and hasn't been touched in years; so yeah, it's dead :)
[15:53] <dobey> dirspec isn't a replacement for all of pyxdg though. only the directory specification bits
[15:53] <mterry> dobey, can't we just patch python-xdg instead of coming up with a new upstream we maintain?  :)
[15:55] <dobey> mterry: by patch you mean, fork and maintain pyxdg?
[15:55] <dobey> :)
[15:55] <mterry> dobey, well, patch it in ubuntu.  I guess you need to worry about win32 too
[15:56] <dobey> i don't want to maintain all the other bits of it. and the directory spec bits are fairly trivial.
[15:56] <dobey> yeah, we have to worry about win32
[15:56] <dobey> also, maintaining patches to a dead project is a waste of resources
[15:57] <mterry> dobey, less than maintaining a new package  :)  it's not like patches to a dead project need much maintenance
[15:58] <mterry> dobey, whatever, I'm not trying to be stop energy, just whining
[15:58] <dobey> mterry: and the dead project is either still dead, or you take it over and maintain it. and neither of those are amicable i think. so maintaining only the bits we need is more useful it seems :)
[15:59] <dobey> plus pyxdg has no test suite or anything nice really
[16:01] <dobey> and then there's the whole multi-platform issue. so yeah, i have thought about all this quite a bit, before actually making dirspec. and it was the best solution :)