<freemangordon>
center frequency should be 2412, right?
<freemangordon>
hmm, my PC reports channel 1 (2412 MHz), width: 40 MHz, center1: 2422 MHz
pere has quit [Ping timeout: 276 seconds]
<mkfx>
arno11: I used native android keyboard
<mkfx>
gives us screen resize
<mkfx>
and no, couldn't update to devel, can't update cellulard (?) since we don't run an init
<mkfx>
tho it's a bit buggy.
whatsupboy has joined #maemo-leste
<Wizzup>
yeah, with openrc's softlevel you can still have services running
<Wizzup>
this is why I'd like to understand what was dobne
<Wizzup>
it's totally possible to leverage openrc still
<Wizzup>
and then some services will run, others can be blocked
<arno11>
mkfx: hmm, can't remember what i did exactly but you should upgrade to chimaera first (and install related missing pkgs but be sure to have proper sources.list without chimaera -devel and with ascii removed), reboot and dist-upgrade to -devel (with chimaera and chimaera -devel in sources.list)
<Wizzup>
did anyone try to just do a rsync -anv to check the diff with a regular image
<arno11>
no idea but i can try soon
_fab has quit [Remote host closed the connection]
<Wizzup>
you could also do the diff on after doing dist-upgrade I suppose
<Wizzup>
it'll just tell us what files are changed
<Wizzup>
then we can see how they are changed
<arno11>
ok
<arno11>
but i think the problem is not the image itself, but rather the 2 custom bash scripts needed to run the img through termux)
_fab has joined #maemo-leste
<arno11>
one of the script runs init and xsession stuff by hand
<arno11>
i modified it a bit iirc
<Wizzup>
yes, but if it was more regular then openrc in soft run level could start the xsession script
<Wizzup>
if it's just the two scripts and the image is unchanged then it's much easier
_fab has quit [Quit: _fab]
<arno11>
yes indeed
_fab has joined #maemo-leste
<arno11>
mkfx: the key file is /leste/diejuse_scripts/launchMaemo.sh if you want to toy with it
<Wizzup>
freemangordon: we have a small problem
<Wizzup>
>>> from debian.debian_support import Version
<Wizzup>
>>> v1=Version('1:1.3-1+m7')
<Wizzup>
>>> v2=Version('1:1.3-1+4m7')
<Wizzup>
>>> v1>v2
<Wizzup>
True
<Wizzup>
>>> v1<v2
<Wizzup>
False
<Wizzup>
with chimaera we missed the +\dm7 and instead wrote +m7
<Wizzup>
and this is now 'newer' than +4m7
<Wizzup>
so I don't know if dist-upgrade will do the right thing
<Wizzup>
any ideas?
<freemangordon>
for all packages?
<Wizzup>
yes
<Wizzup>
beowulf was +2m7
<Wizzup>
daedalus is +4m7
<freemangordon>
well, I saw lots of packages upgraded
<Wizzup>
chimaera unfortunately is +m7
<Wizzup>
yes, some I had to re-tag
<Wizzup>
due to src fixes
<Wizzup>
re-tag meaning up the version
<Wizzup>
maybe it's a non issue, I'll find out
<freemangordon>
I did another dist-upgrade, this time with enough free space :D
<freemangordon>
just rebooting, lemme check if there are any remaining +m7 packages
<Wizzup>
but worth checking for example if rtcom-eventlogger is 1.5.4+m7 or 1.5.4+4m7
<freemangordon>
mhm
<freemangordon>
hmm, h-d hangs right after boot
<Wizzup>
hangs how?
<Wizzup>
waiting for ready signal?
Anasko has joined #maemo-leste
<freemangordon>
no, it boots to h-d
<freemangordon>
but it just freeze
<Wizzup>
maybe start it over ssh and see what the error is
<freemangordon>
something with virtualbox perhaps
<freemangordon>
no error
<Wizzup>
strange
<freemangordon>
something virtualbox related
<Wizzup>
ok
<freemangordon>
lemme try to rebuild gues additions
<mkfx>
arno: okay
<Wizzup>
freemangordon: ah yes, new kernel
<Wizzup>
probably need those
<Wizzup>
(and new x)
Twig has joined #maemo-leste
<Wizzup>
btw, looks like there is no qt6-gtk2 platform theme, just qt6-gtk platform theme (which is gtk3)
<Wizzup>
but that's not too important
<freemangordon>
going to upgrade virtualbox :(
<freemangordon>
even worse :(
antranigv has quit [Ping timeout: 248 seconds]
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Read error: Connection reset by peer]
<Wizzup>
freemangordon: strange, and you're sure it is vbox?
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
Anasko has joined #maemo-leste
<Wizzup>
it's going to take a bit of time to rebase all our upower patches it seems
<freemangordon>
no idea what's going on, but now VM does not even boot the kernel
<Wizzup>
it looks like some changes we suggested are included
<Wizzup>
freemangordon: hm, and chimaera image still works?
<freemangordon>
yes
antranigv has joined #maemo-leste
<Wizzup>
maybe try again and ensure no free space issues?
<freemangordon>
yep, that was with 27G of free space
<freemangordon>
it does not even boot in rescue mode
<freemangordon>
but yeah, lemme try again
<Wizzup>
ok, when you want access to the armhf vm for mesa just let me know D:
<Wizzup>
:D
<freemangordon>
heh
<freemangordon>
I will need VM anyways
<Wizzup>
right
<Wizzup>
what's left now I think is upower (unlocks mce and status area applet battery) and then just tracker, but rtacker is not core
<Wizzup>
we could just have mce and battery applet use mainline upower for a few days
<Wizzup>
kind of inclined to do that tbh
<sicelo>
hehe
<Wizzup>
almost none of the patches apply, they all require conflict resolution :D
<Wizzup>
(upower)
<sicelo>
i don't remember now how (by default) mce decides to power down due to low bat ... if it uses upower percentage, then people whose fuel gauges don't have calibration will not be able to run Leste, since it'll try to shutdown right away. would need to look at the battery-guard plugin to see how it makes that decision
* sicelo
not at PC right now
<Wizzup>
I'm not saying we won't rebase
<Wizzup>
but this is the last thing to be able to make images and dist upgrade ;)
<freemangordon>
approximation done in upower is so inaccurate, that I am not user it is useful
<freemangordon>
so we'd better fix whatever needs to be fixed in mce/drivers instead of porting broken patches
akossh has joined #maemo-leste
<sicelo>
yes @ approximation. i did mention it as well couple of days ago
<freemangordon>
so, besides that, what else do we need that is missing in upstream upower?
<sicelo>
freemangordon: the drivers are technically correct, since the uncalibrated fuel gauge is really not reporting any capacity. as for upstream upower, we only really need the approximation, nothing else
<sicelo>
Wizzup: i can probably volunteer to work on forward-porting it. not sure if i can finish today, but can do my best (holding off on maeotp :p )
<freemangordon>
ok, but lets first decide what we need ported
<freemangordon>
if there is a bug in upstream upower(as the ^^^ commit implies) isn;t it better to open a bug on their tracker, instead having own patches?
<freemangordon>
also, I think we are better without that approximation patch
<freemangordon>
it is totally off
<sicelo>
that commit (time) is upstreamable for sure, but not *too* important either
<freemangordon>
like, sometimes you see 50% and in a minute the battery is flat
<freemangordon>
on d4 that is
<sicelo>
freemangordon: some of that is probably not the approximation ... the approximation only kicks in when your device doesn't report capacity at all, i.e. not calibrated
<freemangordon>
right
<sicelo>
since you use your d4 regularly, i doubt you're affected by that
<freemangordon>
d4 loses calibration on every reboot
<sicelo>
there's an openrc service that stores it, and rewrites it at boot. luckily that property is writeable on the d4's driver
<freemangordon>
this is the capacity that gets overwritten
<freemangordon>
not current charge
<freemangordon>
and that's what is calculated by that patch IIUC
<sicelo>
yup, upower will be happy to see capacity. everything else is less important
<sicelo>
which patch? approximation?
<freemangordon>
yes
<freemangordon>
it provides SOC based on voltage
<freemangordon>
that's totally off
<sicelo>
it's bad for sure, but i don't see another option, when voltage is the only reading you can trust
<freemangordon>
but what do we need that for?
<sicelo>
to show a battery on the status bar that gives user a rough idea of how much juice they have
<freemangordon>
we don;t need to hack upower just to tell user that battery is low
<sicelo>
and to also know when to initiate shutdown due to low battery.
<freemangordon>
it is not even rough idea
<freemangordon>
esp on degraded battery
<freemangordon>
we can do similar without that patch, in battery applet for example
<freemangordon>
we can issue low battery warning on lets say 3.4V
<freemangordon>
and wait for kernel to send "low battery" signal to start shutdowm
<sicelo>
anyway, the problem only affects D4 and N900. other devices should be fine because their fuel gauges have reliable ways to determine it
<freemangordon>
yes
_fab has quit [Remote host closed the connection]
<freemangordon>
and I vote for dropping that patch
<sicelo>
freemangordon: yes @ "low battery" uevent ... hence my patch that's still waiting on krzk. without it, we never get that particular uevent
<freemangordon>
hmm
<freemangordon>
ping him?
<sicelo>
for N900, that is :-)
<freemangordon>
ah, kernel patch
<freemangordon>
but again, this is not a problem of upower, no?
<sicelo>
i thought to wait for holidays a little, then ping. anyway we have it in Leste, so not a problem for us
<freemangordon>
ok
<sicelo>
regarding upower, yes, it can definitely be handled elsewhere, e.g. mce. although i think uvos was also of the view that battery doesn't belong there :p
<Wizzup>
13:31 < freemangordon> d4 loses calibration on every reboot
<sicelo>
anyway, whichever options is fine really. at the end of it all, what matters is (1) being able to show something to the user, and (2) not draining batteries excessively
<Wizzup>
I think it gets saved in init script. no?
<freemangordon>
it is capacity that gets saved, bu we lose SOC
<freemangordon>
*but
<Wizzup>
ok
<Wizzup>
so shall I continue for now with daedalus/bookworm upower?
<freemangordon>
yes
<sicelo>
SOC is automatically calculalaated by the cpcap driver if capacity is there, iirc
<freemangordon>
no
_fab has joined #maemo-leste
<freemangordon>
unless I am missing something
<freemangordon>
but after reboot current charge is reported as 0
<sicelo>
mmm, anyway, upower won't mind charge = 0 as long as capacity != 0 :-)
<sicelo>
let's go with upstream upower
<freemangordon>
yes
<freemangordon>
and see what is missing
<freemangordon>
and kind of start clear, more or less
<Wizzup>
I think we'll find probably a bunch but maybe it's gotten better
<Wizzup>
I think we also depend on some of the properties that were added
<freemangordon>
ok, but lets at least report what is missing to upstream and pester them
<freemangordon>
because on the next migration we'll have the same issues otherwise
<sicelo>
i know for sure the power off problem on N900 (because i experience it on pmos). but then most people have USB port, so easy way out is just to connect a charger ;-)
<sicelo>
it's particularly bad for me because that N900 doesn't have USB port, so always reports 0
<freemangordon>
ok, but shall we hack upower to support a device with HW failure?
<sicelo>
:-)
<freemangordon>
the other option is to reinvent BME
<sicelo>
luckily upstream upower are now a bit more welcoming ... compared to when i tried to work on this issue previously
<freemangordon>
not impossible, but do we want to
<sicelo>
yeah let's go with upower, and move the workarounds into mce. i also would like to see less forks of stuff (that's the convo we had with wizzup regarding upower a couple of days ago)
<sicelo>
*go with daedalus' upower
<freemangordon>
also, I think battery cannot be moved out of mce, because of emergency calls etc handling
<freemangordon>
I *don't* want mce to shut-down device for low battery during emergency (or even normal) call
<Wizzup>
13:47 < freemangordon> the other option is to reinvent BME
<Wizzup>
prefer not to
<freemangordon>
me too
<Wizzup>
in fact I prefer upower fork to another maemo specific daemon
<Wizzup>
hildon-meta-core is now installable on vm
<Wizzup>
shall I build a core vm image?
<Wizzup>
(for daedalus)
<freemangordon>
yes, please
<freemangordon>
maybe it will work properly here :)
<Wizzup>
ok, will take a few hours
<freemangordon>
sure
<freemangordon>
Wizzup: I wonder if we will be able to enable openrc parallel boot at last
<Wizzup>
on the n900 that will just cause more pain I think
<Wizzup>
hm, maybe we need tinydm
<Wizzup>
or did we not need that any more
<freemangordon>
I think we need it
<freemangordon>
hmm, lemme check the package
<Wizzup>
it's not installed on my d4
<freemangordon>
autologin
<freemangordon>
no tinydm is needed
<Wizzup>
autologin I did
<Wizzup>
do you remember the file to touch to have dsme not reboot upon failure, just in case?
<sicelo>
freemangordon: brief return to the upower issue ... one argument for adding the improvements in upower (eventually upstreaming) instead of mce is - if upower reports something usable, then any other application a user may install will see some usable values. e.g. Wizzup had some gnome thing that displayed battery graph. buzz also wrote something.
<sicelo>
just mentioning ... not disagreeing with using upstream upower as is. it remains true that the problem only affects D4 and N900, and only under certain circumstances, so we definitely don't need to r
<sicelo>
earchitect a lot of stuff just for these niche cases
<freemangordon>
sicelo: I am all for improving upower
<freemangordon>
as long as we not have to support a pile of patches
<freemangordon>
we just don;t have the manpower to do it
<freemangordon>
Wizzup: does it react to touches/clicks?
<freemangordon>
also, which kernel does it boot to?