blzr

We have an old-type mobile with keyboard Sony Ericsson W715. I will try to rip in tomorrow how Estonian language has been presented there. The main characters are the letters õ,ä,ö,ü,š,ž, what are missing, If we are talking about Estonian SMS type keyboard.

 

As you can see on the screenshot in my previous post, I've added ä,õ, ö, š, ü, ž letters in my version;
if you'd like to test on your stb, NumericalTextInput.py with Estonian layout added attached...

And second- Estonia is just missing at the moment and I can see there English default setup. I'm investigating where the missing characters of Estonia are located on T9 keyboard (SMS Type keyboard)

 

This one from attached screen would be correct Estonian text input layout?

(I was not completely sure about Š and Ž if they should be included, and of the order of special O's...)

So OpenPLi only lacks the shellinaboxd itself (And an RRECOMMEND in its OWIF-Package)

build and tested this last evening (on pyro branch image) - worked for me
thanks!

t's a known issue (for me at least) - had this on my et9500 since some OE update last year on openpli5 / develop images:
[...]
looks like a driver in connection with some updated OE package (gcc5 most probably?) issue,
 
I was able to easily trigger this using overscan test screen,
you can test this: when your osd is missing, run overscan wizard using openwebif remote and voilà, osd is back...
 
for me the problem was that overscan apparently tended to re-appear spontaneously after e2/box restart from time to time, hence osd randomly got lost, so I just uninstalled videotune plugin, and that helped...

 
You are right, the overscan wizard brings back the OSD.
However, uninstalling the videotune plugin does not make any difference. The problem persists.

I don't have my et9500 anymore to test, but IIRC for me worked something like this:
1) 'restore' osd using overscan wizard from openwebif
2) restart e2, make sure osd is still present (!)
3) uninstall videotune plugin (that includes overscan screen)
4) restart e2, cross your fingers

actually I was never able to trigger osd dissapearance without overscan wizard, so for me after above problem was gone, but...

while you're in 'Menu' screen, press the blue button, then unhide 'Timer' menu entry with yellow...

if you want to try nginx instead of apache, here is a how-to:
https://forums.openp...ndpost&p=618400

1) git clone https://github.com/OpenPLi/enigma2.git

2) in configure.ac comment all PKG_CHECK and AC_CHECK lines

3) cd enigma2

4) ./autogen.sh

5) ./configure --with-po

6) cd po

7) make *.po

 

in enigma2/po you'll find updated .pot and all .po files

...
or we are very simple and not complicated... add the package in the same way oe-a did.... why should we keep openpli4 that clean?

I have no idea why we shouldn't simply add this python-ipaddress to the feed and call it a day...
it's a standard python package, included in openembedded, and it has nothing to do with openpli cleanliness, polluting, nor anything like this

if it's only for your own box(es) I would suggest to just allow local web access directly to the .../deploy/ipk dir on your build machine,
no need to copy whole feed after each build then...

how I set this up on nginx / lubuntu:
1) installed nginx
2) created site file for my feed, in /etc/nginx/sites-available, 'myfeed' looks like that:

server {
    listen 80 default_server;

   root /home/bart/openpli/build/tmp/deploy/ipk/;
 
location / {
        autoindex on;
    }
}

3) disabled the nginx default site

sudo rm /etc/nginx/sites-enabled/default

4) enabled new 'myfeed' site

sudo ln -s /etc/nginx/sites-available/myfeed /etc/nginx/sites-enabled/myfeed

5) restarted nginx

sudo /etc/init.d/nginx restart

now on my boxes, adjusted /etc/opkg/...all, machine, arch... feeds,
like this:

src/gz openpli-mips32el http://192.168.1.5/mips32el

that's all...

--- a/meta-openpli/recipes-openpli/enigma2-plugins/enigma2-plugin-extensions-backupsuite.bb
+++ b/meta-openpli/recipes-openpli/enigma2-plugins/enigma2-plugin-extensions-backupsuite.bb
@@ -15,7 +15,7 @@ DEST = "${D}/usr/lib/enigma2/python/Plugins/Extensions/BackupSuite"
 
 PV = "20+git${SRCPV}"
 PKGV = "20+git${GITPKGV}"
-PR = "r0"
+PACKAGE_ARCH = "${MACHINE}"
 
 RDEPENDS_${PN} = "mtd-utils mtd-utils-ubifs ofgwrite"

and to remove plugin from wetek feed also:

--- a/meta-openpli/recipes-openpli/images/openpli-enigma2-feed.bb
+++ b/meta-openpli/recipes-openpli/images/openpli-enigma2-feed.bb
@@ -105,7 +105,7 @@ ENIGMA2_OPTIONAL = " \
        softcams-enigma2-meta \
        packagegroup-openplugins \
        ${@base_contains("MACHINE_FEATURES", "blindscan-dvbs", "enigma2-plugin-systemplugins-satscan" , "", d)} \
-       ${@base_contains("MACHINE_FEATURES", "dreambox", "", "enigma2-plugin-extensions-backupsuite", d)} \
+       ${@bb.utils.contains_any("MACHINE_FEATURES", "dreambox meson6", "", "enigma2-plugin-extensions-backupsuite", d)} \
        dvb-usb-drivers-meta \
        cdtextinfo \
        meta-enigma2-dvdburn \

ok?

(can't create/test patches at the moment...)
 

@Colin
FWIW:
https://github.com/mirror/libdvdnav

@peti

I found this: https://github.com/o...b6503d0e3f72331 -

reportedly (upgraded) glibc 2.23 doesn't like bcm7405/7413 boxes for whatever reason (brodcom drivers fault?)

 

to check I built master-next image with only glibc rolled back to 2.22 and it boots and works fine...

 

not sure if we can expect any glibc fix/backport upstream, maybe older boxes simply will no longer be able to keep up with OE

 

I did a fresh fresh build from the master-next head with glibc 2.22, and compiled successfully and box is booting. Thanks for the hint. Hopefully someone can fix it, as this chip is not such ancient. 

 

ok, have some good news - today compiled master-next with yesterday's OE snapshot for my et9500, and, guess what - image boots and (at first glance) works fine

apparently glibc update to 2.24 solved our bcm7413 mysterious issue

root@et9x00:~# opkg list-installed *libc6*
libc6 - 2.24-r0

so, after next OE update in OpenPLi master-next our problematic boxes should be again in play

default mount option is defined in kernel (as @MiLo already wrote)

../fs/namespace.c

    /* Default to relatime unless overriden */
    if (!(flags & MS_NOATIME))
        mnt_flags |= MNT_RELATIME;

@peti

I found this: https://github.com/o...b6503d0e3f72331 -

reportedly (upgraded) glibc 2.23 doesn't like bcm7405/7413 boxes for whatever reason (brodcom drivers fault?)

 

to check I built master-next image with only glibc rolled back to 2.22 and it boots and works fine...

 

not sure if we can expect any glibc fix/backport upstream, maybe older boxes simply will no longer be able to keep up with OE
 

and btw I made a serial cable in the meantime, but it turned out that hyperterminal is pretty useless for investigating this issue, logs for broken and working image were the same in my case

(just ended with 'Starting program at 0x805fdb90' and that's all)

for this moment, in your local /meta-openembedded/meta-oe/files/waf-cross-answers:

ln -s cross-answers-mips.txt cross-answers-mipsel.txt