32 replies to this topic

[A.A.]

Up to this commit on bitbake [1]  it was possible to use globs, even though deprecated (read commit).

 

I am now testing meta-openpli with OE master-next and have these two parsing failures (checksum check):

 

ERROR: ExpansionError during parsing /oe/meta-openpli/recipes-openpli/enigma2/settings-autorestore.bb

 

ERROR: ExpansionError during parsing /oe/meta-openpli/recipes-openpli/enigma2-channelsettings/enigma2-plugin-settings-ziggo-casema-west_20110326.bb

 

 

URL: 'file://*' has invalid parameters. file:// urls using globbing are no longer supported. Please place the files in a directory and reference that instead.

 

 

I'd say it would be better to add a tarball at this point, with proper checksum.

Any thoughts?

 

A.A.

 

 

 

[1] https://git.openembe...1001d63f668bdf7

Edited by A.A., 10 July 2021 - 11:18.

[WanWizard]

I think it needs to be looked at on a per-recipe basis.

 

Autorestrore is only two files, and it's better to list them individually, which also makes them easier to maintain. 

 

That settings recipe is 10 years old, not very relevant anymore I'd say, but those are files that go onto the box as-is, so there a tarball would be the obvious choice ('ll remove this recipe).

 

i.e. it depends on what the files are.

[A.A.]

Ok,

I see you removed the ziggo-casema thing, the problematic one.

 

After fixing the settings-autorestore there is now much to do, minor cleanings and, what worries me more, many dangling .bbappends.

These must be verified one-by-one.

 

https://pastebin.com/jR0S7L3M

 

 

Cheers

A.A.

[WanWizard]

Normally when we start preparing the next major release, we create a special OE branch for it, so all these things can happen without impact on the current develop (which may still have to produce minor releases like now 8.1).

[A.A.]

Just for info, I am adding meta-openpli to my core setup, the original one: http://www.openembed...tandalone_Setup

 

So I am insulating the BSP (meta-vuplus) and the DISTRO:

 

$ cat /oe/oe-core/build/conf/local.conf
...
MACHINE ??= "vuduo2"
INHERIT += "rm_work"
TMPDIR = "/tmp/build/tmp-${TCLIBC}"
TCLIBC = "musl"
#require conf/distro/include/security_flags.inc

# DISTRO   OpenPLi
require conf/distro/openpli.conf

 

$ ls /oe
bitbake     meta-openpli  meta-qt5     oe-core 
meta-openembedded     meta-python2  meta-vuplus

 

 

$ cat /oe/oe-core/build/conf/bblayers.conf
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /oe/oe-core/meta \
  /oe/meta-openembedded/meta-oe \
  /oe/meta-openembedded/meta-multimedia \
  /oe/meta-openembedded/meta-networking \
  /oe/meta-openembedded/meta-python \
  /oe/meta-python2 \
  /oe/meta-qt5 \
  /oe/meta-vuplus \
  /oe/meta-openpli \
  "

I must verify about versions in reporefs.conf, I hope its scope is limited to meta-openpli.

 

A.A.

Edited by A.A., 10 July 2021 - 22:36.

[Dimitrij]

 

WARNING: vuplus-blindscan-utils-vuduo4k-5.1-r0 do_package: QA Issue: vuplus-blindscan-utils-vuduo4k: Files/directories were installed but not shipped in any package:
  /usr/bin/.debug
  /usr/bin/.debug/bcm3148
  /usr/bin/.debug/bcm3466
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
vuplus-blindscan-utils-vuduo4k: 3 installed and not shipped files. [installed-vs-shipped]

 

[A.A.]

I have sent PR for adapting to the recent bitbake.

 

Now remaining just the custom .bbappends:

 

$ bitbake -p openpli-enigma2-image
Loading cache: 100% |############################################| Time: 0:00:00
Loaded 2473 entries from dependency cache.
Parsing recipes: 100% |##########################################| Time: 0:00:43
Parsing of 3426 .bb files complete (1642 cached, 1784 parsed). 5057 targets, 820 skipped, 0 masked, 0 errors.
ERROR: No recipes in default available for:
  /oe/meta-openpli/recipes-core/busybox/busybox_1.31.%.bbappend
  /oe/meta-openpli/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
  /oe/meta-openpli/recipes-devtools/binutils/binutils-cross_2.32.bbappend
  /oe/meta-openpli/recipes-devtools/binutils/binutils_2.32.bbappend
  /oe/meta-openpli/recipes-devtools/opkg/opkg_0.4.1.bbappend
  /oe/meta-openpli/recipes-extended/libtirpc/libtirpc_1.1.4.bbappend
  /oe/meta-openpli/recipes-extended/redis/redis_4.0.%.bbappend
  /oe/meta-openpli/recipes-extended/wget/wget_1.20.3.bbappend
  /oe/meta-openpli/recipes-filesystems/fuse-exfat/fuse-exfat_1%.bbappend
  /oe/meta-openpli/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_20%.bbappend
  /oe/meta-openpli/recipes-graphics/gtk/gtk+_2.24.32.bbappend
  /oe/meta-openpli/recipes-graphics/libsdl2/libsdl2_2.0.10.bbappend
  /oe/meta-openpli/recipes-graphics/xorg-lib/xkeyboard-config_2.27.bbappend
  /oe/meta-openpli/recipes-multimedia/servicehisilicon/enigma2-plugin-systemplugins-servicehisilicon.bbappend
  /oe/meta-openpli/recipes-multimedia/v4l2apps/v4l-utils_1.16.5.bbappend
  /oe/meta-openpli/recipes-support/atk/at-spi2-atk_2.32.0.bbappend
  /oe/meta-openpli/recipes-support/fuse/fuse_2.9.%.bbappend
  /oe/meta-openpli/recipes-support/gdbm/gdbm_1.18.1.bbappend
  /oe/meta-openpli/recipes-support/libtalloc/libtalloc_2.3.0.bbappend
  /oe/meta-openpli/recipes-support/libtevent/libtevent_0.10.1.bbappend
  /oe/meta-openpli/recipes-webkit/webkit/enigma2-plugin-extensions-hbbtv-webkit.bbappend
  /oe/meta-openpli/recipes-webkit/webkit/webkit-classic.bbappend

Summary: There was 1 ERROR message shown, returning a non-zero exit code.

 

[WanWizard]

 /oe/meta-openpli/recipes-multimedia/servicehisilicon/enigma2-plugin-systemplugins-servicehisilicon.bbappend

should not be there at all, that should be a PR on the servicehisilicon repo.

[rantanplan]

@A.A.

 

bitbake oe-embedded and oe-embedded-core are mutually dependent.
It is not expedient to update only one of these three depends in isolation.
This then leads to such error messages.

Should you switch from the Zeus branch to the next more up-to-date version, then you would automatically have to worry about whether python 2.7 will be continued.
Likewise the used openssl is likely to be updated.
For me, the Zeus branch for python 2.7 is exactly the last current branch.
Far from exhausted and there is still enough potential to optimize.

The goal should still be to create an image that is as stable as possible and that is possible for all receivers.

greetings

[A.A.]

@A.A.

 

bitbake oe-embedded and oe-embedded-core are mutually dependent.
It is not expedient to update only one of these three depends in isolation.
This then leads to such error messages.

Should you switch from the Zeus branch to the next more up-to-date version, then you would automatically have to worry about whether python 2.7 will be continued.
Likewise the used openssl is likely to be updated.
For me, the Zeus branch for python 2.7 is exactly the last current branch.
Far from exhausted and there is still enough potential to optimize.

The goal should still be to create an image that is as stable as possible and that is possible for all receivers.

greetings

Sorry I am maybe misreading your message, is saturday here

I have both oe-core and meta-openembedded at master-next.

Cheers

A.A.

[rantanplan]

That's the problem.
You created a PR related to a different build environment.
 

Of course, you can also work locally from the master next, but the resulting results cannot be ported to other branches.

[A.A.]

That's the problem.
You created a PR related to a different build environment.
 

Of course, you can also work locally from the master next, but the resulting results cannot be ported to other branches.

Why do you say that?

These slashes are nothing good, same for the lazy glob in SRC_URI, finally the RPROVIDES_append_class-native is just wrong.

 

My PR can/should be backported.

If you have anything against this PR please comment on github with valid reasons, thanks.

 

Please do not pollute this thread, maybe you missed the point: this is a glimpse from the future

 

Cheers

A.A.

[WanWizard]

Please do not upgrade OE in a PR.

 

Upgrading OE should not be underestimated, it is really weeks and weeks of work, and should be done in a different branch because it requires an awful lot of testing as well.

[A.A.]

Sorry, probably I can not express myself properly.

 

One last retry for today: I did upgrade bitbake, oe-core, meta-openembedded up to master-next.

After that I have added meta-vuplus and meta-openpli layers, both updated to the last commits.

 

Recipe-parsing with newer bitbake revealed some hidden issues in the metadata.

The errors are there, it is just that the new bitbake / OE QA check are more clever and reveal the problems.

 

You will stumble in these errors in the future, once you'll upgrade bitbake/OE.

 

I am fixing this for you in advance.

Say at least thanks.

 

Regards

A.A.

[WanWizard]

I feel a lot here is "lost in translation" .

 

If with fixing you mean fixing the recipes in develop with the current OE, I'm all for it, absolutely.

[Persian Prince]

@A.A.

 

Just to let you know you don't need to use -next branches.

[A.A.]

@A.A.

 

Just to let you know you don't need to use -next branches.

From the POV of a distro maintainer, no, absolutely not needed.

 

As OE developer, this is the right thing to do if you are not scared about bleeding edges.

I do my builds on master-next and help the maintainers to fix things or, more frequently, to fix the new regressions introduced in OE.

 

As for OpenPLi, there are only good news: the meta-openpli layer is 95% compatible with master-next: only the custom .bbappends must be adapted.

This means for you PLi developers that you can freely decide to base the next release on latest LTS (dunfell) or even on the forthcoming honister (now master-next).

 

Cheers

A.A.

[Persian Prince]

 

@A.A.

 

Just to let you know you don't need to use -next branches.

From the POV of a distro maintainer, no, absolutely not needed.

 

As OE developer, this is the right thing to do if you are not scared about bleeding edges.

I do my builds on master-next and help the maintainers to fix things or, more frequently, to fix the new regressions introduced in OE.

 

As for OpenPLi, there are only good news: the meta-openpli layer is 95% compatible with master-next: only the custom .bbappends must be adapted.

This means for you PLi developers that you can freely decide to base the next release on latest LTS (dunfell) or even on the forthcoming honister (now master-next).

 

Cheers

A.A.

 

I know, OV uses master branch and GCC 11.1 for months.

 

I just wanted to let you know using -next branches won't bring any good for e2 that's all.

[A.A.]

I think this is a good opportunity to evaluate again the needing of own versions and/or bbappends.

 

For some OE recipes packaging has been made more granular over time, we should maybe discuss with OE upstream about some packageconfig options used in meta-openpli. If interesting can be implemented.

 

I have seen around a valid example in OE-A_

https://github.com/o...c34e257a3c1f169

 

Cheers

A.A.

[WanWizard]

There are two reasons for having own recipes:

* there is no recipe available in OE

* we needed a newver version that the OE we currently use has

 

As to bbappends, most are there to make changes to the OE recipe to fit the way we work, without having to entirely copy the OE recipe.

 

Both should be reviewed and updated or deleted at every OE upgrade (another reason why it needs to happen is a separate branch ). If that hasn't happened, or hasn't happened correctly, it's a good idea to update them.