<gnarface>
Smatkovi: installed some packages, set one extra variable... it was easy in devuan
<gnarface>
so my limited understand of it is, you basically just install the right cross-compiler packages and then set the CROSS_COMPILE environment variable to the right value to use them
<Smatkovi>
i see, thanks. i want to compile organicmaps from the source repo, but with all dependencies it's about 11GB in size
<Smatkovi>
so i thought i would compile it on the pc in virtualbox until i found out those images are amd64 images
<gnarface>
i've only really done it with kernels and u-boot, but 11GB sounds completely normal
<dsc_>
oh, topbar was fine, just no accounts active
<gnarface>
Smatkovi: alternately you could boot an armv7 VM in qemu and build it there, but it probably will still take up a lot of space
<Smatkovi>
that's a good idea gnarface
<Wizzup>
Smatkovi: yes, organicmaps is hard to compile, even just on amd64
System_Error has quit [Ping timeout: 264 seconds]
<Wizzup>
did you manage to build a recent version? I have one from the start of 2024 or so, working on amd64
<Smatkovi>
okay maybe i'll try with amd64 first
Juest has quit [Read error: Connection reset by peer]
ceene has quit [Ping timeout: 244 seconds]
Juest has joined #maemo-leste
_fab has quit [Quit: _fab]
System_Error has joined #maemo-leste
xinomilo has quit [Quit: Leaving]
_fab has joined #maemo-leste
joerg has quit [Quit: this shouldn't have happened... ever]
<dsc_>
could you enable the 'release' feature for this repo so I can upload a 1.4gb .zip: sanderfoobar/vm-image-gui-dev
<dsc_>
Wizzup: ^
joerg has joined #maemo-leste
joerg has quit [Read error: Connection reset by peer]
<dsc_>
it just bootstraps with the things I need (no apparmor / more packages / more swap, cpu/mem)
<dsc_>
no password SSH login :P
<sicelo>
ah :-)
<dsc_>
and run all Telepathy related things in debug by default + logs
xmn has quit [Quit: Leaving]
xmn has joined #maemo-leste
Pali has joined #maemo-leste
<Smatkovi>
i used libstdc++-11 and removed the u flag from "set -eo pipefail" in tools/unix/version.sh and now it compiled in the vm without errors
<Smatkovi>
i mean organicmaps
Smatkovi has quit [Quit: Leaving.]
<Wizzup>
smatkovi, that is great!
<Wizzup>
what version is this?
Smatkovi has joined #maemo-leste
Smatkovi has left #maemo-leste [#maemo-leste]
Smatkovi has joined #maemo-leste
<Smatkovi>
i don't know which version i just cloned the repo from the site you sent a few days ago
<Wizzup>
Smatkovi: can you share which?
Smatkovi has quit [Ping timeout: 272 seconds]
Smatkovi has joined #maemo-leste
pere has quit [Ping timeout: 244 seconds]
vectis_ has joined #maemo-leste
parazyd has quit [Ping timeout: 260 seconds]
parazyd has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
freemangordon: dbus activateing ofono wont help you
<uvos>
since it could be sphone rather than ring that wakes ofono or celluard or so
<uvos>
so it still could start before converstations/tp is ready
<Smatkovi>
i'm on 2g now, but is it enough that it is from the maemo-extras repo you shared?
<Smatkovi>
otherwise i can tell on friday the latest
<uvos>
also if you dbus activate ofono from ring who onlines the modem and how dose it know when
<uvos>
freemangordon: the only solution to use this i can se interface is how it worked before we had conversations and cellulard. In this case sphone did everything, it connected to ofono and then onlined it, ofc knowing that itself was ready to handle incomeing calls/sms on dbus
<uvos>
i would suspect that sfos works the same way
<uvos>
this was still ofc sligtly broken, as nothing handles missed events while sphone was restarting after update or had crashed or whatever
<sicelo>
sphone used to online the modem?
<uvos>
yes original pre maemo sphone onlined the modem
<uvos>
i removed that pretty early (while makeing ofono support a module) but it did
<sicelo>
right. i just never remember that happening on Leste, but as you say, it didn't really do so here
<uvos>
anyhow the only way i can see to use this interface semi correctly is to have one process handle everything
<uvos>
but then i have no idea why ofono bothers with the dbus interface intead of being a lib :P
<sicelo>
this issue would not be solved by being a lib though :-)
<uvos>
sure it would then you would force there to be only one client and ofono would always start with its client
<uvos>
since only one process can open the modem kernel interfaces
<uvos>
only one process gets to use the ofono lib to online the modem :P
<Smatkovi>
but i have to say i compiled the amd64 version, so i will have to try crosscompiling
<sicelo>
mmm, 3G data works for anyone (droid4)?
<uvos>
not since it was shut of in germany
<uvos>
but it did work before that
<sicelo>
at least when i select it from the dialog, there's no activity on ofono's (d)bus
<uvos>
i dont think i ever set the tech preferance
<uvos>
it was just on auto by default and it did choose 3g while that was still available
<uvos>
so could be that the ui for that never worked
<sicelo>
s/3g data/mobile data/
<uvos>
oh
<uvos>
yeah that worked too f
<uvos>
for sure
<uvos>
but i think while there still was 3g in ger we where still at the state of seting that up manually
<uvos>
so could be that that never worked via icd
<Smatkovi>
https>//git.maemo.org/leste-extras/organicmaps was the repo i used
<sicelo>
it has worked. let me try with raw dbus calls
<sicelo>
mmm, not working with direct calls to ofono either. freemangordon or Wizzup , does it work for you?
<Wizzup>
@smatkovi, yes, that repo does work for amd64, but it's 1-2 years out of date I think
<Wizzup>
19:13 < uvos> freemangordon: dbus activateing ofono wont help you
<Wizzup>
19:13 < uvos> since it could be sphone rather than ring that wakes ofono or celluard or so
<Wizzup>
19:14 < uvos> so it still could start before converstations/tp is ready
<Wizzup>
it's not about activating ofono, it's about setting the modem to online
<Wizzup>
it's pretty simple, don't online the modem in cellulard until we are ready
<uvos>
right, onlineing the modem after sphone and converstaions singal ready (somehow) would mostly hide the issue
<Wizzup>
we get to decide what signal that is: tp-ring being on dbus, h-d ready signal, whatever
<Wizzup>
it wouldn't hide the issue, it would make things work as intended :p
<Wizzup>
yeah, right, ok, I didn't think about conversations and sphone as well
<Wizzup>
but we control when we start those (in xsession)
<Wizzup>
so that's easier than tp-ring autostart
<Wizzup>
but if we assume that conversations causes tp-ring to start, we're mostly there I guess
<uvos>
i say hide as i mean the fact that a call or sms can get permanently lost is not great
<uvos>
the issue here is also that ofono acks the incoemeing signal from the operator
<uvos>
with ensureing that something handled the event
<uvos>
if it dident the operator would try again later
<uvos>
that includes even incomeing emergency messages
<uvos>
so a crash of ofonos client can cause lost messages
<uvos>
while in a well implemented stack that dosent need to be possible
<uvos>
*with out ensureing that something handled the event
<sicelo>
yes, i think we're all in agreement that ofono is at fault for not implementing a cache (or similar) for messages until it is sure they have been processed
Livio has joined #maemo-leste
udder has joined #maemo-leste
SovietPony has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
apac has joined #maemo-leste
akossh has joined #maemo-leste
<Wizzup>
I mean it seems like a design decision but yeah
<Wizzup>
ofono is kind of real time I suppose: they want to react quickly
_fab has quit [Quit: _fab]
arno11 has joined #maemo-leste
xmn has quit [Ping timeout: 268 seconds]
akossh has quit [Ping timeout: 272 seconds]
Twig has quit [Remote host closed the connection]
<arno11>
indeed, conversations seems to cause tp-ring to start. at least that's what i see on my n900
<arno11>
and it happens very late, like at the end of h-d loading
<sicelo>
arno11: i believe 2G/3G is still working on your N900?
<arno11>
yes working fine
<sicelo>
sorry, meant gprs
<arno11>
gprs is ok as well
<arno11>
at least the last time i tried
Smatkovi has left #maemo-leste [#maemo-leste]
<sicelo>
ah, another SIM works ... so something's up with my first sim. will investigate on N900
<arno11>
(will check gprs now)
arno11 has quit [Quit: leaving]
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
sicelo: yeah gprs ok, currently using it :P
<sicelo>
yeah, it was on the Droid 4 where i wasn't sure, but have found that a different SIM does work
<arno11>
ah ok
<arno11>
currently testing telegram in 2g
<arno11>
*gprs
<arno11>
works fine
<arno11>
funny that a so old network is usable with modern messaging
vectis_ has quit [Ping timeout: 268 seconds]
Livio has quit [Quit: leaving]
<Wizzup>
I did a call test on the pinephone daedalus and it works
<Wizzup>
cool
<arno11>
nice
apac has quit [Ping timeout: 265 seconds]
arno11 has quit [Quit: leaving]
Pali has quit [Quit: Pali]
uvos has quit [Quit: Konversation terminated!]
<Wizzup>
arno11: I am going to remove the n900 specific fstab from image builder and see how things go
<Wizzup>
I think the postbuild() step would still override the fstab file, so we can either run leste-config configure step again at the end, or... not sure :)