<Guest18624>
Hi, yesterday I got the Droid 4 to connect to the GSM network, with some help from you guys. In addition to the instructions on the page https://leste.maemo.org/Status/Phone, this is what I've done:
<Guest18624>
# after adding the beowulf-devel repository,
<Guest18624>
# sudo apt update throws GPG error for beowulf/Extras
_inky has quit [Read error: Connection reset by peer]
_inky has joined #maemo-leste
<bencoh>
alright, gonna try to upgrade leste here ... what do I need to disable first for it not to reboot? (yeah, I always seem to forget)
<uvos>
touch /etc/no_lg_reboots
<bencoh>
thanks :)
<uvos>
but leste config should do that for you
<uvos>
(if your version is recent enough)
<bencoh>
doubt it is
<Wizzup>
also reboot after that file
<Wizzup>
honeycomb is up and running
<Wizzup>
now I just need to migrate the rpi systems
<bencoh>
reboot after the touch? alright
<Wizzup>
ywesa
<Wizzup>
yes
<bencoh>
I was about to press enter :)
<bencoh>
yay, looks like it worked
<bencoh>
let's see if it reboots
<bencoh>
(I didn't dist-upgrade though)
<bencoh>
oh, is dist-upgrade safe on leste?
<uvos>
yes
<uvos>
and sometimes its nesscary
<uvos>
freemangordon: log dosent really show anything
<uvos>
uvos.xyz/maserati/sphone-abook.log
<bencoh>
interesting ... I got a text getty prompt instead of Xorg after upgrade without dist-upgrade
<bencoh>
I guess kernel version doesn't match xorg driver?
<bencoh>
(nice that it doesn't crash at boot)
<uvos>
uname -a, xorg.log?
<bencoh>
5.10.30
<uvos>
yes wrong kernel
<bencoh>
thought so
<bencoh>
now, to upgrade it from console without usbnet ....
<uvos>
wpa_cli
<bencoh>
yeah
<uvos>
freemangordon: so to repduce: have a eds database, any kind with some contacts. make it default. build sphone from git, have it load contacts-ui-abook instead of -exec, open the dialer, click contacts.
<Wizzup>
bencoh: I think icd might work without x
pere has quit [Ping timeout: 240 seconds]
<Wizzup>
in any case, yes, you must dist-upgrade
<uvos>
icd has pretty piss poor performace on d4 without x
<uvos>
because it ussualy fails at least once trying to connect
<uvos>
and then you would have to wait a long time for it to try again
<Wizzup>
yes, that is a kernel bug
<Wizzup>
not icd2 bug
<uvos>
sure
<uvos>
but in pactice it just dosent work
<Wizzup>
btw, other topic
<uvos>
if you cant use th ui
<Wizzup>
I was thinking we should make or revamp some simple roadmap that we all agree on, on bugs and/or features to work on
<Wizzup>
I have a few people who are interested in helping out but I have trouble pointing them at specific things to pick up
<Wizzup>
our issue list is kinda large and not ordered by priority in any way
<uvos>
also imo it kind of is a icd2 "bug"
<uvos>
it just dosent try hard enough. the connection can fail for any reason incl stuff like temporary interferance
<uvos>
it should just try again
<Wizzup>
right it defers to wpa_supplicant on that
<uvos>
Wizzup: not sure what the difference is between icd2 driving wpa and wpa_cli driving wpa
<uvos>
(wpa_cli never ever fails to connect on d4)
<Wizzup>
pretty sure the first time fails
<Wizzup>
and then it just retries
<uvos>
not always
<Wizzup>
driven by wpa_supplicant standalone logic
<uvos>
and right the problem is icd2 dosent try again
<uvos>
im not sure why but it just gives up after one try
<uvos>
if you connect with wpa_cli it just tries again and suceeds
<uvos>
this is also true if you start wpa_supplicant with -c
pere has joined #maemo-leste
blasty_ has quit [Remote host closed the connection]
_inky has quit [Ping timeout: 268 seconds]
<uvos>
looks like i got another d4 display cable to die on me :(
<Wizzup>
weird, how does that happen
<Wizzup>
do you regularly open them up?
<uvos>
no idea
<uvos>
sure regularly
<uvos>
i mean i use it as a primary device
<uvos>
that comes with lots of openings
<Wizzup>
I can send you something, if you let me know, I am leaving friday morning
<uvos>
nah its fine
<uvos>
i still have 2 others
<uvos>
but at some point if you find a d4 thats broken in a different way sure
<Wizzup>
probably about 12 atm, but those are in the us
<Wizzup>
looks like 5 out of 6 mz617 are in a good state
<Wizzup>
one had a power button that looks like someone *really* wanted to power it off :p
<uvos>
:P
<Wizzup>
ok so the honeycomb is set up, just need to move the build systems there
<Wizzup>
might need to re-install debian or something, the pi rootfses might be too pi specific, not sure
<Wizzup>
btw, any ideas on the roadmap thing?
<uvos>
i dont think its a bad idea per say
<uvos>
but idk how you would organise it
<Wizzup>
wiki page, with links to issues, and the wiki page could be ordered by general goals and then perhaps with some dates as to when we'd -like- to do it
<humpelstilzchen[>
But people just work on whatever they want to, not sure if a roadmap helps in pinning more important issues
<uvos>
i dont think deadlines are particularly usefull
<uvos>
pinning more important tasks helps
<uvos>
timelines dont
<uvos>
imo
<Wizzup>
timelines are not to push pressure, of course
<Wizzup>
humpelstilzchen[: well, I think it would be good to have a bit more direction in that sense
<Wizzup>
doesn't mean people can't do whatever they want :)
<Wizzup>
but it could help with "how much do we think we care about feature X vs bug or feature Y" when it comes up
<freemangordon>
uvos: if I install sphone, will it use osso-abook? or I shall build from the repos?
<uvos>
no
<uvos>
you have to build from repos
<uvos>
and make it load the moduel as stated above
<freemangordon>
above?
<uvos>
[13:12] <uvos> freemangordon: so to repduce: have a eds database, any kind with some contacts. make it default. build sphone from git, have it load contacts-ui-abook instead of -exec, open the dialer, click contacts.
<uvos>
the modules to be loaded are in /usr/share/sphone.ini
<freemangordon>
I am not sure I understand "have it load contacts-ui-abook instead of -exec"
* freemangordon
pulls sphone
<uvos>
look at /usr/share/sphone.ini
<uvos>
should be clear then
<freemangordon>
ok
<uvos>
/usr/share/sphone/sphone.ini
<freemangordon>
ok
<freemangordon>
uvos: sorru, it is still not clear to me. shall I modify ContactsUiExec section?
<uvos>
no
<uvos>
theres not sutch section
<uvos>
Modules=
<freemangordon>
[ContactsUiExec]
<freemangordon>
# Application to call to open contacts
<uvos>
so your default is the same as system-address-book
<uvos>
probubly you need to create some other database to make it break
<uvos>
(and make it default)
<freemangordon>
need a second
<freemangordon>
I don;t see the book selection code called
* freemangordon
fires gdb
<freemangordon>
uvos: you are missing a call to osso_abook_init()
<uvos>
freemangordon: ok thanks
<freemangordon>
wait
<freemangordon>
it will fix missing logs
<freemangordon>
lemme test it here first
_inky has joined #maemo-leste
<freemangordon>
uvos: you better call osso_abook_debug_init() instead of osso_abook_init()
<uvos>
ok
<freemangordon>
osso_abook_init() requires osso_context I am not sure you can get
<uvos>
well one could be created just for this module
<uvos>
(in the module)
<uvos>
but ok
<freemangordon>
no need I think
<freemangordon>
lets first see if we can get sane logs
<uvos>
anyhow
<uvos>
afk
uvos has quit [Quit: Konversation terminated!]
<freemangordon>
uvos: you should keep config in /etc, not in usr/share
<freemangordon>
it gets overwritten on reinstall
<Wizzup>
I think it is some systemish so put configs in /usr/share
<Wizzup>
like X also moved some stuff there
<Wizzup>
maybe it's like system provided vs user set or something
<Wizzup>
systemdism*
<freemangordon>
aha
<freemangordon>
but, it gets overwritten without warning
inky has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
uvos has joined #maemo-leste
uvos is now known as _uvos_
_inky has quit [Ping timeout: 256 seconds]
<_uvos_>
freemangordon: yes as is intended, according LFHS /usr/share contains distro configuration /etc contains system wide administrator configuration and ~ contains user configuration
<_uvos_>
freemangordon: for sphone /usr/share contains defaults if it cant read a config file from ~/.sphone
<_uvos_>
but should be better documented
<freemangordon>
ah, I see
<freemangordon>
uvos: also, you *must* call hildon_gtk_init() and not gtk_init() on leste