| uvos | hmm so something about installing the hildon meta package breaks tinydm (and also lightdms) ability to spawn xorg as user | 00:10 |
|---|---|---|
| uvos | (and also it breaks dbus, but thats expected conisering what af-services dose) | 00:11 |
| Wizzup | uvos: our x pkg has elogind disabled, maybe this is the problem | 00:12 |
| uvos | ah yes probubly | 00:13 |
| Wizzup | uvos: and our old hildon-meta (but not current) would I think conflict with elogind | 00:13 |
| uvos | its current | 00:13 |
| uvos | elogind is there | 00:13 |
| uvos | but the new x package very likely breaks it | 00:13 |
| uvos | why must we disable elogind? | 00:14 |
| Wizzup | uvos: I think it has adverse effects if you don't have elogind | 00:15 |
| uvos | ok | 00:15 |
| uvos | is there a good way ensure a package from a repo is ignored? | 00:16 |
| uvos | ie that update dosent install xorg from madevu | 00:16 |
| uvos | *upgrade | 00:16 |
| Wizzup | I think you can just install it by veresion | 00:16 |
| Wizzup | version | 00:17 |
| Wizzup | are you testing this in a vm or d4? | 00:17 |
| uvos | vm | 00:17 |
| uvos | d4 is different problem | 00:17 |
| Wizzup | it might be easier to just revert952c00ba0dcbb57c03e8ec0693850d0c02aa43ec and rebuild xorg-server then | 00:18 |
| Wizzup | it only takes a few mins | 00:18 |
| Wizzup | but if you search for 'apt install specific version' I am sure it will tell you | 00:18 |
| Wizzup | also I think apt-get install -t <repo name for devuan/debian> might work somehow | 00:18 |
| Wizzup | not sure how it works exactly, but I know you can pin by version for sure, | 00:18 |
| Wizzup | + ssh amprolla@maedevu.maemo.org -- mkdir -p images/droid4/20221213 | 01:37 |
| Wizzup | Host key verification failed. | 01:37 |
| Wizzup | + exit 1 | 01:37 |
| Wizzup | argh | 01:37 |
| Wizzup | well that's over 2 hours of waiting down the drain :p | 01:43 |
| Wizzup | tomorrow then | 01:43 |
| Wizzup | chimaera xz images are ~150MB larger | 11:45 |
| Wizzup | wonder what changed | 11:45 |
| buZz | maybe compare a du -sh /* ? | 12:00 |
| buZz | Wizzup: btw yay, celebrations | 12:01 |
| * buZz has internet at home again | 12:01 | |
| buZz | took almost -exactly- a full month | 12:01 |
| Wizzup | buZz: great | 12:04 |
| sicelo | may i ask - what will go wrong if the evdev/proximity interface for mce is restored, while keeping the iio/proximity interface, i.e. allow them to co-exist? | 12:23 |
| Wizzup | sicelo: agree it could be useful to keep around | 12:26 |
| buZz | ooo MCE can do proximity? nice | 12:27 |
| buZz | i was thinking the tklock might benefit from proximity reading, aka 'dont unlock if slide opens but proximity is VERY CLOSE' to prevent pocket-leste'ing | 12:28 |
| Wizzup | uvos: d4 chimaera images boot to 3g and everything, the only thing missing atm is HAM, which needs one code change and then it can work | 12:29 |
| Wizzup | and of course the 'extras' pkgs | 12:29 |
| Wizzup | I got an sms from the operator in sphone | 12:29 |
| Wizzup | tmlind: freemangordon: got this just now on my lab droid - linux 6.1: https://dpaste.com/EV5CNE6BW.txt - could be related to uvos toying with screens for razr maybe | 13:48 |
| norayr | interesting what from my extras packages won't build under chimaera. | 13:55 |
| norayr | can i already test those in phoenix? | 13:55 |
| Wizzup | norayr: are you using the vm image to build them? | 13:56 |
| Wizzup | norayr: and yes, you can :) | 13:56 |
| norayr | usually i develop richt on device, but i have wm with bullseye and maemo | 13:56 |
| norayr | is there a vm image already for chimaera? | 13:57 |
| Wizzup | uvos: something happened to my d4 where mce didn't re-enable the touchscreen, I had to go in with serial and type 'xinput enable 7' | 13:57 |
| Wizzup | (which is Filtered Touchscreen) | 13:57 |
| norayr | i'll hest in phoenix first, and then if it won't build will use a vm | 13:57 |
| norayr | anyone tried to build omweather? i remember i had troubles and didn't manage to solve those. | 13:58 |
| Wizzup | norayr: ok, there is a vm image already built that should work fyi | 13:58 |
| Wizzup | there is also a d4 image now | 13:59 |
| Wizzup | https://maedevu.maemo.org/images/virtual-machines/20221213-chimaera/ | 13:59 |
| Wizzup | https://maedevu.maemo.org/images/droid4/20221214-chimaera/ | 13:59 |
| Wizzup | it might save you a lot of time if you test on those, but feel free to use the ci | 13:59 |
| norayr | thank you! | 14:00 |
| Wizzup | the branch is 'maemo/chimaera' as you'd expect | 14:00 |
| Wizzup | norayr: got a link to omweather? | 14:01 |
| Wizzup | uvos: does gps work for you? | 14:13 |
| Wizzup | uvos: on 6,1? | 14:13 |
| Wizzup | it does not work for me on beowulf-devel or chimaera I think, I'll leave my phones outside a bit longer | 14:13 |
| Wizzup | freemangordon: btw, let me know when you want to discuss experimental and such setup for chimaera, we're ready now I think | 14:14 |
| uvos | Wizzup: @input this can happen if mce exits abnormaly or is killed for any reason | 14:30 |
| uvos | mce disables xinput devices while the display is off, but if it crashes or is killed it has no way of knowing which devices it disabled and which are disabled by xorg due to user config or xorg heuristics | 14:31 |
| uvos | so it cant renable them when it comes back | 14:32 |
| Wizzup | uvos: maybe the kernel trace is related to this then, but mce should be restarted in this case, and maybe it needs to re-enable the ts or something | 14:32 |
| Wizzup | hmm? | 14:32 |
| uvos | restarting dose not help | 14:32 |
| uvos | see above | 14:32 |
| Wizzup | I don't think user config is really a problem is it? | 14:32 |
| uvos | yes it explictly is a problem on mapphones | 14:32 |
| Wizzup | I think it's entirely fine for mce to 'take over' when it starts up | 14:32 |
| Wizzup | why? | 14:32 |
| uvos | they have a device that is disabled by xorg | 14:33 |
| uvos | (the normal touchscreen) | 14:33 |
| uvos | mce has no way of knowing which xinput devices are the ones it disabled and wich one is the one disabled by config (as required on mapphones) | 14:33 |
| uvos | same thing is true of the pocophone iirc | 14:33 |
| uvos | mce cant just "take over" all input devices | 14:34 |
| uvos | anyhow this is only a problem if mce crashes or is killed by signal 9 | 14:34 |
| uvos | otherwise it just releases the input devices on exit | 14:34 |
| uvos | same problem exits on n900 to iirc | 14:35 |
| uvos | since xorg ignores the accelerometer | 14:35 |
| uvos | as this is also a evdev device | 14:35 |
| uvos | the real solution to this problem is to use replace mces input handeling with libinput | 14:36 |
| uvos | since it then shares heuristics with xorg and can use that to tell wich xinput device belongs to what | 14:36 |
| uvos | and wich are disabled by the user/config | 14:36 |
| uvos | theres also several other reasons to do this, as i have discribed at other times | 14:37 |
| Wizzup | but what happens here is that the device is basically locking out the user | 14:41 |
| Wizzup | hmm | 14:41 |
| Wizzup | I am not sure if mce crashed, but I can try to check the logs | 14:41 |
| Wizzup | btw, gps works now. | 14:42 |
| Wizzup | I was just impatient it seems | 14:42 |
| Wizzup | arg, keyboard is still disabled | 14:42 |
| Wizzup | lol | 14:42 |
| uvos | Wizzup: yes its not great, mce generaly never crashes so its not been a problem yet but yes. | 14:48 |
| Wizzup | well, mce is able to crash since dsme restarts it, so we might want to see if we can rescue it somehow | 14:51 |
| Wizzup | you're saying that libinput has the same logic as x when deciding what to enable/disable? does it read udev rules? | 14:51 |
| uvos | yes so xorg asks libinput what do disable | 14:51 |
| uvos | so if mce where to be able to check with libinput on start it would know wich devices are disabled by config | 14:51 |
| uvos | and then it can assume the mce instance that died disabled all others | 14:52 |
| uvos | anyhow mces input handing is full of holes and needs to be replaced with libinput anyhow | 14:53 |
| Wizzup | mm | 15:11 |
| Wizzup | uvos: looks like my mc got SIBABRT | 15:30 |
| Wizzup | Dec 14 12:13:44 localhost DSME: Process '/usr/bin/mce --force-syslog' with pid 2526 exited with signal 6 and restarted with pid 5692 | 15:30 |
| Wizzup | that is right around: | 15:31 |
| Wizzup | Dec 14 12:13:01 localhost kernel: [ 2916.577270] omapdrm omapdrm.0: atomic complete timeout (pipe 0)! | 15:31 |
| Wizzup | well a bit later | 15:31 |
| Wizzup | Dec 14 12:13:44 localhost systemui[3235]: Method call received from: :1.64, iface: com.nokia.system_ui.request, method: powerkeymenu_close | 15:31 |
| Wizzup | Dec 14 12:13:46 localhost systemui[3235]: Method call received from: :1.64, iface: com.nokia.system_ui.request, method: tklock_close | 15:31 |
| uvos | thats systemui, where is mces log? | 15:33 |
| uvos | if it aborted it presumably failed an assert | 15:34 |
| Wizzup | uvos: this is a fresh chimaera image, so I don't think I have any errors from mce logged | 15:36 |
| Wizzup | Dec 14 12:12:18 localhost mce[2526]: tklock.c: disable_eveater: eveater disabled | 15:36 |
| Wizzup | Dec 14 12:13:44 localhost mce[5692]: mce-conf: Could not get config key PowerKey/KeyCode | 15:36 |
| Wizzup | this is the only msg before/after the restart | 15:36 |
| Wizzup | uvos: btw I know it's systemui, but it interacts with mce, which is why I posted it | 15:37 |
| Wizzup | (note that for the two mce lines there are different pids) | 15:37 |
| Wizzup | uvos: btw looks like we're almost done with chimaera :) | 15:41 |
| uvos | well not the session stuff | 15:42 |
| uvos | thats a lot of work untangeling the mess of how the current session is created | 15:42 |
| uvos | since that happens in a lot of places | 15:42 |
| uvos | any bit of it running breaks all other session | 15:42 |
| uvos | s | 15:42 |
| Wizzup | right, but it's basically the same situation as on beowulf, where elogind also existed | 15:43 |
| Wizzup | uvos: why is the untangling necessary btw? | 15:43 |
| uvos | there are alot of assumptions made when stuff starts in relation to eatch other | 15:44 |
| uvos | init scripts spawing processes that need processes in the the session that need processes spawned by init scripts | 15:44 |
| uvos | the init scripts themselves have lots of dependancies that end up starting xorg or xsession via various depends paths | 15:45 |
| uvos | etc | 15:45 |
| Wizzup | right, but how does this matter to the elogind, can't it just start the stuff the same way? | 15:45 |
| Wizzup | or is it a non-technical reason that you want to untangle it, into actual login sessions | 15:45 |
| uvos | well untangeling the depens is absoulty nessecary | 15:46 |
| uvos | otherwise the old system will start x | 15:46 |
| uvos | and the way the starting order works is increably fragile | 15:47 |
| uvos | and tends to break if you change anything | 15:47 |
| uvos | ie change how the session is started | 15:47 |
| uvos | theres stuff like sleep 2 | 15:48 |
| uvos | (and hope the other process is started now) | 15:48 |
| Wizzup | so I thought you could replace /etc/init.d/xorg and /etc/init.d/xsession with tinydm | 15:49 |
| uvos | you can but you need to update the depends and it breaks the sleep asumptions because timeing | 15:49 |
| Wizzup | assuming that would start X and then just execute the scripts that xxession does | 15:49 |
| Wizzup | hm, the timing really breaks? that's odd | 15:49 |
| uvos | also the current setup starts x | 15:49 |
| uvos | dose stuff | 15:49 |
| uvos | then starts xsession | 15:50 |
| uvos | this is not possible | 15:50 |
| Wizzup | ok | 15:50 |
| Wizzup | uvos: do you think we ought to wait with the chimaera release for the elogind parts? | 15:54 |
| Wizzup | I was hoping we could have it done before christmas, but it's not -required- of course | 15:55 |
| Wizzup | we could also have people upgrade their way through this, I suppose | 15:55 |
| uvos | well replaceing the session stuff and haveing it work without reintall is going to be fairly painful/error prone probubly | 15:55 |
| Wizzup | if we release it without elogind, I suppose people would at least be able to dist-upgrade | 15:56 |
| Wizzup | I think it would be good if we can make it work btw, dist-upgrade, but I agree it'll be tricky | 15:56 |
| uvos | i mean repalceing the session stuff can work ok via upgrade | 15:56 |
| uvos | its just very likely it will break on manny installs for unforsen reasons | 15:57 |
| uvos | theres also the other unkown issues still | 15:58 |
| Wizzup | I think maybe what is best is to re-add the conflict on elogind to hildon-meta for chimaera now, and then in whatever we call the new chimaera experimental, toy around with tinydm there | 15:59 |
| Wizzup | and then from there we can also work on a dist-upgrade path for it | 15:59 |
| uvos | not sure what the conflict helps at all really | 15:59 |
| uvos | its not like its preinstalled | 15:59 |
| Wizzup | it prevents packages pulling it in, which many do | 15:59 |
| uvos | not really | 15:59 |
| Wizzup | try to install anything mafw | 15:59 |
| uvos | apt just drops the metapackage | 15:59 |
| Wizzup | it will pull in elogind and break the device | 15:59 |
| Wizzup | no, it won't | 16:00 |
| Wizzup | hildon-meta is marked 'essential | 16:00 |
| Wizzup | ' | 16:00 |
| uvos | ok that new | 16:00 |
| Wizzup | so you'll have to type something like 'YES I AM REALLY SURE' | 16:00 |
| uvos | i allways end up with it being removed on beowulfd | 16:00 |
| uvos | by mostly silently apt | 16:00 |
| Wizzup | not since the new ddx driver I think | 16:00 |
| uvos | *by | 16:00 |
| uvos | ok | 16:00 |
| uvos | imo chimaera "stable first" was a mistake and it shows here | 16:01 |
| Wizzup | hm? | 16:01 |
| Wizzup | what do you mean? | 16:03 |
| Wizzup | we'd have to support a dist-upgrade no matter what, no? | 16:10 |
| uvos | Wizzup: no i mean you want to revert the change thats a step in the session direction because the chimaera image must continue to work for users now because its stable and no devel equivalent for chimaera exists | 17:15 |
| uvos | same thing with xorg and patching away logind support | 17:16 |
| uvos | there not being a nonstable eqivalent for chimaera means i have no where to put incremental changes that facilitate the session stuff comeing together | 17:17 |
| uvos | at maybe the expense of stuff being more break happty | 17:17 |
| Wizzup | uvos: we don't want to build new packages for beowulf, right? since we're moving to chimaera? | 17:35 |
| Wizzup | the porting to chimaera was never aimed to get to elogind sessions, that was just half forced upon us | 17:36 |
| Wizzup | so I don't think I agree it has to happen in lock step with the migration to newer debian | 17:36 |
| Wizzup | sure it would be a nice, but I think we'll hold ourselves back if just stay a in-between beowulf and chimaera limbo until we get it resolved | 17:36 |
| uvos | Wizzup: ok | 17:55 |
| freemangordon | uvos: BTW, as you think dsme should be removed, what is the replacement? | 18:27 |
| freemangordon | who is going to reboot the device in case h-d fails to restart in case of a crash (for example)? | 18:28 |
| tmlind | jus fyi, i got the mz617 lp8550 mostly figured out, driver need changes. will look at the bridge driver again, seeing just dsi errors for now | 18:39 |
| uvos | freemangordon: so systemd can do that, faling this im not opposed to dsme in pricipal it just needs to be cut back to manage only processes inside the same session it is also in, otherwise its pretty broken | 19:08 |
| uvos | also the restarting behavior of dsme is totaly broken | 19:09 |
| uvos | the most common cause of a deamon failing to restart more than n-times is some update brekaing it | 19:09 |
| uvos | or a user config change that exposes a bug | 19:09 |
| uvos | in these cases dsmes reboot behvior will break the install essentally forceing the user to reinstall | 19:10 |
| uvos | because it will go into a forever bootloop | 19:10 |
| uvos | same thing if a deamon fails to start during an update | 19:10 |
| uvos | i also dissent that rebooting is usefull behavior at all, except in the case of the kernel (where a reboot IS a restart) | 19:11 |
| uvos | if maemo bits stop working permanently a session restart should be executed instead | 19:11 |
| uvos | ofc the current setup makes restarting the session cleanly impossible | 19:12 |
| uvos | also the session restart shal be exectued only once | 19:12 |
| uvos | to avoid the whole endless session restart thing that might otherwise happen | 19:12 |
| freemangordon | why restart session instead of device? | 19:12 |
| uvos | no possible failure mode besides kernel failures cant be resolved by restarting the deamons and the session | 19:13 |
| freemangordon | ok, but you want one more layer of complexity to be introduced without real gain | 19:14 |
| uvos | no | 19:14 |
| freemangordon | few saved seconds is not really a gain | 19:14 |
| uvos | the thing is with xdg sessions this happens automaticly | 19:15 |
| uvos | dsme must only exit | 19:15 |
| uvos | the session manager restarts the session | 19:15 |
| freemangordon | dsme must run as root | 19:15 |
| uvos | dsme should not run as root | 19:15 |
| freemangordon | and session shall tell dsme about session lifecycle | 19:15 |
| uvos | it should mange session processies only | 19:15 |
| uvos | the init system should do the system proccesies | 19:15 |
| uvos | this is the cause of manny a headache | 19:15 |
| freemangordon | no, because dsme takes care for WDs as well | 19:15 |
| freemangordon | and few other things | 19:16 |
| freemangordon | dsme stands for DeviceStateManagementEntity | 19:16 |
| freemangordon | this is not session state | 19:16 |
| freemangordon | so, you want to introduce systemd? | 19:16 |
| uvos | its a terrible alomoration of things this is true | 19:16 |
| uvos | the point is it shal not mange system processies, and shal leave that to the init system | 19:17 |
| uvos | and the bit that manges session processies must reside inside the session in question | 19:17 |
| uvos | and then whatever is left can reside somewhere elsse | 19:17 |
| freemangordon | so my initial question stands - what will replace dsme functionality | 19:17 |
| uvos | as i say inside the session this is the session managers resposability | 19:18 |
| uvos | ie autologin in this case | 19:18 |
| uvos | outside its init | 19:18 |
| freemangordon | and who reboots the device if a critical session process cannot be restarted? | 19:19 |
| freemangordon | n times | 19:19 |
| uvos | no one | 19:20 |
| uvos | the session is restarted instead | 19:20 |
| uvos | and the deamons are if needed | 19:20 |
| uvos | this covers all failure modes outside the kenrel | 19:20 |
| uvos | kernel restarts iself by building it with fatal oopses | 19:20 |
| uvos | the session is restarted by autologin on the signal of dsme exiting | 19:21 |
| uvos | this is how all other linux desktops work | 19:21 |
| uvos | and for good reason | 19:21 |
| freemangordon | this is *not* linux desktop, but anyway, I have to run now | 19:22 |
| uvos | this is falsely axiomatic | 19:22 |
| uvos | nothing about this happening to run on a phone changes anything here | 19:23 |
| Wizzup | tmlind: great news :) | 19:39 |
| Wizzup | uvos: in any case, it sounds like you're ok with cutting over to chimaera with the expectation that we will still split out the sessions in a future dist-upgrade? | 20:25 |
| uvos | Wizzup: sure | 21:10 |
| uvos | can we haz devel/expiramental branch right after? :) | 21:10 |
| Wizzup | yeah, I'm waiting for fmg to share with preferred names for it | 21:10 |
| tmlind | heh so the stock kernel uses dsi commands only for the bridge, it has gpio_46 usage inverted.. it need to be low to read tc358765 bridge regs with i2ctransfer when the lcd is enabled | 21:59 |
| Wizzup | good sleuthing | 22:02 |
| tmlind | i think gpio_46 only affects the i2c control | 22:04 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!