| parazyd | Wizzup: What's the gconf path? | 06:27 |
|---|---|---|
| kona | Sicelo: I think I read that you worked on getting trojita running. I just tried it from osso-xterm and it behaves hikdonized, but if I start from the app manager, it looks totally different and doesn't respond well to input. Is there something wrong with my app manager shortcut? | 07:00 |
| kona | s/ik/il/ | 07:01 |
| Wizzup | parazyd: there are several | 10:03 |
| Wizzup | parazyd: one per network type (wlan_infra, gprs, wlan_adhoc, dummy) | 10:03 |
| Wizzup | parazyd: see gconftool -R /system/osso/connectivity/network_type | 10:05 |
| lel | MerlijnWajer synchronize a pull request: https://github.com/maemo-leste/connui-internet/pull/3 (status-menu-item: use iap_common_get_service_properties) | 10:08 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/connui-internet/pull/3 (status-menu-item: use iap_common_get_service_properties) | 10:08 |
| Wizzup | uvos: btw, upgraded mce and see no problems yet | 10:13 |
| uvos | Wizzup: great | 11:10 |
| uvos | kona: so trojita right now breaks with the maemo qt platform plugin because it uses a hambuger style menu that gets miss translated by the platform plugin into a hildon menu | 11:11 |
| uvos | kona: so the .desktop file disables the platform plugin for now | 11:11 |
| uvos | kona: ill hide enough menu entrys to make it work as soon as i get to it, and also we should improve the hildon menu to support submenus. | 11:12 |
| uvos | kona: anyhow input via vkb via the native method dosent work with or without the plugin as its not implemented in qt yet | 11:12 |
| uvos | kona: but d4 hwkbd and vkb with x11 backend (opend via the search key on d4 or vol up on pp) works fine for me | 11:13 |
| Wizzup | porting the qt5 input method was trickier than I hoped for | 11:13 |
| Wizzup | mostly just because I don't understand X well enough for all the keysym converstion stuff | 11:13 |
| Wizzup | conversion* | 11:13 |
| Wizzup | I did try, might have that work on some branch still | 11:13 |
| uvos | Wizzup: maybe just implementing the acessability dbus interface in him and improving its x11 backend a bit would be a good solution, at least as a stop gap, but imo permanently as well | 11:14 |
| uvos | since that would get everything working (also gtk3) for now untill we have enough time to go around and implement soemthing custiom in eatch toolkit.... | 11:15 |
| Wizzup | mhm | 11:15 |
| parazyd | Wizzup, freemangordon: Does it matter which user runs gconftool to make edits? | 11:24 |
| Wizzup | I think it is best if it runs as 'user', but I am not sure. | 11:25 |
| freemangordon | parazyd: I think so | 11:29 |
| uvos | well all the keys are there even if you run it as root (sudo su -) | 11:31 |
| Wizzup | I think that is true when gconf already runs | 11:31 |
| freemangordon | dpkg: error processing archive /tmp/apt-dpkg-install-gRaeHu/82-mce_1.9.0+2m7.1_amd64.deb (--unpack): | 11:31 |
| freemangordon | trying to overwrite '/usr/include/mce/dbus-names.h', which is also in package mce-dev:amd64 1.8.22+2m7.1 | 11:31 |
| freemangordon | * Caching service dependencies ... [ ok ] | 11:31 |
| freemangordon | * Stopping mce [ !! ] | 11:31 |
| freemangordon | * Starting mce ... | 11:31 |
| freemangordon | * ERROR: mce failed to start | 11:31 |
| freemangordon | invoke-rc.d: initscript mce, action "restart" failed. | 11:31 |
| freemangordon | dpkg: error while cleaning up: | 11:31 |
| freemangordon | installed mce package post-installation script subprocess returned error exit status 1 | 11:31 |
| freemangordon | uvos: ^^^ | 11:31 |
| uvos | thats dsmes fault | 11:32 |
| uvos | we debugged this before, iirc mce registers with dsme for the heartbeat thing and there is a race where dsme rejects mce's reconeccting if it restarts to fast because it hasend cleaned up yet | 11:33 |
| Wizzup | yeah dsme doesn't wait for the process it kills to exit | 11:34 |
| Wizzup | at least via dsmeutil | 11:34 |
| Wizzup | (since dsmeutil doesn't own the pid, it can't know) | 11:34 |
| Wizzup | it happens also with icd2 | 11:35 |
| uvos | "I think that is true when gconf already runs" | 11:37 |
| uvos | how it gconf supposed to work in a multi user env. ? | 11:37 |
| freemangordon | uvos: trying to overwrite '/usr/include/mce/dbus-names.h' is not dsme fault, but debian/control | 11:38 |
| uvos | oh that diden see it | 11:38 |
| uvos | ok interesting | 11:38 |
| freemangordon | uvos: I'll look at mce restart later on | 11:38 |
| uvos | so for mce its mce gets killed via dsmetool & is exiting but then dsmetool dosent wait so openrc restarts mce immidatly | 11:40 |
| uvos | then the new mce exits with failure because either it cant connect with dsme for heartbeat or it cant own its dbus name (depending on moudle load order) both because the old mce istent done exiting | 11:41 |
| freemangordon | uvos: I' | 11:41 |
| freemangordon | I meant - will see if I can do anything about it | 11:41 |
| uvos | right | 11:42 |
| uvos | i was just makeing sure you understand what is happening | 11:42 |
| freemangordon | maybe add waitpid to dsmetool or something | 11:42 |
| freemangordon | thanks | 11:42 |
| Wizzup | I don't think you can waitpid on pids you do not own | 11:43 |
| Wizzup | you could extend dsme socket protocol | 11:43 |
| uvos | you can wait on the /proc file | 11:43 |
| Wizzup | that's racy and a busy loop iiuc | 11:43 |
| uvos | no | 11:43 |
| uvos | you can wait for a event on the file | 11:44 |
| uvos | via the io wait interface | 11:44 |
| Wizzup | til you can inotify on /proc | 11:44 |
| uvos | for some files yeah | 11:44 |
| Wizzup | got some pointers? | 11:44 |
| uvos | no i just tried this for sigstoped | 11:44 |
| uvos | i hope its defined behavior :P | 11:44 |
| parazyd | Wizzup, freemangordon: So, I didn't test this, but: http://sprunge.us/QgfBCb | 11:46 |
| parazyd | Something like this should work, no? | 11:46 |
| parazyd | (I forgot "su user" on the gconftool calls in post{inst,rm} | 11:47 |
| uvos | Wizzup: looks like https://man7.org/linux/man-pages/man2/pidfd_open.2.html is a prefered solution if you just want to wait for a proc to exit | 11:49 |
| uvos | (just found that via google) | 11:50 |
| Wizzup | Can that be used as non-parent? | 11:50 |
| uvos | yes | 11:50 |
| Wizzup | ah I see the EXAMPLES section | 11:51 |
| Wizzup | sounds dsmeutil could maybe use that then | 11:51 |
| uvos | yeah proubly better thant wating on status like sigstoped used to do | 11:51 |
| uvos | (well sigstoped needs the process state anyhow and not just if it exits so different use case) | 11:52 |
| uvos | Wizzup: looks like this landed in 5.3 tho https://lwn.net/Articles/789023/ | 11:53 |
| uvos | Wizzup: thats a problem n900 is on 5.2 right? | 11:53 |
| uvos | also breaks any hope of using meamo on android vendor kernels (not that we care) | 11:54 |
| Wizzup | yeah we don't care about vendor kernels | 11:54 |
| Wizzup | we'll get n900 to newer kernels eventually | 11:55 |
| Wizzup | but yeah that is a problem in the immediate term | 11:55 |
| Wizzup | uvos: so 'apt remove mce-dev' "solves" the problem | 11:57 |
| uvos | right /usr/include/mce/dbus-names.h is a file that belongs in -dev | 11:57 |
| uvos | but it must have slipped into the mce pacakge | 11:57 |
| uvos | ill look later | 11:57 |
| Wizzup | yikes apt complains about me modifying /etc/mce/mce.ini, let's see | 11:57 |
| uvos | well did you? | 11:58 |
| uvos | if so thats correct | 11:58 |
| Wizzup | the diff seems to be rtconf-gconf vs rtconf-ini | 11:58 |
| Wizzup | and lock-generic being inserted | 11:58 |
| Wizzup | as opposed to lock-rtlock | 11:58 |
| Wizzup | lock-tklock* | 11:58 |
| Wizzup | that can't be right | 11:58 |
| uvos | all of that is correct | 11:58 |
| uvos | there is a new file | 11:58 |
| uvos | 10-maemo.ini | 11:58 |
| Wizzup | ah I added callstate at the end | 11:59 |
| Wizzup | that's why | 11:59 |
| uvos | DONT EDIT THIS FILE | 11:59 |
| uvos | it says right at the top :P | 11:59 |
| Wizzup | was that also true initially when I made that change with the older mce? | 11:59 |
| Wizzup | ;) | 11:59 |
| uvos | yes if its adding call state :) | 11:59 |
| Wizzup | hm? | 12:00 |
| Wizzup | so what is the right way to add callstate | 12:00 |
| Wizzup | do I need to copy the entire Modules= line from 10-maemo | 12:00 |
| uvos | yeah you have to copy the entire key you want to change | 12:00 |
| Wizzup | that also means I will miss out of newer changes to 10-maemo.conf though | 12:00 |
| Wizzup | since it will override | 12:01 |
| uvos | yes | 12:01 |
| uvos | thats how it goes | 12:01 |
| * Wizzup adds to 10-maemo.conf | 12:01 | |
| uvos | then apt will complain, as long as you let it replace when it dose its fine ofc | 12:01 |
| Wizzup | seems like a better solution to me | 12:01 |
| uvos | sure depends on what you change, im sure the user dosent want the power key bindngs or led colors to change back every upgrade | 12:02 |
| Wizzup | yeah | 12:02 |
| Wizzup | it'll be a less of a problem once things settle | 12:02 |
| uvos | Wizzup: btw the right way to add a moudle is ModulesUser= | 12:04 |
| Wizzup | ok | 12:05 |
| uvos | Wizzup: so ModulesUser=callstate is what you want | 12:05 |
| uvos | then you get updates and apt dosent complain | 12:05 |
| Wizzup | uvos: check | 12:06 |
| Wizzup | parazyd: does this generate postrm and postinst files based on what is in gconf at the time? | 12:06 |
| Wizzup | if so, I don't think that will work | 12:07 |
| parazyd | Not this script exactly, this is just conceptual. But what it would gather the info when the postinst/postrm scripts run | 12:07 |
| Wizzup | it might be better to have a script that checks all the installed libicd-network-* modules, and knows which have what order | 12:07 |
| Wizzup | ah, I see | 12:07 |
| parazyd | So the order is kept as well | 12:07 |
| Wizzup | so what if I install tor and then wg, and vice versa? | 12:08 |
| Wizzup | the order of the modules matters, it is the order in which they are called | 12:08 |
| Wizzup | so ipv4 must always come before tor | 12:08 |
| parazyd | example install: | 12:08 |
| Wizzup | regardless of when it was installed | 12:08 |
| parazyd | [wpasupplicant.so,ipv4.so,tor.so,wg.so] | 12:08 |
| parazyd | example uninstall: | 12:08 |
| parazyd | [wpasup.so,ipv4.so,wg.so] | 12:08 |
| parazyd | These always append | 12:09 |
| Wizzup | what happens if ipv4 is uninstalled and reinstalled? | 12:09 |
| Wizzup | ok, so that can't work | 12:09 |
| parazyd | We aren't using this for ipv4 | 12:09 |
| Wizzup | also technically the key is owned by libicd-network-wpasupplicant | 12:09 |
| parazyd | That comes from the schema | 12:09 |
| parazyd | (ownership) | 12:10 |
| Wizzup | yes | 12:10 |
| parazyd | gconftool doesn't change that afaik | 12:10 |
| Wizzup | I know, it was a fyi | 12:10 |
| Wizzup | the other thing we could do is just add another gconf key | 12:10 |
| Wizzup | network_modules_extra= | 12:10 |
| parazyd | Does that make more sense to you? | 12:12 |
| parazyd | This is really flaky anyway tbh | 12:14 |
| Wizzup | what is 'this' ? | 12:17 |
| uvos | Wizzup: network_modules_extra idea i think i flakey too | 12:18 |
| uvos | Wizzup: so mce solves this problem by assinging every module a priority | 12:18 |
| uvos | see https://github.com/maemo-leste/mce/blob/master/src/modules/rtconf-gconf.c | 12:19 |
| uvos | (well this is not fully implemented, yet) | 12:19 |
| Wizzup | parazyd: any idea why '/etc/init.d/icd2 stop' would say "WARNING: icd2 is already stopped" when it is not? | 12:19 |
| Wizzup | I see this happen a lot and I think it relates to the debian openrc integration or something | 12:19 |
| Wizzup | (this is also why the gpsd service with liblocation and friends seems to be buggy) | 12:19 |
| uvos | idea being that they are loaded unless some other module is allready loaded with same .provides and loaded in priority order | 12:20 |
| Wizzup | uvos: yeah, that could work | 12:20 |
| parazyd | Wizzup: Not sure, seems it's using dsme and not openrc tools | 12:20 |
| Wizzup | huh? | 12:21 |
| Wizzup | I think this warning short circuits dsme | 12:21 |
| Wizzup | this is based on openrc state | 12:21 |
| Wizzup | as in there's nothing to "check" if it is currently running beyond the cached state | 12:22 |
| Wizzup | so it can't be dsme | 12:22 |
| Wizzup | or do you mean the fact that dsme is used to spawn the process confuses openrc sometimes? | 12:22 |
| Wizzup | it might confuse openrc, but I'm pretty sure that that should not affect the cached state | 12:22 |
| Wizzup | often /etc/init.d/icd2 status does work fine | 12:22 |
| parazyd | freemangordon, Wizzup: Revised dh: http://sprunge.us/Z9U955 | 12:23 |
| parazyd | Wizzup: I mean that using dsme could confuse openrc, yes | 12:24 |
| Wizzup | weird, it shouldn't anymore than start-stop-daemon | 12:24 |
| Wizzup | (I've also seen it lose track of gpsd) | 12:25 |
| parazyd | Wizzup: Did you trigger it with something? | 12:25 |
| parazyd | It looks fine in my VM atm | 12:25 |
| Wizzup | yes, it happens over time, I don't know what does it | 12:25 |
| parazyd | aha | 12:25 |
| Wizzup | but the other day I saw gpsd was running when openrc thought it was not | 12:25 |
| parazyd | I'll keep an eye on it then | 12:25 |
| Wizzup | so I had to pkill it | 12:25 |
| Wizzup | installed the tor stuff and now I no longer see any networks listed in my wifi scans, nice :D | 12:27 |
| uvos | heh icd breaking wifi | 12:35 |
| uvos | classic | 12:35 |
| parazyd | https://github.com/maemo-leste/maemo-system-services/blob/master/debian/dh/dh_maemo_installicdnetwork | 12:36 |
| parazyd | Pushed here, I think this is fine | 12:36 |
| parazyd | If you decide to do _extra, then just line 24 can be changed | 12:37 |
| Wizzup | uvos: :D | 12:43 |
| Wizzup | parazyd: ok, we don't have the modules yet, so we can't really test it yet | 12:43 |
| parazyd | I realize | 12:44 |
| Wizzup | https://wizzup.org/tor-d4-1.png | 12:50 |
| Wizzup | https://wizzup.org/tor-d4-2.png | 12:50 |
| Wizzup | https://wizzup.org/tor-d4-3.png | 12:50 |
| Wizzup | https://wizzup.org/tor-d4-4.png | 12:50 |
| Wizzup | the androidap is not from my android ;) | 12:50 |
| Wizzup | + https://wizzup.org/tor-d4-5.png | 12:52 |
| parazyd | Looks awesome :) | 12:53 |
| bencoh | :) | 12:54 |
| Wizzup | will need to push a fix though... don't install it yet | 12:54 |
| bencoh | at least it's only in -devel :> | 12:54 |
| parazyd | hee | 12:55 |
| parazyd | hehe | 12:55 |
| freemangordon | Wizzup: what about translations? | 14:35 |
| freemangordon | like "Providers" etc? | 14:36 |
| parazyd | They exist | 14:36 |
| parazyd | I need to make new ones for the applets though | 14:37 |
| freemangordon | uvos: you should add "Replaces:/Conflicts:" in debian.control | 14:37 |
| * freemangordon checks | 14:37 | |
| uvos | freemangordon: no | 14:37 |
| freemangordon | what is no? | 14:37 |
| uvos | freemangordon: the issue is that mce.install grabs the headers | 14:37 |
| uvos | freemangordon: it should not | 14:37 |
| uvos | freemangordon: only mce-dev.install should | 14:37 |
| uvos | freemangordon: its a trival fix | 14:37 |
| freemangordon | ah, ok | 14:37 |
| uvos | freemangordon: ill do it as soon as i can | 14:37 |
| freemangordon | ok, got it | 14:38 |
| freemangordon | parazyd: hmm, how did you find conn_set_iap_ti_adv_providers? | 14:40 |
| freemangordon | or this is new? | 14:40 |
| Wizzup | freemangordon: I think I added those for all but "TOR" as provider type | 14:50 |
| Wizzup | 3https://github.com/maemo-leste-translations/osso-connectivity-ui-l10n/commit/a5af55556d59d9672d29a3fd1e45e3d6ba0359fb | 14:50 |
| freemangordon | but it should already be dgettext-aware, no? | 14:50 |
| freemangordon | I mean - getting the provider name | 14:51 |
| freemangordon | isn;t it set in gconf as msgid? | 14:51 |
| Wizzup | you can specify gettext catalog in gconf for srv providers | 14:52 |
| freemangordon | mhm | 14:52 |
| Wizzup | 14:40 < freemangordon> parazyd: hmm, how did you find conn_set_iap_ti_adv_providers? | 14:53 |
| Wizzup | it's new | 14:53 |
| Wizzup | just to be clear | 14:53 |
| freemangordon | so, I think tor provider shall provide l10n package, no? | 14:53 |
| freemangordon | (15,40,12) freemangordon: or this is new? | 14:53 |
| freemangordon | :) | 14:53 |
| Wizzup | I think we can use osso-connectivity-ui | 14:53 |
| Wizzup | oh, the tor provider | 14:53 |
| freemangordon | mhm | 14:53 |
| Wizzup | yeah supposedly, but I don't have time to do that right now | 14:53 |
| freemangordon | sure | 14:53 |
| freemangordon | uvos: Wizzup: what about using ptrace by dsmetool? | 14:59 |
| Wizzup | yikes :) | 15:00 |
| uvos | freemangordon: yeah dont like that | 15:01 |
| uvos | whats wrong with pidfd? | 15:01 |
| freemangordon | 5.3 | 15:01 |
| Wizzup | I think either extending dsme protocol or the pidfd thing makes sense | 15:02 |
| uvos | you could use pidfd where the syscal possible and fall back to current behavior when its not | 15:02 |
| Wizzup | ptrace is not made for this usecase | 15:02 |
| freemangordon | Linux devuan 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux | 15:02 |
| Wizzup | e.g. if something else is tracing it won't work | 15:02 |
| uvos | i dont think leste needs to support every old stable kernel | 15:02 |
| freemangordon | this is devuan we use | 15:02 |
| freemangordon | VM | 15:02 |
| uvos | and fallback to current behavior is ok for testing cases | 15:02 |
| freemangordon | I'd rather have something that works, /proc file polling does, no? | 15:03 |
| uvos | sure | 15:03 |
| uvos | or you can add pidfd with ptrace as a fallback with a big fat REMOVE THIS ASAP | 15:03 |
| freemangordon | isn;t pidfd with /proc polling better? or there is a race with proc polling? | 15:05 |
| Wizzup | why not have dsme report child death over its socket | 15:10 |
| Wizzup | it already waits() anyway | 15:10 |
| Wizzup | maybe it's too complicated, just wondering | 15:11 |
| freemangordon | Wizzup: what about https://bewareofgeek.livejournal.com/2945.html ? | 15:11 |
| freemangordon | PROC_EVENT_EXIT | 15:12 |
| freemangordon | It looks like the best option, if it works | 15:12 |
| Wizzup | >The major problem with this netlink interface and proc events still - the kernel returns 1 event at a time, no matter how big buffer your supply is (What's the reason for that?). So you can really easy get overruns with ENOBUFS from the kernel under heavy load. This means you should be carefull with adding some additional work, especially io, to the netlink listener thread. (the example below ignores | 15:13 |
| freemangordon | uvos: ^^^? | 15:13 |
| Wizzup | that rule for simplicity reason) | 15:13 |
| Wizzup | doesn't sound ideal | 15:13 |
| freemangordon | sure, but is portable | 15:14 |
| Wizzup | dsmeutil can get stuck if I read this correctly | 15:14 |
| Wizzup | I'd rather poll for the pid in /proc honestly | 15:15 |
| freemangordon | but it is racy IIUC | 15:15 |
| Wizzup | + combine it with /proc lifetime | 15:15 |
| Wizzup | afaik you can see when a process was started | 15:15 |
| uvos | we will have lots of instances wating for processes to exit during shutdown/ runlevel changes | 15:18 |
| uvos | i dont think having them all use netlink for it is a good idea | 15:19 |
| freemangordon | ok, so something like: | 15:19 |
| freemangordon | 1. get and store mce process start time (/proc/$pid/stat) | 15:19 |
| freemangordon | 2. kill mce | 15:19 |
| freemangordon | 3. wait until either there is no /proc/$pid/stat or starttime in it changes | 15:19 |
| freemangordon | mce being an example here | 15:19 |
| freemangordon | should do the job, no? | 15:19 |
| Wizzup | yes, that's what I meant with start time | 15:20 |
| uvos | yeah that would work | 15:20 |
| freemangordon | I guess I can poll on /proc/$pid/stat, right? | 15:20 |
| uvos | i would ofc prefer pidfd where its avail. | 15:20 |
| uvos | since then you dont have to poll | 15:20 |
| freemangordon | the problem with pidfd is that I cannot test in the VM | 15:20 |
| uvos | just upgrade the kernel | 15:21 |
| freemangordon | in the VM? | 15:21 |
| uvos | that should be trival in vm no | 15:21 |
| uvos | sure | 15:21 |
| uvos | we could also just do it generaly for vm | 15:21 |
| Wizzup | doesn't it also require specific kernel config options? | 15:21 |
| freemangordon | but then this is no longer leste VM | 15:21 |
| uvos | freemangordon: so its just for you to test | 15:21 |
| uvos | and we maintian kernels for every other target anyhow we could also have a kernal package for vm thats a newer one | 15:22 |
| freemangordon | I'd rather KISS for now and implement the fallback path only | 15:22 |
| uvos | Wizzup: so? you can use localconfig | 15:22 |
| Wizzup | uvos: not making a point other than that we would have to remember to turn it on in various places | 15:22 |
| uvos | Wizzup: turn on what? | 15:22 |
| freemangordon | the config option | 15:23 |
| uvos | the options? | 15:23 |
| uvos | ok | 15:23 |
| uvos | i dont see why upgrading the kernel in vm for fmgs development vm only is a big deal but suit yourself | 15:23 |
| freemangordon | I can do once I have fallback path working | 15:24 |
| freemangordon | I can easily make a snapshot in virualbox | 15:24 |
| uvos | or just test it on d4 dsme compiles plenty fast on it | 15:25 |
| freemangordon | it is way harder to debug ther | 15:26 |
| freemangordon | I can easily setup remote debug using QtCreator in ubuntu to the VM, with source code and everything | 15:26 |
| uvos | not sure how its different than to a remote d4, but no matter, do what works best for you. | 15:27 |
| freemangordon | and with broken USB networking on d4, it will be extremely slow through wifi | 15:27 |
| freemangordon | unless USB networking is fixed lately | 15:28 |
| uvos | i think it works fine | 15:28 |
| uvos | (but i dont use it) | 15:28 |
| uvos | Wizzup: ^^^ | 15:28 |
| freemangordon | but yeah, I prefer developing in the VM | 15:28 |
| Wizzup | it works fine unless the battery is full, then it keeps dropping every couple seconds I think | 15:28 |
| freemangordon | yeah, this | 15:28 |
| uvos | hmm ok | 15:28 |
| uvos | just rmmod cpacp_battery then | 15:28 |
| freemangordon | VM then ;) | 15:28 |
| freemangordon | I really prefer to no lose fucus rmmoding and whatnot | 15:29 |
| freemangordon | *not | 15:29 |
| freemangordon | anyway | 15:29 |
| Wizzup | let's just start with the fallback and see if all problems are gone | 15:29 |
| freemangordon | mhm | 15:31 |
| freemangordon | uvos: Wizzup: why do you think dsmetool is at fault? it sends a message to dsme and then waits | 15:48 |
| freemangordon | I would say this https://github.com/maemo-leste/dsme/blob/master/modules/lifeguard.c#L780 is the problem | 15:51 |
| freemangordon | it does kill() but no waitpid() | 15:51 |
| Wizzup | yes, but it can't just waitpid since that will block dsme | 15:51 |
| Wizzup | it needs to eventually wait for the pid and report it | 15:51 |
| Wizzup | uvos: btw, iirc we reverted the font text change you had, but now my calendar is not usable anymore because of the text colour hehe | 15:52 |
| freemangordon | well, ok, waitpid will obviously block, but I guess we can do that async | 15:52 |
| Wizzup | yes, that's what I've been trying to suggest as alternative | 15:53 |
| freemangordon | this is not an alternative, but the solution IIUC :) | 15:53 |
| Wizzup | let's see :p | 15:53 |
| uvos | freemangordon: was the observed behavior of soemthing like /usr/sbin/dsmetool -k "/usr/bin/mce --verbose --verbose"; /usr/sbin/dsmetool -n -1 -t "/usr/bin/mce --verbose --verbose" | 15:53 |
| uvos | this starts mce before it exits | 15:53 |
| freemangordon | uvos: sure, but dsmetool relies on dsme to kill the process | 15:54 |
| freemangordon | and dsmetool receives reply right after kill() | 15:54 |
| uvos | rigt and dsmetool dosent wait untill it dose | 15:54 |
| uvos | right thats wrong | 15:54 |
| freemangordon | no, dsmetool shall not wait, it is dsme that shall wait | 15:54 |
| Wizzup | as long as it does it async, yeah. | 15:55 |
| freemangordon | actually dsmetool aready waits | 15:55 |
| uvos | well dsmetool needs to wait untill the process exits | 15:55 |
| freemangordon | no, dsme shall wait :p | 15:55 |
| Wizzup | uvos: not if dsme waits | 15:55 |
| uvos | how its implmented is irrelivant | 15:55 |
| Wizzup | uvos: the problem is essentially that dsme reports 'ok' too early | 15:55 |
| freemangordon | uvos: dsmetool sends a message and blocks for a reply | 15:55 |
| uvos | right how dmsetool waiting is implmented is releviant | 15:55 |
| uvos | it dosent work atm | 15:55 |
| uvos | and needs to be fixed :) | 15:55 |
| uvos | *is not relevant | 15:55 |
| freemangordon | dsme replies too early, so it is dsme to be fixed, noy dsmetool | 15:56 |
| freemangordon | *not | 15:56 |
| uvos | ok i hear you | 15:56 |
| freemangordon | good :) | 15:56 |
| freemangordon | I will fix that | 15:56 |
| freemangordon | well, at least will try | 15:56 |
| uvos | Wizzup: you have to fix the qt themes to corrispond to https://doc.qt.io/qt-5/qpalette.html | 15:57 |
| uvos | Wizzup: and then the maemo apps end up broken all over the place because they violate the QPalette::WindowText QPalette::Base deistinction | 15:58 |
| uvos | Wizzup: part of this is violations in the hildonized widgets | 15:58 |
| uvos | and part of it is the apps using the colors wrong | 15:58 |
| uvos | you have to fix it to be to sepc | 15:58 |
| uvos | ie QPalette::Base needs to be used with QPalette::Text and QPalette::Window with QPalette::WindowText | 15:59 |
| uvos | maemo apps do this wrong all over the place | 16:00 |
| uvos | there is no other possible "fix" for this | 16:00 |
| freemangordon | Wizzup: can;t I just fork() and waitpid() there? | 16:07 |
| uvos | dsme uses a unix soccet to comunicate with tool right? | 16:07 |
| freemangordon | yes | 16:07 |
| uvos | then sure i dont see why not | 16:08 |
| freemangordon | mhm | 16:08 |
| uvos | wait no you wont be the processes parent | 16:08 |
| freemangordon | well, will do the /proc hack then | 16:08 |
| freemangordon | in dsme thread | 16:08 |
| uvos | you could spinn up a pthread instead | 16:08 |
| freemangordon | mhm | 16:08 |
| uvos | and waitpid there | 16:09 |
| freemangordon | or GThread | 16:09 |
| uvos | sure | 16:09 |
| freemangordon | yes | 16:09 |
| uvos | ttyl | 16:09 |
| freemangordon | hmm, we already have announce_child_exit() | 16:39 |
| freemangordon | no need of any trickery | 16:39 |
| mighty17[m] | why is powervr crashing a lot on pmOS, i hv been using openpvrsgx 5.12 and blobs are in pmOS repos | 18:29 |
| mighty17[m] | `[ 193.428192] PVR_K:(Error): SGXOSTimer() detected SGX lockup (0xbc tasks)` | 18:29 |
| mighty17[m] | `[ 193.428192] PVR_K: HWRecoveryResetSGX: SGX Hardware Recovery triggered` | 18:29 |
| uvos | mce problem should be fixed | 18:59 |
| uvos | (as soon as the build finishes) | 18:59 |
| mighty17[m] | also, why is CONFIG_BLK_DEV_RAM_SIZE=16384 set to 16384, instead of the default 4096 | 19:24 |
| Wizzup | uvos: great | 19:29 |
| * freemangordon tests dsme process exit fix | 19:42 | |
| kona | Uvos: will try trojita again with x backend vkb, I'm still just learning all the current quirks. :) | 20:06 |
| sicelo | kona: no, i've never installed trojita. | 20:08 |
| kona | I think I remembered wrong, sorry :) | 20:08 |
| freemangordon | Setting up mce (1.9.1+2m7) ... | 20:11 |
| freemangordon | * Caching service dependencies ... [ ok ] | 20:11 |
| freemangordon | * Stopping mce [ !! ] | 20:11 |
| freemangordon | * Starting mce .. | 20:11 |
| freemangordon | :) | 20:11 |
| freemangordon | Wizzup: uvos: https://github.com/maemo-leste/dsme/commit/d866deb122101cffec00620947843fea1396568f | 20:34 |
| freemangordon | one note - I am not sure if I shall check for the signal, if it is not SIGKILL, the process will not actually exit | 20:34 |
| freemangordon | what do you think? | 20:34 |
| uvos | freemangordon: why would the process not exit on things other than sigkill? | 22:48 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-desktop/pull/14 (add support for rotating xinput touchscreens when entering or leaving portrait mode) | 23:07 |
| uvos | freemangordon: ^^^ | 23:08 |
| lel | IMbackK synchronize a pull request: https://github.com/maemo-leste/hildon-desktop/pull/14 (add support for rotating xinput touchscreens when entering or leaving portrait mode) | 23:10 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
