On Thursday 28 March 2013, Thomas Pfeiffer wrote: > > we will be going through release blocker bugs tomorrow in #active at > > 13:00 UTC. all are welcome to join. > > > > cheers ... > > First of all: Thanks for the productive meeting, I'm glad we arranged it! > > So now how do we proceed? Currently we still have two (plus one related) > relatively nasty bugs for which no solution has been found yet: > > https://bugs.kde.org/show_bug.cgi?id=314553 > (which probably causes https://bugs.kde.org/show_bug.cgi?id=314902 ) > and https://bugs.kde.org/show_bug.cgi?id=316158
here is the raw unfiltered gargantuan log: [14:06] <colomar> In the meantime, I'll post the link to the list so that everyone interested can have a look: https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&product=Active&list_id=564029 [14:08] --> ingwa has joined this channel (~ingwa@130.236.218.222). [14:10] <aseigo> oops.. wrong channel. let's try here -> ok [14:12] <colomar> *ggg* [14:12] <notmart> so start one by one? [14:13] <notmart> is this an up to date list? [14:14] <colomar> yes [14:14] <notmart> (in the list i think i don't have any solution for none of them...) [14:14] <notmart> except the first for which always worked correctly for me [14:14] <colomar> The only problem is: When some bugs are fixed, others may come up becasue things can be tested which could not be tested before [14:15] <colomar> Hm [14:15] <colomar> I guess we should look at them one by one and see what we'll do (maybe to work around them) [14:16] <colomar> Okay, so the first one is 317460 [14:16] <colomar> Nepomuk does not index metadata for mp3 and ogg files [14:16] <sebas> I'm going to test the powermanagmente one in a bit [14:16] <aseigo> does that work on desktop? [14:16] <sebas> the webbrowser bug could be solved with webkit2.3 [14:17] <colomar> aseigo: Yes, it does [14:17] <notmart> (and should be filed under nepomuk) [14:17] <notmart> vHanda: any idea what could cause that? (https://bugs.kde.org/show_bug.cgi?id=317460) [14:17] <colomar> notmart: I thought that maybe it has something to do with our setup, since it works on Desktop [14:17] <aseigo> sebas: the web browser compiled with 2.3 in integration now [14:18] <sebas> ah, so updating gets me the new browser, or are packages still building? [14:18] <sebas> uhm, is webkit 2.3 packaged at all? [14:18] <aseigo> notmart: hm. is taglib in the images? [14:18] <vHanda> colomar: Are you on master? [14:18] <aseigo> sebas: i dont' think 2.3 has been packaged yet .. [14:18] <sebas> ok [14:18] <vHanda> colomar: cause if so it would be awesome if you could run nepomukshow "fileName" [14:18] <aseigo> vHanda: 4.10 for PA4 [14:18] <notmart> iirc it wasn't working for me on the desktop as well, vHanda mentioned it could have been caused by outdated virtuoso, i updated it, around a week ago [14:18] <colomar> vHanda: Integration, updated yesterday [14:18] <notmart> but right now should be correct [14:19] <vHanda> colomar: what about nepomuk-core? [14:19] <aseigo> notmart: yeah, that's why i didn't bring that particular possibility up ;) [14:19] <aseigo> vHanda: it's all 4.10 [14:20] <notmart> aseigo: ha, great, i see taglib not found in nepomuk-core build log [14:20] <vHanda> :| [14:20] * aseigo wins an internet [14:20] <sebas> motherfucker guess [14:20] <notmart> what do you do with an entire internet? :p [14:20] <aseigo> i dunno. i keep giving them to girls. they never phone back. [14:20] <sebas> watch all its porn! [14:20] <aseigo> *sad face* [14:20] <sebas> shutdown facebook, etc [14:20] <sebas> I'd know a lot of things [14:20] <aseigo> ah. THAT's what they a re doing [14:20] <colomar> *ggg* [14:21] <colomar> Okay, so that bug can be fixed by compiling nepomuk with taglib? [14:21] <notmart> ok, so this one seems just about packaging [14:21] <notmart> hopefully [14:21] * aseigo adds a note to the br [14:21] <vHanda> try a search for some text in a text file, if that works, then mp3 file indexing should also work [14:22] <vHanda> when you package it [14:22] <aseigo> https://bugs.kde.org/show_bug.cgi?id=314902 next? [14:22] <colomar> vHanda: it doesn't work either, I tested that already [14:22] <vHanda> you can manually force the indexing of some file by running the nepomukindexer <file> [14:23] <aseigo> colomar: *no* files are beign indexed? not even text filese? [14:23] <aseigo> er, file [14:23] <aseigo> s [14:23] <colomar> aseigo: The files as such are indexed, but not their content [14:23] <colomar> Or are you talking about https://bugs.kde.org/show_bug.cgi?id=316158 ? [14:24] * aseigo wasn't, no [14:24] <colomar> ok [14:24] <aseigo> anyways.. music files probably identified [14:24] <colomar> So yes, text files appear by name, but currently you cannot search withing (that did work at some point) [14:24] <colomar> yes [14:25] <colomar> So on to 314902 [14:25] <notmart> 314902 i don't exactly understand what he's saying [14:26] <colomar> look at my comment, maybe that makes it clearer ;) [14:27] <colomar> Basically the bug is that after you tag some files, tagging gets broken until you restart Files. The more file you tag at once, the higher the likelyhood that it breaks [14:27] <colomar> When tagging a full page of files at once, it always goes boom [14:27] <notmart> so seems more 314553 [14:28] <colomar> They are distinct bugs, but related [14:28] <colomar> I don#t know if fixing 314553 would automagically fix 314902 as well [14:29] * notmart fears is due to proxymodels hell [14:29] <notmart> but fixing one would probably fix the other too [14:29] <colomar> likely, yes [14:31] <aseigo> that one seems like a rather high priority items too ... [14:31] <aseigo> it's a key feature [14:31] <colomar> absolutely [14:31] <colomar> Broken tagging is a bad bad thing [14:32] <notmart> yes [14:32] <colomar> notmart: They are definitely related: Tagging only breaks after you triggered 314553, just tested [14:32] <notmart> (and among those is probably the only one directly fixable, at least with a patch in plasma-mobile) [14:34] <notmart> so, basically that one i have to try to get fixed today [14:34] <colomar> Okay, so 314553 is given high priority with hopes that it will fix 314902 along with it [14:35] <notmart> next, 314141 [14:35] <colomar> ok [14:35] <notmart> that i don't know why, evidentely there is just enough difference in the group by query to have a different number of items shown.. [14:36] <colomar> So suggestion: Just don't show any numbers, problem solved? [14:36] <aseigo> yeah, i'm still not convinced those numbers are useful (and they have to take *some* amount of time to generate?) [14:36] <notmart> eh, at least as short term workaround.. [14:37] <aseigo> what is the use case for them? besides being able to show that "hey we've indexed a ton of shit on your device! check it!" [14:37] <colomar> I agree with aseigo that maybe those numbers are not worth the effort anyway. People can see how many files are on a page and how many pages they are, so they get a feel for how many files they have anyway [14:37] <notmart> aseigo: well, it's a group by query, it have to search for all matching triplets anyways, i think it takes same time even to just know if the category should be shown or not (ie >1) [14:37] <aseigo> i'm not sure i care if there 150 or 300 images [14:38] <aseigo> it's useful for debugging perhaps .. but then we can maybe find a place for that number elsewhere when viewing the actual resource [14:38] <notmart> but the value can just be hidden [14:38] <aseigo> vHanda: is there a way to search for matching triplets and stop at the first matching one? [14:38] <aseigo> vHanda: similar to SQL's unique or limit clauses? [14:38] <vHanda> you can always apply a LIMIT 1, but it depends on how you're issuing the query [14:39] <vHanda> yes [14:39] <vHanda> select distinct ?variables where { ... } LIMIT 1 [14:39] <vHanda> you can even do OFFSET along with LIMIT to get a certain range [14:39] <aseigo> well, basically, we want to know which types are indexed .. e.g if there are no images indexed, we don't want to show the entry in the files sidebar [14:39] <aseigo> ah .. distinct .. yay for having that. [14:40] <vHanda> if you're looking at a true/false query, it would be better to do an ask query [14:40] <vHanda> sparql has a special syntax - ask where { ?r a nfo:Image . } [14:40] <aseigo> would be interesting to see if distinct is faster or not (in reasonable SQL dbs, it is on indexed tables) [14:40] <vHanda> it will return true/false is that triple is present in the db [14:40] <aseigo> vHanda: aha ... [14:41] <aseigo> and we could ask for multiple types at once to limit the # of query roundtrips? [14:41] * aseigo notes that his sparql knowledge sucks ass [14:41] <aseigo> (and not in a good way) [14:41] <notmart> is there also a good way? :p [14:42] --> Artox has joined this channel (~ar...@pd957cf82.dip.t-dialin.net). [14:42] <aseigo> notmart: i've been told there is. what do i know [14:42] <Artox> Good day everyone [14:43] <Artox> just had PA booting on a fresh image and it showed the initial background image now instead of black screen :) [14:43] <sebas> suck dick, I can understand, but suck ass ... not sure I even want to imagine [14:43] <sebas> Artox: \o/ [14:44] * aseigo thinks Artox wandered in at an unfortunate moment in the conversation [14:44] <vHanda> notmart: aseigo: Yes, but then it would return true only if ALL of them exist [14:44] <aseigo> notmart: so maybe we move to those ask syntax queries? [14:44] --> Shaan7 has joined this channel (~quassel@kde/shantanu). [14:44] <aseigo> vHanda: so we'd have to do one ask per type [14:44] <vHanda> ask where { ?r a nfo:Image , nfo:Video, nfo:Audio . } [14:44] <vHanda> yes [14:45] <vHanda> these queries are typically very fast [14:45] <vHanda> < 5 ms [14:45] <aseigo> FASTER [14:45] <aseigo> ;) [14:45] <notmart> i can try with the type query [14:45] <vHanda> a large part of the time is actually spent in constructing the query and passing it to virtuoso [14:45] <aseigo> but yeah that's .. awesome. and we can fire them off async in one big batch i suppose [14:46] <notmart> the syntax is actually exactly "ask where { ?r a nfo:Image , nfo:Video, nfo:Audio }" ? [14:46] <vHanda> yes [14:46] <notmart> hmm, all i get is a false [14:47] <aseigo> notmart: http://www.w3.org/TR/2013/REC-sparql11-query-20130321/#ask [14:47] <aseigo> notmart: if you put just one of them? [14:47] <notmart> oh, i get one only if all are true [14:47] <notmart> so i would need to do 5-6 queries instead of one [14:47] <notmart> in a way i don't have bindings yet.. [14:47] <notmart> hmm, not sure is a good idea [14:48] <colomar> Are we still talking about a fix for 314141 ? [14:48] <notmart> yes [14:50] <Artox> I am now again on a weird problem. lockscreen works but the PA does not react to mouse/touchscreen [14:50] <Artox> and after unlocking screen, backgroudn is black again and the left and right buttons are missing [14:51] <Artox> logfile says Skipping non-touch device: TSC2007 Touchscreen [14:51] <Artox> or as alterantive(using usb mouse) PixArt USB Optical mouse [14:51] <notmart> nepomuk rebuilt with dependencies btw, should hopefully index mp3s [14:52] <notmart> Artox: what device? [14:52] <Artox> its my gta04 phone again. [14:52] <Artox> I wasgrowing mad of the 2.6.32 kernel and nonreactive PA so tried newer kernel. 3.7 now but I end up with the same problem I had before [14:53] <vHanda> notmart: the reason why { ?r a nfo:Audio, nfo:Video. } doesn't work is cause it tries to target the same ?r [14:53] <vHanda> the correct syntax would be - { ?r a nfo:Audio . ?r2 a nfo:Video . ?r3 a nfo:Image . } [14:53] <Artox> I looked around google and found meego bugs concerning missing support for xinput2 used by qt [14:53] <Artox> some people with an n900 who may have had same issue [14:54] <sebas> Artox: that should work, it does on all the images so far [14:54] <sebas> our Qt is patched for that [14:54] <Artox> so something is still going wrong on my end [14:54] <notmart> vHanda: but in this case i have an or, while i would need more a single query that says images: yes audio: no documents:yes etc [14:55] <Artox> should I care about those Skipping non-Touch device messages? [14:55] <vHanda> yeah. Multiple queries then [14:55] <notmart> Artox: i get some of those messages as well, never did any hurt so far [14:57] --> Fortuona has joined this channel (~ar...@pd957cf82.dip.t- dialin.net). [14:57] <sebas> power management seems fixed now, should I close that bug? [14:57] <colomar> Okay, so I guess our decision to fix 314141 if there is a quick and feasible solution and just hide the numbers if not still stands, right? [14:57] <colomar> sebas: Has anyone tested the fix? [14:58] <aseigo> hm.. how can we see all the rdf:type tags that in the database? [14:58] <sebas> colomar: I just did [14:58] <notmart> anyways, hiding the number is easy, can then be seen if a faster query can be done since numbers are not needed can be seen afterwards [14:58] <sebas> hm, let me do a few more checks [14:58] <colomar> the power management stuff is pretty tricky, power management does all kinds of weird stuff lately [14:58] <sebas> I know, I wrote some of it :) [14:59] <colomar> Like switching off the screen right after waking up from suspend [14:59] <sebas> that didn't happen here, but I think Oliver's patches contained a fix for that, too [14:59] <notmart> i think that bug actually never really existed, it was just an ui misunderstanding [14:59] <colomar> sebas: I don't mean the stuff you told it to do but... weird stuff ;) [14:59] <notmart> ie the sleep is done by the lockscreen [14:59] <notmart> but there was a config ui to set time for sleep not going trough the lockscreen [15:00] --> kallecarl has joined this channel (~carl@kde/symons). [15:00] <sebas> yeah ... the lockscreen and the timeout are orthogonal [15:00] <aseigo> vHanda: can you suggest the best query to grab all the rdf:types known to the db? [15:00] <notmart> so one told to not sleep but when the screen got locked it went in sleep anyways [15:00] <notmart> now the control says lock screen and sleep and is only one [15:00] <colomar> sebas: I think the "Turn off screen" setting should be removed anyway. If the device is not in use, it locks and then suspends, so what is switching off the screen good for? [15:00] <notmart> and should be less misunderstandable [15:01] <vHanda> uhm, all would be 'select distinct ?t where { ?r a ?t . }' [15:01] <colomar> notmart: Yes, that was definitely an improvement [15:01] <notmart> but so far those controls always made it do the thing they were supposed for me [15:01] <vHanda> though this query seems to take quite some time for me, about 4-10 seconds [15:02] * notmart got some bajillions of results from that query [15:02] <colomar> sebas: Especially the default setting for "Turn off screen" does not make sense: After 60 minutes, the device is fast asleep anyway ;) [15:02] <aseigo> vHanda: same here.. 160 entries.. 4.5s [15:03] <notmart> ah, with distinct actually just 131 in 6.80 seconds [15:03] <vHanda> it might be better to just ask for what you want [15:03] <vHanda> I'm not sure about the speed of this, but one can do something like this as well [15:03] <vHanda> select distinct ?t where { ?r a ?t . FILTER(?t=nfo:Audio && ?t=nfo:Video && ?t=nfo:Image ). } [15:04] <vHanda> replace && with || [15:05] <aseigo> select distinct ?t where { ?r a ?t . FILTER(?t=nfo:Audio || ?t=nfo:Video || ?t=nfo:Image ). } <-- 292ms [15:05] <-- Fortuona has left this server (Quit: Konversation terminated!). [15:06] <notmart> ugh, takes 1.70 seconds here [15:06] <vHanda> I would still recommend the multiple queries approach [15:06] <vHanda> this query above will get progressively slower with the increase in db size [15:07] <-- Shaan7 has left this server (Ping timeout: 245 seconds). [15:07] <notmart> for me the query that actually counts the results is faster [15:07] <notmart> select distinct ?label count(*) as ?count where { ?r rdf:type ?label . ?r rdf:type nfo:FileDataObject . ?r nie:url ?h . } group by ?label order by ?label [15:08] <notmart> 900 msec [15:10] <aseigo> 6.34s here for that query [15:11] <notmart> makes sense due to a bigger database [15:11] <notmart> weird that here the other query instead is much slower [15:12] <aseigo> notmart: is this on device or on a tablet? [15:12] <aseigo> er... on device or on desktop [15:12] <notmart> no, on the desktop here [15:12] <aseigo> odd indeed then :) [15:13] * aseigo assumes you've run nepomukcleaner at some point ... [15:13] <aseigo> vHanda: is there a way to FILTER on t=nfo:* ? [15:13] <notmart> long time ago.. redoing [15:13] <aseigo> vHanda: select distinct ?t where { ?r a ?t . FILTER(?t=nfo:Audio && ?t=nfo:Video && ?t=nfo:Image ). } <-- this returns lots of things that are not nfo: ... [15:13] <vHanda> notmart: won't make much of a difference [15:14] <vHanda> aseigo: there is but that would be a string comparison and would be terribly slow [15:14] <aseigo> vHanda: ok.. what does that syntax look like (for shits and giggles) [15:14] <notmart> anyways what i can try is to implement that series of ask queries in the c++ side of files app [15:15] <vHanda> hmm [15:15] <vHanda> not that slow actually [15:15] <vHanda> select distinct ?t where { ?r a ?t . FILTER(REGEX(STR(?t), "^http://www.semanticdesktop.org/ontologies/2007/03/22/nfo#")) . } [15:15] <vHanda> 6 seconds on my system [15:17] <aseigo> <2s here.. still not a barn burner, but this is good to know. regex. cool [15:18] <vHanda> avoid regex if possible, it's quite slow [15:18] <frinring> heya. no idea is this works with nepomuk/virtuoso, but in my tracker using days I learned that using subselects speeds up things with tracker, so perhaps also here. not checked or tested, perhaps this can be faster (and even give numbers): [15:18] <frinring> select (SELECT COUNT(?r) AS ?audiocnt WHERE { ?r a nfo:Audio }) (SELECT COUNT(?r) AS ?videocnt WHERE { ?r a nfo:Video }) (SELECT COUNT(?r) AS ?imagecnt WHERE { ?r a nfo:Image }) where { ?r a ?t . } [15:19] <frinring> (or where they called subqueries, do not remember) [15:19] <vHanda> hmm [15:19] <vHanda> this is pretty fast [15:19] <vHanda> I didn't think of using sub-queries [15:19] <vHanda> select (SELECT COUNT(?r) AS ?audiocnt WHERE { ?r a nfo:Audio }) (SELECT COUNT(?r) AS ?videocnt WHERE { ?r a nfo:Video }) (SELECT COUNT(?r) AS ?imagecnt WHERE { ?r a nfo:Image }) where {} [15:20] <aseigo> 54 ms [15:20] <aseigo> damn [15:20] <vHanda> it's even fast to change the count to ask [15:20] <aseigo> notmart: did you see that? [15:21] <notmart> uh? [15:21] <vHanda> select (ask WHERE { ?r a nfo:Audio }) as ?audio (ask WHERE { ?r a nfo:Video }) as ?video (ask WHERE { ?r a nfo:Image }) AS ?img where {} [15:22] <vHanda> takes about 60msecs on my system [15:22] <aseigo> holy crap .. yeah, the count returns correctly. ... except in ~50ms [15:22] * aseigo just checked against the query we're using right now [15:22] <aseigo> it's the same results (though less pretty since it's subquery .. so one big row with silly column names) but 50ms instead of 3.5s [15:23] * vHanda reminds people that their caches are now very hot after running all these queries [15:23] <aseigo> only 70x faster [15:23] <aseigo> vHanda: yeah, the query we're using right now has dropped to 3.5s from 6s due to that :) [15:23] <aseigo> still, 3.5s == the suck [15:24] <vHanda> which query is this? [15:27] <colomar> Erm... I don't want to interrupt this obviously very productive conversation/hacking, but maybe we should go over the remaining bugs? [15:27] <vHanda> frinring: pm? [15:29] <frinring> vHanda: sure, though I have nothing more to add besides that hint :) [15:29] <notmart> colomar: yeah, +1 [15:29] <colomar> ok [15:30] <aseigo> vHanda: select distinct ?label count(*) as ?count where { ?r rdf:type ?label . ?r rdf:type nfo:FileDataObject . ?r nie:url ?h . } group by ?label order by ?label [15:30] <vHanda> eww, group by .. and order plus 3 joins [15:30] <aseigo> haha [15:30] <aseigo> what could go wrong? [15:30] <notmart> yeah, heavy [15:30] <colomar> So 308515 might be fixed with Webkit 2.3, so we should just retest when that hits Integration? [15:31] <aseigo> colomar: yes [15:31] <notmart> doesn't seem lack or order by does any difference tough [15:31] <colomar> aseigo: Which will be when? [15:31] <rcg> just a short question as i see you all here [15:31] <notmart> yeah, tough i don't think mer has qwebkit 2.3? [15:31] <rcg> when trying to build a new image i get a conflict for the file /usr/lib/kde4/contour_recommendationengine_documents.so [15:32] <rcg> http://pastebin.com/74kXRrcr [15:32] <rcg> is that a known issue or am i just using to conflicting repositories? [15:32] <aseigo> rcg: the contour repo needs to get dropped [15:32] <aseigo> rcg: it merged yesterday with plasma-mobile repo so we don't have multiple repos with random pieces of each other in them [15:32] <rcg> alright [15:33] <aseigo> rcg: anyone who feels like doing that would be most welcome to do so [15:33] * aseigo notes he had wantd to do the merge on monday after tag but the sysadmin team surprised him with a schedule bump [15:33] <aseigo> silly efficient sysadmins :P [15:33] <aseigo> colomar: next bug? [15:34] <colomar> Oh, a propos recommendations: I think we should deactivate the recommendations overlay and the location icon until we turn those into something useful. They don't have much value in their current state, even though the possibilities are huge [15:34] <colomar> But yes, bugs first ;) [15:34] <rcg> aseigo, roger that.. when talking about bmo, which is the suggested repository to use? [15:34] <aseigo> https://bugs.kde.org/show_bug.cgi?id=313565 <-- that one? [15:34] <colomar> https://bugs.kde.org/show_bug.cgi?id=313565 [15:34] * aseigo takes that as a yes [15:34] <colomar> *ggg* [15:34] <aseigo> rcg: ask notmart [15:34] <notmart> rcg: uuh, there is only kde:devel:ux + mx? [15:35] <notmart> err, mw? [15:35] <rcg> notmart, yeah ux+mw [15:35] <colomar> I read Martin Gräßlin's last comment on that bug as "Not possible to fix with our current architecture" [15:35] <notmart> yeah, that one [15:35] <notmart> about the architecture, don't know, thake the one you need ;) [15:35] <notmart> ha, 313565 [15:36] <notmart> yeah, i can't think of a fix atm :/ [15:36] <colomar> So I'd say we remove the "New Tag" option for now [15:36] <rcg> notmart, i can come back later if you are busy now [15:36] <colomar> If people want to create a new tag, they have to go to Files for the time being [15:36] <aseigo> notmart: not a fix we can do by monday ... [15:37] <notmart> eh, don't see much alternative [15:37] <rcg> just thought i ping you while i see you guys being active in here :) [15:37] <aseigo> notmart: i think we'll need support in kwin specifically for keyboards and then let it know about this process' window(s) [15:37] <aseigo> notmart: as per martin's comment [15:37] <aseigo> but that 's work in kwin and the keyboard and not something that can be done in an hour [15:38] <notmart> aseigo: maliit has an "run embedded into application" mode, kwin could use that to have the keyboard in process... [15:38] <notmart> if is still working [15:38] <notmart> not really sure if still supported with the qt5 version [15:39] <aseigo> how would that fix the problem? kwin would still need to handle that window specially, yes? [15:39] <notmart> yes [15:39] <notmart> ah, well, a window type or something could also do i guess [15:39] <notmart> rcg: but what is the problem, you don't have repos for the right architecture, or? [15:41] <rcg> notmart, well, don't know about the problem in ux there are contour and plasma-mobile and apparently those conflict [15:41] <notmart> rcg: just deleted the offending package [15:42] <notmart> maybe will take a while to publish, not sure [15:42] <rcg> which should i delete? contour or plasma-mobile [15:42] <notmart> i deleted contour [15:42] <rcg> roger that [15:42] <notmart> because the contents of contour are now in plasma-mobile [15:42] <colomar> Okay, next one: https://bugs.kde.org/show_bug.cgi?id=316158 [15:43] <rcg> notmart, alright, retrying [15:44] <notmart> for 316158 there should be directory watchers, however i don't know how much time is realistic to expect something actually being in the index [15:46] <colomar> The thing is that indexing is not triggered at all. If I de- and re-activate the indexer, indexing starts immediately [15:47] <colomar> So I assume something's wrong with the watchers [15:49] <notmart> gah [15:50] <colomar> Oh and I just found a new rather nasty bug: When I insert a thumbdrive and tap "Browse files" (btw: Why are there two options which do the same thing?), it presents my with a browser pointing to / instead of to the device, thus exposing the whole file system which we don't want [15:50] <notmart> colomar: and things like just restarting the file browser don't do as well? [15:51] <-- rnovacek has left this server (Quit: Konversation terminated!). [15:52] --> Aristide has joined this channel (~flor...@ip-64.net-81-220-236.rev.numericable.fr). [15:52] <colomar> notmart: Nope [15:52] <colomar> Only restarting the indexer or rebooting [15:52] <notmart> ok, so nepomuk, not the client [15:52] <colomar> yep [15:53] <notmart> vHanda: any idea what could cause files added in an indexed folder not being picked up? [15:53] <colomar> Going to Desktop Search and und- and rechecking "enable Nepomuk Files Indexer" is the only thing that helps [15:54] <colomar> After that, it indexes immediately and the files show up in Files instantly [15:54] <-- aavci has left this server (Quit: Konversation terminated!). [15:54] <aseigo> notmart: could it be that the FS is mounted in a way that prevents file notifications from bubbling up? [15:55] <notmart> eh, may be [15:55] <vHanda> colomar: notmart: inotify limit [15:55] <notmart> aseigo: any idea how to veryfy that? [15:55] <vHanda> $ cat /proc/sys/fs/inotify/max_user_watches [15:56] <sebas> set to 8192 here [15:56] <sebas> that's not a lot, but should be enough? [15:57] <vHanda> nope [15:57] <notmart> sebas: on desktop or on mer? [15:57] <vHanda> 1 per folder [15:57] <notmart> starting a device with an image installed [15:57] <sebas> notmart: on mer [15:57] <sebas> yesterday's image, updated today [15:58] <vHanda> restart the filewatch service and see if it complains - qdbus org.kde.nepmuk.services.nepomukfilewatch /servicecontrol shutdown [15:58] <aseigo> and /proc/sys/fs/inotify/max_user_instances though i doubt that's a problem here [15:58] <vHanda> $ nepomukservicestub "nepomukfilewatch" [15:59] <colomar> vHanda: /proc/sys/fs/inotify/max_user_instances is 128 on my device [15:59] <notmart> uh, has only 128 here [15:59] <notmart> as max_user_watches [15:59] <colomar> same here [16:00] <vHanda> yeah, so that's probably not enough [16:00] <notmart> 8192 as max_user_watches [16:00] <sebas> instances also 128 here [16:01] <colomar> oh yes it was instances here as well [16:01] <colomar> let me check watches [16:01] <aseigo> there's also max_queued_events, but i'd be surprised if that was being reached [16:01] <colomar> they are 8192 as well [16:02] <colomar> (watches) [16:02] <notmart> tried to restart filewatch service [16:02] <notmart> seems fine [16:02] <notmart> a complaint tough "movetothread can't move qobjects with a parent" [16:02] <aseigo> vHanda: is there a log we can poke to see if nepomuk gets told about a file change? [16:03] <aseigo> and silly question time: every directory that nepomuk indexes ... it also puts a watch on it and all necessary sub-dirs? [16:03] <vHanda> nope. the filewatch service does spew out an error message via kDebug() . I think. [16:03] <vHanda> yes [16:03] <vHanda> not only indexes [16:03] <vHanda> ALL DIRECTORIES [16:03] <vHanda> no matter if they are indexed or not [16:04] <aseigo> in the user's home dir, or the entire fs? [16:04] <vHanda> home [16:04] <notmart> colomar: can confirm the issue of opening the file browser in the root directory [16:04] <notmart> can you report a bug? [16:04] <vHanda> + any other directories set as indexed not in your home [16:05] * aseigo "loves" that inotify advertises its max limits, but you can't ask it what its current state is [16:05] <aseigo> vHanda: right... [16:05] <colomar> notmart: Yes, will do [16:05] <vHanda> if it helps I have a student working on using kio for file copies and inotify for file creation [16:06] <vHanda> that decreases the number of watches to a very large extent [16:06] <vHanda> should be ready in time for 4.11 [16:06] <colomar> And I just noticed that I had forgotten to file a bug for the "Could not delete file" problem :( That happens when you discuss problems on the mailing list without filing a bug: They get lost :( [16:06] <notmart> anyways, i just tried to copy a couple of files to the device and they got picked up immediately [16:06] <aseigo> and these watches all use the same inotify instance? [16:06] <notmart> so don't seem to reproduce the bug [16:07] <vHanda> aseigo: yes [16:07] <aseigo> colomar: do you have a lot of directories on your test system? [16:07] <colomar> aseigo: Nope [16:07] <aseigo> or let's try sth more direct [16:07] --> lamarque has joined this channel (~lamar...@187-0-188-92.viaceu.com.br). [16:08] <aseigo> colomar: as root .. try: echo 65536 > /proc/sys/fs/inotify/max_user_watches [16:08] <aseigo> colomar: then try to reproduce the bug [16:08] <aseigo> if it persists.. [16:08] <aseigo> echo 512 > /proc/sys/fs/inotify/max_user_instances [16:08] <aseigo> and try again [16:08] <colomar> ok, will test [16:08] * aseigo notes that the instances limit is almost certainly not being hit, but let's at least be sure [16:09] <aseigo> then we can know if it is a inotify limit [16:09] <vHanda> I also have a patch on reviewboard which spews an error dialog to the user if their limit is too low [16:10] <vHanda> with an option to increase the limit if they provide us with the appropriate password [16:11] <colomar> aseigo: It still persists with 65536 [16:11] --> Shaan7 has joined this channel (~quassel@kde/shantanu). [16:12] <aseigo> colomar: ok.. so that def isn't it.. [16:15] <aseigo> colomar: silly question time #2 -> on your system, the filewatch is running, right? ps aux | grep nepomukfilewatch [16:18] <colomar> yes, it's running [16:20] * notmart tries to reboot to make sure it's actually correctly started at startup [16:20] <notmart> but on this device it appears to be working [16:20] <notmart> have still to test that on the wetab tough [16:21] <colomar> And btw: I could still reproduce the bug after installing a new image, so it does not seem to have been a problem with a specific installation [16:21] <notmart> wouldn't like that just being an hard drive vs an ssd makes the filesystem that tad different to influence it... [16:22] <colomar> notmart: Maybe it _is_ a wetab-specific problem... [16:24] <notmart> hm, this time instead didn't work.. [16:25] <notmart> yeah, nepomukfilewatch running [16:27] <colomar> So what do we do about this? I don't really see a workaround for this bug... [16:28] <sebas> hm, question ... how do I copy files from a USB stick to the disk? [16:28] <notmart> sebas: select them then drag and drop on the disk icon [16:29] <colomar> Hm, looks like we have a discoverability problem here... [16:30] <colomar> Btw: Being the party pooper I am, I just added to new bugs to our list [16:31] <colomar> One for the "Files pointing to /" problem, and the other one for the "cannot delete file" problem [16:31] <-- jayrulez has left this server (Quit: Leaving). [16:31] <sebas> they don't appear automatically in the semantic view here after copying [16:32] <-- Aristide has left this server (Quit: Konversation terminated!). [16:32] <colomar> sebas: So you're experiencing the bug as well. Try restarting the indexer, then it should index them [16:33] <notmart> so if the indexer restarts then new files added after is restarted gets picked up? [16:34] <sebas> gah, wifi problems with the tablet ... need to reboot it [16:34] <sebas> that will restart the indexer though :) [16:35] <colomar> notmart: Nope [16:35] <colomar> Have to restart the indexer for every newly copied file [16:39] <colomar> sebas: Were your powermanagement checks successful? [16:41] <sebas> colomar: this seems to work, yes [16:41] <colomar> feel free to mark the bug as fixed, then ;) [16:41] <sebas> aye [16:42] <sebas> [mer@localhost ~]$ qdbus org.kde.nepmuk.services.nepomukfilewatch /servicecontrol shutdown [16:42] <sebas> Service 'org.kde.nepmuk.services.nepomukfilewatch' does not exist. [16:42] <sebas> fails to restart the file watcher [16:42] <sebas> do I need more than the DISPLAY set when doing this remotely via ssh? [16:42] <notmart> it needs the dbus session.. [16:43] <sebas> eval `dbus-launch` doesn't seem to help [16:45] <pursuivant-349> plasma-mobile (master) Active/3.0-845-g86d1d38 * Marco Martin: applications/filebrowser (2 files in 2 dirs) [16:45] <pursuivant-349> correctly trash files [16:45] <pursuivant-349> is not possible anyways to delete any of the files in the default data, since they are owned by root [16:45] <pursuivant-349> CCBUG:317490 [16:45] <pursuivant-349> http://commits.kde.org/plasma-mobile/86d1d385de5263cb2fabe257d253626cfb41b6fa [16:45] <notmart> it creates a new one, doesn't reuse the one where nepomuk runs already [16:45] <notmart> no idea how to make it run in the proper one [16:46] <notmart> now should be possible to trash files [16:46] <-- ingwa has left this server (Remote host closed the connection). [16:46] <sebas> hm, ok [16:46] <-- mbohlender has left this server (Ping timeout: 248 seconds). [16:46] --> ingwa has joined this channel (~ingwa@130.236.218.222). [16:47] <sebas> also the usb keyboard seems broken, so it's pretty tedious to debug it right now [16:47] <colomar> notmart: great :) Will test it when it's in Integration (which is tomorrow, right?) [16:47] <notmart> small fix, directly in master [16:47] <colomar> ah okay. So I'll test later when I'm at home [16:47] <notmart> aseigo: if i have other fixes master or one branch for those fixes? [16:47] <colomar> eh [16:48] <colomar> It will still only be available tomorrow, right? ;) [16:48] --> [Enrico] has joined this channel (~chiccoroc@gentoo/contributor/Enrico). [16:48] <sebas> yes [16:48] <notmart> ci should still rebuild that every some minutes [16:49] <colomar> ok [16:50] <-- jgrulich has left this server (Quit: Konversation terminated!). [16:50] <colomar> so it should be there tonight? [16:50] <sebas> ah cool [16:50] <colomar> Okay, so that leaves us with https://bugs.kde.org/show_bug.cgi?id=317493 [16:51] <rcg> notmart, had to mess with the plasma-mobile package to enable building a rootfs tarball from .ks: https://build.merproject.org/package/view_file?file=plasma-mobile.yaml&package=plasma-mobile&project=home%3Awonko%3Abranches%3Akde%3Adevel%3Aux&rev=dfaaff48418642f885481a350e8056c8 [16:52] <rcg> note the Provides and Obsoletes entries [16:52] <rcg> at least building via mic now seems to work.. however, i don't know if the result will be usable [16:52] <sebas> colomar: at least I can confirm that :) [16:52] <notmart> rcg: you only changed the provides and obsoletes? [16:52] <rcg> colomar, will upload the rootfs tarball then.. but i'd say its pretty experimental [16:53] <colomar> sebas: Which one: 317493 ? [16:53] <rcg> notmart, well, i changed some minor things in the .spec file such that those things are not overwritten by spectacle [16:53] <rcg> notmart, also note that the cmake call uses .. and not . [16:53] <sebas> colomar: yes [16:53] <rcg> after specify there will be only a single . [16:54] <notmart> hm, would prefer out of tree build [16:55] <notmart> colomar: 317493 happens also on desktop, so i'm on it that should be feasible [16:55] <rcg> notmart, indeed... that's just a quick 'n crude hack to allow building via mic from .ks at all [16:55] <colomar> Oh, so it's a bug in current device notifier? [16:55] <notmart> colomar: i think is a bug in files, because happens also via command line [16:57] <colomar> ah okay [16:57] <notmart> rcg: anyways (with the corrected spec) maybe is worth to merge the package [16:58] <colomar> notmart: Hm... I think it's rather ugly, but maybe not critical because it can easily be worked around by just tapping the icon for the external drive [16:58] <rcg> notmart, alright, i'll leave it in place so that you can create an sr, ok? [16:58] <notmart> sr? [16:59] <rcg> or should i create an sr? [16:59] <aseigo> notmart: one branch is probably fine [16:59] <rcg> submit request [16:59] <rcg> notmart, on obs, or are you pulling that stuff from git to obs? [16:59] <notmart> rcg: ah, yeah, if you can create one would be cool [16:59] <colomar> So it seems that the blockers now left are https://bugs.kde.org/show_bug.cgi?id=314553 (together with related https://bugs.kde.org/show_bug.cgi?id=314902) and https://bugs.kde.org/show_bug.cgi?id=316158 [16:59] <notmart> rcg: btw, maybe you should have access directly to the projects too [17:00] <notmart> aseigo: ok, so i'll put the others in pa4/blockerbugfix or sth like that [17:00] *** lamarque is now known as lamarque_away. [17:00] <colomar> Sorry, I have to leave now. i can join again from home [17:00] <notmart> so, that leaves with... [17:00] <notmart> still tag monday? [17:00] <colomar> see you later (if you're still on then) [17:01] <colomar> depends: If those bugs cannot be fixed, I don't think we should tag [17:01] <colomar> they're too bad [17:01] <colomar> Let's discuss tonight or on the ML [17:01] <notmart> (that would meancompatible with the time i have, all fixes have to be done between today and tomorrow, fun ;) [17:01] <colomar> (sorry, gotta run, cu l8er) [17:01] <-- colomar has left this server (Quit: Leaving.). [17:02] <rcg> notmart, would be also an option. i would of course coordinate with you before pushing something in there [17:02] <notmart> sure, but for me the higher is the bus factor, the better :p [17:03] <-- herby has left this server (Remote host closed the connection). [17:03] <aseigo> notmart: sounds good [17:03] <rcg> btw. plasma-mobile just failed in both my and the official repo [17:04] <notmart> aseigo: and due to the nature of said problems, is stuff that can either be fixed in 5 minutes or stuff i have completely no idea of (ie nepomuk stuff) [17:04] <notmart> ah, yay [17:04] <notmart> will take a look [17:05] <vHanda> notmart: can I help? [17:05] <-- fabian__ has left this server (Quit: Konversation terminated!). [17:07] <notmart> vHanda: boh, not surei think the big one is new files not being picked up, but i have so no idea about it that wouldn't know [17:08] <notmart> maybe you could try to run one image in virtualbox to see if happens here too and if it tells you what is happening there [17:09] --> herby has joined this channel (~quas...@i59f5ef72.versanet.de). [17:09] <-- herby has left this server (Changing host). [17:09] --> herby has joined this channel (~quassel@opensuse/member/hgraeber). [17:15] <rcg> jfyi, uploading a new rootfs tarball for nexus 7 [17:18] <rcg> finished [17:18] <rcg> but as said, i don't know if this works at all ;) [17:19] <-- Shaan7 has left this server (Ping timeout: 240 seconds). [17:22] <sebas> notmart: if you want, I can take the Files opens in / bug as well [17:23] <notmart> sebas: ah, did just fix that... [17:23] <notmart> thx by the way ;) [17:23] <sebas> ow cool :) [17:24] <pursuivant-349> plasma-mobile (pa4/criticalfixes) Active/3.0-846- gc71c6bc * Marco Martin: applications/filebrowser/package/contents/ui/ToolBar.qml [17:24] <pursuivant-349> make sure the proper device root is open [17:24] <pursuivant-349> show the proper path when a path is passed as parameter [17:24] <pursuivant-349> BUG:317493 [17:24] <pursuivant-349> http://commits.kde.org/plasma-mobile/c71c6bc945e130f8c550daa8250374afd3ad549e [17:24] --> jpwhiting___ has joined this channel (~jer...@67-2-73-232.slkc.qwest.net). [17:24] <notmart> so, bugfixes of this round, in pa4/criticalfixes branch [17:24] <sebas> Kim just came home, cu later! -- Marco Martin _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active