Daanct12 has quit [Remote host closed the connection]
mrgeanie has joined #maemo-leste
Daanct12 has joined #maemo-leste
<buZz>
Daanct12: wat should fn+sym do?
<buZz>
what*
<Daanct12>
Opens up a symbol board for additional chars that do not exist on kb
<buZz>
oh, dont think i ever saw that
<buZz>
eh duh, droid4 has no fn :P
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #maemo-leste
ruleh has quit [Quit: Client closed]
Daanct12 has quit [Ping timeout: 252 seconds]
Daanct12 has joined #maemo-leste
reallll has joined #maemo-leste
belcher_ has quit [Ping timeout: 272 seconds]
diejuse has quit [Quit: Leaving.]
Daanct12 has quit [Ping timeout: 244 seconds]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Changing host]
Daanct12 has joined #maemo-leste
joerg has quit [Killed (copper.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
<parazyd>
Wizzup: We tested qemu-user a few times, and I already told you what happened in Devuan when we were using qemu-user
<parazyd>
Wizzup: So I'm strongly against moving to qemu-user (and qemu-system for that fact) rather than native package builds
<parazyd>
It's not just about gcc, but rather the entire pbuilder/apt setup which is simply too slow when emulated.
Daanct12 has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
Daanct12 has quit [Changing host]
Daanct12 has joined #maemo-leste
Danct12 has quit [Ping timeout: 246 seconds]
belcher_ has joined #maemo-leste
reallll has quit [Ping timeout: 258 seconds]
Danct12 has joined #maemo-leste
Danct12 has quit [Changing host]
Danct12 has joined #maemo-leste
Daanct12 has quit [Ping timeout: 272 seconds]
uvos has joined #maemo-leste
<uvos>
Wizzup: i also cant get gprs/umts data to work
<uvos>
so i have hildon-connectivity-mobile installed
<uvos>
and i installed libicd-network-ofono (this was not in the meta package, probubly a bug)
<uvos>
i used to get the umts/gps connection in the conndialog last time i tryed this
<uvos>
but now no cellular connection appears tehre
<uvos>
*there
<tmlind>
hmm so omerlle was going to look into producing android cpcap register dumps for various voice output settings, with those it should be possible to add support to the cpcap audio driver
<uvos>
tmlind: ok but you confirm it currenly dose not work
<tmlind>
uvos: yeah somebody at some point mentioned the normal non-speaker output working after setting the loopback switch and tweaking alsamixer, i never had any luck with that
<tmlind>
i guess that's the headset speaker output
* tmlind
goes back to nursing the bbq
<sicelo>
buZz: didn't you map Fn on Droid 4 to the OK key? I seem to recall that was your contribution ;-)
<sicelo>
Danct12: last i tried, it was working on N900 Leste, yes. Are you in a text field when you try this?
<Wizzup>
buZz: the same exists on the d4 with diff keys
<Wizzup>
parazyd: I wasn't advocating we move our infra, I just thought it was a neat hack others could use for devel
<sicelo>
uvos: gprs/umts was working for me sometime last week using the Leste connection dialog. unless something broke very recently
<Wizzup>
uvos: did you switch sims?
<uvos>
Wizzup: yes i did
<uvos>
Wizzup: but umts data works fine if i reboot into los
<uvos>
sicelo: something did change very recently
<sicelo>
when switching SIMs, i noticed you have to boot twice before an IAP for the new SIM is created
<sicelo>
uvos: what changed? this shouldn't be related to the wifi stuff, iiuc
<Wizzup>
uvos: so fmg has code to provision a sim
<Wizzup>
I think it is in libicd-network-ofono, so maybe that doesn't trigger properly somehow
<uvos>
sicelo: conndialog itself also some changes in addition to wifi stuff
<Wizzup>
I assume the sim has no pin?
<uvos>
Wizzup: sim has pin
<uvos>
but i enter it via ofno
<uvos>
rather during init
<Wizzup>
I don't follow
<uvos>
it has a pin, but i have a initscript that enters it
<uvos>
the i have 3g and bars in the status menu
<uvos>
as well as the operator name
<uvos>
just the gprs/utms connection option in conndialog is missing
<uvos>
Wizzup: i sent you the output of list-modems
<uvos>
Wizzup: is there any thing else that would help?
<uvos>
i really have no idea about how ofono in particular or cellular stuff in general
<uvos>
works
<sicelo>
the connection in dialog should be in gconf, tied to the SIM card's ID (imsi, iirc)
<sicelo>
i know i didn't have to do it manually even though i also had switched sim. a simple reboot was enough
<uvos>
sicelo: /osso/connectivity/IAP ?
<sicelo>
yes, should be that
<uvos>
nothing cellular there they are all wifi connections
<uvos>
lol it stores the wpa2 passwords as plain text
<uvos>
thats not great
<sicelo>
/osso/connectivity/IAP has no gprs IAPs? then you've never connected to umts/gprs with the maemo conn dialog (or you reinstalled?)
<sicelo>
on my D4 i have two gprs IAPs now
<sicelo>
on that gconf key/tree, that is
<uvos>
i had the cellular networking stuff uninstalled between this try and the last
<Wizzup>
uvos: hang on, let me boot my d4
<uvos>
because it was crashing on me with no sim at some point
<uvos>
last time i tryed this it deffinatly worked
<Wizzup>
(also I need a coffee, brb)
<Wizzup>
uvos: does a icd2 restart help?
<uvos>
Wizzup: no
<uvos>
also reboot dident help either
belcher_ is now known as belcher
<Wizzup>
ok, I'll need to read the provisioning code
<Wizzup>
src/iap.c ofono_iap_provision_sim does the work
<uvos>
for the record i have libicd-network-ofono connui-home-cellular connui-statusbar-cellular connui-cellular-settings libconnui-cellular hildon-connectivity-mobile connui-iapsettings-gprs connui-conndlgs-cellular installed
<uvos>
libicd-network-wpasupplicant: try_scan_wpa_control failed with -1
<uvos>
request 0x4f5700 does not have iaps
<uvos>
nothing obviously ofno or cellular related
<sicelo>
i removed both gprs IAPs in gconf, killed icd2. the apns were still showing in control panel, so i rebooted to be sure no remnants were left over. tried again to connect, and wasn't successful. however, after a while, an iap became visible. so far not had a successful connection, but in gconf, the iap exists now. just doing another reboot to see if it's any better
<sicelo>
i think part of the problem is the droid 4's ofono issues
<Wizzup>
uvos: sorry, I have trouble parsing what you said
<Wizzup>
uvos: one thing you can try is to remove the old GPRS network from gconf and see if that matters
<uvos>
Wizzup: i have no old gprs network in gconf
<Wizzup>
sicelo: yeah the setting up the connection part is a little different
<uvos>
Wizzup: /osso/connectivity/IAP contains only wlan infra connections
<Wizzup>
uvos: hm, ok, let me make another coffee and stare hard at your package list
<Wizzup>
uvos: does libicd-network-ofono get loaded?
<uvos>
Wizzup: how can i tell?
<Wizzup>
uvos: I would run icd2 with -l0 (instead of -l2)
<Wizzup>
or opposite, I always forget, but the opposite of what is in the init script
<uvos>
can i make it log to console instead of syslog?
<Wizzup>
I think unfortunately the answer is no, which I think is quite annoying
<Wizzup>
You could modify rsyslog to log icd2 to a specific file, like /var/log/icd2.log
<uvos>
Wizzup: ok anyhow libicd-network-ofono is not mentioned at all
<Wizzup>
uvos: yeah, I think the [OFONO] messages are from that module
<Wizzup>
Pali: btw I think the u-boot folks are saying that where we load u-boot now, we could load spl (minimal u-boot), which then in turn would load u-boot, which would then load linux or something, which doesn't help with the size requirements, but it's technically doable, I suppose
<Pali>
and I have already explained why this is nonsense
<Wizzup>
Pali: it's not clear to me why exactly
<uvos>
Wizzup: i sent you an email with the [OFONO] messages
<Pali>
I have already wrote about it in previous email
<uvos>
Jun 26 11:29:25 localhost icd2 0.98[3839]: [OFONO] Search group for path /motmdm_0 finished, status 6
<uvos>
i gues this is error maybe?
<Pali>
there is no such SPL, nobody worked on it and implementing it would required to add tons of #ifdefs into u-boot spl code or omap part
<Pali>
to skip all things which cannot be done / called in spl code
<uvos>
also why would you do that vs not appending kernel?
<Pali>
also I have wrote that there is no way how to flash that u-boot into eMMC without working u-boot
<Wizzup>
uvos: I think it would be helpful if libicd-network-ofono was a bit more verbose, but I think maybe it cannot find any contexts ? Are those visible in mdbus2 or the ofono scripts?
<Pali>
so they are trying to introduce a new chicken and egg problem
<uvos>
Wizzup: what contexts?
<Wizzup>
Pali: I think their assumption (regardingless of the work required) is that instead of where we load u-boot, we would load SPL, and SPL would be able to read eMMC, en load u-boot from there
<Wizzup>
uvos: ofono data contexts
<Pali>
yes, I have understood it
<Wizzup>
uvos: list-contexts
<uvos>
nothing
<Pali>
and I have already explained it that this is nonsense
<uvos>
"also I have wrote that there is no way how to flash that u-boot into eMMC without working u-boot" <- that sounds fatal to the idea
<Wizzup>
Pali: so the email with this:
<Wizzup>
Not mentioning that implementing this means to implement all N900 code
<Wizzup>
in U-Boot from scratch. And the last thing is testing...
<uvos>
Wizzup: so shal i try create-internet-context?
<Wizzup>
uvos: not sure, I am still digesting this, many things going on at once
<sicelo>
also check to be sure there are no other personal/private modifications at play - i don't have the IAP problem with the latest -devel. I can't connect, but that's different
<uvos>
sicelo: i dont have anything modifed with cellular
<Wizzup>
uvos: let me see what status 6 is
<uvos>
idk what private modifcations would be
<uvos>
sec ill unlock the pin
<uvos>
maybe its that
<uvos>
*unset the pin
<Wizzup>
uvos: no, it should work with pin
<Wizzup>
as long as you entered it already
<uvos>
ok
<uvos>
yeah its enterd
<Wizzup>
btw 6 = OPERATION_STATUS_CANCEL
<uvos>
i can make voice calls after all
<Wizzup>
and the code checks for OPERATION_STATUS_FINISHED
<Wizzup>
so we need to figure out why ofono_start_search_finish gets a non-successful status
<Wizzup>
Pali: I think Tom has the same confusion as I have/had, I could try to summarise your email if you like, to attempt to clear up confusion, but I'd like to run it past you first
<uvos>
interestingly the operatior technology preferance carrys over from android
<Wizzup>
could it just be some default?
<uvos>
no i changed it to gsm on android
<uvos>
and now ofono also repots gsm
<Wizzup>
I think if you're in a call, it probably has to switch, but maybe that's not it
<uvos>
maybe its saved by the modem or soemthing, no idea
<uvos>
Wizzup: no its not that
<Pali>
Wizzup: ok!
<parazyd>
Wizzup: I was referring to this
<parazyd>
<Wizzup> well, if qemu-user is faster than our pis, maybe we should run it on arm64 host then
<Wizzup>
uvos: it's weird that ofono doesn't show any contexts I think, what if you re-online/offline the host
<Wizzup>
s/host/modem/
<uvos>
Wizzup: so i removed sim pin
<uvos>
and now rebooted
<uvos>
(with android)
<uvos>
and now ./ist contexts has a context
<uvos>
*./list-contexts
<uvos>
[ /motmdm_0 ]
<uvos>
[ /motmdm_0/context1 ]
<uvos>
Name = Internet
<uvos>
Active = 0
<uvos>
Type = internet
<uvos>
Protocol = ip
<uvos>
AccessPointName =
<uvos>
Username =
<uvos>
Password =
<uvos>
AuthenticationMethod = chap
<uvos>
Settings = { }
<uvos>
IPv6.Settings = { }
<Wizzup>
does it get provisioned?
<uvos>
um provisioned is what?
<Wizzup>
accesspointname and such need to be set
<Wizzup>
so any change in icd behaviour?
<uvos>
not in the ui
<uvos>
/system/osso/connectivity/IAP has not gained anything
<uvos>
ill send you the log later
<uvos>
brb makeing food
<Wizzup>
uvos: so I think we're seeing operations_group_timeout be hit, and that calls pending_operation_group_list_remove which sets the OPERATION_STATUS_ABORTED
<uvos>
ok
<Wizzup>
why that happens, I don't know yet
<Wizzup>
Pali: so you think that writing spl support would also require lots of ifdefs in u-boot spl and omap code?
<Pali>
in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo
<Pali>
I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that
<Pali>
spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900
<Pali>
freemangordon has already written patches which enabling usb dm, the last missing thing, in very elegant way
<Pali>
but for their perfectionism they do not like it and want from us completely perfect code
<Pali>
despite the fact that other drivers / boards are using same pattern as freemangordon used in those patches
<Wizzup>
yeah, it's annoying, I agree
<Wizzup>
I think they were saying SPL would just not touch/reinitialise anything
<Pali>
and I really dislike this discussion... if we even implement this as requested (which is imho not possible...) then we would be faced again by another "perfectionism" issues
<Pali>
well as I said, in past I already spend time on SPL for oma3 and it did not work on n900
<Pali>
but that eMMC idea is total nonsense, I really do not know why I'm discussing it
<Wizzup>
Pali: I'll send you my draft now
<Pali>
ack
<Wizzup>
Pali: let me know if you think it's helpful
<Pali>
I think it is fine!
<uvos>
Wizzup: you got mail with a new log
<uvos>
Wizzup: also btw closing icd2 with SIGINT causes it to segfault
<uvos>
so thats funn
<uvos>
also for some reason if i start icd2 with -l0 and then connect to wifi it fails in a maemo dhcpc script
<uvos>
the message abot dhcp is on console not syslog
<uvos>
its /etc/maemo-dhcp.d/50_ipv4_network_setup: 81: kill: Illigal option -S
<Wizzup>
uvos: I have only seen that happen (segfault on sigint) when you locally build and 'cp' .so files in
<Wizzup>
I don't think the illegal option -S is what causes dhcp to fail
<uvos>
maybe we just need to kick jenkins to rebuild the modules
<Wizzup>
maybe, but it works for me I think, so something is odd
<Wizzup>
I need to figure out what is actually timing out for you
<uvos>
based on mce nokia dosent know what a plugin interface is :P
<uvos>
so we should allways rebuild everything
<Wizzup>
The pending operation code confuses me quite a bit
<Wizzup>
I guess it runs search_operation_check
<uvos>
also fun that icd2 leaks the psk to the log file
<Wizzup>
maybe we need some more debug there
<uvos>
who thought thats a good idea
<Wizzup>
uvos: yeah that is my bad
<uvos>
no matter
<Wizzup>
we should take that out
<Wizzup>
uvos: I guess it's part of some entire dictionary that it prints?
<Wizzup>
so then the question is why the provisioning fails in libicd-network-ofono
<uvos>
btw unfortionalty runing icd2 with gdb attached dose not segault on sigint
<Wizzup>
yeah something funny is going on there
<Wizzup>
I am surprised that you have the problem though, if you have no custom modules.
<uvos>
nope no modules
<Wizzup>
can you maybe reinstall libicd-network-ofono or something?
<uvos>
sure
<uvos>
so i did apt reinstall libicd-network-ofono
<uvos>
and restarted icd2
<uvos>
no change
<Wizzup>
it's a bit tricky for to debug the problem since I am not seeing it, maybe you can add some print statements to search_operation_check and see where it fails?
<uvos>
ok
<Wizzup>
you could try to step with gdb, but since it's hitting a timeout, that might get tricky
<uvos>
but not now
<uvos>
ttyl then
<Wizzup>
ok
<Wizzup>
fmg is back on tuesday, it's his code, so maybe he has better ideas
<uvos>
could you kick all the icd2 modules on jenkins just in case?
<Wizzup>
yeah ok, I can do that in a bit
<scops>
hm copy paste will grade nicht ... fluffychat hab ich von flathub
<Danct12>
sicelo, i was in the terminal, so that counts
<Wizzup>
the ui-fonts definitely look a bit better
michiell has quit [Ping timeout: 252 seconds]
<Wizzup>
uvos: should I add sphone to the CI?
<Wizzup>
not as extras, just as core
<uvos>
Wizzup: building what exactly
<uvos>
its not pacakged
<Wizzup>
I guess we'd have to package it
<uvos>
sure if you want to package it that would be lovely :)
<uvos>
idk if adding it to CI is nesscarly helpfull atm
<Wizzup>
yeah, sure, I can do that sometime soon then
<uvos>
but packaging it sure is
<uvos>
Wizzup: btw if you have time you could apt install salutem reboot twice and add it to the metapackage if you like it as is
inky_pbp has joined #maemo-leste
<Wizzup>
uvos: yeah ok, later today, my gf is done working and we're going to a beach for a bit, but once I'm settled there I can check
<uvos>
sounds lovely :)
Danct12 has quit [Quit: Quitting]
inky_ has joined #maemo-leste
inky_pbp has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
inky_pbp has joined #maemo-leste
inky_pbp has quit [Client Quit]
inky_pbp has joined #maemo-leste
diejuse has joined #maemo-leste
stan has joined #maemo-leste
Danct12 has quit [Quit: Quitting]
Danct12 has joined #maemo-leste
diejuse has quit [Quit: Leaving.]
ruleh has joined #maemo-leste
ruleh has quit [Ping timeout: 246 seconds]
inky_pbp has quit [Ping timeout: 265 seconds]
uvos has quit [Ping timeout: 244 seconds]
uvos has joined #maemo-leste
Treebeard has joined #maemo-leste
Treebeard has quit [Changing host]
Treebeard has joined #maemo-leste
BenLand100 has quit [Ping timeout: 268 seconds]
Treebeard is now known as BenLand100
inky_ has quit [Ping timeout: 258 seconds]
inky_ has joined #maemo-leste
inky_ has quit [Ping timeout: 258 seconds]
inky_ has joined #maemo-leste
<uvos>
Wizzup: so i poped the sim into a d4 that i had insalled maemo on but done nothing with
<uvos>
Wizzup: and upgraded it & installed hildon-connectivity-mobile and libicd-network-ofono
<uvos>
and the behavior is exactly the same
<uvos>
so thats a fresh image from the 6th or something upgraded to devel and nothing else
marex has joined #maemo-leste
<uvos>
oh btw apt wont upgrade the alpha theme
<uvos>
becuase it depends on beta or something
<uvos>
no big dieal but there is some packaging bug here
<marex>
Wizzup: Pali: hi, if you need input on the whole spl/usb discussion, just let me know
inky_ has quit [Ping timeout: 272 seconds]
inky_ has joined #maemo-leste
diejuse has joined #maemo-leste
<bencoh>
parazyd: regarding emulated apt-get/dpkg, there is a slight issue with the fact that they derive the native (versus foreign) arch name from the arch of the dpkg/apt process, instead of reading it from a config file (for instance)
<bencoh>
but we may be able to work that around somehow
<bencoh>
(to use amd64 apt/dpkg and still set the native arch to armhf)