uvos has quit [Ping timeout: 256 seconds]
pere has quit [Ping timeout: 268 seconds]
Pali has quit [Ping timeout: 240 seconds]
Oksanaa has joined #maemo-leste
Oksanaa has quit [Ping timeout: 268 seconds]
joerg has quit [Read error: Connection reset by peer]
joerg has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
macros_ has quit [Ping timeout: 250 seconds]
joerg has joined #maemo-leste
macros__ has joined #maemo-leste
<freemangordon> Wizzup: if we don;t want daemon to restart on upgrade, there is no need for hacks etc
<freemangordon> see -r
<freemangordon> hmm, dsme already does that
<freemangordon> maybe I am missing the issue
mardy has joined #maemo-leste
<rafael2k> hey, sorry, ended up sleeping yesterday
<rafael2k> uvos: tks (for sphone info - I will try it out)
<rafael2k> Wizzup: my pp keyboard should arrive in the next days
<rafael2k> Wizzup: sound is still clogged with pa here, pa is shit, I'll check mobian setup
pere has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
pere has joined #maemo-leste
pere has quit [Ping timeout: 250 seconds]
<humpelstilzchen[> oh can we go without pa? :)
pere has joined #maemo-leste
<rafael2k> humpelstilzchen[: I'd like too, but some software rely on it, like sphone and other I think
<humpelstilzchen[> rafael2k: I wonder if apulse emulation helps
<rafael2k> lets try to fix pa first... seems to be some detail
<humpelstilzchen[> oh, dead project. What a pitty
<sicelo> keep pa. you probably just need a simple config or sth.
<Wizzup> freemangordon: I don't think we want to fork every daemon we don't want to restart, but yes, that is a potential solution for ofono and such
<Wizzup> humpelstilzchen[: rafael2k: maemo needs pa
<freemangordon> sure I didn;t mean to fork, but we shall fix our daemons we don't want to be restarted
<freemangordon> my point was more than dsme is already ok in that regard
<freemangordon> BTW, what happens if ofono cashes?
<freemangordon> *crashes
<Wizzup> not sure, either it stays down or it gets started again via dbus activation
<freemangordon> tmlind: hmm, I think omap ddx commit 478fcc45e0b9d93dbe1a2c1f842441af529a3c04 is the reason why we see dma_buf leaks
<freemangordon> "[PATCH] omap: Fix missing usage count decrease in OMAPDRI2DestroyBuffer"
<freemangordon> it decreases usage count, but doesn;t check if it become zero afterwards
<freemangordon> Wizzup: could you have a look too, please?
<Wizzup> I mean it sounds very sensible
<freemangordon> ok, will fix the logic to my understanding, lets see what tmlind will say
<rafael2k> Wizzup: ok! pa stays!
<freemangordon> :)
<rafael2k> Wizzup: I can get sound, but there is some samplerate mismatch... interesting that what triggered the issue was the more recent alsa driver
<rafael2k> some new kernel behavior... dunno yet
<freemangordon> Wizzup: I guess this is the reason for CMA failures on n900 too