panzeroceania has quit [Read error: Connection reset by peer]
panzeroceania has joined #maemo-leste
joerg has quit [Killed (lithium.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
<parazyd>
Wizzup: What's the gconf path?
mardy has joined #maemo-leste
_whitelogger has joined #maemo-leste
nohit has joined #maemo-leste
jr-logbot has joined #maemo-leste
Evil_Bob has quit [*.net *.split]
adc has quit [*.net *.split]
jrayhawk has quit [*.net *.split]
L29Ah has quit [*.net *.split]
R0b0t1` has quit [*.net *.split]
Blikje has quit [*.net *.split]
RedW has quit [*.net *.split]
jrayhawk_ has joined #maemo-leste
Evil_Bob has joined #maemo-leste
R0b0t1` has joined #maemo-leste
RedW has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
Blikje has joined #maemo-leste
adc has joined #maemo-leste
<kona>
Sicelo: I think I read that you worked on getting trojita running. I just tried it from osso-xterm and it behaves hikdonized, but if I start from the app manager, it looks totally different and doesn't respond well to input. Is there something wrong with my app manager shortcut?
<kona>
s/ik/il/
belcher_ is now known as belcher
pere has quit [Ping timeout: 248 seconds]
Pali has joined #maemo-leste
<Wizzup>
parazyd: there are several
<Wizzup>
parazyd: one per network type (wlan_infra, gprs, wlan_adhoc, dummy)
<Wizzup>
parazyd: see gconftool -R /system/osso/connectivity/network_type
<Wizzup>
uvos: btw, upgraded mce and see no problems yet
inky_ has joined #maemo-leste
pere has joined #maemo-leste
crab has quit [Quit: WeeChat 3.0]
crab has joined #maemo-leste
uvos__ has joined #maemo-leste
uvos__ is now known as uvos
<uvos>
Wizzup: great
<uvos>
kona: so trojita right now breaks with the maemo qt platform plugin because it uses a hambuger style menu that gets miss translated by the platform plugin into a hildon menu
<uvos>
kona: so the .desktop file disables the platform plugin for now
<uvos>
kona: ill hide enough menu entrys to make it work as soon as i get to it, and also we should improve the hildon menu to support submenus.
<uvos>
kona: anyhow input via vkb via the native method dosent work with or without the plugin as its not implemented in qt yet
<uvos>
kona: but d4 hwkbd and vkb with x11 backend (opend via the search key on d4 or vol up on pp) works fine for me
<Wizzup>
porting the qt5 input method was trickier than I hoped for
<Wizzup>
mostly just because I don't understand X well enough for all the keysym converstion stuff
<Wizzup>
conversion*
<Wizzup>
I did try, might have that work on some branch still
<uvos>
Wizzup: maybe just implementing the acessability dbus interface in him and improving its x11 backend a bit would be a good solution, at least as a stop gap, but imo permanently as well
<uvos>
since that would get everything working (also gtk3) for now untill we have enough time to go around and implement soemthing custiom in eatch toolkit....
<Wizzup>
mhm
<parazyd>
Wizzup, freemangordon: Does it matter which user runs gconftool to make edits?
<Wizzup>
I think it is best if it runs as 'user', but I am not sure.
Daanct12 has joined #maemo-leste
<freemangordon>
parazyd: I think so
Danct12 has quit [Ping timeout: 250 seconds]
<uvos>
well all the keys are there even if you run it as root (sudo su -)
<Wizzup>
I think that is true when gconf already runs
<freemangordon>
installed mce package post-installation script subprocess returned error exit status 1
<freemangordon>
uvos: ^^^
<uvos>
thats dsmes fault
<uvos>
we debugged this before, iirc mce registers with dsme for the heartbeat thing and there is a race where dsme rejects mce's reconeccting if it restarts to fast because it hasend cleaned up yet
<Wizzup>
yeah dsme doesn't wait for the process it kills to exit
<Wizzup>
at least via dsmeutil
<Wizzup>
(since dsmeutil doesn't own the pid, it can't know)
<Wizzup>
it happens also with icd2
<uvos>
"I think that is true when gconf already runs"
<uvos>
how it gconf supposed to work in a multi user env. ?
<freemangordon>
uvos: trying to overwrite '/usr/include/mce/dbus-names.h' is not dsme fault, but debian/control
<uvos>
oh that diden see it
<uvos>
ok interesting
<freemangordon>
uvos: I'll look at mce restart later on
Daanct12 has quit [Ping timeout: 252 seconds]
<uvos>
so for mce its mce gets killed via dsmetool & is exiting but then dsmetool dosent wait so openrc restarts mce immidatly
<uvos>
then the new mce exits with failure because either it cant connect with dsme for heartbeat or it cant own its dbus name (depending on moudle load order) both because the old mce istent done exiting
<freemangordon>
uvos: I'
<freemangordon>
I meant - will see if I can do anything about it
<uvos>
right
<uvos>
i was just makeing sure you understand what is happening
<freemangordon>
maybe add waitpid to dsmetool or something
<freemangordon>
thanks
<Wizzup>
I don't think you can waitpid on pids you do not own
<freemangordon>
It looks like the best option, if it works
<Wizzup>
>The major problem with this netlink interface and proc events still - the kernel returns 1 event at a time, no matter how big buffer your supply is (What's the reason for that?). So you can really easy get overruns with ENOBUFS from the kernel under heavy load. This means you should be carefull with adding some additional work, especially io, to the netlink listener thread. (the example below ignores
<freemangordon>
uvos: ^^^?
<Wizzup>
that rule for simplicity reason)
<Wizzup>
doesn't sound ideal
<freemangordon>
sure, but is portable
<Wizzup>
dsmeutil can get stuck if I read this correctly
<Wizzup>
I'd rather poll for the pid in /proc honestly
<freemangordon>
but it is racy IIUC
<Wizzup>
+ combine it with /proc lifetime
<Wizzup>
afaik you can see when a process was started
inky has quit [Ping timeout: 250 seconds]
<uvos>
we will have lots of instances wating for processes to exit during shutdown/ runlevel changes
<uvos>
i dont think having them all use netlink for it is a good idea
<freemangordon>
ok, so something like:
<freemangordon>
1. get and store mce process start time (/proc/$pid/stat)
<freemangordon>
mce being an example here
<freemangordon>
3. wait until either there is no /proc/$pid/stat or starttime in it changes
<freemangordon>
2. kill mce
<freemangordon>
should do the job, no?
<Wizzup>
yes, that's what I meant with start time
<uvos>
yeah that would work
<freemangordon>
I guess I can poll on /proc/$pid/stat, right?
<uvos>
i would ofc prefer pidfd where its avail.
<uvos>
since then you dont have to poll
<freemangordon>
the problem with pidfd is that I cannot test in the VM
<uvos>
just upgrade the kernel
<freemangordon>
in the VM?
<uvos>
that should be trival in vm no
<uvos>
sure
<uvos>
we could also just do it generaly for vm
<Wizzup>
doesn't it also require specific kernel config options?
<freemangordon>
but then this is no longer leste VM
<uvos>
freemangordon: so its just for you to test
<uvos>
and we maintian kernels for every other target anyhow we could also have a kernal package for vm thats a newer one
<freemangordon>
I'd rather KISS for now and implement the fallback path only
<uvos>
Wizzup: so? you can use localconfig
<Wizzup>
uvos: not making a point other than that we would have to remember to turn it on in various places
<uvos>
Wizzup: turn on what?
<freemangordon>
the config option
<uvos>
the options?
<uvos>
ok
<uvos>
i dont see why upgrading the kernel in vm for fmgs development vm only is a big deal but suit yourself
<freemangordon>
I can do once I have fallback path working
<freemangordon>
I can easily make a snapshot in virualbox
<uvos>
or just test it on d4 dsme compiles plenty fast on it
<freemangordon>
it is way harder to debug ther
<freemangordon>
I can easily setup remote debug using QtCreator in ubuntu to the VM, with source code and everything
<uvos>
not sure how its different than to a remote d4, but no matter, do what works best for you.
<freemangordon>
and with broken USB networking on d4, it will be extremely slow through wifi
inky_ has joined #maemo-leste
<freemangordon>
unless USB networking is fixed lately
<uvos>
i think it works fine
<uvos>
(but i dont use it)
<uvos>
Wizzup: ^^^
<freemangordon>
but yeah, I prefer developing in the VM
<Wizzup>
it works fine unless the battery is full, then it keeps dropping every couple seconds I think
<freemangordon>
yeah, this
<uvos>
hmm ok
<uvos>
just rmmod cpacp_battery then
<freemangordon>
VM then ;)
<freemangordon>
I really prefer to no lose fucus rmmoding and whatnot
<freemangordon>
*not
<freemangordon>
anyway
<Wizzup>
let's just start with the fallback and see if all problems are gone
<freemangordon>
mhm
<freemangordon>
uvos: Wizzup: why do you think dsmetool is at fault? it sends a message to dsme and then waits