| *** kimmoli_ is now known as kimmoli | 03:45 | |
| piggz | lbt: ping | 09:04 |
|---|---|---|
| lbt | pong | 09:05 |
| piggz | lbt: so, we were discussing yesterday about adding python-gbinder to chum: .... mal thought it would work becuase libgbinder is now shipped in 4.2, but in an adaptati repo ... but it appears that package is not in the build system ob obs for 4.2 .... | 09:06 |
| piggz | any thoughts? | 09:06 |
| piggz | rinigus: ^^ | 09:06 |
| lbt | so... | 09:16 |
| lbt | sec... | 09:20 |
| lbt | so that package is part of sfos but isn't in the repos that get setup to build against | 09:23 |
| lbt | the source is available of course so one option is to build it yourselves in chum | 09:24 |
| lbt | however that presents 2 issues: one is that the version is different for each OS release and since CHUM is structured as it is that will be tricky | 09:25 |
| lbt | right now we think the ABI hasn't changed so it might work for all versions | 09:25 |
| lbt | the second issue is that you really don't want to be publishing a core rpm that could be seen as "newer" by devices | 09:26 |
| lbt | that would be bad | 09:26 |
| lbt | you probably can't sanely repackage the code to just build a -devel either | 09:26 |
| lbt | so one workaround for that is to create a chum-support project with things that you want to use to build but don't want to publish | 09:27 |
| lbt | (I could see other dev-time only tools in there too - like documentation generators) | 09:28 |
| lbt | that repo would be a <path> repo for the main chum project | 09:28 |
| lbt | I think that would solve the 'dangerous' publishing issue but you may hit a mult-version problem | 09:29 |
| lbt | HTH | 09:29 |
| piggz | hmmmm | 09:33 |
| piggz | we already considered the risk of having mismatched versions, and we want to avoid that | 09:34 |
| piggz | lbt: we could add hw:common as a path on chum, as that also has libgbinder, and would do a similar job as chum-support .... not sure if there are any downsides to that though | 09:44 |
| abr | would be easier with these: https://build.sailfishos.org/project/subprojects/sailfishos:chum | 09:45 |
| abr | then you could do it differently for older versions, or even not build it at all for those | 09:45 |
| lbt | yes - I didn't know it was already present in a project | 09:45 |
| abr | i did try to search for it, but search seems broken atm | 09:46 |
| piggz | we arent interested in supporting older than 4.2 for these pacakges anyway | 09:46 |
| piggz | abr: we already can disable on certain projects .. its just in the repo config | 09:47 |
| lbt | hmmm | 09:48 |
| lbt | you could have hw:common:4.1 and hw:common:4.2 in the future | 09:48 |
| lbt | umm 4.3 | 09:48 |
| lbt | so actually that would allow different gbinder versions from different 'support' projects | 09:49 |
| piggz | lbt: so, whats the recommendation? | 09:54 |
| lbt | So the goal here is to provide packages that supplement the core OS and should not be published | 10:01 |
| lbt | I think you'll need this to be SFOS version specific | 10:02 |
| lbt | the hw:common is volatile and out of chum control - IMHO you should not use that. Make a dedicated chum:support:4.2.0.48 that builds against 4.2 and snapshot gbinder and dependencies into there then add that as a path for chum's 4.2 repo | 10:06 |
| lbt | that is then "frozen" | 10:06 |
| lbt | that will need redoing every release | 10:07 |
| rinigus | lbt: as far as I understood from last night discussion, libgbinder is in the new adaptation repo which we get on devices. but that one is not backed up by OBS, same way some other core packages are | 10:07 |
| lbt | right | 10:07 |
| rinigus | so, question is, why not to add it as well as the one of those upstream repos? in the definition of 4.2.0.24 target | 10:08 |
| rinigus | (if I use the terms correctly) | 10:08 |
| rinigus | alternative for this particular package (gbinder-python) is to add it to hw:common and use through that. but that would help ported devices only | 10:10 |
| rinigus | as for having extra sfos:chum:support:a.b.c.d - that would be relatively painful. as you said, would need to start matching gbinder versions and maintain it | 10:11 |
| lbt | you're going to need to do that anyway | 10:11 |
| lbt | it's possible that hw:common should be in the snapshot we install onto OBS at release time | 10:12 |
| lbt | as it's not device specific | 10:12 |
| rinigus | the bindings are not device specific either - so it does match well. | 10:13 |
| rinigus | python bindings | 10:13 |
| rinigus | as for common, it is "frozen" for older releases. so, gbinder should be of correct version for each SFOS version | 10:13 |
| lbt | where? | 10:16 |
| piggz | lbt: https://build.merproject.org/project/show/nemo:testing:hw:common | 10:19 |
| lbt | oooh that's dodgy... | 10:22 |
| lbt | but yes, it will probably work | 10:23 |
| piggz | lol, wdym dodgy :D | 10:23 |
| lbt | those repos are unrecoverable if they accidntally get re-enabled | 10:24 |
| piggz | well, we leave mal in charge of them7 | 10:24 |
| piggz | rinigus: what do u think? we discounted adding that as a path to chum previously so we didnt conflict any official device package but i dont think that will happen as we arnt adding that repo to the use device | 10:28 |
| piggz | its just a build path | 10:28 |
| rinigus | lbt: that's the way we have all ports moving between versions. but it is dodgy in the respect of being unable to recover, indeed | 10:31 |
| piggz | though, im not sure we can specify the repo as the version for each version of chu | 10:31 |
| piggz | m | 10:31 |
| rinigus | piggz: we can, see definition of targets | 10:32 |
| piggz | ok | 10:32 |
| rinigus | let's get back to discussion later, I keep swapping screens and better focus on other things :) | 10:33 |
| lbt | yep | 10:33 |
| lbt | oh | 10:33 |
| piggz | same :) | 10:33 |
| lbt | I meant yep you can have a hw:common version per path in chum | 10:33 |
| lbt | the only concern I'd have is building gbinder in chum - if you're not doing that then you're safe as you won't upset deviced | 10:34 |
| lbt | s | 10:34 |
| lbt | I can't say if hw:common will be in the 4.3 snapshot so this is also a good solution until then | 10:35 |
| lbt | and it won't be backported to the 4.2 snapshot so you'll need it there | 10:35 |
| piggz | lbt: sure, we wont build gbinder itself, just the python binding | 10:36 |
| lbt | yes - that will need publishing | 10:37 |
| lbt | so yes - all looks sane | 10:37 |
| piggz | gr8 | 10:37 |
| rinigus | thanks! but looks like we will have to see what happens with 4.3 and be ready to change then | 10:40 |
| mal | lbt: the testing:common looks terrible because it has all packages that at some point had custom versions built there | 11:06 |
| mal | lbt: as you can see only 17 packages are build for latest release | 11:06 |
| rinigus | mal: I think the point was that if someone, by accident, enables hw:common repo for 3.2 sfos, we will get latest sfos version hw:common build for that | 11:14 |
| rinigus | so, it is not a safe situation | 11:14 |
| rinigus | from this POV, we should have hw:common:4.2.0.24 as separate project | 11:16 |
| rinigus | same logic for each port | 11:16 |
| mal | not sure if I understand | 11:21 |
| lbt | that also would allow fixes to be made should they ever be needed for older versions | 11:22 |
| lbt | it's more work but something to consider | 11:22 |
| rinigus | mal: idea is to have https://build.sailfishos.org/project/show/nemo:testing:hw:common:4.2.0.24 and under that only 4.2.0.24 target | 11:29 |
| rinigus | that way old versions can be kept "active" and don't need to be disabled. | 11:29 |
| mal | hmm | 11:29 |
| rinigus | if someone right now drops <build> <disable/> ... in nemo:testing:hw:common we will be in big trouble | 11:30 |
| rinigus | or if someone deletes generated RPMs as an accident. | 11:30 |
| piggz | rinigus: assuming you have finished $dayjob ..... do we have a plan to bring python-gbinder and waydroid to chum? | 15:12 |
| rinigus | piggz: yes, good evening. back at home and can discuss. | 15:53 |
| rinigus | piggz: so, your point that common is used for compilation only makes it possible to bring the bindings to chum | 15:54 |
| piggz | ok, im for that i think ... we can always see how it goes in testing: | 15:54 |
| piggz | i guess we only add it to each target we want, that way we specify the correct version of hw:common | 15:55 |
| rinigus | we can. now we will need to adjust https://build.merproject.org/project/meta/sailfishos:chum . do we disable builds for older SFOS versions? | 15:55 |
| rinigus | (meta for :testing though) | 15:56 |
| piggz | yes, we can be sure its ok for 4.2 onwards .... only current devices and ports will be compatible with these anyway | 15:58 |
| piggz | im just getting confused to why we have that "invalid" status ... running dbus-monitor, i can see the problem but it doenst make sense! | 15:59 |
| rinigus | piggz: I'll add then repos for 4.2 | 16:01 |
| rinigus | as for invalid - haven't looked into that. so, can't help with it so far | 16:02 |
| piggz | rinigus: according to dbus-montor, systemd returns string "Unit waydroid-session.service not loaded." | 16:08 |
| piggz | which, accorinding to "systemctl --user status waydroid-session.service" it certainly is loaded! | 16:08 |
| rinigus | piggz: loaded for me as well (according to command) | 16:12 |
| rinigus | piggz: is it possible you ask for system' systemd? not from the user's one | 16:14 |
| piggz | rinigus: i think i found it | 16:19 |
| rinigus | meanwhile, I cannot figure out how to catch closing of Waydroid window. nothing obvious on dbus (user or system). | 16:19 |
| rinigus | piggz: great1 | 16:19 |
| piggz | a disabled service doesnt get listed ... the "auto start" disables it | 16:19 |
| piggz | so, i wonder if you can have an enabled service that doesnt start | 16:21 |
| rinigus | piggz: which autostart? but then we can ignore the fact it is invisible and just try to activate it anyway | 16:21 |
| rinigus | and consider "invalid" and stopped or whatever other similar value is as equivalents | 16:22 |
| piggz | rinigus: not wth dbus, becuase you need to specify the unit path to start the unit ... it doesnt have a path if its disabled | 16:22 |
| rinigus | piggz: but if I am in the state "invalid" I can still press your button on GUI and it will start. | 16:23 |
| rinigus | just the status is not updated | 16:23 |
| piggz | hmm, does it actually start? | 16:24 |
| rinigus | ... if I understood your concern correctly | 16:24 |
| rinigus | try to start, swipe out and back again to see status update | 16:24 |
| rinigus | it does start over here | 16:24 |
| piggz | yeah, i think there is something quirky about the systemd dbus api ... seems quite random to when it will return that unit status | 16:27 |
| rinigus | piggz: https://build.sailfishos.org/package/show/sailfishos:chum:testing/gbinder-python | 16:32 |
| rinigus | https://build.sailfishos.org/project/meta/sailfishos:chum:testing | 16:32 |
| rinigus | no builds for i486 | 16:33 |
| piggz | rinigus: https://unix.stackexchange.com/questions/615202/systemd-dbus-api-returns-service-not-loaded-for-disabled-services | 16:33 |
| piggz | so yes, we can start it | 16:33 |
| piggz | rinigus: ok, i think i have it sorted | 16:33 |
| piggz | rinigus: so, if disabled + started ... its possible to get the status, but if disabled and stopped its not ... enabled is fine either way | 16:36 |
| rinigus | piggz: as long as we can switch it on and off - it is all fine :) | 16:37 |
| piggz | rinigus: can you try the latest push | 18:11 |
| piggz | if its good,we can add waydroid to chum before i go to the pub! | 18:11 |
| rinigus | piggz: sure. just a sec | 18:13 |
| rinigus | piggz: meanwhile - waydroid prevents suspend for me. as soon as I have session running, cpu suspend is never happening | 18:15 |
| piggz | rinigus: well, i guess thats a waydroid issue, we just provide users with options | 18:16 |
| rinigus | I asked on waidroid channel | 18:16 |
| rinigus | piggz: you are good to go (submit to chum+pub) - seems like the toggle is working :) | 18:19 |
| piggz | rinigus: submitted | 18:28 |
| rinigus | piggz: it is in. I'll deal with the build config at chum. | 18:29 |
| lal883[m] | rinigus: don't think it prevents suspend on my device. I have been running it continuously for a few days now. | 18:31 |
| rinigus | lal883: have you measured it? | 18:32 |
| lal883[m] | How do I verify though, to be sure? | 18:32 |
| rinigus | I am obviously using collectd/systemdatascope as it monitors everything | 18:33 |
| rinigus | but you can use mce-tools as well | 18:33 |
| piggz | rinigus: i updated instructions and closed issue .... | 18:33 |
| lal883[m] | I have a script that records battery charge every minute. And when the device suspends it fails to record anything. The period which it fails to record has been same before and after Waydroid. | 18:33 |
| piggz | btw, have you done this before... goto a github repo and press . | 18:33 |
| lal883[m] | Okay. Let me check. | 18:34 |
| rinigus | nope, haven't | 18:34 |
| rinigus | selected a . for me | 18:35 |
| rinigus | piggz: README looks good - seems like all needed is there. look how far waydroid managed to develop itself when you compare with what lal883 had to write. | 18:37 |
| rinigus | no more need to deal with adjusting system images, for example | 18:38 |
| rinigus | lal883: with mce-tools, run `mcetool --get-suspend-stats` in the terminal. wait for some time (2-3 min) and run it again. | 18:40 |
| lal883[m] | rinigus: can confirm device suspends with Waydroid. According to mce 49 hours uptime, 31 hours suspend time | 18:41 |
| rinigus | if suspend time changes, your suspend works. you can calc % of suspend from that as well - should 70-80 | 18:41 |
| rinigus | lal883: do you use latest waydroid android images? I am on GAPPS one | 18:42 |
| lal883[m] | No, I didn't update yet. I am still on Waydroid 1.1.1 and old images. | 18:42 |
| rinigus | I have a feeling it worked before, on older image | 18:43 |
| lal883[m] | I will try to verify that. I sure shall upgrade tomorrow evening. | 18:44 |
| lal883[m] | Oh wait, I also have that Waydroid suspend property set. Wonder if that makes a difference. | 18:45 |
| rinigus | lal883: which property? | 18:46 |
| lal883[m] | rinigus waydroid prop set persist.waydroid.suspend true | 18:47 |
| lal883[m] | Read somewhere that it makes the container sleep when not in use. | 18:48 |
| rinigus | lal883: vibration works on tama as well, btw. you have to revert changes in /vendor/etc/vintf/manifest.xml and comment out that disabling of vibrator service | 18:49 |
| rinigus | will test suspend | 18:49 |
| lal883[m] | rinigus: thanks, I made those changes last day. Can confirm I have vibration too. | 18:50 |
| lal883[m] | Although no notification sounds. | 18:50 |
| rinigus | lal883: I was getting notification sounds on new image. drove me crazy with all these google updates and had to make them silent | 18:51 |
| lal883[m] | rinigus Oh cool. That is good! I will wait till tomorrow. | 18:53 |
| rinigus | :) | 18:53 |
| rinigus | do I have to run that set property as root? | 18:53 |
| lal883[m] | No, user. | 18:54 |
| rinigus | ok | 18:54 |
| piggz | rinigus: lal883[m]: cc'd you on forum topic | 19:03 |
| piggz | removed the python and waydroid packages from my port | 19:06 |
| rinigus | lal883: nope, persist.waydroid.suspend set to true didn't help | 19:17 |
| lal883[m] | rinigus: no clue then. I will try to test with new images tomorrow. | 19:19 |
| rinigus | lal883: let's see if I get some feedback on waydroid channel | 19:20 |
| rinigus | lal883: new vanilla image looks to allow suspend | 19:43 |
| hnj | uuuh, is there anything like a wiki for users? with guides how to install sfos on a given device? list of ports? anything like the lineageos wiki or xda-developers.com where practical information for users is easily reachable? everything I find seems very "marketingy" or developer-focused o_O | 19:47 |
| rinigus | hnj: I think poetaster was working on making new list of active ports | 19:49 |
| rinigus | hnj: see https://forum.sailfishos.org/t/community-meeting-on-irc-30th-september-2021/8043/11 for short list to current resources | 19:52 |
| rinigus | and discussion on topic at https://irclogs.sailfishos.org/meetings/sailfishos-meeting/2021/sailfishos-meeting.2021-09-30-07.00.html | 19:53 |
| rinigus | lal883 and piggz : turns out that android image which I use was broken. so, have to ota to newer one and it should be fine | 19:58 |
| piggz[m] | Rinigis: there is some sensor package to package up next i think | 20:00 |
| piggz[m] | Unfortunately sailtrix wont let me post a picture of my beer :D | 20:01 |
| hnj | rinigus: will take a look, thanks | 20:25 |
| hnj | hm, disappointing /-: | 20:37 |
| Nekron[m] | 🍺 there is is :) | 21:21 |
| Nekron[m] | * 🍺 there it is :) | 21:24 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!