[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Re: tagging on Monday(?)
From:       Marco Martin <notmart () gmail ! com>
Date:       2013-03-28 19:54:24
Message-ID: 201303282054.24876.notmart () gmail ! com
[Download RAW message or body]

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 (~Artox@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 (~Artox@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 
(~florian@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 
(~lamarque@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 (~quassel@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  (~jeremy@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


[prev in list] [next in list] [prev in thread] [next in thread]