<uvos>
configureing it to display uptime like in the screenshot looks usefull to catch reboots
<sicelo>
yes, the uptime function comes built it. it's what it shows by default. then you can add other functions as you like
<sicelo>
*built in
<sicelo>
the other functions/scripts don't work, but can be easily edited/removed as needed.
<uvos>
probubly we should replace them in the package then
<sicelo>
yes, will do. this is just initial port
<sicelo>
anyway, got to think of useful scripts/functions, as many of the non-working ones aren't really important on Leste (e.g. rootfs free space - was a big deal for Fremantle)
<Evil_Bob>
hi, im running maserati-calibrate on the latest snapshot (11 april) of maemo leste on a Motorola Droid4, i get the message: mount: /tmp/pds: special device /dev/mmcblk1p7 does not exist
<Evil_Bob>
Error mounting pds
<uvos>
oh yeah
<t_rex>
same here, onboard storage is coming up as mmcblk2
<uvos>
the name of the partitions changed
<t_rex>
edit the script and you're good
<uvos>
i probubly should update the script to use uuid
<uvos>
tmlind: why did the mmc controllers get swapped around anyways?
<Evil_Bob>
ok thanks will try that
<sicelo>
you can 'unswap' them with aliases in dts - had that problem for N900 too
<Evil_Bob>
uvos: good idea or maybe /dev "by-label"
sunshavi has quit [Quit: nil]
sunshavi has joined #maemo-leste
pere has joined #maemo-leste
<tmlind>
uvos: mmc devices probe whenever depending on the regulators etc, it started (again) with commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
<Evil_Bob>
hmm i forgot, how do i insert a ":" again with the keyboard
<uvos>
ok+:
<Evil_Bob>
that doesnt work here, im on a fresh snapshot
<Evil_Bob>
do i need to run some command again to get a different keyboard layout?
<Wizzup>
uvos: what is required for that to show? reboot or some tklock change?
<Entitlement>
uvos - [ osso-systemui-tklock/visual-tklock.c at master · maemo-leste/osso-systemui-tkloc... ]
<Evil_Bob>
uvos: thanks that works, cant these commands just run at startup or at first install?
<Wizzup>
should we auto enable that gconf key?
<uvos>
if you set /system/systemui/tklock/auto_rotation and the theme has lockslider-portrait.png it will work
<uvos>
only marina and the default theme have a portrait image
<uvos>
Wizzup: no
<uvos>
Wizzup: because the lockslider is the wrong length
<uvos>
on everythin other than n900
<uvos>
so it dosent look quite right
<uvos>
because the lockslider slide length is fixed
<uvos>
while its path is part of the backgorund that gets scaled
<sicelo>
parazyd: just to be sure i remember - we don't update tag when rebuilding package because of a change in ./debian. so it means deleting existing tag from GH, and tagging latest commit with old tag name? or there's better/easier way?
<uvos>
parazyd: would you try and find out why udev is not updateing the hwdb when leste-config or kenrel updates?
<parazyd>
sicelo: If you change the debian directory, then just bump the package revision in the changelog, i.e. 1.0-1 to 1.0-2
<uvos>
tmlind: so far not really, i tryed the mesa patches and sock x glamor and after fixing a few things it fails to find a texture format it likes, not sure why. so i went ahead and tryed porting the rockchip/glamor-hybris version back to dma-but since that works on the android pvr blobs but it ends up segfaulting durin initalization.
<uvos>
meanwhile freemangordon reports that the ti pvr blobs (no mesa) segault in a different place with stockish glamor
<tmlind>
heh ok
<uvos>
honestly havent been able to put that mutch time into it either
<tmlind>
yeah ok
<tmlind>
well i'll update droid4-pending-v5.10 to v5.10.30, let's see if that helps
<uvos>
tmlind: did you have to change mutch for 5.11 pvr crap?
<uvos>
tmlind: if no maybe bisecting the pvr traces might be viable
<parazyd>
uvos: Added the Trojita package to jenkins
<tmlind>
uvos: no nothing really, i think the the only change is the memory stuff
<parazyd>
Can you let me know what/where is the 5.10 SDMA patch we should apply for droid4-linux?
<tmlind>
uvos: hmm looks like PVR_LINUX_MEM_AREA_USE_VMAP was there already since v5.8
<uvos>
tmlind: thats nice... i have no idea what that is or why you mention it :P
<tmlind>
uvos: well you asked if i did any changes, and i though that was the only change, but nope that was done earlier too
<uvos>
ok
<uvos>
check
<uvos>
thanks
<uvos>
so i could just bisect between 5.10 and 5.11 for the traces while carrying pvr as a patch
<tmlind>
uvos: i just merged v5.10 pvr stuff to v5.11, so it should be the same thing unless i made a mistake with the merge
<tmlind>
uvos: no clue why that would start happending between v5.10 and v5.11
<tmlind>
anyways, if we can get v5.10 working we can forget v5.11 then..
<parazyd>
I just started the latest 5.10 build and reintroduced the dma patch
<parazyd>
Let's see if that works out
<tmlind>
ok
<uvos>
would be pretty wierd if that works
<uvos>
but 5.11 is fine without
<uvos>
that makes me fear the reboot issue could re-emerge later...
<tmlind>
well pretty much all the fixes i did over the xmas holidays are already there in v5.10.30, it would be possible to just apply the all backports and pending patches in v5.12 branch.. probably no need for that though
enyc has quit [Ping timeout: 246 seconds]
<parazyd>
We could keep updating it more often and then figure out by bisecting I guess
<parazyd>
In case it starts happening again on 5.11
<uvos>
nah 5.11 is fine
<uvos>
also 5.12
<tmlind>
i'm fairly certain that the random reboot issue is out of the way for good, i suspect we may have some other patch missing in v5.10 so merging v5.10.30 might have cleared that whatever it might be
<parazyd>
*fingers crossed*
<tmlind>
so does v5.10 suffer from random hangs or something else?
<parazyd>
Random reboots atm
<parazyd>
Merged .30 now, so we'll see
<tmlind>
parazyd: so a random reboot without a hang first? or a hang, then reboot?
<uvos>
we dont know
<uvos>
i dont think any of us have seen it
<tmlind>
heh
<uvos>
but several users report
<parazyd>
Evil_Bob got it today ^
<uvos>
also clort
<tmlind>
well the tracing bug could be still there in v5.10.30 too, but tracing is still disabled for v5.10 branch, right?
<tmlind>
folks should check if there are any files in /sys/fs/pstore on next boot after a random reset like we had for the tracing oops
<parazyd>
We don't sidable CONFIG_FTRACE if that's what you mean
<tmlind>
right thanks for checking for the n th time :)
<parazyd>
:D
<tmlind>
hmm so on boot, if files in /sys/fs/pstore, copy them to /var/log?
<parazyd>
With some debug initscript?
<parazyd>
Maybe a good idea, yeah
<tmlind>
yeh as /sys/fs/pstore is memory backed
<tmlind>
then we can ask users if they have any /var/log/console* files
<tmlind>
parazyd: perfect, and that can be tested with echo c > /proc/sysrq-trigger
<parazyd>
ok
<parazyd>
I could add this to hildon-base then
<tmlind>
sounds good to me
<tmlind>
parazyd: is v5.10 branch missing the pstore patch though?
<parazyd>
Yeah heh
<parazyd>
rip
<tmlind>
want me to apply that to droid4-pending-v5.10?
<parazyd>
If you think it makes sense. I could also just add it to our debian/patches.
<parazyd>
lmk
<tmlind>
i'll apply it to droid4-pending-v5.10, let me make sure it builds and works
<parazyd>
Thanks
<tmlind>
parazyd: seems to work, pushed out updated droid4-pending-v5.10
<parazyd>
ty
<parazyd>
I'll cancel the current build
<tmlind>
parazyd: ok, what's the default watchdog timeout now? the default 120 might be too long for folks to wait before restarting manually
<parazyd>
We don't change anything IIRC
<tmlind>
ok, 30 secs might be too short for fsck for example, 60 sounds about right
<tmlind>
anyways, at least now we can just ask folks to wait for a watchdog reset and check for logs
<parazyd>
Right
<parazyd>
I updated hildon-base right now, so once users update they should have the initscript in sysinit runlevel.
<tmlind>
parazyd: that 0004-enable-debug-slab.patch never showed any issues, should we just drop it? the performance penalty might be bad with that one
<parazyd>
I took the liberty to enable it by default for everyone, as we're still in the testing stage
<parazyd>
tmlind: Yeah I think we could.
<parazyd>
I'll put it in my TODO, let's first see if the current build solves the reboots
<tmlind>
parazyd: cool, i can test your pstore script change on bionic when it's pushed, this with v5.11 devel kernel on my bionic
<Entitlement>
parazyd - [ Add initscript for saving pstore contents to /var/log if there is any. · maemo-l... ]
<tmlind>
ok
<parazyd>
biab, should cook dinner
<siceloa>
parazyd any idea why ham stops accepting input when gdb attaches to it
<tmlind>
uvos: you might want to build the bionic bootloader kernel with the pstore patch if not done, otherwise the pstore memory can get corrupted during the boot :)
<uvos>
tmlind: ok ill try doin that and upgrading it from 5.8 in the process
<uvos>
its without the patch atm
<tmlind>
uvos: cool, otherwise it will be flakey
<tmlind>
parazyd: nice, it works, i see a file on bionic after doing echo c > /proc/sysrq-trigger and waiting for a reboot :)
<tmlind>
uvos: the /var/log/pstore/ file is corrupt as suspected though
<tmlind>
but should work ok on droid4
<tmlind>
parazyd: i did not see the updated hildon-base after apt update, i installed it manually, is there some delay with generating the list maybe?
<uvos>
siceloa: "gdb -p 7836" (hildon) and then "continue" works perfectly fine for me
<siceloa>
Thanks. That was the missing step - continue
<uvos>
you are welcome
<parazyd>
tmlind: Weird, I get the update here. There's no delay between a finished build and it being in the repo.
<parazyd>
Could be flaked out, try an 'apt clean' to be safe
<tmlind>
parazyd: i have beowulf-devel main contrib non-free droid4 bionic, that should do, right?
random_yanek has quit [Ping timeout: 260 seconds]
<tmlind>
parazyd: beowolf-devel Contents* files still show up timestamp from the 13th while beowolf has 14th
<parazyd>
tmlind: Append both "droid4" and "bionic" for the bionic on the maemo repos
<parazyd>
tmlind: And append only "droid4" for the droid4
<parazyd>
-devel is basically an overlay on top of the main one
<parazyd>
It only contains certain packages which weren't promoted to stable
<parazyd>
note-to-self: Rethink this terminology
<tmlind>
yeah ok will add back the beowolf line, i probably just edited that line originally to change it to beowolf-devel
<parazyd>
++
<tmlind>
ok updated and rebooting now :) yup a bunch of packages got updated
<parazyd>
Nice
<parazyd>
gl
<parazyd>
:D
<tmlind>
ok thanks & ttyl
<parazyd>
o/
* parazyd
kinda liking the atmosphere here lately :)
<sicelo>
parazyd: btw, when a de[vu|bi]an package provides a file in /etc/default/ , and you make changes to that file, does it survive upgrades, or it will likely get overwritten?
<sicelo>
or, better question, how to ensure one's config is always honored even after package upgrade, while it is different from the one provided upstream? specifically, i'm talking about dnsmasq
<parazyd>
It usually stays if edited
<sicelo>
that's the config, or /etc/default?
<sicelo>
i know config pops up that option to choose what you want to happen
<parazyd>
/etc/default
<parazyd>
Other stuff has an interactive prompt
<parazyd>
But I don't know how to trigger it
<parazyd>
Would have to look at some package
<parazyd>
I know that the jenkins (actual software) package does this
<parazyd>
Because I changed the initscript and then got an overwrite prompt on update
<parazyd>
Also if you export DEBIAN_FRONTEND=noninteractive then it won't ask you anything nor will it overwrite the file
<uvos>
parazyd: this works in mce too witch has simple packaging
<parazyd>
Do you remember for which file?
<uvos>
mce.ini
<uvos>
also everything in mce.ini.d
<parazyd>
ah interesting
<uvos>
i gues /etc is a hureistic
<parazyd>
Yeah I guess it is
cockroach has joined #maemo-leste
devrtz has quit [Ping timeout: 258 seconds]
devrtz has joined #maemo-leste
<sicelo>
Wizzup: if you're around and have a moment - when connecting to cellular data, what component actually assigns the received IP address to the modem interface?
<Wizzup>
sicelo: the ipv4 module I believe (doing dhcp)
<Entitlement>
sicelo - [ icd2/busybox-udhcpc: Respect DNS (resolv.conf) from DHCP upon connection · Issue... ]
<Wizzup>
I think we might use dnsmasq, but for ofono/cellular I'm not sure if we want to use the old fremantle scripts
<Wizzup>
I think if we use the icd2 ipv4 module, it should work mostly the same as wifi
<sicelo>
we already have the scripts packaged for leste (as part of libicd-network-ofono), and i think they're good, because they make the DNS work the same way - whether it's wifi or gprs. we're also already using fremantle's scripts for the other network links (e.g. wifi), as found in /etc/50_ipv4_network_setup
<parazyd>
Yeah @ dnsmasq
<parazyd>
I'll set it up for default install these days
<parazyd>
The icd scripts already have some of this dnsmasq logic leftover from fremantle
<parazyd>
I'll also move this cell connectivity stuff to main soon
<parazyd>
Latest droid 5.10 kernel built for main btw.
<parazyd>
Tomorrow I'll build a fresh image locally to test and see what's happening