19:00:21 #startmeeting 19:00:22 Meeting started Tue Mar 19 19:00:21 2013 UTC. The chair is einar77. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:46 #meetingtopic Welcome to the openSUSE KDE community IRC meeting! Please wait with other discussion until the meeting is over. This meeting is logged. 19:01:26 #topic old action items 19:01:36 Do we have any left over from previous meetings? 19:02:19 And for reference, this is the topic list for today (assuming people are alive ;) 19:02:43 Planning a review of openSUSE patches 19:02:45 Adjustment (enforcing) of patch policy 19:02:46 Summary of the 12.3 development cycle: what was good, what wasn't, ideas for improvement 19:02:48 Initial plans for 13.1 19:02:49 Review of KDE Repositories, especially : (tittiatcoke) 19:02:55 How to proceed with KUSC ? (bnc#706813 and the work done by shumski) 19:02:56 - KDE:Unstable:Playground:Telepathy 19:05:04 going through old stuff to see if 19:05:07 there's something worht reporting 19:05:47 alin: did you get through legal for Simon? 19:06:06 einar77: yes... I have put the srs but of course only silence came from them 19:06:24 Do you mean, you have SRs made already? 19:06:30 alin: worth perhaps poking them again? 19:06:33 einar77: sr 156732 , 734 and 735 19:06:56 einar77: I really do not like to piss off people who do not write code... 19:07:15 alin: Well, but I guess some were "forgotten" due to 12.3 having priority 19:07:38 WHat about menioning it in a generic mail to factory ML? 19:07:51 einar77: ok I will 19:08:07 #action alin write to factory ML regarding Simon's status 19:08:39 cb400f: shumski tittiatcoke was 11.4 dropped from KUA? 19:08:50 yep 19:08:59 not sure who/what did it.. but it's gone :-) 19:09:00 Good, so that's done 19:09:12 Maybe someone else can guide me, I would like to file a bug but dont know if I should do it with KDe or with suse 19:09:26 cb400f: ok... so we donot know whom to congratulate... such a pity 19:09:32 CygniX: wait until after the meeting :-) 19:09:32 CygniX: can you wait a few minutes? there's the KDE meeting going on at the moment 19:09:50 Oh OK, no problem guys 19:10:17 cb400f: you had also "start a wiki page for apper", did you get around to it, or did you not have time? 19:10:26 (just trying to "spring clean" the old items) 19:11:05 it's very near the top of my list.. I have already made the screenshots... but I had to wait until I had 12.3 installed 19:11:23 I'll just add to the actions again then ,so that's not forgotten 19:11:47 #action cb400f Make a start with a wiki page for apper 19:12:25 tittiatcoke: do whe have the fix for https://bugreports.qt-project.org/browse/QTBUG-18934 ? 19:12:36 since it caused issues w/nepomukindexer 19:12:43 einar77: yes, submitted it to KDE:Qt 19:12:51 ok, so that's solved 19:13:17 tittiatcoke: 19:13:22 tittiatcoke: last one for you, what about bug 69153? 19:13:22 i don't know did it ended up in 12.3 19:13:27 KDF & Co probably need some silent-time (i.e. no sr's / changes until fully built) though... 19:13:27 er 19:13:42 bug 659153 19:13:42 openSUSE bug 659153 in openSUSE 12.2 (KDE4 Workspace) "Ejecting Optical Drives Causes Immediate Re-Close of Tray and KNotify Crash" [Critical,Reopened] https://bugzilla.novell.com/659153 19:14:35 The old action item was "check with cartman about that bug" 19:14:52 shumski: NicoK do we have nepomuk fileindexer off by default in 12.3? 19:14:53 einar77: I know. Didn't do that one. But the last comment indicate that the bug is gone 19:15:06 einar77: fileindexer is of 19:15:14 ok, both done 19:15:33 I'll defer the discussion on ksuseinstall et al to 13.1 discussion in a moment 19:15:59 #topic status report 19:16:28 Any special non-agenda status report? 19:16:36 Otherwise let's just move to the next topic 19:16:37 einar77: (nepomuk fileindexer) don't know :( 19:17:09 nepomuk and akonadi feeder - ON, fileindexer OFF 19:17:20 shumski: great, as planned 19:17:25 yes 19:17:28 Let's move on with the meat of this meeting 19:17:33 ok 19:17:37 #topic Planning a review of openSUSE patches 19:17:55 As you all know, we do ship quite a lot of patches in our KDE packages 19:18:07 my idea would be to start a (progressive) review 19:18:15 to check: 19:18:24 - whether the bugs they fix are relevant or not; 19:18:30 - whether they are openSUSE specific 19:18:38 - whether they can be pushed upstream instead 19:18:46 - whether they can just be dropped 19:19:09 I don't tihnk this should fall on one person alone, I believe this needs to be done collaboratively 19:19:34 shumski: do you know how many patches for kdelibs, for example? 19:19:37 agreed. maybe it would be a good idea to open a wiki page, and people can write what do they think about specific patches? 19:19:46 einar77: one sec 19:19:57 shumski: probably a good idea 19:19:58 shumski: good idea about the wiki page 19:20:22 Probably divided by package, and I say we focus on the core ones only at the moment 19:20:49 IOW, kdelibs, kdebase-workspace, baseapps, runtime 19:20:55 patch list is here: http://paste.opensuse.org/55518437 19:20:59 (for kdelibs) 19:21:01 once these are clean, we can move to check others 19:21:17 yeah, kdelibs and workspace have the most 19:21:46 shumski: some can probably be pushed upstream, just by reading them 19:22:28 I can create a skeleton, but then I'll need everyone to help ;) 19:23:11 some can, some not i guess 19:23:12 Afterwards we should announce it to the ML 19:23:18 agreed 19:24:14 #action einar77 Create a skeleton page for patch review 19:24:24 #action einar77 Announce wiki page for patch review on ML 19:24:50 Personally (speak up if you disagree) 19:24:52 ~80% of workspace ones are for KDM, afaik 19:25:09 I think we should strive to keep only opensuse specific things in patches 19:25:16 with a good deal of pragmatism 19:25:48 any other comments on this topic? 19:26:15 I'll take this as a no ;) 19:26:28 the rest of the patches fix bugs that are not fixed in the latest release, right? 19:26:33 NicoK: yes 19:26:39 the idea is 19:26:49 keep upstream patches for stuff that's solved in the next release 19:27:07 and for the rest, upstream what's upstreamable, and keep the openSUSE specific things 19:27:16 ok - just wanted to make that sure as these are not really opensuse-specific... 19:27:39 sounds good 19:27:43 NicoK: in that case we can try (not sure if we *always can*) to put them in KDE proper 19:27:45 upstream as much as possible 19:28:15 Any other comment? Otherwise we move to the next item in the agenda 19:28:42 Next it is, then 19:28:52 #topic Adjustment (enforcing) of patch policy 19:29:19 The recent "incident" with the giflib patches showed that so far we were inconsistent with the patch policy 19:29:45 I would propose to enforce the patch policy from now on 19:29:55 to keep consistency 19:29:58 in what way? 19:30:00 i.e. have them annotated 19:30:05 ok, +1 19:30:12 shumski: I like the openSUSE KDE style, to be honest 19:30:24 it's much more informative 19:30:56 +1@patch annotations 19:30:58 albeit not used often outside KDE 19:31:08 einar77: what do you mean by openSUSE KDE style? 19:31:20 sec 19:32:06 NicoK: this one https://en.opensuse.org/KDE/Patch_Annotation_Policy 19:32:10 do we have a github or someplace these patches are stashed outside of OBS ? 19:32:30 mrdocs: not at the moment 19:32:49 mrdocs: I'm not too familiar with the OBS' source control mechanism 19:33:29 My naive question 19:33:38 does it make sense to have patches under version control? 19:33:45 possibly 19:33:50 (my instinct says yes) 19:34:07 and a place where upstream can pull from too 19:34:41 could be possible 19:35:04 @KDE annotation policy: seems similar to patches created by git - and reasonable 19:35:21 mrdocs: you mean storing just the diff, or the whole patched checkout? (I'm thinking the former) 19:35:36 NicoK: in fact we could almost use git-format-patch ;) 19:35:57 git-format patch is cool 19:36:08 just the diffs imo 19:36:13 ok, I agree 19:36:25 OBS uses some sort of version control 19:36:51 NicoK: it's not easy to extract history though, it's often hand in hand with the checkins 19:37:17 yes - another VCS would increase complexity and may reduce partiticipation though 19:37:18 tittiatcoke: what do you think? Does it make sense to have a github repo with our patches? 19:37:42 NicoK: fedora has a git repo for their patches (granted, they don't have OBS, though) 19:37:44 or maybe we could put only those patches there that we want to get upstream 19:37:58 einar77: Might be indeed good, but then we should not only look for patches, but also tools (e.g. my scripts to update KDF, etc) 19:38:04 as some kind of "incubation" project 19:38:07 tittiatcoke: that's an excellent idea 19:38:26 we should keep scripts etc all open to the public 19:38:33 +1 19:39:05 ideally OBS would expose its history in a better way though... 19:39:16 e.g. as a git repo 19:39:20 Agreed, but while it doesn't 19:39:28 most of the KDE team is familiar with git 19:39:38 (despite it being black magic at times) 19:39:41 maybe it's worth adding a FATE entry (if there is none yet) 19:39:46 :) 19:39:49 good idea 19:40:14 Who can talk with whoever's in charge of teh opensuse github repo to have this "incubation" repo created? 19:40:28 Same for the FATE entry 19:40:51 NicoK: since you roposed the FATE entry, would you be able to do it? ;) *hint, hint* 19:41:14 it is not that bad with history, just that is hard to check it if people don't commit with messages 19:41:20 yes 19:41:24 with git you can't 19:41:24 I'm pretty stuffed with work atm - but I can probably search & add a simple request there, I guess 19:41:48 NicoK: not wanting to push you, just to ensure that stuff gets recorded and we know who's doing what 19:41:58 you can omit messages (or write useless messages) in git as well, can't you? 19:42:07 NicoK: yes, of course 19:42:32 "Against stupidity the gods themselves contend in vain", so it'll always happen 19:43:00 shumski: alin tittiatcoke any of you can look for this git repo creation? 19:43:18 einar77: you can assign this one to me 19:43:24 ok, thanks 19:43:48 #action tittiatcoke investigate the creation of a github repo for patches and other KDE team tools 19:44:20 #action all Enforce annotated patch policy for future SRs 19:44:33 Any takers for the FATE entry? 19:45:15 I'm not quite sure whether they'd accept it... 19:45:26 after all they have some sort of history tracking... 19:45:30 OK, let this pass for now 19:45:40 I'll check though 19:45:46 so assign to me for now 19:45:46 we'll see after the result of the github repo creation 19:45:48 ok 19:46:10 #action NicoK open a FATE ticket for improved history in OBS 19:46:19 einar77: do you have an action that somebody will communicate the new patch policy ? (ml, wiki, etc ?) 19:46:31 except a git repo representation, what would you improve? 19:46:37 tittiatcoke: not yet 19:46:41 I would say ML first 19:46:45 then wiki 19:46:59 I can do the ML part 19:47:09 Since I already have things to report via ML anyway 19:47:19 einar77: Ok. :-) Also we need to inform the factory-maintainers that this is the new policy and that they are allowed to reject submissions to factory if the policy is not followed 19:47:43 tittiatcoke: specific mail address, or the factory-ml? 19:48:04 einar77: I am not sure, but we could communicate this through Andreas Jaeger 19:48:20 I would go in 3 stages: 1. tell KDE ML, 2. tell AJaeger, 3. wikify 19:49:04 likely, write to ML, if no big objections make it policy by writing to the factory-maintainers and then wikify it 19:49:44 if you agree, I'll do the ML part first 19:49:50 today or tomorrow I hope 19:49:53 einar77: Ok 19:50:06 #action einar77 write to opensuse-kde ML for the new patch policy 19:50:10 ok, i'll try to annotate the existing ones in the next days (if agreed) 19:50:11 ? 19:50:20 good 19:50:27 shumski: I'll put that as action item so we know 19:50:33 oki 19:50:41 #action shumski annotate existing patches if the new patch policy proceeds 19:50:56 GUys, can some of you take my place for ~10 min? 19:51:04 I need to make a phone call 19:51:18 but before that, any other questions? 19:52:12 Next topic coming up, unless you have more questions 19:52:16 (or proposals) 19:52:39 #topic Summary of the 12.3 development cycle: what was good, what wasn't, ideas for improvement 19:53:10 What are your thoughts overall on this? 19:53:37 How was 12.3 cycle? 19:53:43 what was good? 19:53:44 what wasn't? 19:53:54 * einar77 withdraws for 10 min 19:54:05 Sorry for this, I'll be back ASAP 19:54:42 ← is finally there and scrolls 20:00:13 IMO 12.3 is one of the nicest KDE's in a long time 20:00:37 artwork gets special mention coz i really never bother, but its well done 20:00:57 we still screwed up on a few things.. e.g. no video thumbnails in a default install 20:01:32 also I wonder if kde-gtk-config shouldn't have replaced kcm_gtk as default? 20:01:39 hi 20:01:42 didn't it? 20:01:45 and we didn't get rid of ksuseinstall in time 20:02:02 I have kcm_gtk by default on my 12.3 fresh live install 20:02:35 ok. didn't checked that one. thought it already replaced it 20:02:57 when I try to open mov video file in vlc I get a black screen; also Kaffeine says this: Cannot find demux plugin for MRL; I installed vlc from pacman but it didn't help 20:04:06 cb400f: also seems ffmpegthumbs disappeared from Packman? 20:04:10 ryrych: Please see topic. Meeting is ongoing, please wait with your question till after the meeting 20:04:24 ok sorry :) 20:04:36 ryrych: np :-) 20:04:55 shumski: maybe.. I'm using mplayerthumbs 20:05:00 back and srorry 20:05:14 * einar77 reads 20:05:23 ok. got a qustion today about it, and looked, didn't found it 20:05:53 on the good things 20:06:00 we have strengthened a lot the upstream links, IMO 20:06:09 the aforementioned theme 20:06:23 agreed with cb400f on the ksuseinstall 20:06:31 IMO it should be torched, but that's just me 20:06:55 interesting that you should strengthen relations with upstream by ditching _their_ artwork ;-) 20:07:08 me too :-) 20:07:08 well that's branding and all that jazz ;) 20:07:24 cb400f: but we did a lot of our work upstream or in collaboration with upstream 20:07:28 and even with other distros 20:07:40 (udisks2 backend for solid - upstream / fedora / opensuse stuff) 20:08:22 I think this should be a good marketing point, even 20:08:34 as for stuff that could be improved... 20:09:04 the aforementioned ksuseinstall mostly, from my POV 20:09:32 and some defaults (kcm_gtk2 vs kcm-gtk-config) 20:10:18 alin: krop anything to add on this? 20:10:32 einar77: sorry on the phone 20:10:53 no, as a factory user, I didn't test the 12.3 CD 20:10:58 einar77: aaa about 12.3 12.3 is history 20:11:07 kio_mtp is not in the default install either is it? ... I don't have android.. but that stuff seems to come up rather often 20:11:27 cb400f: good point, these things will need to get into the default pattern 20:11:36 should be on default pattern 20:11:59 looks like I'm out of the loop 20:12:11 including android-tools (iirc it is only a soft requirement in kio_mtp) 20:12:22 i.e. a "suggests" 20:12:25 To summarize, however, I think that this dev cycle is largely positive 20:12:38 but this is not KDE-specific :) 20:12:42 and that we're on the good track 20:12:43 right.. I have it installed actually.. sorry 20:13:00 probably we should improve more stuff like: 20:13:08 - defaults (already good enough IMO) 20:13:11 - default applications 20:13:16 +1 mtp-tools 20:13:39 the next topic deals with 13.1, that's why these two are close together 20:13:47 note: there's a thread upstream talking about kio-mtp and releasing it with 4.11 20:14:00 krop: got a link? 20:14:20 a kde-devel thread from saturday 20:14:28 ok, will check later 20:14:42 Moving on the next topic, if you don't object 20:14:54 http://lists.kde.org/?l=kde-devel&m=136347311903866&w=2 20:15:15 I'll swap topics on the agenda 20:15:35 because since we started late, I'd rathr discuss the most definite scope first 20:16:13 #topic Review of KDE Repositories 20:16:38 #topic * How to proceed with KUSC ? (bnc#706813 and the work done by shumski) 20:17:05 As you know, shumski has been working on creating an out-of-prefix KUSC packaging 20:17:36 I think it may be useful to evaluate whether it may good enough for KUSC 20:17:40 shumski: what's the current status? 20:18:08 einar77: have some core packages there, but didn't continued until decided how to proceed 20:18:19 rationale for this, for the others 20:18:38 it may be worth providing non-prefix packages to ensure they don't destroy the default KDE install 20:18:51 it is working correctly. even the branding stuff (except e.g. kdelibs) 20:18:53 this will be useful for people who do development only on small bits of KDE; or to test 20:18:59 without risks 20:19:15 Now the 1 eurocent question is 20:19:26 - is it worth pursuing? 20:19:28 and 20:19:44 - Do you agree that KUSC would (*potentially*) be better used like that? 20:20:04 there's however a non small issue with repos tied to KUSC (are there any)? 20:20:58 the other shoe which will drop is qt5 20:20:59 obviously both answers from my end are - yes. but it is to others to say what they think 20:21:11 krop: your opinion? 20:21:15 which atm is not parallel installable 20:21:24 mrdocs: yes, that's to keep in mind too 20:21:29 einar77: I guess that if we change the usage of KUSC to a different prefix, then the question is if we should still build KDE:EXtra and KUP for KUSC ? 20:21:38 tittiatcoke: that was my question 20:21:46 I would be inclined to "No" 20:21:54 KUSC is not for regular users IMO 20:21:54 :-) I would say the same. 20:21:55 IMO, no 20:21:57 but remerges might be ugly 20:22:08 mrdocs: can you elaborate? 20:22:11 i said *might* 20:22:39 building kde-foo from extras against a much newer kdelibs or other core lib 20:23:00 just trying to think ahead :-) 20:23:03 so, I have technical questions: how are XDG paths handled ? specially XDG_CONFIG_HOME, XDG_DATA_HOME ? 20:23:17 how are polkit permissions files handled ? 20:23:18 they are exported 20:23:21 .kde-new ? 20:23:30 .kde-unstable for now 20:24:09 krop: everything is installed in /opt/kde-unstable 20:24:32 then polkit won't work (kdm settings, clock settings, apper...) 20:24:38 shumski: IIRC the polkit files will not work out of prefix 20:25:21 ok, then i need to take a look at that 20:26:11 about :Extra, :Playground* I don't really see the reason to not build them anymore ? 20:26:45 I would start small first (assuming it works) 20:27:07 krop: i am not sure how would that work. i use different macros 20:28:15 as long as kde4-filesystem knows the /opt paths, we just have to review each package to make sure it uses the KDE path definitions 20:28:48 macros are ~same only s/_kde4/_kde_unstable 20:30:15 also, specs in extra would need a revisit, for dir ownership 20:30:41 Folks, I just realized I need to leave, didn't expect the meeting to run this long 20:31:04 shumski: so a general review of specs would be required before any other adjustments? 20:31:23 that is for sure :-) 20:31:26 Can someone "take the helm" for the meeting in my stead? 20:31:40 einar77: I would propose that we move this discussion to the next meeting. This gives shumski the time to investigate some stuff and the rest to think about it 20:32:00 #action shumski further investigate out-of-prefix KUSC 20:32:11 tittiatcoke: as expressed in the action above 20:32:16 einar77: Oki :-) 20:32:28 einar77: Thanks for moderating. I will take over for the last agenda item :-) 20:32:38 thanks, sorry for this (And if I messed up tell me!) 20:32:40 later people! 20:32:54 #topic Q&A 20:33:15 already ? didn't you want to discuss kupt ? 20:33:35 krop: Ok :-) 20:34:15 I brought up the point with regards to the separate repo for Telepathy (KUPT). The reason for this is if we still needs this one or that we should merge it into KUP itself 20:35:00 anybody ? 20:35:42 me ! me ! 20:36:10 I see several things: 20:36:29 :-) 20:36:47 - they break their repo, move their code every months and break everything very often 20:37:59 - the dependencies are also evolving quickly (do we really want to ship a recent telepathy-glib or telepathy-whatever in KUP for 12.2 ?) 20:38:34 - we have a local patch that removes the dependency on gnome-keyring (because, well, we don't care about it) 20:39:31 Ok. So a lot speaks for keeping it really separate :-) 20:39:32 - whatever decision, I'd rather keep them in a separate repo due to the amount of packages and provide an _aggregate instead 20:40:06 (the last point is because kup itself has quite some packages already) 20:40:12 true 20:40:29 Does anybody has a different opinion ? 20:41:09 (I'm also thinking about moving the kdevelop plugins in a subproject and add an _aggregate for the same reason) 20:41:25 ok 20:43:03 Hmm, anybody still in the meeting ? 20:43:23 yeah, sorry 20:43:31 guess not too many use ktp from kupt ;-) 20:43:44 no, strong opiniion on KUPT, but seems it is better to leave it separate 20:44:24 Ok. Then we leave it as it is :-) 20:45:05 #chair 20:45:11 #topic Q&A 20:45:27 Hmm, somehow bugbot doesn't react on me :-( 20:45:36 Ok. Last topic. Q&A :-) 20:45:40 Any questions or comments ? 20:45:48 none here 20:46:33 have one, is it worth to add sysinfo in extra? seen some users that would want it back (i know it's a step backward) 20:46:45 but, just asking :-) 20:47:01 If we have a maintainer for it :-) 20:47:12 which we didn't have for years 20:47:27 oki 20:48:09 krop: I was more talking about somebody taking care of the packaging :-) 20:48:20 ah:) 20:48:34 a maintainer for the source would be impossible :-) I don't think that anybody cares for it 20:48:51 i have packaged it today, just wanted to see is it worth it 20:49:39 shumski: Ok :-) I am fine to put it in KDE:Extra :-) 20:50:03 ok, cool. will submit it soon then. 20:50:06 speaking of abandoned things, I'd like to make the KR48 users unhappy and remove akonadi-googledata + libgcal from KDE:Extra 20:50:11 Maybe it would be worth to mention in the description somewhere that it is unsupported :-) 20:50:18 krop: Go for it :-) 20:50:19 tittiatcoke: agreed 20:50:30 both were abandoned ~3 years ago and are really unusable 20:50:40 krop: Drop them :-) 20:50:46 +1 20:51:02 #action shumski submit sysinfo to KDE:Extra with the indication that it is unsupported 20:51:23 #action krop drop akonadi-googledata and libgcal from KDE:Extra for KDE:Release:48 20:51:48 anything else ? 20:52:00 nothing from me 20:52:08 yes... 20:52:19 NicoK: Go ahead :) 20:52:26 from what I've seen in KDF & Co. the repo is in constant rebuild now 20:52:33 we should probably let it settle first 20:52:39 and then continue adding patches etc 20:53:00 at least for the core packages 20:53:19 NicoK: The issue is that as soon as somebody changes something at a low level (e.g. kdelibs4, soprano, etc) the full repo gets rebuild 20:53:33 But I agree that we should let is finish building before accepting new packages 20:54:32 maybe we could collect sr's for core packages (like in the past) and accept them once/twice a week only... 20:54:43 yeah, but somehow you indication that KR410 is leading didn't get 100% through, so i wonder how will this work 20:55:03 shumski: :-) Well, KR410 is no longer leading :-) KDF is the leading one again 20:55:05 ? 20:55:23 tittiatcoke: i know, but the same could be applied for this "rule" 20:55:48 :-) True. But we should have less people accepting requests than those that are submitting 20:56:09 i mean, i agree, just not 100% convinced it will work in practice 20:56:19