<freemangordon>
2025-07-27T08:21:39.634216+03:00 devuan-droid4 mce[2845]: Failed to load module battery-upower: /usr/lib/mce/modules/libbattery-upower.so: cannot open shared object file: No such file or directory; skipping
<Wizzup>
freemangordon: weird, why was this not part of the branches I looked at
<Wizzup>
yeah sicelo also reported that issue @ mce
<freemangordon>
Wizzup: which branches did you look at?
<Wizzup>
I think maemo/daedalus and maemo/daedalus-devel
<Wizzup>
I will be back in 15-20 mins
<freemangordon>
so, do we have a fix for mce or I shall look at it?
<freemangordon>
ok
<Wizzup>
I didn't look yet, so if you want to, please do
<Wizzup>
brb
<freemangordon>
ok
<freemangordon>
building mce:
<freemangordon>
"No upower found, upower support will not be built"
<Wizzup>
so it wasn't getting pulled
<freemangordon>
no, the issue is with upower packaging, we lack libpolkit-gobject-1-dev dependency of libupower-glib-dev
<Wizzup>
if that doesn't work, I will make a tool to sort the output of find correctly
<Wizzup>
I already did this for repodiff
<Wizzup>
with
<Wizzup>
from debian.debian_support import Version
pere has quit [Ping timeout: 276 seconds]
<Wizzup>
there is also reprepro -b /srv/repository/leste/ list daedalus
<sicelo>
on Droid 3, with screen locked & blanked - if you press and release power button (e.g. to see time), after a short while, the screen blanks again, which is fine. but then, for a split second, the desktop contents become visible.
<Wizzup>
probably a lot more sane than running 'find'
<sicelo>
doesn't happen on the N900 (too slow?)
<Wizzup>
sicelo: does it not freeze on you almost immediately
<Wizzup>
or did you mean to write droid 4
<sicelo>
Droid 4, sorry
<Wizzup>
freemangordon: in any case if this works then that's good for me
<Wizzup>
sicelo: damn you got my hopes up
<sicelo>
:-D
<Wizzup>
the droid 3 has been one of the more frustrating things for me
<freemangordon>
Wizzup: I will push the current fix, might change to using reprepro in the future
<Wizzup>
sounds good
<Wizzup>
thanks
apac has joined #maemo-leste
<Wizzup>
btw, after daedalus news post I plan to work on excalibur immediately
<Wizzup>
I think that will be easier for us now
<freemangordon>
Wizzup: how to properly pull jenkins-integration?
<freemangordon>
just git pull?
<freemangordon>
on the server that is
<freemangordon>
yeah, that's it
<Wizzup>
yeah
* sicelo
excited @ excalibur
<freemangordon>
hmm, why is repos build so slow?
<Wizzup>
It runs pkgweb which writes about 200,000 files every time
<Wizzup>
since we still index our beowulf repos
<freemangordon>
but it was not that slow last time
<Wizzup>
I moved the container to a less powerful server and this is the result of that
<freemangordon>
aha
<Wizzup>
we'll move it somewhere else in the near term, I did look at trying to make it faster but due to the way it works it's not that trivial
<Wizzup>
the current server has lots of ram but the two CPUs are only like 1.5Ghz x86s :)
<freemangordon>
I am fine, it is just that I saw it being slower than usual
<Wizzup>
yeah for excalibur this will be a problem (with all the rebuilds)
<Wizzup>
we re-index (and rewrite all files for) beowulf, chimaera, daedalus, excalibur and also -devel and -experimental repos
<freemangordon>
can't it be done only for release we have a new package version?
<Wizzup>
it doesn't know what's new
<freemangordon>
but we do, no?
<Wizzup>
no, we rsync the repos
<freemangordon>
ah
<Wizzup>
and there might also be manual reprepro changes to the repo
<freemangordon>
right
<freemangordon>
but 18 minutes seems like lot
<Wizzup>
yes
<Wizzup>
I'
<Wizzup>
I'll see what I can do now
<Wizzup>
most of it is l10n packages
<Wizzup>
yeah, so it also deletes all the files upon s tart
<Wizzup>
let me see if I can do something clever with tmpfs or something
<freemangordon>
Wizzup: lemme just rebuild mce before that
<Wizzup>
sure
<Wizzup>
even on tmpfs it seems to take a while
<Wizzup>
1 minute or so
<Wizzup>
I can give the sw some more cores
<Wizzup>
or... we can just stop building it every time for beowulf and just assume the files there are stale :)
<Wizzup>
in a month or so I'll have a faster machine for these LXCs anyway
<Wizzup>
we could also not run pkgweb on every -repos job, which is kind of stupid
<Wizzup>
but yeah
<Wizzup>
there's a few problems here, I'll try to figure something out
<Wizzup>
the setup is now much more sane with a VM that is a LXC host, and virtiofsd is used to pass in files
<Wizzup>
but it's not really meant to rewrite 20000 files tiny every 5 seconds, then there's lots of overhead
hm has joined #maemo-leste
rhn_mk1 has joined #maemo-leste
<rhn_mk1>
hey, is there a deb repo with all the packages?
pere has joined #maemo-leste
<sicelo>
rhn_mk1: yes, but what do you mean exactly?
<rhn_mk1>
I want to install openmediaplayer on regular debian and I don't want to build everything from sources
<rhn_mk1>
but I can't find the deb line to put in sources.list
<rhn_mk1>
can't find a devuan image for podman either :/
<Wizzup>
openmediaplayer will probably depend on some hildon pkgs
<Wizzup>
the deb line you can take from any maemo image
<Wizzup>
(also, some idiotic LLM is scraping our pkgweb again)
<Wizzup>
pretending to be a browser of course
<rhn_mk1>
downloading images is raher inconvenient on my unstable internet connection :/
<rhn_mk1>
I was hoping to find the line somewhere around
<Wizzup>
I can boot up my VM in a bit and try it out
<Wizzup>
and send you the line
<rhn_mk1>
that would be beyond cool
<Wizzup>
are you on 2g or something?
<rhn_mk1>
just weak wifi
<sicelo>
openmediaplayer on debian? you're asking for trouble ... will end up using a lot of bandwidth anyway
<sicelo>
which debian exactly?
<rhn_mk1>
sicelo: why trouble?
<rhn_mk1>
PureOS
<Wizzup>
yes, it will depend on many other maemo packages
<rhn_mk1>
maybe I'll have to go down the container route then
<sicelo>
PureOS itself is a bit far from debian to begin with
<rhn_mk1>
only the desktop
<Wizzup>
what's the goal, to play music on pureos using maemo's openmediaplayer?
<sicelo>
why do you need/want this?
<freemangordon>
Wizzup: shall I rebuild upower/mce for stable?
<rhn_mk1>
what Wizzup said
<Wizzup>
freemangordon: sounds good
<rhn_mk1>
my N900 has a broken headphone port and this is the next best thing
<freemangordon>
rhn_mk1: won't work, OMP is just an UI
<rhn_mk1>
oh, what is it talking to?
<freemangordon>
you need the backend as well
<freemangordon>
MAFW
<sicelo>
so you have librem5? (hence PureOS)?
<rhn_mk1>
yeap
<sicelo>
I'd say just use any player that's in PureOS. we are working on Librem5 port, and can ping you as we make progress on that
<rhn_mk1>
I haven't found anything in PureOS that wouldn't suck
<rhn_mk1>
I'll keep an eye on the progress though
<sicelo>
knowing there are potential Librem5 users for Leste is encouraging me to get it done faster :-)
<rhn_mk1>
what are the challenges remaining?
<sicelo>
lately it has mostly been lack of time
<rhn_mk1>
I can relate to that
<sicelo>
BTW PureOS is based on which debian version?
<rhn_mk1>
bullseye
<rhn_mk1>
there's a bookworm version in development
<rhn_mk1>
maybe someone here knows if I can force N900 to output audio on the headphones? I think what's broken on mine is presence detection
<sicelo>
running Fremantle, or Leste?
<rhn_mk1>
Fremantle
<rhn_mk1>
if it can be done on Leste, that might motivate me to switch
<rhn_mk1>
(not like I wasn't planning to, but that would be a stronger motivation)
hm has quit [Remote host closed the connection]
hm has joined #maemo-leste
<freemangordon>
Wizzup: why is maemo-system-services iioproxy init script patch not in -stable?
<Wizzup>
I think it should be now
<Wizzup>
rhn_mk1: you probably can @ force
<rhn_mk1>
Wizzup: any idea how? my alsa-fu is not strong enough, and I don't know where it might be in the kernel
<Wizzup>
no, I don't know enough about it but I know that we have a headset ucm and the alsamixer has like 1000 settings
akossh has quit [Ping timeout: 244 seconds]
apac has quit [Ping timeout: 240 seconds]
<freemangordon>
Wizzup: ok, will pull it
<freemangordon>
Wizzup: I'll try to fix all the hildon-meta (-core) mess
apac has joined #maemo-leste
<freemangordon>
Wizzup: sicelo: so, for hildon-meta and hildon-meta-core - do not work on master branch until we move to excalibur, used daedalus/daedalus-devel instead
<Wizzup>
freemangordon: any reason we can't apply this also to daedalus?
apac has quit [Ping timeout: 276 seconds]
akossh has joined #maemo-leste
Daanct12 is now known as Danct12
<freemangordon>
Wizzup: sorry, can't parse, what is 'this' that we can't apply?
<freemangordon>
Wizzup: so, the above note ( do not work on master branch until we move to excalibur, used daedalus/daedalus-devel instead) is valid for hildon-meta only
<freemangordon>
hildon-meta-core should be fixed now, going to make a release
<Wizzup>
freemangordon: ok, but why do we not use master?
<Wizzup>
what changed?
<freemangordon>
because you used master for excalibur :)
<freemangordon>
so, 2.16.x is daedalus
<freemangordon>
2.17.x is (will be) excalibur
<freemangordon>
or, we shall force-push daedalus hildon-meta to master
<freemangordon>
IIRC you made daedalus 2.13.1 and used 2.16 for excalibur
<sicelo>
it has been tested extensively by myself, and, i believe, arno11
<freemangordon>
sicelo: ugh, sorry, missed that pr
<sicelo>
no worries :-)
<freemangordon>
sicelo: why the rename connmgr->connection?
<freemangordon>
also, why cell_connection_status_cb has error parameter removed?
<freemangordon>
ok, I will revirew
<arno11>
rhn_mk1: if your problem is just presence detection, you can easely force headphone using alsamixer in both fremantle and leste: search for Jack Function and select headphone
<sicelo>
because connui_cell_connmgr_status_register does not exist, instead it's connui_cell_connection_status_register, etc.
apac has quit [Remote host closed the connection]
<freemangordon>
hmm, ok, I see
<freemangordon>
ut then it is the header that shall be fixed
<freemangordon>
*but
<freemangordon>
ok, I'll fix that
<sicelo>
i forgot now, but i seem to have felt "connection" was actually better than "connmgr" for that
* sicelo
rechecks the code
<freemangordon>
yeah, the other functions are like that
<freemangordon>
so it is a proper change
<sicelo>
ok
<freemangordon>
I think there is one issue (the removal of error), but let me see
<freemangordon>
hmm, no, it is ok
<rhn_mk1>
arno11: thanks for the hint. It doesn't seem to work, unless I need to boost some volume somewhere
<sicelo>
fremantle might not easily allow messing with alsamixer ... i.e. you can, but something might reset the state to what maemo wants/sets
<rhn_mk1>
the setting stays, so I probably need to whip out the soldering iron
<sicelo>
soldering iron? :-)
<rhn_mk1>
or a hot air station
<rhn_mk1>
under the assumption that the port is physically busted
<sicelo>
you would just need a new socket. no soldering
<rhn_mk1>
wait, no soldering how? isn't that socket soldered on the board?
<sicelo>
it's not
<rhn_mk1>
okay why have I never noticed this
<sicelo>
how would you have?
<rhn_mk1>
I opened the N900 multiple times :P
<rhn_mk1>
replacing is my first choice for this problem now and I have you to thank for that
arno11 has quit [Quit: arno11]
<sicelo>
with some luck, maybe you don't need to replace ... maybe just need to extend the 'feet'
<rhn_mk1>
oh, it's one of those things with spring pads that hold on to the chassis
lel has quit [Read error: Connection reset by peer]
<sicelo>
freemangordon: while you're here ... we need to do something about the wireless isse
<sicelo>
*issue
lel has joined #maemo-leste
<freemangordon>
lemme first finish with ofono CM bearer in qmi
<sicelo>
since installing the image a day or two ago (for mkf's issue), now i'm back to the indefinitely blinking wifi icon, and broken auto-connect. so i'd push for https://git.maemo.org/leste/libicd-network-wpasupplicant/pulls/3 to also go into stable. but i don't want to be selfish, since it seems to cause issues for Wizzup
<sicelo>
sure, :-)
<freemangordon>
well, maybe ask Wizzup to check the issues
<freemangordon>
what am I supposed to do?
<sicelo>
maybe run the updated version (with my change) and see if it regresses for you as well
<freemangordon>
but why, if it already has issues on Wizzup's device, to me it makes sense he to check what's going on, not to say that he is the author of the plugin
<sicelo>
gotcha
<sicelo>
uvos: btw, do you recall why only Droid 4 was switched to libinput, and not N900? the commit description doesn't explain, and i'm not sure i can see any special reason for this
<Wizzup>
freemangordon: ok, now pkgweb shouldn't take too much time any more
<Wizzup>
On the wifi issue, I don't remember the specific but I think I shared them with sicelo
<Wizzup>
I think I have seen two things: initially the code would not recognize it lost the wifi and it kept trying, which I think was your code freemangordon
<Wizzup>
then sicelo wrote some code to detect this, but his code brought back the dreaded almost instant wifi assoc fails
<Wizzup>
Those are (as usual) paired with dmesg problems
<Wizzup>
And the problem really is in the kernel/wpa_supplicant, not with our software
<Wizzup>
So we're trying to set up some workarounds around this problem, but sicelo's workaround brings back my problem
<Wizzup>
I would maybe suggest to set up some time after which we accept the assoc fails - but not in the 15 seconds say
<Wizzup>
freemangordon: so avg pkgweb runtime should be ~4s
<freemangordon>
so, if we are connected and receive "disconnected" then we error out
<freemangordon>
but, if we are connecting and receive "disconnected" the we shall ignore it, and wait for either connected ot timeout
<freemangordon>
Wizzup: correct? ^^^
<sicelo>
right, but in practice, if we are connected, then disconnected, the UI keeps thinking we're connected, so the status menu item still shows the old network name, and new connections do not happen, until you manually disconnect from the zombie connection. the wlan icon itself keeps blinking forever
<freemangordon>
not here at least
<sicelo>
the issue might be that ctx->state == STATE_CONNECTED is probably not getting reset at the right time?
<freemangordon>
why reset?
<Wizzup>
freemangordon: might be @ correct, sorry, I don't really remember :)
<sicelo>
i mean, when we lose the connection (due to going out of range), ctx->state should indicate that we are no longer connected
<freemangordon>
sicelo: can you enable traces in icd plugin and gather some logs?
<sicelo>
but the UI behavior indicates that this doesn't happen
<sicelo>
i'll give that a go again
<sicelo>
(but not right now) :-)
<freemangordon>
please revert your patch, at it is clearly not the proper one
<freemangordon>
sure, I have no time now too
<sicelo>
i am back on your patch (because mine's not in stable). while everything was working nicely the past few weeks, now i'm back to issues :p
<sicelo>
ultimately i guess we probably need to look at kernel or elsewhere as Wizzup says
<freemangordon>
well, just gather logs that are detailed enough to see the sequence of events
<sicelo>
of course i recall uvos said there was no problem with NetworkManager, so yeah.
<freemangordon>
I would prefer to fix our plugin, it should not be a rocket science to propery implenet a timeout
<freemangordon>
*implement
<sicelo>
quick reminder on how to get logs from the icd plugin please