Thursday, 2021-10-21

*** kimmoli_ is now known as kimmoli03:45
piggzlbt: ping09:04
piggzlbt: 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
piggzany thoughts?09:06
piggzrinigus: ^^09:06
lbtso that package is part of sfos but isn't in the repos that get setup to build against09:23
lbtthe source is available of course so one option is to build it yourselves in chum09:24
lbthowever 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 tricky09:25
lbtright now we think the ABI hasn't changed so it might work for all versions09:25
lbtthe second issue is that you really don't want to be publishing a core rpm that could be seen as "newer" by devices09:26
lbtthat would be bad09:26
lbtyou probably can't sanely repackage the code to just build a -devel either09:26
lbtso 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 publish09:27
lbt(I could see other dev-time only tools in there too - like documentation generators)09:28
lbtthat repo would be a <path> repo for the main chum project09:28
lbtI think that would solve the 'dangerous' publishing issue but you may hit a mult-version problem09:29
piggzwe already considered the risk of having mismatched versions, and we want to avoid that09:34
piggzlbt: 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 though09:44
abrwould be easier with these:
abrthen you could do it differently for older versions, or even not build it at all for those09:45
lbtyes - I didn't know it was already present in a project09:45
abri did try to search for it, but search seems broken atm09:46
piggzwe arent interested in supporting older than 4.2 for these pacakges anyway09:46
piggzabr: we already can disable on certain projects .. its just in the repo config09:47
lbtyou could have hw:common:4.1 and hw:common:4.2 in the future09:48
lbtumm 4.309:48
lbtso actually that would allow different gbinder versions from different 'support' projects09:49
piggzlbt: so, whats the recommendation?09:54
lbtSo the goal here is to provide packages that supplement the core OS and should not be published10:01
lbtI think you'll need this to be SFOS version specific10:02
lbtthe hw:common is volatile and out of chum control - IMHO you should not use that. Make a dedicated chum:support: that builds against 4.2 and snapshot gbinder and dependencies into there then add that as a path for chum's 4.2 repo10:06
lbtthat is then "frozen"10:06
lbtthat will need redoing every release10:07
riniguslbt: 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 are10:07
rinigusso, question is, why not to add it as well as the one of those upstream repos? in the definition of target10:08
rinigus(if I use the terms correctly)10:08
rinigusalternative for this particular package (gbinder-python) is to add it to hw:common and use through that. but that would help ported devices only10:10
rinigusas 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 it10:11
lbtyou're going to need to do that anyway10:11
lbtit's possible that hw:common should be in the snapshot we install onto OBS at release time10:12
lbtas it's not device specific10:12
rinigusthe bindings are not device specific either - so it does match well.10:13
riniguspython bindings10:13
rinigusas for common, it is "frozen" for older releases. so, gbinder should be of correct version for each SFOS version10:13
lbtoooh that's dodgy...10:22
lbtbut yes, it will probably work10:23
piggzlol, wdym dodgy :D10:23
lbtthose repos are unrecoverable if they accidntally get re-enabled10:24
piggzwell, we leave mal in charge of them710:24
piggzrinigus: 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 device10:28
piggzits just a build path10:28
riniguslbt: that's the way we have all ports moving between versions. but it is dodgy in the respect of being unable to recover, indeed10:31
piggzthough, im not sure we can specify the repo as the version for each version of chu10:31
riniguspiggz: we can, see definition of targets10:32
riniguslet's get back to discussion later, I keep swapping screens and better focus on other things :)10:33
piggzsame :)10:33
lbtI meant yep you can have a hw:common version per path in chum10:33
lbtthe 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 deviced10:34
lbtI can't say if hw:common will be in the 4.3 snapshot so this is also a good solution until then10:35
lbtand it won't be backported to the 4.2 snapshot so you'll need it there10:35
piggzlbt: sure, we wont build gbinder itself, just the python binding10:36
lbtyes - that will need publishing10:37
lbtso yes - all looks sane10:37
rinigusthanks! but looks like we will have to see what happens with 4.3 and be ready to change then10:40
mallbt: the testing:common looks terrible because it has all packages that at some point had custom versions built there11:06
mallbt: as you can see only 17 packages are build for latest release11:06
rinigusmal: 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 that11:14
rinigusso, it is not a safe situation11:14
rinigusfrom this POV, we should have hw:common: as separate project11:16
rinigussame logic for each port11:16
malnot sure if I understand11:21
lbtthat also would allow fixes to be made should they ever be needed for older versions11:22
lbtit's more work but something to consider11:22
rinigusmal: idea is to have and under that only target11:29
rinigusthat way old versions can be kept "active" and don't need to be disabled.11:29
rinigusif someone right now drops  <build> <disable/> ... in nemo:testing:hw:common we will be in big trouble11:30
rinigusor if someone deletes generated RPMs as an accident.11:30
piggzrinigus: assuming you have finished $dayjob ..... do we have a plan to bring python-gbinder and waydroid to chum?15:12
riniguspiggz: yes, good evening. back at home and can discuss.15:53
riniguspiggz: so, your point that common is used for compilation only makes it possible to bring the bindings to chum15:54
piggzok, im for that i think ... we can always see how it goes in testing:15:54
piggzi guess we only add it to each target we want, that way we specify the correct version of hw:common15:55
riniguswe can. now we will need to adjust . do we disable builds for older SFOS versions?15:55
rinigus(meta for :testing though)15:56
piggzyes, we can be sure its ok for 4.2 onwards .... only current devices and ports will be compatible with these anyway15:58
piggzim 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
riniguspiggz: I'll add then repos for 4.216:01
rinigusas for invalid - haven't looked into that. so, can't help with it so far16:02
piggzrinigus: according to dbus-montor, systemd returns    string "Unit waydroid-session.service not loaded."16:08
piggzwhich, accorinding to "systemctl --user status waydroid-session.service" it certainly is loaded!16:08
riniguspiggz: loaded for me as well (according to command)16:12
riniguspiggz: is it possible you ask for system' systemd? not from the user's one16:14
piggzrinigus: i think i found it16:19
rinigusmeanwhile, I cannot figure out how to catch closing of Waydroid window. nothing obvious on dbus (user or system).16:19
riniguspiggz: great116:19
piggza disabled service doesnt get listed ... the "auto start" disables it16:19
piggzso, i wonder if you can have an enabled service that doesnt start16:21
riniguspiggz: which autostart? but then we can ignore the fact it is invisible and just try to activate it anyway16:21
rinigusand consider "invalid" and stopped or whatever other similar value is as equivalents16:22
piggzrinigus: not wth dbus, becuase you need to specify the unit path to start the unit ... it doesnt have a path if its disabled16:22
riniguspiggz: but if I am in the state "invalid" I can still press your button on GUI and it will start.16:23
rinigusjust the status is not updated16:23
piggzhmm, does it actually start?16:24
rinigus... if I understood your concern correctly16:24
rinigustry to start, swipe out and back again to see status update16:24
rinigusit does start over here16:24
piggzyeah, i think there is something quirky about the systemd dbus api ... seems quite random to when it will return that unit status16:27
rinigusno builds for i48616:33
piggzso yes, we can start it16:33
piggzrinigus: ok, i think i have it sorted16:33
piggzrinigus: so, if disabled + started ... its possible to get the status, but if disabled and stopped its not ... enabled is fine either way16:36
riniguspiggz: as long as we can switch it on and off - it is all fine :)16:37
piggzrinigus: can you try the latest push18:11
piggzif its good,we can add waydroid to chum before i go to the pub!18:11
riniguspiggz: sure. just a sec18:13
riniguspiggz: meanwhile - waydroid prevents suspend for me. as soon as I have session running, cpu suspend is never happening18:15
piggzrinigus: well, i guess thats a waydroid issue, we just provide users with options18:16
rinigusI asked on waidroid channel18:16
riniguspiggz: you are good to go (submit to chum+pub) - seems like the toggle is working :)18:19
piggzrinigus: submitted18:28
riniguspiggz: 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
riniguslal883: have you measured it?18:32
lal883[m]How do I verify though, to be sure?18:32
rinigusI am obviously using collectd/systemdatascope as it monitors everything18:33
rinigusbut you can use mce-tools as well18:33
piggzrinigus: 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
piggzbtw, have you done this before... goto a github repo and press .18:33
lal883[m]Okay. Let me check.18:34
rinigusnope, haven't18:34
rinigusselected a . for me18:35
riniguspiggz: 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
rinigusno more need to deal with adjusting system images, for example18:38
riniguslal883: 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 time18:41
rinigusif suspend time changes, your suspend works. you can calc % of suspend from that as well - should 70-8018:41
riniguslal883: do you use latest waydroid android images? I am on GAPPS one18:42
lal883[m]No, I didn't update yet. I am still on Waydroid 1.1.1 and old images.18:42
rinigusI have a feeling it worked before, on older image18: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
riniguslal883: which property?18:46
lal883[m]rinigus  waydroid prop set persist.waydroid.suspend true18:47
lal883[m]Read somewhere that it makes the container sleep when not in use.18:48
riniguslal883: 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 service18:49
riniguswill test suspend18: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
riniguslal883: I was getting notification sounds on new image. drove me crazy with all these google updates and had to make them silent18:51
lal883[m]rinigus Oh cool. That is good! I will wait till tomorrow.18:53
rinigusdo I have to run that set property as root?18:53
lal883[m]No, user.18:54
piggzrinigus: lal883[m]: cc'd you on forum topic19:03
piggzremoved the python and waydroid packages from my port19:06
riniguslal883: nope, persist.waydroid.suspend set to true didn't help19:17
lal883[m]rinigus: no clue then. I will try to test with new images tomorrow.19:19
riniguslal883: let's see if I get some feedback on waydroid channel19:20
riniguslal883: new vanilla image looks to allow suspend19:43
hnjuuuh, 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 where practical information for users is easily reachable? everything I find seems very "marketingy" or developer-focused o_O19:47
rinigushnj: I think poetaster was working on making new list of active ports19:49
rinigushnj: see for short list to current resources19:52
rinigusand discussion on topic at
riniguslal883 and piggz : turns out that android image which I use was broken. so, have to ota to newer one and it should be fine19:58
piggz[m]Rinigis: there is some sensor package to package up next i think20:00
piggz[m]Unfortunately sailtrix wont let me post a picture of my beer :D20:01
hnjrinigus: will take a look, thanks20:25
hnjhm, disappointing /-:20:37
Nekron[m]🍺 there is is :)21:21
Nekron[m] * 🍺 there it is :)21:24

Generated by 2.17.1 by Marius Gedminas - find it at!