<_uvos_>
this is currently missing, therefore this hack
<Wizzup>
_uvos_: ok, but for telepathy-ring this is fine
<Wizzup>
since it's also just line numbers
<_uvos_>
sure you can add ring
<_uvos_>
but do not remove the check
_uvos__ has joined #maemo-leste
<Wizzup>
hm
<Wizzup>
well we first need to figure out how to really name the tp backends
<Wizzup>
I can give the ring one a special name, but there might be eventually one tp-ring per sim
<Wizzup>
currently it's a dbus object path
<Wizzup>
for example: /org/freedesktop/Telepathy/Account/ring/tel/account0
<Wizzup>
I'll implement hold tomorrow, maybe see if I can find someone to test multi party on
_uvos_ has quit [Ping timeout: 252 seconds]
<Wizzup>
anyway I'm happy :D
<Wizzup>
btw, the n900 phone ui is basically:
<Wizzup>
[horizontal dialing pad button]
_uvos__ has quit [Ping timeout: 260 seconds]
<Wizzup>
[select contact]
<Wizzup>
[rtcom ui log]
<Wizzup>
and then the dialing pad is a nested window with:
<Wizzup>
[call type]
<Wizzup>
[text area for number]
<Wizzup>
dialing pad
<Wizzup>
this is pretty much the same elements the current gtk ui has, just sans the nested window and the rtcom ui
<xes>
Wizzup: hi
<Wizzup>
hi
<xes>
Wizzup: can we stop maedevu @ maemo infra?
<Wizzup>
yeah I think we migrated it half a year ago to my hw
<xes>
yep, i know, i mean.. there is nothing left there that is still in use
<Wizzup>
yeah, no, the dns we switched over a long time ago
<Wizzup>
so nothing should use it
<xes>
ok!
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
xmn_ has quit [Ping timeout: 256 seconds]
k1r1t0 has joined #maemo-leste
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
Twig has joined #maemo-leste
ceene has joined #maemo-leste
SuperMarioSF_ has quit [Remote host closed the connection]
SuperMarioSF has joined #maemo-leste
<SuperMarioSF>
inky: I'm using Hexchat on droid4.
Twig has quit [Remote host closed the connection]
<SuperMarioSF>
Wizzup: Okay, but where should I post that package request? bugtracker isn't a suitable place for this.
<SuperMarioSF>
btw, mscim is seems too old for nowdays, maybe port fcitx5 is more likely to work?
<SuperMarioSF>
ibus is out of question, because it was broken since 2016. never worked correctly on Chinese input.
pere has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
<SuperMarioSF>
btw, about supporting IRC in connui, please at least implement SASL authentication, or there will be some problem logging in to Libera.Chat on some strange IP address.
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
uvos__ has quit [Ping timeout: 256 seconds]
<SuperMarioSF>
well, Chromium is much better used with --force-device-scale-factor=1.0
<SuperMarioSF>
add CHROMIUM_FLAGS="--force-device-scale-factor=1.0" in /etc/profile (or new file in /etc/profile.d/chromium.sh) can do it every time without messing around .desktop files and MIME types
<SuperMarioSF>
and touch support is great
<SuperMarioSF>
much better than firefox does
<SuperMarioSF>
maybe the workaround of touchscreen on firefox can be used to solve the problem
<SuperMarioSF>
but I'm sticking on Chromium for now.
<norayr>
wow. in firefox i am using
<norayr>
MOZ_USE_XINPUT2=1 /usr/bin/firefox
<norayr>
but it became unusable on chimaera/droid. but good on pp.
<SuperMarioSF>
yes, I was using that env var on my other UMPCs
<norayr>
hexchat was a bit small for me i guess. i don't remember. or hard to configure on droid's small screen.
<SuperMarioSF>
it is diffcult or even unconfigurable on droid itself
<SuperMarioSF>
so you need some hack
<SuperMarioSF>
use X forwarding to forward hexchat on your desktop
<SuperMarioSF>
you only need this for initial configuration
<SuperMarioSF>
once you set up Librea.Chat and its SASL configuration, close it and launch it on droid, then you can use it normally.
<SuperMarioSF>
sometimes a bigger screen surely can help
<SuperMarioSF>
I suggest you do X forwarding with USB RNDIS, because you surely won't want a traffic intensive X forwarding on a laggy 2.4GHz WiFi.
<SuperMarioSF>
and I also suggest you use compression on SSH, it will be look like this
<SuperMarioSF>
ssh -YC user@192.168.42.2
<SuperMarioSF>
if your local X server isn't a Linux desktop one (for example, a X server program on Windows), you may do `xhost +` to allow all access (danger for a proper X server), then use `ssh -XC` instead.
<Wizzup>
SuperMarioSF: the bugtracker is fine for this imo
<SuperMarioSF>
OK
<SuperMarioSF>
the real problem is mail client
<SuperMarioSF>
I use Claws Mail, and it was diffcult to setup on Droid
<SuperMarioSF>
You have to setup IMAP in only one go, otherwise you have to remove the account entirely and do it again.
<SuperMarioSF>
becase some retry option is hidden in context menu, and I have no way to access the context menu by "right click" it.
<SuperMarioSF>
for some reason Chromium has a proper long-press context menu support.
<SuperMarioSF>
but for some GTK based application it isn't there. Maybe this is a window manager thing?
<SuperMarioSF>
btw I installed Trojita after, it is much easy to use and have HTML mail support.
<Wizzup>
11:20 < norayr> but it became unusable on chimaera/droid. but good on pp.
<Wizzup>
yes this is a firefox change
<Wizzup>
they do some dumb stuff now
<Wizzup>
SuperMarioSF: what's wrong with the default mail client
<SuperMarioSF>
I haven't seen a "default mail client" on my installation
<Wizzup>
try apt-get install modest
<Wizzup>
I think it's there in chimaera
<Wizzup>
(by default)
<SuperMarioSF>
I'm on droid right now...
<Wizzup>
SuperMarioSF: yep just apt-get install modest
<SuperMarioSF>
woah that's a lot package to install
<SuperMarioSF>
90% of them are locales btw
<SuperMarioSF>
well...
<SuperMarioSF>
I installed it
<SuperMarioSF>
but nothing happend
<SuperMarioSF>
no new application, nothing in settings.
<SuperMarioSF>
is a reboot required?
<Wizzup>
I don't think so
<Wizzup>
the application is called 'email'
<Wizzup>
in settings there is no applet for it
<SuperMarioSF>
there is no new application on application menu
<SuperMarioSF>
I know that should be called "email"
<Wizzup>
you can try to run it from terminal, but it should auto show up if the right package triggers run
<SuperMarioSF>
it can show up with 'modest -s'
<SuperMarioSF>
I'm rebooting
<SuperMarioSF>
OK after a reboot it shown up
<SuperMarioSF>
Seems worked correctly
<SuperMarioSF>
attempt open a link and got "Unsupported link type"
<SuperMarioSF>
because it's missing a "stock default browser"?
<SuperMarioSF>
opening in 3rd party email client have no problem tho
<Wizzup>
could be, don't know :)
<SuperMarioSF>
well, don't mind I post too many bug report on bugtracker [emoji::rofl]
<Wizzup>
please do :)
<freemangordon>
SuperMarioSF: the url support is not email client thingie though
<freemangordon>
but libhildonmime
<freemangordon>
basically, in terms of maemo, there is no default browser
<freemangordon>
we shall teach it to fallback to xdg
<freemangordon>
Wizzup: I am not sure they broke HW acceleration or COU rendering
<SuperMarioSF>
disabled hw accel, and it was a bit choopy
<freemangordon>
*CPU
<SuperMarioSF>
not that obvious tho
<Wizzup>
freemangordon: in any case that code is obviously wrong
<freemangordon>
right
<freemangordon>
SuperMarioSF: is that d4?
<SuperMarioSF>
yes, it is a d4, on -devel
<freemangordon>
ah, this is beowulf
<Wizzup>
freemangordon: and I see the exact error in their code
<Wizzup>
as in
<Wizzup>
record_error("GLX extension missing");
<Wizzup>
$ firefox-esr -P
<Wizzup>
[GFX1-]: glxtest: eglCreateContext returned an error
<Wizzup>
[GFX1-]: glxtest: GLX extension missing
<freemangordon>
so you are without GPU rendering no matter the setting
<freemangordon>
Wizzup: yeah, I know
<freemangordon>
and agree
<Wizzup>
freemangordon: ok, so clearly this code is active and a problem :P
<SuperMarioSF>
I guess enable hw accel did nothing
<freemangordon>
SuperMarioSF: right
<freemangordon>
we have fixes in chimaera that actually allow chromium to enable GPU rendering
<Wizzup>
freemangordon: uvos: I think we should decide if we release chimaera soon and just without elogind support initially, it is becoming more of a nuisance to support both IMO
<SuperMarioSF>
oh, about elogind
<SuperMarioSF>
I was attempt installing kleopatra
<freemangordon>
Wizzup: I have no enough expertise to decide
<freemangordon>
so up to you to decide
<Wizzup>
freemangordon: "it works", but many packages are not installable
<freemangordon>
I know
<Wizzup>
like blueman (the gtk3 bluetooth manager)
<freemangordon>
and gparted and whatnot
<SuperMarioSF>
and it had package dependency problem in elogind
<Wizzup>
I think it's not about expertise, it's about what we want to communicate to others :)
<SuperMarioSF>
on -devel droid
<freemangordon>
me PR?!?
<freemangordon>
:p
<Wizzup>
SuperMarioSF: yes, we also block elogind on beowulf, but there less pkgs depends on it
<Wizzup>
anything that directly depends on elogind is currently a no-no everywhere on leste
<Wizzup>
freemangordon: well we can look into allowing elogind to start without it negatively affecting the system, many apps don't truly depend on it running for example
<Wizzup>
that would be a stop gap I guess
<Wizzup>
either that or we go full tinydm session
<SuperMarioSF>
maybe elogind is just providing some session related thing for those apps
<SuperMarioSF>
for kleopatra it may because KDE related thing
<Wizzup>
it doesn't just 'provide' that, but it also 'provides' a broken experience, i.e. pressing the power button will shut down the phone with elogind installed
<Wizzup>
and it will also cause chimaera phones to get bricked a boot to a black screen
<freemangordon>
Wizzup: is it dbus service?
<Wizzup>
so there's a bunch of work to do there, and like I said there's two immediate ways forward
<Wizzup>
freemangordon: it's a systemd thing, so it's everything
<SuperMarioSF>
[emoji::rofl] Oh that is a broken one indeed
<Wizzup>
freemangordon: jokes aside, it seems to take over from consolekit and other similar login tracking programs
<Wizzup>
like, this is the thing that on servers will kill all your processes if you log out from ssh
<Wizzup>
no matter if you run them in screen or whatever
<freemangordon>
can't we just add Provides: elogind to one of our metas?
<freemangordon>
and call it a day?
<Wizzup>
lol, we could try, that's option (2)
<Wizzup>
option (1) was trying to make a elogind compatible session eventually
<Wizzup>
maybe it's not a bad short term "solution"
<freemangordon>
2 is not really an option
<freemangordon>
but a short-term workaraound
<freemangordon>
the only option is 1
<Wizzup>
right, we might be in for a whole bunch of brokenness down the line
<freemangordon>
but, in order to release
<SuperMarioSF>
provide a elogind package do absolutely nothing [emoji::rofl] the problem is what if elogind is actually being needed?
<Wizzup>
but I'll try it
<freemangordon>
right
<Wizzup>
SuperMarioSF: right
<freemangordon>
SuperMarioSF: I really don;t see how a package like gparted (or blueman) would require anything from alogind
<freemangordon>
it is like a cancer to me, this systemd ideology
<Wizzup>
the idea of tracking programs within a desktop session makes some sense to me, it's just too bad that gnome and everyone under the sun immediately depend on it
<Wizzup>
brb
<freemangordon>
sicelo: SuperMarioSF: the is a new ofono plugin in -devel repo, please upgrade
<freemangordon>
sicelo: I will appreciate if you test that new plugin from scratch, like reset iap/context/etc, including APN change
<freemangordon>
this pugin shall fix the APN change issue
<sicelo>
cool. in evening i can try
<freemangordon>
ok, thanks
<freemangordon>
Wizzup: I am not sure this commit is the reason for bad performance
<freemangordon>
but I cannot find the video that uvos posted on YT
<Wizzup>
freemangordon: well for sure firefox no longer uses gpu accel
<freemangordon>
I will wait for him top appear
<freemangordon>
I am not sure it ever used
<freemangordon>
because if you look at the commit, they changed from #define to a variable
<Wizzup>
freemangordon: well maybe it was wrong before then :)
<freemangordon>
mhm :)
<Wizzup>
but I know it used to work for sure
<freemangordon>
so, we have 2 issues
<freemangordon>
one is that gles never worked on armhf
<freemangordon>
the other being: unusable performance since some update
<freemangordon>
I think it was 6x->7x
<freemangordon>
but not sure
<freemangordon>
I think uvos has details
<freemangordon>
not saying gl detection shall not be fixed
<freemangordon>
just that I think it will not fix the performance issue
<Wizzup>
ok
<Wizzup>
maybe it will if they use the gpu sw render as 'hw accel' :)
<freemangordon>
ah
<freemangordon>
llvmpipe?
<freemangordon>
I think they blacklist that explicitly
<freemangordon>
but yeah
<freemangordon>
at least I recovered my bugzilla account :)
<freemangordon>
ttyl
<Wizzup>
for sure in 2021 there was no 'useGles'
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
xmn has joined #maemo-leste
rafael2k has joined #maemo-leste
<freemangordon>
Wizzup: going to bisect esr versions in debian repo
<bencoh>
freemangordon: yeah, I checked again after discussing with uvos, and firefox 78 worked decently (even though gl accel did not work), and it got unusable later
<freemangordon>
firefox-esr_78.15.0esr-1~deb10u1_armhf.deb scrolls like butter
<bencoh>
I know 78 is okay, and 93 is unusable
<freemangordon>
right
<freemangordon>
will check the next one
<bencoh>
I dunno if there is a next-one available in repos
<freemangordon>
so, who is going to parse vcf files?
<uvos__>
and only the evolution module may depend on evolution
<freemangordon>
if there is no evolution?
<uvos__>
no one is parsing vcf files
<freemangordon>
I see
<uvos__>
some other module that parses vcf fiels
<uvos__>
with no changes to the other modules
<uvos__>
the point is that the evolution module may be replaced
<uvos__>
thats the whole point of sphones architecture
<freemangordon>
I understand that, but what I don;t understand is how such a module (supporting some form of contacts import/export) is not mandatory
<uvos__>
this isent about contacts import or export
<Wizzup>
we can make it mandatory for us
<uvos__>
its about what fields to use to match a contact
<uvos__>
to a call
<uvos__>
and vice versa
<freemangordon>
I think we are rediscovering the hot water
<uvos__>
not really
<freemangordon>
everybody is using vcf
<freemangordon>
and you have UID tehre
<freemangordon>
*there
<Wizzup>
I think the way to see it is that sphone sees the concept of contacts as optional
<uvos__>
dutr
<uvos__>
sure
<uvos__>
but we get a call
<uvos__>
we only know the number or sip handle or whatsapp username or whatever from that call
<uvos__>
we need to figure out what contact this call is comeing from
<freemangordon>
Wizzup: I understand that, but that's some academic approach I am not sure is the best
<uvos__>
no uuids help us here
<uvos__>
we need to know what the backend the specific inceoming string iding the call
<uvos__>
corrisponds to in terms of contact fields
<freemangordon>
uvos__: if you assume that vcf UID is the common denominator for all plugins, then you can use it
<uvos__>
thats all
<uvos__>
no i can not
<uvos__>
its physicly impossible to get a cellular call
<uvos__>
and magicly get some id from that
<uvos__>
you only get a phone number
<uvos__>
from the modem
<freemangordon>
why? you can ask ads (or whatever backend) to give you the UID for that phone
<uvos__>
_thats_ where we are at
<freemangordon>
*eds
<uvos__>
yes
<Wizzup>
uvos__: unrelated, how do you hold and re-activate calls in sphone
<uvos__>
but sphone dosent know that the string its getting from a backend IS a phone number
<uvos__>
thats all this is about
<uvos__>
add ing a way the backend can tell sphone what the incoeming line id is
<freemangordon>
ok, maybe then sphone can provide an interface based on EVCard attributes (I hate to say it, but maybe duplicate those defines)
<uvos__>
Wizzup: well you press hold on a call
<Wizzup>
uvos__: like how does the hold trigger communicate if it should hold or release
<uvos__>
Wizzup: and then you press hold again to activate
<uvos__>
but it dosent work
<uvos__>
beacuse it dosent work on d4 ofono
<uvos__>
so no backend currently implements call holding
<uvos__>
so its also untested
<Wizzup>
the remove party can also put you on hold
<Wizzup>
remote*
<uvos__>
sure but holding just dosent work at all
<uvos__>
atm
<uvos__>
we dont get holding information form either end from ofono
<uvos__>
(ps if a backend did know the rmote party put us on hold it would just push that call down the pipe itself)
<uvos__>
freemangordon: yes thats exactly the plan
<freemangordon>
ugly, but yeah, might work
<Wizzup>
uvos__: what?
<uvos__>
freemangordon: and the eds module then uses that information to match the right contact
<uvos__>
and tell the rest of sphone about it
<uvos__>
Wizzup: [16:33] <freemangordon> ok, maybe then sphone can provide an interface based on EVCard attributes (I hate to say it, but maybe duplicate those defines)
<Wizzup>
uvos__: no, I mean, 'push that call down the pipe itself' ?
<Wizzup>
I can definitely detect hold of remote party in telepathy-ring
<Wizzup>
but I don't know how I put someone on hold since I don't see the button for it
<freemangordon>
uvos__: BTW, do you still have a link to that FF d4 video around?
<uvos__>
backend finds out call goes on hold
<Wizzup>
and the trigger only allows to put something on hold, it doesn't allow for killing the hold
<uvos__>
backend pushes that call down the hold pipe
<Wizzup>
yes, that's for the remote party
<Wizzup>
but you can also put the other side on hold yourself
<uvos__>
ui wants a hold
<uvos__>
ui pushes the call down the hold pipe
<uvos__>
its that simple
<Wizzup>
I don't need the hold pipe to push hold down the pipe, I can use &call_properties_changed_pipe for that
<Wizzup>
uvos__: ok, but as a user, how do I do that now?
<uvos__>
theres a hold button
<uvos__>
hmm maybe i hid it
<Wizzup>
ok, and where is the unhold?
<uvos__>
because it dosent work with ofono
<Wizzup>
since the hold trigger doesn't allow specifying hold:TRUE or hold:FALSE
<uvos__>
Wizzup: same button
<uvos__>
Wizzup: just changes its text
<Wizzup>
ok, but the backend doesn't know if you want to hold or not
<Wizzup>
I can store that info locally in the backend per call of course
<uvos__>
sure it dose
<uvos__>
yes the backend is expected to have a list of calls
<uvos__>
anyhow this holding thing is untested and maybe half implemented (dont remember)
<Wizzup>
I'd like to implement it
<uvos__>
since it dident work in ofono it stoped working on it
<Wizzup>
when was this?
<uvos__>
when i started working on sphone :P
<uvos__>
since you are the first backend to implement holding if it makes your code easier
<uvos__>
you can also add a new unhold pipe
<uvos__>
and just change to ui to call the right one depending on the state of the currently selected call
<uvos__>
in the active calls list
<Wizzup>
let's assume it works in ofono
<Wizzup>
I guess call->state can be used in the hold function
<Wizzup>
it just seems more clear to have an un-hold somehow
<freemangordon>
do you have a video with FF performing better? I want to add the link to the bug on bugzilla
<uvos__>
freemangordon: no
<uvos__>
but i mean it perfomes fine here
<uvos__>
ddk1.17 is only slightly better
<freemangordon>
ok
<freemangordon>
thanks
<Wizzup>
uvos__: I will try to submit a PR today for the comm-telepathy module
<Wizzup>
I'm sure you'll have some comments
<uvos__>
for one thing
<uvos__>
if your module is larger than one source file
<uvos__>
put it in a folder please
pere has quit [Ping timeout: 268 seconds]
<Wizzup>
ok
<Wizzup>
and for a hildonized gtk, another module?
<freemangordon>
wow, "Patches submitted 14" :)
<freemangordon>
when did I do that?
<Wizzup>
uvos__: btw for local testing with sphone the modules in another dir breaks the working of sphone
norayr has joined #maemo-leste
<Wizzup>
I had to make symlinks for modules in nested dirs
<uvos__>
Wizzup: what hildonized gtk?
<uvos__>
Wizzup: the current ui dose use some hildon functions (optionally)
<Wizzup>
ui module that makes it behave like maemo/fremantle
<Wizzup>
stacked windows
<Wizzup>
rtcom log
<uvos__>
the windows are stacked
<uvos__>
byw this is a problem
<uvos__>
as libhildon supports only one stack per process
<uvos__>
but sphone really needs 2
<uvos__>
and this causes some strange behavior
<bencoh>
debian/rules:236: *** Unfortunately cannot build on armhf. Try a 64-bits kernel. Stop.
<freemangordon>
what?
<bencoh>
that's when trying to build firefox from debian's git
<Wizzup>
uvos__: we only need main window with rtcom log, contacts, and dialer button, and dialer window on top of it, and on top of that the call window
<Wizzup>
the sms stuff will be handled by conversations with tp module
<bencoh>
either my builder borked the build system, or ... I'm missing something
Oksanaa has quit [Ping timeout: 260 seconds]
<uvos__>
Wizzup: thats nice that its handled by conversations
<freemangordon>
bencoh: maybe try apt-get source
<uvos__>
but that has no bearing on sphone
<bencoh>
freemangordon: yeah I'll try that
<Wizzup>
it does on sphone in leste :p
<uvos__>
and sphone must continue to support messages
<uvos__>
sure but you may not break it
<freemangordon>
I don;t think it is a good idea to have 2 sms apps active in parallel
<uvos__>
sphone is modular
<freemangordon>
so as soon as we have conversations, I think disabling sphone hildon module for sms makes sense
<uvos__>
you need not load those modules
<uvos__>
still you may not break them
<uvos__>
and the windows are stacked
<freemangordon>
so, what is the issue? how to show smsm while in a call?
<freemangordon>
*sms
<uvos__>
its just that the sms and dialer windows are stacked on top of eatch other
<uvos__>
because of hildon limitations
<uvos__>
so idk what wizzup wants to change
<freemangordon>
the main window, iiuc
<freemangordon>
a side question: how am I supposed to use MESA_EXTENSION_OVERRIDE?
<freemangordon>
MESA_EXTENSION_OVERRIDE="-EGL_CHROMIUM_sync_control" eglinfo still returns EGL_CHROMIUM_sync_control
<Wizzup>
uvos__: hence a new module
<Wizzup>
so then on leste we load what we want
<Wizzup>
and on non-leste it uses other modules
<uvos__>
im still not sure what you want
<uvos__>
make the recens dialog the main window?
<uvos__>
essetally?
<uvos__>
hard no, the dailer should be the first window
k1r1t0 has quit [Ping timeout: 246 seconds]
<Wizzup>
then we must fork...
<Wizzup>
we can just make a new ui module, seems easiest to me
<uvos__>
why would you want recents as the first window...
<uvos__>
even contacts would make more sense
<Wizzup>
it's what fremantle does, and it makes so much sense, I use it *all* the time
<Wizzup>
android does the same
<uvos__>
not really
<uvos__>
android has both one window
<uvos__>
wich is fine
<uvos__>
(and is incedentally how sphone used to work)
<Wizzup>
almost like a stacked window with a dialer button :P
<uvos__>
not really
<freemangordon>
uvos__: from UX POV, what is the idea of having a dialer on the first window?
<freemangordon>
how often you dial numbers, compared to redialing a contact or selecting a contact from a list
<uvos__>
you place a phone call you dial a number
<uvos__>
all the time
<freemangordon>
no
<freemangordon>
you dial a contact
<Wizzup>
I literally never do this unless it's some number I don't know
<uvos__>
when you missed a call it takes you straigt there
<uvos__>
so no change tehre
<freemangordon>
what if you have 3 missed calls?
<Wizzup>
no, only when you keep that window open
Oksanaa has joined #maemo-leste
<uvos__>
freemangordon: what then?
<uvos__>
recents is longer than 3 calls
<uvos__>
Wizzup: so?
<freemangordon>
yes, but you have everything ordered by time of the (missed) call
<uvos__>
so? not sure what you expect to happen when you click on a missed call
<uvos__>
it takes you to the call in the list
<uvos__>
thats all
<freemangordon>
uvos__: sure, we can do it so you are required to solve a puzlle to be able to call back, but that's not user friendly
<uvos__>
?
<uvos__>
you click on the missed call notification it takes you to the call in the lst
<freemangordon>
clicking on a missed call shall bring you to the selection of what you want to do:
<uvos__>
you click on that, it enters the number
<freemangordon>
no
<uvos__>
for you to then click call
<uvos__>
how is that a puzzle
<freemangordon>
no, you may not want to call back, but instead to do sms
<freemangordon>
or call back via sip
<freemangordon>
etc
<Wizzup>
yup
<bencoh>
on fremantle it just takes to you the recent calls list
<freemangordon>
right
<uvos__>
on sphone exactly the same
<Wizzup>
no, it takes you to dialer
<freemangordon>
but clicking on an entry in the recent calls does not bring the dialer
<freemangordon>
no
<uvos__>
Wizzup: no it dosent
<Wizzup>
the phone icon takes you to dialer
<uvos__>
clicking on the entry DOSE bring the dialer
<Wizzup>
this is silly
<freemangordon>
it asks what to do: call or sms
<uvos__>
where you can then choose the backend
* Wizzup
takes a break
<Wizzup>
we want our phone to be one icon
<freemangordon>
agree
<uvos__>
the only thing in sphone it is annoying to sms someone who you missed a call of
<uvos__>
but thats a easy fix
<freemangordon>
I don;t think it is that easy
<uvos__>
just add a way to message a entry in the recents list
<freemangordon>
if you don't integrate with addressbook
<bencoh>
basically on fremantle clicking a missing call entry brings up the contact card
<freemangordon>
exactly
pere has joined #maemo-leste
<sicelo>
freemangordon: libicd-network-ofono 1.1.0+2m7 ? looks like it still doesn't save apn in context
<freemangordon>
umm
<freemangordon>
did I forget to do something?
<sicelo>
perhaps :-)
<freemangordon>
ah, in th econtext
<freemangordon>
but at least it finds the correct context, no?
<freemangordon>
if you change the apn that is
<sicelo>
not sure i understand ... there's still one context
<sicelo>
which doesn't have apn
<freemangordon>
yes, but you edit from the settings
<freemangordon>
and enter some apn
<freemangordon>
this apn is not saved to context for some reason, but is set on iap, correct?
<sicelo>
yes. and this apn from settings doesn't make it to the ofono context. that one still has no apn
<freemangordon>
ok, that's another bug then :)
<freemangordon>
so, is it set on iap?
<sicelo>
yes it exists in iap
<freemangordon>
great
<freemangordon>
so I must have forgotten to set it to the context
<freemangordon>
ok, will fix that, thanks for reporting
<sicelo>
freemangordon: sorry if i wasn't clear before (some days ago) - i actually originally meant the apn doesn't get set on the ofono context itself
<sicelo>
great :-)
<freemangordon>
yes, but back then it was unable to find the contaxt when apn was changed, no?
<freemangordon>
and now it finds it, it is just that apn (and user/pwd perhaps in that regard) arte not set back
<freemangordon>
correct?
<sicelo>
i am not sure. let me explain
<freemangordon>
no need
<freemangordon>
I think I know what the issue is
<sicelo>
ah yes, correct. i misread
<freemangordon>
ok, great
<freemangordon>
hopefully tomorrow I will fix that
<sicelo>
thanks. no rush
* sicelo
has no time these days ... but can test, as long as it takes no more than 30 mins :-)
<rafael2k>
I was playing with whatsmeow... it is pretty easy to use
<rafael2k>
I just needed to get used to go
<rafael2k>
btw, for people in amd64, harbour-pinhole should work on any platform with proper camera drivers
<Wizzup>
rafael2k: we can try to use whatsmeow for tp, but if it requires whatsapp web it will always require some android or ios device
<Wizzup>
whatsapp/facebook will be forced to offer an api per new eu law
<Wizzup>
so we can wait that one out maybe
<bencoh>
yeah, whatsmeow's howto recommends using the android sdk emulator and passthrough a webcam
<bencoh>
which is nice but not enough
<sicelo>
Wizzup: really? what law is that?
<Wizzup>
sicelo: will need to look it up
<Wizzup>
it's the gatekeeper one
<Wizzup>
requiring interoperability
<Wizzup>
in car atm
<bencoh>
something tells me they'll still find a way to keep some kind of "auth" ("to prevent spam, of course")
<Wizzup>
we'll see
<Wizzup>
auth is ok
<Wizzup>
as long as it doesn't require nonfree crap
<Wizzup>
imo
<bencoh>
yeah, but ....
<bencoh>
well, we'll see :)
<SuperMarioSF_>
oops
<SuperMarioSF_>
I made a mistake
<SuperMarioSF_>
SIM card is not recognized after a battery swap
<SuperMarioSF_>
I don't know why
<SuperMarioSF_>
but I can sure SIM card itself is working correctly
<bencoh>
I failed building firefox from apt-get source as well btw, even after bypassing the armhf/arm64 thing, I still get a stupid python stacktrace and "Permission denied" at the end of the configure process
<bencoh>
Wizzup: you might want to try building on the arm64 boards
<SuperMarioSF_>
It's time for a big brain solution: I'm gonna use my another d4. I'm gonna transplant the working screen on my broken d4 to my another working d4
<bencoh>
uh
<SuperMarioSF_>
my another working d4 having a broken screen
<bencoh>
how would a battery swap affect the SIM module though?
<SuperMarioSF_>
I wonder that.
<SuperMarioSF_>
It doesn't even connected together.
<SuperMarioSF_>
maybe I used too much force lifting battery and breaked baseband somehow
<SuperMarioSF_>
this time I will be careful.
SuperMarioSF has joined #maemo-leste
<SuperMarioSF_>
well
<SuperMarioSF_>
I should make sure this phone actually works
SuperMarioSF has quit [Remote host closed the connection]
<SuperMarioSF_>
I have a different idea tho
<SuperMarioSF_>
maybe it is not baseband related
<SuperMarioSF_>
it may be because the Android side
<SuperMarioSF_>
it switched to CDMA mode
<SuperMarioSF_>
That the reason I can't get signal
<SuperMarioSF_>
Lemme check real quicl
<Wizzup>
bencoh: I can give you access to a honeycomb dev vm
<Wizzup>
I set one up for dsc the other day
<bencoh>
if it runs an armhf rootfs it might help
<bencoh>
well, assuming I understand how this build is supposed to work anyway
<bencoh>
I don't really understand how debian builds it
<bencoh>
(arm64 kernel host running an armhf debian rootfs, _maybe_)
<bencoh>
oh and, funnily enough they read /sys/devices/system/cpu/modalias for detection of kernel cputype, which happily returns x86 in our container
<bencoh>
or I could try building on my lepotato board here
<bencoh>
err, 2G ram won't cut it, nevermind
<SuperMarioSF_>
well
<SuperMarioSF_>
I fixed it
<SuperMarioSF_>
it was the problem on android side
<SuperMarioSF_>
I did a switch now SIM care is working.
<SuperMarioSF_>
lemme check leste side really quick
<SuperMarioSF_>
It's working perfectly now
<SuperMarioSF_>
however I still want a screen swap
<SuperMarioSF_>
so I will do it anyways
<SuperMarioSF_>
to be exact: it will be a shell swap, I will keep the mainboard intact
<Wizzup>
bencoh: yes armhf root
<bencoh>
Wizzup: sounds good then
<Wizzup>
bencoh: just a few mins, dm me ssh pubkey pls
<bencoh>
Wizzup: we can setup a native lxc container if you don't want to mess with the main rootfs
<Wizzup>
bencoh: up to you
rafael2k has quit [Ping timeout: 252 seconds]
rafael2k has joined #maemo-leste
<bencoh>
Wizzup: hmm apparently that board runs a v7l (armhf) kernel, not aarch64
<bencoh>
I'll try anyway
<Wizzup>
bencoh: you wanted aarch64?
<bencoh>
for kernel yeah
<bencoh>
but armhf rootfs
<bencoh>
anyway, we'll see if it builds
<bencoh>
I removed the check
<Wizzup>
bencoh: oh, it was just for kernel? I thought this was a firefox thing :D
<bencoh>
it's to build firefox
<bencoh>
but firefox buildsystem checks kernel arch
<bencoh>
(they say it's because 32b has limited process memory size)
<Wizzup>
we have lpae
<bencoh>
yeah ... well, we'll see, currently building
akossh has joined #maemo-leste
<Wizzup>
:)
SuperMarioSF has joined #maemo-leste
<SuperMarioSF>
hello from fixed d4
<SuperMarioSF>
battery and chassis replaced
SuperMarioSF has quit [Ping timeout: 260 seconds]
SuperMarioSF has joined #maemo-leste
SuperMarioSF has quit [Remote host closed the connection]
SuperMarioSF has joined #maemo-leste
SuperMarioSF has quit [Client Quit]
mro has joined #maemo-leste
<sicelo>
SuperMarioSF_: nice
<SuperMarioSF_>
here is a problem
<SuperMarioSF_>
it seems nowdays if a uncalibrated battery goes below 30% it will automatically shutdown, so can I just start calibration there?
* sicelo
long gave up about calibration on d4 ... i just charge whenever i get a chance
mro has quit [Remote host closed the connection]
<SuperMarioSF_>
nvm
<SuperMarioSF_>
I goes to android side
<SuperMarioSF_>
and it report battery at 4%
<Wizzup>
sicelo: but, freemangordon has charger patches no?
<SuperMarioSF_>
I'm waiting for it automatically shutodown
<SuperMarioSF_>
and I know what happend to my modem
<Wizzup>
ah?
<SuperMarioSF_>
it seems the LineageOS installed on this device cannot properly handle CDMA/GSM switching
<SuperMarioSF_>
once startup it stuck at some weird state, neither CDMA nor GSM
<SuperMarioSF_>
I switched to CDMA (NV mode) after while I can see a roaming icon, then it successfully entered CDMA mode.
<SuperMarioSF_>
Then switched to GSM mode (RUIM/SIM mode), and my SIM card finally show up.
<SuperMarioSF_>
For comparsion, the stock Motorola firmware handled this properly.
<SuperMarioSF_>
Once my SIM card show up, reboot into Leste, it will work correctly.
<SuperMarioSF_>
and every time LineageOS boot up, it will enter that weird state, so I need to switch it every time if I booted into Android.
mro has joined #maemo-leste
<Wizzup>
oh yes, this can happen
<bencoh>
Wizzup: g++: fatal error: Killed signal terminated program cc1plus
<bencoh>
:(
<bencoh>
I think it's a memory issue
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
<SuperMarioSF_>
weird
<SuperMarioSF_>
the battery at 1% and it keep running for at least 15min now
<SuperMarioSF_>
on android side
<SuperMarioSF_>
and battery voltage is all over the place
<SuperMarioSF_>
I guess they didn't get a real data from PMIC
<sicelo>
hehe, yes it's all black magic
<SuperMarioSF_>
I'm going to play some video to make the battery drain even more faster
<SuperMarioSF_>
ah
<SuperMarioSF_>
finally it shut down
* freemangordon
wonders what is wrong with usiing swap nowadays :)
<freemangordon>
bencoh: ^^^
<freemangordon>
Wizzup: going to post the requested info on bugzilla
<freemangordon>
about:config that is, from FF 78
<freemangordon>
unfortunately, gl rendering seems disabled to me
<SuperMarioSF_>
btw
<SuperMarioSF_>
found a issue
<SuperMarioSF_>
maybe related to libhildonmime
gliffy has joined #maemo-leste
<SuperMarioSF_>
I can't load any image in modest email client, even if I clicked download image button
<SuperMarioSF_>
all image shown broken
<SuperMarioSF_>
it is fine in another email client tho
<freemangordon>
yes, the same as with browser
<freemangordon>
there is not default image viewer
<freemangordon>
*no
<SuperMarioSF_>
I guess I will pile up many bugs these days. Now I have to go have some rest, I'm going have a trip 5hours later
<Wizzup>
SuperMarioSF_: great, yeah, please file them when you can
<gliffy>
I may have found a possible culprit for the choppines I mentioned earlier on the n900. The change between the image builds 20220123 and 20220206 that I think might cause it is the replacement of the package "ti-omap3-sgx" with various other packages. I haven't been able to confirm this though since xorg has failed to start every time I tried replacing the package or upgrading the rest of the system. Does anyone have any
<gliffy>
insight on the difference between "ti-omap3-sgx" and the packages that replace it?
<Wizzup>
Hm.. that would be going from ddx 1.9 to ddx 1.17 I think
<gliffy>
Could that be the reason?
<freemangordon>
yes
<freemangordon>
also, I think that on ddk 1.9 was using 16bpp
<freemangordon>
but not sure
<freemangordon>
gliffy: those are GPU driver blobs
<gliffy>
I see
<freemangordon>
we were forced to move omapfb->omapdrm
<freemangordon>
but, last time I checked it was not *that* bad
<sicelo>
mmm, one of the things i like with maemo seems to not be working in leste - that when you open an (hildon) internet-needing application, it automatically establishes a connection, or prompts for one. just tried "Send and Receive" in Modest while not connected. didn't get a prompt
<freemangordon>
that's weird, it should have worke
<freemangordon>
*worked
<rafael2k>
camera focus working! yay!
<bencoh>
neat
<freemangordon>
unless we didn;t compile it with correct libs
<freemangordon>
cool
<sicelo>
perhaps someone else can try, to rule out something being broken with my setup
<freemangordon>
lemme try here
<freemangordon>
hmm
<freemangordon>
'refresh' should open connect to dialog