[00:02] Sweetshark: https://bugs.launchpad.net/qt/+bug/914033 [00:02] Launchpad bug 914033 in qt4-x11 "threading crashes in qt with kde theme" [Undecided,New] [08:08] jasoncwarner_: cjk input in unity dash? [08:09] https://bugs.launchpad.net/ubuntu/oneiric/+source/ibus/+bug/880876 [08:09] Launchpad bug 880876 in unity "Unity causes ibus to not work correctly (spaces incorrectly placed)" [High,Confirmed] [08:15] jasoncwarner_, cyphermox: so the ibus fix I uploaded before holidays is not enough? [08:15] maybe not, I'll try it here now [08:18] seb128: jasoncwarner_: indeed, I can reproduce the bug still [08:18] (in unity) [08:19] Good Morning [08:22] What is the preferred position for dialog buttons in Ubuntu? OK and CANCEL grouped together with OK being on the right side? [08:24] cyphermox, jasoncwarner_: http://launchpadlibrarian.net/87652650/ibus_1.4.0-1ubuntu2_1.4.0-1ubuntu3.diff.gz is the fix I uploaded [08:24] yup, the patch is applied [08:25] I checked in case it was somehow dropped in the merge, but it seems not [08:40] TheMuso`, do you think you could take on bug #880886 from rodrigo? [08:40] 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] TheMuso`, seems a simple "check gtkbuilder files for a11y properties" [08:47] mvo, hey [08:48] mvo, could you roll an ubuntu-system-service to fix bug #877088 when you have some time? [08:48] 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] mvo, i.e it's fixed in the vcs, just need an update to precise [09:08] rodrigo_, hey [09:14] hi seb128 [09:14] rodrigo_, how are you? [09:14] rodrigo_, congrats for your new job ;-) [09:14] seb128, I'm fine, and you? [09:14] seb128, thanks! [09:14] I'm great thanks [09:29] Sweetshark: around today? [09:30] yes, [09:30] saw the bug, whatssup with it? [09:41] ubuntuone--syncdaemon --help [09:41] --im_ok_with_being_root_pretty_please_let_me_be_root [09:41] WTH :) [09:41] dobey: ^ that's you, isn't it :) [09:42] add a --funroll-loops ... that always helps [09:51] 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] 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] pitti, hi [09:53] 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] hello tkamppeter [09:55] robert_ancell, https://docs.google.com/a/canonical.com/document/d/1ILTJDiDCd25Npt2AmgzF8aOnZZECxTfM0hvsbWT2BxA/edit?ndplr=1 section 2.6 [09:56] pitti, it is about the USB backend of CUPS. [09:57] 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] pitti, now I get many bug reports about problems communicating with USB printers. [09:58] tkamppeter: i. e. the libusb backend doesn't work properly? [09:58] pitti, now we need a solution to make the libusb-based CUPS backend working as well as the former usblp-based one. [09:59] pitti, especially the libusb-based backend does not support bi-di at all, what the usblp-based one does. [10:00] hello [10:00] 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] 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] 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] ricotz, ok, I can sponsor that for you [10:01] tkamppeter: what kind of USB backend do they use in MacOS? [10:01] ricotz, I guess you are not interested to write the changelog? :-) [10:02] seb128, sorry, currently not, just wanted to point you there [10:02] 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] ricotz, no worry, thanks [10:03] seb128, please notice the glib patch which is needed for 2.31 [10:03] tkamppeter: hm, I don't think we have any in C :( [10:03] ricotz, ok [10:03] 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] tkamppeter: why was the usblp one removed, because the kernel module is deprecated, right? [10:04] pitti, mostly because our hybrid backend was not accepted upstream and Mike answered my suggestion with deprecating usblp. [10:04] pitti, in addition libusb gives more flexibility, like the possibility to use packet mode. [10:05] 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] seb128, please use the version string with "git" so the debian breaks/conflicts are working [10:06] pitti, note that udev-config-printer (the Plug'n'Print) has awkward code to search and identify printers always with both methods. [10:07] tkamppeter: right, I thought that's why we blacklisted usblp, so that we could drop the hybrid one and only use libusb [10:08] pitti, and now we need a libusb expert to make the libusb backend doing everything the usblp backend is capable of. [10:10] pitti, looking into changelogs of libusb seems that Canonical's libusb competence is having a package sync bot ... [10:10] tkamppeter: that's pretty much correct [10:11] pitti, is there someone at Canonical who develops on software which uses libusb to give Ubuntu certain additional USB functionality? [10:11] bryce: when sponsoring patches like in bug 645974, can you please make sure that they get reported/forwarded upstream? thanks [10:11] Launchpad bug 645974 in pm-utils "xfs handling on battery not working correctly" [Low,Fix released] https://launchpad.net/bugs/645974 [10:13] tkamppeter: note that cups uses a very ancient libusb (0.1), there is not even an upstream for this any more [10:13] tkamppeter: libusb-1.0-0-dev is much more modern, and perhaps even supports bidi [10:13] tkamppeter: but I'd say that any effort on improving libusb 0.1 is just wasted [10:14] tkamppeter: I checked the rdepends, there is no canonical project using libusb :/ [10:16] 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] 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] seb128: sure, done [10:17] tkamppeter: ah, ok [10:20] mvo, danke [10:20] ricotz, so basically getting your ppa version, tweaking the changelog and upload should work? [10:21] 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] ah, good [10:23] robert_ancell, didrocks, mterry, agateau: ^ you get work items there [10:23] seb128, yes [10:23] yay [10:23] ricotz, thanks [10:24] bryce: sent upstream now, and committed to debian git [10:25] we're still undecided about whether precise with get g-c-c 3.4 or 3.2? [10:26] jbicha, 3.2 [10:26] Sweetshark: does libreoffice still need the patch as a SRU? [10:26] jbicha, 3.4 would move keybindings to gsettings which would mean requiring to port compiz to gsettings because they share that [10:27] Sweetshark: or only qt? [10:27] Compiz isn't going to gsettings this cycle either? [10:27] jbicha, no, we have enough stability issues, we want to focus on fixing bugs [10:28] not spend the cycle landing a new backend to then spend the end of the cycle debugging it [10:28] you know how it goes with compiz... [10:28] well maybe it wouldn't be that bad, but still we don't want to focus on bug fixing only [10:30] seb128, this might be interesting to you https://bugzilla.gnome.org/show_bug.cgi?id=639875 [10:30] 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] then I guess gnome-shell 3.4 will have to stay in the PPA then [10:31] ricotz, thanks [10:31] 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] jbicha, note to properly work g-s/mutter will need g-c-c/g-s-d too :\ [10:33] jbicha, you can give them a try and see what it breaks (staging ppa) [10:33] the breakage should be minimal, perhaps only the keyboard shortcuts panel of g-c-c [10:34] yes [10:38] jbicha, well, still not cool [10:38] it means unity keybindings wouldn't be possible to update from g-c-c [10:40] well compiz had a gsettings port months ago but I guess it didn't work well enough [10:41] anyway, bye for now :) [10:43] 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] jbicha, bye ;-) [10:45] 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] pitti, any idea about the libusb-based backend problem? [10:46] 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] tkamppeter: I'm afraid not :( this is again a case of orphaned piece of software :( [10:46] 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] pitti, ignoring all the bug reports? [10:48] tkamppeter: well, if you have a better idea.. [10:48] pitti, we have already dropped the hybrid backend. We are working with the upstream libusb-based backend. [10:49] pitti, the move of deprecating usblp and dropping the hybrid backend introduced the problems. [10:58] Sweetshark: nudge [12:23] What is the equivalent to GdkPixbuf in Gtk3? :/ [12:24] ok, just ignore me [14:00] pitti: not really me, no. ubuntuone-foundations team, but the idea sounds plausible [14:21] Sweetshark: nudge [14:39] Riddell: pong [14:41] Sweetshark: yo, does libreoffice need the patch backported? [14:46] Riddell: rechecking [14:47] 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] Riddell: and we will SRU 3.4.5 rsn [14:48] Sweetshark: ok so just qt that needs the SRU === james_w` is now known as james_w === m_conley_away is now known as m_conley [15:41] 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] Launchpad bug 913908 in dirspec "[MIR] dirspec" [Undecided,New] [15:44] dobey, you need more than GLib's access functions for those directories? [15:48] 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] dobey, and python-xdg is dead? [15:53] mterry: it is unmaintained, still sat in fd.o cvs, and hasn't been touched in years; so yeah, it's dead :) [15:53] dirspec isn't a replacement for all of pyxdg though. only the directory specification bits [15:53] dobey, can't we just patch python-xdg instead of coming up with a new upstream we maintain? :) [15:55] mterry: by patch you mean, fork and maintain pyxdg? [15:55] :) [15:55] dobey, well, patch it in ubuntu. I guess you need to worry about win32 too [15:56] i don't want to maintain all the other bits of it. and the directory spec bits are fairly trivial. [15:56] yeah, we have to worry about win32 [15:56] also, maintaining patches to a dead project is a waste of resources [15:57] dobey, less than maintaining a new package :) it's not like patches to a dead project need much maintenance [15:58] dobey, whatever, I'm not trying to be stop energy, just whining [15:58] 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] plus pyxdg has no test suite or anything nice really [16:01] 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 :) === nekohayo_ is now known as nekohayo === m_conley is now known as m_conley_away