Wikiwide | That's neither here nor there : https://build.merproject.org/package/show/home:simonschmeisser:branches:nemo:devel:hw:lge:bullhead/gst-droid | 00:02 |
---|---|---|
* Wikiwide sighs, and continues to idle | 01:15 | |
dcaliste | Good morning pvuorela. Thanks a lot for the festival of merged PRs these last days. | 08:01 |
pvuorela | g'morning. there was indeed quite a bunch of PRs. | 08:01 |
pvuorela | good stuff, thanks! | 08:02 |
pvuorela | think i merged all that i had time to look into. | 08:03 |
dcaliste | I'm surprised the local time was not working actually. I thought I tested it when I developped the UI part some months or years ago. | 08:03 |
dcaliste | Indeed, all recent PRs were merged. | 08:03 |
dcaliste | Concerning older PRs, there is the sync failure resolution trilogy: | 08:04 |
dcaliste | - https://github.com/sailfishos/buteo-sync-plugin-caldav/pull/10 | 08:04 |
dcaliste | - https://github.com/sailfishos/nemo-qml-plugin-calendar/pull/16 | 08:05 |
dcaliste | - and jolla-calendar #312 | 08:05 |
dcaliste | I've reworked the UI part yesterday, according to jpetrell's comments. | 08:05 |
dcaliste | The middleware being more or less the same (I think I rebased it). | 08:05 |
dcaliste | The current working is that, events can be flagged by the CalDAV plugin when they are failing to sync for whatever reason. | 08:06 |
dcaliste | These flags are saved as a string as a volatile incidence property. | 08:07 |
dcaliste | In QML bindings, this string is changed into an enum exposed to the UI. | 08:07 |
dcaliste | So the UI is displaying a warning label. All this is already in. | 08:07 |
dcaliste | The three new PRs are adding a way for the user to flag back the events to indicate what to do to the sync plugin. | 08:08 |
dcaliste | This is done in the same way : via an enum in the QML bindings that is stored as a volatile string. | 08:08 |
dcaliste | The sync plugin is changing its strategy with regard to such flagged events accordingly. | 08:08 |
dcaliste | As jpetrell mentioned in his comments, this is mainly to help the user circumvent unsolvable issues, mainly due to bugs, either on server or in SailfishOS sync plugin. | 08:09 |
pvuorela | alright. could aim to check that next. and/or the dst thing. | 08:11 |
dcaliste | Sure, do it according to your available time of course. Nothing is in a hurry. | 08:12 |
dcaliste | As another topic, I would like to ask you about kernel sources. It's related to https://forum.sailfishos.org/t/reliable-crash-sfos-through-grep-command/10069/26 | 08:19 |
dcaliste | Is there somewhere a git repo of the kernel sources used in the device ? | 08:20 |
dcaliste | Are they only available as a tarball, without commit history and applied patches ? | 08:20 |
dcaliste | In any case, what is the best way to submit a patch to kernel sources ? | 08:21 |
pvuorela | um, think the kernels are somewhere but since i try to stay on the userland side i don't have an immediate link | 08:21 |
dcaliste | I'm asking this, because I've looked to the upstream kernel, in its git history also, but I cannot find any trace of the line I think is errneous in u_serial.c | 08:21 |
dcaliste | Sure, I prefer the userland also, but a `cat readstatus` that makes a kernel Oops and reboot the device is a bit annoying... | 08:22 |
Wikiwide | Wow. Bus 007 Device 030: ID 22b8:ff48 Motorola PCS F(x)tec Pro1 . What is that mode? | 08:23 |
pvuorela | dcaliste: which device were you interested in? jolla c or x10 II? | 08:29 |
dcaliste | I've a JollaC. | 08:30 |
pvuorela | out of interest, do you do all the development on that or do you have some newer one too? | 08:31 |
pvuorela | on the x10 II guess this would be relevant https://github.com/mer-hybris/android_kernel_sony_msm/ | 08:31 |
pvuorela | mal: you might know better here :) ^ | 08:33 |
mal | pvuorela: know what? | 08:38 |
pvuorela | sources for jolla c kernel | 08:38 |
dcaliste | I'm using only a JollaC. It's my day to day phone ! | 08:42 |
pvuorela | dcaliste: brave if you also develop all the things on the same thing :) | 08:44 |
dcaliste | I guess the kernel is built from somewhere for each release, but maybe it's internal only... | 08:45 |
pvuorela | yea, it differs between all the devices what the kernel is and where it lives. | 08:45 |
dcaliste | Yes, it's simpler for me to develop on the same device I'm using daily. It helps to test and I try not to break too many things so it's still usable. | 08:46 |
dcaliste | That's also why, I'm not much eager to touch to lipstick, and even more the kernel. | 08:46 |
pvuorela | very understandable. | 08:47 |
dcaliste | In any case, as I mentioned in the forum comment, I think a check for non NULL pointer is missing in u_serial.c#1292, file from kernel-adaptation-l500d-b690c5d16244040d5f4b0265a56e3b406f6ae1bb/drivers/usb/gadget/ | 08:49 |
dcaliste | I didn't test because I've no idea how to rebuilt the kernel and safely put it on device without bricking it. But it's the best bet I can do from the trace. | 08:50 |
pvuorela | dcaliste: guess the l500d parts here could be of help http://releases.sailfishos.org/sources/4.0.1.48/ | 08:50 |
mal | jolla c kernel sources are available here http://releases.sailfishos.org/sources/4.0.1.48/ | 08:51 |
pvuorela | sync :) | 08:51 |
dcaliste | Yes, that's where I got the sources from. But I would have hoped for a git tree with history to compare it to upstream and see where the faulty patch comes from. | 08:51 |
dcaliste | And upstream the fix if necessary. | 08:52 |
dcaliste | The `if (gser->get_dtr)` on line 1292 is very suspicious and missing a `gser && ` in my opinion. | 08:53 |
mal | dcaliste: what issue are you trying to fix? | 08:57 |
dcaliste | `cat /d/usb_serial0/readstatus` creates a kernel Oops and reboot the device. | 08:57 |
dcaliste | Not really a big deal, but not very nice. | 08:58 |
dcaliste | See https://forum.sailfishos.org/t/reliable-crash-sfos-through-grep-command/10069/25 for the associated partial kernel trace. | 08:58 |
mal | dcaliste: is there anything in last_kmsg? | 09:01 |
mal | ah, that is in the forum post | 09:01 |
dcaliste | I'm at all used to kernel developping, but I didn't find any trace upstream of the debug functions like debug_read_status() from u_serial.c. So I guess they have been added as a patch, but without git history, it's a bit difficult to find. | 09:03 |
dcaliste | s/I'm/ I'm not/ | 09:04 |
mal | those are sometimes quite annoying to debug | 09:09 |
dcaliste | Well, if you have access to the kernel source repo, you can add there a `(gser && gser->...)`, it cannot hurt and may fix the problem. | 09:11 |
dcaliste | Some people reported it for XA2 in the forum also, if I remember well. Or X10, not sure. | 09:12 |
mal | hmm, I can test that later | 09:13 |
dcaliste | Thank you mal. | 09:17 |
henk | I wish software would stop giving me math homework: that short message was received '33 m ago'. MFer I want the exact time! at least show me a fscking clock so I can do the math! it gets worse the longer it was ago: tweeted 1 day ago. WTF does that mean? exactly 24h? more than 12 hours? before 00:00 today, i.e. yesterday? what is the point where it’s not "exact to the minute" anymore but | 09:18 |
henk | "accuracy to something between 12h and 48h needs to be enough … or maybe 6h? because it depends on when the date swiched? who knows, go read the fscking source code. loser." | 09:18 |
henk | to devs: please don’t waste CPU cycles on calculating this, checking if displayed things need to be updated constantly because now it’s 34 minutes, then update that shit, just show the fscking timestamp. or at least make that configurable if you enjoy programming these details. please. thank you | 09:21 |
dcaliste | Thank you mal and pvuorela for your help today. I think that's all from my side. Don't hesitate to ping if you want to ask some clarification on points discussed today. Enjoy the week ! | 09:21 |
pvuorela | dcaliste: thanks | 09:23 |
*** ggabriel is now known as Guest1404 | 16:13 | |
piggz | rinigus: ping | 21:41 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!