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
smartboyhwGood morning people03: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
markeywhat's the deal with this: "The following packages have been kept back:kscreen"05:57
manchickenapachelogger: Did you see my latest submission?06:05
valoriemarkey, same thing happened to me06:06
valorieif you apt-get install kscreen you get the new one06:06
valorieerrr, libkscreen I think06:07
markeyvalorie: thanks that worked06:07
valorielast I heard, the packagers were still thinking about how to do that better06:08
ggvaberihello. is possible to debug rmmod process?06:54
jussianyone know why kscreen is being kept bck?07:15
yofeljussi: packaging issue, please update with 'sudo apt-get install kscreen'07:16
jussiyofel: ok, thanks07:16
yofelxnox: 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 anymore07:17
yofel(it can't find it when trying to rebuild it either)07:17
tsdgeosyofel: 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 fault07:22
yofeltsdgeos: nah, it's avogadro's fault. more precise avogadro_LIB_DEPENDS in /usr/lib/avogadro/1_0/AvogadroLibraryDeps.cmake07:25
* yofel needs to run07:26
tester56yofel: remember the nepomuk bug we talked about?07:26
yofeltester56: which one? I remember more than one ^^08:18
tester56the nepomuk backup thing08:18
tester56where it did not restore comments etc.08:19
tester56vHanda fixed it yesterday for the final ... hopefully nepomuk-core can be respun ...08:20
yofelah yeah, saw the review on the release-team ML08:36
tester56yofel: do have time for a moment?09:18
tester56*you 09:18
vHandaI still haven't committed it09:19
vHandawill do probably do that today or so09:20
yofeltester56: hm?09:28
tester56yofel: could you try switching activity and see if it works for you?09:28
tester56it seems activities are broken in 4.10.97 for me09:29
tester56when i switch activities pager still shows me the windows of the preceeding activity09:29
yofelthere's an activity pager?09:30
tester56no the virtual workspace pager09:30
yofelhm.. works for me09:32
tester56furthermore both taskmanager and icon tasks show me all the windows of the first activity although configured to only show windows of current activity09:32
tester56i am also on saucy09:32
tester56yofel: thanks for trying out ... strange ... maybe sth. screwed up my config09:33
yofelwell, 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 either09:33
tester56kain says "trying to alter state of unknown activity!!"09:36
xnoxyofel: right. I'd rather fix kalzium/avogadro in that case. I'll take a look.09:37
yofelxnox: ok thanks, kalzium will be fine once avogradro is fixed09:38
tester56yofel: i will investigate that later ... it seems kwin related ... maybe because of xorg edgers ppa09:39
smartboyhwHello yofel09:39
yofelhi smartboyhw09:39
smartboyhwRegistering for SAT 2/11/2013...10:01
smartboyhwyofel, how's avogardo doing?10:18
yofelsmartboyhw: waiting to be fixed10:20
yofelsee ^10:20
smartboyhwyofel, oh great10:21
smartboyhwlalalalala not much work to do:P10:21
smartboyhwIt would be good if you guys do the translations, it seemed like non-developers have to use ec2s:P10:21
yofelyou can do backporting to raring if everything except kalzium is done10:21
smartboyhwyofel, I think all of them is done, this is a rather smooth release I'd say10:22
smartboyhwBut, I need to practice my piano now:P10:22
yofelsmartboyhw: well, not really, but as we need to sign some 50 packages you should generate it somewhere where we can access it10:22
yofelyou could use my container10:22
yofelthen I can sign it10:22
smartboyhwyofel, I knoq10:22
smartboyhwAnyway, piano practice is my 1st priority10:23
yofelbut it's easier if someone with upload permissions just does l10n10:23
smartboyhwI nominate yofel or shadeslayer 10:23
yofelno hurry with it anyway10:23
yofeloh hm, backporting to raring would have to be done in ninjas until the tars are public10:24
yofelalso nepomuk might get a respin10:24
yofelso lets wait10:24
smartboyhwyofel, nepomuk-core why?10:27
yofelsee release-team ML10:31
smartboyhwyofel, hmm I'm subscribed with no mail about it10:42
yofelsmartboyhw: http://lists.kde.org/?t=137598458700001&r=1&w=2 and http://lists.kde.org/?t=137598458900004&r=1&w=210:46
smartboyhwyofel, ookkkkk10:49
smartboyhwHas anyone here taken the SAT before?10:49
BluesKajHiyas all11:03
=== greyback is now known as greyback|lunch
=== greyback|lunch is now known as greyback
xnoxyofel: 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
xnoxi 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
BluesKajare you guys seeing mysql dependency problems on upgrades today? , we're getting reports of mysql depend troubles blocking upgrades on 13.04 12:46
smartboyhwBluesKaj, hmm for which package mysql was blocking13:11
ScottKBluesKaj: With -proposed enabled?13:28
ScottKThere was a bad SRU in -proposed that got pulled.13:28
ScottKxnox: Would you please coordinate the CMake stuff with MoDaX in Debian.13:29
xnoxScottK: ok. it needs to go upstream anyway, both multiarch findboost and multiple-pythons in findboost.13:29
ScottKI 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
ScottKOur version apparently isn't fully backward compatible.13:31
xnoxScottK: so i heard.14:06
xnoxyofel: kalzium rebuilds now in saucy.14:10
smartboyhwxnox, \o/14:11
yofelxnox: thanks a lot!14:45
ScottKHow close are to to 4.11.0 in saucy?15:22
smartboyhwScottK, only kalzium15:44
smartboyhwAnd a possible nepomuk-core fix from upstream15:44
* ScottK works on kopete ftbfs on ppc.16:46
ScottKKDE Bug 32331216:59
ubottuKDE bug 323312 in Jabber Plugin "Please update embedded libjingle" [Normal,Unconfirmed] http://bugs.kde.org/show_bug.cgi?id=32331216:59
xnoxScottK: is Kubuntu/KDE using qt5 yet?19:23
yofelxnox: no19:25
yofelkde frameworks 5 (kdelibs replacement) will be based on qt519:25
yofelcoming sometime next year19:25
xnoxyofel: before or after 14.04 =)19:26
xnoxyofel: ok.19:26
xnoxin that case, some time lines imposed by ScottK do not sound reasonable from Kubuntu's point of view.19:27
ScottKxnox: I'm not a "Kubuntu" release manager.  I'm part of the release team for the entire  project.19:28
xnoxScottK: 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
ScottKCore 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
ScottKIf 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
xnoxScottK: have we ever had a gtk or qt package without patches? has debian _ever_ had that?19:33
ScottKNo, 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
ScottKCurrently 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
xnoxScottK: who "we"?19:38
ScottKThe people working on that package.  ATM, myself and mitya57.19:39
ScottKOr Debian and Ubuntu if you prefer.19:39
ScottKWorks out the same.19:39
xnoxd_ed_: based around ubuntu releases, rather than qt releases.19:39
ScottKI know sometimes stuff needs to be patched.  I don't object to that.  I object to not caring about upstreaming.19:39
xnoxScottK: but i can't upstream changes into release qt 5.0 toolkit anymore. and they stopped taking patches for qt4.19:40
kubotuxnox meant: "ScottK: but i can't upstream changes into released qt 5.0 toolkit anymore. and they stopped taking patches for qt4."19:40
ScottKRight, but you can get them in 5.2.19:41
ScottKAnd there's stuff that never got into 4.8, but it got into 5.0.19:41
xnoxScottK: in that sense I interpret your stance as a deadlock, rather than advocating for proactive upstreaming.19:41
xnoxScottK: ack.19:42
ScottKNo.  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
xnoxScottK: 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 kernel19:49
d_ed_QPA plugins remain in the Qt tree19:50
xnoxd_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 things19: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 use19:52
d_ed_Styles (Oxygen, Plastique, Aqua, etc.) which can change minor things in widgets19:52
xnoxd_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
ScottKxnox: What platform is this?19:57
xnoxd_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
xnoxScottK: "Qt Platform Abstraction", or please elaborate your question.19:58
xnoxoh, i see i used same work twice with different meaning.19:58
ScottKWhat'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 answer19:58
soeewhats wrong with kscreen on raring ? it was stopped during upgrade ?20:00
xnoxd_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
xnoxd_ed_: i really cannot explode the matrix and have multiple qt flavours packages. and my app should run under all UIs.20:01
yofelsoee: apt-get install kscreen20:01
yofelsoee: we'll try to work that out ASAP20:02
xnoxd_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
yofelafiestas: ping again about libkscreen plugin namespacing. Possible or not?20:02
d_ed_xnox: so you're a Qt packager?20:03
xnoxd_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
xnoxd_ed_: that's my question above ^20:03
d_ed_so you're a ubuntu developer wanting to ship a Ubuntu platform?20:04
afiestasyofel: about what?20:04
xnoxd_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
yofelafiestas: 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
soeeyofel, 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 finished20:05
yofelafiestas: could we instead add the soversion to the plugin path so that they're co-installable?20:05
yofelafiestas: or would having 2 sets of plugins break something?20:06
yofel(linked against different libs)20:06
afiestaswhy do you want to co install them_20:06
xnoxafiestas: yes.20:07
xnoxafiestas: it's currently supported.20:07
yofelafiestas: because usually, the same library with different SOVERSIONS should be co-installable20:07
yofelas there are no file conflicts20:07
yofelonly the plugins break that20:07
yofeland apt doesn't really like that20:07
yofel(on upgrades)20:07
yofelwe're not yet sure *why* it doesn't like it though20:08
afiestaswell, we look in a folder for the plugins20:11
afiestasif we found 4, 2 of them with different abi we'll break20:12
d_ed_xnox: right, so everything will hopefully be a platform theme at some point20:12
d_ed_so you ship liqt.. .plus some platform themes20:12
afiestassiml;y replace them, nobody is using libkscreen and you don't want to ahve both versions20:12
d_ed_xnox: and there shouldn't be any additional patches/hacks anywhere20:12
yofelafiestas: you look in /usr/lib/kde4/plugins/, could libkscreen 1 not look in /usr/lib/kde4/plugins/kscreen1/  or so?20:12
yofeler, /usr/lib/kde4/plugins/kscreen20:13
yofelif we could make that /usr/lib/kde4/plugins/kscreen1, we would have no file conflicts, and you shouldn't find multiple sets of plugins20:13
yofelafiestas: we currently do replace them, but apt for *some stupid reason* refuses to do that20:14
yofelso the update is simply held back for most people20:14
afiestasbut they are conflicting aren't they?20:15
yofelthey do, because they both ship /usr/lib/kde4/plugins/kscreen20:15
yofelyou can't have 2 packages install the same files20:16
afiestasI can do that I guess, having it namespaces is always good but I can't do this now20:16
yofelok, thanks for the input.20:17
yofelwe'll try to debug apt in the meanwhile20:17
yofeldebfx: ^20:18
yofelJontheEchidna: do you know whether http://lists.kde.org/?l=kde-commits&m=136332005527708 did get a quantal SRU? (see #kubuntu)20:30
valoriewhat y'all do is so important! http://blog.sucuri.net/2013/08/open-source-backdoor-copyrighted-under-gnu-gpl.html20:46
yofelthat's evil :S21:00
ScottKIt's PHP, so it was evil to start with.  This is just another evil.21:05
valorieright, just an example21:10
alleeyofel: Why not just:  Conflicts: libkscreen0    Should work, at least for one of my local-only pkgs21:39
yofelit has21:40
yofelBreaks: libkscreen021:40
yofelReplaces: libkscreen021:40
yofelas it should by policy21:40
alleehmm breaks.  Time to reread policy ... 21:42
alleeyofel: 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
yofelallee: well, this is really about moving files from one package to another, which is Breaks21:54
yofelthough the 2nd paragraph of conflicts sounds interesting, maybe worth a try21:55
alleeIf the kscreen/KSC_*.so plugins are dynamicly load by libkscreenX  that IMHO they should be put into/usr/lib/kde4/plugins/libkscreenX 21:55
yofelas we said above21:56
alleeif not, they are better put into their own package e.g. kscreen-kcs  which would make libkscreen{0.1} koexists21:56
alleeand libkscreen(x-1) has no rdepends as soon as libkscreen(x) is installed and can stay on disk or autoremoved21:57
=== v_ is now known as v
alleeKCS_* 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
alleeafiestas: do the KCS_* plugins/backends use libkscreen or uses libkscreen the KCS* plugins/backends to abstract the impl. details away?22:17
yofelanyone an idea about this crash? http://paste.kde.org/p4945167a/22:19
yofelhappens when trying to use the kipi-plugins from digikam 3.3 on quantal and precise22:19
alleeMost kipi crashes AFAIR were due to pluging links libabcX and app links against libabcY22:24
yofelwell, this was built against the matching kde libs22:26
alleebut, e.g. libexiv, used by plugin and an app using the plugins can still be different soversion22:28
allee^^ not sure if it's the case here22:28
* allee tries to find a precise system with digikam 3.3. ....22:28
yofelwell, this was ksnapshot, crashes when I click on 'send to' trying to load the kipi plugins22:28
yofelallee: you won't, it's for testing in yofel/staging1 ppa22:29
yofelbuild against kde in kubuntu-ppa/backports22:29
afiestasallee: the second thing22:40
afiestasthough plugins link against kscreen and return classes defines adn exported there22:41
alleeokay. 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/libkscreenX22:47
ScottKThat could work.22:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!