branon has quit [Ping timeout: 240 seconds]
branon has joined #maemo-leste
branon has quit [Read error: Connection reset by peer]
branon has joined #maemo-leste
Danct12 has joined #maemo-leste
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
joerg has quit [Ping timeout: 255 seconds]
joerg has joined #maemo-leste
macros_2ndPC has quit [Ping timeout: 256 seconds]
macros_2ndPC has joined #maemo-leste
maemish_ has joined #maemo-leste
Twig has joined #maemo-leste
Danct12 has quit [Read error: Connection reset by peer]
Danct12 has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
<freemangordon> Wizzup: I shall re-tag the kernel to do new build, right?
antranigv has quit [Quit: ZNC 1.8.2 - https://znc.in]
antranigv has joined #maemo-leste
maemish_ has quit [Quit: Connection closed for inactivity]
Danct12 has quit [Read error: Connection reset by peer]
<Wizzup> freemangordon: yes
<freemangordon> Wizzup: BTW https://github.com/maemo-leste/droid4-linux/blob/maemo-6.1.y/scripts/package/builddeb#L205 goes into maintainer scripts substituted, is that on purpose?
<freemangordon> this is what I mean
sicelo has quit [Ping timeout: 246 seconds]
sicelo has joined #maemo-leste
<Wizzup> freemangordon: hm, not so sure, that looks wrong
<freemangordon> mhm
<Wizzup> well, unless what you pasted is the postinstall
<freemangordon> umm...
<freemangordon> this is postinst script, yes
<freemangordon> so, this is on purpose?
<freemangordon> because postrm looks exactly the same, besides the switch argument
<Wizzup> freemangordon: does it say case postinst in ?
<freemangordon> obviously it works, but looks wrong to multiply the same script all over the place and decide on what to do based on hard-coded switch argument
<freemangordon> Wizzup: tis is postinst file in linux-image-omap
<freemangordon> *this
<freemangordon> it is generated by the code I linked ^^^
<Wizzup> yes, but the postrm
<Wizzup> does it have the correct replacement?
<freemangordon> yes
<freemangordon> it is 'case "postrm" in'
<freemangordon> but looks weird to me, that's why I asked is that on purpose
<Wizzup> ok
<Wizzup> I agree it's weird, but I don't think it's worth fixing it up tbh
<Wizzup> but up to you :P
<freemangordon> well, if it is made like that on purpose, I will not 'fix' it
akossh has joined #maemo-leste
antranigv has quit [Quit: ZNC 1.8.2 - https://znc.in]
antranigv has joined #maemo-leste
<freemangordon> Wizzup: heh
<freemangordon> this is exactly what we do it seems
norayr has quit [Excess Flood]
norayr has joined #maemo-leste
<freemangordon> Wizzup: https://pastebin.com/izhxkhw9
<freemangordon> the only side effect is that dkms modules are left on the filesystem on upgrade
<Wizzup> hm, do they ever go away eventually, or?
<freemangordon> no. But it seems debian does rm -rf on purge
<freemangordon> they do that in postrm
<Wizzup> ok
<freemangordon> well, not sure what we shall do
<freemangordon> maybe unpatch dkms and call it a day
<freemangordon> upstream dkms does 'dkms uninstall'
<Wizzup> what do you mean, unpatch dkms?
<freemangordon> but, don't know how would that affect VM
<freemangordon> no idea what to do
<Wizzup> freemangordon: I am not sure if I understand the root cause
<Wizzup> I thought you figured out the problem with dkms
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
<freemangordon> Wizzup: what happens is that dkms module gets uninstalled on kernel upgrade
<freemangordon> the reason for that is the change in debian dkms ^^^
<freemangordon> upstream debian kernels hack around that by not calling /etc/kernel/prerm.d scripts
<freemangordon> on package upgrade that is
<freemangordon> what I don;t understand is how they remove kernel modules build by dkms on upgrdae
<Wizzup> maybe dkms does it itself
<freemangordon> no, because it is not called :)
arno11 has joined #maemo-leste
<freemangordon> Wizzup: oh, they do not 'upgrade'
<freemangordon> they install diferent kernel packages
<freemangordon> linux-image-5.10.0-20-amd64 vs linux-image-5.10.0-21-amd64
<freemangordon> that's why all this works
<arno11> Wizzup: sicelo: i found a magic trick to reduce latency from 600ms to 30ms using pactl :)
<arno11> calls are good
<arno11> the only thing to improve is microphone level
<arno11> a bit low even at 100 purcent
<Wizzup> arno11: great, I', happy that was it
<Wizzup> could you maybe hsare this trick too on the m-l?
<Wizzup> freemangordon: ah
<arno11> Wizzup: sure
<sicelo> arno11: maybe there's another control to toggle?
<arno11> sicelo: oh. maybe
<arno11> i'll have a look
<arno11> in fact we have already in leste specific pulseaudio modules to do lot of things automatically :)
<Wizzup> sicelo: 30ms sounds good to me tbh
<arno11> in real call it seems a bit more than that but not bad compared to my andro phone
<Wizzup> sicelo: what other control are you thinking of?
<Wizzup> arno11: yeah, glad to know that was it
<Wizzup> it is what I told pavel at FOSDEM, probably just this
<sicelo> arno11: how does cmtspeech impact cpu ... did you notice any worse power consumption perhaps?
Twig has quit [Remote host closed the connection]
<arno11> sicelo: cpu is running between 92 and 95 purcent with overclock
<freemangordon> IIRC it is NEON optimized, so someone else is loading the system
<freemangordon> PA most-probably
<arno11> but it is still possible to navigate in the phone with no real troubles
Twig has joined #maemo-leste
<sicelo> i see. and current draw?
<arno11> sicelo: no idea for current draw. i have to check
<arno11> in cmtspeech source code there is a tweak to reduce cpu cons in cost of latency
<Wizzup> there's probably a lot more we can do once we have the initial working setup ... set up
<arno11> indeed
<arno11> and i'm not a pulseaudio professional lol
<arno11> back in bit. testing current draw
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon> oh, it is actually upstream that changed it, not debian
akossh has quit [Ping timeout: 264 seconds]
arno11 has joined #maemo-leste
<arno11> sicelo: phone call drains arround 400mA
<arno11> with overclock. maybe blocking cpu at 250 could decrease power cons a lot
<sicelo> yeah, i guess that's alright. i was interested in how much more if any, running cmtspeech in background affects the power consumption
<Wizzup> sicelo: during a call or not
<sicelo> i.e. when there's no active call
<Wizzup> right
<Wizzup> that should be none, but yeah
<arno11> with no active call there is no cons with cmtspeech in fact
<sicelo> oh sweet
<sicelo> :-)
<arno11> yes
<arno11> :)
<arno11> once call is starting that's another story
<arno11> cmtspeech is registering other ofono event too
<arno11> like receiving sms
<sicelo> as long as it doesn't impact power at 'rest', i guess consuming more during times of modem activity is acceptable
<arno11> yes i think so
<Wizzup> better than none for now at least
<Wizzup> it's possible that cmt speech code is currently overly aggressive wrt latency because the pa latency msec thing wasn't set
<Wizzup> which it won't need to be, perhaps
<arno11> hmm yes according to pactl pa latency is not set
<arno11> but it's easy to configure through pactl
<Wizzup> I can find the libpulse call quite soon probably if you share which parts you set/chagne using pactl
<arno11> here is the trick
<arno11> pactl load-module module-loopback latency_msec=1
<arno11> and then unload module immediately
<Wizzup> Pass a pa_buffer_attr struct in the buffer_attr parameter. In the fields of this struct make sure to initialize every single field to (uint32_t) -1, with the exception of tlength (for playback) resp. fragsize (for recording).
Twig has quit [Ping timeout: 240 seconds]
<Wizzup> I think the current API used by utils/pulse.c doesn't let you control the latency
<arno11> good question
<arno11> that's why latency seems dynamic on my device
<Wizzup> it uses pa_simple_new which doesn't let you set flags
<Wizzup> see my link above
<Wizzup> (I was looking at changing the source code of the libcmtspeechdata)
<arno11> i see
<Wizzup> https://juho.tykkala.fi/Pulseaudio-and-latency this also let's you see the latency for streams it seems
<Wizzup> in any case IMO the right fix here is to have libcmtspeechdata request proper latency
<arno11> it is the link where i found the tweak :)
<arno11> yes agree
<Wizzup> The PA_STREAM_ADJUST_LATENCY flag is automatically set for all streams
<Wizzup> created with the simple API.
<Wizzup> ah, so maybe you just need to set fragsize correctly and everything else to -1
<arno11> yes not difficult
<arno11> fragsize=15 you think ?
<Wizzup> actually just a second
<arno11> let me have a look
<Wizzup> hang on, I need to fix it up
<arno11> ok
<Wizzup> I am trying to figure out if tlength and fragsize are in msec or some other fmt
<arno11> ah ok
<Wizzup> the fdo link seems to suggest you need to use pa_usec_to_bytes to figure out what to set it to, but that seems to take some other struct
<Wizzup> oh
<Wizzup> arno11: ^^ :)
<Wizzup> if you could test it, I'd hope it would bring down latency without needing the extra hack
<Wizzup> if I understand correctly, if pavel set it to 1024, that's probably no good
<arno11> ok i remember something about that
<arno11> let me check
<Wizzup> it's a nice trap
<Wizzup> ;)
<arno11> arghh i can't remove my hack ATM. i need to reverse things to be able to compare
<arno11> and i have to go. i'll have time this evening to test stuff. ttyl
<Wizzup> aight ty
arno11 has left #maemo-leste [#maemo-leste]
<Wizzup> good progress in any case
akossh has joined #maemo-leste
maemish_ has joined #maemo-leste
akossh has quit [Ping timeout: 250 seconds]
<freemangordon> Wizzup: I'll just hack dkms support in postinst file
akossh has joined #maemo-leste
xmn has joined #maemo-leste
eqed has joined #maemo-leste
nmdv has joined #maemo-leste
nmdv has quit [Ping timeout: 264 seconds]
<freemangordon> Wizzup: are we ok with having bash prerm script?
<freemangordon> #!/bin/bash, not #!/bin/sh that is
maemish_ has quit [Quit: Connection closed for inactivity]
eqed has quit [Quit: WeeChat 3.8]
<Wizzup> freemangordon: I am
<freemangordon> I was able to avoid that
<freemangordon> Wizzup: this
<freemangordon> LMK if you are find with it. If yes, I'll issue a new kernel build
<freemangordon> this^^^
elastic_1 has joined #maemo-leste
elastic_dog has quit [Killed (platinum.libera.chat (Nickname regained by services))]
LjL has quit [Ping timeout: 250 seconds]
LjL has joined #maemo-leste
LjL has quit [Read error: Connection reset by peer]
LjL has joined #maemo-leste
LjL has quit [Excess Flood]
LjL has joined #maemo-leste
LjL^ has joined #maemo-leste
LjL has quit [Ping timeout: 240 seconds]
LjL^ is now known as LjL
Twig has joined #maemo-leste
Twig has quit [Remote host closed the connection]
antranigv has quit [Read error: Connection reset by peer]
antranigv has joined #maemo-leste
maemish_ has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11> Wizzup: unfortunatly the new pulse.c is not working: only cracking sound both ways with arround 5 sec latency
<arno11> maybe a conflict with my settings
<arno11> but really not sure
<arno11> back to normal reinstalling libcmtspeech stock version
<Wizzup> ok
<Wizzup> freemangordon: lgtm
<freemangordon> Wizzup: already built it :)
<freemangordon> unfortunately iphb-dkms will have to be reinstalled after new kernel is as current kernel prerm script is broken
<freemangordon> Wizzup: BTW, I think we are ready for release. Unless I am missing something
<freemangordon> we have everything login session related in place, including auth agent
<freemangordon> power usage is back to normal
<freemangordon> etc
<buZz> does gpu accel work again?
* buZz tries chromium
<buZz> nope, still black
<buZz> weird btw, because 3D accel seems quite fine
<freemangordon> buZz: it has never worked in chromium
<buZz> yes it did
<freemangordon> no
<buZz> ok
<buZz> either way, prior to chimaera , chromium worked without --disable-gpu
<buZz> now it doesnt
<freemangordon> start chromium with --disable-gpu and disable hw accel from settings
<freemangordon> because before it was not detecting gpu at all
<buZz> ahh, thats what you mean, it auto-disabled prior?
<buZz> right, ok
<buZz> yeah its not compiling the shaders
<freemangordon> now it detects gpu and tries to use it
<freemangordon> even if it does, it still fails
<buZz> seems the driver misses some glsl libs?
<freemangordon> you can start it with --no-sanbox or whatever
<buZz> but havent dug too deep
<freemangordon> I played a bit
<freemangordon> buZz: chromium --no-sandbox
<freemangordon> with gpu enabled
<buZz> can it compile glsl then?
<freemangordon> yes
<freemangordon> but is slow as hell
<buZz> nice! :)
<freemangordon> [6611:6611:0415/225126.332080:ERROR:gl_display.cc(504)] EGL Driver message (Error) eglGetSyncValuesCHROMIUM: glXGetSyncValuesOML failed.
<freemangordon> lots of those errors
<buZz> lol ok
<buZz> might have some flag to ignore refresh rates
<freemangordon> was not able to find it
<freemangordon> didn't try hard though
<buZz> --disable-gpu-vsync maybe
<freemangordon> no idea
<freemangordon> chrome just crashed gpu here :)
<buZz> it seems pretty fast, beside the hanging on that error
<freemangordon> "--disable-frame-rate-limit --disable-gpu-vsync"
<freemangordon> according to google
<buZz> oh, and one other thing thats still broken since chimeara ; desktop widgets
<buZz> they keep getting removed when i 'sudo poweroff' and boot back up
<freemangordon> you have a widget that crashes
<buZz> and adding 'calendar widget' adds no widget plus removes all others
<freemangordon> that one then
<buZz> might be the calendar one yeah
<freemangordon> hildon-home keeps itself from a boot loop by disabling all widgets on one crashing
<buZz> alas; adding --disable-frame-rate-limit --disable-gpu-vsync gives the same errors
<freemangordon> well...
<buZz> freemangordon: do they ever get re-tested for crashing? or is it forever labelled 'bad'
<buZz> can i unlabel it? :)
<freemangordon> yes, but not sure how
<freemangordon> next restart maybe
<buZz> well, then 'calendar widget' is just completely broken ? :(
<buZz> sad, was so useful
<freemangordon> I will have a look at it tomorrow, just remind me
<buZz> i'd like to remove the broken one then, so i can -keep- widgets over reboots :P
<buZz> i'll try to remove it with apt / appmanager i guess
<buZz> whats sorta funny, readding the widgets one by one puts em back in exact location with exact config
<buZz> ok, removed through appmanager, gonna try a restart to see if widgets stay ^_^
<buZz> omg yes!
<buZz> w00t
<buZz> :D :D
<buZz> so just -having it installed- and not visible causes this , impressive
<freemangordon> I have some ideas what might be
<freemangordon> hmm, no, not that
<freemangordon> buZz: /usr/bin/hildon-home: symbol lookup error: /usr/lib/x86_64-linux-gnu/hildon-desktop/cal-home-widget.so: undefined symbol: time_get_local
<freemangordon> :)
<buZz> looks like a symbol that should have a definition?
<freemangordon> missing -l flag
<freemangordon> sec
<buZz> ooooo
<buZz> freemangordon: you're too early, you said tomorrow!
<buZz> :)
<freemangordon> it turned out that tomorrow I will be MIA
<buZz> oo
<buZz> freemangordon in concert!
<freemangordon> no
<buZz> MIA is such a cool artist :D
<freemangordon> heh
<buZz> hehe i know, just kidding ;)
<Wizzup> arno11: maybe try it only for source then
<Wizzup> arno11: ah you siad both ways
<Wizzup> freemangordon: regarding release, let's see, just a sec
<freemangordon> buZz: https://pastebin.com/x9GCvQdG
<freemangordon> feel free to make a PR with that patch, I am going to watch Ronnie :)
<freemangordon> ttyl
<buZz> :) enjoy!
<buZz> thanks!
nela has quit [Ping timeout: 240 seconds]
<Wizzup> buZz: do you want me to commit and build?
<buZz> if you want to? i was still searching for how ;)
<Wizzup> building now
<buZz> woot :) it tend to use the maemo calendar a lot, even with the broken layout and colors :P
<buZz> i tend*
elastic_dog has joined #maemo-leste
<sicelo> buZz: the widget positions on desktop are stored in gconf. that's why they go back to original location on being added again :-)
<buZz> fancy :)
<Wizzup> buZz: should be in repos
* buZz tries
<buZz> w00t, instantly even adds it back to desktop :D
<buZz> \o/
<buZz> it works, Wizzup :)
<buZz> oo also new kernel and new hildon-base
nela has joined #maemo-leste
<buZz> arf
<buZz> rebooted for the new kernel -> all widgets gone again
<Wizzup> maybe you have another widget with this problem
<buZz> i just have 3 widgets installed ; command exec, personal IP , and the calendar one
<buZz> they all are on 1 desktop page and work now
<buZz> the command exec is 8x on desktop even , 8 different commands
<buZz> maybe something else causes the same behaviour? like a broken statusmenu plugin? (afaik orientation lock is still installed here)
<sicelo> i hope it's not my widgets, although I'll admit i haven't tested them on chimaera
Daaanct12 is now known as Danct12
<buZz> i'm not sure, those arent in appmanager?
<sicelo> iow, personal ip and cmd exec ... i ported them and should maintain them
<buZz> iow?
<buZz> the personal ip and cmd exec ones i use, and they seem to work totally fine
<sicelo> "in other words" ..
<buZz> oh, right, ok
<sicelo> nice to hear they work good :-)
<buZz> :)
<sicelo> i haven't run Leste in a while now ... haven't had much time to spare, although arno11's work is encouraging me to 'return' asap
<buZz> i removed orientationlock and trying a powercycle now
<Wizzup> could also be the ip address one
<buZz> but its working?
<buZz> oh wait
<buZz> maybe hildon -remembered- that the calendar one is broken
<buZz> and doesnt retest ever
<buZz> powercycle now removes em all again
<sicelo> if ip address or cmd exec cause issues, please feel free to ping. I'm still willing to maintain them
<sicelo> buZz: look at or enable logs
<buZz> just gonna try a hunch
<buZz> (removing cal-home-widget, to see if hildon has some memory about this)
maemish_ has quit [Quit: Connection closed for inactivity]
<buZz> hahahaha it does
<buZz> so uninstalling the functional cal-home-widget made hildon assume they're all good , so displays them as before poweroff
<buZz> but, adding it back makes hildon remember the old crashing state of that 1 plugin, removing -all- from desktop on reboot
<buZz> amazing UI nokia :D
<sicelo> sounds weird
<buZz> i guess 'restore factory defaults' or something would fix it
<sicelo> maybe need gconf cleanup
<buZz> yeah likely
<buZz> or wherever it stored it
<Wizzup> I think what would make more sense is that you run hildon-home in debug mode
<Wizzup> and see if any other errors occur
<Wizzup> this might be based on too many assumptions on your side
<buZz> right, ok, where is it launched?
<Wizzup> you first have to stop it using dsmetool and then start it from gdb or so
<freemangordon> buZz: /usr/sbin/dsmetool -k /usr/bin/hildon-home
<freemangordon> sudo apt install hildon-home-dbgsym
<buZz> i'll install gdb first :P
<freemangordon> gdb maemo-summoner
<freemangordon> r /usr/bin/hildon.home.launch
<buZz> go to your movie ;)
<freemangordon> ummm....
<freemangordon> r /usr/bin/hildon-home.launch
<buZz> :)
<freemangordon> movie? Ronnie is not a movie ;)
<buZz> oh, i thought Reagan, the actor
<freemangordon> no
<buZz> hildon-home-dbg , it seems?
<freemangordon> could be, yeah
<Wizzup> dbgsym probably, use apt-cache search
<buZz> hildon-home-dbg/stable 0.3.79+m7 armhf
<buZz> yeah
<Wizzup> huh, that one is still on dbg eh?
<freemangordon> yeah
<freemangordon> compat is 5
<buZz> but, how can i run hildon-home through gdb to read debug msgs, when this only happens on boot?
<freemangordon> buZz: see what I wrote ^^^
<freemangordon> start with "/usr/sbin/dsmetool -k /usr/bin/hildon-home"
<freemangordon> then "G_MESSAGES_DEBUG=all gdb maemo-summoner"
<freemangordon> then in gdb: "r /usr/bin/hildon.home.launch"
<buZz> yeah but, then the issue is already gone?
<freemangordon> sorry, r /usr/bin/hildon-home.launch
<freemangordon> what do you mean?
<buZz> because that would be the second launch of hildon-home since boot
<freemangordon> and?
<freemangordon> so what?
<buZz> i thought i was trying to find why it removes the widgets :P
<freemangordon> does it display them on second launch?
<Wizzup> probably because is crashes and then restores safe state
<freemangordon> mhm
<Wizzup> why is why you're starting it like this
<Wizzup> which is why*
<buZz> ok, well, lets see
<buZz> :D
<freemangordon> buZz: lets try as I say, if we cannot repro, will try other things
<buZz> i'm installing it with hildon-home in gdb , to see if any errors directly appear, then restarting and seeing if its giving more new errors
<freemangordon> hmm?
<freemangordon> please, do what I wrote ^^^
<freemangordon> do not restart anything
<buZz> but, eh
<buZz> ok
<buZz> only lacked G_MESSAGES_DEBUG=all :)
<freemangordon> does not matter
<freemangordon> and?
<buZz> no errors on adding the calendar widget back
<freemangordon> sure
<buZz> and it displays
<freemangordon> now, break into debugger (ctrl-c) and quit
<buZz> but how can i now see the behaviour its showing on boot, of removing all the widgets?
<freemangordon> buZz: patience :)
<freemangordon> do as I say
<freemangordon> "now, break into debugger (ctrl-c) and quit"
<buZz> 'quit anyway (y/n)
<freemangordon> yes
<buZz> done
<freemangordon> now start it again in gdb
<freemangordon> G_MESSAGES_DEBUG=all gdb maemo-summoner
<freemangordon> etc
<buZz> first line 'hildon-home: program did not exit properly on the previous session. All plugins will be disabled'
<freemangordon> mhm, that's the issue
<freemangordon> sec
<freemangordon> buZz: what is the result of "find / -name hildon-home.stamp"
<freemangordon> or rather ls -al /tmp/hildon-desktop/
<buZz> eh, guess i should have hildon-home running then , 1 moment ;)
<freemangordon> wait
<Wizzup> no
<freemangordon> how do you restart the device?
<buZz> eh, often just sudo reboot/sudo poweroff
<freemangordon> so, what is the result of ls -al /tmp/hildon-desktop?
<buZz> sometimes i take the time to press powerbutton and tap the button
<freemangordon> so?
<buZz> there's a 1 byte hildon-home.stamp
<freemangordon> buZz: please...
<buZz> timestamped for just-now
<freemangordon> ls -al /tmp/hildon-desktop
<freemangordon> just give me the output
<buZz> total 16
<buZz> drwxr-xr-x 2 user user 4096 Apr 15 23:39 .
<buZz> -rw-r--r-- 1 user user 1 Apr 15 23:39 hildon-home.stamp
<buZz> -rw-r--r-- 1 user user 0 Apr 15 23:39 desktop-started.stamp
<buZz> -rw-r--r-- 1 user user 1 Apr 15 23:39 status-menu.stamp
<buZz> drwxrwxrwt 7 root root 4096 Apr 15 23:40 ..
<buZz> here you go :D
<freemangordon> now rm hildon-home.stamp
<buZz> done
<freemangordon> and then /usr/sbin/dsmetool -t /usr/bin/hildon-home
<buZz> oh, -t
<buZz> dangit, did -k
<freemangordon> and then add calendar widget again (if it is missing)
<freemangordon> no problem
<freemangordon> it kills nothing if there is nothing to kill :)
<buZz> ehhhh, 'desktop menu' doesnt work after -k (and then -t)
<freemangordon> what does it mean "does not work"?
<buZz> tapping it doesnt display a menu
<buZz> tapping 'done' does close it
<freemangordon> hmm
<freemangordon> ok, do /usr/sbin/dsmetool -b
<freemangordon> this will reboot the device
<buZz> ok
<buZz> thats the same as powermenu 'switch off' ?
<freemangordon> almost
<freemangordon> will reboot though
<buZz> seems similar , insta-black and whiteled directly
<freemangordon> yes, similar but not same
<buZz> ok, it booted back up now
<freemangordon> is widget there?
<buZz> non of the widgets are
<freemangordon> which widgets do you have?
<freemangordon> calendar, ip and?
<buZz> 22:51:09 < buZz> i just have 3 widgets installed ; command exec, personal IP , and the calendar one
<freemangordon> ok
<freemangordon> i am missing exec one
<buZz> removing cal-home-widget fixed it prior btw
<freemangordon> I have calendar and ip widgets on my d4 and VM, no issues there
<buZz> as in , apt remove
<buZz> curious :)
<freemangordon> buZz: could you pastebin /var/log/maemo/dsme.log?
<freemangordon> buZz: scratch that, we have to do one more thing before that
<freemangordon> please re-add cal widget and then again reboot with "/usr/sbin/dsmetool -b"
<buZz> ok
<buZz> rebooting
<buZz> and then just last entries since boot from dsme.log?
<freemangordon> mhm
<freemangordon> well, lets see if widget will be there
<freemangordon> Wizzup: I think the issue comes from non-dsme reboot
<freemangordon> h-h is either not removing most probably
<freemangordon> s/either//
<freemangordon> ugh
<freemangordon> h-h is not removing its timestamp file most probably
<buZz> its not there
<freemangordon> :(
<freemangordon> please pastebin last ~100 lines from dsme log
<buZz> alright
<freemangordon> "Process '/usr/bin/hildon-home' with pid 4145 exited with return value 1 and restarted with pid 4146" etc
<Wizzup> maybe some widget doesn't like starting early on
arno11 has left #maemo-leste [#maemo-leste]
<freemangordon> mhm
<freemangordon> but I wonder which one
maemish_ has joined #maemo-leste
<freemangordon> buZz: could you pastebin last 200 lines?
<buZz> maybe calendar backend takes a long time to start with 397489475983749 entries in it?
<buZz> bit less, but its not few
<freemangordon> that should not crash the widget, no?
<buZz> change filename to 200 for 200 lines version
<buZz> i'll do a 1000 ahead of your request aswell :P
<freemangordon> no
<buZz> ok
<freemangordon> Apr 15 23:39:05 localhost DSME: process '/usr/bin/hildon-home' started with pid 2666
<freemangordon> Apr 15 23:42:06 localhost DSME: Process '/usr/bin/hildon-home' with pid 2666 exited with return value 0
<freemangordon> what the?
<buZz> might be me messing with gdb? /me checks timestamps
<freemangordon> no
<Wizzup> good luck, /me zz
<freemangordon> yeah, I need some rest too
<buZz> take your time guys :)
<freemangordon> buZz: when I have time I will provide you a special version of cal widget to track what's going on
<Wizzup> freemangordon: I will see if I can start working on news post
<Wizzup> (tomorrow)
<freemangordon> cool
<buZz> cool cool :)
<Wizzup> we still have some regressions, but urgent ones
<Wizzup> (maep crash and syncevolution syncing not working are the ones on my mind)
<Wizzup> maep crash is probably simple
<freemangordon> buZz: in the meanwhile, please confirm that with calendar widget not added, other widgets survive reboot
<freemangordon> buZz: one more thing (I doubt it will help, but still)
<freemangordon> could you pastebin last 200-300 lines of /var/log/maemo/hildon-home.log
<buZz> holy, that file is >500MB
<freemangordon> hmmm
<Wizzup> probably usb stuff
<Wizzup> we still have the constant switching when on power and full
<buZz> it seems every ... 3 seconds a loooot of debug_netreg() lines
<Wizzup> oh
<Wizzup> yeah that
<Wizzup> good point, I should remote that
<Wizzup> remove*
<Wizzup> well if you ever wanted to know the cellids you visited :P
<buZz> heheh
<buZz> more fun would be finding cellids that are unlisted ;)
<buZz> last 300 lines is -just- netreg stuff :)
<buZz> oh!
<buZz> Apr 15 23:57:02 localhost hildon-home[2629]: CALENDAR:getInstanceTimes: CComponent::getInstanceTimes(time_t,time_t): DEPRECTAED#012
<buZz> DEPRECTAED :D
<buZz> btw last 300 lines of hildon-home.log ; https://space.nurdspace.nl/~buzz/maemo/last300lines.log
<freemangordon> hmm that's too noisy
<freemangordon> I need th elog around Apr 15 23:42:06
<buZz> but there -is- a calendar error in it
<freemangordon> where?
<buZz> Apr 15 23:57:02 localhost hildon-home[2629]: CALENDAR:getInstanceTimes: CComponent::getInstanceTimes(time_t,time_t): DEPRECTAED#012
<freemangordon> thats a warning
<freemangordon> I guess
<buZz> oh ok
<freemangordon> but yeah, maybe this is the issue
<buZz> the timestamp is right before i rebooted
<buZz> just after i re-added the widget
<freemangordon> yeah, but we need after the reboot with missing wodget
<freemangordon> *widget
<buZz> right, hmhm
<buZz> thats the lines below it from 00:02 on
<freemangordon> anyway, lets continue next time
<buZz> alright :)