<sicelo>
Wizzup: mmm, how are you able to send emails to the ML and it arrives this quick? I normally Cc the ML when sending kernel patches, but they take ages to show up on the ML
<Wizzup>
sicelo: maybe some of them require manual review
<Wizzup>
I think one kernel for armhf would be great from a maintenance perspective but you can also take the droid4-linux and remove most of the omap patches and build a different defconfig
<mkf>
hm
<mkf>
i pretty much needed no patch for my tablet, mainline just worked™
<mkf>
however for some of my devices i don't know how to test properly, like screen rotation or bluetooth
<mkf>
i guess i'll fork droid4 then or update sunxi
fantom has quit [Ping timeout: 244 seconds]
<sicelo>
freemangordon: Wizzup: as far as the Maemo/Leste stack is concerned, which process is the most important, and which is not allowed to be stopped/restarted, i.e. restarting it basically requires a reboot, or similar?
<sicelo>
i guess dsme can be restarted without ill effect?
<Wizzup>
I don't think restarting dsme is a great idea
<sicelo>
i think correct solution is for dsme to take an inhibitor lock at startup, which would ensure it sees all requests for shutdown and can decide whether or not to honor them. anyway, maybe job for 2030, but this would do a lot of good, i think
<sicelo>
maybe then that gives us also the chance to remove battery stuff from mce, fulfilling uvos' wish :-)
<Wizzup>
can we have upowerd make no decisions about shutdow and ignore its requests?
<Wizzup>
or, why do we want to utilise upowerd here?
<sicelo>
yes we can tell upower to not request the shutdown, if we ship a suitable config (AllowRiskyCriticalPowerAction=true and CriticalPowerAction=Ignore).
<Wizzup>
that seems to be all we need for now, right?
<Wizzup>
I'm trying to understand if/why we would want deeper integration with upowerd, it is not clear to me that it will offer the smarts that we need
<sicelo>
yes i didn't mean integrating upower with dsme :-)
<sicelo>
i just observed that dsme would probably benefit from taking an inhibitor lock, so it can reliably control/manage requests for shutdown, whether coming from upower or anything else
System_Error has quit [Ping timeout: 264 seconds]
<Wizzup>
I see, and this lock is some systemd interface, or?
<sicelo>
yes. elogind also implements it, so it can work on Leste/Devuan too. anyway, it's not an immediate thing to implement. lots of other stuff is more urgent
<Wizzup>
I see, so it was ultimately elogind that did the actual shutdown
<sicelo>
yes. upower just requests it
<Wizzup>
can we disable that in elogind?
<Wizzup>
then we could make things work without a upower fork now, I think
<sicelo>
if we had an inhibitor lock held by something else, then yes, we can disable it
<sicelo>
anyway, i think the fork will help us in other ways (e.g. we do need to show some sort of status icon, even if inhibit solves the shutdown problem), so let's pursue the fork first, and do the inhibitor later. the idea/plan is for the fork to be upstreamed anyway, so it will not be a maintenance burden like previously
<mkf>
freemangordon: should i put my device trees in linux sunxi or should i fork linux-droid4?
_fab has quit [Quit: _fab]
_fab has joined #maemo-leste
<mkf>
Wizzup: btw have you considered source hut?
_fab has quit [Quit: _fab]
<Wizzup>
not really
<mkf>
it's nice imho.
<Wizzup>
I don't have a good personal experience with the author of the sw and I think it's perhaps a bit too 'hacker focussed'. I'd consider using it for some personal project
<mkf>
fair enough, author was indeed a bit controversial.
<mkf>
however it's nice that it doesn't require js. i often find myself around computers without browsers with js support or too weak to handle modern day js.
<Wizzup>
true...
<Wizzup>
gitea/forgejo makes things quite easy though, with good migrations tools, oauth2, etc
<Wizzup>
I think either will be a big usability change over github
<Wizzup>
btw, re kernel. I think maybe just take 6.12 or whatever kernel, add the build deb patches we have in linux-droid4, and then push to linux-sunxi or so
<Wizzup>
the build dep patches are really most of what you need, and probably also take a new debian dir from droid4-linux and change the right names/etc for sunxi
<Wizzup>
I can help with some of it
<Wizzup>
btw, might be worth testing how usable forgejo is without js
<mkf>
is it up?
<Wizzup>
currently git.maemo.org runs gitea still, but I plan to nuke it this week and replace it with forgejo
<Wizzup>
did you try git.maemo.org without js?
<mkf>
let me do so
<Wizzup>
I tried dillo and it's ... eh :)
<mkf>
mothra looks like what mothra would generally look like
<freemangordon>
no, but i don think bs is supported by that driver
<mkf>
i keep seeing people mention 8723bs driver is going to be replace by rtl8xxxx family
<mkf>
but i dont see explict code of 8723bs driver
<freemangordon>
"Driver for Realtek RTL8XXXXU usb wifi chips, which is backported from linux mainline"
<mkf>
hm.
<mkf>
oh well.
<gnarface>
what i seemed to be able to gather, is that basically people don't know that the 8723bs is not the same as the 8723cs
<mkf>
yeah seems no sdio varient exists yet
<freemangordon>
mkf: so, with my band patch your chip cannot connect?
<gnarface>
so there's apparently this widespread mistaken assumption that recent efforts to get the 8723cs working with the new (rtw88?) driver also magically inherited 8723bs support, which is not the case
<mkf>
it seems that patch doesn't effect me much, it's still 1 in 10 with maemo ui
<freemangordon>
hmm...
<mkf>
(but better with wpa cli?)
<gnarface>
however, they might not be so different that it can't still be added, reports are that the staging driver is still faster
<mkf>
if i restart icd like ten times i might get that working
<freemangordon>
mkf: that should not be the case, I put a fix in icd plugin, lemme check if it is in stable
<freemangordon>
mkf: your device is on chimaera, right?
<freemangordon>
oh, fixes are not in -stable :(
<freemangordon>
mkf: later on will build those fixes for stable, it should get better after that
<mkf>
by stable you mean debian terminology? isnt chimaera oldstable?
<mkf>
i can update to dadelus
ceene has quit [Ping timeout: 252 seconds]
<freemangordon>
no
<freemangordon>
bu stable I mean chimaera-stable
<freemangordon>
*by
<freemangordon>
do you have chimaera-devel repos enabled?
<mkf>
no, but i can do so.
<freemangordon>
no, don't
<mkf>
ok
<freemangordon>
we have to mova that to stable anyways
<freemangordon>
*move
<freemangordon>
argh, another typo day
<freemangordon>
Wizzup: do we have a list of diffs between -sable and -devel? for chimaera
apac has quit [Ping timeout: 276 seconds]
<mkf>
there are like two streams one being devuan and other being leste?
<sicelo>
no. leste is based on devuan ...
<freemangordon>
no, what do you mean?
<sicelo>
freemangordon: your ofono CVE fix has been merged ;-)
<mkf>
like leste version x can be installed in devuan x and y
<sicelo>
like leste version x is devuan version x with leste-specific packages on top
<mkf>
okay. so leste isn't really a os like original maemo
<sicelo>
well ... :-)
<mkf>
it's a customized devuan installation with specfic config and packages
<mkf>
i.e, not a hard fork i guess
<sicelo>
it can be argued that the original maemo was debian with maemo-specific stuff on top ;-)
<sicelo>
yes no, not a hard fork. in fact not a fork at all
<mkf>
true. :)
<sicelo>
look at /etc/apt/sources.list ... you'll see the devuan repos there
<mkf>
freemangordon: please let me know once that's available.
<Wizzup>
freemangordon: I can make a repodiff list
<Wizzup>
brb though
Livio has quit [Remote host closed the connection]
<sicelo>
Wizzup: where does devuan keep their development work? i'm looking for their upower packaging. https://git.devuan.org/devuan/upower seems too ancient