tk has quit [Quit: Well, this is unexpected.]
tk has joined #maemo-leste
Oksanaa has quit [Remote host closed the connection]
Oksanaa has joined #maemo-leste
uvos has quit [Ping timeout: 240 seconds]
xmn has joined #maemo-leste
jk_000 has joined #maemo-leste
jk__000 has quit [Ping timeout: 272 seconds]
pagurus has quit [Ping timeout: 272 seconds]
pagurus has joined #maemo-leste
TonyStone has quit [Ping timeout: 240 seconds]
TonyStone has joined #maemo-leste
mardy has joined #maemo-leste
joerg has quit [Ping timeout: 256 seconds]
joerg has joined #maemo-leste
xmn has quit [Ping timeout: 256 seconds]
pere has quit [Ping timeout: 272 seconds]
pere has joined #maemo-leste
Twig has joined #maemo-leste
mepy has quit [Ping timeout: 240 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Pali has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
Pali has quit [Ping timeout: 256 seconds]
macros_ has joined #maemo-leste
_inky has quit [Ping timeout: 240 seconds]
Twig has quit [Ping timeout: 240 seconds]
halftux has joined #maemo-leste
<Wizzup> freemangordon: can you remind me what I had to do for libsdl(2) ?
_inky has joined #maemo-leste
<buZz> is it me or is phoenix.maemo.org really slow
<buZz> grabbing last droid4 build at 300kb/s
<freemangordon> Wizzup: pull latest from debian in our repo so I can make it build on leste
<freemangordon> (IIRC) :)
<freemangordon> debian == salsa.$whatever.$it.$was
_inky has quit [Ping timeout: 240 seconds]
<buZz> this 'low battery poweroff' is kinda annoying when trying to setup a fresh droid4 :P
_inky has joined #maemo-leste
<Wizzup> ok
<buZz> guess i'll just leave it on usb for longer
<Wizzup> buZz: what do you observe?
<buZz> maemo boots, charging led is on , i can connect to wifi, start a 'apt update' , and during it just powers off, seemingly
<buZz> also, white led is blinking through the charging led now? hmm
_inky has quit [Ping timeout: 240 seconds]
<buZz> hmmmm , maybe it just synced time during connecting to wifi and got confused?
<buZz> oh, btw, last build oin phoenix. gives me on 'apt update' (after 5th time it seems to stay running now) : 'invalid signature 'maemo leste extra signing key''
<buZz> on latest image from phoenix*
<buZz> i'll try upgrade & dist-upgrade, reboot, and retry apt update
<buZz> ah, already a 'apt update' after the upgrade doesnt give the key error
<Wizzup> buZz: not sure about the power off, that seems weird, does it do a reboot, or just reset?
<Wizzup> buZz: the signing key is fixed with an update of core pkgs
<buZz> it seems to do a full poweroff, its kinda weird
<buZz> maybe this cable is dubious .. hmm
sunshavi has quit [Read error: Connection reset by peer]
sunshavi has joined #maemo-leste
_inky has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
_inky has quit [Ping timeout: 272 seconds]
_inky has joined #maemo-leste
pere has quit [Ping timeout: 240 seconds]
uvos has joined #maemo-leste
<uvos> buZz: thats expected behavior
<buZz> right, just saying its a annoying situation :)
<uvos> buZz: the d4 only charges with 500mA if you load it (like apt update dose) it will be discarging the battery
<uvos> buZz: if its discarging the battery while the voltage is below threshold it will power off
<uvos> buZz: this is the only thing it can do to prevent damage
<buZz> hmhm
<buZz> well, there are alternatives :)
<uvos> no
<buZz> 'while (battery <2%) { echo "preventing further booting while charging to minimum capacity"; }' in rc.local or something
<uvos> dosent help
<uvos> and we do this
<uvos> in charge-mode
<Wizzup> uvos: the power off you describe, is that what buzz sees?
<buZz> ah, didnt see any msg
<Wizzup> uvos: it sounded like immediate power off to me
<uvos> Wizzup: its working as intended
<Wizzup> hmm, is there a way to see this in the logs?
<uvos> Wizzup: mce powers off because the battery is discarging while below a voltage threshold
<buZz> yeah often its immediate , but as i read it, it might just be dropping so low that it plops away instantly?
<Wizzup> a buddy of mine had his d4 also just shut down without errors in dmesg
<Wizzup> and I htink I saw it too at some point
<Wizzup> maybe it's a voltage drop
<uvos> Wizzup: well the led makes it obivous
<buZz> what does the led say?
<Wizzup> uvos: then I think it is a different behaviour
<uvos> Wizzup: led on = mce is volontarly shuting down
<Wizzup> buZz: I think the led should be purple
<uvos> white
<buZz> which color on?
<Wizzup> ok, white then
<buZz> uvos: once i had 'white led on' while completely powered off even
<buZz> is that this behaviour?
<uvos> its not off
<uvos> it turns off the display immidatly
<uvos> and then powers off
<uvos> while the led is on its not finished
<Wizzup> ok I just thought that buzz said the device powered off immediately
<Wizzup> like some reset
<buZz> right, just not responding to keyboard, slider or USB in/out
<uvos> right
<uvos> this is correct
<buZz> with whiteled on
<uvos> its in the processes of shutdown
<Wizzup> ok
<Wizzup> then it is what uvos said
<buZz> uvos: it took >5 minutes?
<uvos> buZz: there a kernel bug
<uvos> buZz: that causes a oops on shutdown
<buZz> eventually i did power+voldown
<uvos> it can hang
<uvos> yeah
<uvos> this is a different issue
<buZz> cant we keep display on with backlight off on poweroff-by-mce ?
<uvos> this is the uart dirver oopsing
<uvos> buZz: we dont want to
<uvos> the led is your indication :)
<buZz> right but its indicating things that arent clear :D
<uvos> (and serial sticks around ofc)
<uvos> imo its fine
<uvos> ofc the kernel should not oops :P
<Wizzup> maybe the led pattern could pulse or something
<uvos> no not possible
<uvos> and not a good idea
<uvos> the led pattern has to be on untill the device is hardware off
<uvos> this is long after mce dies
<uvos> so mce cant be pulsing the led
<uvos> the current pattern on n900/fremantle is also very dumb
<uvos> it ramps down in about 1 sec
<uvos> thus not telling the user anything really (ie the n900 can hang in shutdown forever and the user wont know untill he finds his battery unexpectantly empty)
<uvos> we should be changing the n900 led to be like the mapphone one not the other way around
jk000 has joined #maemo-leste
jk_000 has quit [Read error: Connection reset by peer]
xmn has joined #maemo-leste
<bencoh> wait, the n900 led driver has a hardware led pattern engine
<uvos> right, so dose the d4, but its not used sanely on n900
<uvos> its programed to turn off the led slowly in a fixed time
<uvos> this has no relation to the n900 acctually turning off
<uvos> its just a meaningless/useless animation
jk000 has quit [Remote host closed the connection]
jk000 has joined #maemo-leste
_inky has quit [Ping timeout: 260 seconds]
<freemangordon> uvos: not really, on n900 WD actually works, not like the one on d4
<uvos> mope
<uvos> nope
<freemangordon> yes, it does
<uvos> n900 can and absoulty dose hang like this
<uvos> i has in the past
<uvos> *it
<freemangordon> no way
<uvos> wd can not prevent every hang
<freemangordon> sure it can
<uvos> no
<freemangordon> I don;t know waht happens on d4 though
<freemangordon> I suspect WD there is not correctly setup or something
<uvos> same way it can happen on n900 (and has on older kernels)
<uvos> or maybe its not set up, but that dosent change that it can still hapen with wd
<freemangordon> if WD is correctly set-up (no way out), there is absolutely no way for device to hang forever
<uvos> ofc there is
<uvos> come one
<uvos> there millions of ways the wd can still be kicked while the device is stuck in some way
<freemangordon> no, ther eis no, this is HW engine connected to one of the reset signals
<uvos> the d4 isent really stuck either
<uvos> you can still use it over serial in this state
<freemangordon> see, I am using n900 for 11 years already
<uvos> its just parts of userspace that get stuck
<uvos> i dont care if you have been using it for 1million years
<uvos> wd is not a silver bullet
<freemangordon> yeah, right
* freemangordon is out
<Wizzup> well we disable ws reset on reboot
<Wizzup> s/ws/wd/
<Wizzup> that's why we don't have NOWAYOUT set
<uvos> no
<Wizzup> I think we do, don't we?
<Wizzup> at least we hand it back to kernel I think
<uvos> pretty sure it works
<uvos> oh on reboot
<uvos> sorry i read that wrong
<uvos> yeah its disabled at some point in the reboot process
<Wizzup> right
<freemangordon> why do we do that?
<uvos> iirc dsme get shut down
<Wizzup> because our reboot with sysvinit/openrc is too slow
<uvos> and then it would wd before its power off
<freemangordon> dsme is not touched by openrc
<freemangordon> sec
<Wizzup> we even had this do not kill pids list
_inky has joined #maemo-leste
<Wizzup> but this, what we have now, was the proper solution
<Wizzup> if kernel didn't panic and keep wd alive during panic we'd be ok
<uvos> iirc from poking around in the d4 state the problem is that agetty
<uvos> is in D state
<uvos> because of the oops
<uvos> so it cant be killed
<uvos> and init just waits for it to die forever
<uvos> this is becasue the tty subsystem is in unsable state after the oops
<freemangordon> TBH I don;t think we shall return the WD control to the kernel
<uvos> freemangordon: in this case whatever you wont help
<uvos> freemangordon: if you give wd to kernel it wont reboot
<uvos> freemangordon: if you keep dsme allive it wont eihter
<freemangordon> no, wait
<uvos> wd cant help you here
<freemangordon> the point is - dsme is not killed by openrc
<freemangordon> kernel starts to kill processes and dsme gets killed but init is not
<freemangordon> 15 seconds afted dsme gets killed, WD reboots the device
<freemangordon> or was it 1 seconds?
<freemangordon> *12
<Wizzup> we're going back to a discussion we resolved before
<freemangordon> did we?
<Wizzup> maybe read logs and issues going back to get up to date on this
<Wizzup> yes
<freemangordon> ok
<freemangordon> so, is it possible what you decided back then to be wrong?
<uvos> that is a _terrible_ thing to do
<uvos> btw
<Wizzup> it could be wrong, but let's read the older issues / logs first
<freemangordon> ok
<uvos> the time the kernel takes to shutdown after killing everything is not determistic
<freemangordon> sure, but WD timeout is controllable too, iirc
<uvos> dosent help
<uvos> just give wd back to the kernel
<uvos> the kernl has to for intance sync disks, that might mean flushing 2gb to a really slow usb stick on pp
<freemangordon> and hope for the best?
<uvos> a hard time out is _bad_
<uvos> really really bad
<Wizzup> freemangordon: imho this is a kernel problem
<freemangordon> ok, I'll try to find the log
<freemangordon> Wizzup: yeah, maybe there is some knob we can play with, maybe - "how long shall we wait for a process to die"?
<Wizzup> as I understand it getty is unkillable because of oops
<Wizzup> which prevents reboot
<Wizzup> so maybe we can skip waiting
<uvos> you could force the kenrel to just reboot
<Wizzup> but if this wasn't oops but a panic the device would I think just reboot
<uvos> but really
<uvos> just dont panic
<Wizzup> it's not a panic I think
<uvos> er oops
<uvos> yes
<freemangordon> uvos: we can;t guarantee that
<uvos> freemangordon: well you cant guarentee everything
<uvos> thats just how it is
<freemangordon> bullshit
<uvos> fucking around with the wd dosent help it just causes more issues
<freemangordon> it is reaaly not productive
<freemangordon> WD is there for a reason, don;'t you think?
<Wizzup> fwiw I agree with uvos here that we did the right thing with the handoff instead of hard timeou
<freemangordon> which I guess differs from "lets disable WD"
<uvos> right its there for the kernel to use it
<uvos> the kernel dose use it
<Wizzup> we don't disable it
<uvos> if the kernel hangs it will wd reboot
<Wizzup> it's enabled, kernel just decides it doesn't want to restart
<uvos> problem is that in this case the kernel is not really hanged so its kicking the wd
<Wizzup> or maybe openrc/sysvinit does, because getty is unkillable
<freemangordon> ok, that's why I said " yeah, maybe there is some knob we can play with, maybe - "how long shall we wait for a process to die"?"
<Wizzup> right, or we fix this oops and move on :)
<Wizzup> or make it a panic, in which case the right thing happens
<freemangordon> no, because we can;t prevent kernel from oopsing
<freemangordon> anyway
<uvos> you kan make every oops a panic
<uvos> btw
<uvos> so sure
<uvos> you could do taht
<uvos> (not right now please)
<bencoh> Wizzup: I'd suggest enabling kgdb/kgdboc instead of making it a panic
<bencoh> then you might be able to debug it some
System_Error has quit [Ping timeout: 240 seconds]
<Wizzup> well tmlind was already looking into it
<bencoh> kgdb, or the bug?
<freemangordon> the bug
_inky has quit [Read error: Connection reset by peer]
belcher has quit [Ping timeout: 240 seconds]
_inky has joined #maemo-leste
belcher has joined #maemo-leste
pere has joined #maemo-leste
_inky has quit [Read error: Connection reset by peer]
halftux has quit [Quit: leaving]
inky_ has joined #maemo-leste
belcher has quit [Quit: Leaving]
belcher has joined #maemo-leste
inky has joined #maemo-leste
inky_ has quit [Ping timeout: 240 seconds]
Twig has joined #maemo-leste
Pali has joined #maemo-leste
_inky has joined #maemo-leste
_inky has quit [Ping timeout: 250 seconds]
_inky has joined #maemo-leste
<sicelo> I like Wizzup's suggestion of purple led for d4 shutdown notification
<sicelo> Or some other noticeable color besides white. The Droid 4 has a tiny led, and for some reason the white is inconspicuous. The green works very well, so maybe purple could work good.
freemangordon has quit [Ping timeout: 240 seconds]
freemangordon has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
mjsir911 has joined #maemo-leste
<Wizzup> ok
<Wizzup> let's see if I can get this arm build machine going :)
pere has joined #maemo-leste
<Wizzup> going ro restart the server that runs some of our infra momentarily
Twig has quit [Ping timeout: 260 seconds]
mardy has quit [Quit: WeeChat 2.8]
<Wizzup> looks like I need to remove a disk :)
mepy has joined #maemo-leste
mepy has quit [Remote host closed the connection]
<Wizzup> stuff should be back
<Wizzup> ordered a disk replacement
<Wizzup> should be able to replace it by tomorrow
<uvos> so abook dosent show any conacts
<Wizzup> (16TB disk died after 2 years, wtf)
<Wizzup> uvos: do you have any?
<uvos> yeah sphone can see them, so can gnome-contacts
<Wizzup> I was going to look at syncing my n900 contacts to my d4, but didn't get to do it yet
<Wizzup> hm, ok
<uvos> i sync via dav with my android devices
<uvos> anyhow
<Wizzup> from leste?
<Wizzup> how a line on how you do that for contacts?
<Wizzup> s/how/got/
<uvos> i used gnome-contacts to set it up iirc
<uvos> it created a evolution adress book and set it as default
<Wizzup> btw, I have 8 more 10" mz tablets here it looks like
<Wizzup> should I send any out?
<uvos> not to me, mines fine
<Wizzup> ok
<uvos> you dont have mz609 right?
<uvos> ie those are mz617?
<uvos> or 615
<Wizzup> I believe so
<uvos> ok
<Wizzup> mz617
<uvos> ok - no interest
<Wizzup> I suspect they work
<Wizzup> will figure that out soon
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #maemo-leste
<Wizzup> I'm a bit upset one of my 16TB disks died that soon :/
<Wizzup> well at least it was a raid and all
<uvos> :\
<Wizzup> waiting for the replacement so I can run 'btrfs dev replace'
<Wizzup> experience thought me that just removing the missing dev and then adding one later is much, much slower
<Wizzup> anwyay
<Wizzup> hopefully tonight or tomorrow the 16core arm server is up :)
<uvos> uvos.xyz/maserati/syncevo.txt
<uvos> so thats the setup
<uvos> i suspect that abook is using the wrong addressbook
<uvos> it should let you choose (like sphone) and/or use the default address book
<uvos> freemangordon: ^^^
<uvos> 05ec7443-1cec-421a-a6c9-2bbd2892b974 is empty
<uvos> dosent work even after deating all adress books except the right one
<Wizzup> does it not have a store for its own?
<uvos> it dosent make one and is should respect eds default no?
<uvos> ie at the very least contacts in eds default should show
<Wizzup> uh, I don't think that's how it works per fmg
<Wizzup> right
<uvos> well thats wrong
<Wizzup> not sure about that, but likely
<uvos> it should not have its own it should do what its told by eds ie display the default book or the book user selects
<uvos> *book the user
<uvos> like the other frontends
* Wizzup cannot comment on what it should do
<Wizzup> ok, tomorrow I will setup the honeycomb
<Wizzup> it seems not super hard
<uvos> honeycomb?
<uvos> android 3.0
<uvos> ?
<uvos> ah the arm server
<uvos> right
<Wizzup> yes
<Wizzup> 32GB 16 cores
<Wizzup> got all the other components as well
<uvos> well 16 fairly weak cores
<uvos> anyhow cool
<uvos> how will we be manageing building for both arm archs?
<Wizzup> I will just make two KVM VMs
<Wizzup> I think that should be fine
<Wizzup> of course it will take a while because parazyd used to do it and I don't know how :)
<Wizzup> but maybe I am take the ata over ethernet image and just read it from qemu for now (ofc not using ata over ethernet)
<lel> IMbackK opened a pull request: https://github.com/maemo-leste/hildon-desktop/pull/18 (launcher: quote command sent to terminal emulator)
<uvos> Wizzup: ^^ trival correction to your patch
<Wizzup> ah
<Wizzup> this is the problem?
<uvos> yes
<Wizzup> ok
<Wizzup> mtg atm
Pali has quit [Ping timeout: 245 seconds]