uvos has quit [Remote host closed the connection]
vectis has quit [Ping timeout: 268 seconds]
sch has quit [Ping timeout: 252 seconds]
sch has joined #maemo-leste
noidea__ has joined #maemo-leste
noidea_ has quit [Ping timeout: 268 seconds]
akossh has quit [Quit: Leaving.]
xmn has quit [Ping timeout: 256 seconds]
mdz has quit [Ping timeout: 256 seconds]
vectis has joined #maemo-leste
f_ has quit [Read error: Connection reset by peer]
mqlnv has quit [Ping timeout: 256 seconds]
f_ has joined #maemo-leste
sch has quit [Ping timeout: 268 seconds]
sch has joined #maemo-leste
mqlnv has joined #maemo-leste
Juest has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
Juest has joined #maemo-leste
nmdv has joined #maemo-leste
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
nmdv has quit [Read error: Connection reset by peer]
<freemangordon> uvos: re locales: Nokia managed to avoid building on device, by pre-building on image-builder
<freemangordon> umm, in auto-builder, not image-builder
<freemangordon> perhaps we can create a package that contains pre-build locales and tracks libc6
nmdv has joined #maemo-leste
ceene has joined #maemo-leste
<freemangordon> or, we can just not enable anything but en_GB on the image, and provide an UI for user to add more locales as she wants
mdz has joined #maemo-leste
ceene has quit [Ping timeout: 260 seconds]
slep has joined #maemo-leste
ceene has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
xmn has quit [Ping timeout: 264 seconds]
akossh has joined #maemo-leste
ceene has quit [Remote host closed the connection]
ceene has joined #maemo-leste
mdz has quit [Ping timeout: 256 seconds]
mdz has joined #maemo-leste
<sicelo> i think en_US would be better than en_GB, or at least both then. many locales inherit from en_US afaik
<Wizzup> freemangordon: debian rebuilds them upon libc upgrade only
<Wizzup> so when people flash an image they don't run into rebuilding issues
<tmlind> Wizzup: nice if you got m-l image in works for mz617 :) have not seen the atmel_mxt_ts issue, then again i've mostly used it without a gui so far
<Wizzup> yeah it works quite smooth :)
<inky> important lagrange update: gemini://bbs.geminispace.org/s/Lagrange/13969 - i need to make an update.
sch has quit [Ping timeout: 252 seconds]
sch has joined #maemo-leste
<Wizzup> inky: check
<inky> check what? i am building it on device now to test, then will try in phoenix.
<Wizzup> inky: as in confirm
<Wizzup> as in ok
<Wizzup> :)
mdz has quit [Ping timeout: 252 seconds]
noidea__ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
udder has quit [Quit: die in fire]
udder has joined #maemo-leste
xmn has joined #maemo-leste
zeta_ has joined #maemo-leste
<freemangordon> Wizzup: yes, but on libc upgrade, it takes ages
<Wizzup> yup
<Wizzup> like I said, just edit /etc/locale.gen
<Wizzup> I am not sure if we need a UI for that now
<freemangordon> but, we can do it on the opposite - enable only en_GB in /etc.locale.gen by default
<Wizzup> I would do en_US like sicelo said, but yes
<Wizzup> this is easy and I think the image builder or leste-config does this
<freemangordon> and then "just edit /etc/locale.gen"
<freemangordon> yes
<freemangordon> why US?
<Wizzup> # TODO: Do this through a package when we have a language-changing package
<Wizzup> # Generate locales
<Wizzup> apt-cache search hildon-common-strings-l10n \ | grep -v mr0 \ | awk -F'[()]' '{printf "%s.UTF-8 UTF-8\n", \$2}' \ >> /etc/locale.gen
<Wizzup> locale-gen
<Wizzup> freemangordon: that's the default on basically all systems
<Wizzup> we also set it as default as you can see in the chimaera.blend file
<freemangordon> not on fremantle though
<Wizzup> freemangordon: I don't think fremantle ever regenerated them
<Wizzup> in any case I really don't care enough about the default locale, if you want it to be en_GB that is fine but then please deal with fallout if any
<Wizzup> so how do we manage locale.gen going forward? it needs to be through some package
ceene has quit [Ping timeout: 245 seconds]
<Wizzup> uvos: later tonight and/or tomorrow I will bring two droids to my desk, one with leste on it and one with android, hopefully you can help me figure out what might cause the instability
nmdv has quit [Ping timeout: 264 seconds]
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
<bencoh> Wizzup: I don't think forcing too many locales to the user is a good idea, because regenerating it takes a lot of time on aging platforms
<Wizzup> yes, we're in agreement I think
<bencoh> ah okay
<Wizzup> right now we're generating /all/ of them
<Wizzup> the question is, how does the user control which ones he/she wants
<bencoh> oh, I see
<bencoh> yeah, that's the question indeed
<Wizzup> right now I think the only ones visible in the settings UI are the *generated* ones
<Wizzup> so we can just tell people 'sudo vi /etc/locale.gen && locale-gen'
<Wizzup> I'm fine with that
<Wizzup> but then some pkg should 'own' locale.gen, or otherwise we can't bring it as an update, but that then means that user choices could be reverted by upgrades, etc
<Wizzup> could be some hacky one-shot postinst script I suppose
uvos has joined #maemo-leste
<uvos> please use en_US as the default locale
<uvos> idk about gb but de_DE causes alot of stupid bugs in dumb scripts, i dont think it makes sense to rock the boat just because fremantle
<uvos> en_US is simply the universal default, and everthing that is unintentioally broken on other locales works in en_US
<uvos> Wizzup: btw yes cpufreq works again in 6.6 after depmod
<uvos> so was just that
<Wizzup> cool
<uvos> wait no
<uvos> i just booted the wrong thing :D
<uvos> nvm
<Wizzup> how do you test?
<uvos> cat /sys/bus/cpu/devices/cpu0/cpufreq/ is missing
<freemangordon> in our localisation packages, en_GB is the base locale
<freemangordon> so that makes it the default
<freemangordon> everything else is based on en_GB
<Wizzup> uvos: # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not set
<Wizzup> is that a problem?
<freemangordon> heh
<freemangordon> that might explain cpufreq not being loaded
<Wizzup> there is also
<Wizzup> # CONFIG_PM_DEVFREQ is not set
<sicelo> freemangordon: ok. i think having both is fine then :-)
<freemangordon> why?
<freemangordon> why exactly you need en_US?
<freemangordon> for non-maemo packages?
<Wizzup> the world runs on en_US, it's the default everywhere, and I don't think it will negatively affect maemo
<Wizzup> it's also mostly a non-issue I think, which is why I don't care :D
<Wizzup> in fact, as stated before, it is -currently- the default on maemo leste
<freemangordon> "freemangordon: in our localisation packages, en_GB is the base locale"
<uvos> Wizzup: yeah thats wierd but here is 6.1 # CONFIG_ARM_OMAP2PLUS_CPUFREQ is not se
<uvos> so this dident change
<Wizzup> freemangordon: that's fine, but the d4 in your pocket uses en_US and clearly the maemo locales work
<freemangordon> no
<freemangordon> it uses en_GB
<uvos> i dffed the config and its the same between 6.1 and 6.6
* freemangordon checks
<uvos> and its the same besides additions
<Wizzup> uvos: strange
<uvos> ofc one of those could now be required idk
<freemangordon> English (United Kingdom) ;)
<Wizzup> can you share output of 'locale'
<freemangordon> LANG=en_GB.utf-8
<Wizzup> ok, then you manually changed it
<freemangordon> sure
<Wizzup> mine is English (United States)
<sicelo> mine's en_US too (n900). i can't swear to it, but i'd like to think i never changed it
<Wizzup> I linked the image-builder scripts and it set it to en_US
<freemangordon> Wizzup: the pont is - in every osso- localisation package, the locale every other locales are based on is en_GB
<Wizzup> so no need to check
<uvos> LANG=en_US.utf-8
<Wizzup> freemangordon: fine then change it and please deal with the fallout if any
<uvos> dident change it besides LC_NUMERIC=de_DE.utf-8
<Wizzup> I'm sure there will be some funny error messages popping up that aren't quite googleable because they are slightly different
<Wizzup> I just /really/ don't care about the default locale so I don't want to waste energy on it
<sicelo> otherwise yes, i also don't think en_GB would adversely affect my usage ... i'm just used to en_US
<uvos> error: user missing trousers
* sicelo thinks someday there should be en_SZ :p
<freemangordon> Wizzup: see, I am trying to understand why the obsession on US
<uvos> because most software is terrible
<Wizzup> freemangordon: no obsession, it's just the default everywhere
<uvos> and since its the default everywhere most terrible software works correctly so
<freemangordon> sicelo: IIRC, default in fremantle is en)GB, fro the reason I stated above
<uvos> :P
<Wizzup> all my machines are also en_US because I don't want coredumps to use a different word that isn't googleable
<uvos> googleablilty is a good point
<freemangordon> ok
<freemangordon> so be
<Wizzup> I checked my fremantle and it is en_GB
<freemangordon> yes
<freemangordon> I know
<Wizzup> I don't know enough how locales work but I think there shouldn't be any problems showing english to the user either way
<Wizzup> (that's a serious question)
<gnarface> dpkg-reconfigure locales?
<uvos> main issue i encourter is locale aware parsers being used in places they should not causing issues
<uvos> bane of ones existance with scientific software/scripts parsing csv files and things
<freemangordon> ok, lets have both US and GB
<Wizzup> gnarface: good point, we didn't consider how debian handles this
<freemangordon> the issue with US as default is that there might be osso- localisation packages that has GB but not US entry
<gnarface> i see a lot of people mangling the settings ala-carte, the dpkg-reconfigure script will at least set all the environment variables right as a set
<Wizzup> freemangordon: so the way controlpanel regional plugin works is that it only looks at the generated locales, so then users won't /see/ the other languages
<freemangordon> Wizzup: yes, I know
<Wizzup> 16:47 < freemangordon> the issue with US as default is that there might be osso- localisation packages that has GB but not US entry
<Wizzup> so that was my question
<Wizzup> I think the en_ prefix just means there is a fallback
<Wizzup> but that is an assumption
<freemangordon> not sure either
<gnarface> i think the pine64 keyboards may also need en_GB-altgr or whatever it's called
<Wizzup> freemangordon: I see maemo text just fine and mine is set to en_US
<Wizzup> so probably it just works
<uvos> worste case it ends up with effectively C as locale or which is also english?
<uvos> not sure
<gnarface> (some of them, anyway)
<freemangordon> no, probably there is no issue wieh US localisation
<Wizzup> I think keyboard layout is independent from localisation
<Wizzup> well at least on a 'locale' leven
<Wizzup> level*
<freemangordon> Wizzup: regarding locales not listed - I think it is very easy to add one more touch selector "add locale" to cpl applet
<gnarface> oh, yes it's "dpkg-reconfigure keyboard-configuration" but you often find you have to set both of these to a coherent set
<freemangordon> I can take on that
<Wizzup> ok
<freemangordon> I just need the full list of locales we want to support
<uvos> gnarface: not on leste as lots of people use droid4s with only us keyboards
<freemangordon> but I can take that from the image
<bencoh> Wizzup: sounds like the regional panel would need an additional 'install languages/locales' panel to modify /etc/locale.gen ?
<gnarface> TBH though my suggestion would just be to make it clear for users how to change both, and not weigh the base install down with lots of them
<gnarface> ... not that i have any horse in this race, just an opinion
<Wizzup> gnarface: yeah I think we're (all) in agreement
<Wizzup> currently the base install has /all/
<Wizzup> which isn't really an issue until they need to be re-generated or you need to fix leste in a 800MB partition because of locked bootloaders :P
<bencoh> :]
<uvos> thers also the l10n packages
<freemangordon> bencoh: "(17,48,17) freemangordon: Wizzup: regarding locales not listed - I think it is very easy to add one more touch selector "add locale" to cpl applet"
<freemangordon> :)
<bencoh> yeah
<Wizzup> uvos: yes, that would need to be sorted via a meta pkg too
<uvos> its a bit annoying that one is forced to have so many l10n packages installed for languages one dosent speak
<freemangordon> uvos: I think we are in agreement here
<freemangordon> we'll have only GB and US pre-enabled
<freemangordon> and controlpanel UI to add/remove
<Wizzup> what about mountain german
<freemangordon> what about it?
<uvos> i dont speak that
<Wizzup> freemangordon: it was a joke
<freemangordon> I know
<freemangordon> my point was - no issue with it, lets add it as well :p
<Wizzup> there's no austrian locale it looks on leste atm ;)
<freemangordon> Wizzup: but yeah, we need a package
<Wizzup> can you make an issue for this? or maybe two?
<Wizzup> uvos: I'm booting my leste droid3 and also charging the android one
<Wizzup> in case you'd have some time at some point
<freemangordon> they don;t deserve, forcing me waiting hours on the Greek border :p
<freemangordon> Wizzup: no, I'll just implement as soon as I have some spare time
<Wizzup> wait austria doesn't border greece
<Wizzup> freemangordon: cool
xmn has quit [Ping timeout: 264 seconds]
<freemangordon> yeah, but they stopped BG from full Schengen
<Wizzup> oh yeah, before that it was just NL for 10 years
<freemangordon> yeah, but NL played it generous just before NY
<freemangordon> it is only Austria stopping us
<freemangordon> well, they allowed air and see
<Wizzup> I'm sure they'll resolve it soon
<freemangordon> but not the land
<freemangordon> will, see, but until then no locale in leste :p
<uvos> "wait austria doesn't border greece" laughs in 1915
<Wizzup> uvos: something I also notice when I use clownboot on the d3, the screen backlight flickers a bit when a usb cable is plugged in
<uvos> Wizzup: hmm
<uvos> Wizzup: strange
xmn has joined #maemo-leste
<Wizzup> uvos: in any case I need to do some work but if there is a good time to bug you about the d3 let me know
<uvos> Wizzup: so the first thing would be https://github.com/tmlind/cpcaprw
<uvos> dump that in android at the same oop as mainline and see if we are missconfigureing any regulators
<uvos> the d3 has a special kernel so really anything could be different
<uvos> could maybe also make sense to look at omap-emif since the memory chip is the other thing thats quite different
<Wizzup> how could I ensure things are at the same oop?
<uvos> examine the d3 stock dts diffed against the xt875 one again and the signal map
<uvos> Wizzup: you can use cpu freq to force the oop
<Wizzup> in android?
<uvos> yes
<uvos> clowboot dose it in the script even
<uvos> just before kexec
<Wizzup> ok
<uvos> so look ther
<uvos> e
<Wizzup> hm, I don't have armel cross, only armhf (for cpcaprw)
<Wizzup> well, let's see if I can fix that
<uvos> i would strongly recommend using the android sdk
<Wizzup> if you have a binary around, could you share it? that would save me getting the whole android sdk/ndk
<uvos> but im not sure what api level i compiled this against
<uvos> if it compiled it agains api level 15/android 4.0 it wont work on droid 3 which is api level 9 or 10
<Wizzup> ok, when my d3 is charged we will see
nmdv has joined #maemo-leste
<Wizzup> heh this one is the chinese droid 3 :)
<Wizzup> xt883
xmn has quit [Ping timeout: 268 seconds]
<uvos> oh and dont do this via adb
<Wizzup> don't do what?
<uvos> we want the no usb connected state
<Wizzup> oh, that will be new for me
<uvos> just use the android build in terminal on device
<Wizzup> ok
<uvos> you have to go to settings -> device proparties (or so)
xmn has joined #maemo-leste
<uvos> and click on the build number 10 times
<uvos> then you get a new developer entry in settings
<uvos> there you can unhide the build in terminal
<uvos> otherwise the cpcap regs will have a bunch of spurious differences
<uvos> as the mainline kernel dosent setup charging the same way
<Wizzup> otherwise -> if using adb over usb ?
<uvos> you will have lots more registers to lookup after the diff with the mainline kernel
<Wizzup> ok, I'll try to get this set up in the next few hours
uvos has quit [Quit: Konversation terminated!]
nmdv has quit [Ping timeout: 264 seconds]
brosame has joined #maemo-leste
sch has quit [Ping timeout: 256 seconds]
sch has joined #maemo-leste
sch has quit [Ping timeout: 252 seconds]
akossh has quit [Quit: Leaving.]
sch has joined #maemo-leste
sch has quit [Ping timeout: 256 seconds]
apoage2 has joined #maemo-leste
apoage2 has quit [Client Quit]
sch has joined #maemo-leste
ashley has quit [Ping timeout: 245 seconds]
slep has left #maemo-leste [#maemo-leste]
diejuse has joined #maemo-leste
<diejuse> Hello everyone