*** zbenjamin_ is now known as zbenjamin | 02:10 | |
dcaliste | Hello chriadam, I hope you envoyed nice vacations. | 08:13 |
---|---|---|
chriadam | dcaliste: hi, thank-you, yes ;-) snowboarding, was fun | 08:13 |
chriadam | dcaliste: I hope you've been well | 08:13 |
dcaliste | I'm fine, thanks. I've seen your comments on the security-ui thing. | 08:14 |
chriadam | (I didn't get a chance yet to test your patch) | 08:14 |
dcaliste | No prblem, as I was mentioning, it's not a definitive fix. | 08:15 |
dcaliste | It just makes the app crash later in the call stack… | 08:15 |
chriadam | ah, I didn't understand that. what crashes later? qtquick side? | 08:17 |
dcaliste | Yes, if you look at the backtrace in the snippet, you see that it happens from a call in qtquick -> qtwayland. | 08:18 |
dcaliste | To summarize: | 08:18 |
dcaliste | the render thread is in a QWaylandGLContext::swapBuffers() call. | 08:19 |
dcaliste | at the same time, the main thread is destroying the the window that the rendering thread is swapping. | 08:19 |
dcaliste | In this scenario, there are several possible place for the app to crash: | 08:19 |
dcaliste | - in libhybris at two different places, because the the swap buffer call is calling internally prepareSwap() and later on finishSwap() with pointer on the window that is nullified in the main thread. | 08:20 |
dcaliste | - if we survive libhybris, there is a last call in swapBuffer in QtWayland (doResize stuff) that is called at the end of the routine that is accessing private members of the window that have been destroyed in the main thread. | 08:21 |
dcaliste | I've patched libhybris in the mentioned PR on Github.com to avoid accessing nullified pointers and add locking mechanism for the main thread to set this pointer to null safely. | 08:22 |
dcaliste | But I've no idea how to proceed for QtWayland, because I didn't see any locking mechanism there. | 08:23 |
dcaliste | And we are at the threat of the main thread destroying the object while the rendering thread is still within swapBuffer(). | 08:23 |
dcaliste | I want to give a look in QtQuick to see if there is some smat pointer mechanism there ensuring that the object is not destroyed while the rendering is still using it, but didn't find the package with debug symbols. | 08:25 |
tortoisedoc | dcaliste : the object living in the gl state machine is a copy of the one in the main thread, living in gpu memory? | 08:25 |
dcaliste | I've seen you mentioned mer-qt repo, I'm going to check if it is enabled on my device. | 08:25 |
tortoisedoc | mal : can you point me to enable valgrind in sb2? | 08:26 |
tortoisedoc | ...it seems due to stripped ld-linux.so, valgrind refuses to run | 08:26 |
chriadam | dcaliste: mine is internal repo, but hopefully the same packages also exist in public repositories... mer-qt ... https://download-internal.jollamobile.com/mer:/qt/latest_armv7hl/ | 08:26 |
dcaliste | tortoisedoc: for the gpu, yes I guess so, but here we're still on CPU, having two CPU threads, as far as I understand, and the main one is destroying memory used by the rendering one in my particular scenario. | 08:27 |
tortoisedoc | dcaliste : garbage collecting? | 08:27 |
chriadam | no, race between window close causing destruction of surfaces, and final frame being rendered from window to egl buffer | 08:28 |
chriadam | (if my understanding is correct) | 08:28 |
dcaliste | chriadam: thanks for the rephrasing, exactly my thinking ;) | 08:28 |
chriadam | dcaliste: one sec, just pinged denexter | 08:31 |
dcaliste | chriadam: about the repo, 'ssu lr' doesn't show me any disabled repos that may be of interest, and 'pkcon search qtquick' doesn't list any debuginfo package… | 08:32 |
chriadam | dcaliste: can you pastebin or email `ssu lr` output? | 08:33 |
chriadam | also, qtdeclarative not qtquick | 08:34 |
dcaliste | chriadam: https://pastebin.com/WgFUheim | 08:35 |
dcaliste | chriadam: Ah, I see, there is a qtdeclarative-debuginfo, goos. | 08:36 |
dcaliste | good. | 08:36 |
dcaliste | It may cover the qt5-qtdeclarative-qtquick subpackage, indeed. Thanks for the tips. | 08:37 |
chriadam | no worries. that ssu lr output is different to what I expected, e.g. no mer-core or mer-qt. I wonder if you try to access https://cbeta.jolla.com/releases/3.0.1.13/mer/qt/armv7hl/ does that work? or https://cbeta.jolla.com/releases/3.0.1.13/mer/core/armv7hl/ ? | 08:37 |
dcaliste | I don't know, because I don't know how to provide credential if I curl these URLs for instance. But I'm installing the qtdeclarative-debuginfo package and I will see if that's enough. | 08:40 |
chriadam | cool | 08:40 |
chriadam | hopefully qt5-debuginfo for qtcore/qtgui will work also | 08:40 |
chriadam | dcaliste: Andrew said that it might (or might not) be fixed with upgraded QtWayland (e.g. Qt 5.9) | 08:42 |
chriadam | aside from that he couldn't offer much advice unfortunately | 08:44 |
chriadam | I agree that it's v.strange that qtquick doesn't internally manage its state to avoid the race | 08:44 |
dcaliste | Yes, that's why I would like to give a look. Maybe it's just how we are calling it that creates the race in this specific scenario and not in the majority of cases. | 08:46 |
chriadam | right, if the window destruction is somehow being triggered due to server-side signal in this case, rather than normal "application is quitting" case | 08:49 |
chriadam | or something else "unusual" | 08:49 |
chriadam | well, I really appreciate you looking into this. regardless, I think defensive programming (your hybris PR) makes sense, I will ask people to review / test / merge your pr | 08:50 |
chriadam | on the email / signature stuff side, jpetrell is still on leave, he should be back in 2 days IIRC | 08:51 |
chriadam | then we can get the ball rolling on that one again I think | 08:51 |
chriadam | unrelated, but I noticed at recently sailfish community meeting, someone raised the IMAP IDLE issue again. I will follow up on that one internally, too, as JB#32000 was recently marked for maintenance work IIRC | 08:52 |
chriadam | oh, no, it was just flagged internally again, but not yet approved for maintenance work | 08:53 |
Dakon | the whole IMAP stuff sucks | 08:53 |
dcaliste | Thank you. Indeed, in my opinion, there is an issue there in libhybris and I would like to discuss it with whoever knows better than me on this topic. | 08:54 |
chriadam | Dakon: what in particular? | 08:54 |
Dakon | it keeps duplicating deleted mails in my trash folder, it is slow and unreliable marking mails as read or moving them to the correct folder | 08:54 |
chriadam | dcaliste: sledges / frajo / abranson probably know libhybris best | 08:54 |
Dakon | and it seems to completely get messed up when you mark mails as read or even delete them from a different host | 08:55 |
dcaliste | About IMAP stuff, yes that bug is tricky about loosing idle. It takes a lot of time to investigate. I really would like to make it goes on but I really have no time for it now. | 08:55 |
Dakon | and it only watches inbox | 08:55 |
chriadam | dcaliste: I hope that rainemak has time to investigate that one | 08:55 |
chriadam | as he did similar work for exchange in the past IIRC | 08:55 |
abranson | dcaliste: thanks for helping point out that it's not a trivial bug to fix in the last meeting :) | 08:56 |
chriadam | Dakon: if you can provide me with logs of error case syncs (e.g. the duplication events etc) and email to chris dot adams at jolla dot com I would appreciate it | 08:56 |
dcaliste | Concerning GPG stuff, I'll be off the two next Tuesdays, but will be around some of the other days. I've addressed all remarks from pvuorela on the GUI side. Don't hesitate to test internally and report anything in the various MRs, I'll reply quickly there. | 08:56 |
chriadam | Dakon: you may have to enable a bunch of debugging output (see https://sailfishos.org/wiki/Sailfish_OS_Cheat_Sheet#Diagnostics for more info) | 08:56 |
chriadam | dcaliste: no worries, and thank you very much | 08:57 |
chriadam | I'll poke jpetrell when he gets back, and we will finally get all that stuff in ;-) | 08:57 |
rainemak | generally speaking... if you see / find something useful missing from e.g. Sailfish_OS_Cheat_Sheet please raise / propose improvements | 08:58 |
chriadam | indeed | 08:58 |
chriadam | abranson: are you able to help dcaliste with libhybris things, by any chance? | 08:58 |
dcaliste | I wish so ;) I would happy to have some feedback from cbeta and early adopters also, that would be great. | 08:59 |
krnlyng | chriadam, i am in the process of updating libhybris to a common base, i will look into the rendering issue afterwards if that is ok (otherwise we need to cherry-pick it to each adaptation) | 08:59 |
krnlyng | rendering PR* | 08:59 |
chriadam | krnlyng: yes, that sounds very sensible | 08:59 |
chriadam | what is the eta for that, ooi? | 08:59 |
krnlyng | chriadam, this or next week hopefully | 09:00 |
chriadam | definitely no problem ;-) | 09:00 |
chriadam | thank you | 09:01 |
chriadam | dcaliste: did you have anything else to discuss tonight? did I forget anything of importance which I need to follow up on over the coming weeks? | 09:01 |
abranson | chriadam: i'm not very knowledgeable about libhybris - krnlyng's your man there ;) | 09:02 |
dcaliste | No, the main blocker IMHO for the GPG stuff is the hanging of security-ui and we have discussed this a lot today. I'm going to look into the call path in QtQuick to see if we're doing something strange there. | 09:02 |
Dakon | and the email app needs a option "automatically mark mails as read when moving to trash" as roundcube has it | 09:02 |
chriadam | Dakon: that sort of feature request is sensible. when jpetrell gets back you should mention that to him. | 09:03 |
Dakon | when will that be? | 09:03 |
dcaliste | Dakon, that's true, I agree, I'll give a look, no ETAt though. | 09:04 |
chriadam | Dakon: jpetrell should be back at the end of this month, e.g. 2 or 3 days I think | 09:05 |
chriadam | ok, thanks again - if there's nothing else to discuss, I will head home now :-) have a good night / week, and I look forward to discussing with you again in 3 weeks hopefully after merging the gpg stuff to email side! | 09:07 |
dcaliste | Have a good night. Thank you for all the feedback ;) | 09:07 |
Dakon | oh, and a switch "don't bother me with the HTML cruft, show the text/plain part only. always." | 09:09 |
tortoisedoc | martyone_ : ping | 09:22 |
martyone | tortoisedoc: pong | 09:23 |
martyone | tortoisedoc: reply to your last question: I assume you installed them inside tooling (correct). Did you run sb2-init after that, to tell sb2 about the new compiler? | 09:23 |
martyone | tortoisedoc: get an irc boucer ;) | 09:23 |
martyone | bouNcer | 09:24 |
tortoisedoc | martyone : hey, thanks, yes I got the gcc4.9 working thanks :) now Im investigating memory bubbles in rustc, so I need valgrind. But as ld-linux.so is stripped, valgrind is not cooperating :( | 09:28 |
tortoisedoc | martyone : so I am looking how to use valgrind effectively from within sb2 (or from outside if necessary) | 09:31 |
martyone | tortoisedoc: I have no answer to that at hand, sorry | 09:32 |
tortoisedoc | martyone : is the source code for ld-linux.so somewhere? | 09:33 |
martyone | definitely, part of glibc I guess | 09:34 |
tortoisedoc | hmhm | 09:37 |
tortoisedoc | thanks, ill have a look | 09:37 |
Laalf | so i bought an xa2 because my op3 died and sfos seemed nice. i also saw that there will be an option to buy the full package of sailfishos soon for this device. what does "soon" mean? | 18:02 |
r0kk3rz | a not too distant point in the future | 18:03 |
Laalf | the first contact i had with sfos was pretty much saturday. so i dont really know what "too distant" means for jolla | 18:04 |
leszek | This year definitely. Q1 maybe. Is that better? | 18:05 |
Laalf | yep. thanks. fingerprint won't come with that, right? | 18:06 |
r0kk3rz | idk its already been delayed once or twice, so who knows | 18:08 |
leszek | Laalf: I am not even sure we will get fp this year | 18:19 |
Laalf | leszek: fingerprint isnt that important, autocorrect would be though.. | 18:19 |
caitlin | got pretty used to jolla making up release dates for things and then releasing less than suggested later than suggested. but it does at least work. | 18:27 |
leszek | Laalf: there is no autocorrect available for SailfishOS. There is text predicition that should work already without an issue on Xperia X. | 18:31 |
leszek | XA2 will have it with the commercial image | 18:31 |
Laalf | i have an xa2 | 18:31 |
Laalf | idk, ill probably get used to it. | 18:32 |
vinipsmaker | where do I report issues and feature requests for the virtual keyboard? | 18:37 |
vinipsmaker | I reported a few to the maliit repository, but I think that was the wrong place to report | 18:38 |
*** Renault_ is now known as Renault | 18:39 | |
leszek | vinipsmaker: I think tjc aswell might help | 18:42 |
vinipsmaker | leszek: thanks | 19:25 |
vinipsmaker | tjc: ping | 19:26 |
attah | So I tried wdehoog's gstreamer from yesterday, but it seems my /var/lib/environment/nemo/90-gstreamer-playbin.conf isn't being run | 19:36 |
Laalf | kido: so starfish is incredibly white. and only white. | 19:49 |
kido | damn whitewashing | 19:50 |
Laalf | lol | 19:51 |
kido | Laalf: well, probably there is a bug, I assume you compiled it yourself and ran it from Qt Creator, didn't you? don't you have logs of what's going on in the tiny execution box at the bottom of the window? | 19:51 |
Laalf | kido: i imported that project and i hope i compiled it correctly. gave me a 32kb or so rpm that i just installed on my phone | 19:52 |
kido | if you got a rpm probably the compilation went fine but there is a problem at the execution | 19:52 |
Laalf | where can i find logs? | 19:53 |
Laalf | or do you have a package? | 19:53 |
kido | I just remembered you also need that daemon here: https://github.com/AsteroidOS/asteroidsyncservice | 19:53 |
kido | we did some work to have it work for both SFOS and Ubuntu Touch but it might be that we got it to work on neither of those in the end | 19:54 |
Laalf | so i compile that thing as well, install it and hope for the best? | 19:54 |
kido | sort of, yeah | 20:00 |
kido | story of my life :| | 20:00 |
kido | what I suspect happens is the QML code from starfish (which is not parsed before building the RPM) tries to import org.asteroid.syncservice which is distributed as part of the asteroidsyncservice repository https://github.com/AsteroidOS/starfish/blob/master/qml/starfish.qml#L22 | 20:01 |
kido | and since it doesn't find it, then QML is unhappy and the whole thing doesn't work ;) | 20:02 |
kido | but you should find a way to run starfish from QtCreator if you want a convenient way to work on it | 20:02 |
Laalf | i should just buy an old pebble | 20:02 |
Laalf | those seem to work | 20:02 |
kido | oh and from a look at it, asteroidsyncservice also depends on libasteroid | 20:03 |
kido | https://github.com/AsteroidOS/libasteroid | 20:03 |
Laalf | oh god | 20:03 |
kido | eheh :) | 20:03 |
kido | I told you it's not entirely trivial | 20:03 |
kido | there is a lot of work to do on sailfish to implement this in a way that the connection isn't lost when the app closes | 20:04 |
kido | and also there is a lot of work done to make the whole thing modular so that other projects (such as Telescope, the Ubuntu Touch client) don't have to reinvent the wheel | 20:04 |
Laalf | id rather just spend another few € on a watch that will kinda work out of the box | 20:06 |
Laalf | but i dont even know what that would be | 20:06 |
kido | yeah I understand that, thanks for trying at least ;) | 20:10 |
kido | as I told you there is quite a bit of work required to make starfish work so it needs proper motivation | 20:10 |
Laalf | i am not that big of a dev. so if it doesnt work i probably wont do anything anyways... lets see if i can find some hardware list for pebble/rockpool | 20:11 |
kido | sounds like a simpler way indeed | 20:12 |
Laalf | cant get my lifetime back. i can get my money back though. i shouldnt be scared of closed software since i am running sailfish:') | 20:13 |
kido | :) | 20:23 |
Laalf | if someone runs rockpool, could you tell me what watch you run? i cant seem to find anything on which watch would be ok to buy | 20:24 |
wdehoog | attah: it is not working? too bad | 20:45 |
attah | Weird how that file is not processed | 20:46 |
attah | If you are running that, what is your output of env | grep GST | 20:46 |
attah | ? | 20:46 |
wdehoog | running what? | 20:47 |
attah | that patched bunch of gstreamer packages | 20:47 |
wdehoog | if I ssh in it prints: NOTICE: Env value ignored GST_PLAYBIN_FLAGS=0x182 | 20:48 |
wdehoog | for the shell the two vars are not allowed | 20:48 |
attah | interesting | 20:48 |
wdehoog | but for apps I launch (sailsoma of shoutcast-sailfish) they work | 20:49 |
attah | but they apply anyway, how would one know? | 20:49 |
wdehoog | the other one: NOTICE: Env value ignored GST_PLAYBIN_BUFFER_SIZE=256000 | 20:49 |
attah | you get that from just SSH-ing in? | 20:50 |
wdehoog | well without them shoutcast-sailfish takes ages before a 320 stream is buffered | 20:50 |
wdehoog | with the buffer it is a few seconds | 20:50 |
attah | O.o | 20:50 |
wdehoog | yes plain ssh | 20:50 |
wdehoog | see https://pastebin.com/JYqHg7VY | 20:50 |
attah | hah, what do you know.. i get those warnings | 20:51 |
attah | they are just, as it says, ...ignored | 20:51 |
attah | I perceive a *slight* improvement to initial stuttering.. but at the expense of alot more lag until start | 20:53 |
attah | sight ~=50%, alot ~=10x | 20:53 |
wdehoog | they are being filtered here: /etc/profile.d/developer-profile.sh | 20:53 |
attah | i just thought my app was acting up on the latter | 20:53 |
wdehoog | slight is not enough, then it will not help you at all | 20:54 |
attah | no, not really | 20:54 |
wdehoog | maybe try other flags or bigger buffer | 20:54 |
attah | I'm on 512 already | 20:54 |
wdehoog | or it is just another problem | 20:54 |
attah | I should try switching to a seekable stream version and seek back soem seconds initially | 20:55 |
wdehoog | or ask a jolla person. abranson might know more on gstreamer | 20:56 |
attah | Yeah... just throwing a live .mp3 stream at the QML MediaPlayer should be expected to work somewhat reliably | 21:00 |
attah | as in stutter only on bad networks or so | 21:00 |
wdehoog | attah: just curious do you have a journal log of what happens when you start playing the stream? | 21:00 |
attah | i could make one i guess | 21:01 |
attah | journalctl -f gives nothing but my debug printouts | 21:02 |
wdehoog | maybe use GST_DEBUG or stuff like that | 21:06 |
attah | hmm, i did export GST_DEBUG=1 and then launced the app via xdg-open on the .desktop file (since it is a pure QML app), no change to jounal | 21:10 |
wdehoog | or increase log of pa: http://www.merproject.org/logs/%23sailfishos-porters/%23sailfishos-porters.2017-09-26.log.html#t2017-09-26T11:22:58 | 21:10 |
wdehoog | xdg-open? will that result in setting the correct flags and buffer_size? | 21:11 |
attah | although 1 isn't high enough it seems | 21:11 |
attah | i thought this was system wide? | 21:12 |
attah | just not the devmode console for whatever reason | 21:12 |
wdehoog | but you start xdg-open from that console? or not? | 21:12 |
attah | oh, right | 21:12 |
attah | le derp | 21:13 |
attah | sooo debug level 5 seems to do the business | 21:14 |
attah | it log so much that the audio becomes laggy :P | 21:14 |
attah | seems i have something to to tomorrow evening as well | 21:17 |
wdehoog | attah: so I have to do like this: GST_PLAYBIN_FLAGS=0x182;GST_PLAYBIN_BUFFER_SIZE=256000 xdg-open /usr/share/applications/shoutcast-sailfish.desktop | 21:21 |
attah | right, that makes sense | 21:21 |
wdehoog | this does not work: xdg-open /usr/share/applications/shoutcast-sailfish.desktop | 21:21 |
wdehoog | for me that is | 21:21 |
attah | But i need more than a few minutes if i'm going to read the amount of log it produces... thus, tomorrow | 21:23 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!