1177 replies to this topic

[Erik Slagter]

Why don't we simply get samba out of the image and make it optional (feed only)? Then only the windows-file-sharing-die-hards have the disadvantage of the large image.

[littlesat]

+1

[WanWizard]

Because most people expect it to be there? I don't use it either, so I don't mind, just saying that if we decide to do this, we better communicate this up front.

[littlesat]

But when we do this it might be helpfull we create an ipk so they can install it via the UI...

[Erik Slagter]

Apparently some devs already took a shot at inflating samba and I frankly don't think it will get much smaller than this.

 

On the other hand, what is large? STB's have huge flash memories nowadays.

[christophecvr]

Well I personnally use nfs. OK my stb's are only nfs clients. and I mount the exports at boot time via fstab. I do not have nfs server on stb.

 

But could not be easier an more lightweight to install an nfs server on stb instead off samba for the interbox connections. Runs better then samba especially for stb's with GB network cards and connected in Gb network.

On the other hand users with windows pc will not have the stb anymore in there shares.

[christophecvr]

@MiLo,

 

Is there not a way to reanable easier way to habdle packages.

 

Like for development it was easy to 1) just rebuild the package or at least some packages like enigma2 and other as long the bb file was adapted to have all m4 macro's linked into build.

Then You could rebuild e2 with modified code by just using :

MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb -f -c configure
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb

After build on the box it just did

opkg install enigma2 --force-reinstall

Now this can be done anymore. I always have to at least extra run rootfs on the image (and that's really to long) this then also followed by the box first with

opkg update
opkg install enigma2 --force-reinstall

[betacentauri]

Use -b option only when you compile your local git with own changes.
If you want to compile e2 from normal openpli github git you can use
bitbake -c cleansstate enigma2
bitbake enigma2

For local git package creation don't work afaik. But you can still use "bitbake -c compile -f -b <path to local git clone>/enigma2.bb" and this builds e2 binary. Just copy binary to the box and you can test.

Edited by betacentauri, 9 January 2016 - 07:57.

[christophecvr]

Use -b option only when you compile your local git with own changes.
If you want to compile e2 from normal openpli github git you can use
bitbake -c cleansstate enigma2
bitbake enigma2

For local git package creation don't work afaik. But you can still use "bitbake -c compile -f -b <path to local git clone>/enigma2.bb" and this builds e2 binary. Just copy binary to the box and you can test.

Now that's not the problem I met.

 

Yes I use the -b option cause I rebuild modified package from an already build package. package and build is fine (I added link to all m4 macros into my bb file). And absolutely do not wan't the full image to build (parse and so that's all unneeded time). It's just one package.

 

But with master-next now we can not install the modified package anymore. That's the problem.  It's just tells You that the sources (ipk) fails is corrupt because it does I check on the file lenght, that's the problem.

 

So now to let it work (cause i just needed to reconfigure and rebuild e2 with for example a slight modification as test off something into let's say module servicemp3.c) You can not in that case use bitbake whitout the -b option. As it will start the whole parsing process and so on which is not needed and a terrible waist off time.

 

After You change You just do :

MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb -f -c configure
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb

And You will have the package which was present just overwritten. (that's enough)

 

Then You do (it always worked) By You're box

opkg install enigma2 --force-reinstall

Actually I just do it like this

init 2
opkg install enigma2 --force-reinstall
enigma2.sh

Then I can see in log what my change is doeing.

 

But now it does not do the install anymore as it breaks on that the file is corrupt  off course I do know that it's different and it must for that reason --force-reinstall is issued.

 

This always worked now anymore now I have to do

MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb -f -c configure
MACHINE=vuduo2 bitbake -b ../meta-openpli/recipes-openpli/enigma2/enigma2.bb
MACHINE=vuduo2 bitbake -b ../meta-local/recipes-local/images/cvr-image.bb -f -c rootfs

and on the box

init 2
opkg update
opkg install enigma2 --force-reinstall
enigma2.sh # to log

The fact that I have to do that rootfs is a terrible waist of time.

[betacentauri]

As said then only compile e2 binary with
bitbake -f -c compile -b .../enigma2.bb
Copy the e2 binary and the changed Python files to your box and your problem is "solved". Yes, it's so nice, because you can forget to copy a file and e2 binary is not stripped, but it works. I always do it like that, because I often only need adapted e2 binary.

[Erik Slagter]

You can strip the binary manually, look in the sdk's arch's compiler binary directory and use the strip command Otherwise it will take up (too) much space (also in RAM).

[betacentauri]

I know Sometimes I use it but not very often.
Never had problems with unstripped binary on my Xtrend boxes.

[mirakels]

I removed  'rm_work'  (takes some disk space but alas).

Then I just develop in enigma2 stage dir and start the run.do_compile in the temp dir to get it compiled again. When finished I copy the enigma2 binary to the testbox. Never had issues with unstripped enigma2.

When satisfied I run a diff on the orignal sourcs and apply that to my enigma2 git and commit.

[betacentauri]

The problem with it is that when somebody commits a new patch, the build env will download and build new version. Then you have to copy your changes to new directory or set fix commit hash in bb file.
I prefer local copy of the git. Then this cannot happen and I can merge whenever I want.

[Erik Slagter]

I start of like Mirakels, then copy (and modify!) the do_configure script that bitbake generates, copy that to my local enigma2 clone and run it there. After that, you can edit, compile (make), git commit etc. just like any other "normal" project.

 

To generate a package I temporarily change the URI in my build environment and have it point to my local enigma2 clone.

 

This also as information for those who think it's "simple" to test everything before pushing it...

[MiLo]

...
After build on the box it just did

opkg install enigma2 --force-reinstall

Now this can be done anymore. I always have to at least extra run rootfs on the image (and that's really to long) this then also followed by the box first with

opkg update
opkg install enigma2 --force-reinstall

Run "bitbake package-index" after running "bitbake enigma2", that will update the package.gz files so the box will 'see' the new ones after opkg update.

you can of course always just scp the binaries to the box (e.g. if you changed C code, just upload the new enigma2 binary).

[blzr]

In these (rare) cases I need to test something in enigma, I make changes in my cloned e2 repo, then simply build using .bb recipe included in (local) enigma2 repo

bitbake -b ~/enigma2/e2/enigma2.bb

as a result I have stripped binary, and even all e2 ipk packages

(for master-next you only need to change GST_MAJORMINOR=0.10 to 1.0 in configure.ac)

Edited by blzr, 9 January 2016 - 13:29.

[daimon]

upgrade building pli 5 dm8000 fails with this error

 

error
opkg_prepare url_for install: Could not find anything to Satisfy 'enigma2-plugin-systemplugins-frontprocessorupgrade'.

[athoik]

It will be removed soon.

diff --git a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
index 09342df..7f0921b 100644
--- a/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
+++ b/meta-openpli/recipes-openpli/images/openpli-enigma2-image.bb
@@ -59,7 +59,6 @@ ENIGMA2_PLUGINS = " \
        \
        ${@base_contains("MACHINE_FEATURES", "3dtv", "enigma2-plugin-systemplugins-osd3dsetup" , "", d)} \
        ${@base_contains("MACHINE_FEATURES", "dvb-c", "enigma2-plugin-systemplugins-cablescan" , "", d)} \
-       ${@base_contains("MACHINE_FEATURES", "frontprocessor", "enigma2-plugin-systemplugins-frontprocessorupgrade" , "", d)} \
        ${@base_contains("MACHINE_FEATURES", "hdmicec", "enigma2-plugin-systemplugins-hdmicec" , "", d)} \
        ${@base_contains("MACHINE_FEATURES", "osdposition", "enigma2-plugin-systemplugins-osdpositionsetup" , "", d)} \
        ${@base_contains("MACHINE_FEATURES", "wlan", "enigma2-plugin-systemplugins-wirelesslan", "", d)} \

[daimon]

disabling the plugin in openpli-enigma2-image.bb

the building is successful.