| kubotu | ::workspace-bugs:: [1197317] After KDE update in Saucy, PowerDevil does not suspend the system @ https://bugs.launchpad.net/bugs/1197317 (by Wladimir Mutel) | 00:42 |
|---|---|---|
| smartboyhw | Good morning people | 03:08 |
| === smartboyhw changed the topic of #kubuntu-devel to: Kubuntu - Friendly Computing | https://trello.com/kubuntu | https://notes.kde.org/p/kubuntu-ninjas 4.10.97 saucy/archive raring/beta quantal/staging precise/beta/read_notes_on_pad | 4.11.0 saucy/ninjas | 13.10 Alpha 2 released | 13.10 milestoned bugs tagged Kubuntu http://goo.gl/vHRjj | Kubuntu Developers meeting at 12th Aug 2013 13:00 UTC | ||
| markey | what's the deal with this: "The following packages have been kept back:kscreen" | 05:57 |
| manchicken | apachelogger: Did you see my latest submission? | 06:05 |
| valorie | markey, same thing happened to me | 06:06 |
| valorie | if you apt-get install kscreen you get the new one | 06:06 |
| valorie | errr, libkscreen I think | 06:07 |
| markey | valorie: thanks that worked | 06:07 |
| valorie | last I heard, the packagers were still thinking about how to do that better | 06:08 |
| ggvaberi | hello. is possible to debug rmmod process? | 06:54 |
| jussi | anyone know why kscreen is being kept bck? | 07:15 |
| yofel | jussi: packaging issue, please update with 'sudo apt-get install kscreen' | 07:16 |
| jussi | yofel: ok, thanks | 07:16 |
| yofel | xnox: what breaks is kalzium, which needs avogadro, which has a hard cmake dependency on '/usr/lib/libboost-python.so'. With the new boost-python changes avogadro can't find boost-python anymore | 07:17 |
| yofel | (it can't find it when trying to rebuild it either) | 07:17 |
| tsdgeos | yofel: ah so that's it, i kept wondering wth that /usr/lib/libboost-python.so came from but decided that since no code had changed for a long time it wasn't kalziums fault | 07:22 |
| yofel | tsdgeos: nah, it's avogadro's fault. more precise avogadro_LIB_DEPENDS in /usr/lib/avogadro/1_0/AvogadroLibraryDeps.cmake | 07:25 |
| * yofel needs to run | 07:26 | |
| tester56 | yofel: remember the nepomuk bug we talked about? | 07:26 |
| yofel | tester56: which one? I remember more than one ^^ | 08:18 |
| tester56 | the nepomuk backup thing | 08:18 |
| tester56 | where it did not restore comments etc. | 08:19 |
| tester56 | vHanda fixed it yesterday for the final ... hopefully nepomuk-core can be respun ... | 08:20 |
| yofel | ah yeah, saw the review on the release-team ML | 08:36 |
| tester56 | yofel: do have time for a moment? | 09:18 |
| tester56 | *you | 09:18 |
| vHanda | I still haven't committed it | 09:19 |
| vHanda | will do probably do that today or so | 09:20 |
| tester56 | thanks! | 09:20 |
| yofel | tester56: hm? | 09:28 |
| tester56 | yofel: could you try switching activity and see if it works for you? | 09:28 |
| tester56 | it seems activities are broken in 4.10.97 for me | 09:29 |
| tester56 | when i switch activities pager still shows me the windows of the preceeding activity | 09:29 |
| yofel | there's an activity pager? | 09:30 |
| tester56 | no the virtual workspace pager | 09:30 |
| yofel | hm.. works for me | 09:32 |
| yofel | (saucy) | 09:32 |
| tester56 | furthermore both taskmanager and icon tasks show me all the windows of the first activity although configured to only show windows of current activity | 09:32 |
| tester56 | i am also on saucy | 09:32 |
| tester56 | yofel: thanks for trying out ... strange ... maybe sth. screwed up my config | 09:33 |
| yofel | well, here it seesm to work. I switch to another activity, all my windows are gone, task manager doesn't show them (like it's set to), and they don't show up on the desktop pager either | 09:33 |
| tester56 | kain says "trying to alter state of unknown activity!!" | 09:36 |
| tester56 | *kwin | 09:36 |
| xnox | yofel: right. I'd rather fix kalzium/avogadro in that case. I'll take a look. | 09:37 |
| yofel | xnox: ok thanks, kalzium will be fine once avogradro is fixed | 09:38 |
| tester56 | yofel: i will investigate that later ... it seems kwin related ... maybe because of xorg edgers ppa | 09:39 |
| smartboyhw | Hello yofel | 09:39 |
| yofel | hi smartboyhw | 09:39 |
| smartboyhw | Registering for SAT 2/11/2013... | 10:01 |
| smartboyhw | yofel, how's avogardo doing? | 10:18 |
| yofel | smartboyhw: waiting to be fixed | 10:20 |
| yofel | see ^ | 10:20 |
| smartboyhw | yofel, oh great | 10:21 |
| smartboyhw | lalalalala not much work to do:P | 10:21 |
| smartboyhw | It would be good if you guys do the translations, it seemed like non-developers have to use ec2s:P | 10:21 |
| yofel | you can do backporting to raring if everything except kalzium is done | 10:21 |
| smartboyhw | yofel, I think all of them is done, this is a rather smooth release I'd say | 10:22 |
| smartboyhw | But, I need to practice my piano now:P | 10:22 |
| yofel | smartboyhw: well, not really, but as we need to sign some 50 packages you should generate it somewhere where we can access it | 10:22 |
| yofel | you could use my container | 10:22 |
| yofel | then I can sign it | 10:22 |
| smartboyhw | yofel, I knoq | 10:22 |
| smartboyhw | *know | 10:22 |
| smartboyhw | Anyway, piano practice is my 1st priority | 10:23 |
| smartboyhw | :P | 10:23 |
| yofel | but it's easier if someone with upload permissions just does l10n | 10:23 |
| smartboyhw | I nominate yofel or shadeslayer | 10:23 |
| yofel | no hurry with it anyway | 10:23 |
| yofel | oh hm, backporting to raring would have to be done in ninjas until the tars are public | 10:24 |
| yofel | also nepomuk might get a respin | 10:24 |
| yofel | so lets wait | 10:24 |
| yofel | -core | 10:24 |
| smartboyhw | yofel, nepomuk-core why? | 10:27 |
| yofel | see release-team ML | 10:31 |
| smartboyhw | yofel, hmm I'm subscribed with no mail about it | 10:42 |
| yofel | smartboyhw: http://lists.kde.org/?t=137598458700001&r=1&w=2 and http://lists.kde.org/?t=137598458900004&r=1&w=2 | 10:46 |
| smartboyhw | yofel, ookkkkk | 10:49 |
| smartboyhw | Has anyone here taken the SAT before? | 10:49 |
| BluesKaj | Hiyas all | 11:03 |
| === greyback is now known as greyback|lunch | ||
| === greyback|lunch is now known as greyback | ||
| xnox | yofel: ScottK: the fix is two fold. (a) make cmake's FindBoost look into multiarch locations (b) make avogadro look for python-py27 boost module. | 12:18 |
| xnox | i think I should continue shipping boost-python.so -> boost-python-py27.so symlink. But I am not sure. Upstream abi tags don't seem to support 27/3x tags on the boost python library yet. | 12:19 |
| smartboyhw | Boom | 12:36 |
| BluesKaj | are you guys seeing mysql dependency problems on upgrades today? , we're getting reports of mysql depend troubles blocking upgrades on 13.04 | 12:46 |
| smartboyhw | BluesKaj, hmm for which package mysql was blocking | 13:11 |
| ScottK | BluesKaj: With -proposed enabled? | 13:28 |
| ScottK | There was a bad SRU in -proposed that got pulled. | 13:28 |
| ScottK | xnox: Would you please coordinate the CMake stuff with MoDaX in Debian. | 13:29 |
| xnox | ScottK: ok. it needs to go upstream anyway, both multiarch findboost and multiple-pythons in findboost. | 13:29 |
| ScottK | I got him to use the multiple Python include dirs patch in Debian's CMake, but it's not upstream yet. You might offer to help him get that sorted too. | 13:31 |
| ScottK | Our version apparently isn't fully backward compatible. | 13:31 |
| xnox | ScottK: so i heard. | 14:06 |
| xnox | yofel: kalzium rebuilds now in saucy. | 14:10 |
| smartboyhw | xnox, \o/ | 14:11 |
| yofel | xnox: thanks a lot! | 14:45 |
| ScottK | How close are to to 4.11.0 in saucy? | 15:22 |
| smartboyhw | ScottK, only kalzium | 15:44 |
| smartboyhw | And a possible nepomuk-core fix from upstream | 15:44 |
| * ScottK works on kopete ftbfs on ppc. | 16:46 | |
| ScottK | KDE Bug 323312 | 16:59 |
| ubottu | KDE bug 323312 in Jabber Plugin "Please update embedded libjingle" [Normal,Unconfirmed] http://bugs.kde.org/show_bug.cgi?id=323312 | 16:59 |
| xnox | ScottK: is Kubuntu/KDE using qt5 yet? | 19:23 |
| yofel | xnox: no | 19:25 |
| yofel | kde frameworks 5 (kdelibs replacement) will be based on qt5 | 19:25 |
| yofel | coming sometime next year | 19:25 |
| xnox | yofel: before or after 14.04 =) | 19:26 |
| yofel | after | 19:26 |
| xnox | yofel: ok. | 19:26 |
| xnox | in that case, some time lines imposed by ScottK do not sound reasonable from Kubuntu's point of view. | 19:27 |
| ScottK | xnox: I'm not a "Kubuntu" release manager. I'm part of the release team for the entire project. | 19:28 |
| xnox | ScottK: sure, I don't deny that. And historically our entire project wouldn't exist, unless we apply patches, strive to not regress, or differentiate. Otherwise we'd be arch linux. | 19:31 |
| * ScottK looks at /usr/bin/python --> python3 in arch and totally doesn't understand. | 19:31 | |
| ScottK | Core toolkit packages like Qt shouldn't diverge from upstream. That doesn't mean that stuff can't land in the distro first, but that can't be it. | 19:33 |
| ScottK | If you look at the history, you'll see I've been quite open to stuff coming into qt4-x11 before it could actually land upstream while it was being worked on. | 19:33 |
| xnox | ScottK: have we ever had a gtk or qt package without patches? has debian _ever_ had that? | 19:33 |
| ScottK | No, but, to pick a related example, we've had long term Debian/Ubuntu python-qt4 patches because no one ever upstream them. pyqt5, we're starting fresh and working with upstream from the start. | 19:35 |
| ScottK | Currently we've got no patches that aren't upstream for the next release and the same for the arm build patch I'm about to add. | 19:35 |
| d_ed_ | xnox: what time lines? | 19:37 |
| xnox | ScottK: who "we"? | 19:38 |
| ScottK | The people working on that package. ATM, myself and mitya57. | 19:39 |
| ScottK | Or Debian and Ubuntu if you prefer. | 19:39 |
| ScottK | Works out the same. | 19:39 |
| xnox | d_ed_: based around ubuntu releases, rather than qt releases. | 19:39 |
| ScottK | I know sometimes stuff needs to be patched. I don't object to that. I object to not caring about upstreaming. | 19:39 |
| xnox | ScottK: but i can't upstream changes into release qt 5.0 toolkit anymore. and they stopped taking patches for qt4. | 19:40 |
| xnox | s/release/released/ | 19:40 |
| kubotu | xnox meant: "ScottK: but i can't upstream changes into released qt 5.0 toolkit anymore. and they stopped taking patches for qt4." | 19:40 |
| ScottK | Right, but you can get them in 5.2. | 19:41 |
| ScottK | And there's stuff that never got into 4.8, but it got into 5.0. | 19:41 |
| xnox | ScottK: in that sense I interpret your stance as a deadlock, rather than advocating for proactive upstreaming. | 19:41 |
| xnox | ScottK: ack. | 19:42 |
| ScottK | No. My stance is go work with upstream and show you did it because it's been demonstrated over the last ~4 years that "trust me, I'll do it later" isn't reliable. | 19:43 |
| xnox | ScottK: ok. but with qt5, they no longer want platform ports upstream (e.g. windows/mac/symbian/linux-maemo/linux-meego/linux-android....) but rather platforms provide their own Qt Platform Abstraction plugins, such that the API is upstreamed, yet implementations can & should be vendor specific. | 19:49 |
| d_ed_ | xnox: that's not quite true. QPA has no binary compatability. They want it out of the kernel | 19:49 |
| d_ed_ | QPA plugins remain in the Qt tree | 19:50 |
| xnox | d_ed_: if it has no binary compatability, i'm not sure how is that any better over qt4 style ports then. | 19:50 |
| * xnox goes to read up more. | 19:50 | |
| d_ed_ | there are three things | 19:51 |
| d_ed_ | Platform (i.e Wayland, Mir, X, Windows, Cocoa, etc.) which do graphic stuff | 19:51 |
| d_ed_ | PlatformThemes (KDE, Gnome, Windows, OS X) which do default shortcuts, which open dialog to use | 19:52 |
| d_ed_ | Styles (Oxygen, Plastique, Aqua, etc.) which can change minor things in widgets | 19:52 |
| xnox | d_ed_: why would I want to maintain my platform plugin in qt upstream, rather than on my platform, since for example appmenu API is dependant on ubuntu release and qt version there. Inherently we do not support arbitrary future major qt releases backported back to previous releases. | 19:56 |
| xnox | (as a whole project) | 19:56 |
| ScottK | xnox: What platform is this? | 19:57 |
| xnox | d_ed_: reading up: http://qforever.wordpress.com/2012/04/10/qt-platform-abstraction-starter-guide/ we want to support as many platforms in parallel as possible. And that in itself should be co-installable and easily to switch between at runtime. | 19:57 |
| xnox | ScottK: "Qt Platform Abstraction", or please elaborate your question. | 19:58 |
| xnox | oh, i see i used same work twice with different meaning. | 19:58 |
| ScottK | What's the platform for the Ubuntu project? | 19:58 |
| d_ed_ | xnox: instead, could you explain what you want to acheive. | 19:58 |
| d_ed_ | xnox: I'll put my Qt hat on and answer | 19:58 |
| soee | whats wrong with kscreen on raring ? it was stopped during upgrade ? | 20:00 |
| xnox | d_ed_: in ubuntu project we ship binaries of Qt with universal support. Yet we ship multiple Qt based platforms with different abstractions: kde (more or less stock), kde active plasma (may have unique abstraction from previous), unity on compiz, unity on mir, unity on mir - tablet semantics, unity on mir - phone semantics, lubuntu new qt project (what's its name). | 20:00 |
| xnox | d_ed_: i really cannot explode the matrix and have multiple qt flavours packages. and my app should run under all UIs. | 20:01 |
| yofel | soee: apt-get install kscreen | 20:01 |
| yofel | soee: we'll try to work that out ASAP | 20:02 |
| xnox | d_ed_: thus i should compile my qt5 with as many platforms enabled as possible. and depending on the session the right ones should be used. | 20:02 |
| yofel | afiestas: ping again about libkscreen plugin namespacing. Possible or not? | 20:02 |
| d_ed_ | xnox: so you're a Qt packager? | 20:03 |
| xnox | d_ed_: what's the best way to develop platform plugins that are specific to ubuntu project (e.g. unity*), together with external platform plugins (e.g. kde, lubuntu) and upstream (e.g. stock qt)? | 20:03 |
| xnox | d_ed_: that's my question above ^ | 20:03 |
| d_ed_ | so you're a ubuntu developer wanting to ship a Ubuntu platform? | 20:04 |
| afiestas | yofel: about what? | 20:04 |
| xnox | d_ed_: if you look at my launchpad page, i'm ubuntu/kubuntu/lubuntu/xubuntu developer =) so yeah, I am one of the people who makes ubuntu project. It currently support multitude of platforms, there isn't just one. | 20:05 |
| yofel | afiestas: our kscreen update in raring is currently stuck because apt refuses to automatically replace libkscreen0 with libkscreen1 (they're not co-installable because they both have the same plugins) | 20:05 |
| soee | yofel, worked, ok but i had to run also apt-get -f install as apt-get install kscreen ended with: Operation was stopped before could be finished | 20:05 |
| yofel | afiestas: could we instead add the soversion to the plugin path so that they're co-installable? | 20:05 |
| yofel | afiestas: or would having 2 sets of plugins break something? | 20:06 |
| yofel | (linked against different libs) | 20:06 |
| afiestas | why do you want to co install them_ | 20:06 |
| afiestas | ? | 20:06 |
| xnox | afiestas: yes. | 20:07 |
| xnox | afiestas: it's currently supported. | 20:07 |
| yofel | afiestas: because usually, the same library with different SOVERSIONS should be co-installable | 20:07 |
| yofel | as there are no file conflicts | 20:07 |
| yofel | only the plugins break that | 20:07 |
| yofel | and apt doesn't really like that | 20:07 |
| yofel | (on upgrades) | 20:07 |
| yofel | we're not yet sure *why* it doesn't like it though | 20:08 |
| afiestas | well, we look in a folder for the plugins | 20:11 |
| afiestas | if we found 4, 2 of them with different abi we'll break | 20:12 |
| d_ed_ | xnox: right, so everything will hopefully be a platform theme at some point | 20:12 |
| d_ed_ | so you ship liqt.. .plus some platform themes | 20:12 |
| afiestas | siml;y replace them, nobody is using libkscreen and you don't want to ahve both versions | 20:12 |
| d_ed_ | xnox: and there shouldn't be any additional patches/hacks anywhere | 20:12 |
| yofel | afiestas: you look in /usr/lib/kde4/plugins/, could libkscreen 1 not look in /usr/lib/kde4/plugins/kscreen1/ or so? | 20:12 |
| yofel | er, /usr/lib/kde4/plugins/kscreen | 20:13 |
| yofel | if we could make that /usr/lib/kde4/plugins/kscreen1, we would have no file conflicts, and you shouldn't find multiple sets of plugins | 20:13 |
| yofel | afiestas: we currently do replace them, but apt for *some stupid reason* refuses to do that | 20:14 |
| yofel | so the update is simply held back for most people | 20:14 |
| afiestas | but they are conflicting aren't they? | 20:15 |
| yofel | they do, because they both ship /usr/lib/kde4/plugins/kscreen | 20:15 |
| yofel | you can't have 2 packages install the same files | 20:16 |
| afiestas | I can do that I guess, having it namespaces is always good but I can't do this now | 20:16 |
| yofel | ok, thanks for the input. | 20:17 |
| yofel | we'll try to debug apt in the meanwhile | 20:17 |
| yofel | debfx: ^ | 20:18 |
| yofel | JontheEchidna: do you know whether http://lists.kde.org/?l=kde-commits&m=136332005527708 did get a quantal SRU? (see #kubuntu) | 20:30 |
| valorie | what y'all do is so important! http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html | 20:46 |
| yofel | that's evil :S | 21:00 |
| ScottK | It's PHP, so it was evil to start with. This is just another evil. | 21:05 |
| valorie | right, just an example | 21:10 |
| allee | yofel: Why not just: Conflicts: libkscreen0 Should work, at least for one of my local-only pkgs | 21:39 |
| yofel | it has | 21:40 |
| yofel | Breaks: libkscreen0 | 21:40 |
| yofel | Replaces: libkscreen0 | 21:40 |
| yofel | as it should by policy | 21:40 |
| allee | hmm breaks. Time to reread policy ... | 21:42 |
| allee | yofel: hmmm, as you want to get libkscreen0 removed when libkscreen1 is installed, then it's conflict (at least that's my understanding of http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks 73. and 7.4) | 21:50 |
| yofel | allee: well, this is really about moving files from one package to another, which is Breaks | 21:54 |
| yofel | though the 2nd paragraph of conflicts sounds interesting, maybe worth a try | 21:55 |
| allee | If the kscreen/KSC_*.so plugins are dynamicly load by libkscreenX that IMHO they should be put into/usr/lib/kde4/plugins/libkscreenX | 21:55 |
| yofel | right | 21:56 |
| yofel | as we said above | 21:56 |
| allee | if not, they are better put into their own package e.g. kscreen-kcs which would make libkscreen{0.1} koexists | 21:56 |
| allee | and libkscreen(x-1) has no rdepends as soon as libkscreen(x) is installed and can stay on disk or autoremoved | 21:57 |
| === v_ is now known as v | ||
| allee | KCS_* link against libkscreenX. So it looks like the proper solution would be to move then to their own package (or better upstream can move then into kscreen) | 22:15 |
| allee | afiestas: do the KCS_* plugins/backends use libkscreen or uses libkscreen the KCS* plugins/backends to abstract the impl. details away? | 22:17 |
| yofel | anyone an idea about this crash? http://paste.kde.org/p4945167a/ | 22:19 |
| yofel | happens when trying to use the kipi-plugins from digikam 3.3 on quantal and precise | 22:19 |
| allee | Most kipi crashes AFAIR were due to pluging links libabcX and app links against libabcY | 22:24 |
| yofel | well, this was built against the matching kde libs | 22:26 |
| allee | but, e.g. libexiv, used by plugin and an app using the plugins can still be different soversion | 22:28 |
| allee | ^^ not sure if it's the case here | 22:28 |
| * allee tries to find a precise system with digikam 3.3. .... | 22:28 | |
| yofel | well, this was ksnapshot, crashes when I click on 'send to' trying to load the kipi plugins | 22:28 |
| yofel | allee: you won't, it's for testing in yofel/staging1 ppa | 22:29 |
| yofel | build against kde in kubuntu-ppa/backports | 22:29 |
| afiestas | allee: the second thing | 22:40 |
| afiestas | though plugins link against kscreen and return classes defines adn exported there | 22:41 |
| allee | okay. usage from top to bottom is: kscreen -> libkscreen <-> KCS_XXX, so proper solution from pkging point of view would be to namespace the plugins below plugins/libkscreenX | 22:47 |
| ScottK | That could work. | 22:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!