From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qyv1B-0004O4-Do for garchives@archives.gentoo.org; Thu, 01 Sep 2011 00:20:30 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0FBF21C045; Thu, 1 Sep 2011 00:20:20 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 7821321C045 for ; Thu, 1 Sep 2011 00:20:20 +0000 (UTC) Received: from flycatcher.gentoo.org (flycatcher.gentoo.org [81.93.255.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id C192E1B4020 for ; Thu, 1 Sep 2011 00:20:19 +0000 (UTC) Received: by flycatcher.gentoo.org (Postfix, from userid 2276) id 831E320051; Thu, 1 Sep 2011 00:20:18 +0000 (UTC) From: "Andreas HAttel (dilfridge)" To: gentoo-commits@lists.gentoo.org Reply-To: gentoo-dev@lists.gentoo.org, dilfridge@gentoo.org Subject: [gentoo-commits] gentoo commit in xml/htdocs/proj/en/desktop/kde/meeting-logs: kde-project-meeting-log-20110831.txt X-VCS-Repository: gentoo X-VCS-Files: kde-project-meeting-log-20110831.txt X-VCS-Directories: xml/htdocs/proj/en/desktop/kde/meeting-logs X-VCS-Committer: dilfridge X-VCS-Committer-Name: Andreas HAttel Content-Type: text/plain; charset=utf8 Message-Id: <20110901002018.831E320051@flycatcher.gentoo.org> Date: Thu, 1 Sep 2011 00:20:18 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 47fe6b48d3452024a16d1f5e5b5252bf dilfridge 11/09/01 00:20:18 Added: kde-project-meeting-log-20110831.txt Log: Added meeting log Revision Changes Path 1.1 xml/htdocs/proj/en/desktop/kde/meeting-logs/kde-proj= ect-meeting-log-20110831.txt file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/des= ktop/kde/meeting-logs/kde-project-meeting-log-20110831.txt?rev=3D1.1&view= =3Dmarkup plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/des= ktop/kde/meeting-logs/kde-project-meeting-log-20110831.txt?rev=3D1.1&cont= ent-type=3Dtext/plain Index: kde-project-meeting-log-20110831.txt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [00:13:23] !herd kde [00:13:23] (kde) abcd, alexxy, dilfridge, jmbsvicetto, mschif= f, patrick, reavertm, spatz, tampakrap, thev00d00 [00:13:28] meeting start [00:13:32] First topic: KDE 4.7.0 stabilization (without kdep= im) [00:13:43] +1 [00:13:45] +1 [00:13:45] dilfridge: reason to do so? we usually stabilize a= fter the .0 release [00:13:50] no bugs [00:13:57] fyi i object, i have plenty [00:14:04] the upgrade went perfectly smooth here [00:14:34] and there are also no significand new things on bu= gzi [00:14:35] tampakrap: I haven't hit any more bugs than usua= l [00:14:39] but bugs is a general problem of kde not only 4.7.0,= I am running 4.7.49.9999 here [00:14:42] fwiw kdepim works fine here as well, why don't we = stabilize this one as well? [00:14:53] maybe with .2 ` [00:14:55] ? [00:15:09] I'll leave kdepim for those of you that actually= use it :P [00:15:18] i use kdepim-4.4 [00:15:28] kdepim 4.4 is obsolete, no bugfixes, no security u= pdates [00:15:29] kdepim is special: I think there the newest version = is better these days [00:15:35] can't we keep them both and just notify users? [00:15:39] sure [00:15:40] and let them decide on what they want [00:15:41] (speaking of the *2 versions) [00:15:56] but i still object on stabilizing .0, i have some = plasma regressions [00:16:04] like? [00:16:08] and of course we don't get such bugs, since they a= re upstream [00:16:17] i have problem on focus [00:16:17] I guess .1 is not far away right? [00:16:24] has there ever been a version without plasma regre= ssions? [00:16:31] another i have is that taskbar entries are not hig= hlighted correctly [00:16:32] tagging tomorrow, technically [00:16:44] release sept 6 isnt it? [00:16:50] I have som eprobs here too: a windows that had a not= ify, tends to keep that status in the window bar [00:17:04] but maybe messed up because of 2 migratet categories [00:17:22] ok [00:17:26] so=20 [00:17:29] mschiff: I have the same, sticky red quassel for e= xample [00:17:39] consensus seems to be more, stabilize 4.7.1 [00:17:41] my opinion is to stabilize .1 (after a meeting dec= ision) WITH kdepim [00:17:46] Thev00d00: exactly, I think its what tampakrap also = meant [00:17:52] but let the users know first [00:17:59] document everything etc [00:18:08] news item maybe [00:18:08] maybe even put a news item out as well [00:18:20] ok fine with me [00:18:29] +1 for .1 with pim [00:18:38] anyone else? [00:18:53] But 4.4 should stay in tree for some time [00:18:58] yes [00:19:07] I'll take care of it as good as possible [00:19:15] +1 for .1 [00:19:24] ok [00:19:32] then [00:19:34] ok, prepare a news item, and take care of the docu= mentation then, and after next month's meeting we'll decide on 4.7.1 [00:19:48] anything else? [00:20:05] so not stabilize .1 as its available? [00:20:11] next topic then [00:20:28] no, after meeting [00:20:36] tampakrap: I'd try to decide the stabilization b= y email [00:20:53] no problem [00:20:54] mschiff: at earliest 30days after release, so we h= ave lots of time [00:21:02] anyway, next topic [00:21:06] 2) Road towards KDE 5 - what news is there from th= e Desktop Summit? [00:21:16] who was at the Desktop Summit? [00:21:20] ah that was me!! [00:21:21] you [00:21:44] so, i learned there that Qt 4.8 is NOT going to be= split [00:21:51] Qt 5 will [00:21:58] into what? [00:22:03] and we have plenty of time to worry about KDE 5 [00:22:09] into small parts [00:22:10] =3D) [00:22:14] even atoms [00:22:22] even Thiago didn't tell me details [00:22:26] oh dear, radiation alert [00:22:29] I'd *really* like split tarballs [00:22:36] tampakrap: is there any eta for kde5? [00:22:39] a 200M download when you need 10M is a bit sad [00:22:46] about a year or so? [00:22:51] not yet, but we have plenty of time [00:22:52] work started in kdelibs [00:23:00] framework branch [00:23:07] and they won't do big changes like the 3->4 transi= tion [00:23:41] that's what some core KDE developers (like Aaron S= eigo and David Faure) said in their presentation [00:23:59] will there be a kde 4.8? [00:24:03] yes [00:24:11] but Alex has been talking about using the bump t= o get some ABI incompatible changes [00:24:31] also seems something is going to happen with nepomuk [00:24:33] that has been mentioned multiple times in the re= lease ml [00:24:37] that was the plan, it changed somewhere in the mid= dle [00:24:45] hmm [00:24:52] unless you are talking about something else [00:25:15] I heard some rumour about kdelibs basically remain= ing at 4.7? [00:25:46] i also took part in a release team BoF along with = Slackware, Fedora, openSUSE packagers and a GNOME release team guy [00:25:58] chaired by Sebastian Krugler and Dirk Muller [00:25:59] 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] package* [00:26:20] they talked about the splitting of modules, how to= handle it and about future KDE releases [00:26:28] dilfridge: They've been saying there won't be a = kdelibs-4.8 [00:26:36] ok [00:26:41] so nothing big is expected [00:27:04] are you talking about the superbuild package? [00:27:20] No, that was their "reply" to slackware [00:27:46] no idea what you're talking about then [00:27:57] afaik there will be kdelibs 4.8 and KDE SC 4.8 [00:27:59] 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] ah yes [00:28:13] i recall now [00:28:18] tampakrap: that's not what has been talked in th= e kde relase ml [00:28:21] what does have to do with us? [00:28:21] Alex ? [00:28:33] but I haven't talked to anyone about this nor wa= s I at the Desktop summit :P [00:28:33] Alexander Neundorf, main buildsystem guy [00:28:35] ah [00:28:50] i follow the kde release team, never saw such thin= g :/ [00:29:15] tampakrap: What I'm saying is that they've talke= d about doing incompatible changes. I hear from you that is not what they= 're going to do [00:29:36] they were, but things changed in Qt, thus in KDE [00:29:42] that's what i know so far [00:30:13] but they had also decided on not having KDE/ branches and just 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] tampakrap: ok [00:30:49] anyway [00:31:03] if big changes are going to come we'll know them i= n time [00:31:07] we always did [00:31:08] true [00:31:44] https://plus.google.com/photos/1163816675744988563= 10/albums/5637225108859383905 <-- and here are the photos for those who h= aven't seen them, to make you jealous [00:31:50] :D [00:31:59] anything else here? [00:32:12] not from me [00:32:29] or me [00:32:57] ok [00:32:57] 3) The NetworkManager-0.9 mess [00:33:03] hehe [00:33:05] no idea here [00:33:09] the basic summary is [00:33:23] A gnome-3 requires networkmanager-0.9 [00:33:37] B kde does not support networkmanager-0.9 [00:33:52] A seems to be set in stone [00:33:57] dilfridge: knetworkmanager works fine with nm09 [00:34:04] B is being worked on [00:34:07] yes [00:34:14] and i use this combination on my laptop [00:34:16] dilfridge: wasn't the delay on solid? [00:34:27] also in git master of kdelibs there is a stub for nm0= 9 [00:34:33] for solid [00:34:38] what alexxy is using and what we have in the tree = now is the nm09 branch [00:34:38] I don't use knetworkmanager, nor networkmanager,= so I don't know anything about it [00:35:00] that is basically sponsored by fedora, as they hav= e the same problem [00:35:04] and it seems to work ok [00:35:13] it mostly works [00:35:16] excetp wimax [00:35:17] =3D) [00:35:34] so my cell modem and wifi + vpn works fine [00:35:43] didn't someone put a masked knetworkmanager 0.9 co= mpatible in tree? [00:35:46] the only problem with it is that the knetworkmanag= er developers do not really support it but have different plans (or lack = of motivation) [00:35:52] tampakrap: yes me [00:36:04] basically it is a fedora-fork [00:36:09] dilfridge: no [00:36:15] its different approcah [00:36:30] fedora has patched nm09 with nm08 compatibility layer [00:36:41] nm or knm? [00:36:46] nm [00:36:52] knetworkmanager developers were in summit, why did= n't you tell me earlier to talk to them? :/ [00:36:53] strange [00:36:59] anyway [00:37:01] and its own patched version of knm [00:37:21] oh dear :-/ [00:37:21] probably the best thing is to just stick to the nm= 09 branch [00:37:23] there 3 impletation of nm09 support in knm [00:37:34] first one is fedora [00:37:45] second nm09 branch from knm devs [00:37:52] and third libqtnm [00:38:00] that is worked on [00:38:08] we use second one [00:38:15] since its only working [00:38:15] what's libqtnm? [00:38:34] i dont remember how its called correctly [00:38:40] anyway [00:38:45] but they want to create qt lib fro nm [00:38:45] alexxy: shall we continue using nm09 branch, what = do you think? [00:38:45] since it works, and it is in tree [00:38:49] what is the problem? [00:39:02] tampakrap: there is no real problem [00:39:08] dilfridge: i think that it will be best chois at this= time [00:39:25] the purpose was only to make people aware that thi= s may become problem at some time [00:39:34] but right now I agree with alexxy [00:39:42] summarize the problem please, i'm confused [00:39:59] dilfridge: there will be no problems with migration [00:40:09] since nm settings are stored by nm [00:40:10] chaotic situation, many different approaches, no c= lear upstream [00:40:15] and not by applet [00:40:47] alexxy: ok [00:40:53] so summary: no problem [00:40:57] :D [00:40:57] but we have something that works at the moment, so= let's just wait for upstream to fix their mess [00:41:13] ok=20 [00:41:16] next point? [00:41:18] next issue [00:41:31] meh it's me again [00:41:34] 4) Does anyone still have an overview of the glib-= networking/libproxy problem? [00:42:05] pacho was quite insistent that we have a look at t= his [00:42:15] because it blocks a big fat sec bug [00:42:58] i don't use that app at all [00:43:49] it's pulled in eg by firefox [00:44:15] I went through the >100 comments and tried to make= sense of it yesterday [00:44:20] dilfridge: I can't help as I don't use it as wel= l [00:44:30] I never had the problem myself either [00:44:34] which flag in firefox? [00:44:45] dont remember sorry [00:44:57] a guy put a summary there did you look at it? [00:45:14] yes, me :]... I *believe* the problem is fixed [00:45:22] but believing =3D not knowing [00:45:31] does anyone else know anything? [00:45:54] I do not have it installed [00:45:58] I recommend the gnome guys just go ahead... [00:46:04] any dupes? any activity in the bug? [00:46:21] not anymore for a while (that's why I think it's o= k now) [00:46:42] go on then [00:46:56] ok I'll tell them to just go ahead [00:47:08] next topic [00:47:21] 5) Suggestion - splitting the Gentoo KDE Guide int= o two pages [00:47:21] 1) main page: main tree, stable and ~arch things o= nly [00:47:21] 2) poweruser page: overlay, live ebuilds, sets, kd= e-sunset [00:47:31] who added this topic? [00:47:33] my suggestion=20 [00:47:38] and I'd be willing to do it [00:47:45] but only if you think it's good [00:47:47] that's a no :) [00:48:02] from the very beginning i wanted that guide to be = monolithic [00:48:14] else there will be a lot of duplication [00:48:40] plus readers will be able to jump from one topic t= o another (eg see the existence of the overlay quickly, and maybe prefer = the live ebuilds or snapshots) [00:49:01] there are tags there as well, append #kde4_6 and s= imilar [00:49:02] I think it should always be clear what the guides re= fers to: ~arch or stable [00:49:11] it is [00:49:45] -*- dilfridge is slightly distracted by some dirndls walking p= ast the window [00:49:47] people don't go by branch, they go by KDE version [00:50:39] anyway, anything else here? [00:50:42] no [00:50:48] the guide needs update [00:51:09] what kind of update? [00:51:15] hald [00:51:18] -- [00:51:23] the removal instructions [00:51:33] live branches [00:51:37] not correct [00:51:52] true, give me a patch :) [00:52:08] I hald really still being used? [00:52:15] and maybe some info from the upgrade 4.4 guide [00:52:24] mschiff: no [00:52:33] j0hu: are you willing to update it? [00:52:45] should we kill the upgrade guide and merge some in= fo into the main guide? [00:52:50] will do after finishing the quizz [00:53:08] merge info: yes, kill the upgrade guide: not yet [00:53:31] anything else? [00:53:50] go ahead [00:53:59] not here [00:54:11] 6) Build system architecture bug [00:54:15] +s [00:54:24] bug 358059 [00:54:26] tampakrap: https://bugs.gentoo.org/358059 "cmake-u= tils.eclass PREFIX is not defined"; Gentoo Linux, Eclasses and Profiles; = CONF; meka:kde [00:54:45] no idea about the consequences [00:55:02] I was kind of hoping that reavertm would turn up [00:57:06] if it is defined either way [00:57:12] why defining it earlier is a problem? [00:59:02] but wha does the patch kill the /usr default? [00:59:15] I dont understand problem nor solution [00:59:28] I only looked at the patch [00:59:40] mschiff: see line 7 [01:00:01] I'm more concerned about lines 32/33 [01:00:29] why suddenly add the prefix at a place where it wa= s not needed before?! [01:01:20] hm, seems a bit strange to me [01:01:40] this is wrong indeed [01:01:44] seems like $libdir must not be set this way [01:01:46] the rest is fine imho [01:02:10] if it was set to /usr it will end up in /usr/usr/lib [01:02:45] ok shall we kill the 32/33 chunk and test the rest= in the overlay? [01:03:03] not sure [01:03:08] me neither [01:03:08] we need more eyes indeed [01:03:19] CC scarabeus and reavertm there and ask them [01:03:22] I'll try to persuade scarabeus [01:03:25] yes [01:03:36] next one [01:03:44] the rest ist nothing special [01:03:54] 32/33 is the only real change [01:04:07] ok [01:04:09] next [01:04:13] bug 356681 [01:04:15] 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] i don't like this one, and i am not willing to wor= k on this [01:04:45] jmbsvicetto: is it a good solution to create a vir= tual/phonon? [01:05:41] I fear that the number of problem sources could ex= plode with more than one implementation :| [01:05:56] sorry, I was looking at the patch for the previo= us bug [01:06:01] YEEEHAH [01:06:03] can we hide it under a kde flag? [01:06:09] btw, the only "real change" in there seems to be= the following: [01:06:10] - SET (CMAKE_INSTALL_LIBDIR ${lib= dir} CACHE PATH "Output directory for libraries") [01:06:11] ...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] err sorry [01:06:13] + SET (CMAKE_INSTALL_LIBDIR ${PRE= FIX}/${libdir} CACHE PATH "Output directory for libraries") [01:06:22] -*- dilfridge just read "CURRENT STATUS OF MANUSCRIPT: Editori= ally approved for publication" [01:06:53] jmbsvicetto: thats what I was saying [01:06:57] -*- alexxy still waits for similar resolution from jpcs [01:06:59] about phonon, are they compatible now? [01:07:00] and in the eclass: [01:07:04] # Eclass respects PREFIX variable, though it's not r= ecommended way to set [01:07:04] # install/lib/bin prefixes. [01:07:04] # Use -DCMAKE_INSTALL_PREFIX=3D... CMake variable in= stead. [01:07:22] cause qt-phonon was behind phonon for a long tim= e [01:07:39] no idea about qt-phonon [01:07:43] and i don't care tbh [01:07:56] I'll see what I can do about this one [01:08:14] I still think we should prefer media-libs/phonon= to x11-libs/qt-phonon, though [01:08:15] i'm asking if a virtual is fine, or if we can do t= his but introduce a kde useflag there so that media-libs/phonon is defaul= t [01:09:03] we could say something like " kde? ( media-libs/ph= onon ) !kde? ( virtual/phonon ) " [01:09:17] dilfridge: kdelibs? [01:09:23] f.ex. [01:09:31] yes, in other kde apps as well [01:09:34] if that is possible and even works [01:09:35] i like it [01:09:46] dilfridge: if so, how's that any different from = the current || ( media-libs/phonon x11-libs/qt-phonon ) ? [01:09:58] anyone willing to work on these? (virtual/phonon A= ND qt-phonon for kdelibs) [01:10:15] with !kde you can run kdelibs also with qt-phonon = then [01:10:20] not me [01:10:20] a guy with -kde can get qt-phonon [01:10:22] tampakrap: I'll have to check, but we used to su= pport qt-phonon on kdelibs. We just defaulted to phonon [01:10:37] I'll work on it [01:10:45] ok cool [01:10:46] dilfridge: then someone dropped the old conditio= nal [01:10:49] ok, have a look at both the virtual and the kde fl= ag [01:11:10] tampakrap: I don't know if we gain anything with= the virtual (for KDE) [01:11:30] i believe we are [01:11:41] not only for kdelibs, but for other kde apps [01:12:00] put virtual/phonon there instead of the conditiona= l you pasted earlier [01:12:03] seems cleaner [01:12:20] until you think how to prefer media-libs/phonon = over x11-libs/qt-phonon [01:12:53] that's for kdelibs (solved by the flag) [01:13:08] other kde or non-kde apps don't need to prefer any= thing [01:13:08] I'll look at it and then talk to you [01:13:13] sure [01:13:28] bug 332829 [01:13:30] tampakrap: https://bugs.gentoo.org/332829 "Inconsi= stency between distro's KDE4WorkspaceConfig.cmake and the actual layout";= Gentoo Linux, Library; CONF; cheepeero:kde [01:13:50] i talked about it with reavertm, someone needs to = work on it [01:13:54] 99% it will work [01:14:16] tampakrap: tell me if you need chroot testing [01:14:33] not sure if anyone wants to do this in his main sy= stem first [01:14:37] i can't work on it, someone else has to do it [01:14:59] volunteers? [01:15:08] whats this about? [01:15:28] the internal configuration of the kde build variab= les is somehow messed up [01:15:53] it makes problems for building apps outside portag= e [01:16:27] that's about my whole understanding [01:16:42] so do we have some qt developer in the team? [01:16:54] dilfridge: that whole deal of building apps outs= ide of portage, is something we should probably talk about again [01:16:57] oh [01:17:03] -*- Sput forgot to check this channel [01:17:07] ABCD: ^^ wanna work on it? [01:17:20] Sput: do you use kdevelop? [01:17:23] mschiff: that needs cmake understanding, not Qt [01:17:33] it is easy to test, there is a patch there already [01:17:50] when we started with kde-4.X, we were clear that= we supported portage and building packages with our ebuilds (we have ebu= ilds for all releases, snapshots and live) and that we wouldn't bother wi= th supporting people that want to install software outside portage [01:17:57] I still think that should be our stance [01:18:06] tampakrap: yeah I meant someone who is gerneally dev= eloping something with qt or kde... [01:18:32] jmbsvicetto: yes but if someone wants to use kdeve= lop? [01:18:40] dilfridge: RESO:CANTFIX; KDE4WorkspaceConfig.cmake can = only be installed by one package (for hopefully obvious reasons), yet mus= t change when other packages are installed (breaking checksums) :) [01:19:01] like, use the application to program something? [01:19:11] dilfridge: if I understand the issue, get upstre= am to do a release [01:19:56] dilfridge: if the problem is with testing applic= ations built with kdevelop, I'd say the real issue is cmake [01:20:00] jmbsvicetto: no, I mean if upstream is using gento= o?! [01:20:15] dilfridge: I know how much KDE developers hated = auto-tools, but this is a price you pay for using cmake [01:20:37] well... it's not really my problem [01:20:55] what I could do is feed the patch into a chroot an= d rebuild kde [01:21:00] and look at the result [01:21:09] ok [01:21:34] do you think that would be enough testing? [01:21:46] the package is libkworkspace, file is /usr/lib/cma= ke/KDE4Workspace/KDE4WorkspaceConfig.cmake [01:21:54] and build kdevelop from source [01:21:55] dilfridge: I've talked with Diego about the next= bug, and even though we shouldn't be setting RPATH to /usr (KDE), if I u= nderstood the issue correctly, that alone won't fix the issue as the othe= r applications (kdevelop?) are setting RPATH themselves [01:22:34] bug 380415 [01:22:37] 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] we could also drop the /usr/qt4 RPATH for QT as = it's part of LDPATH [01:22:56] tampakrap: could this be fixed in qt? [01:23:04] i can't decide [01:23:18] hehe agenda topic for next qt meeting [01:23:27] One issue I talked to Diego but didn't understan= d is what kind of impact this might have for security [01:23:27] sure, can you test beforehand? [01:23:31] -*- dilfridge pushes the pile of papers to the next guy [01:23:39] just reading backlog... fwiw, I've been using nm09 with= knetworkmanager and USE=3Dnm09 for quite a while, it works fine [01:24:06] if anyone tells me how to disable RPATH in qt, yes [01:24:27] and there won't be a kdelibs-4.8 release (the master br= anch is frozen now, and people are working in the frameworks branch) [01:24:53] The user on that bug seems to want the QT/KDE li= bs built without RPATH so that if he builds and installs an app in /usr/l= ocal and (as I understand it), he adds a plugin to /usr/local the lib wil= l "link" to that plugin - my question is won't that allow having system l= ibs linking to user-controlled paths? That sounds dangerous [01:25:21] jmbsvicetto: only if they are in LDPATH I guess [01:25:29] 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 pr= actical [01:25:35] The issue is that they are not in LDPATH [01:25:56] 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] and if someone is adding a local dir to LDPATH bef= ore system dir, that is his own stupidity [01:26:25] ABCD: understood. That means the request cannot = be fulfilled then [01:26:40] dilfridge: sure [01:27:04] 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] dilfridge: the default actually puts /usr/local/lib fir= st before everything else (note, /usr/local/lib64 isn't mentioned until a= fter /lib64 and /usr/lib64) [01:27:32] dilfridge: and I don't use KDevelop at the moment [01:27:39] 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] /usr/local/lib is still root:root [01:27:41] see /etc/env.d/00basic [01:27:49] true :) [01:28:44] ok I guess this is effectively going to be decided= by the qt team [01:28:48] so I don't know enough about this, but hope any = change we do won't open any unwanted "doors" [01:29:47] any more thoughts about this? [01:29:52] dilfridge / tampakrap: No comments or objections= from me to the next 2 (final) items [01:30:42] the last two items are the simple ones [01:30:51] no objections from me either [01:31:16] my opinion: a) add libXkbfile globally, b) remove = the useflag [01:31:43] yes and yes [01:31:43] 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] (I think cmake uses the proper ld(1) options that make = the linker set DT_RPATH *and* DT_RUNPATH) [01:32:56] as for the Qt5/KDE5 thingy: Qt5 will be released next s= pring or so, KDE will take longer... work on kdelibs is going on in the f= ramework branch [01:33:04] >:| [01:33:24] we need the qt herd to provide us with Qt5 ebuilds soon= ish (and I hope the eclasses still support proper slotting) [01:33:44] I think some eclass magic is needed to make kdefoo 4.8 = depend on kdelibs >=3D 4.7.0 [01:33:48] Sput: argh... which gets back to the last issue [01:33:48] Sput: i thought frameworks is going to be kdelibs = 4.8 [01:33:55] ABCD: yes but that is doable [01:34:01] tampakrap: no, frameworks is not going to be 4.8 [01:34:10] there won't be a kdelibs-4.8 [01:34:10] dilfridge: that is "I think I'm going to have to write = some eclass magic ..." [01:34:12] and what is it going to be then? [01:34:46] ABCD: or fakebump kdelibs to 4.8 :) [01:34:51] well, probably what we call "KDE 5" although I'm sure t= he KDE promo team is going to come up with yet another naming scheme in t= ime :P [01:34:54] tampakrap: too much work :D [01:35:07] Sput: there is no KDE 4, so how could there be a KDE 5?= :) [01:35:11] Sput: indeed [01:35:18] ok let's wait then [01:35:22] KDE is a community, you can't attach a version number t= o something like that :) [01:35:22] ABCD: exactly [01:35:22] Bulshytt! [01:35:26] 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 ea= rly KDE-4 days [01:35:56] the frameworks branch ist going to be the next incarnat= ion 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] 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] the rest of KDE will follow suit only later [01:36:28] jmbsvicetto: that's only assumptions, just wait fo= r the release [01:36:29] if upstream slots things properly, I think we should sl= ot; otherwise everything goes in :4 (which we might want to make :0 inste= ad :D) [01:36:37] 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] ABCD: nononono, what with :4 and :5 then? :O [01:37:11] we certainly will have to slot Qt versions [01:37:14] -*- dilfridge thinks we cannot really predict the upcoming cha= os [01:37:16] ABCD: no gain in moving to :0 again [01:37:17] not sure about KDE [01:37:26] ABCD: besides, don't forget some people still us= e kde-3.5 ;) [01:37:44] Enable auto-destruct sequence [01:37:50] Sput: qt is slot 4, isn't that sufficient? [01:38:05] some people dont know how to remove 3.5 :P [01:38:05] tampakrap: it is, if slotting still works in the eclass= es [01:38:26] it is, why shouldn't it? :) [01:38:35] anyway, people, don't panic [01:38:43] tampakrap: well, we've removed proper slotting support = from the KDE eclasses [01:38:48] who knows what the qt herd did :) [01:38:51] you are all making assumptions here, just wait for= the next release to show up [01:38:55] tampakrap: because it hasn't been tested in a lo= ng time ;) [01:39:06] lol [01:39:15] 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 insta= ll it into Gentoo [01:39:23] (without removing qt4 obviously) [01:39:46] Sput: unless we get ABI deps, I suspect you're g= oing to have *great* pain trying that [01:40:07] true, nothing's going to be so smooth for sure [01:40:09] unless every binary sets the correct RPATH :P [01:40:14] major versions ahead, red flag [01:40:34] jmbsvicetto: well, used to be the case that just callin= g the correct qmake version would set everything up correctly... [01:41:01] this is going nowhere [01:41:02] I'm just saying, we need to be aware of Qt5 being right= around the corner already [01:41:06] let's just wait and see [01:41:12] it's not something that'll hit us in a few years [01:41:18] 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 c= ase a huge wave rocks the boat ;) [01:41:20] 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] meetings are long, eh :) [01:41:57] -*- Sput has moar in the fridge [01:41:58] and btw, MEETING IS OFF [01:42:08] summary tomorrow