path: root/meeting-logs/20110831.txt

[00:13:23] <tampakrap> !herd kde
[00:13:23] <willikins> (kde) abcd, alexxy, dilfridge, jmbsvicetto, mschiff, patrick, reavertm, spatz, tampakrap, thev00d00
[00:13:28] <tampakrap> meeting start
[00:13:32] <tampakrap> First topic: KDE 4.7.0 stabilization (without kdepim)
[00:13:43] <jmbsvicetto> +1
[00:13:45] <dilfridge> +1
[00:13:45] <tampakrap> dilfridge: reason to do so? we usually stabilize after the .0 release
[00:13:50] <dilfridge> no bugs
[00:13:57] <tampakrap> fyi i object, i have plenty
[00:14:04] <dilfridge> the upgrade went perfectly smooth here
[00:14:34] <dilfridge> and there are also no significand new things on bugzi
[00:14:35] <jmbsvicetto> tampakrap: I haven't hit any more bugs than usual
[00:14:39] <mschiff> but bugs is a general problem of kde not only 4.7.0, I am running 4.7.49.9999 here
[00:14:42] <tampakrap> fwiw kdepim works fine here as well, why don't we stabilize this one as well?
[00:14:53] <dilfridge> maybe with .2 `
[00:14:55] <dilfridge> ?
[00:15:09] <jmbsvicetto> I'll leave kdepim for those of you that actually use it :P
[00:15:18] <dilfridge> i use kdepim-4.4
[00:15:28] <tampakrap> kdepim 4.4 is obsolete, no bugfixes, no security updates
[00:15:29] <mschiff> kdepim is special: I think there the newest version is better these days
[00:15:35] <tampakrap> can't we keep them both and just notify users?
[00:15:39] <dilfridge> sure
[00:15:40] <tampakrap> and let them decide on what they want
[00:15:41] <mschiff> (speaking of the *2 versions)
[00:15:56] <tampakrap> but i still object on stabilizing .0, i have some plasma regressions
[00:16:04] <dilfridge> like?
[00:16:08] <tampakrap> and of course we don't get such bugs, since they are upstream
[00:16:17] <tampakrap> i have problem on focus
[00:16:17] <mschiff> I  guess .1 is not far away right?
[00:16:24] <dilfridge> has there ever been a version without plasma regressions?
[00:16:31] <tampakrap> another i have is that taskbar entries are not highlighted correctly
[00:16:32] <dilfridge> tagging tomorrow, technically
[00:16:44] <Thev00d00> release sept 6 isnt it?
[00:16:50] <mschiff> I have som eprobs here too: a windows that had a notify, tends to keep that status in the window bar
[00:17:04] <j0hu> but maybe messed up because of 2 migratet categories
[00:17:22] <dilfridge> ok
[00:17:26] <dilfridge> so 
[00:17:29] <Thev00d00> mschiff: I have the same, sticky red quassel for example
[00:17:39] <dilfridge> consensus seems to be more, stabilize 4.7.1
[00:17:41] <tampakrap> my opinion is to stabilize .1 (after a meeting decision) WITH kdepim
[00:17:46] <mschiff> Thev00d00: exactly, I think its what tampakrap also meant
[00:17:52] <tampakrap> but let the users know first
[00:17:59] <tampakrap> document everything etc
[00:18:08] <dilfridge> news item maybe
[00:18:08] <tampakrap> maybe even put a news item out as well
[00:18:20] <dilfridge> ok fine with me
[00:18:29] <alexxy> +1 for .1 with pim
[00:18:38] <dilfridge> anyone else?
[00:18:53] <mschiff> But 4.4 should stay in tree for some time
[00:18:58] <dilfridge> yes
[00:19:07] <dilfridge> I'll take care of it as good as possible
[00:19:15] <Thev00d00> +1 for .1
[00:19:24] <dilfridge> ok
[00:19:32] <dilfridge> then
[00:19:34] <tampakrap> ok, prepare a news item, and take care of the documentation then, and after next month's meeting we'll decide on 4.7.1
[00:19:48] <tampakrap> anything else?
[00:20:05] <mschiff> so not stabilize .1 as its available?
[00:20:11] <dilfridge> next topic then
[00:20:28] <tampakrap> no, after meeting
[00:20:36] <jmbsvicetto> tampakrap: I'd try to decide the stabilization by email
[00:20:53] <tampakrap> no problem
[00:20:54] <dilfridge> mschiff: at earliest 30days after release, so we have lots of time
[00:21:02] <tampakrap> anyway, next topic
[00:21:06] <tampakrap> 2) Road towards KDE 5 - what news is there from the Desktop Summit?
[00:21:16] <tampakrap> who was at the Desktop Summit?
[00:21:20] <tampakrap> ah that was me!!
[00:21:21] <dilfridge> you
[00:21:44] <tampakrap> so, i learned there that Qt 4.8 is NOT going to be split
[00:21:51] <tampakrap> Qt 5 will
[00:21:58] <dilfridge> into what?
[00:22:03] <tampakrap> and we have plenty of time to worry about KDE 5
[00:22:09] <alexxy> into small parts
[00:22:10] <alexxy> =)
[00:22:14] <alexxy> even atoms
[00:22:22] <tampakrap> even Thiago didn't tell me details
[00:22:26] <dilfridge> oh dear, radiation alert
[00:22:29] <bonsaikitten> I'd *really* like split tarballs
[00:22:36] <alexxy> tampakrap: is there any eta for kde5?
[00:22:39] <bonsaikitten> a 200M download when you need 10M is a bit sad
[00:22:46] <alexxy> about a year or so?
[00:22:51] <tampakrap> not yet, but we have plenty of time
[00:22:52] <j0hu> work started in kdelibs
[00:23:00] <j0hu> framework branch
[00:23:07] <tampakrap> and they won't do big changes like the 3->4 transition
[00:23:41] <tampakrap> that's what some core KDE developers (like Aaron Seigo and David Faure) said in their presentation
[00:23:59] <dilfridge> will there be a kde 4.8?
[00:24:03] <tampakrap> yes
[00:24:11] <jmbsvicetto> but Alex has been talking about using the bump to get some ABI incompatible changes
[00:24:31] <alexxy> also seems something is going to happen with nepomuk
[00:24:33] <jmbsvicetto> that has been mentioned multiple times in the release ml
[00:24:37] <tampakrap> that was the plan, it changed somewhere in the middle
[00:24:45] <dilfridge> hmm
[00:24:52] <tampakrap> unless you are talking about something else
[00:25:15] <dilfridge> I heard some rumour about kdelibs basically remaining at 4.7?
[00:25:46] <tampakrap> i also took part in a release team BoF along with Slackware, Fedora, openSUSE packagers and a GNOME release team guy
[00:25:58] <tampakrap> chaired by Sebastian Krugler and Dirk Muller
[00:25:59] <jmbsvicetto> Alex also worked on getting all KDE cmake files that were ok for kitware into 4.8.0 (?) and created the new cmake-extras packages
[00:26:02] <jmbsvicetto> package*
[00:26:20] <tampakrap> they talked about the splitting of modules, how to handle it and about future KDE releases
[00:26:28] <jmbsvicetto> dilfridge: They've been saying there won't be a kdelibs-4.8
[00:26:36] <dilfridge> ok
[00:26:41] <tampakrap> so nothing big is expected
[00:27:04] <tampakrap> are you talking about the superbuild package?
[00:27:20] <jmbsvicetto> No, that was their "reply" to slackware
[00:27:46] <tampakrap> no idea what you're talking about then
[00:27:57] <tampakrap> afaik there will be kdelibs 4.8 and KDE SC 4.8
[00:27:59] <jmbsvicetto> The cmake-extras package is a package that Alex has "sponsored" to have all cmake files that can't be accepted into cmake by kitware
[00:28:09] <tampakrap> ah yes
[00:28:13] <tampakrap> i recall now
[00:28:18] <jmbsvicetto> tampakrap: that's not what has been talked in the kde relase ml
[00:28:21] <tampakrap> what does have to do with us?
[00:28:21] <dilfridge> Alex ?
[00:28:33] <jmbsvicetto> but I haven't talked to anyone about this nor was I at the Desktop summit :P
[00:28:33] <tampakrap> Alexander Neundorf, main buildsystem guy
[00:28:35] <dilfridge> ah
[00:28:50] <tampakrap> i follow the kde release team, never saw such thing :/
[00:29:15] <jmbsvicetto> tampakrap: What I'm saying is that they've talked about doing incompatible changes. I hear from you that is not what they're going to do
[00:29:36] <tampakrap> they were, but things changed in Qt, thus in KDE
[00:29:42] <tampakrap> that's what i know so far
[00:30:13] <jmbsvicetto> but they had also decided on not having KDE/<version> branches and just <version> branches and now in the kde-scm ml they're almost reverting that because of the talks other KDE devs had on kde-core-devel that appearantly didn't follow the kde-release or kde-scm mls
[00:30:27] <jmbsvicetto> tampakrap: ok
[00:30:49] <tampakrap> anyway
[00:31:03] <tampakrap> if big changes are going to come we'll know them in time
[00:31:07] <tampakrap> we always did
[00:31:08] <dilfridge> true
[00:31:44] <tampakrap> https://plus.google.com/photos/116381667574498856310/albums/5637225108859383905 <-- and here are the photos for those who haven't seen them, to make you jealous
[00:31:50] <dilfridge> :D
[00:31:59] <tampakrap> anything else here?
[00:32:12] <dilfridge> not from me
[00:32:29] <jmbsvicetto> or me
[00:32:57] <dilfridge> ok
[00:32:57] <tampakrap> 3) The NetworkManager-0.9 mess
[00:33:03] <dilfridge> hehe
[00:33:05] <tampakrap> no idea here
[00:33:09] <dilfridge> the basic summary is
[00:33:23] <dilfridge> A gnome-3 requires networkmanager-0.9
[00:33:37] <dilfridge> B kde does not support networkmanager-0.9
[00:33:52] <dilfridge> A seems to be set in stone
[00:33:57] <alexxy> dilfridge: knetworkmanager works fine with nm09
[00:34:04] <dilfridge> B is being worked on
[00:34:07] <dilfridge> yes
[00:34:14] <alexxy> and i use this combination on my laptop
[00:34:16] <jmbsvicetto> dilfridge: wasn't the delay on solid?
[00:34:27] <alexxy> also in git master of kdelibs there is a stub for nm09
[00:34:33] <alexxy> for solid
[00:34:38] <dilfridge> what alexxy is using and what we have in the tree now is the nm09 branch
[00:34:38] <jmbsvicetto> I don't use knetworkmanager, nor networkmanager, so I don't know anything about it
[00:35:00] <dilfridge> that is basically sponsored by fedora, as they have the same problem
[00:35:04] <dilfridge> and it seems to work ok
[00:35:13] <alexxy> it mostly works
[00:35:16] <alexxy> excetp wimax
[00:35:17] <alexxy> =)
[00:35:34] <alexxy> so my cell modem and wifi + vpn works fine
[00:35:43] <tampakrap> didn't someone put a masked knetworkmanager 0.9 compatible in tree?
[00:35:46] <dilfridge> the only problem with it is that the knetworkmanager developers do not really support it but have different plans (or lack of motivation)
[00:35:52] <dilfridge> tampakrap: yes me
[00:36:04] <dilfridge> basically it is a fedora-fork
[00:36:09] <alexxy> dilfridge: no
[00:36:15] <alexxy> its different approcah
[00:36:30] <alexxy> fedora has patched nm09 with nm08 compatibility layer
[00:36:41] <dilfridge> nm or knm?
[00:36:46] <alexxy> nm
[00:36:52] <tampakrap> knetworkmanager developers were in summit, why didn't you tell me earlier to talk to them? :/
[00:36:53] <dilfridge> strange
[00:36:59] <dilfridge> anyway
[00:37:01] <alexxy> and its own patched version of knm
[00:37:21] <mschiff> oh dear :-/
[00:37:21] <dilfridge> probably the best thing is to just stick to the nm09 branch
[00:37:23] <alexxy> there 3 impletation of nm09 support in knm
[00:37:34] <alexxy> first one is fedora
[00:37:45] <alexxy> second nm09 branch from knm devs
[00:37:52] <alexxy> and third libqtnm
[00:38:00] <alexxy> that is worked on
[00:38:08] <alexxy> we use second one
[00:38:15] <alexxy> since its only working
[00:38:15] <tampakrap> what's libqtnm?
[00:38:34] <alexxy> i dont remember how its called correctly
[00:38:40] <tampakrap> anyway
[00:38:45] <alexxy> but they want to create qt lib fro nm
[00:38:45] <dilfridge> alexxy: shall we continue using nm09 branch, what do you think?
[00:38:45] <tampakrap> since it works, and it is in tree
[00:38:49] <tampakrap> what is the problem?
[00:39:02] <dilfridge> tampakrap: there is no real problem
[00:39:08] <alexxy> dilfridge: i think that it will be best chois at this time
[00:39:25] <dilfridge> the purpose was only to make people aware that this may become problem at some time
[00:39:34] <dilfridge> but right now I agree with alexxy
[00:39:42] <tampakrap> summarize the problem please, i'm confused
[00:39:59] <alexxy> dilfridge: there will be no problems with migration
[00:40:09] <alexxy> since nm settings are stored by nm
[00:40:10] <dilfridge> chaotic situation, many different approaches, no clear upstream
[00:40:15] <alexxy> and not by applet
[00:40:47] <dilfridge> alexxy: ok
[00:40:53] <dilfridge> so summary: no problem
[00:40:57] <dilfridge> :D
[00:40:57] <tampakrap> but we have something that works at the moment, so let's just wait for upstream to fix their mess
[00:41:13] <dilfridge> ok 
[00:41:16] <dilfridge> next point?
[00:41:18] <tampakrap> next issue
[00:41:31] <dilfridge> meh it's me again
[00:41:34] <tampakrap> 4) Does anyone still have an overview of the glib-networking/libproxy problem?
[00:42:05] <dilfridge> pacho was quite insistent that we have a look at this
[00:42:15] <dilfridge> because it blocks a big fat sec bug
[00:42:58] <tampakrap> i don't use that app at all
[00:43:49] <dilfridge> it's pulled in eg by firefox
[00:44:15] <dilfridge> I went through the >100 comments and tried to make sense of it yesterday
[00:44:20] <jmbsvicetto> dilfridge: I can't help as I don't use it as well
[00:44:30] <dilfridge> I never had the problem myself either
[00:44:34] <tampakrap> which flag in firefox?
[00:44:45] <dilfridge> dont remember sorry
[00:44:57] <tampakrap> a guy put a summary there did you look at it?
[00:45:14] <dilfridge> yes, me :]... I *believe* the problem is fixed
[00:45:22] <dilfridge> but believing = not knowing
[00:45:31] <dilfridge> does anyone else know anything?
[00:45:54] <mschiff> I do not have it installed
[00:45:58] <dilfridge> I recommend the gnome guys just go ahead...
[00:46:04] <tampakrap> any dupes? any activity in the bug?
[00:46:21] <dilfridge> not anymore for a while (that's why I think it's ok now)
[00:46:42] <tampakrap> go on then
[00:46:56] <dilfridge> ok I'll tell them to just go ahead
[00:47:08] <tampakrap> next topic
[00:47:21] <tampakrap> 5) Suggestion - splitting the Gentoo KDE Guide into two pages
[00:47:21] <tampakrap> 1) main page: main tree, stable and ~arch things only
[00:47:21] <tampakrap> 2) poweruser page: overlay, live ebuilds, sets, kde-sunset
[00:47:31] <tampakrap> who added this topic?
[00:47:33] <dilfridge> my suggestion 
[00:47:38] <dilfridge> and I'd be willing to do it
[00:47:45] <dilfridge> but only if you think it's good
[00:47:47] <tampakrap> that's a no :)
[00:48:02] <tampakrap> from the very beginning i wanted that guide to be monolithic
[00:48:14] <tampakrap> else there will be a lot of duplication
[00:48:40] <tampakrap> plus readers will be able to jump from one topic to another (eg see the existence of the overlay quickly, and maybe prefer the live ebuilds or snapshots)
[00:49:01] <tampakrap> there are tags there as well, append #kde4_6 and similar
[00:49:02] <mschiff> I think it should always be clear what the guides refers to: ~arch or stable
[00:49:11] <tampakrap> it is
[00:49:45] -*- dilfridge is slightly distracted by some dirndls walking past the window
[00:49:47] <tampakrap> people don't go by branch, they go by KDE version
[00:50:39] <tampakrap> anyway, anything else here?
[00:50:42] <dilfridge> no
[00:50:48] <j0hu> the guide needs update
[00:51:09] <tampakrap> what kind of update?
[00:51:15] <j0hu> hald
[00:51:18] <j0hu> --
[00:51:23] <dilfridge> the removal instructions
[00:51:33] <j0hu> live branches
[00:51:37] <j0hu> not correct
[00:51:52] <tampakrap> true, give me a patch :)
[00:52:08] <mschiff> I hald really still being used?
[00:52:15] <j0hu> and maybe some info from the upgrade 4.4 guide
[00:52:24] <dilfridge> mschiff: no
[00:52:33] <tampakrap> j0hu: are you willing to update it?
[00:52:45] <dilfridge> should we kill the upgrade guide and merge some info into the main guide?
[00:52:50] <j0hu> will do after finishing the quizz
[00:53:08] <tampakrap> merge info: yes, kill the upgrade guide: not yet
[00:53:31] <tampakrap> anything else?
[00:53:50] <j0hu> go ahead
[00:53:59] <dilfridge> not here
[00:54:11] <tampakrap> 6) Build system architecture bug
[00:54:15] <tampakrap> +s
[00:54:24] <tampakrap> bug 358059
[00:54:26] <willikins> tampakrap: https://bugs.gentoo.org/358059 "cmake-utils.eclass PREFIX is not defined"; Gentoo Linux, Eclasses and Profiles; CONF; meka:kde
[00:54:45] <dilfridge> no idea about the consequences
[00:55:02] <dilfridge> I was kind of hoping that reavertm would turn up
[00:57:06] <tampakrap> if it is defined either way
[00:57:12] <tampakrap> why defining it earlier is a problem?
[00:59:02] <mschiff> but wha does the patch kill the /usr default?
[00:59:15] <dilfridge> I dont understand problem nor solution
[00:59:28] <mschiff> I only looked at the patch
[00:59:40] <dilfridge> mschiff: see line 7
[01:00:01] <dilfridge> I'm more concerned about lines 32/33
[01:00:29] <dilfridge> why suddenly add the prefix at a place where it was not needed before?!
[01:01:20] <mschiff> hm, seems a bit strange to me
[01:01:40] <tampakrap> this is wrong indeed
[01:01:44] <mschiff> seems like $libdir must not be set this way
[01:01:46] <tampakrap> the rest is fine imho
[01:02:10] <mschiff> if it was set to /usr it will end up in /usr/usr/lib
[01:02:45] <dilfridge> ok shall we kill the 32/33 chunk and test the rest in the  overlay?
[01:03:03] <tampakrap> not sure
[01:03:08] <dilfridge> me neither
[01:03:08] <tampakrap> we need more eyes indeed
[01:03:19] <tampakrap> CC scarabeus and reavertm there and ask them
[01:03:22] <dilfridge> I'll try to persuade scarabeus
[01:03:25] <dilfridge> yes
[01:03:36] <dilfridge> next one
[01:03:44] <mschiff> the rest ist nothing special
[01:03:54] <mschiff> 32/33 is the only real change
[01:04:07] <tampakrap> ok
[01:04:09] <tampakrap> next
[01:04:13] <tampakrap> bug 356681
[01:04:15] <willikins> tampakrap: https://bugs.gentoo.org/356681 "Please remove media-libs/phonon dependency from kde-base/kdelibs"; Gentoo Linux, Ebuilds; CONF; hwoarang:kde
[01:04:32] <tampakrap> i don't like this one, and i am not willing to work on this
[01:04:45] <tampakrap> jmbsvicetto: is it a good solution to create a virtual/phonon?
[01:05:41] <dilfridge> I fear that the number of problem sources could explode with more than one implementation :|
[01:05:56] <jmbsvicetto> sorry, I was looking at the patch for the previous bug
[01:06:01] <dilfridge> YEEEHAH
[01:06:03] <tampakrap> can we hide it under a kde flag?
[01:06:09] <jmbsvicetto> btw, the only "real change" in there seems to be the following:
[01:06:10] <jmbsvicetto> -                SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output directory for libraries")
[01:06:11] <ABCD> ...sorry I missed most of the meeting (I just got back from a family dinner, which I was rudely informed was more important than this :D)
[01:06:11] <dilfridge> err sorry
[01:06:13] <jmbsvicetto> +                SET (CMAKE_INSTALL_LIBDIR ${PREFIX}/${libdir} CACHE PATH "Output directory for libraries")
[01:06:22] -*- dilfridge just read "CURRENT STATUS OF MANUSCRIPT: Editorially approved for publication"
[01:06:53] <mschiff> jmbsvicetto: thats what I was saying
[01:06:57] -*- alexxy still waits for similar resolution from jpcs
[01:06:59] <jmbsvicetto> about phonon, are they compatible now?
[01:07:00] <mschiff> and in the eclass:
[01:07:04] <mschiff> # Eclass respects PREFIX variable, though it's not recommended way to set
[01:07:04] <mschiff> # install/lib/bin prefixes.
[01:07:04] <mschiff> # Use -DCMAKE_INSTALL_PREFIX=... CMake variable instead.
[01:07:22] <jmbsvicetto> cause qt-phonon was behind phonon for a long time
[01:07:39] <tampakrap> no idea about qt-phonon
[01:07:43] <tampakrap> and i don't care tbh
[01:07:56] <jmbsvicetto> I'll see what I can do about this one
[01:08:14] <jmbsvicetto> I still think we should prefer media-libs/phonon to x11-libs/qt-phonon, though
[01:08:15] <tampakrap> i'm asking if a virtual is fine, or if we can do this but introduce a kde useflag there so that media-libs/phonon is default
[01:09:03] <dilfridge> we could say something like " kde? ( media-libs/phonon )  !kde? ( virtual/phonon ) "
[01:09:17] <jmbsvicetto> dilfridge: kdelibs?
[01:09:23] <dilfridge> f.ex.
[01:09:31] <tampakrap> yes, in other kde apps as well
[01:09:34] <dilfridge> if that is possible and even works
[01:09:35] <tampakrap> i like it
[01:09:46] <jmbsvicetto> dilfridge: if so, how's that any different from the current || ( media-libs/phonon x11-libs/qt-phonon ) ?
[01:09:58] <tampakrap> anyone willing to work on these? (virtual/phonon AND qt-phonon for kdelibs)
[01:10:15] <dilfridge> with !kde you can run kdelibs also with qt-phonon then
[01:10:20] <dilfridge> not me
[01:10:20] <tampakrap> a guy with -kde can get qt-phonon
[01:10:22] <jmbsvicetto> tampakrap: I'll have to check, but we used to support qt-phonon on kdelibs. We just defaulted to phonon
[01:10:37] <jmbsvicetto> I'll work on it
[01:10:45] <dilfridge> ok cool
[01:10:46] <jmbsvicetto> dilfridge: then someone dropped the old conditional
[01:10:49] <tampakrap> ok, have a look at both the virtual and the kde flag
[01:11:10] <jmbsvicetto> tampakrap: I don't know if we gain anything with the virtual (for KDE)
[01:11:30] <tampakrap> i believe we are
[01:11:41] <tampakrap> not only for kdelibs, but for other kde apps
[01:12:00] <tampakrap> put virtual/phonon there instead of the conditional you pasted earlier
[01:12:03] <tampakrap> seems cleaner
[01:12:20] <jmbsvicetto> until you think how to prefer media-libs/phonon over x11-libs/qt-phonon
[01:12:53] <tampakrap> that's for kdelibs (solved by the flag)
[01:13:08] <tampakrap> other kde or non-kde apps don't need to prefer anything
[01:13:08] <jmbsvicetto> I'll look at it and then talk to you
[01:13:13] <tampakrap> sure
[01:13:28] <tampakrap> bug 332829
[01:13:30] <willikins> tampakrap: https://bugs.gentoo.org/332829 "Inconsistency between distro's KDE4WorkspaceConfig.cmake and the actual layout"; Gentoo Linux, Library; CONF; cheepeero:kde
[01:13:50] <tampakrap> i talked about it with reavertm, someone needs to work on it
[01:13:54] <tampakrap> 99% it will work
[01:14:16] <dilfridge> tampakrap: tell me if you need chroot testing
[01:14:33] <dilfridge> not sure if anyone wants to do this in his main system first
[01:14:37] <tampakrap> i can't work on it, someone else has to do it
[01:14:59] <tampakrap> volunteers?
[01:15:08] <mschiff> whats this about?
[01:15:28] <dilfridge> the internal configuration of the kde build variables is somehow messed up
[01:15:53] <dilfridge> it makes problems for building apps outside portage
[01:16:27] <dilfridge> that's about my whole understanding
[01:16:42] <mschiff> so do we have some qt developer in the team?
[01:16:54] <jmbsvicetto> dilfridge: that whole deal of building apps outside of portage, is something we should probably talk about again
[01:16:57] <Sput> oh
[01:17:03] -*- Sput forgot to check this channel
[01:17:07] <tampakrap> ABCD: ^^ wanna work on it?
[01:17:20] <dilfridge> Sput: do you use kdevelop?
[01:17:23] <tampakrap> mschiff: that needs cmake understanding, not Qt
[01:17:33] <tampakrap> it is easy to test, there is a patch there already
[01:17:50] <jmbsvicetto> when we started with kde-4.X, we were clear that we supported portage and building packages with our ebuilds (we have ebuilds for all releases, snapshots and live) and that we wouldn't bother with supporting people that want to install software outside portage
[01:17:57] <jmbsvicetto> I still think that should be our stance
[01:18:06] <mschiff> tampakrap: yeah I meant someone who is gerneally developing something with qt or kde...
[01:18:32] <dilfridge> jmbsvicetto: yes but if someone wants to use kdevelop?
[01:18:40] <ABCD> dilfridge: RESO:CANTFIX; KDE4WorkspaceConfig.cmake can only be installed by one package (for hopefully obvious reasons), yet must change when other packages are installed (breaking checksums) :)
[01:19:01] <dilfridge> like, use the application to program something?
[01:19:11] <jmbsvicetto> dilfridge: if I understand the issue, get upstream to do a release
[01:19:56] <jmbsvicetto> dilfridge: if the problem is with testing applications built with kdevelop, I'd say the real issue is cmake
[01:20:00] <dilfridge> jmbsvicetto: no, I mean if upstream is using gentoo?!
[01:20:15] <jmbsvicetto> dilfridge: I know how much KDE developers hated auto-tools, but this is a price you pay for using cmake
[01:20:37] <dilfridge> well... it's not really my problem
[01:20:55] <dilfridge> what I could do is feed the patch into a chroot and rebuild kde
[01:21:00] <dilfridge> and look at the result
[01:21:09] <tampakrap> ok
[01:21:34] <dilfridge> do you think that would be enough testing?
[01:21:46] <tampakrap> the package is libkworkspace, file is /usr/lib/cmake/KDE4Workspace/KDE4WorkspaceConfig.cmake
[01:21:54] <tampakrap> and build kdevelop from source
[01:21:55] <jmbsvicetto> dilfridge: I've talked with Diego about the next bug, and even though we shouldn't be setting RPATH to /usr (KDE), if I understood the issue correctly, that alone won't fix the issue as the other applications (kdevelop?) are setting RPATH themselves
[01:22:34] <dilfridge> bug 380415
[01:22:37] <willikins> dilfridge: https://bugs.gentoo.org/380415 "Qt and KDE libs and plugins should not have an RPATH"; Gentoo Linux, KDE; CONF; realnc:kde
[01:22:49] <jmbsvicetto> we could also drop the /usr/qt4 RPATH for QT as it's part of LDPATH
[01:22:56] <dilfridge> tampakrap: could this be fixed in qt?
[01:23:04] <tampakrap> i can't decide
[01:23:18] <dilfridge> hehe agenda topic for next qt meeting
[01:23:27] <jmbsvicetto> One issue I talked to Diego but didn't understand is what kind of impact this might have for security
[01:23:27] <tampakrap> sure, can you test beforehand?
[01:23:31] -*- dilfridge pushes the pile of papers to the next guy
[01:23:39] <Sput> just reading backlog... fwiw, I've been using nm09 with knetworkmanager and USE=nm09 for quite a while, it works fine
[01:24:06] <dilfridge> if anyone tells me how to disable RPATH in qt, yes
[01:24:27] <Sput> and there won't be a kdelibs-4.8 release (the master branch is frozen now, and people are working in the frameworks branch)
[01:24:53] <jmbsvicetto> The user on that bug seems to want the QT/KDE libs built without RPATH so that if he builds and installs an app in /usr/local and (as I understand it), he adds a plugin to /usr/local the lib will "link" to that plugin - my question is won't that allow having system libs linking to user-controlled paths? That sounds dangerous
[01:25:21] <dilfridge> jmbsvicetto: only if they are in LDPATH I guess
[01:25:29] <ABCD> jmbsvicetto: the point with Qt's RPATH of /usr/lib*/qt4 is that the qt team was going to *drop* it from LDPATH as soon as was practical
[01:25:35] <jmbsvicetto> The issue is that they are not in LDPATH
[01:25:56] <jmbsvicetto> better put, that is the complaint and what Diego was pointing out. If it's not in LDPATH it won't "magically" work
[01:26:00] <dilfridge> and if someone is adding a local dir to LDPATH before system dir, that is his own stupidity
[01:26:25] <jmbsvicetto> ABCD: understood. That means the request cannot be fulfilled then
[01:26:40] <jmbsvicetto> dilfridge: sure
[01:27:04] <jmbsvicetto> dilfridge: but what they wanted was the libs to have no rpath so they could "link" to a lib anywhere - that's what sounds dangerous to me
[01:27:22] <ABCD> dilfridge: the default actually puts /usr/local/lib first before everything else (note, /usr/local/lib64 isn't mentioned until after /lib64 and /usr/lib64)
[01:27:32] <Sput> dilfridge: and I don't use KDevelop at the moment
[01:27:39] <jmbsvicetto> dilfridge: even though, from what Diego told me, that won't work as without RPATH the system will only look under LDPATH
[01:27:39] <dilfridge> /usr/local/lib is still root:root
[01:27:41] <ABCD> see /etc/env.d/00basic
[01:27:49] <ABCD> true :)
[01:28:44] <dilfridge> ok I guess this is effectively going to be decided by the qt team
[01:28:48] <jmbsvicetto> so I don't know enough about this, but hope any change we do won't open any unwanted "doors"
[01:29:47] <dilfridge> any more thoughts about this?
[01:29:52] <jmbsvicetto> dilfridge / tampakrap: No comments or objections from me to the next 2 (final) items
[01:30:42] <dilfridge> the last two items are the simple ones
[01:30:51] <tampakrap> no objections from me either
[01:31:16] <dilfridge> my opinion: a) add libXkbfile globally, b) remove the useflag
[01:31:43] <tampakrap> yes and yes
[01:31:43] <ABCD> do the libs/progs with RPATH set also have RUNPATH set? If so, then LD_LIBRARY_PATH overrides it anyway, so... :D
[01:32:56] <ABCD> (I think cmake uses the proper ld(1) options that make the linker set DT_RPATH *and* DT_RUNPATH)
[01:32:56] <Sput> as for the Qt5/KDE5 thingy: Qt5 will be released next spring or so, KDE will take longer... work on kdelibs is going on in the framework branch
[01:33:04] <dilfridge> >:|
[01:33:24] <Sput> we need the qt herd to provide us with Qt5 ebuilds soonish (and I hope the eclasses still support proper slotting)
[01:33:44] <ABCD> I think some eclass magic is needed to make kdefoo 4.8 depend on kdelibs >= 4.7.0
[01:33:48] <dilfridge> Sput: argh... which gets back to the last issue
[01:33:48] <tampakrap> Sput: i thought frameworks is going to be kdelibs 4.8
[01:33:55] <dilfridge> ABCD: yes but that is doable
[01:34:01] <Sput> tampakrap: no, frameworks is not going to be 4.8
[01:34:10] <Sput> there won't be a kdelibs-4.8
[01:34:10] <ABCD> dilfridge: that is "I think I'm going to have to write some eclass magic ..."
[01:34:12] <tampakrap> and what is it going to be then?
[01:34:46] <tampakrap> ABCD: or fakebump kdelibs to 4.8 :)
[01:34:51] <Sput> well, probably what we call "KDE 5" although I'm sure the KDE promo team is going to come up with yet another naming scheme in time :P
[01:34:54] <ABCD> tampakrap: too much work :D
[01:35:07] <ABCD> Sput: there is no KDE 4, so how could there be a KDE 5? :)
[01:35:11] <dilfridge> Sput: indeed
[01:35:18] <tampakrap> ok let's wait then
[01:35:22] <ABCD> KDE is a community, you can't attach a version number to something like that :)
[01:35:22] <Sput> ABCD: exactly
[01:35:22] <dilfridge> Bulshytt!
[01:35:26] <jmbsvicetto> tampakrap: that's why last time there was a talk on #-kde about this I said we were going to have some fun like in the early KDE-4 days
[01:35:56] <Sput> the frameworks branch ist going to be the next incarnation of kdelibs, currently they work on reorganizing/cleaning up/splitting kdelibs, as soon as Qt5 is released they'll port it over
[01:36:01] <jmbsvicetto> tampakrap: we're going to have kde-4.8 depending on kdelibs-4.7 and we may even have kdeA-4.8, kdeB-4.9, etc
[01:36:03] <Sput> the rest of KDE will follow suit only later
[01:36:28] <tampakrap> jmbsvicetto: that's only assumptions, just wait for the release
[01:36:29] <ABCD> if upstream slots things properly, I think we should slot; otherwise everything goes in :4 (which we might want to make :0 instead :D)
[01:36:37] <Sput> there will be more kdelibs-4.7.x releases, but I don't think a 4.8 ever unless they changed plans again
[01:36:50] <dilfridge> ABCD: nononono, what with :4 and :5 then? :O
[01:37:11] <Sput> we certainly will have to slot Qt versions
[01:37:14] -*- dilfridge thinks we cannot really predict the upcoming chaos
[01:37:16] <jmbsvicetto> ABCD: no gain in moving to :0 again
[01:37:17] <Sput> not sure about KDE
[01:37:26] <jmbsvicetto> ABCD: besides, don't forget some people still use kde-3.5 ;)
[01:37:44] <dilfridge> Enable auto-destruct sequence
[01:37:50] <tampakrap> Sput: qt is slot 4, isn't that sufficient?
[01:38:05] <j0hu> some people dont know how to remove 3.5 :P
[01:38:05] <Sput> tampakrap: it is, if slotting still works in the eclasses
[01:38:26] <tampakrap> it is, why shouldn't it? :)
[01:38:35] <tampakrap> anyway, people, don't panic
[01:38:43] <Sput> tampakrap: well, we've removed proper slotting support from the KDE eclasses
[01:38:48] <Sput> who knows what the qt herd did :)
[01:38:51] <tampakrap> you are all making assumptions here, just wait for the next release to show up
[01:38:55] <jmbsvicetto> tampakrap: because it hasn't been tested in a long time ;)
[01:39:06] <tampakrap> lol
[01:39:15] <Sput> tampakrap: well, Qt5 is already under development (and I will start working with it in a few days), I'd love to be able to install it into Gentoo
[01:39:23] <Sput> (without removing qt4 obviously)
[01:39:46] <jmbsvicetto> Sput: unless we get ABI deps, I suspect you're going to have *great* pain trying that
[01:40:07] <tampakrap> true, nothing's going to be so smooth for sure
[01:40:09] <dilfridge> unless every binary sets the correct RPATH :P
[01:40:14] <tampakrap> major versions ahead, red flag
[01:40:34] <Sput> jmbsvicetto: well, used to be the case that just calling the correct qmake version would set everything up correctly...
[01:41:01] <dilfridge> this is going nowhere
[01:41:02] <Sput> I'm just saying, we need to be aware of Qt5 being right around the corner already
[01:41:06] <dilfridge> let's just wait and see
[01:41:12] <Sput> it's not something that'll hit us in a few years
[01:41:18] <jmbsvicetto> tampakrap: no need for anyone to stuck his head in the ground, but it's probably wise to look over the ship's border in case a huge wave rocks the boat ;)
[01:41:20] <tampakrap> dilfridge: this is open floor, of course it's not going nowhere :)
[01:41:33] -*- dilfridge gets himself a drink
[01:41:39] -*- Sput has a beer
[01:41:49] -*- tampakrap drunk his already
[01:41:52] <nirbheek> meetings are long, eh :)
[01:41:57] -*- Sput has moar in the fridge
[01:41:58] <tampakrap> and btw, MEETING IS OFF
[01:42:08] <tampakrap> summary tomorrow