mrkrisprolls has quit [Remote host closed the connection]
k1r1t0 has quit [Ping timeout: 260 seconds]
mrkrisprolls has joined #maemo-leste
joerg has quit [Ping timeout: 272 seconds]
joerg has joined #maemo-leste
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 246 seconds]
<SuperMarioSF>
just found some bug in hildon-application-manager
<SuperMarioSF>
Attempt install any application from it and you got a crash.
<SuperMarioSF>
stdout/stderr says: ***invalid %N$ use detected***
<SuperMarioSF>
just searched the code and nothing related found. maybe this message is from another library rather than the application manager itself?
<SuperMarioSF>
btw the crash ended with Abort signal, so it was being caught by something and just aborted.
rafael2k__ has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 260 seconds]
<sicelo>
you're on which release? stable, -devel, or chimaera?
Twig has joined #maemo-leste
rafael2k__ is now known as rafael2k
<sicelo>
getting touchscreen issues when receiving a phone call is a consistent occurrence on my droid 4
<sicelo>
am i the only one experiencing this?
<sicelo>
is it a race between tklock and sphone?
pere has quit [Ping timeout: 256 seconds]
<norayr>
i am having touch issues while or after charging. don't use calls, cannot tell
<norayr>
z
<sicelo>
on droid 4? i think that's related to static or something like that
<sicelo>
capacitive touch blues - it happens even on other phones tbh
<sicelo>
(the erratic touch when charging ...)
pere has joined #maemo-leste
akossh has joined #maemo-leste
xmn has quit [Ping timeout: 246 seconds]
xmn has joined #maemo-leste
k1r1t0 has joined #maemo-leste
<SuperMarioSF>
sicelo, I'm on -devel, but this issue also on release as well.
<SuperMarioSF>
device is droid4
<SuperMarioSF>
btw the touchscreen issue is just a widely affected issue, even to this day for some devices.
<SuperMarioSF>
usually caused by bad charger design and not-so-good touchscreen designs back in the old days.
<SuperMarioSF>
Especially when you using wall power.
<SuperMarioSF>
I use power bank for droid4 almost for all the time, and never had this kind of problem, until I connected to some not-well designed charging station, woah that went crazy.
xmn has quit [Ping timeout: 268 seconds]
<SuperMarioSF>
Wizzup, I tested about the CHN-UNICOM APN auto-provisioning problem.
<SuperMarioSF>
It seems even roaming from another provider in another region are also affected.
<sicelo>
yes @charger. because c-ts depend onthe relative charge between your finger and itself, anything that can alter the charge also affects the screen. i've seen windows move just by passing heaphone cables nearby
<SuperMarioSF>
I have a special eSIM in a real SIM adaptor card, download and activated that and verified with another phone that is working, and inserted into droid4
<SuperMarioSF>
good 3G signal, no APN provisioned at all.
<SuperMarioSF>
and it was working in Android side with no problem.
<SuperMarioSF>
btw the eSIM card I have is from esim.me, the only limitation for this card to work is configuring multiple eSIM profile on this card, you can only manage via Android App for the card. It had different one for Apple devides I guess.
<SuperMarioSF>
Once you enabled a profile via App, you can basically insert the card into any phone and use that profile no problem, the only problem is you have to insert into a Android phone to configure it again.
<SuperMarioSF>
So it works like a normal SIM card in any phone.
<Wizzup>
I think if we don't know the provider, it might not provision well
<Wizzup>
I don't know what the current fallback solution is here
<SuperMarioSF>
I guess the auto-provisioning problem is related to China Unicom itself, maybe it did something cause the droid4 leste unable to provision APNs properly.
<SuperMarioSF>
so... what provider?
<SuperMarioSF>
oh I have a idea
<SuperMarioSF>
I have a N900 with stock firmware
<SuperMarioSF>
Let me test that
<sicelo>
Wizzup: i think we also should just support manually adding an APN
<Wizzup>
sicelo: yes, we should
<Wizzup>
it might make sense to file a bug for this
<Wizzup>
someone is writing an actual user handbook now, and these are things we could cover in it too
<SuperMarioSF>
btw China Unicom itself works well on stock firmware of N900, I tested that early.
<SuperMarioSF>
just don't know what will appear if I instert my eSIM into it.
<sicelo>
eSIM on the N900? insert it so we find out :-)
<SuperMarioSF>
I have tested a disfunct SIM card which is a virtual-ISP, and itself provisioned successfully, however it was registered to China Mobile, which doesn't have WCDMA support at all.
<sicelo>
nice
<SuperMarioSF>
currently my eSIM have only one profile, it is from 3HK, an operator from Hong Kong.
<sicelo>
tbh, i am not sure we have that kind of thing in Leste (or any other mobile distro) ... the OTA stuff
<SuperMarioSF>
oh
<SuperMarioSF>
no worries
<sicelo>
it's my uninformed guess. take it with a grain of salt
<SuperMarioSF>
i guess eSIM have a much different OTA kind stuff.
<SuperMarioSF>
just guessing
<SuperMarioSF>
my eSIM.me card can have up to 15 profiles stored.
<SuperMarioSF>
and that is expensive, for card itself.
<norayr>
esim is good for privacy i guess?
<norayr>
i can get a esim online and use for internet in my country, and carriers in my country won't know who am i?
<sicelo>
heh, no (unless i am wrong too)
<sicelo>
it's mainly just to make phones thinner/smaller
<norayr>
i mean if i get esim in other country
<sicelo>
each removable thing (sd card, sim) needs a lot of space in a phone for the receptacle. if everything is built into the phone, it can take up less space, allowing for other fancy stuff to be added
<sicelo>
norayr: you'll have to register that esim somewhere ... it's just a sim - the networks themselves aren't changing
pere has quit [Ping timeout: 256 seconds]
uvos has joined #maemo-leste
<uvos>
more importantly, if you design a pcb you will quickly discover that connectors and slots are surprisingly expensive and will quickly add up to be a significant part of you bom
pere has joined #maemo-leste
<SuperMarioSF>
eSIM can load operator's profile in another country/region, but the local operator will still know your IMEI, your network registration info (ICCID for example) and the peering roaming operator, for whole system to work.
<SuperMarioSF>
they may or may not have your networking traffic depends on how they implement the roaming protocols.
<SuperMarioSF>
usually your network traffic will have a VPN tunnel directing your traffic to your eSIM's operator, but local operator may have chance to peek into.
<SuperMarioSF>
However if they leaked any amount of sign of they are listening in your data without your consent, they will have a big trouble. Even operator in China, which is state-operated, won't do this kind of thing.
<SuperMarioSF>
OK, eSIM insterted to stock firmware N900, let's see what will happen next.
<SuperMarioSF>
let me do second reboot to skip initial setup (for disconnected battery once)
<SuperMarioSF>
Well
<SuperMarioSF>
Stock firmware auto-provisioned APN correctly, even with its correct name.
<bencoh>
:)
<SuperMarioSF>
Expecting "3" as its APN name, because that is the operator's name, it is 3HK, and APN name is just "3".
<SuperMarioSF>
the local operator is China Unicom (shown in stock firmware of N900 as CHN-UNICOM, which is the same if I inserted a China Unicom SIM into it)
<SuperMarioSF>
and it only shown the local operator's name (CHN-UNICOM)
<SuperMarioSF>
this behavior is same when insterted into leste droid4.
arno11 has joined #maemo-leste
<SuperMarioSF>
but no APN will be correctly provisioned in leste droid4 for either 3HK eSIM or China Unicom SIM
<SuperMarioSF>
so at least there is some uniformity
<bencoh>
maybe ofono isn't looking for right info
<SuperMarioSF>
so is there anything I can looking into?
<SuperMarioSF>
I have plenty time today so I can help for debugging the issue.
<SuperMarioSF>
and I have both eSIM and a normal SIM with 2 droid4 available at once.
<SuperMarioSF>
they can both have SSH connection if anyone want to dig deeper.
<SuperMarioSF>
here is the one with eSIM : ssh ro-CeqU5HstCNechqcdMcDAe8PTH@sgp1.tmate.io
<sicelo>
but i somehow got provisioned for my previous sim in Leste :-/
<sicelo>
freemangordon: Wizzup: https://paste.debian.net/1267798/ here's my log. this is 653-01. i can manually connect to internet using ofono scripts. unable to provision in icd2 so far ..
<bencoh>
apparently devuan changed the repository structure (?) at some point, meaning that one has to change the /etc/apt/sources.list file before using apt
<bencoh>
(or should?)
<bencoh>
but I think that it should work overall
<Wizzup>
great
<bencoh>
regarding the rootfs I uploaded, the leste meta (?) package installed resolvconf, but since the relevant files aren't properly populated (it's not a fullblown leste system afterall, at least it's not configured as such), /etc/resolv.conf points to a nonexistant /run/ file
<bencoh>
I never really looked into resolvconf, so I dunno how to fix it quickly (apart from just overriding /etc/resolv.conf with something custom)
<bencoh>
apparently using a 32b qemu would fix it, I haven't tried
<bencoh>
anyway, it affects readdir() for armhf binaries running inside the container, it should be fine for most devbuild use, but it means it can't be used as-is in production (ie package buildbots)
<Wizzup>
oh yeah we know about this one I think :)
<Wizzup>
this also hit the image-builder
<bencoh>
oh
<Wizzup>
dsc: maemo-translate runs locally here :)
<Wizzup>
dsc_: ah no, I do get the bus error
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
asriel has joined #maemo-leste
<dsc_>
Wizzup: :D
SuperMarioSF_ has joined #maemo-leste
SuperMarioSF has quit [Ping timeout: 246 seconds]
<Wizzup>
freemangordon: ping, what's a good package to test -mthumb -mfpu=neon with
<Wizzup>
freemangordon: and do we want to test this in a separate section/repo? maybe only for chimaera-experimental or something?
<rafael2k>
btw, do we have chimaera-devel or chimaera-experimental already?
<Wizzup>
rafael2k: we do have it, but they're empty, but they should work
<Wizzup>
so if you make a maemo/chimaera-devel branch, it'll go in there
<Wizzup>
at least it should
<Wizzup>
our *new* idea is:
<Wizzup>
actually
<Wizzup>
we have
<Wizzup>
sorry
<Wizzup>
rafael2k: so we have:
<Wizzup>
'chimaera',
<Wizzup>
'chimaera-devel',
<Wizzup>
'chimaera-experimental',
<Wizzup>
'chimaera-testing',
<Wizzup>
chimaera is obvious
<rafael2k>
cool! lots of repos!
<Wizzup>
chimaera-testing <- for users who just want some testing stuff but not break their device
<Wizzup>
chimaera-devel <- for us to test new sw releases
<Wizzup>
chimaera-experimental <- omg crazy kernel might brick everything and eat data
<rafael2k>
so most likely I'll use chimaera and chimaera-devel (especially for new major kernel releases)
<Wizzup>
well the idea is to also use chimaera-testing, but that depends on our testing audience :)
<rafael2k>
right, lemme think about it then
<rafael2k>
I know very well testing from debian...
<rafael2k>
btw lets put pinhole to chimaera
<rafael2k>
piggz said he will solve that white bar showing up in Maemo
<rafael2k>
he said is a kirigami issue
<rafael2k>
(in SF silica this is not happening, looking in the screenshots)
<Wizzup>
rafael2k: I was planning to clarify this more upon release
<Wizzup>
but I imagined regular flow to be: devel -> testing -> stable
<Wizzup>
rafael2k: but then of course -more regular- than currently with beowulf-devel
<Wizzup>
rafael2k: I could make a web if for getting the current diff between them
<Wizzup>
rafael2k: I have a python tool for it, we could turn that into a web page