Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig
On Thu, 2019-02-21 at 20:09 -0500, Rich Persaud wrote: > > On Feb 21, 2019, at 18:51, Richard Purdie < > > richard.pur...@linuxfoundation.org> wrote: > > > > Multiconfig is meant to support this workflow. Unfortunately there > > are > > open bugs and people haven't the time to work on it so its stalled. > > That said, the key pieces are already there. > > > > A picture is worth a thousand words. I thought a demo might > > interest > > people and "prove" this can work. > > Thank you for the patches and PoC. We will test and are motivated to > see this work. I've been thinking about what Alejandro and I discussed and I think the correct fix for the multiconfig code is to filter the BB_TASKDEPDATA at source in bitbake to remove the multiconfig entries for other multiconfigs. I'll try and work up a patch for that in the next day or two as the hacks on my branch that do this are fragile right now. > I will also be experimenting with the generation of "immutable > infrastructure" from source code, to learn whether a single Packer.io > template can be used to both: > > (a) modify binary images, in the traditional Packer model, e.g. start > a bitbake-generated image in a VM or container, make runtime > configuration changes, then repack the machine image > > (b) perform automated customization of _inputs_ to bitbake recipes > and package source code, such that a machine image built by bitbake + > Packer template is equivalent to the image generated by Packer at > runtime > > If feasible, this would combine the agility of image customizations > with the security of bitbake's reproducible builds and supply chain > integrity. (a) definitely sounds easier than (b). I've not used packer.io but I'd be curious to see how that works out. People do find our image customisation hard to get to grips with :( Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 3/3] alsa-utils: 1.1.6 -> 1.1.8
On Thu, 2019-02-21 at 22:13 +0200, Tanu Kaskinen wrote: > SRC_URI was changed to a more reliable source (at least currently the > ftp server is flaky). > > [...] > > -SRC_URI = " > ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \ > - " > - > -SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002" > -SRC_URI[sha256sum] = > "155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e" > +SRC_URI = " > https://www.alsa-project.org/files/pub/utils/${BP}.tar.bz2; > +SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028" > +SRC_URI[sha256sum] = > "fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf" Thanks for the upgrades, its much appreciated! I have a small fixup queued in master-next for this, the SRC_URI uses alsa-utils-${PV} because of the alsa-utils-scripts recipe. I'll squash that in when merging if that is ok. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bitbake.conf:update FETCHCMD_wget with --no-passive-ftp
On Fri, 2019-02-22 at 14:03 +0800, Liu Haitao wrote: > When fetching the source of alsa it would trigger the following > WARNING: > > > WARNING: alsa-lib-1.1.6-r0 do_fetch: Failed to fetch URL > > ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.6.tar.bz2, > > attempting MIRRORS if > > available > > Bitbake would use wget with "--no-passive" to fetch the source. > Behind most firewall and NAT > configurations it could work well.However, in some rare firewall > configurations, > active FTP actually works when passive FTP doesn't. > > So disable the use of the passive FTP transfer mode for wget. As you say, its much more likely that passive ftp would work than active ftp, so this change would make things worse for more people? We're trying to get away from having ftp urls in oe-core at all so hopefully this isn't a big deal. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb
Currently kernel-fitimage gets the dtb from KERNEL_DEVICETREE, however there are instances when the DTB file can be generated using other recipes, provide a way to include the DTB instead of inkernel device tree. Add support for external device tree during the creation of fitimage. If virtual/dtb is set using PREFERRED_PROVIDER_virtual/dtb = "devicetree", which inherits the devicetree.bbclass then use the path provided in EXTERNAL_KERNEL_DEVICETREE else use KERNEL_DEVICETREE during fitimage process Signed-off-by: Manjukumar Matha --- Changelog v2: Update commit message to indicate PREFERRED_PROVIDER_virtual/dtb = "devicetree" to set external devicetree recipe meta/classes/kernel-fitimage.bbclass | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/meta/classes/kernel-fitimage.bbclass b/meta/classes/kernel-fitimage.bbclass index 8ebd3dd..3adb1c9 100644 --- a/meta/classes/kernel-fitimage.bbclass +++ b/meta/classes/kernel-fitimage.bbclass @@ -30,6 +30,13 @@ python __anonymous () { if image: d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' ${INITRAMFS_IMAGE}:do_image_complete') + #check if there are any dtb providers +providerdtb = d.getVar("PREFERRED_PROVIDER_virtual/dtb") +if providerdtb: +d.appendVarFlag('do_assemble_fitimage', 'depends', ' virtual/dtb:do_populate_sysroot') +d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' virtual/dtb:do_populate_sysroot') +d.setVar('EXTERNAL_KERNEL_DEVICETREE', "${RECIPE_SYSROOT}/boot/devicetree") + # Verified boot will sign the fitImage and append the public key to # U-Boot dtb. We ensure the U-Boot dtb is deployed before assembling # the fitImage: @@ -373,7 +380,8 @@ fitimage_assemble() { # # Step 2: Prepare a DTB image section # - if [ -n "${KERNEL_DEVICETREE}" ]; then + + if [ -z "${EXTERNAL_KERNEL_DEVICETREE}" ] && [ -n "${KERNEL_DEVICETREE}" ]; then dtbcount=1 for DTB in ${KERNEL_DEVICETREE}; do if echo ${DTB} | grep -q '/dts/'; then @@ -391,6 +399,16 @@ fitimage_assemble() { done fi + if [ -n "${EXTERNAL_KERNEL_DEVICETREE}" ]; then + dtbcount=1 + for DTBFILE in ${EXTERNAL_KERNEL_DEVICETREE}/*.dtb; do + DTB=`basename ${DTBFILE}` + DTB=$(echo "${DTB}" | tr '/' '_') + DTBS="${DTBS} ${DTB}" + fitimage_emit_section_dtb ${1} ${DTB} ${DTBFILE} + done + fi + # # Step 3: Prepare a setup section. (For x86) # -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] dpkg: 1.18.25 -> 1.19.4
From: Kai Kang Upgrade dpkg from 1.18.25 to 1.19.4: * update SRC_URI which DEBIAN_MIRROR * un-export PERL which causes script scripts/dpkg-architecture.pl fails to get cpu type and package arch * add configure option '--disable-update-alternatives' which causes installed-vs-shipped issue * add patch for dpkg-native to resolve host tar may not support options --owner=NAME:ID and --group=NAME:ID * update context of patches * drop dpkg-configure.service that apt provides a systemd timer to do it Signed-off-by: Kai Kang --- meta/recipes-devtools/dpkg/dpkg.inc | 25 +++-- ...s-expect-D-to-be-set-when-running-in.patch | 19 ++--- .../0005-dpkg-compiler.m4-remove-Wvla.patch | 16 ++- ...c-Remove-usage-of-clamp-mtime-in-tar.patch | 12 ++--- .../dpkg/dpkg/dpkg-configure.service | 17 .../dpkg/dpkg/glibc2.5-sync_file_range.patch | 11 +--- .../dpkg/tweak-options-require-tar-1.27.patch | 27 +++ .../dpkg/{dpkg_1.18.25.bb => dpkg_1.19.4.bb} | 11 8 files changed, 77 insertions(+), 61 deletions(-) delete mode 100644 meta/recipes-devtools/dpkg/dpkg/dpkg-configure.service create mode 100644 meta/recipes-devtools/dpkg/dpkg/tweak-options-require-tar-1.27.patch rename meta/recipes-devtools/dpkg/{dpkg_1.18.25.bb => dpkg_1.19.4.bb} (73%) diff --git a/meta/recipes-devtools/dpkg/dpkg.inc b/meta/recipes-devtools/dpkg/dpkg.inc index fe4732d1db..fee7a75814 100644 --- a/meta/recipes-devtools/dpkg/dpkg.inc +++ b/meta/recipes-devtools/dpkg/dpkg.inc @@ -9,15 +9,8 @@ RDEPENDS_${PN}_class-native = "" UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/dpkg/" -inherit autotools gettext perlnative pkgconfig systemd perl-version +inherit autotools gettext perlnative pkgconfig perl-version -python () { -if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d): -pn = d.getVar('PN') -d.setVar('SYSTEMD_SERVICE_%s' % (pn), 'dpkg-configure.service') -} - -export PERL = "${bindir}/perl" PERL_class-native = "${STAGING_BINDIR_NATIVE}/perl-native/perl" export PERL_LIBDIR = "${libdir}/perl/${@get_perl_version(d)}" @@ -29,14 +22,14 @@ EXTRA_OECONF = "\ --with-libz \ --with-libbz2 \ --without-libselinux \ + TAR=tar \ " +EXTRA_OECONF_append_class-target = " --disable-update-alternatives DEB_HOST_ARCH=${DPKG_ARCH}" + PACKAGECONFIG = "liblzma" PACKAGECONFIG[liblzma] = "--with-liblzma,--without-liblzma, xz" -EXTRA_OECONF += "TAR=tar" -EXTRA_OECONF_append_class-target = " DEB_HOST_ARCH=${DPKG_ARCH}" - do_install_append () { if [ "${PN}" = "dpkg-native" ]; then # update-alternatives doesn't have an offline mode @@ -45,16 +38,6 @@ do_install_append () { else sed -i -e 's|^#!.*${bindir}/perl-native.*/perl|#!/usr/bin/env perl|' ${D}${bindir}/dpkg-* fi - - if ${@bb.utils.contains('DISTRO_FEATURES','sysvinit','false','true',d)};then - install -d ${D}${systemd_unitdir}/system - install -m 0644 ${WORKDIR}/dpkg-configure.service ${D}${systemd_unitdir}/system/ - sed -i -e 's,@BASE_BINDIR@,${base_bindir},g' \ - -e 's,@SYSCONFDIR@,${sysconfdir},g' \ - -e 's,@BINDIR@,${bindir},g' \ - -e 's,@SYSTEMD_UNITDIR@,${systemd_unitdir},g' \ - ${D}${systemd_unitdir}/system/dpkg-configure.service - fi } PROV = "virtual/update-alternatives" diff --git a/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch b/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch index 93d870443c..b88be87490 100644 --- a/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch +++ b/meta/recipes-devtools/dpkg/dpkg/0003-Our-pre-postinsts-expect-D-to-be-set-when-running-in.patch @@ -10,15 +10,16 @@ Upstream-Status: Inappropriate [OE Specific] RP 2011/12/07 ALIMON 2016/05/26 ALIMON 2017/02/21 +KKang 2019/02/20 --- src/script.c | 44 +++- 1 file changed, 3 insertions(+), 41 deletions(-) diff --git a/src/script.c b/src/script.c -index 2f252ae..768a9d1 100644 +index 0865b95..73ed35d 100644 --- a/src/script.c +++ b/src/script.c -@@ -97,48 +97,10 @@ setexecute(const char *path, struct stat *stab) +@@ -96,58 +96,11 @@ setexecute(const char *path, struct stat *stab) static const char * maintscript_pre_exec(struct command *cmd) { @@ -32,6 +33,8 @@ index 2f252ae..768a9d1 100644 - changedir = "/"; - - if (instdirlen > 0 && !fc_script_chrootless) { +- int rc; +- - if (strncmp(admindir, instdir, instdirlen) != 0) - ohshit(_("admindir must be inside instdir for dpkg to work properly")); - if
[OE-core] [PATCH] bitbake.conf:update FETCHCMD_wget with --no-passive-ftp
When fetching the source of alsa it would trigger the following WARNING: |WARNING: alsa-lib-1.1.6-r0 do_fetch: Failed to fetch URL |ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.6.tar.bz2, attempting MIRRORS if |available Bitbake would use wget with "--no-passive" to fetch the source. Behind most firewall and NAT configurations it could work well.However, in some rare firewall configurations, active FTP actually works when passive FTP doesn't. So disable the use of the passive FTP transfer mode for wget. Signed-off-by: Liu Haitao --- meta/conf/bitbake.conf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 435646a946..357de41780 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -666,7 +666,7 @@ SRC_URI[vardepsexclude] += "\ FETCHCMD_svn = "/usr/bin/env svn --non-interactive --trust-server-cert" FETCHCMD_cvs = "/usr/bin/env cvs" -FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate" +FETCHCMD_wget = "/usr/bin/env wget -t 2 -T 30 --no-passive-ftp --no-check-certificate" FETCHCMD_bzr = "/usr/bin/env bzr" FETCHCMD_hg = "/usr/bin/env hg" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: remove duplicate overrides
As Peter mentions the underlying issue is already mitigated when we read the value of DEVTOOL_EXTRA_OVERRIDES; for clarity I'd say let's revert this (90f667db2219f04e6d61588cd61056d3d8da6d7d). My apologies, I wasn't paying attention earlier. Cheers, Paul On Wednesday, 23 January 2019 12:32:35 PM NZDT Peter Kjellerstedt wrote: > This has already been merged, but see below. > > > -Original Message- > > From: openembedded-core-boun...@lists.openembedded.org > core-boun...@lists.openembedded.org> On Behalf Of Dan Dedrick > > Sent: den 21 januari 2019 17:05 > > To: openembedded-core@lists.openembedded.org > > Subject: [OE-core] [PATCH] devtool: remove duplicate overrides > > > > DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of > > overrides. Previous to these changes it would find every override to > > SRC_URI and add it to the list. This would duplicate instances where > > SRC_URI is modified multiple times with the same override like: > > SRC_URI_append_foo += "file://0001-foo.patch" > > SRC_URI_append_foo += "file://0002-bar.patch" > > > > A bbappend might also overwrite a SRC_URI override, which would also > > cause multiple instances to occur. > > > > When there are multiple instances of the same override in > > DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating > > override branches. The failure occurs when attempting to create the same > > override branch a second time and looks like this: > > > > The stack trace of python calls that resulted in this exception/failure was: > > File: 'exec_python_func() autogenerated', lineno: 2, function: > > 0001: > > *** 0002:devtool_post_patch(d) > > 0003: > > File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202, > > function: devtool_post_patch > > 0198: > > 0199:for override in extra_override_list: > > The reference to extra_override_list above indicates that you developed > this patch for an older version of OE-Core, since that variable was > renamed on master of OE-Core in October when this problem was fixed (see > commit 95a92195). However, that fix was made to devtool-source.bbclass, > where it uses the value of DEVTOOL_EXTRA_OVERRIDES, instead of to > scripts/lib/devtool/standard.py where you made the change. This is > probably why you did not notice that the problem had already been fixed. > > > 0200:localdata = bb.data.createCopy(d) > > 0201:if override in default_overrides: > > *** 0202:bb.process.run('git branch devtool-override-%s > > %s' % (override, devbranch), cwd=srcsubdir) > > 0203:else: > > 0204:# Reset back to the initial commit on a new branch > > 0205:bb.process.run('git checkout %s -b > > devtool-override-%s' % (initial_rev, override), cwd=srcsubdir) > > 0206:# Run do_patch function with the override applied > > File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run > > 0174:if not stderr is None: > > 0175:stderr = stderr.decode("utf-8") > > 0176: > > 0177:if pipe.returncode != 0: > > *** 0178:raise ExecutionError(cmd, pipe.returncode, stdout, stderr) > > 0179:return stdout, stderr > > Exception: bb.process.ExecutionError: Execution of 'git branch > > devtool-override-foo devtool' failed with exit code 128: > > fatal: A branch named 'devtool-override-foo' already exists. > > > > Signed-off-by: Dan Dedrick > > --- > > scripts/lib/devtool/standard.py | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/scripts/lib/devtool/standard.py > > b/scripts/lib/devtool/standard.py > > index d14b7a6543..a45ad36812 100644 > > --- a/scripts/lib/devtool/standard.py > > +++ b/scripts/lib/devtool/standard.py > > @@ -509,6 +509,11 @@ def _extract_source(srctree, keep_temp, devbranch, > > sync, config, basepath, works > > if not 'flag' in event: > > if event['op'].startswith(('_append[', '_prepend[')): > > > > extra_overrides.append(event['op'].split('[')[1].split(']')[0]) > > +# We want to remove duplicate overrides. If a recipe had multiple > > +# SRC_URI_override += values it would cause mulitple instances of > > +# overrides. This doesn't play nicely with things like creating a > > +# branch for every instance of DEVTOOL_EXTRA_OVERRIDES. > > +extra_overrides = list(set(extra_overrides)) > > if extra_overrides: > > logger.info('SRC_URI contains some conditional > > appends/prepends - will create branches to represent these') > > > > -- > > 2.20.1 > > //Peter > > -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: deploy-target: allow use of alternate ssh
Looks good to me. Acked-by: Paul Eggleton On Friday, 22 February 2019 2:10:45 AM NZDT Olaf Mandel wrote: > Allow the use of an alternate SSH executable for deploy-target and > undeploy-target. The command can be specified with -e / --ssh-exec. > > Signed-off-by: Olaf Mandel > --- > scripts/lib/devtool/deploy.py | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py > index 886004b5d0..f345f31b7b 100644 > --- a/scripts/lib/devtool/deploy.py > +++ b/scripts/lib/devtool/deploy.py > @@ -211,6 +211,11 @@ def deploy(args, config, basepath, workspace): > if not args.show_status: > extraoptions += ' -q' > > +scp_sshexec = '' > +ssh_sshexec = 'ssh' > +if args.ssh_exec: > +scp_sshexec = "-S %s" % args.ssh_exec > +ssh_sshexec = args.ssh_exec > scp_port = '' > ssh_port = '' > if args.port: > @@ -238,7 +243,7 @@ def deploy(args, config, basepath, workspace): > for fpath, fsize in filelist: > f.write('%s %d\n' % (fpath, fsize)) > # Copy them to the target > -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, > extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) > +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, > scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), > shell=True) > if ret != 0: > raise DevtoolError('Failed to copy script to %s - rerun with > -s to ' > 'get a complete error message' % args.target) > @@ -246,7 +251,7 @@ def deploy(args, config, basepath, workspace): > shutil.rmtree(tmpdir) > > # Now run the script > -ret = exec_fakeroot(rd, 'tar cf - . | ssh %s %s %s \'sh %s %s %s > %s\'' % (ssh_port, extraoptions, args.target, tmpscript, args.recipename, > destdir, tmpfilelist), cwd=recipe_outdir, shell=True) > +ret = exec_fakeroot(rd, 'tar cf - . | %s %s %s %s \'sh %s %s %s > %s\'' % (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript, > args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True) > if ret != 0: > raise DevtoolError('Deploy failed - rerun with -s to get a > complete ' > 'error message') > @@ -276,6 +281,11 @@ def undeploy(args, config, basepath, workspace): > if not args.show_status: > extraoptions += ' -q' > > +scp_sshexec = '' > +ssh_sshexec = 'ssh' > +if args.ssh_exec: > +scp_sshexec = "-S %s" % args.ssh_exec > +ssh_sshexec = args.ssh_exec > scp_port = '' > ssh_port = '' > if args.port: > @@ -292,7 +302,7 @@ def undeploy(args, config, basepath, workspace): > with open(os.path.join(tmpdir, os.path.basename(tmpscript)), 'w') as > f: > f.write(shellscript) > # Copy it to the target > -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, > extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) > +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, > scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), > shell=True) > if ret != 0: > raise DevtoolError('Failed to copy script to %s - rerun with -s > to ' > 'get a complete error message' % args.target) > @@ -300,7 +310,7 @@ def undeploy(args, config, basepath, workspace): > shutil.rmtree(tmpdir) > > # Now run the script > -ret = subprocess.call('ssh %s %s %s \'sh %s %s\'' % (ssh_port, > extraoptions, args.target, tmpscript, args.recipename), shell=True) > +ret = subprocess.call('%s %s %s %s \'sh %s %s\'' % (ssh_sshexec, > ssh_port, extraoptions, args.target, tmpscript, args.recipename), shell=True) > if ret != 0: > raise DevtoolError('Undeploy failed - rerun with -s to get a > complete ' > 'error message') > @@ -324,6 +334,7 @@ def register_commands(subparsers, context): > parser_deploy.add_argument('-n', '--dry-run', help='List files to be > deployed only', action='store_true') > parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve > existing files', action='store_true') > parser_deploy.add_argument('--no-check-space', help='Do not check for > available space before deploying', action='store_true') > +parser_deploy.add_argument('-e', '--ssh-exec', help='Executable to use > in place of ssh') > parser_deploy.add_argument('-P', '--port', help='Specify port to use for > connection to the target') > > strip_opts = parser_deploy.add_mutually_exclusive_group(required=False) > @@ -346,5 +357,6 @@ def register_commands(subparsers, context): > parser_undeploy.add_argument('-s',
[OE-core] [PATCH] perl: fix incorrect symbolic link for libperl.so
The perl-cross uses PERL_API_VERSION but not PERL_VERSION to define libperl soname: libperl.so.$PERL_API_REVISION.$PERL_API_VERSION.$PERL_API_SUBVERSION. For perl stable releases, the PERL_API_SUBVERSION is always 0. Specify the so version for libperl to make sure the libperl.so can be linked to the correct library. Signed-off-by: Yi Zhao --- meta/recipes-devtools/perl-sanity/perl_5.28.1.bb | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb index 71653fe..1cc5480 100644 --- a/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb +++ b/meta/recipes-devtools/perl-sanity/perl_5.28.1.bb @@ -34,6 +34,8 @@ inherit upstream-version-is-even DEPENDS += "db gdbm zlib virtual/crypt" +PERL_LIB_VER = "${@'.'.join(d.getVar('PV').split('.')[0:2])}.0" + do_unpack_append() { bb.build.exec_func('do_copy_perlcross', d) } @@ -104,7 +106,7 @@ do_install() { # Fix up shared library rm ${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so -ln -sf ../../../../libperl.so.${PV} ${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so +ln -sf ../../../../libperl.so.${PERL_LIB_VER} ${D}/${libdir}/perl5/${PV}/${TARGET_ARCH}-linux/CORE/libperl.so } do_install_append_class-target() { -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] debianutils: update to 4.8.6.1
Signed-off-by: Yi Zhao --- .../debianutils/{debianutils_4.8.6.bb => debianutils_4.8.6.1.bb} | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) rename meta/recipes-support/debianutils/{debianutils_4.8.6.bb => debianutils_4.8.6.1.bb} (86%) diff --git a/meta/recipes-support/debianutils/debianutils_4.8.6.bb b/meta/recipes-support/debianutils/debianutils_4.8.6.1.bb similarity index 86% rename from meta/recipes-support/debianutils/debianutils_4.8.6.bb rename to meta/recipes-support/debianutils/debianutils_4.8.6.1.bb index c37e842..7cc78a6 100644 --- a/meta/recipes-support/debianutils/debianutils_4.8.6.bb +++ b/meta/recipes-support/debianutils/debianutils_4.8.6.1.bb @@ -3,13 +3,15 @@ SECTION = "base" LICENSE = "GPLv2 & SMAIL_GPL" LIC_FILES_CHKSUM = "file://debian/copyright;md5=f01a5203d50512fc4830b4332b696a9f" -SRC_URI = "http://snapshot.debian.org/archive/debian/20180626T205238Z/pool/main/d/${BPN}/${BPN}_${PV}.tar.xz; +SRC_URI = "http://snapshot.debian.org/archive/debian/20190217T160716Z/pool/main/d/${BPN}/${BPN}_${PV}.tar.xz; # the package is taken from snapshots.debian.org; that source is static and goes stale # so we check the latest upstream from a directory that does get updated UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/d/${BPN}/" -SRC_URI[md5sum] = "f0f1fa39383815fb7950dcee52be4361" -SRC_URI[sha256sum] = "db09047144dadf6a35d0f28977fbef83b0dd60ca32e6c8512cce2444a6423f73" +SRC_URI[md5sum] = "80e2e670d8f6c0036770e971237f1f5c" +SRC_URI[sha256sum] = "099f1e8a7278b26145a2ba2dda84c4118403bfab38c8d7070a6235a7ffcb55ed" + +S = "${WORKDIR}/${BPN}" inherit autotools update-alternatives -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] u-boot: Upgrade to 2019.01 release
On Fri, Feb 22, 2019 at 12:56:18AM +0100, Marek Vasut wrote: > This upgrades the U-Boot to latest 2019.01 release. > > Signed-off-by: Marek Vasut > Cc: Otavio Salvador > Cc: Richard Purdie > Cc: Ross Burton Reviewed-by: Tom Rini -- Tom -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] populate_sdk_ext.bbclass: Fix the derivate sdk build error from an published eSDK
When you install the eSDK in publish mode and then try to build a derivative sdk using devtool build-sdk, the following error happens | NOTE: Generating sstate task list... | NOTE: Generating sstate-cache... | NOTE: Generating sstate-cache... | DEBUG: Python function copy_buildsystem finished | NOTE: Executing install_tools ... | DEBUG: Executing shell function install_tools | install: cannot stat /core/meta/files/ext-sdk-prepare.py': No such file or directory This patch will fix the error by installing ext-sdk-prepare.py in publish mode, so that derivative sdk can be generated. Signed-off-by: Manjukumar Matha --- meta/classes/populate_sdk_ext.bbclass | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/meta/classes/populate_sdk_ext.bbclass b/meta/classes/populate_sdk_ext.bbclass index 40b0375..800e117 100644 --- a/meta/classes/populate_sdk_ext.bbclass +++ b/meta/classes/populate_sdk_ext.bbclass @@ -589,11 +589,8 @@ sdk_ext_preinst() { exit 1 fi SDK_EXTENSIBLE="1" - if [ "$publish" = "1" ] ; then - EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS --exclude=ext-sdk-prepare.py" - if [ "${SDK_EXT_TYPE}" = "minimal" ] ; then - EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS --exclude=sstate-cache" - fi + if [ "$publish" = "1" ] && [ "${SDK_EXT_TYPE}" = "minimal" ] ; then + EXTRA_TAR_OPTIONS="$EXTRA_TAR_OPTIONS --exclude=sstate-cache" fi } SDK_PRE_INSTALL_COMMAND_task-populate-sdk-ext = "${sdk_ext_preinst}" @@ -635,6 +632,8 @@ sdk_ext_postinst() { # sourcing a script. That is why this has to look so ugly. LOGFILE="$target_sdk_dir/preparing_build_system.log" sh -c ". buildtools/environment-setup* > $LOGFILE && cd $target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . $target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && python $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" || { echo "printf 'ERROR: this SDK was not fully installed and needs reinstalling\n'" >> $env_setup_script ; exit 1 ; } + fi + if [ -e $target_sdk_dir/ext-sdk-prepare.py ]; then rm $target_sdk_dir/ext-sdk-prepare.py fi echo done -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] u-boot: Upgrade to 2019.01 release
This upgrades the U-Boot to latest 2019.01 release. Signed-off-by: Marek Vasut Cc: Otavio Salvador Cc: Richard Purdie Cc: Ross Burton --- meta/recipes-bsp/u-boot/u-boot-common.inc | 2 +- .../{u-boot-fw-utils_2018.11.bb => u-boot-fw-utils_2019.01.bb} | 0 .../u-boot/{u-boot-tools_2018.11.bb => u-boot-tools_2019.01.bb} | 0 .../recipes-bsp/u-boot/{u-boot_2018.11.bb => u-boot_2019.01.bb} | 0 4 files changed, 1 insertion(+), 1 deletion(-) rename meta/recipes-bsp/u-boot/{u-boot-fw-utils_2018.11.bb => u-boot-fw-utils_2019.01.bb} (100%) rename meta/recipes-bsp/u-boot/{u-boot-tools_2018.11.bb => u-boot-tools_2019.01.bb} (100%) rename meta/recipes-bsp/u-boot/{u-boot_2018.11.bb => u-boot_2019.01.bb} (100%) diff --git a/meta/recipes-bsp/u-boot/u-boot-common.inc b/meta/recipes-bsp/u-boot/u-boot-common.inc index 6f4a10b7a4..dcfb9cc63f 100644 --- a/meta/recipes-bsp/u-boot/u-boot-common.inc +++ b/meta/recipes-bsp/u-boot/u-boot-common.inc @@ -8,7 +8,7 @@ PE = "1" # We use the revision in order to avoid having to fetch it from the # repo during parse -SRCREV = "0157013f4a4945bbdb70bb4d98d680e0845fd784" +SRCREV = "d3689267f92c5956e09cc7d1baa4700141662bff" SRC_URI = "git://git.denx.de/u-boot.git" diff --git a/meta/recipes-bsp/u-boot/u-boot-fw-utils_2018.11.bb b/meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.01.bb similarity index 100% rename from meta/recipes-bsp/u-boot/u-boot-fw-utils_2018.11.bb rename to meta/recipes-bsp/u-boot/u-boot-fw-utils_2019.01.bb diff --git a/meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb b/meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb similarity index 100% rename from meta/recipes-bsp/u-boot/u-boot-tools_2018.11.bb rename to meta/recipes-bsp/u-boot/u-boot-tools_2019.01.bb diff --git a/meta/recipes-bsp/u-boot/u-boot_2018.11.bb b/meta/recipes-bsp/u-boot/u-boot_2019.01.bb similarity index 100% rename from meta/recipes-bsp/u-boot/u-boot_2018.11.bb rename to meta/recipes-bsp/u-boot/u-boot_2019.01.bb -- 2.19.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig
Multiconfig is meant to support this workflow. Unfortunately there are open bugs and people haven't the time to work on it so its stalled. That said, the key pieces are already there. A picture is worth a thousand words. I thought a demo might interest people and "prove" this can work. To make it work you need four patches: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=b896b2238c100d486e7c43992b49001150749d04 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=e5ef6b008e85f42b5e4ffd72fae7036dd68b2ea5 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=5d2bd43d14315ef3212e0d09a16446bd74305a2f http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222=abdb83576b699448b76293294809aaa04b8e853b The first two are fixes from Alejandro which haven't merged as they're not right. The third patch was me hitting the fixes and bitbake to make the demo work. That proves they're not right and hints at where we have some problems in bitbake too. We can get those issues sorted fairly easily and I'm going to block 2.7 M3 on them. The final patch is the interesting one. It adds a layer, meta-multiconfig-example layer with a README about how to configure it. Basically you create two multiconfig configurations, "musl" and "tiny". The demo is to run "bitbake core-image-full-cmdline". The result is a core-image-full-cmdline image with a tiny qemux86 image and a musl based qemux86-64 image installed into /var/lib/machines/ The way it does this is creative, having a recipe called image-packer which creates virtclass variants of itself which depend on the appropriate multiconfig. It pulls in the images and creates a package containing them which the bbappend to core-image-full-cmdline can then install. It'd be very easy to turn this into a list driven piece of code rather than the two values currently listed. Its late here, some of the above code is horrible. I have rushed this but hopefully it shows this is possible! :) I've love to turn this into an oe-selftest, that is my ultimate intention for this code. As things stand today you can't query one multiconfig from another. As this demo shows, that doesn't need to stop you making interesting things though. We will do something with such querying eventually to make things easier but until then, much is still possible. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] glib-networking: upgrade 2.54.1 -> 2.58.0
This does not build any more if USE_NLS = "no" is used. Has anyone looked at making this work together with meson? Otherwise I guess there is trouble ahead now that more and more packages are being converted to use meson, since the code in gettext.bbclass currently only supports autotools. A quick look at meson's i18n.py module does not indicate that there is any easy way to disable the gettext support, corresponding to autotools' --disable-nls. Apparently it was discussed in https://github.com/mesonbuild/meson/issues/821, but it seems they only added detection of the gettext tools without adding support for disabling gettext and then closed the issue. Looking at 1d6648102 (json-glib: fix native build), it seems Ross encountered a similar problem for json-glib and opted to workaround the problem by overriding USE_NLS. However, that does not seem like a long term solution... //Peter > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Anuj Mittal > Sent: den 20 februari 2019 08:13 > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH 2/2] glib-networking: upgrade 2.54.1 -> > 2.58.0 > > * Autotools support has been removed upstream, so migrate recipe to > meson. For changes, see: > https://gitlab.gnome.org/GNOME/glib-networking/blob/glib-2-58/NEWS > > * Remove unsupported configure options: pkcs11, ca-certificates. See: > https://bugzilla.gnome.org/show_bug.cgi?id=793281 > https://bugzilla.gnome.org/show_bug.cgi?id=753260 > > License-Update: Change to LGPLv2.1 > > Signed-off-by: Anuj Mittal > --- > ...ng_2.54.1.bb => glib-networking_2.58.0.bb} | 26 ++- > 1 file changed, 14 insertions(+), 12 deletions(-) > rename meta/recipes-core/glib-networking/{glib-networking_2.54.1.bb => > glib-networking_2.58.0.bb} (40%) > > diff --git a/meta/recipes-core/glib-networking/glib- > networking_2.54.1.bb b/meta/recipes-core/glib-networking/glib- > networking_2.58.0.bb > similarity index 40% > rename from meta/recipes-core/glib-networking/glib-networking_2.54.1.bb > rename to meta/recipes-core/glib-networking/glib-networking_2.58.0.bb > index 5d17a824f0..f3190e1cae 100644 > --- a/meta/recipes-core/glib-networking/glib-networking_2.54.1.bb > +++ b/meta/recipes-core/glib-networking/glib-networking_2.58.0.bb > @@ -3,27 +3,29 @@ DESCRIPTION = "glib-networking contains the > implementations of certain GLib netw > HOMEPAGE = "https://gitlab.gnome.org/GNOME/glib-networking/; > BUGTRACKER = "http://bugzilla.gnome.org; > > -LICENSE = "LGPLv2" > -LIC_FILES_CHKSUM = > "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2" > +LICENSE = "LGPLv2.1" > +LIC_FILES_CHKSUM = > "file://COPYING;md5=4fbd65380cdd255951079008b364516c" > > SECTION = "libs" > DEPENDS = "glib-2.0" > > -SRC_URI[archive.md5sum] = "99867463f182c2767bce0c74bc9cc981" > -SRC_URI[archive.sha256sum] = > "eaa787b653015a0de31c928e9a17eb57b4ce23c8cf6f277afaec0d685335012f" > +SRC_URI[archive.md5sum] = "75b14b7e73a67753be9ce307751c661d" > +SRC_URI[archive.sha256sum] = > "bdfa0255e031b8ee003cc283002536b77ee76450105f1dc6ab066b9bf4330068" > > -PACKAGECONFIG ??= "ca-certificates gnutls" > +PACKAGECONFIG ??= "gnutls" > > -# No explicit dependency as it works without ca-certificates installed > -PACKAGECONFIG[ca-certificates] = "--with-ca- > certificates=${sysconfdir}/ssl/certs/ca-certificates.crt,--without-ca- > certificates" > -PACKAGECONFIG[gnutls] = "--with-gnutls,--without-gnutls,gnutls" > -PACKAGECONFIG[libproxy] = "--with-libproxy,--without- > libproxy,libproxy" > -PACKAGECONFIG[pkcs11] = "--with-pkcs11,--without-pkcs11,p11-kit" > +PACKAGECONFIG[gnutls] = "-Dgnutls=true,-Dgnutls=false,gnutls" > +PACKAGECONFIG[libproxy] = "-Dlibproxy_support=true,- > Dlibproxy_support=false,libproxy" > > -EXTRA_OECONF = "--without-gnome-proxy" > +EXTRA_OEMESON = "-Dgnome_proxy_support=false" > > +GNOMEBASEBUILDCLASS = "meson" > inherit gnomebase gettext upstream-version-is-even gio-module-cache > > -FILES_${PN} += "${libdir}/gio/modules/libgio*.so ${datadir}/dbus- > 1/services/" > +FILES_${PN} += "\ > +${libdir}/gio/modules/libgio*.so \ > +${datadir}/dbus-1/services/ \ > +${systemd_user_unitdir} \ > +" > FILES_${PN}-dev += "${libdir}/gio/modules/libgio*.la" > FILES_${PN}-staticdev += "${libdir}/gio/modules/libgio*.a" > -- > 2.17.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gtk+3: Fix build failure with gold linker
Explicitly link in libfribidi Signed-off-by: Khem Raj --- .../gtk+/gtk+3/link_fribidi.patch | 19 +++ meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb | 1 + 2 files changed, 20 insertions(+) create mode 100644 meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch diff --git a/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch b/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch new file mode 100644 index 00..e4bbd799f1 --- /dev/null +++ b/meta/recipes-gnome/gtk+/gtk+3/link_fribidi.patch @@ -0,0 +1,19 @@ +Link with libfribidi, this is to avoid under linking where these functions are +used but the library is not linked in, and they are marked undefined by BFD linker +but gold linker refuses to link + +| ./.libs/libgdk-3.so: error: undefined reference to 'fribidi_get_bidi_type' + +Signed-off-by: Khem Raj +Upstream-Status: Pending + +--- a/gdk/Makefile.am b/gdk/Makefile.am +@@ -55,6 +55,7 @@ LDADD = \ + -version-info $(LT_VERSION_INFO)\ + -export-dynamic \ + -rpath $(libdir)\ ++ -lfribidi \ + $(no_undefined) + + # diff --git a/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb b/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb index 799cbd4707..92c9a3ebfb 100644 --- a/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb +++ b/meta/recipes-gnome/gtk+/gtk+3_3.24.5.bb @@ -6,6 +6,7 @@ SRC_URI = "http://ftp.gnome.org/pub/gnome/sources/gtk+/${MAJ_VER}/gtk+-${PV}.tar file://0001-Hardcoded-libtool.patch \ file://0002-Do-not-try-to-initialize-GL-without-libGL.patch \ file://0003-Add-disable-opengl-configure-option.patch \ + file://link_fribidi.patch \ " SRC_URI[md5sum] = "32862355c08f6af3e7848c695cd4081b" SRC_URI[sha256sum] = "0be5fb0d302bc3de26ab58c32990d895831e2b7c7418d0ffea1206d6a3ddb02f" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v6 13/13] util-linux: final cleanup
Looks like the manpage cleanup didn't quite work: WARNING: util-linux-2.32.1-r0 do_configure: QA Issue: util-linux: invalid PACKAGECONFIG: manpages [invalid-packageconfig] Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb
Hi Richard, > -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Wednesday, February 20, 2019 3:16 PM > To: Manjukumar Harthikote Matha ; Philip Balister > > Cc: openembedded-core > Subject: Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to > provide external dtb > > On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha wrote: > > Hi Philip, > > > > > -Original Message- > > > From: Philip Balister [mailto:phi...@balister.org] > > > Sent: Sunday, February 17, 2019 3:47 PM > > > To: Manjukumar Harthikote Matha > > > Cc: openembedded-core > > > Subject: Re: [OE-core][PATCH 2/2] kernel-fitimage.bbclass: > > > Introduce a way to > > > provide external dtb > > > > > > With these patches, I made a fitImage that booted on the mini-zed. > > > It would be nice > > > to include a note on how to enable this. I took at few stabs at it > > > and ended up with > > > > Thanks for testing it out on mini-zed > > > > > PREFERRED_PROVIDER_virtual/dtb = "devicetree" > > > > > > > Yes, I should have added this in the commit message. I will update it > > and re-send V2 > > What may also help a lot here would be some tests. This is currently a > blackhole in > the tests :( > Are there examples of having tests only for bbclass in OE-Core? We need a recipe or create-one to inherit this class and probably add that as a testcase. I am not sure how to proceed, any example would help to implement the same Thanks, Manju -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/3] alsa recipe updates
On Thu, 21 Feb 2019 at 21:13, Tanu Kaskinen wrote: > Changes in v2: > - More reliable SRC_URIs. > > > Tanu Kaskinen (3): > alsa-lib: 1.1.6 -> 1.1.8 > alsa-plugins: 1.1.6 -> 1.1.8 > alsa-utils: 1.1.6 -> 1.1.8 > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 6 +- > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 86 +-- > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 14 ++- > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- I guess alsa-tools should also get an updated SRC_URI, even without a version upgrade for now? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/3] alsa-plugins: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 The --enable-avcodec configure option was renamed to --enable-libav, and I renamed the respective packageconfig item too. There's a new pcm plugin: aaf (AVTP Audio Format). I added a packageconfig item for it, but I didn't test it, because libavtp doesn't seem to be currently packaged for OpenEmbedded. There are now configuration files for most of the plugins. I removed the symlink creation for 50-pulseaudio.conf, because upstream now creates the symlinks for us. 99-pulseaudio-default.conf is an exception, because upstream ships it only as an example, and upstream doesn't install a symlink for it (upstream actually installs it directly under /etc, but I moved it back to /usr/share), so for that file we still have to create the symlink ourselves. The lavcrate plugin was converted to use libavresample (and renamed to lavrate). Libavresample is provided by ffmpeg, but ffmpeg was by default built with libavresample disabled. This patch now enables libavresample by default in the ffmpeg recipe in order to not cause a regression in alsa-plugins. SRC_URI was changed to a more reliable source (at least currently the ftp server is flaky). Signed-off-by: Tanu Kaskinen --- ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 89 +++ .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- 2 files changed, 75 insertions(+), 16 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} (53%) diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb similarity index 53% rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb index ee06191ea9..2d9cc06f58 100644 --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb @@ -20,9 +20,9 @@ LIC_FILES_CHKSUM = "\ file://rate/rate_samplerate.c;endline=35;md5=fd77bce85f4a338c0e8ab18430b69fae \ " -SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2; -SRC_URI[md5sum] = "8387279e99feeb2ecffaac5f293223d7" -SRC_URI[sha256sum] = "6f1d31ebe3b1fa1cc8dade60b7bed1cb2583ac998167002d350dc0a5e3e40c13" +SRC_URI = "https://www.alsa-project.org/files/pub/plugins/${BP}.tar.bz2; +SRC_URI[md5sum] = "d0f87211d1560f2c07c8eae4297bc4f6" +SRC_URI[sha256sum] = "7f77df171685ccec918268477623a39db4d9f32d5dc5e76874ef2467a2405994" DEPENDS += "alsa-lib" @@ -33,8 +33,9 @@ PACKAGECONFIG ??= "\ speexdsp \ ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio', d)} \ " -PACKAGECONFIG[avcodec] = "--enable-avcodec,--disable-avcodec,libav" +PACKAGECONFIG[aaf] = "--enable-aaf,--disable-aaf,avtp" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" +PACKAGECONFIG[libav] = "--enable-libav,--disable-libav,libav" PACKAGECONFIG[maemo-plugin] = "--enable-maemo-plugin,--disable-maemo-plugin" PACKAGECONFIG[maemo-resource-manager] = "--enable-maemo-resource-manager,--disable-maemo-resource-manager,dbus" PACKAGECONFIG[pulseaudio] = "--enable-pulseaudio,--disable-pulseaudio,pulseaudio" @@ -54,15 +55,11 @@ do_install_append() { rm ${D}${libdir}/alsa-lib/*.la if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', d)}" = "yes" ]; then - # We use the example as is, so just drop the .example suffix. - mv ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf - - # The conf.d files are installed in datadir, but alsa-lib - # searches for conf.d files only in sysconfdir. Distributions - # are expected to create symlinks in sysconfdir, so that's what - # we do here. - mkdir -p ${D}${sysconfdir}/alsa/conf.d - ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf + # We use the example as is. Upstream installs the file under + # /etc, but we move it under /usr/share and add a symlink under + # /etc to be consistent with other installed configuration + # files. + mv ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf fi } @@ -73,6 +70,68 @@ python populate_packages_prepend() { d.setVar("RDEPENDS_alsa-plugins", packages) } +# Many plugins have a configuration file (plus a symlink in /etc) associated +# with them. We put the plugin and it's configuration usually in the same +# package, but that's problematic when the configuration file is related to +#
[OE-core] [PATCH v2 0/3] alsa recipe updates
The following changes since commit ff2c029b568f70aa9960dde04ddd207829812ea0: resulttool: Improvements to allow integration to the autobuilder (2019-02-21 12:31:50 +) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib tanuk/updates http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates The alsa-tools update is missing, because the recipe upgrade deadline is near and the changes in alsa-tools look like a potential rabbit hole. I'll send the alsa-tools update separately when it's ready. The main change in alsa-tools is that the hwmixvolume program got ported from PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone actually is using that program, it's not even built by default. Changes in v2: - More reliable SRC_URIs. Tanu Kaskinen (3): alsa-lib: 1.1.6 -> 1.1.8 alsa-plugins: 1.1.6 -> 1.1.8 alsa-utils: 1.1.6 -> 1.1.8 .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 6 +- ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 86 +-- ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 14 ++- .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- 5 files changed, 88 insertions(+), 20 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} (83%) rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} (50%) rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} (100%) rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} (90%) -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/3] alsa-lib: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 One significant change was that the search path of add-on configuration files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d. Packages that install such files should still use the /usr/share location, though. Symlinks need to be created from /etc to /usr/share. The rationale for using /etc is that the system administrator can better control the configuration that way, and the rationale for installing files under /usr/share is that configuration snippets that are installed by packages are not meant to be directly edited by the administrator. alsa-plugins had to be modified to add symlinks for the configuration snippets that it installs. I also added FILES_${PN} = "", because the alsa-plugins package is supposed to be empty, but also because for some reason that I don't understand the symlinks would otherwise go to the alsa-plugins package rather than alsa-plugins-pulseaudio-conf. SRC_URI was changed to a more reliable source (at least currently the ftp server is flaky). Signed-off-by: Tanu Kaskinen --- .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 6 +++--- meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb | 13 - 2 files changed, 15 insertions(+), 4 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} (83%) diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb similarity index 83% rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb index 25e7a3c6b7..76cc9627e5 100644 --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb @@ -7,9 +7,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \ file://src/socket.c;md5=dd1bc7f44872690224d89c1a9806e495;beginline=1;endline=26 \ " -SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2; -SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788" -SRC_URI[sha256sum] = "5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724" +SRC_URI = "https://www.alsa-project.org/files/pub/lib/${BP}.tar.bz2; +SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca" +SRC_URI[sha256sum] = "3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf" inherit autotools pkgconfig diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb index 7ede8be98a..ee06191ea9 100644 --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb @@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*" # The alsa-plugins package doesn't itself contain anything, it just depends on # all built plugins. +FILES_${PN} = "" ALLOW_EMPTY_${PN} = "1" do_install_append() { rm ${D}${libdir}/alsa-lib/*.la - # We use the example as is, so just drop the .example suffix. if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', d)}" = "yes" ]; then + # We use the example as is, so just drop the .example suffix. mv ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf + + # The conf.d files are installed in datadir, but alsa-lib + # searches for conf.d files only in sysconfdir. Distributions + # are expected to create symlinks in sysconfdir, so that's what + # we do here. + mkdir -p ${D}${sysconfdir}/alsa/conf.d + ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf + ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf fi } @@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = "dev-so" FILES_${PN}-pulseaudio-conf += "\ ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \ ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \ +${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \ +${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \ " RDEPENDS_${PN}-pulseaudio-conf += "\ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/3] alsa-utils: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 There's a new program, axfer, which is a reimplementation of aplay (and arecord). The purpose of the rewrite is to have code that is easier to maintain. For now both implementations exist, and I decided to put both in the aplay package. The new 89-alsa-ucm.rules udev file initializes the mixer settings for certain hardware. It's needed for making the hardware usable at boot, in case there's no higher level software (such as PulseAudio) managing the mixer settings. Shipping hardware specific configuration in alsa-utils seems wrong, but I don't know what else to do. I added it to the alsaucm package, because it's kind of tied to the alsaucm utility (the udev rules execute the alsaucm program, and the build system installs the rules file only when alsaucm is enabled). Ideally the UCM configuration in alsa-lib would define the default UCM verb for each hardware, then the udev rules file could just enable the default verb, and there would be no hardware specific configuration in alsa-utils. But that requires upstream development effort. SRC_URI was changed to a more reliable source (at least currently the ftp server is flaky). Signed-off-by: Tanu Kaskinen --- ...cripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 .../{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 14 ++ 2 files changed, 6 insertions(+), 8 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} (100%) rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} (90%) diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb similarity index 100% rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb similarity index 90% rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb index b8ba0cb22a..1e21022e95 100644 --- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb @@ -19,11 +19,9 @@ PACKAGECONFIG[bat] = "--enable-bat,--disable-bat,fftwf" PACKAGECONFIG[udev] = "--with-udev-rules-dir=`pkg-config --variable=udevdir udev`/rules.d,--with-udev-rules-dir=/unwanted/rules.d,udev" PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, xmlto-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native" -SRC_URI = "ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \ - " - -SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002" -SRC_URI[sha256sum] = "155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e" +SRC_URI = "https://www.alsa-project.org/files/pub/utils/${BP}.tar.bz2; +SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028" +SRC_URI[sha256sum] = "fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf" # On build machines with python-docutils (not python3-docutils !!) installed # rst2man (not rst2man.py) is detected and compile fails with @@ -59,7 +57,7 @@ RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}" FILES_${PN} = "" FILES_alsa-utils-alsabat = "${bindir}/alsabat" FILES_alsa-utils-alsatplg= "${bindir}/alsatplg" -FILES_alsa-utils-aplay = "${bindir}/aplay ${bindir}/arecord" +FILES_alsa-utils-aplay = "${bindir}/aplay ${bindir}/arecord ${bindir}/axfer" FILES_alsa-utils-amixer = "${bindir}/amixer" FILES_alsa-utils-alsamixer = "${bindir}/alsamixer" FILES_alsa-utils-speakertest = "${bindir}/speaker-test ${datadir}/sounds/alsa/ ${datadir}/alsa/speaker-test/" @@ -67,10 +65,10 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi ${bindir}/arecordmidi ${bind FILES_alsa-utils-aconnect= "${bindir}/aconnect" FILES_alsa-utils-aseqnet = "${bindir}/aseqnet" FILES_alsa-utils-iecset = "${bindir}/iecset" -FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d */*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/" +FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules ${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/" FILES_alsa-utils-aseqdump= "${bindir}/aseqdump" FILES_alsa-utils-alsaloop= "${bindir}/alsaloop" -FILES_alsa-utils-alsaucm = "${bindir}/alsaucm" +FILES_alsa-utils-alsaucm = "${bindir}/alsaucm */udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules" SUMMARY_alsa-utils-alsabat = "Command-line sound tester for ALSA sound card driver" SUMMARY_alsa-utils-alsatplg = "Converts topology text files into binary format for kernel" -- 2.20.1 --
Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8
On Thu, 2019-02-21 at 21:38 +0200, Tanu Kaskinen wrote: > On Thu, 2019-02-21 at 10:43 -0800, Khem Raj wrote: > > WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL > > ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting > > MIRRORS if available > > > > we might need a better source > > I don't know what's going on with the alsa infrastructure, it has had > various problems since last weekend. Sometimes the ftp server works, > sometimes it doesn't. The ftp server is certainly the official source, > since that's what was advertised in the release announcement. > > In my testing I used Debian's archives, but I suppose it's not cool to > cause server load on Debian. > > Is github a good source? If I recall correctly, github has had some > kind of problems in the past regarding checksum stability, has that > improved? I see there are many recipes using github, so I suppose it's > ok. > > This link seems to work: > https://github.com/alsa-project/alsa-lib/archive/v1.1.8.tar.gz > ...but most github SRC_URIs have structure where the the tarball is > under archive/download// and I wasn't able to figure out a > working url for alsa-lib that would have that structure. Never mind, I didn't notice that Alex already provided a good source. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8
On Thu, 2019-02-21 at 10:43 -0800, Khem Raj wrote: > WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL > ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting > MIRRORS if available > > we might need a better source I don't know what's going on with the alsa infrastructure, it has had various problems since last weekend. Sometimes the ftp server works, sometimes it doesn't. The ftp server is certainly the official source, since that's what was advertised in the release announcement. In my testing I used Debian's archives, but I suppose it's not cool to cause server load on Debian. Is github a good source? If I recall correctly, github has had some kind of problems in the past regarding checksum stability, has that improved? I see there are many recipes using github, so I suppose it's ok. This link seems to work: https://github.com/alsa-project/alsa-lib/archive/v1.1.8.tar.gz ...but most github SRC_URIs have structure where the the tarball is under archive/download// and I wasn't able to figure out a working url for alsa-lib that would have that structure. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8
WARNING: alsa-lib-native-1.1.8-r0 do_fetch: Failed to fetch URL ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.8.tar.bz2, attempting MIRRORS if available we might need a better source On Thu, Feb 21, 2019 at 5:34 AM Tanu Kaskinen wrote: > > Changelogs: > http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 > http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 > > One significant change was that the search path of add-on configuration > files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d. > Packages that install such files should still use the /usr/share > location, though. Symlinks need to be created from /etc to /usr/share. > The rationale for using /etc is that the system administrator can better > control the configuration that way, and the rationale for installing > files under /usr/share is that configuration snippets that are installed > by packages are not meant to be directly edited by the administrator. > > alsa-plugins had to be modified to add symlinks for the configuration > snippets that it installs. I also added FILES_${PN} = "", because the > alsa-plugins package is supposed to be empty, but also because for some > reason that I don't understand the symlinks would otherwise go to the > alsa-plugins package rather than alsa-plugins-pulseaudio-conf. > > Signed-off-by: Tanu Kaskinen > --- > .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 ++-- > meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb | 13 - > 2 files changed, 14 insertions(+), 3 deletions(-) > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} > (88%) > > diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb > b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb > similarity index 88% > rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb > rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb > index 25e7a3c6b7..bb22acdd33 100644 > --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb > +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb > @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = > "file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \ > " > > SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2; > -SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788" > -SRC_URI[sha256sum] = > "5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724" > +SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca" > +SRC_URI[sha256sum] = > "3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf" > > inherit autotools pkgconfig > > diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb > b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb > index 7ede8be98a..ee06191ea9 100644 > --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb > +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb > @@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*" > > # The alsa-plugins package doesn't itself contain anything, it just depends > on > # all built plugins. > +FILES_${PN} = "" > ALLOW_EMPTY_${PN} = "1" > > do_install_append() { > rm ${D}${libdir}/alsa-lib/*.la > > - # We use the example as is, so just drop the .example suffix. > if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', > 'no', d)}" = "yes" ]; then > + # We use the example as is, so just drop the .example suffix. > mv > ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example > ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf > + > + # The conf.d files are installed in datadir, but alsa-lib > + # searches for conf.d files only in sysconfdir. Distributions > + # are expected to create symlinks in sysconfdir, so that's > what > + # we do here. > + mkdir -p ${D}${sysconfdir}/alsa/conf.d > + ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf > ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf > + ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf > ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf > fi > } > > @@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = > "dev-so" > FILES_${PN}-pulseaudio-conf += "\ > ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \ > ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \ > +${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \ > +${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \ > " > > RDEPENDS_${PN}-pulseaudio-conf += "\ > -- > 2.20.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] alsa recipe updates
ftp://ftp.alsa.org seems inaccessible or unstable: https://autobuilder.yoctoproject.org/typhoon/#/builders/70/builds/317/steps/7/logs/step1b (also can't open it on my local machine) and generally we prefer http:// sources over ftp, if available. Alsa does have one: https://www.alsa-project.org/files/ so can you please resend with SRC_URIs changed to use it? (also for alsa-tools and everywhere where the ftp is currently used) Alex On Thu, 21 Feb 2019 at 19:09, Alexander Kanavin wrote: > > Bah, and I often point out to people that they should read *my* cover letters > :) > Thanks! > > Alex > > On Thu, 21 Feb 2019 at 17:41, Tanu Kaskinen wrote: > > > > Richard already sent the update for sbc, so I left it out. As for alsa- > > tools, if you read the cover letter in more detail, you'll find the > > answer there :) (Spoiler: I'll send it, but it's not ready yet.) > > > > -- Tanu > > > > On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote: > > > (Also sbc needs an update, I think) > > > > > > Alex > > > > > > > > > On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin > > > wrote: > > > > Thanks! Will you be also sending an update to alsa-tools? > > > > > > > > Alex > > > > > > > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen wrote: > > > > > The following changes since commit > > > > > f15ceac287c094abdeda64b03628455d92e0ce74: > > > > > > > > > > libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) > > > > > > > > > > are available in the Git repository at: > > > > > > > > > > git://git.openembedded.org/openembedded-core-contrib tanuk/updates > > > > > > > > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates > > > > > > > > > > > > > > > The alsa-tools update is missing, because the recipe upgrade deadline > > > > > is > > > > > near and the changes in alsa-tools look like a potential rabbit hole. > > > > > I'll send the alsa-tools update separately when it's ready. The main > > > > > change in alsa-tools is that the hwmixvolume program got ported from > > > > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone > > > > > actually is using that program, it's not even built by default. > > > > > > > > > > > > > > > Tanu Kaskinen (3): > > > > > alsa-lib: 1.1.6 -> 1.1.8 > > > > > alsa-plugins: 1.1.6 -> 1.1.8 > > > > > alsa-utils: 1.1.6 -> 1.1.8 > > > > > > > > > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- > > > > > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 > > > > > +-- > > > > > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > > > > > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- > > > > > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- > > > > > 5 files changed, 85 insertions(+), 15 deletions(-) > > > > > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => > > > > > alsa-lib_1.1.8.bb} (88%) > > > > > rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => > > > > > alsa-plugins_1.1.8.bb} (51%) > > > > > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => > > > > > alsa-utils-scripts_1.1.8.bb} (100%) > > > > > rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => > > > > > alsa-utils_1.1.8.bb} (92%) > > > > > > > > > > -- > > > > > 2.20.1 > > > > > > > > > > -- > > > > > ___ > > > > > Openembedded-core mailing list > > > > > Openembedded-core@lists.openembedded.org > > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > -- > > Tanu > > > > https://www.patreon.com/tanuk > > https://liberapay.com/tanuk > > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Openembedded-architecture] Incorporating deploy artefacts from one multiconfig in another multiconfig
On 2/21/19 9:44 AM, Burton, Ross wrote: > So I'd like to use multiconfig for a fairly typical host/container use > case. I've a class which can be used to build packages from images in > a fairly simple manner, essential just taking files from DEPLOY_DIR > when creating a package: > > core-image-minimal-package.bb: > do_install[depends] += "core-image-minimal:do_image_complete > virtual/kernel:do_deploy" > do_install () { > install -d ${D}/var/lib/machines/ > install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4 > ${D}/var/lib/machines/core-image-minimal.ext4 > install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} > ${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE} > } > > This part works fine, but the problem is straddling multiconfig boundaries... > > I can't just add "core-image-minimal-package" to IMAGE_INSTALL because > it will build that for the current configuration. I can't just add > "multiconfig:uos:core-image-minimal-package" because that will look > for a recipe with that name. I've a rather ugly hack to call opkg > directly in a post-rootfs hook which sort of works. Linking in bits > of the other configuration's deploy directory in a pre-rootfs hook and > extending IMAGE_INSTALL there almost works, apart from the rootfs code > then looks at the task dependencies to generate a pruned deploy dir, > which is missing the pieces I linked in. > > I suspect this is now breaking new ground: the multiconfiguration > support lets you do builds but so far the artefact sharing hasn't > really been explored. Has anyone dug further into this? I don't think anyone has. But as we continue moving toward containers/micro services environments -- this exactly type of thing is going to be more and more needed. One 'build', with various configurations that end up constructing a single device image with a container runtime (booting OS), and a number of container micro services should be able to be created with a single call to bitbake and (a potentially complex) config. I think the first question is, can one multiconfig require a dependency out of another yet? I thought this was still unimplemented. Once this can be done, then it should be much easier to have a 'configuration' whose job it is to assemble the various components while waiting for everything to finish being built. --Mark > Ross > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ltp: Bump to 20190115
This patch has been refreshed: * 0008-Check-if-__GLIBC_PREREQ-is-defined-before-using-it.patch These patches have been dropped as they have been merged: * 0001-netns_helper.sh-use-ping-6-when-ping6-is-not-avaliab.patch * 0001-setrlimit05-Use-another-method-to-get-bad-address.patch * 0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch * 0001-statx-fix-compile-errors.patch * 0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch * 0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch This patch has been added: * define-sigrtmin-and-sigrtmax-for-musl.patch Added these rdependencies: * file: for ld01, file01 and logrotate * quota: for quota_remount_test01 Signed-off-by: Daniel DÃaz --- ...getcpu-to-avoid-conflict-with-glibc-.patch | 57 -- ...use-ping-6-when-ping6-is-not-avaliab.patch | 45 - ...suite-mmap24-2-Relax-condition-a-bit.patch | 6 +- ...se-another-method-to-get-bad-address.patch | 61 -- ...-recent-glibc-calls-syscall-directly.patch | 75 --- .../ltp/0001-statx-fix-compile-errors.patch | 35 ...ake-OFD-command-use-fcntl64-syscall-.patch | 184 - ...option-to-select-libc-implementation.patch | 3 +- ...E-undeclared-when-building-with-musl.patch | 2 +- ...BC_PREREQ-is-defined-before-using-it.patch | 190 +++--- .../ltp/0035-fix-test_proc_kill-hang.patch| 2 +- ...1-Fix-for-test-in-deterministic-mode.patch | 2 +- ...efine-sigrtmin-and-sigrtmax-for-musl.patch | 114 +++ .../ltp/{ltp_20180926.bb => ltp_20190115.bb} | 11 +- 14 files changed, 154 insertions(+), 633 deletions(-) delete mode 100644 meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch delete mode 100644 meta/recipes-extended/ltp/ltp/0001-netns_helper.sh-use-ping-6-when-ping6-is-not-avaliab.patch delete mode 100644 meta/recipes-extended/ltp/ltp/0001-setrlimit05-Use-another-method-to-get-bad-address.patch delete mode 100644 meta/recipes-extended/ltp/ltp/0001-sigwaitinfo01-recent-glibc-calls-syscall-directly.patch delete mode 100644 meta/recipes-extended/ltp/ltp/0001-statx-fix-compile-errors.patch delete mode 100644 meta/recipes-extended/ltp/ltp/0001-syscalls-fcntl-make-OFD-command-use-fcntl64-syscall-.patch create mode 100644 meta/recipes-extended/ltp/ltp/define-sigrtmin-and-sigrtmax-for-musl.patch rename meta/recipes-extended/ltp/{ltp_20180926.bb => ltp_20190115.bb} (91%) diff --git a/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch b/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch deleted file mode 100644 index d0c847774d..00 --- a/meta/recipes-extended/ltp/ltp/0001-getcpu01-Rename-getcpu-to-avoid-conflict-with-glibc-.patch +++ /dev/null @@ -1,57 +0,0 @@ -From c9edb0eaaca83c18ac7b5ea3330faad8d47d3fd1 Mon Sep 17 00:00:00 2001 -From: Khem Raj -Date: Fri, 14 Dec 2018 06:44:02 -0800 -Subject: [PATCH] getcpu01: Rename getcpu to avoid conflict with glibc >= 2.29 - -glibc has added getcpu() API starting with glibc 2.29 release, this -makes the static function in conflict and signatures are not same as -well. - -Renaming helps to keep ltp build going - -Upstream-Status: Submitted [http://lists.linux.it/pipermail/ltp/2018-December/010321.html] - -Signed-off-by: Khem Raj - testcases/kernel/syscalls/getcpu/getcpu01.c | 10 +- - 1 file changed, 5 insertions(+), 5 deletions(-) - -diff --git a/testcases/kernel/syscalls/getcpu/getcpu01.c b/testcases/kernel/syscalls/getcpu/getcpu01.c -index c927512ca..e850fe844 100644 a/testcases/kernel/syscalls/getcpu/getcpu01.c -+++ b/testcases/kernel/syscalls/getcpu/getcpu01.c -@@ -82,7 +82,7 @@ int sys_support = 0; - - void cleanup(void); - void setup(void); --static inline int getcpu(unsigned int *, unsigned int *, void *); -+static inline int get_cpu(unsigned int *, unsigned int *, void *); - unsigned int set_cpu_affinity(void); - unsigned int get_nodeid(unsigned int); - unsigned int max_cpuid(size_t, cpu_set_t *); -@@ -124,7 +124,7 @@ int main(int ac, char **av) - #ifdef __i386__ - node_set = get_nodeid(cpu_set); - #endif -- TEST(getcpu(_id, _id, NULL)); -+ TEST(get_cpu(_id, _id, NULL)); - if (TEST_RETURN == 0) { - if (cpu_id != cpu_set) { - tst_resm(TFAIL, "getcpu() returned wrong value" -@@ -157,10 +157,10 @@ int main(int ac, char **av) - } - - /* -- * getcpu() - calls the system call -+ * get_cpu() - calls the system call - */ --static inline int getcpu(unsigned *cpu_id, unsigned *node_id, -- void *cache_struct) -+static inline int get_cpu(unsigned *cpu_id, unsigned *node_id, -+void *cache_struct) - { - #if defined(__i386__) - return syscall(318, cpu_id, node_id, cache_struct); --- -2.20.0 - diff --git
Re: [OE-core] [PATCH 0/3] alsa recipe updates
Bah, and I often point out to people that they should read *my* cover letters :) Thanks! Alex On Thu, 21 Feb 2019 at 17:41, Tanu Kaskinen wrote: > > Richard already sent the update for sbc, so I left it out. As for alsa- > tools, if you read the cover letter in more detail, you'll find the > answer there :) (Spoiler: I'll send it, but it's not ready yet.) > > -- Tanu > > On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote: > > (Also sbc needs an update, I think) > > > > Alex > > > > > > On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin > > wrote: > > > Thanks! Will you be also sending an update to alsa-tools? > > > > > > Alex > > > > > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen wrote: > > > > The following changes since commit > > > > f15ceac287c094abdeda64b03628455d92e0ce74: > > > > > > > > libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) > > > > > > > > are available in the Git repository at: > > > > > > > > git://git.openembedded.org/openembedded-core-contrib tanuk/updates > > > > > > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates > > > > > > > > > > > > The alsa-tools update is missing, because the recipe upgrade deadline is > > > > near and the changes in alsa-tools look like a potential rabbit hole. > > > > I'll send the alsa-tools update separately when it's ready. The main > > > > change in alsa-tools is that the hwmixvolume program got ported from > > > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone > > > > actually is using that program, it's not even built by default. > > > > > > > > > > > > Tanu Kaskinen (3): > > > > alsa-lib: 1.1.6 -> 1.1.8 > > > > alsa-plugins: 1.1.6 -> 1.1.8 > > > > alsa-utils: 1.1.6 -> 1.1.8 > > > > > > > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- > > > > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +-- > > > > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > > > > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- > > > > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- > > > > 5 files changed, 85 insertions(+), 15 deletions(-) > > > > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => > > > > alsa-lib_1.1.8.bb} (88%) > > > > rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => > > > > alsa-plugins_1.1.8.bb} (51%) > > > > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => > > > > alsa-utils-scripts_1.1.8.bb} (100%) > > > > rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => > > > > alsa-utils_1.1.8.bb} (92%) > > > > > > > > -- > > > > 2.20.1 > > > > > > > > -- > > > > ___ > > > > Openembedded-core mailing list > > > > Openembedded-core@lists.openembedded.org > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- > Tanu > > https://www.patreon.com/tanuk > https://liberapay.com/tanuk > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] alsa recipe updates
Richard already sent the update for sbc, so I left it out. As for alsa- tools, if you read the cover letter in more detail, you'll find the answer there :) (Spoiler: I'll send it, but it's not ready yet.) -- Tanu On Thu, 2019-02-21 at 15:57 +0100, Alexander Kanavin wrote: > (Also sbc needs an update, I think) > > Alex > > > On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin > wrote: > > Thanks! Will you be also sending an update to alsa-tools? > > > > Alex > > > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen wrote: > > > The following changes since commit > > > f15ceac287c094abdeda64b03628455d92e0ce74: > > > > > > libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) > > > > > > are available in the Git repository at: > > > > > > git://git.openembedded.org/openembedded-core-contrib tanuk/updates > > > > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates > > > > > > > > > The alsa-tools update is missing, because the recipe upgrade deadline is > > > near and the changes in alsa-tools look like a potential rabbit hole. > > > I'll send the alsa-tools update separately when it's ready. The main > > > change in alsa-tools is that the hwmixvolume program got ported from > > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone > > > actually is using that program, it's not even built by default. > > > > > > > > > Tanu Kaskinen (3): > > > alsa-lib: 1.1.6 -> 1.1.8 > > > alsa-plugins: 1.1.6 -> 1.1.8 > > > alsa-utils: 1.1.6 -> 1.1.8 > > > > > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- > > > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +-- > > > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > > > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- > > > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- > > > 5 files changed, 85 insertions(+), 15 deletions(-) > > > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => > > > alsa-lib_1.1.8.bb} (88%) > > > rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => > > > alsa-plugins_1.1.8.bb} (51%) > > > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => > > > alsa-utils-scripts_1.1.8.bb} (100%) > > > rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => > > > alsa-utils_1.1.8.bb} (92%) > > > > > > -- > > > 2.20.1 > > > > > > -- > > > ___ > > > Openembedded-core mailing list > > > Openembedded-core@lists.openembedded.org > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Incorporating deploy artefacts from one multiconfig in another multiconfig
So I'd like to use multiconfig for a fairly typical host/container use case. I've a class which can be used to build packages from images in a fairly simple manner, essential just taking files from DEPLOY_DIR when creating a package: core-image-minimal-package.bb: do_install[depends] += "core-image-minimal:do_image_complete virtual/kernel:do_deploy" do_install () { install -d ${D}/var/lib/machines/ install ${DEPLOY_DIR_IMAGE}/core-image-minimal-${MACHINE}.ext4 ${D}/var/lib/machines/core-image-minimal.ext4 install ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE} ${D}/var/lib/machines/${IMAGE_NAME}.${KERNEL_IMAGETYPE} } This part works fine, but the problem is straddling multiconfig boundaries... I can't just add "core-image-minimal-package" to IMAGE_INSTALL because it will build that for the current configuration. I can't just add "multiconfig:uos:core-image-minimal-package" because that will look for a recipe with that name. I've a rather ugly hack to call opkg directly in a post-rootfs hook which sort of works. Linking in bits of the other configuration's deploy directory in a pre-rootfs hook and extending IMAGE_INSTALL there almost works, apart from the rootfs code then looks at the task dependencies to generate a pruned deploy dir, which is missing the pieces I linked in. I suspect this is now breaking new ground: the multiconfiguration support lets you do builds but so far the artefact sharing hasn't really been explored. Has anyone dug further into this? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system
On Wed, Feb 20, 2019 at 9:11 PM Khem Raj wrote: > > still seeing errors when building for rpi3-64 > > | checking for xrandr... no > | configure: error: Package requirements (xrandr) were not met: > | > | No package 'xrandr' found > | > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > | installed software in a non-standard prefix. > This is fixed with latest commit so we can move on but there is new one on aarch64/rpi https://errors.yoctoproject.org/Errors/Details/229582/ seems to be due to this commit. https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743 probably a revert of the above patch is what can get us further. > > On Wed, Feb 20, 2019 at 4:41 PM Mittal, Anuj wrote: > > > > On Wed, 2019-02-20 at 18:10 -0300, Fabio Berton wrote: > > > +PACKAGECONFIG[xvmc] = "-gallium-xvmc=true,-Dgallium- > > > xvmc=false,libxvmc" > > > > This is missing a '-D' ... Was a problem with my original patch as > > well. > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system
On Thu, Feb 21, 2019 at 7:04 AM Khem Raj wrote: > > On Thu, Feb 21, 2019 at 7:01 AM Alexander Kanavin > wrote: > > > > On Thu, 21 Feb 2019 at 15:56, Khem Raj wrote: > > > > still seeing errors when building for rpi3-64 > > > > > > > > | checking for xrandr... no > > > > | configure: error: Package requirements (xrandr) were not met: > > > > | > > > > | No package 'xrandr' found > > > > | > > > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > > > > | installed software in a non-standard prefix. > > > > > > > > > > This is fixed with latest commit so we can move on but there is new one > > > on aarch64/rpi > > > > > > https://errors.yoctoproject.org/Errors/Details/229582/ > > > > > > seems to be due to this commit. > > > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743 > > > > > > probably a revert of the above patch is what can get us further. > > > > Shouldn't we rather add a dependency on the component providing the > > missing include? > > fredreno build uses its own copy of libdrm IIRC and this might end up > in unexpected results > so revert would be safest > infact upstream has reverted it too https://gitlab.freedesktop.org/mesa/drm/commit/e09f327765902f3b7d31874ccf0f45b783299bc0 > > > > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system
On Thu, Feb 21, 2019 at 7:01 AM Alexander Kanavin wrote: > > On Thu, 21 Feb 2019 at 15:56, Khem Raj wrote: > > > still seeing errors when building for rpi3-64 > > > > > > | checking for xrandr... no > > > | configure: error: Package requirements (xrandr) were not met: > > > | > > > | No package 'xrandr' found > > > | > > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > > > | installed software in a non-standard prefix. > > > > > > > This is fixed with latest commit so we can move on but there is new one > > on aarch64/rpi > > > > https://errors.yoctoproject.org/Errors/Details/229582/ > > > > seems to be due to this commit. > > > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743 > > > > probably a revert of the above patch is what can get us further. > > Shouldn't we rather add a dependency on the component providing the > missing include? fredreno build uses its own copy of libdrm IIRC and this might end up in unexpected results so revert would be safest > > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC][PATCH v3] mesa: Convert recipe to use meson build system
On Thu, 21 Feb 2019 at 15:56, Khem Raj wrote: > > still seeing errors when building for rpi3-64 > > > > | checking for xrandr... no > > | configure: error: Package requirements (xrandr) were not met: > > | > > | No package 'xrandr' found > > | > > | Consider adjusting the PKG_CONFIG_PATH environment variable if you > > | installed software in a non-standard prefix. > > > > This is fixed with latest commit so we can move on but there is new one > on aarch64/rpi > > https://errors.yoctoproject.org/Errors/Details/229582/ > > seems to be due to this commit. > > https://gitlab.freedesktop.org/mesa/drm/commit/b541d21a0a908bf98d44375720f4430297720743 > > probably a revert of the above patch is what can get us further. Shouldn't we rather add a dependency on the component providing the missing include? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] alsa recipe updates
(Also sbc needs an update, I think) Alex On Thu, 21 Feb 2019 at 15:56, Alexander Kanavin wrote: > > Thanks! Will you be also sending an update to alsa-tools? > > Alex > > On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen wrote: > > > > The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74: > > > > libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) > > > > are available in the Git repository at: > > > > git://git.openembedded.org/openembedded-core-contrib tanuk/updates > > > > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates > > > > > > The alsa-tools update is missing, because the recipe upgrade deadline is > > near and the changes in alsa-tools look like a potential rabbit hole. > > I'll send the alsa-tools update separately when it's ready. The main > > change in alsa-tools is that the hwmixvolume program got ported from > > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone > > actually is using that program, it's not even built by default. > > > > > > Tanu Kaskinen (3): > > alsa-lib: 1.1.6 -> 1.1.8 > > alsa-plugins: 1.1.6 -> 1.1.8 > > alsa-utils: 1.1.6 -> 1.1.8 > > > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- > > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +-- > > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- > > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- > > 5 files changed, 85 insertions(+), 15 deletions(-) > > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => > > alsa-lib_1.1.8.bb} (88%) > > rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => > > alsa-plugins_1.1.8.bb} (51%) > > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => > > alsa-utils-scripts_1.1.8.bb} (100%) > > rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => > > alsa-utils_1.1.8.bb} (92%) > > > > -- > > 2.20.1 > > > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe] [PATCH 2/2] gtkwave: add version 3.3.98
On 2/20/19 11:33 PM, Hoang Anh Tuan wrote: > > Signed-off-by: Hoang Anh Tuan Wrong ML, please send to openembedded-de...@lists.openembedded.org > --- > Â meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb | 19 > +++ > Â 1 file changed, 19 insertions(+) > Â create mode 100644 meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb > > diff --git a/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb > b/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb > new file mode 100644 > index 000..6fd9392 > --- /dev/null > +++ b/meta-oe/recipes-graphics/gtkwave/gtkwave_3.3.98.bb > @@ -0,0 +1,19 @@ > +SUMMARY = "VCD (Value Change Dump) file waveform viewer" > +DESCRIPTION = "gtkwave is a viewer for VCD (Value Change Dump) files > which are usually created by digital circuit simulators. (These files > have no connection to video CDs!) " > +HOMEPAGE = "http://gtkwave.sourceforge.net/; > + > +LICENSE = "GPLv2" > +LIC_FILES_CHKSUM = "file://COPYING;md5=75859989545e37968a99b631ef42722e" > + > +SRC_URI = "http://gtkwave.sourceforge.net/${PN}-${PV}.tar.gz; > + > +SRC_URI[md5sum] = "eac3073ef381e0c09da33590296ca37f" > +SRC_URI[sha256sum] = > "efa6bbbeb3bd54104425a69a2aa0d079bb5c3ecc1c420ba57dcaa1c97c5a22f6" > + > +inherit pkgconfig autotools gettext texinfo > +DEPENDS = "tcl tk gperf-native bzip2 xz pango zlib gtk+ gdk-pixbuf > glib-2.0" > +RDEPENDS_${PN} = "tk-lib" > + > +EXTRA_OECONF = "--with-tcl=${STAGING_BINDIR_CROSS} > --with-tk=${STAGING_BINDIR_CROSS}" > + > +FILES_${PN} = "${bindir} ${datadir}" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/3] alsa recipe updates
Thanks! Will you be also sending an update to alsa-tools? Alex On Thu, 21 Feb 2019 at 14:34, Tanu Kaskinen wrote: > > The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74: > > libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) > > are available in the Git repository at: > > git://git.openembedded.org/openembedded-core-contrib tanuk/updates > http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates > > > The alsa-tools update is missing, because the recipe upgrade deadline is > near and the changes in alsa-tools look like a potential rabbit hole. > I'll send the alsa-tools update separately when it's ready. The main > change in alsa-tools is that the hwmixvolume program got ported from > PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone > actually is using that program, it's not even built by default. > > > Tanu Kaskinen (3): > alsa-lib: 1.1.6 -> 1.1.8 > alsa-plugins: 1.1.6 -> 1.1.8 > alsa-utils: 1.1.6 -> 1.1.8 > > .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- > ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +-- > ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 > ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- > .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- > 5 files changed, 85 insertions(+), 15 deletions(-) > rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} > (88%) > rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => > alsa-plugins_1.1.8.bb} (51%) > rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => > alsa-utils-scripts_1.1.8.bb} (100%) > rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => > alsa-utils_1.1.8.bb} (92%) > > -- > 2.20.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
On Wed, Feb 20, 2019 at 10:55:20AM +, Mike Looijmans wrote: > >>> I am aware of two fixes for U-Boot. I will look them up, and reply again > >>> to this thread. > > Browsing through u-boot commits, I found this gem that's disabled by default: > > CONFIG_BLOCK_CACHE=y > > The commit is this one: > > commit e40cf34a29f1b248643731a11fb1c6f0520d016c > Author: Eric Nelson > Date: Mon Mar 28 10:05:44 2016 -0700 > > drivers: block: add block device cache > > Add a block device cache to speed up repeated reads of block devices by > various filesystems. For the record, it's not that it's disabled by default but rather to enable it, you need to enable other "new" frameworks and so forth. And at least for "legacy" platforms, there's a certain level of pushback against doing the work required to enable that (as to be honest, it is more than just enable a few CONFIG options and re-test). A counter-pushback of "but it enables things that fix some bad performance problems!" would be really helpful. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/3] alsa recipe updates
The following changes since commit f15ceac287c094abdeda64b03628455d92e0ce74: libdrm: Upgrade 2.4.96 -> 2.4.97 (2019-02-20 21:22:28 +) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib tanuk/updates http://cgit.openembedded.org/openembedded-core-contrib/log/?h=tanuk/updates The alsa-tools update is missing, because the recipe upgrade deadline is near and the changes in alsa-tools look like a potential rabbit hole. I'll send the alsa-tools update separately when it's ready. The main change in alsa-tools is that the hwmixvolume program got ported from PyGTK to gobject-introspection, and from GTK2 to GTK3. I doubt anyone actually is using that program, it's not even built by default. Tanu Kaskinen (3): alsa-lib: 1.1.6 -> 1.1.8 alsa-plugins: 1.1.6 -> 1.1.8 alsa-utils: 1.1.6 -> 1.1.8 .../{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 +- ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 84 +-- ...s_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 ...lsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +-- .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- 5 files changed, 85 insertions(+), 15 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} (88%) rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} (51%) rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} (100%) rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} (92%) -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/3] alsa-lib: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 One significant change was that the search path of add-on configuration files was changed from /usr/share/alsa/alsa.conf.d to /etc/alsa/conf.d. Packages that install such files should still use the /usr/share location, though. Symlinks need to be created from /etc to /usr/share. The rationale for using /etc is that the system administrator can better control the configuration that way, and the rationale for installing files under /usr/share is that configuration snippets that are installed by packages are not meant to be directly edited by the administrator. alsa-plugins had to be modified to add symlinks for the configuration snippets that it installs. I also added FILES_${PN} = "", because the alsa-plugins package is supposed to be empty, but also because for some reason that I don't understand the symlinks would otherwise go to the alsa-plugins package rather than alsa-plugins-pulseaudio-conf. Signed-off-by: Tanu Kaskinen --- .../alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} | 4 ++-- meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb | 13 - 2 files changed, 14 insertions(+), 3 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-lib_1.1.6.bb => alsa-lib_1.1.8.bb} (88%) diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb similarity index 88% rename from meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb index 25e7a3c6b7..bb22acdd33 100644 --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.8.bb @@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a916467b91076e631dd8edb7424769c7 \ " SRC_URI = "ftp://ftp.alsa-project.org/pub/lib/${BP}.tar.bz2; -SRC_URI[md5sum] = "2f981a8f7897c59ec2ddc44916d33788" -SRC_URI[sha256sum] = "5f2cd274b272cae0d0d111e8a9e363f08783329157e8dd68b3de0c096de6d724" +SRC_URI[md5sum] = "0eec0d657a07927795809c8f87fb76ca" +SRC_URI[sha256sum] = "3cdc3a93a6427a26d8efab4ada2152e64dd89140d981f6ffa003e85be707aedf" inherit autotools pkgconfig diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb index 7ede8be98a..ee06191ea9 100644 --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb @@ -47,14 +47,23 @@ PACKAGES_DYNAMIC = "^libasound-module-.*" # The alsa-plugins package doesn't itself contain anything, it just depends on # all built plugins. +FILES_${PN} = "" ALLOW_EMPTY_${PN} = "1" do_install_append() { rm ${D}${libdir}/alsa-lib/*.la - # We use the example as is, so just drop the .example suffix. if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', d)}" = "yes" ]; then + # We use the example as is, so just drop the .example suffix. mv ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf + + # The conf.d files are installed in datadir, but alsa-lib + # searches for conf.d files only in sysconfdir. Distributions + # are expected to create symlinks in sysconfdir, so that's what + # we do here. + mkdir -p ${D}${sysconfdir}/alsa/conf.d + ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf + ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf fi } @@ -94,6 +103,8 @@ INSANE_SKIP_${MLPREFIX}libasound-module-rate-speexrate = "dev-so" FILES_${PN}-pulseaudio-conf += "\ ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf \ ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf \ +${sysconfdir}/alsa/conf.d/50-pulseaudio.conf \ +${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf \ " RDEPENDS_${PN}-pulseaudio-conf += "\ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/3] alsa-utils: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 There's a new program, axfer, which is a reimplementation of aplay (and arecord). The purpose of the rewrite is to have code that is easier to maintain. For now both implementations exist, and I decided to put both in the aplay package. The new 89-alsa-ucm.rules udev file initializes the mixer settings for certain hardware. It's needed for making the hardware usable at boot, in case there's no higher level software (such as PulseAudio) managing the mixer settings. Shipping hardware specific configuration in alsa-utils seems wrong, but I don't know what else to do. I added it to the alsaucm package, because it's kind of tied to the alsaucm utility (the udev rules execute the alsaucm program, and the build system installs the rules file only when alsaucm is enabled). Ideally the UCM configuration in alsa-lib would define the default UCM verb for each hardware, then the udev rules file could just enable the default verb, and there would be no hardware specific configuration in alsa-utils. But that requires upstream development effort. Signed-off-by: Tanu Kaskinen --- ...ls-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} | 0 .../alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} | 10 +- 2 files changed, 5 insertions(+), 5 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.1.6.bb => alsa-utils-scripts_1.1.8.bb} (100%) rename meta/recipes-multimedia/alsa/{alsa-utils_1.1.6.bb => alsa-utils_1.1.8.bb} (92%) diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb similarity index 100% rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.1.8.bb diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb similarity index 92% rename from meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb index b8ba0cb22a..ab02169ac6 100644 --- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.8.bb @@ -22,8 +22,8 @@ PACKAGECONFIG[manpages] = "--enable-xmlto, --disable-xmlto, xmlto-native docbook SRC_URI = "ftp://ftp.alsa-project.org/pub/utils/alsa-utils-${PV}.tar.bz2 \ " -SRC_URI[md5sum] = "50ae75567459646b843bed78d916b002" -SRC_URI[sha256sum] = "155caecc40b2220f686f34ba3655a53e3bdbc0586adb1056733949feaaf7d36e" +SRC_URI[md5sum] = "54d6f9b483144823d0fc0c26e8cea028" +SRC_URI[sha256sum] = "fd9bf528922b3829a91913b89a1858c58a0b24271a7b5f529923aa9ea12fa4cf" # On build machines with python-docutils (not python3-docutils !!) installed # rst2man (not rst2man.py) is detected and compile fails with @@ -59,7 +59,7 @@ RDEPENDS_${PN} += "${ALSA_UTILS_PKGS}" FILES_${PN} = "" FILES_alsa-utils-alsabat = "${bindir}/alsabat" FILES_alsa-utils-alsatplg= "${bindir}/alsatplg" -FILES_alsa-utils-aplay = "${bindir}/aplay ${bindir}/arecord" +FILES_alsa-utils-aplay = "${bindir}/aplay ${bindir}/arecord ${bindir}/axfer" FILES_alsa-utils-amixer = "${bindir}/amixer" FILES_alsa-utils-alsamixer = "${bindir}/alsamixer" FILES_alsa-utils-speakertest = "${bindir}/speaker-test ${datadir}/sounds/alsa/ ${datadir}/alsa/speaker-test/" @@ -67,10 +67,10 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi ${bindir}/arecordmidi ${bind FILES_alsa-utils-aconnect= "${bindir}/aconnect" FILES_alsa-utils-aseqnet = "${bindir}/aseqnet" FILES_alsa-utils-iecset = "${bindir}/iecset" -FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d */*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/" +FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d/90-alsa-restore.rules */*/udev/rules.d/90-alsa-restore.rules ${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/" FILES_alsa-utils-aseqdump= "${bindir}/aseqdump" FILES_alsa-utils-alsaloop= "${bindir}/alsaloop" -FILES_alsa-utils-alsaucm = "${bindir}/alsaucm" +FILES_alsa-utils-alsaucm = "${bindir}/alsaucm */udev/rules.d/89-alsa-ucm.rules */*/udev/rules.d/89-alsa-ucm.rules" SUMMARY_alsa-utils-alsabat = "Command-line sound tester for ALSA sound card driver" SUMMARY_alsa-utils-alsatplg = "Converts topology text files into binary format for kernel" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/3] alsa-plugins: 1.1.6 -> 1.1.8
Changelogs: http://alsa-project.org/main/index.php/Changes_v1.1.6_v1.1.7 http://alsa-project.org/main/index.php/Changes_v1.1.7_v1.1.8 The --enable-avcodec configure option was renamed to --enable-libav, and I renamed the respective packageconfig item too. There's a new pcm plugin: aaf (AVTP Audio Format). I added a packageconfig item for it, but I didn't test it, because libavtp doesn't seem to be currently packaged for OpenEmbedded. There are now configuration files for most of the plugins. I removed the symlink creation for 50-pulseaudio.conf, because upstream now creates the symlinks for us. 99-pulseaudio-default.conf is an exception, because upstream ships it only as an example, and upstream doesn't install a symlink for it (upstream actually installs it directly under /etc, but I moved it back to /usr/share), so for that file we still have to create the symlink ourselves. The lavcrate plugin was converted to use libavresample (and renamed to lavrate). Libavresample is provided by ffmpeg, but ffmpeg was by default built with libavresample disabled. This patch now enables libavresample by default in the ffmpeg recipe in order to not cause a regression in alsa-plugins. Signed-off-by: Tanu Kaskinen --- ...plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} | 87 --- .../recipes-multimedia/ffmpeg/ffmpeg_4.1.1.bb | 2 +- 2 files changed, 74 insertions(+), 15 deletions(-) rename meta/recipes-multimedia/alsa/{alsa-plugins_1.1.6.bb => alsa-plugins_1.1.8.bb} (54%) diff --git a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb similarity index 54% rename from meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb rename to meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb index ee06191ea9..3da2634e94 100644 --- a/meta/recipes-multimedia/alsa/alsa-plugins_1.1.6.bb +++ b/meta/recipes-multimedia/alsa/alsa-plugins_1.1.8.bb @@ -21,8 +21,8 @@ LIC_FILES_CHKSUM = "\ " SRC_URI = "ftp://ftp.alsa-project.org/pub/plugins/${BP}.tar.bz2; -SRC_URI[md5sum] = "8387279e99feeb2ecffaac5f293223d7" -SRC_URI[sha256sum] = "6f1d31ebe3b1fa1cc8dade60b7bed1cb2583ac998167002d350dc0a5e3e40c13" +SRC_URI[md5sum] = "d0f87211d1560f2c07c8eae4297bc4f6" +SRC_URI[sha256sum] = "7f77df171685ccec918268477623a39db4d9f32d5dc5e76874ef2467a2405994" DEPENDS += "alsa-lib" @@ -33,8 +33,9 @@ PACKAGECONFIG ??= "\ speexdsp \ ${@bb.utils.filter('DISTRO_FEATURES', 'pulseaudio', d)} \ " -PACKAGECONFIG[avcodec] = "--enable-avcodec,--disable-avcodec,libav" +PACKAGECONFIG[aaf] = "--enable-aaf,--disable-aaf,avtp" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" +PACKAGECONFIG[libav] = "--enable-libav,--disable-libav,libav" PACKAGECONFIG[maemo-plugin] = "--enable-maemo-plugin,--disable-maemo-plugin" PACKAGECONFIG[maemo-resource-manager] = "--enable-maemo-resource-manager,--disable-maemo-resource-manager,dbus" PACKAGECONFIG[pulseaudio] = "--enable-pulseaudio,--disable-pulseaudio,pulseaudio" @@ -54,15 +55,11 @@ do_install_append() { rm ${D}${libdir}/alsa-lib/*.la if [ "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'yes', 'no', d)}" = "yes" ]; then - # We use the example as is, so just drop the .example suffix. - mv ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf - - # The conf.d files are installed in datadir, but alsa-lib - # searches for conf.d files only in sysconfdir. Distributions - # are expected to create symlinks in sysconfdir, so that's what - # we do here. - mkdir -p ${D}${sysconfdir}/alsa/conf.d - ln -s ${datadir}/alsa/alsa.conf.d/50-pulseaudio.conf ${D}${sysconfdir}/alsa/conf.d/50-pulseaudio.conf + # We use the example as is. Upstream installs the file under + # /etc, but we move it under /usr/share and add a symlink under + # /etc to be consistent with other installed configuration + # files. + mv ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf.example ${D}${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ln -s ${datadir}/alsa/alsa.conf.d/99-pulseaudio-default.conf ${D}${sysconfdir}/alsa/conf.d/99-pulseaudio-default.conf fi } @@ -73,6 +70,68 @@ python populate_packages_prepend() { d.setVar("RDEPENDS_alsa-plugins", packages) } +# Many plugins have a configuration file (plus a symlink in /etc) associated +# with them. We put the plugin and it's configuration usually in the same +# package, but that's problematic when the configuration file is related to +# multiple plugins, as is the case with the pulse, oss and maemo plugins. In +# case of the pulse plugins, we have a separate alsa-plugins-pulseaudio-conf +# package that depends on all the pulse plugins, which ensures that all plugins +# that the configuration
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Thursday 21 February 2019 at 13:01:27 +, Richard Purdie wrote: > On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote: > > On Wednesday 23 January 2019 at 16:27:59 +, Mike Crowe wrote: > > > > > > Does the lack of response mean that both approaches are horrendous? > > > If so, do you have any better ideas? > > > > There doesn't seem to be much interest in this one. > > > > The only other idea I've had is to create the symlink at rootfs-creation > > time. However, that seems to be detaching it too much from glibc, which > > would cause confusion. > > > > I can apply one of my fixes locally (we currently have some far uglier > > hacks than these that I'd like to remove), but I'd really rather not have > > to diverge from upstream this much. > > Sorry for the lack of feedback. > > I'm fairly strongly against a separate aarch64 only recipe for this. > Realistically we therefore have to fix this in the existing > class/code/recipe. > > The changes you sent previously didn't look that horrific, did you find > a working version of that? > > I'm wondering if we can come up with something which works and > hopefully we can spot some way to then clean it up to be a bit nicer... > > The delay was that I was going to try and come up with something but > that hasn't happened yet. If you have a horrific non-separate recipe > version that is complete, we can see if we can do anything to improve > it. I had suspected that was the reason for the delay. I shall knock my modifications to glibc-package.inc into shape and send a tested patch. I've already improved it a little compared to the version I sent previously. Thanks for the response. Mike. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] devtool: deploy-target: allow use of alternate ssh
Allow the use of an alternate SSH executable for deploy-target and undeploy-target. The command can be specified with -e / --ssh-exec. Signed-off-by: Olaf Mandel --- scripts/lib/devtool/deploy.py | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py index 886004b5d0..f345f31b7b 100644 --- a/scripts/lib/devtool/deploy.py +++ b/scripts/lib/devtool/deploy.py @@ -211,6 +211,11 @@ def deploy(args, config, basepath, workspace): if not args.show_status: extraoptions += ' -q' +scp_sshexec = '' +ssh_sshexec = 'ssh' +if args.ssh_exec: +scp_sshexec = "-S %s" % args.ssh_exec +ssh_sshexec = args.ssh_exec scp_port = '' ssh_port = '' if args.port: @@ -238,7 +243,7 @@ def deploy(args, config, basepath, workspace): for fpath, fsize in filelist: f.write('%s %d\n' % (fpath, fsize)) # Copy them to the target -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) if ret != 0: raise DevtoolError('Failed to copy script to %s - rerun with -s to ' 'get a complete error message' % args.target) @@ -246,7 +251,7 @@ def deploy(args, config, basepath, workspace): shutil.rmtree(tmpdir) # Now run the script -ret = exec_fakeroot(rd, 'tar cf - . | ssh %s %s %s \'sh %s %s %s %s\'' % (ssh_port, extraoptions, args.target, tmpscript, args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True) +ret = exec_fakeroot(rd, 'tar cf - . | %s %s %s %s \'sh %s %s %s %s\'' % (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript, args.recipename, destdir, tmpfilelist), cwd=recipe_outdir, shell=True) if ret != 0: raise DevtoolError('Deploy failed - rerun with -s to get a complete ' 'error message') @@ -276,6 +281,11 @@ def undeploy(args, config, basepath, workspace): if not args.show_status: extraoptions += ' -q' +scp_sshexec = '' +ssh_sshexec = 'ssh' +if args.ssh_exec: +scp_sshexec = "-S %s" % args.ssh_exec +ssh_sshexec = args.ssh_exec scp_port = '' ssh_port = '' if args.port: @@ -292,7 +302,7 @@ def undeploy(args, config, basepath, workspace): with open(os.path.join(tmpdir, os.path.basename(tmpscript)), 'w') as f: f.write(shellscript) # Copy it to the target -ret = subprocess.call("scp %s %s %s/* %s:%s" % (scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) +ret = subprocess.call("scp %s %s %s %s/* %s:%s" % (scp_sshexec, scp_port, extraoptions, tmpdir, args.target, os.path.dirname(tmpscript)), shell=True) if ret != 0: raise DevtoolError('Failed to copy script to %s - rerun with -s to ' 'get a complete error message' % args.target) @@ -300,7 +310,7 @@ def undeploy(args, config, basepath, workspace): shutil.rmtree(tmpdir) # Now run the script -ret = subprocess.call('ssh %s %s %s \'sh %s %s\'' % (ssh_port, extraoptions, args.target, tmpscript, args.recipename), shell=True) +ret = subprocess.call('%s %s %s %s \'sh %s %s\'' % (ssh_sshexec, ssh_port, extraoptions, args.target, tmpscript, args.recipename), shell=True) if ret != 0: raise DevtoolError('Undeploy failed - rerun with -s to get a complete ' 'error message') @@ -324,6 +334,7 @@ def register_commands(subparsers, context): parser_deploy.add_argument('-n', '--dry-run', help='List files to be deployed only', action='store_true') parser_deploy.add_argument('-p', '--no-preserve', help='Do not preserve existing files', action='store_true') parser_deploy.add_argument('--no-check-space', help='Do not check for available space before deploying', action='store_true') +parser_deploy.add_argument('-e', '--ssh-exec', help='Executable to use in place of ssh') parser_deploy.add_argument('-P', '--port', help='Specify port to use for connection to the target') strip_opts = parser_deploy.add_mutually_exclusive_group(required=False) @@ -346,5 +357,6 @@ def register_commands(subparsers, context): parser_undeploy.add_argument('-s', '--show-status', help='Show progress/status output', action='store_true') parser_undeploy.add_argument('-a', '--all', help='Undeploy all recipes deployed on the target', action='store_true') parser_undeploy.add_argument('-n', '--dry-run', help='List files to be undeployed only', action='store_true') +
Re: [OE-core] [PATCHv2] glibc: Separate out AArch64 multilib loader symlink creation
On Wed, 2019-02-20 at 16:47 +, Mike Crowe wrote: > On Wednesday 23 January 2019 at 16:27:59 +, Mike Crowe wrote: > > > > Does the lack of response mean that both approaches are horrendous? > > If so, do you have any better ideas? > > There doesn't seem to be much interest in this one. > > The only other idea I've had is to create the symlink at rootfs-creation > time. However, that seems to be detaching it too much from glibc, which > would cause confusion. > > I can apply one of my fixes locally (we currently have some far uglier > hacks than these that I'd like to remove), but I'd really rather not have > to diverge from upstream this much. Sorry for the lack of feedback. I'm fairly strongly against a separate aarch64 only recipe for this. Realistically we therefore have to fix this in the existing class/code/recipe. The changes you sent previously didn't look that horrific, did you find a working version of that? I'm wondering if we can come up with something which works and hopefully we can spot some way to then clean it up to be a bit nicer... The delay was that I was going to try and come up with something but that hasn't happened yet. If you have a horrific non-separate recipe version that is complete, we can see if we can do anything to improve it. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 08/14] netbase: upgrade 5.5 -> 5.6
Signed-off-by: Richard Purdie --- ...netbase-add-rpcbind-as-an-alias-to-sunrpc.patch | 14 ++ .../netbase/{netbase_5.5.bb => netbase_5.6.bb} | 4 ++-- 2 files changed, 8 insertions(+), 10 deletions(-) rename meta/recipes-core/netbase/{netbase_5.5.bb => netbase_5.6.bb} (83%) diff --git a/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch b/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch index 56c8d5b5c21..27ba2f68a26 100644 --- a/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch +++ b/meta/recipes-core/netbase/netbase/netbase-add-rpcbind-as-an-alias-to-sunrpc.patch @@ -1,4 +1,4 @@ -From 76989205a1411f16d7ab09ff9d279539a73dc259 Mon Sep 17 00:00:00 2001 +From 52d46c4d1fbd4c88d69c2fcf7837b2f2ba7ef6f2 Mon Sep 17 00:00:00 2001 From: "Maxin B. John" Date: Thu, 12 Jan 2017 16:50:58 +0200 Subject: [PATCH] netbase: add rpcbind as an alias to sunrpc @@ -10,6 +10,7 @@ Upstream-Status: Pending Signed-off-by: Li Wang Signed-off-by: Maxin B. John + --- etc-rpc | 2 +- etc-services | 4 ++-- @@ -29,12 +30,12 @@ index 1b30625..9a9a81a 100644 rusersd 12 rusers nfs 13 nfsprog diff --git a/etc-services b/etc-services -index e3202ec..a039d7e 100644 +index fa7ae24..10ba2bc 100644 --- a/etc-services +++ b/etc-services -@@ -64,8 +64,8 @@ csnet-ns 105/udp cso-ns - rtelnet 107/tcp # Remote Telnet - rtelnet 107/udp +@@ -51,8 +51,8 @@ kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5 + iso-tsap 102/tcp tsap# part of ISODE + acr-nema 104/tcp dicom # Digital Imag. & Comm. 300 pop3 110/tcp pop-3 # POP version 3 -sunrpc111/tcp portmapper # RPC 4.0 portmapper -sunrpc111/udp portmapper @@ -43,6 +44,3 @@ index e3202ec..a039d7e 100644 auth 113/tcp authentication tap ident sftp 115/tcp nntp 119/tcp readnews untp # USENET News Transfer Protocol --- -2.4.0 - diff --git a/meta/recipes-core/netbase/netbase_5.5.bb b/meta/recipes-core/netbase/netbase_5.6.bb similarity index 83% rename from meta/recipes-core/netbase/netbase_5.5.bb rename to meta/recipes-core/netbase/netbase_5.6.bb index eb53adda8d9..2aa49711cca 100644 --- a/meta/recipes-core/netbase/netbase_5.5.bb +++ b/meta/recipes-core/netbase/netbase_5.6.bb @@ -9,8 +9,8 @@ PE = "1" SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz \ file://netbase-add-rpcbind-as-an-alias-to-sunrpc.patch" -SRC_URI[md5sum] = "15f2d9b3783802f7f48f6734b6540ac4" -SRC_URI[sha256sum] = "309bddc69a43b98e5a450992b70cdfc0e3d1afb9107bc631d04b0714be98f88b" +SRC_URI[md5sum] = "7ad156272c5a42f49c73386ff39c8624" +SRC_URI[sha256sum] = "5d93a099deb28869b7306e914700fafbd293b55bdb5df05a5aa6effd0af5930c" UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/" do_install () { -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/14] readline: upgrade 7.0 -> 8.0
Signed-off-by: Richard Purdie --- .../{readline-7.0 => readline-8.0}/configure-fix.patch | 0 .../readline/{readline-7.0 => readline-8.0}/norpath.patch | 0 meta/recipes-core/readline/readline_7.0.bb | 7 --- meta/recipes-core/readline/readline_8.0.bb | 7 +++ 4 files changed, 7 insertions(+), 7 deletions(-) rename meta/recipes-core/readline/{readline-7.0 => readline-8.0}/configure-fix.patch (100%) rename meta/recipes-core/readline/{readline-7.0 => readline-8.0}/norpath.patch (100%) delete mode 100644 meta/recipes-core/readline/readline_7.0.bb create mode 100644 meta/recipes-core/readline/readline_8.0.bb diff --git a/meta/recipes-core/readline/readline-7.0/configure-fix.patch b/meta/recipes-core/readline/readline-8.0/configure-fix.patch similarity index 100% rename from meta/recipes-core/readline/readline-7.0/configure-fix.patch rename to meta/recipes-core/readline/readline-8.0/configure-fix.patch diff --git a/meta/recipes-core/readline/readline-7.0/norpath.patch b/meta/recipes-core/readline/readline-8.0/norpath.patch similarity index 100% rename from meta/recipes-core/readline/readline-7.0/norpath.patch rename to meta/recipes-core/readline/readline-8.0/norpath.patch diff --git a/meta/recipes-core/readline/readline_7.0.bb b/meta/recipes-core/readline/readline_7.0.bb deleted file mode 100644 index 85dfaa62948..000 --- a/meta/recipes-core/readline/readline_7.0.bb +++ /dev/null @@ -1,7 +0,0 @@ -require readline.inc - -SRC_URI += "file://configure-fix.patch \ -file://norpath.patch" - -SRC_URI[archive.md5sum] = "205b03a87fc83dab653b628c59b9fc91" -SRC_URI[archive.sha256sum] = "750d437185286f40a369e1e4f4764eda932b9459b5ec9a731628393dd3d32334" diff --git a/meta/recipes-core/readline/readline_8.0.bb b/meta/recipes-core/readline/readline_8.0.bb new file mode 100644 index 000..99d022a32f6 --- /dev/null +++ b/meta/recipes-core/readline/readline_8.0.bb @@ -0,0 +1,7 @@ +require readline.inc + +SRC_URI += "file://configure-fix.patch \ +file://norpath.patch" + +SRC_URI[archive.md5sum] = "7e6c1f16aee3244a69aba6e438295ca3" +SRC_URI[archive.sha256sum] = "e339f51971478d369f8a053a330a190781acb9864cf4c541060f12078948e461" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/14] libxau: upgrade 1.0.8 -> 1.0.9
Signed-off-by: Richard Purdie --- .../xorg-lib/{libxau_1.0.8.bb => libxau_1.0.9.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/xorg-lib/{libxau_1.0.8.bb => libxau_1.0.9.bb} (76%) diff --git a/meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb b/meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb similarity index 76% rename from meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb rename to meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb index 8c52475b855..dcfc66652a8 100644 --- a/meta/recipes-graphics/xorg-lib/libxau_1.0.8.bb +++ b/meta/recipes-graphics/xorg-lib/libxau_1.0.9.bb @@ -20,5 +20,5 @@ XORG_PN = "libXau" BBCLASSEXTEND = "native nativesdk" -SRC_URI[md5sum] = "685f8abbffa6d145c0f930f00703b21b" -SRC_URI[sha256sum] = "fdd477320aeb5cdd67272838722d6b7d544887dfe7de46e1e7cc0c27c2bea4f2" +SRC_URI[md5sum] = "c5f16288f2da9f071b29111d68797480" +SRC_URI[sha256sum] = "ccf8cbf0dbf676faa2ea0a6d64bcc3b6746064722b606c8c52917ed00dcb73ec" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/14] less: upgrade 530 -> 549
The license checksum changed due to a change in copyright years. Signed-off-by: Richard Purdie --- meta/recipes-extended/less/{less_530.bb => less_549.bb} | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) rename meta/recipes-extended/less/{less_530.bb => less_549.bb} (82%) diff --git a/meta/recipes-extended/less/less_530.bb b/meta/recipes-extended/less/less_549.bb similarity index 82% rename from meta/recipes-extended/less/less_530.bb rename to meta/recipes-extended/less/less_549.bb index c07b1217449..140c89fcb0b 100644 --- a/meta/recipes-extended/less/less_530.bb +++ b/meta/recipes-extended/less/less_549.bb @@ -21,14 +21,15 @@ SECTION = "console/utils" LICENSE = "GPLv3+ | BSD-2-Clause" LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \ -file://LICENSE;md5=2ef3e4b8dafc85612bc5254b8081e234" +file://LICENSE;md5=ba01d0cab7f62f7f2204c7780ff6a87d \ +" DEPENDS = "ncurses" SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \ " -SRC_URI[md5sum] = "6a39bccf420c946b0fd7ffc64961315b" -SRC_URI[sha256sum] = "503f91ab0af4846f34f0444ab71c4b286123f0044a4964f1ae781486c617f2e2" +SRC_URI[md5sum] = "d12863d348077739a4d3bc67ad9b7f00" +SRC_URI[sha256sum] = "eec42357903faabfb294ffcc41ff08cbb29db54db46568cd8d0ed15a0482e19d" UPSTREAM_CHECK_URI = "http://www.greenwoodsoftware.com/less/download.html; -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 04/14] gst-examples: upgrade to latest revision
Signed-off-by: Richard Purdie --- meta/recipes-multimedia/gstreamer/gst-examples_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb index 1d87f24fe59..f8cef857b32 100644 --- a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb +++ b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb @@ -8,7 +8,7 @@ SRC_URI = "git://anongit.freedesktop.org/gstreamer/gst-examples \ file://0001-Make-player-examples-installable.patch \ file://gst-player.desktop" -SRCREV = "48247c6ab6807d6ae179cf653cbdc64714d3313c" +SRCREV = "2b3fc175c252cd5a537e4b2864b572a8372473d6" PV = "0.0.1+git${SRCPV}" UPSTREAM_CHECK_COMMITS = "1" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 06/14] libassuan: upgrade 2.5.2 -> 2.5.3
Signed-off-by: Richard Purdie --- .../libassuan/{libassuan_2.5.2.bb => libassuan_2.5.3.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/libassuan/{libassuan_2.5.2.bb => libassuan_2.5.3.bb} (88%) diff --git a/meta/recipes-support/libassuan/libassuan_2.5.2.bb b/meta/recipes-support/libassuan/libassuan_2.5.3.bb similarity index 88% rename from meta/recipes-support/libassuan/libassuan_2.5.2.bb rename to meta/recipes-support/libassuan/libassuan_2.5.3.bb index 515d60f7f65..6fb3d2f3a47 100644 --- a/meta/recipes-support/libassuan/libassuan_2.5.2.bb +++ b/meta/recipes-support/libassuan/libassuan_2.5.3.bb @@ -17,8 +17,8 @@ SRC_URI = "${GNUPG_MIRROR}/libassuan/libassuan-${PV}.tar.bz2 \ file://libassuan-add-pkgconfig-support.patch \ " -SRC_URI[md5sum] = "4d0d5738936bd8f4f0287e1dd80432b6" -SRC_URI[sha256sum] = "986b1bf277e375f7a960450fbb8ffbd45294d06598916ad4ebf79aee0cb788e7" +SRC_URI[md5sum] = "226c504ea78a232224bf3b6846b3adb9" +SRC_URI[sha256sum] = "91bcb0403866b4e7c4bc1cc52ed4c364a9b5414b3994f718c70303f7f765e702" BINCONFIG = "${bindir}/libassuan-config" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 13/14] xkeyboard-config: upgrade 2.25 -> 2.26
Signed-off-by: Richard Purdie --- .../{xkeyboard-config_2.25.bb => xkeyboard-config_2.26.bb}| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/xorg-lib/{xkeyboard-config_2.25.bb => xkeyboard-config_2.26.bb} (87%) diff --git a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb similarity index 87% rename from meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb rename to meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb index b67dfa566ba..5c232884561 100644 --- a/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.25.bb +++ b/meta/recipes-graphics/xorg-lib/xkeyboard-config_2.26.bb @@ -14,8 +14,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=0e7f21ca7db975c63467d2e7624a12f9" SRC_URI = "${XORG_MIRROR}/individual/data/xkeyboard-config/${BPN}-${PV}.tar.bz2" -SRC_URI[md5sum] = "a0238f95118f39f5f685dd28fbd9d24f" -SRC_URI[sha256sum] = "fec6c25a8d3931bd9afca49a1653b0fa222c85610502d7b77699bb61262934b2" +SRC_URI[md5sum] = "e2e980629bfeb9f40a7d44488b18ba12" +SRC_URI[sha256sum] = "393718c7460cd06c4e8cb819d943ca54812ea476f32714c4d8975c77031a038e" SECTION = "x11/libs" DEPENDS = "intltool-native util-macros libxslt-native" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 14/14] gnu-config: upgrade to 20181128 revision
Signed-off-by: Richard Purdie --- meta/recipes-devtools/gnu-config/gnu-config_git.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/gnu-config/gnu-config_git.bb b/meta/recipes-devtools/gnu-config/gnu-config_git.bb index 4745f19ceee..e597ebedbc1 100644 --- a/meta/recipes-devtools/gnu-config/gnu-config_git.bb +++ b/meta/recipes-devtools/gnu-config/gnu-config_git.bb @@ -8,8 +8,8 @@ DEPENDS_class-native = "hostperl-runtime-native" INHIBIT_DEFAULT_DEPS = "1" -SRCREV = "30d53fc428ea42af9d6f4d355db0022e3918a824" -PV = "20180713+git${SRCPV}" +SRCREV = "058639be227bbe8f03cc39f79f7ce84918012143" +PV = "20181128+git${SRCPV}" SRC_URI = "git://git.savannah.gnu.org/config.git \ file://gnu-configize.in" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 11/14] sbc: upgrade 1.3 -> 1.4
Signed-off-by: Richard Purdie --- meta/recipes-multimedia/sbc/{sbc_1.3.bb => sbc_1.4.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-multimedia/sbc/{sbc_1.3.bb => sbc_1.4.bb} (84%) diff --git a/meta/recipes-multimedia/sbc/sbc_1.3.bb b/meta/recipes-multimedia/sbc/sbc_1.4.bb similarity index 84% rename from meta/recipes-multimedia/sbc/sbc_1.3.bb rename to meta/recipes-multimedia/sbc/sbc_1.4.bb index 2bb895de980..674d77ef485 100644 --- a/meta/recipes-multimedia/sbc/sbc_1.3.bb +++ b/meta/recipes-multimedia/sbc/sbc_1.4.bb @@ -14,8 +14,8 @@ DEPENDS = "libsndfile1" SRC_URI = "${KERNELORG_MIRROR}/linux/bluetooth/${BP}.tar.xz" -SRC_URI[md5sum] = "2d8b7841f2c11ab287718d562f2b981c" -SRC_URI[sha256sum] = "e61022cf576f14190241e7071753fdacdce5d1dea89ffd704110fc50be689309" +SRC_URI[md5sum] = "800fb0908899baa48dc216d8e156cc05" +SRC_URI[sha256sum] = "518bf46e6bb3dc808a95e1eabad26fdebe8a099c1e781c27ed7fca6c2f4a54c9" inherit autotools pkgconfig -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 12/14] xf86-input-libinput: upgrade 0.28.1 -> 0.28.2
Signed-off-by: Richard Purdie --- ...input-libinput_0.28.1.bb => xf86-input-libinput_0.28.2.bb} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/xorg-driver/{xf86-input-libinput_0.28.1.bb => xf86-input-libinput_0.28.2.bb} (63%) diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb similarity index 63% rename from meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb rename to meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb index 0b77546d6f9..19123e06c91 100644 --- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.1.bb +++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.28.2.bb @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0" DEPENDS += "libinput" -SRC_URI[md5sum] = "9d2fb3d6b452d568a275908b856de0e2" -SRC_URI[sha256sum] = "9ada448e076c0078a84b48e5298fa8ce317565f9b342b74c20429214a707d98b" +SRC_URI[md5sum] = "b7548bc1d7e82d189205794ff86307af" +SRC_URI[sha256sum] = "b8b346962c6b62b8069928c29c0db83b6f544863bf2fc6830f324de841de2820" FILES_${PN} += "${datadir}/X11/xorg.conf.d" -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/14] pkgconf: upgrade 1.5.3 -> 1.6.0
Signed-off-by: Richard Purdie --- .../pkgconf/{pkgconf_1.5.3.bb => pkgconf_1.6.0.bb}| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/pkgconf/{pkgconf_1.5.3.bb => pkgconf_1.6.0.bb} (95%) diff --git a/meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb b/meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb similarity index 95% rename from meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb rename to meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb index 415478d5cf9..1452875f5d8 100644 --- a/meta/recipes-devtools/pkgconf/pkgconf_1.5.3.bb +++ b/meta/recipes-devtools/pkgconf/pkgconf_1.6.0.bb @@ -21,8 +21,8 @@ SRC_URI = "\ file://pkg-config-native.in \ file://pkg-config-esdk.in \ " -SRC_URI[md5sum] = "c21743bca14c882c0f282746168a5edc" -SRC_URI[sha256sum] = "d3468308553c94389dadfd10c4d1067269052b5364276a9d24a643c88485f715" +SRC_URI[md5sum] = "0c93492d7f001e5175b0347b5472e86d" +SRC_URI[sha256sum] = "6135a3abb576672ba54a899860442ba185063f0f90dae5892f64f7bae8e1ece5" inherit autotools -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/14] gnupg: upgrade 2.2.12 -> 2.2.13
Signed-off-by: Richard Purdie --- ...configure.ac-use-a-custom-value-for-the-location-of-.patch | 2 +- meta/recipes-support/gnupg/gnupg/relocate.patch | 2 +- .../gnupg/{gnupg_2.2.12.bb => gnupg_2.2.13.bb}| 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) rename meta/recipes-support/gnupg/{gnupg_2.2.12.bb => gnupg_2.2.13.bb} (93%) diff --git a/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch b/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch index c43ecdf8616..2c204e02452 100644 --- a/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch +++ b/meta/recipes-support/gnupg/gnupg/0001-configure.ac-use-a-custom-value-for-the-location-of-.patch @@ -1,4 +1,4 @@ -From c69c3a49f3295179c247db5ceb3ef8952928a724 Mon Sep 17 00:00:00 2001 +From e7ad11cf54475e455fdb84d118e4782961698567 Mon Sep 17 00:00:00 2001 From: Alexander Kanavin Date: Mon, 22 Jan 2018 18:00:21 +0200 Subject: [PATCH] configure.ac: use a custom value for the location of diff --git a/meta/recipes-support/gnupg/gnupg/relocate.patch b/meta/recipes-support/gnupg/gnupg/relocate.patch index 1a5ea4aa2b7..e5a82aa76d5 100644 --- a/meta/recipes-support/gnupg/gnupg/relocate.patch +++ b/meta/recipes-support/gnupg/gnupg/relocate.patch @@ -1,4 +1,4 @@ -From 6d31b04d7a75f1d73c3518bf043b5b0a2dc40cb1 Mon Sep 17 00:00:00 2001 +From 59c077f32e81190955910cae02599c7a3edfa7fb Mon Sep 17 00:00:00 2001 From: Ross Burton Date: Wed, 19 Sep 2018 14:44:40 +0100 Subject: [PATCH] Allow the environment to override where gnupg looks for its diff --git a/meta/recipes-support/gnupg/gnupg_2.2.12.bb b/meta/recipes-support/gnupg/gnupg_2.2.13.bb similarity index 93% rename from meta/recipes-support/gnupg/gnupg_2.2.12.bb rename to meta/recipes-support/gnupg/gnupg_2.2.13.bb index a02c66a0c87..3ce2a38c0eb 100644 --- a/meta/recipes-support/gnupg/gnupg_2.2.12.bb +++ b/meta/recipes-support/gnupg/gnupg_2.2.13.bb @@ -20,8 +20,8 @@ SRC_URI_append_class-native = " file://0001-configure.ac-use-a-custom-value-for- file://relocate.patch" -SRC_URI[md5sum] = "421b17028878b253c5acfef056bc6141" -SRC_URI[sha256sum] = "db030f8b4c98640e91300d36d516f1f4f8fe09514a94ea9fc7411ee1a34082cb" +SRC_URI[md5sum] = "563b959d0c3856e34526e9ca51c80d7b" +SRC_URI[sha256sum] = "76c787a955f9e6e0ead47c9be700bfb9d454f955a7b7c7e697aa719bac7b11d8" EXTRA_OECONF = "--disable-ldap \ --disable-ccid-driver \ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/14] curl: upgrade 7.63.0 -> 7.64.0
The license checksum changed as the copyright years changed. Fixes: - CVE-2018-16890: NTLM type-2 out-of-bounds buffer read - CVE-2019-3822: NTLMv2 type-3 header stack buffer overflow - CVE-2019-3823: SMTP end-of-response out-of-bounds read Signed-off-by: Richard Purdie --- .../recipes-support/curl/{curl_7.63.0.bb => curl_7.64.0.bb} | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) rename meta/recipes-support/curl/{curl_7.63.0.bb => curl_7.64.0.bb} (93%) diff --git a/meta/recipes-support/curl/curl_7.63.0.bb b/meta/recipes-support/curl/curl_7.64.0.bb similarity index 93% rename from meta/recipes-support/curl/curl_7.63.0.bb rename to meta/recipes-support/curl/curl_7.64.0.bb index f7557a2f46d..a1b5e7d5797 100644 --- a/meta/recipes-support/curl/curl_7.63.0.bb +++ b/meta/recipes-support/curl/curl_7.64.0.bb @@ -3,14 +3,14 @@ HOMEPAGE = "http://curl.haxx.se/; BUGTRACKER = "http://curl.haxx.se/mail/list.cgi?list=curl-tracker; SECTION = "console/network" LICENSE = "MIT" -LIC_FILES_CHKSUM = "file://COPYING;md5=ef889a37a5a874490ac7ce116396f29a" +LIC_FILES_CHKSUM = "file://COPYING;md5=be5d9e1419c4363f4b32037a2d3b7ffa" SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \ file://0001-replace-krb5-config-with-pkg-config.patch \ " -SRC_URI[md5sum] = "0a6c1e993bd5102bc52fc89900542644" -SRC_URI[sha256sum] = "9bab7ed4ecff77020a312d84cc5fb7eb02d58419d218f267477a724a17fd8dd8" +SRC_URI[md5sum] = "d0bcc586873cfef08b4b9594e5395a33" +SRC_URI[sha256sum] = "d573ba1c2d1cf9d8533fadcce480d778417964e8d04ccddcc76e591d544cf2eb" CVE_PRODUCT = "curl libcurl" inherit autotools pkgconfig binconfig multilib_header -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/14] blktool: upgrade 4-7 -> 4-7.1
Signed-off-by: Richard Purdie --- .../blktool/{blktool_4-7.bb => blktool_4-7.1.bb}| 2 ++ 1 file changed, 2 insertions(+) rename meta/recipes-extended/blktool/{blktool_4-7.bb => blktool_4-7.1.bb} (90%) diff --git a/meta/recipes-extended/blktool/blktool_4-7.bb b/meta/recipes-extended/blktool/blktool_4-7.1.bb similarity index 90% rename from meta/recipes-extended/blktool/blktool_4-7.bb rename to meta/recipes-extended/blktool/blktool_4-7.1.bb index 0e6f7ee6df1..468925e329b 100644 --- a/meta/recipes-extended/blktool/blktool_4-7.bb +++ b/meta/recipes-extended/blktool/blktool_4-7.1.bb @@ -9,6 +9,8 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ DEPENDS = "glib-2.0" +SRC_URI[sha256sum] = "b1e6d5912546d2a4b704ec65c2b9664aa3b4663e7d800e06803330335a2cb764" +SRC_URI[md5sum] = "62edc09c9908107e69391c87f4f3fd40" SRC_URI = "http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/b/${BPN}/${BPN}_4.orig.tar.gz;name=tarball \ file://0001-fix-typos-in-manpage.patch \ file://0002-fix-string-error.patch \ -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
On Thu, 21 Feb 2019 at 10:17, Mike Looijmans wrote: > That'd be best. One would expect that creating a filesystem "offline" would > yield something optimal in terms of the way files are allocated, since > everything about all files is already known when it's written. But because we don't run image generation as root in a loopback mount, we're limited to how clever e2fsprogs's debugfs is, *not* the kernel driver. Just a few weeks ago I fixed a bug in debugfs where it was only writing the first 2^31 bits of a file... Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
On 19-02-19 21:45, Leon Woestenberg wrote: > Hello all, > > On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy wrote: >> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg wrote: >>> >>> Hello Mike, >>> >>> sounds familiar. >>> >>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans >>> wrote: Took me a while to figure out why my board took 90 seconds to boot suddenly. The issue turned out to be the ext4 partition created by wic. >>> >>> I suspect it's not WIC's fault. ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin 19311092 bytes read in 85529 ms (219.7 KiB/s) Now if I boot the board rename and copy that file onto itself, then it's suddenly normal again when I reboot the board: ZynqMP> load mmc 0:2 0x1 I'm not knowledgeable on ext4, so any ideas what's being passed onto the image creation tool that causes this? >>> >>> I suspect your version of U-Boot does not handle files spread across >>> multiple filesystems (allocation) extends efficiently. >>> >>> Copying the file makes the copy being layed out in one extend probably. >> >> >> If WIC is generating filesystem images from scratch there's no excuse for >> files to be unnecessarily fragmented. >> >> Even if some of all of the boot time can be recovered by a patch to u-boot >> that won't help systems which have already been deployed and don't have a >> way to update the bootloader. >> > I am not sure if "fragmented" is the right term in terms of filesystem > details. Filesystem allocation extents (not "extends" as I mistyped > earlier) are different from heavy file fragmentation. However, I agree > things can be made more optimal. > > So, with adding the above, there are *two* issues at play here: > 1) Most/older versions of U-Boot not able to efficiently load files > from ext4 filesystems, that cross multiple extents. I am aware of two > fixes, see below. > 2) WIC uses mkext4fs in such a way that files can cross multiple > (allocation) extents. This is sub-optimal and know to cause issues > with many U-Boot versions (deployed on existing systems in the field). > The problems shows "randomly" with large files being deployed to the > ext4 filesystem. We (OE/Yocto) may want to fix this. That'd be best. One would expect that creating a filesystem "offline" would yield something optimal in terms of the way files are allocated, since everything about all files is already known when it's written. My current workaround is to just mount the device and unpack the rootfs tar onto that, which yields a filesystem that u-boot can read at normal speed. >>> I am aware of two fixes for U-Boot. I will look them up, and reply again to >>> this thread. > > Google for these two commits. I cherry-picked the first one for my > project and can confirm it brings back the desired performance. (Still > assuming this is the identical cause as for TO/Mike.) > > commit 855b8e4f9f255415a7753819e392e4b5d984f35c > Author: Matt Madison > Date: Sat Aug 19 08:46:46 2017 -0700 > > ext4: cache extent blocks during file reads > > A simpler and less-efficient approach to solving > the problem with extent index blocks than what > was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5, > but one that does not break write operations. > > Signed-off-by: Matt Madison I'll give it a try... You mentioned "two" commits? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud][PATCH] ghostscript: Fix CVE-2019-6116
It was discovered that the ghostscript /invalidaccess checks fail under certain conditions. An attacker could possibly exploit this to bypass the -dSAFER protection and, for example, execute arbitrary shell commands via a specially crafted PostScript document. Reference: https://www.openwall.com/lists/oss-security/2019/01/23/5 Upstream patches: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=13b0a36f8181db66a91bcc8cea139998b53a8996 http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2db98f9c66135601efb103d8db7d020a672308db http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=99f13091a3f309bdc95d275ea9fec10bb9f42d9a http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=59d8f4deef90c1598ff50616519d5576756b4495 http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2768d1a6dddb83f5c061207a7ed2813999c1b5c9 http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=49c8092da88ef6bb0aa281fe294ae0925a44b5b9 http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=2ff600a3c4fc169e7c6c1e83874a6bf63a6fb42b Signed-off-by: Ovidiu Panait --- .../ghostscript/CVE-2019-6116-0001.patch | 177 ++ .../ghostscript/CVE-2019-6116-0002.patch | 442 + .../ghostscript/CVE-2019-6116-0003.patch | 32 + .../ghostscript/CVE-2019-6116-0004.patch | 136 .../ghostscript/CVE-2019-6116-0005.patch | 250 .../ghostscript/CVE-2019-6116-0006.patch | 596 ++ .../ghostscript/CVE-2019-6116-0007.patch | 346 ++ .../ghostscript/ghostscript_9.26.bb | 7 + 8 files changed, 1986 insertions(+) create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0002.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0003.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0004.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0005.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0006.patch create mode 100644 meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0007.patch diff --git a/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch new file mode 100644 index 00..b2c1ade4be --- /dev/null +++ b/meta/recipes-extended/ghostscript/ghostscript/CVE-2019-6116-0001.patch @@ -0,0 +1,177 @@ +From c8c77690199b677f70093824382f0881e643e17b Mon Sep 17 00:00:00 2001 +From: Chris Liddell +Date: Wed, 5 Dec 2018 12:22:13 + +Subject: [PATCH 1/7] Sanitize op stack for error conditions + +We save the stacks to an array and store the array for the error handler to +access. + +For SAFER, we traverse the array, and deep copy any op arrays (procedures). As +we make these copies, we check for operators that do *not* exist in systemdict, +when we find one, we replace the operator with a name object (of the form +"/--opname--"). + +CVE: CVE-2019-6116 +Upstream-Status: Backport [git://git.ghostscript.com/ghostpdl.git] + +Signed-off-by: Ovidiu Panait +--- + psi/int.mak | 3 +- + psi/interp.c | 8 ++ + psi/istack.c | 78 + psi/istack.h | 3 ++ + 4 files changed, 91 insertions(+), 1 deletion(-) + +diff --git a/psi/int.mak b/psi/int.mak +index 6ab5bf0..6b349cb 100644 +--- a/psi/int.mak b/psi/int.mak +@@ -204,7 +204,8 @@ $(PSOBJ)iparam.$(OBJ) : $(PSSRC)iparam.c $(GH)\ + $(PSOBJ)istack.$(OBJ) : $(PSSRC)istack.c $(GH) $(memory__h)\ + $(ierrors_h) $(gsstruct_h) $(gsutil_h)\ + $(ialloc_h) $(istack_h) $(istkparm_h) $(istruct_h) $(iutil_h) $(ivmspace_h)\ +- $(store_h) $(INT_MAK) $(MAKEDIRS) ++ $(store_h) $(icstate_h) $(iname_h) $(dstack_h) $(idict_h) \ ++ $(INT_MAK) $(MAKEDIRS) + $(PSCC) $(PSO_)istack.$(OBJ) $(C_) $(PSSRC)istack.c + + $(PSOBJ)iutil.$(OBJ) : $(PSSRC)iutil.c $(GH) $(math__h) $(memory__h) $(string__h)\ +diff --git a/psi/interp.c b/psi/interp.c +index 6dc0dda..aa5779c 100644 +--- a/psi/interp.c b/psi/interp.c +@@ -761,6 +761,7 @@ copy_stack(i_ctx_t *i_ctx_p, const ref_stack_t * pstack, int skip, ref * arr) + uint size = ref_stack_count(pstack) - skip; + uint save_space = ialloc_space(idmemory); + int code, i; ++ref *safety, *safe; + + if (size > 65535) + size = 65535; +@@ -778,6 +779,13 @@ copy_stack(i_ctx_t *i_ctx_p, const ref_stack_t * pstack, int skip, ref * arr) + make_null(>value.refs[i]); + } + } ++if (pstack == _stack && dict_find_string(systemdict, "SAFETY", ) > 0 && ++dict_find_string(safety, "safe", ) > 0 && r_has_type(safe, t_boolean) && ++safe->value.boolval == true) { ++code = ref_stack_array_sanitize(i_ctx_p, arr, arr); ++if (code < 0) ++return code; ++} +
Re: [OE-core] wic creates ext4 images that read really slow in u-boot
>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to >>> this thread. Browsing through u-boot commits, I found this gem that's disabled by default: CONFIG_BLOCK_CACHE=y The commit is this one: commit e40cf34a29f1b248643731a11fb1c6f0520d016c Author: Eric Nelson Date: Mon Mar 28 10:05:44 2016 -0700 drivers: block: add block device cache Add a block device cache to speed up repeated reads of block devices by various filesystems. This small amount of cache can dramatically speed up filesystem operations by skipping repeated reads of common areas of a block device (typically directory structures). This has shown to have some benefit on FAT filesystem operations of loading a kernel and RAM disk, but more dramatic benefits on ext4 filesystems when the kernel and/or RAM disk are spread across multiple extent header structures as described in commit fc0fc50. ... I'll be giving that a test drive soon... -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] kernel-fitimage.bbclass: Introduce a way to provide external dtb
On Thu, 2019-02-21 at 03:53 +, Manjukumar Harthikote Matha wrote: > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > > On Tue, 2019-02-19 at 19:34 +, Manjukumar Harthikote Matha > > > > > > PREFERRED_PROVIDER_virtual/dtb = "devicetree" > > > > > > > > > > Yes, I should have added this in the commit message. I will > > > update it > > > and re-send V2 > > > > What may also help a lot here would be some tests. This is > > currently a blackhole in > > the tests :( > > > Are there examples of having tests only for bbclass in OE-Core? There are. See meta/lib/oeqa/selftest/cases/wic.py I appreciate wic is a tool, not a class but the examples there should help. You can trigger them with oe-selftest -r wic. Another example which is a bbclass is selftest/cases/archiver.py which does use a class inherit. > We need a recipe or create-one to inherit this class and probably add > that as a testcase. > I am not sure how to proceed, any example would help to implement the > same See above, they show how to add small config fragments. If you do need a full recipe, then the meta-selftest layer of OE-Core should be able to help too. If you have any other questions or run into issues please do ask! Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lighttpd: Use the upstream lighttpd.service
We shipped an old version that was missing several fixes. A minor incompatibility is that this moves /etc/lighttpd.conf -> /etc/lighttpd/lighttpd.conf Signed-off-by: Adrian Bunk --- meta/recipes-extended/lighttpd/lighttpd/lighttpd | 2 +- meta/recipes-extended/lighttpd/lighttpd/lighttpd.service | 12 meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb| 9 - 3 files changed, 5 insertions(+), 18 deletions(-) delete mode 100644 meta/recipes-extended/lighttpd/lighttpd/lighttpd.service diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd b/meta/recipes-extended/lighttpd/lighttpd/lighttpd index bf89a60b7d..82fbaa523b 100644 --- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd +++ b/meta/recipes-extended/lighttpd/lighttpd/lighttpd @@ -4,7 +4,7 @@ PATH=/sbin:/bin:/usr/sbin:/usr/bin DAEMON=/usr/sbin/lighttpd NAME=lighttpd DESC="Lighttpd Web Server" -OPTS="-f /etc/lighttpd.conf" +OPTS="-f /etc/lighttpd/lighttpd.conf" case "$1" in start) diff --git a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service b/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service deleted file mode 100644 index 66a907aa17..00 --- a/meta/recipes-extended/lighttpd/lighttpd/lighttpd.service +++ /dev/null @@ -1,12 +0,0 @@ -[Unit] -Description=Lightning Fast Webserver With Light System Requirements -After=network.target - -[Service] -ExecStartPre=@SBINDIR@/lighttpd -t -f @SYSCONFDIR@/lighttpd.conf -ExecStart=@SBINDIR@/lighttpd -D -f @SYSCONFDIR@/lighttpd.conf -ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID - -[Install] -WantedBy=multi-user.target - diff --git a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb index a58faa17be..a0b350f358 100644 --- a/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb +++ b/meta/recipes-extended/lighttpd/lighttpd_1.4.53.bb @@ -16,7 +16,6 @@ SRC_URI = "http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-${PV}.t file://index.html.lighttpd \ file://lighttpd.conf \ file://lighttpd \ -file://lighttpd.service \ file://0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch \ " @@ -57,13 +56,13 @@ INITSCRIPT_PARAMS = "defaults 70" SYSTEMD_SERVICE_${PN} = "lighttpd.service" do_install_append() { - install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd.d ${D}/www/pages/dav + install -d ${D}${sysconfdir}/init.d ${D}${sysconfdir}/lighttpd ${D}${sysconfdir}/lighttpd.d ${D}/www/pages/dav install -m 0755 ${WORKDIR}/lighttpd ${D}${sysconfdir}/init.d - install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir} + install -m 0644 ${WORKDIR}/lighttpd.conf ${D}${sysconfdir}/lighttpd install -m 0644 ${WORKDIR}/index.html.lighttpd ${D}/www/pages/index.html install -d ${D}${systemd_unitdir}/system - install -m 0644 ${WORKDIR}/lighttpd.service ${D}${systemd_unitdir}/system + install -m 0644 ${S}/doc/systemd/lighttpd.service ${D}${systemd_unitdir}/system sed -i -e 's,@SBINDIR@,${sbindir},g' \ -e 's,@SYSCONFDIR@,${sysconfdir},g' \ -e 's,@BASE_BINDIR@,${base_bindir},g' \ @@ -75,7 +74,7 @@ do_install_append() { FILES_${PN} += "${sysconfdir} /www" -CONFFILES_${PN} = "${sysconfdir}/lighttpd.conf" +CONFFILES_${PN} = "${sysconfdir}/lighttpd/lighttpd.conf" PACKAGES_DYNAMIC += "^lighttpd-module-.*" -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: enable CONFIG_FLOAT_DURATION
The 1.29.3 -> 1.30.1 upgrade lost support for sleep with float values (e.g. "sleep 0.1") since this replacement for CONFIG_FEATURE_FLOAT_SLEEP (enabled in thud) was missing. Signed-off-by: Adrian Bunk --- meta/recipes-core/busybox/busybox/defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-core/busybox/busybox/defconfig b/meta/recipes-core/busybox/busybox/defconfig index a209eea5a1..493db28e86 100644 --- a/meta/recipes-core/busybox/busybox/defconfig +++ b/meta/recipes-core/busybox/busybox/defconfig @@ -83,7 +83,7 @@ CONFIG_NO_DEBUG_LIB=y # Library Tuning # # CONFIG_FEATURE_USE_BSS_TAIL is not set -# CONFIG_FLOAT_DURATION is not set +CONFIG_FLOAT_DURATION=y CONFIG_FEATURE_RTMINMAX=y # CONFIG_FEATURE_RTMINMAX_USE_LIBC_DEFINITIONS is not set CONFIG_FEATURE_BUFFERS_USE_MALLOC=y -- 2.11.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core