Re: [OE-core] Truly scary SSL 3.0 vuln to be revealed soon:
Ross, > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Burton, Ross > Sent: Wednesday, October 15, 2014 6:07 AM > To: Sona Sarmadi > Cc: yo...@yoctoproject.org; openembedded- > c...@lists.openembedded.org > Subject: Re: [OE-core] Truly scary SSL 3.0 vuln to be revealed soon: > > On 15 October 2014 07:48, Sona Sarmadi wrote: > > The advice is: Disable SSLv3. > > > > I created https://bugzilla.yoctoproject.org/show_bug.cgi?id=6843 so we > can start to work with this immediately. > > Presumably the list of affected packages is: > - gnutls > - openssl > - nss > > Are there more? Will ENEA be able to send patches to these packages? > I did a few quick searches of recipe names and descriptions on the meta-openembedded and poky (which includes oe-core) layers for SSL and TLS relation. The searches I used from the poky directory were: find meta* -name "*ssl*.bb" find meta* -name "*tls*.bb" grep -nrE '(ssl|SSL|tls|TLS)' meta* | grep -vE '(DSSSL|dsssl|[Ll]ossless)' | grep '\.bb:' Then ignoring packages that expressly disable SSL, here's what I found for other packages to evaluate: python-pyopenssl socat curl libsoup packagegroup-toolset-native packagegroup-core-basic packagegroup-core-lsb ltp mailx libarchive iputils msmtp webkit-gtk packagegroup-self-hosted eglibc glib-networking x11vnc bind telepathy-idle openssh valgrind tcf-agent python-native python rpm neon nostromo cherokee apache2 ajenti net-snmp claws-mail sylpheed libimobiledevice loudmouth hostap-daemon gateone libtorrent krb5 networkmanager nodejs4 nodejs libc-client python-twisted python-m2crypto links links-x11 openldap gsoap mbuffer cryptsetup iksemel strongswan ca-certificates libetpan cyrus-sasl vsftpd accel-ppp openvpn znc azy midori oscam tvheadend Almost all the packages require openssl or gnutls, so patching openssl and gnutls may be sufficient for most of these packages. I'm still working with the dylan branch. If any new packages have been added since then I may have missed them. I'm not sure how dropbear does its encryption, so that may be one to look at also. Regards, Bryan Evenson > Ross > -- > ___ > 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] Status of Shellshock backport for dylan?
I see that a pull request for backporting the Shellshock fix to the dylan branch had been submitted a few days ago: http://patchwork.openembedded.org/patch/81571/ but the pull request has not made it to the oe-core dylan branch. Is there more testing that needs to be done on this one for dylan, or is there something else holding up pulling in the fix? Thanks, Bryan Evenson -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] PR server import/export operation
All,
I am on poky/dylan and I have not yet changed to using the PR server. There
are some pieces of the PR server operation that I don't understand, and I want
to confirm how certain aspects of the PR server work before I make the switch
to make sure I don't make a mess of my builds.
I see that there is import/export functionality for the PR server
("bitbake-prserv-tool export" and "bitbake-prserv-tool import") for saving the
PR server state. However, I'm confused on how it works for independent build
systems.
Example scenario:
1. I make some changes for a product release and build a new image. I push all
layer changes to our local Git repositories and store the resulting image and
packages on our server.
2. I call "bitbake-prserv-tool export" and push the exported table to our local
Git repository.
3. I tag our local Git repositories "v1.0" to mark the latest product release.
4. My hard drive crashes and I need to get a new one. I get my computer back
up and running and do a fresh clone of our local Git repositories and checkout
"v1.0".
5. I call "bitbake-prserv-tool import" using the PR table from our local Git
repository.
6. I do my initial image build, which pulls in all the source code and builds
all packages for the first time.
My question is: will the package versions for all packages be the same after
step 6 as they were after step 1? Or will every PR get incremented by the PR
server in step 6? If so, is there an order to doing things so that I can get
the PRs to match in step 1 and in step 6?
Regards,
Bryan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Resetting PR for PR service
I am on poky/dylan and I am using the PR service for the first time. At this time I am making some cosmetic .bbappend recipe changes (reordering and spacing with no affect on the final built package). Of course, after rebuilding the recipe the PR service bumped the PR since it saw a change in the metadata. I don't want this package PR to change at this time; the package would "upgrade" on the next release even though the contents are identical. I would like to revert the PR for this package but I am having difficulty. I had not previously used the PR service, so the old package name was foo_1.0.0-r0_arm926ejste.ipk. After being rebuilt, the new package name was foo_1.0.0-r0.0_arm926ejste.ipk (added the .0). I tried to revert the PR for this package as follows: 1. Export the current PR service data by calling "bitbake-prserv-tool export prserv_export.inc" 2. Moved the file cache/prserv.sqlite3 to effectively delete the PR Service database. 3. Opened prserv_export.inc and removed the two lines related to package foo. 4. Cleaned package foo by calling "bitbake -c clean foo" 5. Imported the PR service data by calling "bitbake-prserv-tool import prserv_export.inc" 6. Rebuilt package foo by calling "bitbake foo" After step 6, the resulting package name was still foo_1.0.0-r0.0_arm926ejste.ipk. Is there a step I'm missing in reverting the PR value? On another note, I discovered that to import the prserv data the filename needs to end with .inc, otherwise you get an error stating that Bitbake does not know what to do with the file. Or more specifically, the file to be imported at least can't be a .txt extension. If there is a specific file extension needed for import, I'd suggest the info be included on the PR Service wiki. Regards, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Resetting PR for PR service
Richard, > -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Thursday, November 20, 2014 3:05 PM > To: Bryan Evenson > Cc: Openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Resetting PR for PR service > > On Thu, 2014-11-20 at 19:43 +, Bryan Evenson wrote: > > I am on poky/dylan and I am using the PR service for the first time. At > > this > time I am making some cosmetic .bbappend recipe changes (reordering and > spacing with no affect on the final built package). Of course, after > rebuilding > the recipe the PR service bumped the PR since it saw a change in the > metadata. I don't want this package PR to change at this time; the package > would "upgrade" on the next release even though the contents are identical. > I would like to revert the PR for this package but I am having difficulty. > > > > I had not previously used the PR service, so the old package name was > foo_1.0.0-r0_arm926ejste.ipk. After being rebuilt, the new package name > was foo_1.0.0-r0.0_arm926ejste.ipk (added the .0). I tried to revert the PR > for this package as follows: > > 1. Export the current PR service data by calling "bitbake-prserv-tool export > prserv_export.inc" > > 2. Moved the file cache/prserv.sqlite3 to effectively delete the PR Service > database. > > 3. Opened prserv_export.inc and removed the two lines related to package > foo. > > 4. Cleaned package foo by calling "bitbake -c clean foo" > > This is just off the top of my head but have you tried a -c cleansstate here? > I'd misread your response and I tried -c cleanall and that didn't help. I tried again this time disabling the PR service after the export, then "bitbake -c cleanall foo" followed by "bitbake foo". I then got the errors stating the PR went backwards and the PR had reverted to what I was looking for. I think this is a special case since there is no .0 added yet. I suspect if I wanted to back up a PR that had a value already (such as going from .3 to .2) I could just change the value in the imported text and it'd do what I suspected. I have a few more packages that were modified that I don't want the PR to change, so I have a few more items I could do some testing with. > > 5. Imported the PR service data by calling "bitbake-prserv-tool import > prserv_export.inc" > > 6. Rebuilt package foo by calling "bitbake foo" > > > > After step 6, the resulting package name was still foo_1.0.0- > r0.0_arm926ejste.ipk. Is there a step I'm missing in reverting the PR value? > > > > On another note, I discovered that to import the prserv data the > > filename needs to end with .inc, otherwise you get an error stating > > that Bitbake does not know what to do with the file. Or more > > specifically, the file to be imported at least can't be a .txt > > extension. If there is a specific file extension needed for import, > > I'd suggest the info be included on the PR Service wiki. > > That sounds like a good idea. You should be able to update the wiki? I'll create an account on the wiki and do some edits. Regards, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Setting up an init other than SysVinit or systemd?
All, I am in the process of upgrading core items in my image (core-image-minimal with a few additional packages), and one item I am taking a look at is changing my init from SysVinit. I know the other easily supported option for init is systemd, but if I change to systemd I want to do it because it works best for my setup and not just because I think its my only other option. I'd like to try some other init options out, but I don't see how to setup the configuration to use an init other than SysVinit or systemd and I am looking for some help. >From looking at the OpenEmbedded Metadata Index, I see there is a recipe for >Upstart (http://layers.openembedded.org/layerindex/recipe/4994/) so I'm >assuming somone else has used Upstart at least at one time. I also know that >Busybox includes runit. I'd like to give each of these a try to see how they >work, but first I need to build an image with these init managers. From >looking at the development manual I see how to choose systemd but I don't see >how to choose anything else. What configuration variables do I need to set in order to use a different init system? What items do I need to add that are automatically added when using SysVInit or systemd that would not be added when using an unsupported init system? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Build error on Fedora 21: "Unsupported version of git (2.1.0)"
All, I'm transitioning to a new laptop and I've installed Fedora 21 on the new one. I'm trying to build for the first time and I'm running into some issues. I'm still on the dylan branch. I have an image that is based on core-image-minimal with a few additional packages. When I attempt to build my image, it fails when attempting to patch the Linux kernel. The failure message in log.do_patch says: Unsupported version of git (2.1.0) [ERROR] unable to complete push pending patches are: Unsupported version of git (2.1.0) ERROR. could not update git tree ERROR. Could not apply patches for at91sam9x5ek. So I'm assuming what happened was the build system's version of Git was used for the initial kernel checkout but the host's version of Git is being used in the do_patch step. However, I haven't a clue what to do about it. Any ideas? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Build error on Fedora 21: "Unsupported version of git (2.1.0)"
Bruce, > -Original Message- > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > Sent: Friday, February 27, 2015 1:14 PM > To: Bryan Evenson > Cc: Openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Build error on Fedora 21: "Unsupported version of git > (2.1.0)" > > On Fri, Feb 27, 2015 at 12:17 PM, Bryan Evenson > wrote: > > All, > > > > I'm transitioning to a new laptop and I've installed Fedora 21 on the new > one. I'm trying to build for the first time and I'm running into some issues. > > > > I'm still on the dylan branch. I have an image that is based on core-image- > minimal with a few additional packages. When I attempt to build my image, it > fails when attempting to patch the Linux kernel. The failure message in > log.do_patch says: > > > > Unsupported version of git (2.1.0) > > [ERROR] unable to complete push > > pending patches are: > > Unsupported version of git (2.1.0) > > ERROR. could not update git tree > > ERROR. Could not apply patches for at91sam9x5ek. > > > > So I'm assuming what happened was the build system's version of Git was > used for the initial kernel checkout but the host's version of Git is being > used > in the do_patch step. However, I haven't a clue what to do about it. Any > ideas? > > That older set of kern tools used guilt to push / maintain the kernel patch > queue. guilt unfortunately has a version check, and if the version hasn't been > added, it aborts. > > So you'd need to patch guilt to add that version into its case statement (and > then hope that no other behaviours have changed to break the commands > guilt is running). Thanks, that seems to have solved this problem. But, I keep running into other build problems. I've cherry-picked a few commits to fix issues so far, but I'm getting a few more problems that are less obvious. I'd been working on updating to daisy and was hoping to get dylan to build on the new laptop first to make sure the built image functions okay. I may need to go the other way around... Thanks, Bryan > > Bruce > > > > > Thanks, > > Bryan > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > > -- > "Thou shalt not follow the NULL pointer, for chaos and madness await thee > at its end" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Verification on how TARGET_CFLAGS is set
I am about to upgrade to the dizzy branch. I have a built a bootable image on my test build machine, and now I'm going to be applying changes to the system I use for building production images. I'm planning on deleting my tmp directory to force a re-build of everything. Since I'm rebuilding everything anyway, I'm taking a deeper look at the CFLAGS related settings and I'm getting a little lost in the logic. I'd like to verify these settings before I start rebuilding everything. If I'm following the default logic correctly in bitbake.conf, by default TARGET_CFLAGS will be set to "-O2 -pipe -g -feliminate-unused-debug-types". I want the default TARGET_CFLAGS for my production image to be "-O2 -pipe". What's the suggested variable to change, and where, to get this final value? Do I set TARGET_CFLAGS directly, or do I set SELECTED_OPTIMIZATIONS or even FULL_OPTIMIZATIONS? Do I set it in local.conf or should I be setting it somewhere else? Any other related tips are welcome. Thanks, Bryan Evenson -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Verification on how TARGET_CFLAGS is set
Richard and Mark, > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Richard Purdie > Sent: Monday, March 30, 2015 5:43 PM > To: Mark Hatle > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Verification on how TARGET_CFLAGS is set > > On Mon, 2015-03-30 at 15:37 -0500, Mark Hatle wrote: > > On 3/30/15 3:27 PM, Richard Purdie wrote: > > > On Mon, 2015-03-30 at 13:09 +, Bryan Evenson wrote: > > >> I am about to upgrade to the dizzy branch. I have a built a bootable > > >> image on my test build machine, and now I'm going to be applying > > >> changes to the system I use for building production images. I'm > > >> planning on deleting my tmp directory to force a re-build of > > >> everything. Since I'm rebuilding everything anyway, I'm taking a > > >> deeper look at the CFLAGS related settings and I'm getting a little > > >> lost in the logic. I'd like to verify these settings before I start > > >> rebuilding everything. > > >> > > >> If I'm following the default logic correctly in bitbake.conf, by > > >> default TARGET_CFLAGS will be set to "-O2 -pipe -g > > >> -feliminate-unused-debug-types". I want the default TARGET_CFLAGS > for > > >> my production image to be "-O2 -pipe". What's the suggested variable > > >> to change, and where, to get this final value? Do I set TARGET_CFLAGS > > >> directly, or do I set SELECTED_OPTIMIZATIONS or even > > >> FULL_OPTIMIZATIONS? Do I set it in local.conf or should I be setting > > >> it somewhere else? > > > > > > If I remember rightly, you need the -g option there to generate the -dbg > > > packages correctly. The target system binaries won't change since we > > > separate out the debug data into separate files as part of the packaging > > > process. > > > > > > You therefore can gain some build performance from turning that off but > > > your runtime won't alter much (other than the debuglink ID which is a > > > few bytes). > > > > I strongly caution people against removing '-g' from their production > > builds. > > If you do, you will no longer have any way to do any type of > > production/field > > debug. As Richard indicated the -g will cause the symbols and debug > > information > > to get separated into special -dbg packages that you generally don't > > distribute > > on a production device -- but those same -dbg package (preserved) can be > > later > > used for debugging of production devices. In my situation this is kind of a moot point, as I've never been able to successfully get gdb to work. It has been a while since I've tried, so I guess I could give it another go. > > > > This is why the default is what it is. > > > > The difference in executable size between -g (split debug) and w/o -g, is > > usually around 15 - 30 bytes. Roughly the length of the path to the > executable > > and/or library plus ".debug/" (7 characters) > > Are you sure its even that? I thought it was literally just the debug ID > code and the paths to debug were assumed by the debug tools which would > search several locations for a matching ID? Is that all that it is? I was under the impression that adding -g adds the debug symbols to the executable, not just the hooks to include the debug symbols. If the -g flag really does just add a few bytes to each executable, then I won't worry about it. Regards, Bryan > > Cheers, > > Richard > > -- > ___ > 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] base-files: Upgrade causes circular symbolic link for /run
I am on poky/dizzy and I am testing upgrading of some systems with older firmware. I am using sysvinit for an init and opkg for a package manager. I am having an issue with the /run directory which I believe I have traced down to this commit: http://git.openembedded.org/openembedded-core/commit/meta/recipes-core/base-files?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873 Before this commit, the symbolic links for /run are as follows: /run -> /var/run /var/run -> volatile/run When I upgrade an older system with dizzy HEAD, the symbolic links are as follows: /run -> /var/run /var/run -> ../run This makes /run and /var/run inaccessible since it is a circular symbolic link. As expected, there are a few things that aren't working right because /run cannot be used. Has anyone else had this experience? If so, how did you work around it? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] sysvinit upgrade woes
I am using opkg for package management and sysvinit for init. I am testing a large jump on an upgrade and I have been having a few issues. One issue I have traced to sysvinit's upgrade, but I'm unsure how to remedy the solution. At some point during the upgrade process, opkg records what the new version is of all the packages getting installed. However, when I upgrade sysvinit causes sysvinit to restart before opkg has recorded which packages were just installed. So opkg thinks that it didn't upgrade anything even though all packages were upgraded. I verified that if I call "opkg upgrade" for all packages that require upgrade except for sysvinit that opkg correctly records which packages were upgraded. However, the end user doesn't have that kind of control, so upgrading in this manner is not an option. Has anyone else seen a similar issue? Any ideas on how to hold off sysvinit from restarting until after opkg has finished recording its information? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
All,
> -Original Message-
> From: Bryan Evenson [mailto:beven...@melinkcorp.com]
> Sent: Friday, April 10, 2015 12:44 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Bryan Evenson
> Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
> softlinks on upgrade
>
> Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the locations
> of /run and /var/lock to match the FHS 3 draft specifications.
> However, the install doesn't remove the existing directories.
> As a result, upgrading a system may result in /run as a softlink
> to /var/run and /var/run as a softlink to /run, creating a circular
> link.
>
> During pre and post-install, check for the existence of the old
> softlinks, move the old file contents to a temporary location, remove
> the softlinks, and restore the directory contents after installation.
>
I went about this wrong, as I forgot that items may be mounted under /run. I'm
working on a different solution in which the preinst step removes the /run and
/var/lock softlinks if they exist. However, I still have odd issues. The
first reboot works fine, but then on the next reboot there is a link inside
/run for "run -> /var/run" and inside /var there is a link for "run ->
/var/volatile/run". This doesn't match up with the files listed in the
base-files recipe. I can't figure out where these links are coming from. Has
anyone else had issues upgrading base-files?
Thanks,
Bryan
> Signed-off-by: Bryan Evenson
> ---
> meta/recipes-core/base-files/base-files_3.0.14.bb | 55
> +++
> 1 file changed, 55 insertions(+)
>
> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> b/meta/recipes-core/base-files/base-files_3.0.14.bb
> index 07f5c54..71cea08 100644
> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> @@ -66,6 +66,41 @@ hostname = "openembedded"
>
> BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"
>
> +# In previous versions of base-files, /run was a softlink to /var/run and the
> +# directory was located in /var/volatlie/run. Also, /var/lock was a softlink
> +# to /var/volatile/lock which is where the real directory was located. Now,
> +# /run and /run/lock are the real directories. If we are upgrading, we may
> +# need to remove the symbolic links first before we create the directories.
> +# Otherwise the directory creation will fail and we will have circular
> symbolic
> +# links.
> +#
> +# If we do need to remove the symbolic links first, we also need to preserve
> +# all the contents of the directory so running programs can find the files
> that
> +# are in use in these directories. Move the contents to a temporary
> directory
> +# during pre-install to protect the contents
> +pkg_preinst_${PN} () {
> +#!/bin/sh -e
> +if [ x"$D" = "x" ]; then
> +if [ -e "/var/volatile/lock" ]; then
> +# Move the contents of /var/volatile/lock to a temporary
> directory
> +mkdir -p /run_lock_tmp
> +mv /var/volatile/lock/* /run_lock_tmp/
> +
> +# Remove the current directory
> +rm -rf /var/volatile/lock
> +fi
> +
> +if [ -h "/run" ]; then
> +# Move the contents of /run to a temporary directory
> +mkdir -p /run_tmp
> +mv /run/* /run_tmp/
> +
> +# Remove the current directory
> +rm -rf /run
> +fi
> +fi
> +}
> +
> do_install () {
> for d in ${dirs755}; do
> install -m 0755 -d ${D}$d
> @@ -79,6 +114,7 @@ do_install () {
> for d in ${volatiles}; do
> ln -sf volatile/$d ${D}${localstatedir}/$d
> done
> +
> ln -snf ../run ${D}${localstatedir}/run
> ln -snf ../run/lock ${D}${localstatedir}/lock
>
> @@ -144,6 +180,25 @@ do_install_append_linuxstdbase() {
> done
> }
>
> +# If we are on the actual hardware, check if we had to move /run and
> /run/lock.
> +# If so, copy the temporary directory contents to their new locations.
> +pkg_postinst_${PN} () {
> +#!/bin/sh -e
> +if [ x"$D" = "x" ]; then
> +if [ -e "/run_tmp" ]; then
> +mv /run_tmp/* /run/
> +rmdir /run_tmp
> +fi
> +
> +if [ -e "/run_lock_tmp/" ]; then
> +mv /run_lock_tmp/* /run/lock
> +rmdir /run_lock_tmp
> +fi
> +else
> +exit 1
> +fi
> +}
> +
> PACKAGES = "${PN}-doc ${PN} ${PN}-dev ${PN}-dbg"
> FILES_${PN} = "/"
> FILES_${PN}-doc = "${docdir} ${datadir}/common-licenses"
> --
> 2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
All,
> -Original Message-
> From: Bryan Evenson
> Sent: Tuesday, April 14, 2015 11:47 AM
> To: Bryan Evenson; openembedded-core@lists.openembedded.org
> Subject: RE: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
> softlinks on upgrade
>
> All,
>
> > -Original Message-
> > From: Bryan Evenson [mailto:beven...@melinkcorp.com]
> > Sent: Friday, April 10, 2015 12:44 PM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Bryan Evenson
> > Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and
> > /var/lock softlinks on upgrade
> >
> > Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the
> locations of
> > /run and /var/lock to match the FHS 3 draft specifications.
> > However, the install doesn't remove the existing directories.
> > As a result, upgrading a system may result in /run as a softlink to
> > /var/run and /var/run as a softlink to /run, creating a circular link.
> >
> > During pre and post-install, check for the existence of the old
> > softlinks, move the old file contents to a temporary location, remove
> > the softlinks, and restore the directory contents after installation.
> >
>
> I went about this wrong, as I forgot that items may be mounted under /run.
> I'm working on a different solution in which the preinst step removes the
> /run and /var/lock softlinks if they exist. However, I still have odd issues.
> The first reboot works fine, but then on the next reboot there is a link
> inside
> /run for "run -> /var/run" and inside /var there is a link for "run ->
> /var/volatile/run". This doesn't match up with the files listed in the
> base-files
> recipe. I can't figure out where these links are coming from. Has anyone
> else
> had issues upgrading base-files?
The root cause seems to be the initscripts package. The script
/etc/volatile.cache is generated by /etc/init.d/populate-volatile.sh. On
upgrade, this file is not removed and may not necessarily be regenerated. As a
result, on the next boot the script /etc/volatile.cache repopulates directories
as it remembers them which may not be accurate. In my case, after the reboot,
the /etc/volatile.cache script deleted everything from a USB flash drive
attached to my system when it attempted to remove /run.
So to get this portion of the upgrade to work, I had to:
1. Remove the softlinks for /run and /var/lock through a preinst script in the
base-files recipe
2. Remove /etc/volatile.cache as a postint script in the initscripts recipe
Would someone like for me to submit a patch?
Thanks,
Bryan
>
> Thanks,
> Bryan
>
> > Signed-off-by: Bryan Evenson
> > ---
> > meta/recipes-core/base-files/base-files_3.0.14.bb | 55
> > +++
> > 1 file changed, 55 insertions(+)
> >
> > diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > index 07f5c54..71cea08 100644
> > --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > @@ -66,6 +66,41 @@ hostname = "openembedded"
> >
> > BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"
> >
> > +# In previous versions of base-files, /run was a softlink to /var/run
> > +and the # directory was located in /var/volatlie/run. Also,
> > +/var/lock was a softlink # to /var/volatile/lock which is where the
> > +real directory was located. Now, # /run and /run/lock are the real
> > +directories. If we are upgrading, we may # need to remove the symbolic
> links first before we create the directories.
> > +# Otherwise the directory creation will fail and we will have
> > +circular symbolic # links.
> > +#
> > +# If we do need to remove the symbolic links first, we also need to
> > +preserve # all the contents of the directory so running programs can
> > +find the files that # are in use in these directories. Move the
> > +contents to a temporary
> > directory
> > +# during pre-install to protect the contents pkg_preinst_${PN} () {
> > +#!/bin/sh -e
> > +if [ x"$D" = "x" ]; then
> > +if [ -e "/var/volatile/lock" ]; then
> > +# Move the contents of /var/volatile/lock to a temporary
> > directory
> > +mkdir -p /run_lock_tmp
> > +mv /var/volatile/lock/* /run_lock_tmp/
> > +
> > +# Remove the current directory
> > +rm -rf /var/volatile/lock
> > +fi
> > +
> > +if [ -h "/run"
[OE-core] [dizzy][PATCHv2 1/2] base-files: Check for /run and /var/lock softlinks on upgrade
Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the locations
of /run and /var/lock to match the FHS 3 draft specifications.
However, the install doesn't remove the existing directories.
As a result, upgrading a system may result in /run as a softlink
to /var/run and /var/run as a softlink to /run, creating a circular
link.
During pre-install, check for the existence of the old softlinks and
remove them so the new directories can be installed.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 24 +++
1 file changed, 24 insertions(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 07f5c54..9021103 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -66,6 +66,29 @@ hostname = "openembedded"
BASEFILESISSUEINSTALL ?= "do_install_basefilesissue"
+# In previous versions of base-files, /run was a softlink to /var/run and the
+# directory was located in /var/volatlie/run. Also, /var/lock was a softlink
+# to /var/volatile/lock which is where the real directory was located. Now,
+# /run and /run/lock are the real directories. If we are upgrading, we may
+# need to remove the symbolic links first before we create the directories.
+# Otherwise the directory creation will fail and we will have circular symbolic
+# links.
+#
+pkg_preinst_${PN} () {
+#!/bin/sh -e
+if [ x"$D" = "x" ]; then
+if [ -h "/var/lock" ]; then
+# Remove the symbolic link
+rm -f /var/lock
+fi
+
+if [ -h "/run" ]; then
+# Remove the symbolic link
+rm -f /run
+fi
+fi
+}
+
do_install () {
for d in ${dirs755}; do
install -m 0755 -d ${D}$d
@@ -79,6 +102,7 @@ do_install () {
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dizzy][PATCHv2 2/2] initscripts: Remove /etc/volatile.cache on upgrade
/etc/volatile.cache is a cached copy of a script (which is
generated by /etc/init.d/populate-volatile.sh) that generates
the volatile filesystem directories. Since volatile.cache is
a generated file, it is not necessarily changed if
populate-volatile.sh is updated. As a result, the stale script
can add/remove the wrong directories on the next system boot.
If initscripts is being upgraded, make sure volatile.cache gets
deleted.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/initscripts/initscripts_1.0.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index a665acf..775816a 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -161,4 +161,9 @@ pkg_postinst_${PN} () {
systemctl $OPTS mask $SERVICE.service
done
fi
+
+# Delete any old volatile cache script, as directories may have moved
+if [ -z "$D" ]; then
+rm -f "/etc/volatile.cache"
+fi
}
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] sysvinit upgrade woes
All,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Bryan Evenson
> Sent: Tuesday, April 14, 2015 11:26 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] sysvinit upgrade woes
>
> I am using opkg for package management and sysvinit for init. I am testing a
> large jump on an upgrade and I have been having a few issues. One issue I
> have traced to sysvinit's upgrade, but I'm unsure how to remedy the
> solution.
>
> At some point during the upgrade process, opkg records what the new
> version is of all the packages getting installed. However, when I upgrade
> sysvinit causes sysvinit to restart before opkg has recorded which packages
> were just installed. So opkg thinks that it didn't upgrade anything even
> though all packages were upgraded. I verified that if I call "opkg upgrade"
> for
> all packages that require upgrade except for sysvinit that opkg correctly
> records which packages were upgraded. However, the end user doesn't
> have that kind of control, so upgrading in this manner is not an option.
>
> Has anyone else seen a similar issue? Any ideas on how to hold off sysvinit
> from restarting until after opkg has finished recording its information?
>
I've found the problem but don't yet have a good solution. At the end of the
sysvinit-inittab pkg_postinst script is the line:
kill -HUP 1
This kills init before opkg has finished doing its job. On my system, I've
added a .bbappend with a pk_postinst script as follows for items that require a
reboot after installation:
touch /var/run/reboot-required
echo "${PN}" >>/var/run/reboot-required.pkgs
After my system performs firmware upgrade, it checks if
/var/run/reboot-required exists and then reboots the system. So on my system,
I changed the pkg_postinst script for sysvinit-inittab to replace the "kill
-HUP 1" with the reboot required notations.
Is there some suitable solution that would be reasonable to change in the
sysvinit-inittab recipe that would work for other people?
Regards,
Bryan
> Thanks,
> Bryan
> --
> ___
> 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] sysvinit upgrade woes
Paul,
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Thursday, April 16, 2015 1:57 PM
> To: Bryan Evenson
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] sysvinit upgrade woes
>
> Hi Bryan,
>
> On Thursday 16 April 2015 13:53:14 Bryan Evenson wrote:
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf
> > > Of Bryan Evenson
> > > Sent: Tuesday, April 14, 2015 11:26 AM
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: [OE-core] sysvinit upgrade woes
> > >
> > > I am using opkg for package management and sysvinit for init. I am
> > > testing a large jump on an upgrade and I have been having a few issues.
> > > One issue I have traced to sysvinit's upgrade, but I'm unsure how to
> > > remedy the solution.
> > >
> > > At some point during the upgrade process, opkg records what the new
> > > version is of all the packages getting installed. However, when I
> > > upgrade sysvinit causes sysvinit to restart before opkg has recorded
> > > which packages were just installed. So opkg thinks that it didn't
> > > upgrade anything even though all packages were upgraded. I verified
> > > that if I call "opkg upgrade" for all packages that require upgrade
> > > except for sysvinit that opkg correctly records which packages were
> > > upgraded. However, the end user doesn't have that kind of control,
> > > so upgrading in this manner is not an option.
> > >
> > > Has anyone else seen a similar issue? Any ideas on how to hold off
> > > sysvinit from restarting until after opkg has finished recording its
> > > information?
> >
> > I've found the problem but don't yet have a good solution. At the end
> > of the sysvinit-inittab pkg_postinst script is the line:
> >
> > kill -HUP 1
> >
> > This kills init before opkg has finished doing its job. On my system,
> > I've added a .bbappend with a pk_postinst script as follows for items
> > that require a reboot after installation:
> >
> > touch /var/run/reboot-required
> > echo "${PN}" >>/var/run/reboot-required.pkgs
> >
> > After my system performs firmware upgrade, it checks if
> > /var/run/reboot-required exists and then reboots the system. So on my
> > system, I changed the pkg_postinst script for sysvinit-inittab to
> > replace the "kill -HUP 1" with the reboot required notations.
> >
> > Is there some suitable solution that would be reasonable to change in
> > the sysvinit-inittab recipe that would work for other people?
>
> SIGHUP is supposed to make sysvinit re-read inittab, not kill it. Can you tell
> what is actually happening?
Ah, I don't know for sure what is happening but now I have a different guess.
I have tried running the upgrade with "opkg -V4 upgrade" (insanely verbose
debug output) and I can tell that is doing the postinst scripts when the
upgrade stops and I get logged out. I am doing my testing through the debug
serial port on my system. My best guess without further proof is that the
SIGHUP restarts my terminal which in turn kills "opkg upgrade" which was
commanded through my terminal.
If that is what is happening, then the upgrade should continue normally if I
send it to the background ("opkg upgrade &"), correct? Or it would run just
fine if a cron job started the upgrade?
Thanks,
Bryan
>
> Cheers,
> Paul
>
> --
>
> 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] sysvinit upgrade woes
Martin and Paul,
> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Thursday, April 16, 2015 3:11 PM
> To: Bryan Evenson
> Cc: Paul Eggleton; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] sysvinit upgrade woes
>
> On Thu, Apr 16, 2015 at 06:42:58PM +, Bryan Evenson wrote:
> > Paul,
> >
> > > -Original Message-
> > > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> > > Sent: Thursday, April 16, 2015 1:57 PM
> > > To: Bryan Evenson
> > > Cc: openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] sysvinit upgrade woes
> > >
> > > Hi Bryan,
> > >
> > > On Thursday 16 April 2015 13:53:14 Bryan Evenson wrote:
> > > > > -Original Message-
> > > > > From: openembedded-core-boun...@lists.openembedded.org
> > > > > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> > > Behalf
> > > > > Of Bryan Evenson
> > > > > Sent: Tuesday, April 14, 2015 11:26 AM
> > > > > To: openembedded-core@lists.openembedded.org
> > > > > Subject: [OE-core] sysvinit upgrade woes
> > > > >
> > > > > I am using opkg for package management and sysvinit for init. I am
> > > > > testing a large jump on an upgrade and I have been having a few
> issues.
> > > > > One issue I have traced to sysvinit's upgrade, but I'm unsure how to
> > > > > remedy the solution.
> > > > >
> > > > > At some point during the upgrade process, opkg records what the
> new
> > > > > version is of all the packages getting installed. However, when I
> > > > > upgrade sysvinit causes sysvinit to restart before opkg has recorded
> > > > > which packages were just installed. So opkg thinks that it didn't
> > > > > upgrade anything even though all packages were upgraded. I verified
> > > > > that if I call "opkg upgrade" for all packages that require upgrade
> > > > > except for sysvinit that opkg correctly records which packages were
> > > > > upgraded. However, the end user doesn't have that kind of control,
> > > > > so upgrading in this manner is not an option.
> > > > >
> > > > > Has anyone else seen a similar issue? Any ideas on how to hold off
> > > > > sysvinit from restarting until after opkg has finished recording its
> > > > > information?
> > > >
> > > > I've found the problem but don't yet have a good solution. At the end
> > > > of the sysvinit-inittab pkg_postinst script is the line:
> > > >
> > > > kill -HUP 1
> > > >
> > > > This kills init before opkg has finished doing its job. On my system,
> > > > I've added a .bbappend with a pk_postinst script as follows for items
> > > > that require a reboot after installation:
> > > >
> > > > touch /var/run/reboot-required
> > > > echo "${PN}" >>/var/run/reboot-required.pkgs
> > > >
> > > > After my system performs firmware upgrade, it checks if
> > > > /var/run/reboot-required exists and then reboots the system. So on
> my
> > > > system, I changed the pkg_postinst script for sysvinit-inittab to
> > > > replace the "kill -HUP 1" with the reboot required notations.
> > > >
> > > > Is there some suitable solution that would be reasonable to change in
> > > > the sysvinit-inittab recipe that would work for other people?
> > >
> > > SIGHUP is supposed to make sysvinit re-read inittab, not kill it. Can you
> tell
> > > what is actually happening?
> >
> > Ah, I don't know for sure what is happening but now I have a different
> guess. I have tried running the upgrade with "opkg -V4 upgrade" (insanely
> verbose debug output) and I can tell that is doing the postinst scripts when
> the upgrade stops and I get logged out. I am doing my testing through the
> debug serial port on my system. My best guess without further proof is that
> the SIGHUP restarts my terminal which in turn kills "opkg upgrade" which was
> commanded through my terminal.
> >
> > If that is what is happening, then the upgrade should continue normally if I
> send it to the background ("opkg upgrade &"), correct? Or it would run just
> fine if a cron job started the up
[OE-core] Clarification on backport and bugfix patch submittal process
Last week I had submitted two patches (1f994e81717502fd9d3c2f69772ae8556e6de4cb and 433ec67686d6991d2d5f43fd1af957968da1971c) related to problems I had been having on the dizzy branch and was happy to see they were accepted. However, I only see the patches on the dizzy branch and I think these changes are suitable for backport for all supported branches since the problem was introduced (which I think was introduced in dora). I think I had included [dizzy] as a tag in the subject for the patches since that was the branch I had been working with. I can see that there are cases in which a patch only applies to a particular branch (e.g. package version changes in the next branch, patch no longer applies) and there are cases in which the patch is applicable for master all the way back to a particular branch. What is the suggested way of indicating the difference when submitting patches? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Clarification on backport and bugfix patch submittal process
Paul, > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Monday, April 20, 2015 9:18 AM > To: Bryan Evenson > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] Clarification on backport and bugfix patch submittal > process > > Hi Bryan, > > On Monday 20 April 2015 12:42:33 Bryan Evenson wrote: > > Last week I had submitted two patches > > (1f994e81717502fd9d3c2f69772ae8556e6de4cb and > > 433ec67686d6991d2d5f43fd1af957968da1971c) related to problems I had > > been having on the dizzy branch and was happy to see they were > accepted. > > However, I only see the patches on the dizzy branch and I think these > > changes are suitable for backport for all supported branches since the > > problem was introduced (which I think was introduced in dora). I > > think I had included [dizzy] as a tag in the subject for the patches > > since that was the branch I had been working with. > > Is the patch also applicable to fido/master? Because at the moment it seems > only to have been applied to dizzy. > Yes, in my opinion these two patches are suitable for dora up through master. > > I can see that there are cases in which a patch only applies to a > > particular branch (e.g. package version changes in the next branch, > > patch no longer > > applies) and there are cases in which the patch is applicable for > > master all the way back to a particular branch. What is the suggested > > way of indicating the difference when submitting patches? > > In general the policies we use for maintaining the stable branch should be > documented here: > > https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance > That page helps a lot. I've bookmarked it for future reference when submitting patches. Thanks, Bryan > I would say if there is any specificity to the issue the patch fixes, > particularly if > it only applies to one of the stable branches, it should probably be noted in > the commit message. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] udev: Add RCONFLICTS/RREPLACES for udev-utils
As of commit 9bb5c7472958aeea46225e835f44d45bea7f7351, the
udev-utils package no longer exists with udev taking ownership
of udevadm. However, systems that had udev-utils installed have
a conflict with udev.
Add RCONFLICTS and RREPLACES variables for udev-utils so udev-utils
will be removed from systems that are upgrading udev. This change
would be applicable for master back through dizzy when the problem
was introduced.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/udev/udev.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/udev/udev.inc b/meta/recipes-core/udev/udev.inc
index 24463b1..a63fc8c 100644
--- a/meta/recipes-core/udev/udev.inc
+++ b/meta/recipes-core/udev/udev.inc
@@ -61,6 +61,11 @@ INITSCRIPT_PARAMS_udev-cache = "start 36 S ."
FILES_${PN} += "${libexecdir} ${libdir}/ConsoleKit ${nonarch_base_libdir}/udev
${bindir}/udevadm"
RRECOMMENDS_${PN} += "udev-cache"
+# udev-utils has been removed as a package. Note that udev conflicts with
udev-utils so that
+# udev-utils is removed from systems on upgrade.
+RCONFLICTS_${PN} += "udev-utils"
+RREPLACES_${PN} += "udev-utils"
+
FILES_${PN}-dbg += "${libexecdir}/.debug"
FILES_${PN}-dbg += "${base_libdir}/udev/.debug/"
FILES_${PN}-dbg += "${base_libdir}/udev/.debug/*"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Add alternatives for lastb
Both sysvinit and util-linux create lastb as a softlink to last. However, neither package references lastb in their alternatives list. As a result, package managers may not upgrade either package unless they are specifically told to upgrade anyway. Add lastb to the alternatives list for both sysvinit and util-linux so package managers will upgrade both packages without conflict. Bryan Evenson (2): sysvinit: Add lastb to alternatives util-linux: Add lastb to alternatives meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb | 2 +- meta/recipes-core/util-linux/util-linux.inc| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] sysvinit: Add lastb to alternatives
SysVinit creates lastb as a symlink to last during the build.
Just as other applications may provide last, other applications
may provide lastb.
Add alternatives designations for lastb to avoid installation
conflicts with other applications.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
b/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
index 00d..2c7e3ce 100644
--- a/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
+++ b/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb
@@ -29,7 +29,7 @@ B = "${S}/src"
inherit update-alternatives
DEPENDS_append = " update-rc.d-native base-passwd"
-ALTERNATIVE_${PN} = "init mountpoint halt reboot runlevel shutdown poweroff
last mesg utmpdump wall"
+ALTERNATIVE_${PN} = "init mountpoint halt reboot runlevel shutdown poweroff
last lastb mesg utmpdump wall"
ALTERNATIVE_PRIORITY = "200"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] util-linux: Add lastb to alternatives
util-linux creates lastb as a symlink to last during the build.
Just as other applications may provide last, other applications
may provide lastb.
Add alternatives designations for lastb to avoid installation
conflicts with other applications.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/util-linux/util-linux.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 2c299e8..78cff02 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -168,7 +168,7 @@ inherit update-alternatives
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root switch_root"
-ALTERNATIVE_${PN} += "mkfs.minix hexdump last logger mesg renice wall"
+ALTERNATIVE_${PN} += "mkfs.minix hexdump last lastb logger mesg renice wall"
ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject getopt sulogin"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] util-linux: Add lastb to alternatives
Richard, > -Original Message- > From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] > Sent: Monday, April 20, 2015 11:12 AM > To: Bryan Evenson > Cc: Openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH 2/2] util-linux: Add lastb to alternatives > > On Mon, 2015-04-20 at 11:07 -0400, Bryan Evenson wrote: > > util-linux creates lastb as a symlink to last during the build. > > Just as other applications may provide last, other applications may > > provide lastb. > > > > Add alternatives designations for lastb to avoid installation > > conflicts with other applications. > > > > Signed-off-by: Bryan Evenson > > --- > > meta/recipes-core/util-linux/util-linux.inc | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Doesn't appear to apply against master? > Sorry, there a few recent commits to util-linux on master that I had missed. One of the commits is doing something similar for lastb, but only for the man page and not for the executable. I'll check with those involved with the last few util-linux commits to see if they already have a commit in the works that includes the same changes as mine. Regards, Bryan > Cheers, > > Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] util-linux: Add lastb to alternatives
util-linux creates lastb as a symlink to last during the build.
Just as other applications may provide last, other applications
may provide lastb.
Add alternatives designations for lastb to avoid installation
conflicts with other applications.
Signed-off-by: Bryan Evenson
Conflicts:
meta/recipes-core/util-linux/util-linux.inc
---
meta/recipes-core/util-linux/util-linux.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 80065e3..60309a5 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -174,7 +174,7 @@ do_install_append_class-native () {
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root switch_root"
-ALTERNATIVE_${PN} += "mkfs.minix hexdump last logger mesg renice wall"
+ALTERNATIVE_${PN} += "mkfs.minix hexdump last lastb logger mesg renice wall"
ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] populate-volatile.sh: detect the change of configuration files
Chen,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of ChenQi
> Sent: Tuesday, April 21, 2015 2:00 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] populate-volatile.sh: detect the change
> of configuration files
>
> ping ...
>
> //Chen Qi
>
> On 03/20/2015 02:27 PM, Chen Qi wrote:
> > In case the configuration files are modified by user, the cached
> > script, /etc/volatile.cache should not be executed. Instead, the
> > configuration files should be parsed again and generate the new cache.
> > Otherwise, the user modifications take no effect which would obviously
> confuse users.
> >
> > Signed-off-by: Chen Qi
> > ---
> > .../initscripts/initscripts-1.0/populate-volatile.sh | 19
> ++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git
> > a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > index 904037e..eaf0f1c 100755
> > ---
> > a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > +++ b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.
> > +++ sh
> > @@ -204,9 +204,25 @@ do
> > done
> > exec 9>&-
> >
> > -if test -e ${ROOT_DIR}/etc/volatile.cache -a "$VOLATILE_ENABLE_CACHE"
> = "yes" -a "x$1" != "xupdate" -a "x$clearcache" = "x0"
> > +# Check whether configuration files have changed, if so, the cache
> > +needs to be removed # and generated again CACHE_MATCH="no"
> > +CACHE_DATA="${ROOT_DIR}/etc/.volatile.cache.data"
> > +CACHE_TMP="${ROOT_DIR}/etc/.volatile.cache.tmp"
> > +VOLATILE_CONFFILES="${ROOT_DIR}/etc/default/volatiles/*"
> > +if [ "$VOLATILE_ENABLE_CACHE" = "yes" ]; then
> > + stat -c '%s %Y %n' $VOLATILE_CONFFILES | awk -F/ '{print $1 " " $NF;}'
> > $CACHE_TMP
> > + if [ -e $CACHE_DATA ]; then
> > + if cmp $CACHE_DATA $CACHE_TMP > /dev/null; then
> > + CACHE_MATCH="yes"
> > + fi
> > + fi
> > +fi
> > +
> > +if test -e ${ROOT_DIR}/etc/volatile.cache -a "$VOLATILE_ENABLE_CACHE"
> = "yes" -a "x$1" != "xupdate" -a "x$clearcache" = "x0" -a "$CACHE_MATCH" =
> "yes"
> > then
> > sh ${ROOT_DIR}/etc/volatile.cache
> > + [ -e $CACHE_TMP ] && rm $CACHE_TMP
> > else
> > rm -f ${ROOT_DIR}/etc/volatile.cache
> ${ROOT_DIR}/etc/volatile.cache.build
> > for file in `ls -1 "${CFGDIR}" | sort`; do @@ -214,6 +230,7 @@ else
> > done
> >
> > [ -e ${ROOT_DIR}/etc/volatile.cache.build ] && sync && mv
> > ${ROOT_DIR}/etc/volatile.cache.build ${ROOT_DIR}/etc/volatile.cache
> > + [ -e $CACHE_TMP ] && mv $CACHE_TMP $CACHE_DATA
> > fi
> >
> > if [ -z "${ROOT_DIR}" ] && [ -f /etc/ld.so.cache ] && [ ! -f
> > /var/run/ld.so.cache ]
>
I didn't see this patch when I was working through my issues. I'll test this
patch on my system with my change to pkg_postinst removed and verify I get the
same end result.
Regards,
Bryan
> --
> ___
> 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 1/1] populate-volatile.sh: detect the change of configuration files
Chen,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Bryan Evenson
> Sent: Tuesday, April 21, 2015 8:35 AM
> To: ChenQi; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] populate-volatile.sh: detect the change
> of configuration files
>
> Chen,
>
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf Of
> > ChenQi
> > Sent: Tuesday, April 21, 2015 2:00 AM
> > To: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] [PATCH 1/1] populate-volatile.sh: detect the
> > change of configuration files
> >
> > ping ...
> >
> > //Chen Qi
> >
> > On 03/20/2015 02:27 PM, Chen Qi wrote:
> > > In case the configuration files are modified by user, the cached
> > > script, /etc/volatile.cache should not be executed. Instead, the
> > > configuration files should be parsed again and generate the new cache.
> > > Otherwise, the user modifications take no effect which would
> > > obviously
> > confuse users.
> > >
> > > Signed-off-by: Chen Qi
> > > ---
> > > .../initscripts/initscripts-1.0/populate-volatile.sh | 19
> > ++-
> > > 1 file changed, 18 insertions(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > > b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > > index 904037e..eaf0f1c 100755
> > > ---
> > > a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> > > +++ b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.
> > > +++ sh
> > > @@ -204,9 +204,25 @@ do
> > > done
> > > exec 9>&-
> > >
> > > -if test -e ${ROOT_DIR}/etc/volatile.cache -a
> "$VOLATILE_ENABLE_CACHE"
> > = "yes" -a "x$1" != "xupdate" -a "x$clearcache" = "x0"
> > > +# Check whether configuration files have changed, if so, the cache
> > > +needs to be removed # and generated again CACHE_MATCH="no"
> > > +CACHE_DATA="${ROOT_DIR}/etc/.volatile.cache.data"
> > > +CACHE_TMP="${ROOT_DIR}/etc/.volatile.cache.tmp"
> > > +VOLATILE_CONFFILES="${ROOT_DIR}/etc/default/volatiles/*"
> > > +if [ "$VOLATILE_ENABLE_CACHE" = "yes" ]; then
> > > + stat -c '%s %Y %n' $VOLATILE_CONFFILES | awk -F/ '{print $1 " " $NF;}'
> > > $CACHE_TMP
> > > + if [ -e $CACHE_DATA ]; then
> > > + if cmp $CACHE_DATA $CACHE_TMP > /dev/null; then
> > > + CACHE_MATCH="yes"
> > > + fi
> > > + fi
> > > +fi
> > > +
> > > +if test -e ${ROOT_DIR}/etc/volatile.cache -a
> "$VOLATILE_ENABLE_CACHE"
> > = "yes" -a "x$1" != "xupdate" -a "x$clearcache" = "x0" -a
> > "$CACHE_MATCH" = "yes"
> > > then
> > > sh ${ROOT_DIR}/etc/volatile.cache
> > > + [ -e $CACHE_TMP ] && rm $CACHE_TMP
> > > else
> > > rm -f ${ROOT_DIR}/etc/volatile.cache
> > ${ROOT_DIR}/etc/volatile.cache.build
> > > for file in `ls -1 "${CFGDIR}" | sort`; do @@ -214,6 +230,7 @@
> > > else
> > > done
> > >
> > > [ -e ${ROOT_DIR}/etc/volatile.cache.build ] && sync && mv
> > > ${ROOT_DIR}/etc/volatile.cache.build ${ROOT_DIR}/etc/volatile.cache
> > > + [ -e $CACHE_TMP ] && mv $CACHE_TMP $CACHE_DATA
> > > fi
> > >
> > > if [ -z "${ROOT_DIR}" ] && [ -f /etc/ld.so.cache ] && [ ! -f
> > > /var/run/ld.so.cache ]
> >
>
> I didn't see this patch when I was working through my issues. I'll test this
> patch on my system with my change to pkg_postinst removed and verify I
> get the same end result.
I reverted commit 167025e6d72c44cacfdc5d8b98e942066df09a4f on my system and
applied your patch and applied the upgrade as before. /etc/volatile.cache was
updated on my system and I don't see any of the problems I was experiencing
previously. This fix works for me.
Regards,
Bryan
>
> Regards,
> Bryan
>
> > --
> > ___
> > 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
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv3] util-linux: Add lastb to alternatives
util-linux creates lastb as a symlink to last during the build.
Just as other applications may provide last, other applications
may provide lastb. Add alternatives designations for lastb to
avoid installation conflicts with other applications.
Both last and lastb are can be exist in other packages.
Add lastb to the list of alternatives for util-linux.
Add last as a PACKAGECONFIG option and optionally build last
if requested. Only generate the last and lastb alternative links
if last is enabled in the configuration.
Signed-off-by: Bryan Evenson
Conflicts:
meta/recipes-core/util-linux/util-linux.inc
---
meta/recipes-core/util-linux/util-linux.inc | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 80065e3..ada64fc 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -39,7 +39,7 @@ PACKAGES_DYNAMIC = "^util-linux-lib.*"
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-makeinstall-chown \
- --enable-kill --enable-last --enable-mesg
--enable-partx \
+ --enable-kill --enable-mesg --enable-partx \
--enable-raw --enable-reset --disable-login \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
@@ -49,7 +49,8 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
EXTRA_OECONF = "${SHARED_EXTRA_OECONF} --libdir=${base_libdir}"
-PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)}"
+PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
+ last"
PACKAGECONFIG[pam] = "--enable-su --enable-runuser,--disable-su
--disable-runuser, libpam,"
# Respect the systemd feature for uuidd
@@ -61,6 +62,8 @@ PACKAGECONFIG[libcap-ng] =
"--enable-setpriv,--disable-setpriv,libcap-ng,"
# Build python bindings for libmount
PACKAGECONFIG[pylibmount] = "--with-python
--enable-pylibmount,--without-python --disable-pylibmount,python"
+PACKAGECONFIG[last] = "--enable-last,,"
+
FILES_${PN}-bash-completion += "${datadir}/bash-completion"
FILES_${PN}-doc += "${datadir}/getopt/getopt-*.*"
@@ -174,7 +177,7 @@ do_install_append_class-native () {
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root switch_root"
-ALTERNATIVE_${PN} += "mkfs.minix hexdump last logger mesg renice wall"
+ALTERNATIVE_${PN} += "mkfs.minix hexdump logger mesg renice wall"
ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
@@ -187,10 +190,8 @@ ALTERNATIVE_LINK_NAME[switch_root] =
"${base_sbindir}/switch_root"
ALTERNATIVE_LINK_NAME[mkfs.minix] = "${base_sbindir}/mkfs.minix"
ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
-ALTERNATIVE_${PN}-doc = "mountpoint.1 last.1 lastb.1 mesg.1 wall.1 nologin.8
sulogin.8 utmpdump.1 reset.1"
+ALTERNATIVE_${PN}-doc = "mountpoint.1 mesg.1 wall.1 nologin.8 sulogin.8
utmpdump.1 reset.1"
-ALTERNATIVE_LINK_NAME[last.1] = "${mandir}/man1/last.1"
-ALTERNATIVE_LINK_NAME[lastb.1] = "${mandir}/man1/lastb.1"
ALTERNATIVE_LINK_NAME[mesg.1] = "${mandir}/man1/mesg.1"
ALTERNATIVE_LINK_NAME[mountpoint.1] = "${mandir}/man1/mountpoint.1"
ALTERNATIVE_LINK_NAME[nologin.8] = "${mandir}/man8/nologin.8"
@@ -252,6 +253,15 @@ python do_package_prepend () {
alt_name = "su"
d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, '%s/%s' %
(d.getVar('base_bindir', True), alt_name))
d.appendVar('ALTERNATIVE_%s' % (d.getVar('PN', True)), ' ' + alt_name)
+if '--enable-last' in d.getVar('EXTRA_OECONF', True).split():
+alt_name_last = "last"
+alt_name_lastb = "lastb"
+d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name_last, '%s/%s' %
(d.getVar('bindir', True), alt_name_last))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name_lastb, '%s/%s' %
(d.getVar('bindir', True), alt_name_lastb))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', '%s.1' % alt_name_last,
'%s/man1/%s.1' % (d.getVar('mandir', True), alt_name_last))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', '%s.1' % alt_name_lastb,
'%s/man1/%s.1' % (d.getVar('mandir', True), alt_name_lastb))
+d.appendVar('ALTERNATIVE_%s' % (d.getVar('PN', True)), ' ' +
alt_name_last + ' ' + alt_name_lastb)
+d.appendVar('ALTERNATIVE_%s-doc' % (d.getVar('PN', True)), ' ' +
alt_name_last + ' ' + alt_name_lastb)
}
python populate_packages_prepend() {
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv3] Add alternatives for lastb
I made some more changes to the util-linux patch based upon some feedback. Changes from v2: * Uses PACKAGECONFIG to optionally build last * Only provides binary and man page alternatives if last is built Bryan Evenson (1): util-linux: Add lastb to alternatives meta/recipes-core/util-linux/util-linux.inc | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv4] Add alternatives for lastb
I received help from Matthieu Crapet to find and fix a few problems with v3. Changes in v4: * Adds last to PACKAGECONFIG_class-native and PACKAGECONFIG_class-nativesdk to mimic current behavior * Add "--disable-last" to configuration options if last is not in PACKAGECONFIG * Fix errors in the documentation alternative link generation Changes in v3: * Uses PACKAGECONFIG to optionally build last * Only provides binary and man page alternatives if last is built Changes in v2: * Rebase on master so patch applies cleanly Bryan Evenson (1): util-linux: Add lastb to alternatives meta/recipes-core/util-linux/util-linux.inc | 25 +++-- 1 file changed, 19 insertions(+), 6 deletions(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv4] util-linux: Add lastb to alternatives
util-linux creates lastb as a symlink to last during the build.
Just as other applications may provide last, other applications
may provide lastb. Add alternatives designations for lastb to
avoid installation conflicts with other applications.
Both last and lastb are can be exist in other packages.
Add lastb to the list of alternatives for util-linux.
Add last as a PACKAGECONFIG option and optionally build last
if requested. Only generate the last and lastb alternative links
if last is enabled in the configuration.
Signed-off-by: Bryan Evenson
Tested-by: Matthieu Crapet
---
meta/recipes-core/util-linux/util-linux.inc | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 80065e3..724969f 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -39,7 +39,7 @@ PACKAGES_DYNAMIC = "^util-linux-lib.*"
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-makeinstall-chown \
- --enable-kill --enable-last --enable-mesg
--enable-partx \
+ --enable-kill --enable-mesg --enable-partx \
--enable-raw --enable-reset --disable-login \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
@@ -49,7 +49,11 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
EXTRA_OECONF = "${SHARED_EXTRA_OECONF} --libdir=${base_libdir}"
-PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)}"
+PACKAGECONFIG_class-target ?= "${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam', '', d)} \
+ last"
+PACKAGECONFIG_class-native ?= "last"
+PACKAGECONFIG_class-nativesdk ?= "last"
+
PACKAGECONFIG[pam] = "--enable-su --enable-runuser,--disable-su
--disable-runuser, libpam,"
# Respect the systemd feature for uuidd
@@ -61,6 +65,8 @@ PACKAGECONFIG[libcap-ng] =
"--enable-setpriv,--disable-setpriv,libcap-ng,"
# Build python bindings for libmount
PACKAGECONFIG[pylibmount] = "--with-python
--enable-pylibmount,--without-python --disable-pylibmount,python"
+PACKAGECONFIG[last] = "--enable-last,--disable-last"
+
FILES_${PN}-bash-completion += "${datadir}/bash-completion"
FILES_${PN}-doc += "${datadir}/getopt/getopt-*.*"
@@ -174,7 +180,7 @@ do_install_append_class-native () {
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root switch_root"
-ALTERNATIVE_${PN} += "mkfs.minix hexdump last logger mesg renice wall"
+ALTERNATIVE_${PN} += "mkfs.minix hexdump logger mesg renice wall"
ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
@@ -187,10 +193,8 @@ ALTERNATIVE_LINK_NAME[switch_root] =
"${base_sbindir}/switch_root"
ALTERNATIVE_LINK_NAME[mkfs.minix] = "${base_sbindir}/mkfs.minix"
ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
-ALTERNATIVE_${PN}-doc = "mountpoint.1 last.1 lastb.1 mesg.1 wall.1 nologin.8
sulogin.8 utmpdump.1 reset.1"
+ALTERNATIVE_${PN}-doc = "mountpoint.1 mesg.1 wall.1 nologin.8 sulogin.8
utmpdump.1 reset.1"
-ALTERNATIVE_LINK_NAME[last.1] = "${mandir}/man1/last.1"
-ALTERNATIVE_LINK_NAME[lastb.1] = "${mandir}/man1/lastb.1"
ALTERNATIVE_LINK_NAME[mesg.1] = "${mandir}/man1/mesg.1"
ALTERNATIVE_LINK_NAME[mountpoint.1] = "${mandir}/man1/mountpoint.1"
ALTERNATIVE_LINK_NAME[nologin.8] = "${mandir}/man8/nologin.8"
@@ -252,6 +256,15 @@ python do_package_prepend () {
alt_name = "su"
d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, '%s/%s' %
(d.getVar('base_bindir', True), alt_name))
d.appendVar('ALTERNATIVE_%s' % (d.getVar('PN', True)), ' ' + alt_name)
+if '--enable-last' in d.getVar('EXTRA_OECONF', True).split():
+alt_name_last = "last"
+alt_name_lastb = "lastb"
+d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name_last, '%s/%s' %
(d.getVar('bindir', True), alt_name_last))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name_lastb, '%s/%s' %
(d.getVar('bindir', True), alt_name_lastb))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', '%s.1' % alt_name_last,
'%s/man1/%s.1' % (d.getVar('mandir', True), alt_name_last))
+d.setVarFlag('ALTERNATIVE_LINK_NAME', '%s.1' % alt_name_lastb,
'%s/man1/%s.1' % (d.getVar('mandir', True), alt_name_lastb))
+d.appendVar('ALTERNATIVE_%s' % (d.getVar('PN', True)), ' ' +
alt_name_last + ' ' + alt_name_lastb)
+d.appendVar('ALTERNATIVE_%s-doc' % (d.getVar('PN', True)), ' ' +
alt_name_last + '.1 ' + alt_name_lastb + '.1')
}
python populate_packages_prepend() {
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 00/70] Proposed changes for fido
Joshua, > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Joshua Lock > Sent: Monday, May 11, 2015 4:41 AM > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH 00/70] Proposed changes for fido > > Please consider the following changes for the fido stable branch. > > Regards, > > Joshua > > The following changes since commit > cd3da9c95f48899e134a5b7ed1754fd18985df4f: > > curl: several security fixes (2015-04-27 15:25:19 +0100) > > are available in the git repository at: > > git://git.openembedded.org/openembedded-core-contrib joshuagl/fido- > next > http://cgit.openembedded.org/cgit.cgi/openembedded-core- > contrib/log/?h=joshuagl/fido-next > > Andre McCurdy (2): > libpcap.inc: remove obsolete libnl1 PACKAGECONFIG > busybox: remove CVE-2014-9645 patch (already upstream in 1.23.x) > > Aníbal Limón (2): > lzop: Fix build using x32 ABI > nss: Fix build in x32 ABI > > Armin Kuster (1): > crypto: use bigint in x86-64 perl > > Bruno Bottazzini (1): > systemd 219 -> system 219-stable > > Bryan Evenson (1): > util-linux: Add lastb to alternatives There is a refined version of this patch available that was submitted to the mailing list here: http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104132.html. It uses PACKAGECONFIG to remove last, lastb and the man pages for last and lastb from the util-linux build if 'last' is not in PACKAGECONFIG. It also adds 'last' to PACKAGECONFIG by default which mimics previous behavior. I'm still a little unclear on the patch approval process, so I assume the updated patch would need to be accepted into master before being backported into fido? Regards, Bryan > > Carlos Rafael Giani (1): > u-boot.inc: make sure all counter variables are properly unset > > Chen Qi (5): > shadow: fix `su' behaviour > uninative-tarball: delete the packagedata task > populate_sdk_base: avoid executing empty function > util-linux: split out util-linux-sulogin > shadow: add 'util-linux-sulogin' to RDEPENDS > > Christopher Larson (1): > oe.sstatesig: align swspec handling with sstate.bbclass > > Chunrong Guo (1): > groff: add runtime dependency on sed > > Cristian Iorga (1): > oeqa/selftest/toaster: fix bad indent > > Denys Dmytriyenko (1): > security_flags.inc: elfutils on ARM fails with PIE flags > > Dmitry Eremin-Solenikov (2): > lsb: provide lsb-core-ARCH > bitbake.conf: add sed-native to ASSUME_PROVIDED > > Gary Thomas (2): > libgpg-error: Fix native build on i686 > gst-player: Fix typo > > Jean-Benoit MARTIN (1): > package_manager: RpmPM: Fix scriptlet for rpm 4 > > Joe Slater (1): > nss: generate debug info > > Joshua Lock (1): > systemd: remove unused patches > > Jukka Rissanen (1): > connman: Create connman.service at proper moment > > Jun Zhu (1): > meta/lib/oe/utils.py: Corrected the return value of both_contain() > > Junling Zheng (3): > uclibc: fix undefinition of '_dl_strchr' in libdl.a > elfutils: fix an incorrect patch for 0.161 > less: fix CVE-2014-9488 > > Ken Sharp (2): > udev-cache: Remove unnecessary tar read from stdin > udev-cache: improve error handling > > Khem Raj (4): > bluez4: Fix encrypt symbol namespace collision > libusb-compat: Include sys/types.h in usb.h > libffi: Use proper compiler define for linux platform > ppp: Add extra include dirs > > Koen Kooi (5): > gst-ffmpeg: fix internal-libav builds with inherit autotools-brokensep > gst-ffmpeg: remove bogus patch that leads to build failures > gst-ffmpeg: fix libav-9.patch > libgpg-error 1.18: simplify tupple handling and add armv8b support > strace: fix build for aarch64 > > Krishnanjanappa, Jagadeesh (2): > dpkg: add triplet entry to fix build error for armeb > ghostscript: add objarch.h for armeb > > Li Zhou (5): > xorg-server: Security Advisory - xorg-server - CVE-2015-0255 > libarchive: Security Advisory - libarchive - CVE-2015-2304 > libxfont: Security Advisory - libxfont - CVE-2015-1802 > libxfont: Security Advisory - libxfont - CVE-2015-1803 > libxfont: Security Advisory - libxfont - CVE-2015-1804 > > Mariano Lopez (1): > kexec-tools: Add support for build with x32 ABI in x86_64 > > Mario Domenech Goulart (1): > useradd_base.bbclass: typo fixes (s/scucess/success/) > > Martin Jansa (2): > pango: fix postinst > tzdata: fix postinst > > Matt Madison (1): >
Re: [OE-core] [PATCH 00/70] Proposed changes for fido
Joshua, > -Original Message- > From: Joshua Lock [mailto:joshua.l...@collabora.co.uk] > Sent: Monday, May 11, 2015 11:08 AM > To: Bryan Evenson > Cc: openembedded-core@lists.openembedded.org > Subject: Re: [OE-core] [PATCH 00/70] Proposed changes for fido > > Hi Bryan, > > On Mon, 2015-05-11 at 12:40 +0000, Bryan Evenson wrote: > > > Bryan Evenson (1): > > > util-linux: Add lastb to alternatives > > > > There is a refined version of this patch available that was submitted > > to the mailing list here: > > http://lists.openembedded.org/pipermail/openembedded-core/2015 > > -April/104132.html. It uses PACKAGECONFIG to remove last, lastb and > > the man pages for last and lastb from the util-linux build if 'last' > > is not in PACKAGECONFIG. It also adds 'last' to PACKAGECONFIG by > > default which mimics previous behavior. I'm still a little unclear on > > the patch approval process, so I assume the updated patch would need > > to be accepted into master before being backported into fido? > > Unless the patch is specific to the stable branch we only pull in changes > into a > stable branch once they have been reviewed and accepted into the master > branch. > > Is this change valuable without the refined patch? Or should I pull it until > I can > merge both? It does have value as it stands. It fixes some upgrade cases I was seeing which was forcing me to run opkg with "--force-overwrite" set. The refined patch removes last and lastb from util-linux if someone does not want it there; good to do but not as critical as fixing a package management issue. So in my opinion it'd be worth merging the proposed patch into fido. If there is something more that I need to do to get my updated patch to master? Thanks, Bryan > > Thanks, > > Joshua -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] opinions on enabling busybox's "runit" implementation to control some services?
Robert, > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Robert P. J. Day > Sent: Wednesday, December 14, 2016 5:28 AM > To: OE Core mailing list > Subject: [OE-core] opinions on enabling busybox's "runit" implementation to > control some services? > > > colleague needs "runit" to control one or more services that have > historically > been managed that way, so a couple questions: > > 1) anyone with experience with busybox's implementation of runit? does it > work properly? does it play nicely with others? > I have not, but this last year I was looking into what it'd take to use Busybox's runit as an alternative to SysVinit. I didn't do a complete code comparison, but Busybox's runit seems to be the same as the upstream package minus all the code that is not needed because it is present elsewhere in Busybox. I couldn't figure out how to setup the image to use runit for init before I got pulled onto other tasks. > 2) is runit actually necessary, or would it be easy to migrate said services > off > of runit? > The official runit site has tons of init examples for different services and has a brief explanation on how to change a SysVInit init script to work for runit. I haven't done it myself, but I don't think it'd be that much work to go the other way. > i've never used runit, so have no idea what it is that makes it so > (allegedly) indispensable. if it's easily migrateable, that'd be great. It's small and simple. Start services I parallel, monitor to make sure they are still running, and restart as necessary. Done. I like the idea of its simplicity and I'm interested in seeing if it works as well as it says it does. If you figure out how to get runit as the system's init, I'd love to give it a try myself. Regards, Bryan > > thanks muchly. > > rday > > -- > > == > == > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > == > == > > -- > ___ > 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] libcurl vs. libcurl5 vs. libcurl4
I'm on the dizzy branch and I'm working on updating my build tools to use a
more recent branch. I have an image built using fido and I'm doing some
firmware upgrade testing. I have a package that depends on libcurl and I'm
getting some strange version dependencies that I'm trying to sort out.
In my package recipe I have "RDEPENDS_${PN} =
libcurl" to pull in the runtime depenency on curl. When I build my image using
the dizzy branch, libcurl gets built as libcurl5-7.37.1, but when I build my
image using the fido branch libcurl gets built as libcurl4-7.40.0. As a
result, by checking my package dependencies with "opkg info "
I see that the package dependency has changed from "libcurl5 (>=7.37.1)" to
"libcurl4 (>=7.40.1)".
Any ideas why the package name dropped from libcurl5 to libcurl4? Is this
something that has been fixed in a more recent branch? If I'm reading the
dependencies correctly, opkg should still install libcurl-7.40.0 since my
package depends on libcurl4, correct?
Thanks,
Bryan Evenson
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] libcurl vs. libcurl5 vs. libcurl4
Martin,
> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Friday, February 10, 2017 2:54 PM
> To: Bryan Evenson
> Cc: Openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] libcurl vs. libcurl5 vs. libcurl4
>
> On Fri, Feb 10, 2017 at 03:41:44PM +, Bryan Evenson wrote:
> > I'm on the dizzy branch and I'm working on updating my build tools to use a
> more recent branch. I have an image built using fido and I'm doing some
> firmware upgrade testing. I have a package that depends on libcurl and I'm
> getting some strange version dependencies that I'm trying to sort out.
> >
> > In my package recipe I have "RDEPENDS_${PN} = packages> libcurl" to pull in the runtime depenency on curl. When I build my
> image using the dizzy branch, libcurl gets built as libcurl5-7.37.1, but when
> I
> build my image using the fido branch libcurl gets built as libcurl4-7.40.0.
> As a
> result, by checking my package dependencies with "opkg info
> " I see that the package dependency has changed
> from "libcurl5 (>=7.37.1)" to "libcurl4 (>=7.40.1)".
> >
> > Any ideas why the package name dropped from libcurl5 to libcurl4? Is this
> something that has been fixed in a more recent branch? If I'm reading the
> dependencies correctly, opkg should still install libcurl-7.40.0 since my
> package depends on libcurl4, correct?
>
> See --enable-soname-bump option in curl.
>
> This change in oe-core:
> commit 49c848018484827c433e1bcf9c63416640456f3e
> Author: Khem Raj
> Date: Tue Apr 28 22:34:22 2015 -0700
> Subject: curl: Fix wrong assumption about sizeof off_t on largefile
> systems
>
> This issue was reported on poky ml as well see
> https://lists.yoctoproject.org/pipermail/poky/2013-
> December/009435.html
>
> Causes this difference in curl_config.h between Dizzy and Fido:
> diff 7.40.0-r0-dizzy/build/lib/curl_config.h
> 7.40.0-r0-fido/build/lib/curl_config.h
> 878c877
> < #define SIZEOF_OFF_T 4
> ---
> > #define SIZEOF_OFF_T 8
> Which in turn causes curl's configure script to stop bumping the SONAME
> version.
>
> That's why newer curl 7.40.1 produces libcurl4 while older 7.37.1 produced
> libcurl5.
Thanks for the explanation. I also verified that the package dependencies
worked correctly. My updated package now depends on libcurl4 instead of
libcurl5, so the new package was correctly installed. In my case I'll avoid
doing any specific patch to keep the SONAME version the same if firmware
upgrade works as expected.
Thanks,
Bryan
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-image upgrades
For one project I'm using an Atmel AT91SAM9G25 processor, and I started when support for the chip wasn't fully integrated into the mainline kernel. As a result, I was using Atmel's Linux fork. Support has been in the mainline kernel for a while now, so in the middle of doing other updates I plan on switching to using one of the mainline LTS releases. I'm using the kernel recipe in the meta-sunxi layer as an example (located here: https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-kernel/linux/linux_4.4.40.bb). I also plan on keeping more up to date on releases. However, due to the package naming for the kernel images, the RREPLACES/RCONFLICTS statements for firmware upgrade for this recipe is getting ridiculous. I'm currently building for kernel version 4.1.38, and here's what I have so far to handle all previous cases: RREPLACES_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-at91" RCONFLICTS_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-at91" If it makes a difference, I'm using opkg for a package manager. Since the kernel version is in the package name, I'm assuming that if I do keep going forward and relatively up to date with LTS release, I'll have to start adding "kernel-image-4.1.38 kernel-image-4.1.39 kernel-image 4.1.40 " to the RREPLACES/RCONFLICTS so opkg will upgrade the kernel. Is there a better way to do this? I've tried using some wildcards in the package names without any success. Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-image upgrades
Khem,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Khem Raj
> Sent: Wednesday, February 15, 2017 5:17 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-
> image upgrades
>
>
>
> On 2/15/17 1:54 PM, Bryan Evenson wrote:
> > For one project I'm using an Atmel AT91SAM9G25 processor, and I started
> when support for the chip wasn't fully integrated into the mainline kernel.
> As a result, I was using Atmel's Linux fork. Support has been in the mainline
> kernel for a while now, so in the middle of doing other updates I plan on
> switching to using one of the mainline LTS releases. I'm using the kernel
> recipe in the meta-sunxi layer as an example (located here:
> https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-
> kernel/linux/linux_4.4.40.bb). I also plan on keeping more up to date on
> releases. However, due to the package naming for the kernel images, the
> RREPLACES/RCONFLICTS statements for firmware upgrade for this recipe is
> getting ridiculous. I'm currently building for kernel version 4.1.38, and
> here's
> what I have so far to handle all previous cases:
> >
> > RREPLACES_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-
> yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> at91"
> > RCONFLICTS_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-
> yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> at91"
> >
> > If it makes a difference, I'm using opkg for a package manager. Since the
> kernel version is in the package name, I'm assuming that if I do keep going
> forward and relatively up to date with LTS release, I'll have to start adding
> "kernel-image-4.1.38 kernel-image-4.1.39 kernel-image 4.1.40 " to the
> RREPLACES/RCONFLICTS so opkg will upgrade the kernel.
> >
> > Is there a better way to do this? I've tried using some wildcards in the
> package names without any success.
> >
>
> you can increment PE
I tried that and it didn't make a difference; without the specific previous
package names listed in RDEPENDS/RCONFLICTS, opkg does not recognize the new
kernel-image as an upgrade. From my understanding PE only affects the version
number, not the package name. In this case, since KERNEL_VERSION is part of
the package name, opkg does not immediately recognize kernel-image-4.1.38 as an
upgrade for kernel-image-3.10.0-at91. Even though both packages provide
"kernel-image", that's not what opkg is looking at when it checks for upgrades.
Could someone explain to me why KERNEL_VERSION is even in the package name to
begin with? I'm tempted to remove the following two lines from kernel.bbclass:
PKG_kernel-image =
"kernel-image-${@legitimize_package_name('${KERNEL_VERSION}')}"
PKG_kernel-base = "kernel-${@legitimize_package_name('${KERNEL_VERSION}')}"
However, I don't know if this will break something else that would cause an
even bigger problem.
Thanks,
Bryan
>
> > Thanks,
> > Bryan
> >
> --
> ___
> 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] Suggested RREPLACES/RCONFLICTS for easier kernel-image upgrades
Andreas,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Andreas Oberritter
> Sent: Friday, February 17, 2017 5:46 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier kernel-
> image upgrades
>
> On Thu, 16 Feb 2017 13:43:03 +
> Bryan Evenson wrote:
>
> > Khem,
> >
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On
> Behalf
> > > Of Khem Raj
> > > Sent: Wednesday, February 15, 2017 5:17 PM
> > > To: openembedded-core@lists.openembedded.org
> > > Subject: Re: [OE-core] Suggested RREPLACES/RCONFLICTS for easier
> kernel-
> > > image upgrades
> > >
> > >
> > >
> > > On 2/15/17 1:54 PM, Bryan Evenson wrote:
> > > > For one project I'm using an Atmel AT91SAM9G25 processor, and I
> started
> > > when support for the chip wasn't fully integrated into the mainline
> kernel.
> > > As a result, I was using Atmel's Linux fork. Support has been in the
> mainline
> > > kernel for a while now, so in the middle of doing other updates I plan on
> > > switching to using one of the mainline LTS releases. I'm using the kernel
> > > recipe in the meta-sunxi layer as an example (located here:
> > > https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-
> > > kernel/linux/linux_4.4.40.bb). I also plan on keeping more up to date on
> > > releases. However, due to the package naming for the kernel images,
> the
> > > RREPLACES/RCONFLICTS statements for firmware upgrade for this recipe
> is
> > > getting ridiculous. I'm currently building for kernel version 4.1.38, and
> here's
> > > what I have so far to handle all previous cases:
> > > >
> > > > RREPLACES_kernel-image = "kernel-image (<= 4.1) kernel-image-3.6.9-
> > > yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> > > at91"
> > > > RCONFLICTS_kernel-image = "kernel-image (<= 4.1) kernel-image-
> 3.6.9-
> > > yocto-standard kernel-image-3.10.0-yocto-standard kernel-image-3.10.0-
> > > at91"
> > > >
> > > > If it makes a difference, I'm using opkg for a package manager. Since
> the
> > > kernel version is in the package name, I'm assuming that if I do keep
> going
> > > forward and relatively up to date with LTS release, I'll have to start
> > > adding
> > > "kernel-image-4.1.38 kernel-image-4.1.39 kernel-image 4.1.40 " to the
> > > RREPLACES/RCONFLICTS so opkg will upgrade the kernel.
> > > >
> > > > Is there a better way to do this? I've tried using some wildcards in
> > > > the
> > > package names without any success.
> > > >
> > >
> > > you can increment PE
> >
> > I tried that and it didn't make a difference; without the specific previous
> package names listed in RDEPENDS/RCONFLICTS, opkg does not recognize
> the new kernel-image as an upgrade. From my understanding PE only
> affects the version number, not the package name. In this case, since
> KERNEL_VERSION is part of the package name, opkg does not immediately
> recognize kernel-image-4.1.38 as an upgrade for kernel-image-3.10.0-at91.
> Even though both packages provide "kernel-image", that's not what opkg is
> looking at when it checks for upgrades.
> >
> > Could someone explain to me why KERNEL_VERSION is even in the
> package name to begin with? I'm tempted to remove the following two lines
> from kernel.bbclass:
> >
> > PKG_kernel-image = "kernel-image-
> ${@legitimize_package_name('${KERNEL_VERSION}')}"
> > PKG_kernel-base = "kernel-
> ${@legitimize_package_name('${KERNEL_VERSION}')}"
> >
> > However, I don't know if this will break something else that would cause an
> even bigger problem.
>
> That's what I do in my kernel recipes:
>
> # By default, kernel.bbclass modifies package names to allow multiple
> kernels
> # to be installed in parallel. We revert this change and rprovide the
> versioned
> # package names instead, to allow only one kernel to be installed.
> PKG_kernel = "kernel"
> RPROVIDES_kernel = "kernel-${KERNEL_VERSION_PKG_NAME}"
> PKG_kernel-base = "
Re: [OE-core] how to *securely* do a remote install of an OE image?
Robert,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Robert P. J. Day
> Sent: Tuesday, February 28, 2017 10:20 AM
> To: Patrick Ohly
> Cc: OE Core mailing list
> Subject: Re: [OE-core] how to *securely* do a remote install of an OE image?
>
> On Tue, 28 Feb 2017, Patrick Ohly wrote:
>
> > For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
> >
> > INHERIT += "rootfsdebugfiles"
> > ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
> ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
> >
> > This copies my id_rsa.pub into authorized_keys and thus let's me log
> > into images that I create via ssh.
>
> this has definite potential, but i'm about to check whether the
> person/entity that builds the image vs. the person/entity that does the
> install vs. the person that eventually logs into the new system to finish
> setting up could potentially be different.
>
> there's a *possibility* that remote installation might be done by a
> distributor, after which someone else might need to do the first login to
> finish the setup, which would complicate things immensely.
Are you talking about burning the initial image or firmware upgrade? If you're
talking about firmware upgrade, another possibility is that you could flip the
direction of access. Instead of remotely logging into each target system, have
the target systems remotely login to a centralized server. That's the approach
we took. We burn the systems with the latest image, and then when we assign
them a serial number the system is given a set of SSH keys specific to that
serial number. That set of SSH keys is then used to access the centralized
server and obtain the latest firmware. With this method there's no need to
login to the target system, so you can lock it down as much as you want.
Regards,
Bryan
>
> i don't know that this is what will happen, but i'm about to run off and ask
> about possibilities.
>
> rday
>
> --
>
> ==
> ==
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
> ==
> ==
>
> --
> ___
> 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] util-linux: Multiple alternatives issues preventing clean upgrades
I am using opkg for package management, and before moving to a more recent branch (currently on dizzy) I'm doing some firmware upgrade tests to make sure I have a clean upgrade process. For my testing I flash an image using our current production image and then do firmware upgrade from the command line by doing "opkg update; opkg upgrade --download-only; opkg upgrade" and checking what errors pop up. I am currently testing upgrading to the jethro branch and I am seeing some errors in regards to util-linux. I see the following errors during upgrade: * check_data_file_clashes: Package util-linux-sulogin wants to install file /sbin/sulogin.util-linux But that file is already provided by package * util-linux update-alternatives: Error: cannot register alternative readprofile to /usr/sbin/readprofile since it is already registered to /sbin/readprofile * pkg_run_script: package "util-linux-readprofile" postinst script returned status 1. * opkg_configure: util-linux-readprofile.postinst returned 1. The first error I traced down to being related to this commit: http://git.openembedded.org/openembedded-core/commit/meta/recipes-core/util-linux?h=jethro&id=4bde182ed236243547929dd98763f1c09eddd097 The second error I traced down to being related to this commit: http://git.openembedded.org/openembedded-core/commit/meta/recipes-core/util-linux?h=jethro&id=43424eb3c8bf03a2f9ec331b78dd4040dd39eacd I know this is all related to alternatives, but that's about as far as my knowledge extends in this area. Yes, everything is running okay but I'd like to clean up problems like this if possible. Does anyone have any suggestions on what would need to change in the util-linux recipe to clean up these errors? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] util-linux: Multiple alternatives issues preventing clean upgrades
I've made some progress but I'm afraid I still have a few more questions. > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Bryan Evenson > Sent: Wednesday, March 01, 2017 9:22 AM > To: Openembedded-core@lists.openembedded.org > Subject: [OE-core] util-linux: Multiple alternatives issues preventing clean > upgrades > > I am using opkg for package management, and before moving to a more > recent branch (currently on dizzy) I'm doing some firmware upgrade tests to > make sure I have a clean upgrade process. For my testing I flash an image > using our current production image and then do firmware upgrade from the > command line by doing "opkg update; opkg upgrade --download-only; opkg > upgrade" and checking what errors pop up. I am currently testing upgrading > to the jethro branch and I am seeing some errors in regards to util-linux. I > see the following errors during upgrade: > > * check_data_file_clashes: Package util-linux-sulogin wants to install file > /sbin/sulogin.util-linux > But that file is already provided by package * util-linux > update-alternatives: Error: cannot register alternative readprofile to > /usr/sbin/readprofile since it is already registered to /sbin/readprofile > * pkg_run_script: package "util-linux-readprofile" postinst script returned > status 1. > * opkg_configure: util-linux-readprofile.postinst returned 1. > > The first error I traced down to being related to this commit: > http://git.openembedded.org/openembedded-core/commit/meta/recipes- > core/util-linux?h=jethro&id=4bde182ed236243547929dd98763f1c09eddd097 > I added the following line to util-linux.inc: RREPLACES_util-linux-sulogin = "util-linux" After adding this line, then opkg acknowledged that util-linux-sulogin replaced the files that were previously owned by util-linux and the error went away. Looking at the commit log on master in the util-linux directory, it looks like util-linux is being split up into even more packages. Should the proper RREPLACES be added for each package that was split out? > The second error I traced down to being related to this commit: > http://git.openembedded.org/openembedded-core/commit/meta/recipes- > core/util-linux?h=jethro&id=43424eb3c8bf03a2f9ec331b78dd4040dd39eacd > >From the command line on the target I entered the line: update-alternatives --remove readprofile /sbin/readprofile After that I issued "opkg upgrade" again and the postinstall script for util-linux-readprofile finished without issue. I'm a little baffled why the old link wasn't removed. Is there something that needs to be added to the postinstall script to remove the old link prior to adding the new one? Thanks, Bryan > I know this is all related to alternatives, but that's about as far as my > knowledge extends in this area. Yes, everything is running okay but I'd like > to > clean up problems like this if possible. Does anyone have any suggestions on > what would need to change in the util-linux recipe to clean up these errors? > > Thanks, > Bryan > -- > ___ > 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] Larger kernel with gcc-6.2 than gcc-5.x
All, I'm on poky/krogoth and I am in the process of moving to poky/morty on an Atmel AT91SAM9G25 platform (arm926ejste architecture). On the first try booting with my image built under morty, I noticed that the kernel image was larger. I've done some more testing and I see that the rest of the image is the same size, just the kernel got larger. I'm using a custom kernel, so the kernel image is using the same commit, patches and configuration. I decided to try building with both gcc-6.2 and gcc-5.4 and see what the size differences were. My results: Kernel size under poky/morty with gcc-6.2: 3158616 bytes Kernel size under poky/morty with gcc-5.4: 3141312 bytes Kernel size under poky/krogoth with gcc-5.3: 3144200 bytes It's not a huge change and I have the space for the larger kernel. However, I was curious if this was a sign that something else changed that I should be concerned about. Has anyone else seen gcc-6.2 producing larger binaries? If so, does anyone know why? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] eudev: opkg not automatically upgrading from udev to eudev
I have an image based on core-image-minimal that uses sysvinit for init and opkg for package management. I am doing some upgrade testing and I see an issue with eudev. I am testing upgrading an image that was built under dizzy to my latest image built under morty. I'm first testing that all the correct packages and new dependencies are correctly being identified for upgrade by running "opkg update; opkg upgrade --download-only" from the command line and comparing what is in the opkg cache directory with what was available. All packages except eudev and udev-cache are being downloaded for upgrade. I ran the opkg upgrade again with the -V4 option for additional debug output Here's what I saw in one section regarding udev: pkg_hash_fetch_best_installation_candidate: Best installation candidate for udev: pkg_hash_fetch_best_installation_candidate: apkg=udev nprovides=2. pkg_hash_fetch_best_installation_candidate: Adding eudev to providers. pkg_hash_fetch_best_installation_candidate: Adding udev to providers. pkg_hash_fetch_best_installation_candidate: eudev arch=armv5e arch_priority=41 version=3.2. pkg_hash_fetch_best_installation_candidate: udev arch=arm926ejste arch_priority=51 version=182. pkg_hash_fetch_best_installation_candidate: Candidate: udev 182. pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for apkg=udev: pkg_hash_fetch_best_installation_candidate: eudev 3.2 armv5e pkg_hash_fetch_best_installation_candidate: udev 182 arm926ejste opkg_upgrade_pkg: Comparing visible versions of pkg udev: 182-r9.9 is installed 182-r9.9 is available 0 was comparison result opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to date. I'm assuming the problem is that udev is version 182 and eudev is version 3.2 and that opkg doesn't think udev needs to be upgraded. Is there an RDEPENDS that needs to be added somewhere so opkg sees that it needs to upgrade udev to eudev? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] eudev: opkg not automatically upgrading from udev to eudev
All, > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf > Of Bryan Evenson > Sent: Tuesday, May 16, 2017 2:01 PM > To: Openembedded-core@lists.openembedded.org > Subject: [OE-core] eudev: opkg not automatically upgrading from udev to > eudev > > > I have an image based on core-image-minimal that uses sysvinit for init and > opkg for package management. I am doing some upgrade testing and I see > an issue with eudev. I am testing upgrading an image that was built under > dizzy to my latest image built under morty. I'm first testing that all the > correct > packages and new dependencies are correctly being identified for upgrade > by running "opkg update; opkg upgrade --download-only" from the > command line and comparing what is in the opkg cache directory with what > was available. All packages except eudev and udev-cache are being > downloaded for upgrade. > > I ran the opkg upgrade again with the -V4 option for additional debug output > Here's what I saw in one section regarding udev: > > pkg_hash_fetch_best_installation_candidate: Best installation candidate for > udev: > pkg_hash_fetch_best_installation_candidate: apkg=udev nprovides=2. > pkg_hash_fetch_best_installation_candidate: Adding eudev to providers. > pkg_hash_fetch_best_installation_candidate: Adding udev to providers. > pkg_hash_fetch_best_installation_candidate: eudev arch=armv5e > arch_priority=41 version=3.2. > pkg_hash_fetch_best_installation_candidate: udev arch=arm926ejste > arch_priority=51 version=182. > pkg_hash_fetch_best_installation_candidate: Candidate: udev 182. > pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for > apkg=udev: > pkg_hash_fetch_best_installation_candidate: eudev 3.2 armv5e > pkg_hash_fetch_best_installation_candidate: udev 182 arm926ejste > opkg_upgrade_pkg: Comparing visible versions of pkg udev: > 182-r9.9 is installed > 182-r9.9 is available > 0 was comparison result > opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to date. > > I'm assuming the problem is that udev is version 182 and eudev is version 3.2 > and that opkg doesn't think udev needs to be upgraded. Is there an > RDEPENDS that needs to be added somewhere so opkg sees that it needs to > upgrade udev to eudev? I made some changes and now both eudev and udev-cache are being pulled in on upgrade. However, I'd like a second opinion that what I did was reasonable. First, I created eudev_%.bbappend in my private layer and added "PE = "1"" to the bbappend. Since the numbering scheme changed between udev and eudev, I figured this was a reasonable move. This brought the update udev-cache in for upgrade, but not eudev. In my private layer, I also have an image version number package. I added eudev to the RDEPENDS list for this package since my image, which now has linux version 4.4, does depend on eudev. Does this sound reasonable? Is there a better way to do the same thing? Thanks, Bryan > > Thanks, > Bryan > -- > ___ > 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] eudev: opkg not automatically upgrading from udev to eudev
All, > -Original Message- > From: Bryan Evenson > Sent: Wednesday, May 17, 2017 11:27 AM > To: Bryan Evenson ; Openembedded- > c...@lists.openembedded.org > Subject: RE: eudev: opkg not automatically upgrading from udev to eudev > > All, > > > -Original Message- > > From: openembedded-core-boun...@lists.openembedded.org > > [mailto:openembedded-core-boun...@lists.openembedded.org] On > Behalf Of > > Bryan Evenson > > Sent: Tuesday, May 16, 2017 2:01 PM > > To: Openembedded-core@lists.openembedded.org > > Subject: [OE-core] eudev: opkg not automatically upgrading from udev > > to eudev > > > > > > I have an image based on core-image-minimal that uses sysvinit for > > init and opkg for package management. I am doing some upgrade testing > > and I see an issue with eudev. I am testing upgrading an image that > > was built under dizzy to my latest image built under morty. I'm first > > testing that all the correct packages and new dependencies are > > correctly being identified for upgrade by running "opkg update; opkg > > upgrade --download-only" from the command line and comparing what is > > in the opkg cache directory with what was available. All packages > > except eudev and udev-cache are being downloaded for upgrade. > > > > I ran the opkg upgrade again with the -V4 option for additional debug > > output Here's what I saw in one section regarding udev: > > > > pkg_hash_fetch_best_installation_candidate: Best installation > > candidate for > > udev: > > pkg_hash_fetch_best_installation_candidate: apkg=udev nprovides=2. > > pkg_hash_fetch_best_installation_candidate: Adding eudev to providers. > > pkg_hash_fetch_best_installation_candidate: Adding udev to providers. > > pkg_hash_fetch_best_installation_candidate: eudev arch=armv5e > > arch_priority=41 version=3.2. > > pkg_hash_fetch_best_installation_candidate: udev arch=arm926ejste > > arch_priority=51 version=182. > > pkg_hash_fetch_best_installation_candidate: Candidate: udev 182. > > pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for > > apkg=udev: > > pkg_hash_fetch_best_installation_candidate: eudev 3.2 armv5e > > pkg_hash_fetch_best_installation_candidate: udev 182 arm926ejste > > opkg_upgrade_pkg: Comparing visible versions of pkg udev: > > 182-r9.9 is installed > > 182-r9.9 is available > > 0 was comparison result > > opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to date. > > > > I'm assuming the problem is that udev is version 182 and eudev is > > version 3.2 and that opkg doesn't think udev needs to be upgraded. Is > > there an RDEPENDS that needs to be added somewhere so opkg sees that > > it needs to upgrade udev to eudev? > > I made some changes and now both eudev and udev-cache are being pulled > in on upgrade. However, I'd like a second opinion that what I did was > reasonable. > > First, I created eudev_%.bbappend in my private layer and added "PE = "1"" > to the bbappend. Since the numbering scheme changed between udev and > eudev, I figured this was a reasonable move. This brought the update udev- > cache in for upgrade, but not eudev. In my private layer, I also have an > image > version number package. I added eudev to the RDEPENDS list for this > package since my image, which now has linux version 4.4, does depend on > eudev. > > Does this sound reasonable? Is there a better way to do the same thing? Things didn't go as well when I did the upgrade. I attempted the upgrade with "opkg upgrade" (no options) and everything worked until then end. Then I got a bunch of error messages like the following: * check_data_file_clashes: Package eudev wants to install file /lib/udev/scsi_id But that file is already provided by package * udev After the upgrade neither udev nor eudev were installed on my system. I've solved similar problems in the past by adding RCONFLICTS/RREPLACES listings in the new packages recipe, but since eudev is listed as providing udev I'm not sure what is appropriate here. Should there be RCONFLICTS/RREPLACES in the eudev recipe, or is there another solution to this problem? Thanks, Bryan > > Thanks, > Bryan > > > > > Thanks, > > Bryan > > -- > > ___ > > 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] eudev: opkg not automatically upgrading from udev to eudev
Martin, Thanks for the pointers. I think I finally have it working correctly. I added RPROVIDES/RCONFLICTS/RREPLACES in my eudev bbappend to state it replaces udev. I also needed to set PE = 1 for udev-cache. Since udev-cache didn’t change the package name, I can’t say it RCONFLICTS/RREPLACES itself. Thanks, Bryan From: Martin Jansa [mailto:martin.ja...@gmail.com] Sent: Wednesday, May 17, 2017 12:18 PM To: Bryan Evenson Cc: Openembedded-core@lists.openembedded.org Subject: Re: [OE-core] eudev: opkg not automatically upgrading from udev to eudev Isn't it enough to set RPROVIDES/RCONFLICTS/RREPLACES combo to say that eudev really replaces old udev even when the package version is lower. This used to fix such upgrade-path issues before, but I've stopped testing them long time ago. On Wed, May 17, 2017 at 5:26 PM, Bryan Evenson mailto:beven...@melinkcorp.com>> wrote: All, > -Original Message- > From: > openembedded-core-boun...@lists.openembedded.org<mailto:openembedded-core-boun...@lists.openembedded.org> > [mailto:openembedded-core-boun...@lists.openembedded.org<mailto:openembedded-core-boun...@lists.openembedded.org>] > On Behalf > Of Bryan Evenson > Sent: Tuesday, May 16, 2017 2:01 PM > To: > Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org> > Subject: [OE-core] eudev: opkg not automatically upgrading from udev to > eudev > > > I have an image based on core-image-minimal that uses sysvinit for init and > opkg for package management. I am doing some upgrade testing and I see > an issue with eudev. I am testing upgrading an image that was built under > dizzy to my latest image built under morty. I'm first testing that all the > correct > packages and new dependencies are correctly being identified for upgrade > by running "opkg update; opkg upgrade --download-only" from the > command line and comparing what is in the opkg cache directory with what > was available. All packages except eudev and udev-cache are being > downloaded for upgrade. > > I ran the opkg upgrade again with the -V4 option for additional debug output > Here's what I saw in one section regarding udev: > > pkg_hash_fetch_best_installation_candidate: Best installation candidate for > udev: > pkg_hash_fetch_best_installation_candidate: apkg=udev nprovides=2. > pkg_hash_fetch_best_installation_candidate: Adding eudev to providers. > pkg_hash_fetch_best_installation_candidate: Adding udev to providers. > pkg_hash_fetch_best_installation_candidate: eudev arch=armv5e > arch_priority=41 version=3.2. > pkg_hash_fetch_best_installation_candidate: udev arch=arm926ejste > arch_priority=51 version=182. > pkg_hash_fetch_best_installation_candidate: Candidate: udev 182. > pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for > apkg=udev: > pkg_hash_fetch_best_installation_candidate: eudev 3.2 armv5e > pkg_hash_fetch_best_installation_candidate: udev 182 arm926ejste > opkg_upgrade_pkg: Comparing visible versions of pkg udev: > 182-r9.9 is installed > 182-r9.9 is available > 0 was comparison result > opkg_upgrade_pkg: Package udev (182-r9.9) installed in root is up to date. > > I'm assuming the problem is that udev is version 182 and eudev is version 3.2 > and that opkg doesn't think udev needs to be upgraded. Is there an > RDEPENDS that needs to be added somewhere so opkg sees that it needs to > upgrade udev to eudev? I made some changes and now both eudev and udev-cache are being pulled in on upgrade. However, I'd like a second opinion that what I did was reasonable. First, I created eudev_%.bbappend in my private layer and added "PE = "1"" to the bbappend. Since the numbering scheme changed between udev and eudev, I figured this was a reasonable move. This brought the update udev-cache in for upgrade, but not eudev. In my private layer, I also have an image version number package. I added eudev to the RDEPENDS list for this package since my image, which now has linux version 4.4, does depend on eudev. Does this sound reasonable? Is there a better way to do the same thing? Thanks, Bryan > > Thanks, > Bryan > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org<mailto: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] [oe-core][PATCH] eudev: Add RREPLACES/RCONFLICTS/PE for udev migration
Commit e5e540513665105b963262c2eaf33f197a0a36c replaced
udev with eudev on system's using sysvinit for init.
For clean upgrades, some extra variables are needed to
appropriately mark eudev as an update to udev.
* Add RREPLACES/RCONFLICTS for udev so udev is removed on
upgrade and the new files are replaced.
* Commit ca2948a1d4e408bccdfcd43fc8833ea356a74bca added
RREPLACES/RCONFLICTS for udev-utils when the udev-utils
package was merged into udev. Inherit this RREPLACES
and RCONFLICTS so older systems with udev-utils will
still upgrade cleanly.
* The version numbering changed with eudev from a single
version number to an x.y.z format with a lower version
number. The RREPLACES/RCONFLICTS takes care of upgrading
udev to eudev, but both eudev and udev add the udev-cache
package. Since udev-cache can't replace/conflict with
itself, the PE needs to be incremented for udev-cache
to upgrade.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/udev/eudev_3.2.1.bb | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/recipes-core/udev/eudev_3.2.1.bb
b/meta/recipes-core/udev/eudev_3.2.1.bb
index bdfb544..539945e 100644
--- a/meta/recipes-core/udev/eudev_3.2.1.bb
+++ b/meta/recipes-core/udev/eudev_3.2.1.bb
@@ -8,6 +8,8 @@ DEPENDS = "glib-2.0 glib-2.0-native gperf-native kmod
libxslt-native util-linux"
PROVIDES = "udev"
+PE = "1"
+
SRC_URI =
"https://github.com/gentoo/${BPN}/archive/v${PV}.tar.gz;downloadfilename=${BP}.tar.gz
\
file://0014-Revert-rules-remove-firmware-loading-rules.patch \
file://Revert-udev-remove-userspace-firmware-loading-suppor.patch \
@@ -86,6 +88,10 @@ RRECOMMENDS_${PN} += "udev-cache"
RPROVIDES_${PN} = "hotplug udev"
RPROVIDES_eudev-hwdb += "udev-hwdb"
+RCONFLICTS_${PN} += "udev udev-utils"
+
+RREPLACES_${PN} += "udev udev-utils"
+
python () {
if bb.utils.contains ('DISTRO_FEATURES', 'systemd', True, False, d):
raise bb.parse.SkipPackage("'systemd' in DISTRO_FEATURES")
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] php: pyro: php fails to compile under pyro with empty PACKAGECONFIG
I am on poky/morty and I am doing some test builds to attempt to stay up to
date with the latest branches. I am having issues building php. For my build,
I don't want any of the PACKAGECONFIG features and I add curl support, so I
have a bbappend with the following:
DEPENDS += " \
curl \
"
EXTRA_OECONF += " \
--with-curl=${STAGING_LIBDIR}/.. \
"
PACKAGECONFIG = ""
This builds without error under morty, but under pyro I get the following
errors:
| ERROR: oe_runmake failed
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
ext/sqlite3/libsqlite/sqlite3.o: undefined reference to symbol
'dlsym@@GLIBC_2.4'
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libdl.so.2:
error adding symbols: DSO missing from command line
| collect2: error: ld returned 1 exit status
| make: *** [sapi/cgi/php-cgi] Error 1
| make: *** Waiting for unfinished jobs
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
ext/sqlite3/libsqlite/sqlite3.o: undefined reference to symbol
'dlsym@@GLIBC_2.4'
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libdl.so.2:
error adding symbols: DSO missing from command line
| collect2: error: ld returned 1 exit status
| make: *** [sapi/cli/php] Error 1
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
ext/sqlite3/libsqlite/sqlite3.o: undefined reference to symbol
'dlsym@@GLIBC_2.4'
|
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libdl.so.2:
error adding symbols: DSO missing from command line
| collect2: error: ld returned 1 exit status
| make: *** [sapi/fpm/php-fpm] Error 1
| ERROR: Function failed: do_compile (log file is located at
/<...>/build/tmp/work/armv5e-poky-linux-gnueabi/php/5.6.26-r0/temp/log.do_compile.28830)
NOTE: recipe php-5.6.26-r0: task do_compile: Failed
I get the same error regardless of whether I build version 5.6.26 or version
7.1.0. What I find odd with this error is that it is failing when loading
symbols for sqlite3, but I explicitly remove sqlite3 from PACKAGECONFIG. If I
use the default PACKAGECONFIG settings, then php builds without error. Has
anyone else seen similar errors?
Thanks,
Bryan
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] multiconfig: Build breaks parsing recipes for other config layer
I'm testing a new board with a BSP that is setup on the gatesgarth branch.
I've been able to build and load the demo images for this board. I'm now
trying to use multiconfig to build images for my old board and my new board.
So far the build hasn't got past parsing recipes and I'm wondering what I'm
doing wrong.
For my setup, I have two separate layers for the two different boards. Each
layer has its own MACHINE and DISTRO definitions. I setup the multiconfig
files as follows:
conf/local.conf:
Added the following line:
BBMULTICONFIG = "configA configB"
conf/multiconfig/configA.conf: (config for old board)
MACHINE = "machineA"
TMPDIR = "${TOPDIR}/tmpConfigA"
DISTRO = "distroA"
conf/multiconfig/configB.conf: (config for new board)
MACHINE = "machineB"
TMPDIR = "${TOPDIR}/tmpConfigB"
DISTRO = "distroB"
If I try building the old image by doing:
bitbake mc:configA:image-nameA
I get errors while parsing the files. It complains about a Network Manager
bbappend in layer B that uses variables that depends on MACHINE being set to
"machineB". The image for configA does not use Network Manager. I also tried
removing the MACHINE and DISTRO settings from local.conf to make sure the
multiconfig settings are used, but then I get an error that MACHINE has not
been set.
Does layerB need something added to it so parsing ignores recipes in this layer
when they aren't needed? Or do the recipes need to change so they build for
other machines?
Thanks,
Bryan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177808):
https://lists.openembedded.org/g/openembedded-core/message/177808
Mute This Topic: https://lists.openembedded.org/mt/97276005/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] multiconfig: Build breaks parsing recipes for other config layer
Mikko and Joshua,
Thanks for the guidance. I tried using BBMASK and that wasn't working for me.
After a little digging I figured out that the BSP for this new board is based
on an old enough version of gatesgarth that it doesn't have the patch for
BBMASK multiconfig support.
I've been looking at the meta-ti layer for an example of how to use distro
overrides to set variables in recipes selectively based on the distro. The
build has been getting further as I update the recipes one at a time.
I may give the BBFILES filtering by different distro variables a try. I think
I can see a way I can set DISTRO_CODENAME in each multiconfig conf file that
will set it up to ignore the layers I want it to ignore for each config.
Either way, I think I'll be with the company that created the BSP on possible
ways to make their BSP portable for multiconfig setups.
Thanks,
Bryan
> -Original Message-
> From: Mikko Rapeli
> Sent: Tuesday, February 28, 2023 2:06 AM
> To: Joshua Watt
> Cc: Bryan Evenson ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] multiconfig: Build breaks parsing recipes for other
> config layer
>
> Hi,
>
> On Mon, Feb 27, 2023 at 03:03:48PM -0600, Joshua Watt wrote:
> >
> > On 2/27/23 14:35, Bryan Evenson wrote:
> > > I'm testing a new board with a BSP that is setup on the gatesgarth branch.
> I've been able to build and load the demo images for this board. I'm now
> trying to use multiconfig to build images for my old board and my new board.
> So far the build hasn't got past parsing recipes and I'm wondering what I'm
> doing wrong.
> > >
> > > For my setup, I have two separate layers for the two different boards.
> Each layer has its own MACHINE and DISTRO definitions. I setup the
> multiconfig files as follows:
> > >
> > > conf/local.conf:
> > > Added the following line:
> > > BBMULTICONFIG = "configA configB"
> > >
> > > conf/multiconfig/configA.conf: (config for old board) MACHINE =
> > > "machineA"
> > > TMPDIR = "${TOPDIR}/tmpConfigA"
> > > DISTRO = "distroA"
> > >
> > > conf/multiconfig/configB.conf: (config for new board) MACHINE =
> > > "machineB"
> > > TMPDIR = "${TOPDIR}/tmpConfigB"
> > > DISTRO = "distroB"
> > >
> > > If I try building the old image by doing:
> > > bitbake mc:configA:image-nameA
> > >
> > > I get errors while parsing the files. It complains about a Network
> Manager bbappend in layer B that uses variables that depends on MACHINE
> being set to "machineB". The image for configA does not use Network
> Manager. I also tried removing the MACHINE and DISTRO settings from
> local.conf to make sure the multiconfig settings are used, but then I get an
> error that MACHINE has not been set.
> > >
> > > Does layerB need something added to it so parsing ignores recipes in this
> layer when they aren't needed? Or do the recipes need to change so they
> build for other machines?
> >
> > When you use multiconfig, all of you layers need to parse for all
> > configurations (although this is generally good layer practice in
> > general, not just when using multiconfig). Usually this involves
> > writing the recipes to use overrides where appropriate
> >
> >
> > Although, if you _really_ don't want to do that, the BBMASK variable
> > (https://docs.yoctoproject.org/ref-manual/variables.html#term-BBMASK)
> > can now be set per-multiconfig so you can have layerA mask out layerB
> > recipes and vice-versa.
>
> Another way to have distro, machine, version etc specific bbappends and
> recipes in layers is to use DISTRO, MACHINE, DISTRO_CODENAME etc
> variables in BBFILES path. Example layer.conf:
>
> BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
> ${LAYERDIR}/recipes-*/*/*.bbappend \
> ${LAYERDIR}/${DISTRO_CODENAME}-recipes-*/*/*.bb \
> ${LAYERDIR}/${DISTRO_CODENAME}-recipes-*/*/*.bbappend \ "
>
> Then the layer can have kirkstone-recipes* and mickledore-recipes*
> directories for bbappends specific to those branches. This enables supporting
> multiple poky/yocto major versions from a single meta layer branch without
> having recipe version specific bbappends which cause problems when there
> are no recipes matching those versions. Same approach will work with
> DISTRO, MACHINE and other variables.
>
> Cheers,
>
> -Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177834):
https://lists.openembedded.org/g/openembedded-core/message/177834
Mute This Topic: https://lists.openembedded.org/mt/97276005/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [oe-core][PATCH] initscripts: Add RREPLACES for initscripts-functions
Back at commit acaf650aa4d458120038ba431c2d1ea563f90f77
initscripts was split into the initscripts and
initscripts-functions packages. However, no RREPLACES was listed.
When using opkg for package managment, upgrades fail unless
--force-overwrite is specified.
Add an RREPLACES declaration stating that initscripts-functions
replaces initscripts so old system can upgrade without conflicts.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/initscripts/initscripts_1.0.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index f90de6e..c0feca3 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -51,6 +51,7 @@ RDEPENDS_${PN} = "${PN}-functions \
${@bb.utils.contains('DISTRO_FEATURES','selinux','bash','',d)} \
"
FILES_${PN}-functions = "${sysconfdir}/init.d/functions*"
+RREPLACES_${PN}-functions = "${PN}"
ALTERNATIVE_PRIORITY_${PN}-functions = "90"
ALTERNATIVE_${PN}-functions = "functions"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] binutils: compilation error 'unknown pseudo-op: `.l`'
All,
I have a AT91SAM9G25 based system that has been built and works using yocto-2.2
(morty). I am in the process of upgrading my build tools to the latest. The
build image is a custom image that is based off of core-image-minimal with a
few additional packages. I'm using Ubuntu 18.04.06 LTS for my host
environment. I'm up to yocto-2.7.4 (warrior) and I hit some build issues that
I'm looking for some help in solving.
Here is some build configuration details (with details I don't want spread over
the internet removed):
Build Configuration:
BB_VERSION = "1.42.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "at91sam9x5ek"
DISTRO_VERSION = "2.7.4"
TUNE_FEATURES= "arm armv5 thumb dsp"
TARGET_FPU = "soft"
meta-bacnet = "master:49ebde9269e8533a8e4ce9c335addced6bfb79b6"
meta-atmel = "warrior:102d92bfc7bd772387ea89c149d33cc5ebf9179c"
meta-qt5 = "warrior:6310c5c17380ad5e3bdaf1938e025d713066e7ee"
meta
meta-poky
meta-yocto-bsp = "warrior:eb163bd6aa0911a9541702cd12a3df684fe5fbb1"
meta-oe
meta-networking
meta-python = "warrior:a24acf94d48d635eca668ea34598c6e5c857e3f8"
I'm getting following error when the system is compiling binutils:
In file included from ../../gold/powerpc.cc:43:
../../gold/gc.h:375:1: note: parameter passing for argument of type
'std::vector::iterator' {aka
'__gnu_cxx::__normal_iterator >'} changed in GCC 7.1
}
^
../../gold/gc.h:375:1: note: parameter passing for argument of type
'std::vector::iterator' {aka
'__gnu_cxx::__normal_iterator >'} changed in GCC 7.1
{standard input}: Assembler messages:
{standard input}:347600: Warning: end of file not at end of a line; newline
inserted
{standard input}:347687: Error: unknown pseudo-op: `.l'
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
arm-poky-linux-gnueabi-g++: fatal error: Killed signal terminated program
cc1plus
compilation terminated.
Makefile:1137: recipe for target 'powerpc.o' failed
I have looked through the Git log for meta/recipes-devtools/binutils up through
master HEAD, and I don't see any references to a problem similar to this one.
Has anyone seen a problem like this before? If so, does anyone know how to fix
it?
Thanks,
Bryan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156424):
https://lists.openembedded.org/g/openembedded-core/message/156424
Mute This Topic: https://lists.openembedded.org/mt/85926755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] binutils: compilation error 'unknown pseudo-op: `.l`'
Khem,
> -Original Message-
> From: Khem Raj
> Sent: Tuesday, September 28, 2021 2:41 PM
> To: Bryan Evenson
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] binutils: compilation error 'unknown pseudo-op: `.l`'
>
> On Tue, Sep 28, 2021 at 8:11 AM Bryan Evenson
> wrote:
> >
> > All,
> >
> > I have a AT91SAM9G25 based system that has been built and works using
> yocto-2.2 (morty). I am in the process of upgrading my build tools to the
> latest. The build image is a custom image that is based off of core-image-
> minimal with a few additional packages. I'm using Ubuntu 18.04.06 LTS for my
> host environment. I'm up to yocto-2.7.4 (warrior) and I hit some build issues
> that I'm looking for some help in solving.
> >
> > Here is some build configuration details (with details I don't want spread
> over the internet removed):
> > Build Configuration:
> > BB_VERSION = "1.42.0"
> > BUILD_SYS= "x86_64-linux"
> > NATIVELSBSTRING = "universal"
> > TARGET_SYS = "arm-poky-linux-gnueabi"
> > MACHINE = "at91sam9x5ek"
> > DISTRO_VERSION = "2.7.4"
> > TUNE_FEATURES= "arm armv5 thumb dsp"
> > TARGET_FPU = "soft"
> > meta-bacnet =
> "master:49ebde9269e8533a8e4ce9c335addced6bfb79b6"
> > meta-atmel = "warrior:102d92bfc7bd772387ea89c149d33cc5ebf9179c"
> > meta-qt5 = "warrior:6310c5c17380ad5e3bdaf1938e025d713066e7ee"
> > meta
> > meta-poky
> > meta-yocto-bsp =
> "warrior:eb163bd6aa0911a9541702cd12a3df684fe5fbb1"
> > meta-oe
> > meta-networking
> > meta-python =
> "warrior:a24acf94d48d635eca668ea34598c6e5c857e3f8"
> >
> > I'm getting following error when the system is compiling binutils:
> >
> > In file included from ../../gold/powerpc.cc:43:
> > ../../gold/gc.h:375:1: note: parameter passing for argument of type
> > 'std::vector::iterator' {aka
> > '__gnu_cxx::__normal_iterator > std::vector >'} changed in GCC 7.1 } ^
> > ../../gold/gc.h:375:1: note: parameter passing for argument of type
> > 'std::vector::iterator' {aka
> '__gnu_cxx::__normal_iterator long unsigned int> >'} changed in GCC 7.1 {standard input}: Assembler
> messages:
> > {standard input}:347600: Warning: end of file not at end of a line;
> > newline inserted {standard input}:347687: Error: unknown pseudo-op: `.l'
> > {standard input}: Error: open CFI at the end of file; missing
> > .cfi_endproc directive
> > arm-poky-linux-gnueabi-g++: fatal error: Killed signal terminated
> > arm-poky-linux-gnueabi-g++program cc1plus
> > compilation terminated.
> > Makefile:1137: recipe for target 'powerpc.o' failed
> >
> > I have looked through the Git log for meta/recipes-devtools/binutils up
> through master HEAD, and I don't see any references to a problem similar to
> this one. Has anyone seen a problem like this before? If so, does anyone
> know how to fix it?
> >
>
> it seems compiler is out of memory.
That may be what happened. I tried rebuilding a few times and I kept getting
the same error. I read through the release notes for the other releases and I
saw that I would eventually need to add 'ptest' to my DISTRO_FEATURES_remove
list. I did that and rebuilt the image, and it built without issues.
If I see this again in the future, I may need to change the parallel build
settings so there is less building at the same time.
Thanks,
Bryan
>
> > Thanks,
> > Bryan
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156429):
https://lists.openembedded.org/g/openembedded-core/message/156429
Mute This Topic: https://lists.openembedded.org/mt/85926755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] busybox: rm and sed not available during upgrade
All, I have an image that is based off of core-image-minimal that uses opkg for the packaging system. My latest build is on the morty release and I'm working on updating a more recent release. Things are generally working on the dunfell release but I'm having an upgrade problem related to busybox. I'm testing my system upgrade as follows: opkg update opkg --download-only upgrade opkg upgrade When I upgrade in this manner, some commands provided by busybox are not available during the upgrade process. Update-alternatives removes the links to busybox, which on my system then leaves no alternatives for rm and sed. Some other packages, such as util-linux, then attempt to use rm and sed in their upgrade process and are unable to delete the package's old files. At the end of the upgrade process update-alternatives installs all the new links. Busybox upgrades just fine but several packages do not upgrade successfully because certain files could not be removed. I see a commit which looks like it is supposed to fix this situation: https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/busybox/busybox.inc?h=dunfell&id=3a035bd0a06a6ded4d0ce7e35a3bce42245727d2. I've verified this commit is present in my local working copy, and I've verified that the additions from this commit are present in the postinst script for busybox. Does this need to occur at a different point in the upgrade process so rm and sed are available to other packages during upgrade? Thanks, Bryan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157185): https://lists.openembedded.org/g/openembedded-core/message/157185 Mute This Topic: https://lists.openembedded.org/mt/86443182/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Busybox upgrades sometimes fail, especially if there is a major distribution
upgrade and all packages need to be updated. Success is highly dependent
on the package upgrade order.
Commit [1] attempts to ensure a shell is still present by adding an
alternative to /bin/sh if busybox is the only shell. However, if busybox
is not the only shell present and the other shells are upgrading, it may
then be possible that all shells will be removed during the upgrade process.
Commit [2] creates temporary symbolic links for all the busybox links during
busybox's postinst step. However, this is too late in the process as some
packages attempt to use 'rm' and 'sed' after update-alternatives removes the
old links and prior to when busybox's postinst step runs.
This fix is similar to [2] but runs during the preinst step. For opkg,
this is the first step that is guaranteed to run from the new package (prerm
is run from the old package) and will therefore be a backwards-compatible fix
for upgrading older systems.
Copies the existing busybox binary and the busybox.links files to a temporary
directory and then creates alternative links for all installed busybox
commands. The temporary links and directory are cleaned up during the
postinst step.
RFC: This works for me, but there may be room for improvement. I don't know
if the current pkg_prerm steps are necessary anymore. However, in my testing
I did need the links for update-alternatives to work in the preinst step. I
am also not certain if the populate_packages_updatealternatives_append
step is necessary anymore. I have also only tested this fix on dunfell, as
I don't have a working image based on master yet. It may be more appropriate
for this to go to master and then be backported to dunfell, but I would need
assistance in testing.
[1]
https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/busybox/busybox.inc?id=a9d2af8f5b3da8239cf00a52883ca596a19ea23a
[2]
https://git.openembedded.org/openembedded-core/commit/meta/recipes-core/busybox/busybox.inc?id=3a035bd0a06a6ded4d0ce7e35a3bce42245727d2
Signed-off-by: Bryan Evenson
---
meta/recipes-core/busybox/busybox.inc | 57 ++-
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index e0522be729..c85402411b 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -441,12 +441,28 @@ pkg_postinst_${PN}_prepend () {
}
pkg_postinst_${PN}_append () {
-# If busybox exists in the remove directory it is because it was the
only shell left.
if [ "x$D" = "x" ] ; then
+ # If busybox exists in the remove directory it is because it was
the only shell left.
if [ "x$BUSYBOX" != "x" ] ; then
update-alternatives --remove sh $BUSYBOX
- rm -f $BUSYBOX
fi
+ # Remove the temporary alternatives
+ for busybox_preinstdir in /tmp/busyboxpreinst-*; do
+ if [ "$busybox_preinstdir" != '/tmp/busyboxpreinst-*' ] ; then
+ BUSYBOX_PREINST_DIR="$busybox_preinstdir"
+ BUSYBOX="$BUSYBOX_PREINST_DIR/busybox"
+ if [ -e $BUSYBOX ] ; then
+ for suffix in "" ".nosuid" ".suid"; do
+ if [ -e $BUSYBOX_PREINST_DIR/busybox.links$suffix ]
; then
+ while read link; do
+ update-alternatives --remove $($BUSYBOX
basename $link) $BUSYBOX
+ done < $BUSYBOX_PREINST_DIR/busybox.links$suffix
+ fi
+ done
+ fi
+ rm -rf $BUSYBOX_PREINST_DIR
+ fi
+ done
fi
}
@@ -480,6 +496,43 @@ pkg_prerm_${PN} () {
fi
}
+pkg_preinst_${PN} () {
+# Create a temporary copy the busybox binary and the links files.
Then,
+# install an alternative link for all the links. Other packages use
these
+# commands during their upgrade process. This ensures the links are
available
+# to all the other packages. We do this in the preinst step because
it is
+# the first step guaranteed to be used from the new package. The
prerm is
+# used from the old package. Placing this here ensures it runs on
upgrade even
+# on older systems.
+
+if [ "x$D" = "x" ] ; then
+ # update-alternatives may need the links from commands added in the
prerm step
+ # to operate. Make sure we can get to that path.
+ for busybox_rmdir in /tmp/busyboxrm-*; do
+ if [ "$busybox_rmdir" != '/tmp/busyboxrm
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
All,
Ping on this RFC. It works for me, but I have a feeling there is a better way
to do this. It still seems a little messy and could probably be simplified for
the same effect.
Thanks,
Bryan
> -Original Message-
> From: Bryan Evenson
> Sent: Thursday, December 23, 2021 9:50 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links
> during install
>
> Busybox upgrades sometimes fail, especially if there is a major distribution
> upgrade and all packages need to be updated. Success is highly dependent
> on the package upgrade order.
>
> Commit [1] attempts to ensure a shell is still present by adding an
> alternative
> to /bin/sh if busybox is the only shell. However, if busybox is not the only
> shell present and the other shells are upgrading, it may then be possible that
> all shells will be removed during the upgrade process.
>
> Commit [2] creates temporary symbolic links for all the busybox links during
> busybox's postinst step. However, this is too late in the process as some
> packages attempt to use 'rm' and 'sed' after update-alternatives removes
> the old links and prior to when busybox's postinst step runs.
>
> This fix is similar to [2] but runs during the preinst step. For opkg, this
> is the
> first step that is guaranteed to run from the new package (prerm is run from
> the old package) and will therefore be a backwards-compatible fix for
> upgrading older systems.
>
> Copies the existing busybox binary and the busybox.links files to a temporary
> directory and then creates alternative links for all installed busybox
> commands. The temporary links and directory are cleaned up during the
> postinst step.
>
> RFC: This works for me, but there may be room for improvement. I don't
> know if the current pkg_prerm steps are necessary anymore. However, in
> my testing I did need the links for update-alternatives to work in the preinst
> step. I am also not certain if the
> populate_packages_updatealternatives_append
> step is necessary anymore. I have also only tested this fix on dunfell, as I
> don't have a working image based on master yet. It may be more
> appropriate for this to go to master and then be backported to dunfell, but I
> would need assistance in testing.
>
> [1] https://git.openembedded.org/openembedded-
> core/commit/meta/recipes-
> core/busybox/busybox.inc?id=a9d2af8f5b3da8239cf00a52883ca596a19ea23a
> [2] https://git.openembedded.org/openembedded-
> core/commit/meta/recipes-
> core/busybox/busybox.inc?id=3a035bd0a06a6ded4d0ce7e35a3bce42245727
> d2
>
> Signed-off-by: Bryan Evenson
> ---
> meta/recipes-core/busybox/busybox.inc | 57
> ++-
> 1 file changed, 55 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
> core/busybox/busybox.inc
> index e0522be729..c85402411b 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -441,12 +441,28 @@ pkg_postinst_${PN}_prepend () { }
>
> pkg_postinst_${PN}_append () {
> -# If busybox exists in the remove directory it is because it was the
> only
> shell left.
> if [ "x$D" = "x" ] ; then
> + # If busybox exists in the remove directory it is because it was
> the only
> shell left.
> if [ "x$BUSYBOX" != "x" ] ; then
>update-alternatives --remove sh $BUSYBOX
> - rm -f $BUSYBOX
> fi
> + # Remove the temporary alternatives
> + for busybox_preinstdir in /tmp/busyboxpreinst-*; do
> + if [ "$busybox_preinstdir" != '/tmp/busyboxpreinst-*' ] ; then
> + BUSYBOX_PREINST_DIR="$busybox_preinstdir"
> + BUSYBOX="$BUSYBOX_PREINST_DIR/busybox"
> + if [ -e $BUSYBOX ] ; then
> + for suffix in "" ".nosuid" ".suid"; do
> + if [ -e $BUSYBOX_PREINST_DIR/busybox.links$suffix
> ] ; then
> + while read link; do
> + update-alternatives --remove $($BUSYBOX
> basename
> $link) $BUSYBOX
> + done <
> $BUSYBOX_PREINST_DIR/busybox.links$suffix
> + fi
> + done
> + fi
> + rm -rf $BUSYBOX_PREINST_DIR
> + fi
> + done
> fi
> }
>
> @@ -480,6 +496,43 @@ pkg_prerm_${PN} () {
>
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Andrej, Thanks for the response. This is an attempt to fix a problem I am having with automated firmware upgrades for my system. I am using opkg for a package manager; not sure if the same problem exists with other package managers. I run into problems whenever busybox is one of the packages that needs to get updated. I enact my distribution firmware upgrade by calling "opkg --download-only upgrade; opkg upgrade". What I see happen is: 1. In the busybox pkg_prerm stage sets up some soft links for some common applets in a temporary directory and exports a path to that directory. It might also setup a temporary alternative to /bin/sh if it is the last shell. 2. After the remove stage, the busybox binary is gone. The softlinks created in the prerm stage are useless since they point to binary that no longer exists. 3. opkg continues with upgrade on other packages which may depend on a command provided by busybox in a prerm, postrm, preinst or postinst script. These upgrades then fail since the commands are no longer available. 4. The busybox upgrade completes, which may or may not complete successfully. For what I am attempting, I am upgrading my system from the morty branch to dunfell. I have util-linux on my system which shares some alternatives with busybox. The util-linux upgrade fails because it needs some busybox applets during its upgrade process. Then the busybox upgrade fails because the final update-alternatives doesn’t work; some files still exist that util-linux couldn't remove during its upgrade that clash with busybox's alternatives. After trying several ways to get my upgrade to work, I landed on the approach below. I'm creating a temporary directory and copying the busybox binary and the busybox.links files to that directory. I then install an alternative for every applet for busybox listed in all of its busybox.links files that points to the temporary copy of the busybox binary. This means that any package that uses a busybox applet during its install process should still work. Then during the postinst step I am removing all the temporary alternative links. I use the temporary busybox.links files for removing the alternative links in case the upgraded busybox is now configured with a different set of applets. This is a heavy handed approach, and it does extend the upgrade process for me by a few minutes since it runs through update-alternatives for busybox two more times. But, the approach works for me and I think would be more resilient than past approaches. I tried to mimic the existing code in my additions. If a more widescale rewrite makes sense than that works for me also. Thanks, Bryan > -Original Message- > From: Valek, Andrej > Sent: Friday, January 21, 2022 9:01 AM > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > links during install > > Hi Bryan, > > Sorry, maybe I didn't fully understand the use-case. Are you trying to > upgrade the busybox on demand? If yes, that is not a good idea. > > I'm little bit scary about doing "export PATH=$busybox_rmdir:$PATH" and > creating a custom locks is not a good at all. > > Cheers, > Andrej > > On Fri, 2022-01-21 at 13:29 +, Bryan Evenson wrote: > > All, > > > > Ping on this RFC. It works for me, but I have a feeling there is a > > better way to do this. It still seems a little messy and could > > probably be simplified for the same effect. > > > > Thanks, > > Bryan > > > > > -Original Message- > > > From: Bryan Evenson > > > Sent: Thursday, December 23, 2021 9:50 AM > > > To: openembedded-core@lists.openembedded.org > > > Subject: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > > > links during install > > > > > > Busybox upgrades sometimes fail, especially if there is a major > > > distribution upgrade and all packages need to be updated. Success > > > is highly dependent on the package upgrade order. > > > > > > Commit [1] attempts to ensure a shell is still present by adding an > > > alternative to /bin/sh if busybox is the only shell. However, if > > > busybox is not the only shell present and the other shells are > > > upgrading, it may then be possible that all shells will be removed > > > during the upgrade process. > > > > > > Commit [2] creates temporary symbolic links for all the busybox > > > links during busybox's postinst step. However, this is too late in > > > the process as some packages attempt to use 'rm' and 'sed' after > > > update-alternatives removes the old links and pr
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Andrej, I suspect it is still an issue in master, but I haven't been able to confirm. I'm using a third-party layer that hasn't been updated to support the new override syntax introduced in the honister release. I agree that it should be fixed in master and then backported as deemed necessary to other supported releases. I wasn’t able to do that yet but I wanted to give some visibility to the issue. I suspect that it is still a problem in master since I don't see any changes in busybox.inc between dunfell and master that I think could change this behavior. I'll continue to work on a consistent way for others to reproduce the problem. I suspect anyone could reproduce this problem by just adding 'util-linux' to core-image-minimal and attempting an upgrade between major releases. I'll work to confirm if this is true or not. Thanks, Bryan > -Original Message- > From: Valek, Andrej > Sent: Saturday, January 22, 2022 2:26 AM > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > links during install > > Hello again, > > Maybe a general question. Is it working in current master? I do not want to > brake dunfell, just applying something, which will create a lot of divergence. > > Cheers, > Andrej > > On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote: > > Andrej, > > > > Thanks for the response. This is an attempt to fix a problem I am > > having with automated firmware upgrades for my system. I am using > > opkg for a package manager; not sure if the same problem exists with > > other package managers. I run into problems whenever busybox is one > > of the packages that needs to get updated. I enact my distribution > > firmware upgrade by calling "opkg --download-only upgrade; opkg > > upgrade". What I see happen is: > > > > 1. In the busybox pkg_prerm stage sets up some soft links for some > > common applets in a temporary directory and exports a path to that > > directory. It might also setup a temporary alternative to /bin/sh if > > it is the last shell. > > 2. After the remove stage, the busybox binary is gone. The softlinks > > created in the prerm stage are useless since they point to binary that > > no longer exists. > > 3. opkg continues with upgrade on other packages which may depend on a > > command provided by busybox in a prerm, postrm, preinst or postinst > > script. These upgrades then fail since the commands are no longer > > available. > > 4. The busybox upgrade completes, which may or may not complete > > successfully. For what I am attempting, I am upgrading my system from > > the morty branch to dunfell. I have util-linux on my system which > > shares some alternatives with busybox. The util-linux upgrade fails > > because it needs some busybox applets during its upgrade process. > > Then the busybox upgrade fails because the final update- alternatives > > doesn’t work; some files still exist that util-linux couldn't remove > > during its upgrade that clash with busybox's alternatives. > > > > After trying several ways to get my upgrade to work, I landed on the > > approach below. I'm creating a temporary directory and copying the > > busybox binary and the busybox.links files to that directory. I then > > install an alternative for every applet for busybox listed in all of > > its busybox.links files that points to the temporary copy of the > > busybox binary. This means that any package that uses a busybox > > applet during its install process should still work. Then during the > > postinst step I am removing all the temporary alternative links. I > > use the temporary busybox.links files for removing the alternative > > links in case the upgraded busybox is now configured with a different > > set of applets. > > > > This is a heavy handed approach, and it does extend the upgrade > > process for me by a few minutes since it runs through update- > > alternatives for busybox two more times. But, the approach works for > > me and I think would be more resilient than past approaches. I tried > > to mimic the existing code in my additions. If a more widescale > > rewrite makes sense than that works for me also. > > > > Thanks, > > Bryan > > > > > > > -Original Message- > > > From: Valek, Andrej > > > Sent: Friday, January 21, 2022 9:01 AM > > > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > > > > > Subject: Re: [dunfell][PATCH RFC] busybo
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Andrej, > -Original Message- > From: Valek, Andrej > Sent: Saturday, January 22, 2022 2:26 AM > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > links during install > > Hello again, > > Maybe a general question. Is it working in current master? I do not want to > brake dunfell, just applying something, which will create a lot of divergence. > I wasn't able to build an image based on the latest master as of Monday. From the error messages I think it had something to do with the addition of setuptools3-base that wasn't complete yet. I was able to build and run an image based on the latest honister branch. The master branch has four commits for busybox that honsiter does not have. In those four commits, I see no changes to any of the installation steps. Based on this information, I'd say its safe to say that testing on the latest honister branch should confirm whether the problem is still present or not. To test, I first built my image and directly programmed it on my hardware. My image is based upon core-image-minimal, uses sysvinit for an init system and opkg for a package manager. I have also added bash, cronie, dhcpcd and util-linux to my image; I've added others but these seem to produce the most obvious errors. After programming the image on my hardware, I added PR="r1" to the gcc recipe. This forced all the packages to get rebuilt and increment the version number (if anyone knows a simpler way to accomplish this, let me know). I then created a package feed with this update and attempted an upgrade. To upgrade, I did: opkg update opkg --download-only upgrade opkg upgrade > full_upgrade.txt 2>&1 & I download all the packages to be upgraded first. I then sent the upgrade process to the background so I could check other things during the upgrade process. During the upgrade, I would occasionally execute "ls -l" to verify that the file full_upgrade.txt existed and was still growing. About a minute into the upgrade process when I executed "ls -l" I got the error message: ls: not found From that point on until upgrade was complete I had to execute "busybox ls -l" to see the current directory file list. After upgrade was complete, I checked full_upgrade.txt for error messages. I saw the following: /usr/bin/update-alternatives: line 1: sed: not found (occurred 102 times) /usr/sbin/update-rc.d: line 54: rm: not found (occurred 36 times) Stopping crond: /etc/init.d/crond: line 37: start-stop-daemon: not found /tmp/opkg-yBH1Ta/cronie-zHpym4/preinst: line 1: tr: not found /etc/init.d/udev: line 74: start-stop-daemon: not found /tmp/opkg-yBH1Ta/dhcpcd-c86ca9/preinst: line 1: tr: not found In this case, a lot of alternatives and init scripts may not be setup correctly because either the old ones were not removed or the new ones were not installed. Prior to my patch below, I saw similar errors when upgrading my image from a build based off the morty branch to one based off dunfell (and my system was not operational after the upgrade). After my patch, I performed the same upgrade with no errors and my system was fully operational. I'm up for any thoughts on a different approach that accomplishes the same goal. Otherwise, I'm going to work with what I have and update my changes so they patch cleanly on master. Thanks, Bryan > Cheers, > Andrej > > On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote: > > Andrej, > > > > Thanks for the response. This is an attempt to fix a problem I am > > having with automated firmware upgrades for my system. I am using > > opkg for a package manager; not sure if the same problem exists with > > other package managers. I run into problems whenever busybox is one > > of the packages that needs to get updated. I enact my distribution > > firmware upgrade by calling "opkg --download-only upgrade; opkg > > upgrade". What I see happen is: > > > > 1. In the busybox pkg_prerm stage sets up some soft links for some > > common applets in a temporary directory and exports a path to that > > directory. It might also setup a temporary alternative to /bin/sh if > > it is the last shell. > > 2. After the remove stage, the busybox binary is gone. The softlinks > > created in the prerm stage are useless since they point to binary that > > no longer exists. > > 3. opkg continues with upgrade on other packages which may depend on a > > command provided by busybox in a prerm, postrm, preinst or postinst > > script. These upgrades then fail since the commands are no longer > > available. > > 4. The busybox upgrade completes, which may or may not complete > >
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Andrej, > -Original Message- > From: Valek, Andrej > Sent: Friday, January 28, 2022 6:39 AM > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > links during install > > Hello Bryan, > > So looks like, there is some kind of problem. > > Was you able to run the busybox command after upgrade like, "busybox ls /" > ? In this particular case, after upgrade both "busybox ls" and "ls" worked. However, that was partly because for this particular case the packages were identical but I just forced a version number change. None of the files were actually different after the upgrade. Failure to replace files didn't affect operation. When I was upgrading my image from the morty release to the dunfell release, there was a change in util-linux that conflicted with busybox if they both didn't upgrade cleanly and the update-alternatives installation step would fail for both. In that case "busybox ls" would still work but "ls" would not. Repeated upgrade attempts didn't fix it. I had to manually delete certain files that were not deleted during the initial upgrade attempt and then upgrade packages manually in a particular order to get the system fully operational again. > - If yes, there is a problem, that update alternatives hasn't been processed > correctly. Try direct command after reboot, if possible > - If no, lets continue with patch creation based on the master branch I will continue work on a patch based on master. I'm going to try testing a few other cases so I don't anticipate having a patch ready until early next week. Thanks, Bryan > > Cheers, > Andrej > > On Thu, 2022-01-27 at 14:39 +, Bryan Evenson wrote: > > Andrej, > > > > > -Original Message- > > > From: Valek, Andrej > > > Sent: Saturday, January 22, 2022 2:26 AM > > > To: openembedded-core@lists.openembedded.org; Bryan Evenson > > > > > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary > > > busybox links during install > > > > > > Hello again, > > > > > > Maybe a general question. Is it working in current master? I do not > > > want to brake dunfell, just applying something, which will create a > > > lot of divergence. > > > > > > > I wasn't able to build an image based on the latest master as of > > Monday. From the error messages I think it had something to do with > > the addition of setuptools3-base that wasn't complete yet. I was able > > to build and run an image based on the latest honister branch. > > The master branch has four commits for busybox that honsiter does not > > have. In those four commits, I see no changes to any of the > > installation steps. Based on this information, I'd say its safe to > > say that testing on the latest honister branch should confirm whether > > the problem is still present or not. > > > > To test, I first built my image and directly programmed it on my > > hardware. My image is based upon core-image-minimal, uses sysvinit > > for an init system and opkg for a package manager. I have also added > > bash, cronie, dhcpcd and util-linux to my image; I've added others but > > these seem to produce the most obvious errors. > > > > After programming the image on my hardware, I added PR="r1" to the gcc > > recipe. This forced all the packages to get rebuilt and increment the > > version number (if anyone knows a simpler way to accomplish this, let > > me know). I then created a package feed with this update and > > attempted an upgrade. > > > > To upgrade, I did: > > opkg update > > opkg --download-only upgrade > > opkg upgrade > full_upgrade.txt 2>&1 & > > > > I download all the packages to be upgraded first. I then sent the > > upgrade process to the background so I could check other things during > > the upgrade process. > > > > During the upgrade, I would occasionally execute "ls -l" to verify > > that the file full_upgrade.txt existed and was still growing. About a > > minute into the upgrade process when I executed "ls -l" I got the > > error message: > > > > ls: not found > > > > From that point on until upgrade was complete I had to execute > > "busybox ls -l" to see the current directory file list. After upgrade > > was complete, I checked full_upgrade.txt for error messages. > > I saw the following: > > > > /usr/bin/u
[OE-core] busybox: rm and sed not available during upgrade
All, I have custom image based off core-image-minimal that is on the morty branch. I am working on upgrading the image up to the latest supported branch, one step at a time. I updated to the pyro branch and got an image to build. I am using opkg for a package manager. I test firmware upgrade by executing "opkg update; opkg --download-only upgrade; opkg upgrade" and then looking for errors in the output. I am seeing some errors during upgrade that I don't know how to fix. When opkg removes the old version of busybox, updates-alternatives removes all the softlinks for busybox. Then, it proceeds to upgrade other packages prior to running upgrade-alternatives to create the new softlinks for busybox. As a result, the preinstall script fails on several packages because the preinstall script can't find rm, sed, tr or start-stop-daemon. I don't remember seeing these errors previously. Is there some flag or setting that should force busybox to complete its upgrade prior to uninstalling and installing other packages? Thanks, Bryan Evenson -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#155995): https://lists.openembedded.org/g/openembedded-core/message/155995 Mute This Topic: https://lists.openembedded.org/mt/85586922/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install
Jate, I don’t know when the binary is removed, but I see update-alternatives –remove for all the busybox links is in the prerm script and update-alternatives –install is in the postinst script. For opkg, I am witnessing the prerm stage run for busybox and other packages performing some stages of their upgrade prior to busybox completing its upgrade. It is possible that rpm operates differently. I have a patch that I will be sending out shortly. I’ve tested on honister by forcing all package versions to increment. I’ve also tested upgrading from an image based on the morty release up to the latest on honister. Both ways I upgrade cleanly with my patch. -Bryan From: Jate Sujjavanich Sent: Wednesday, February 2, 2022 10:59 AM To: Bryan Evenson Cc: Valek, Andrej ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [dunfell][PATCH RFC] busybox.inc: Create temporary busybox links during install I have performed a major distribution upgrade in the past. This was with rpm which requires bash. I did not have issues with utilities required by the upgrade disappearing. I believe rpm installs the new file, and then removes old files. Does opkg remove the old binary before installing the new version? -Jate On Fri, Jan 28, 2022 at 8:12 AM Bryan Evenson mailto:beven...@melinkcorp.com>> wrote: Andrej, > -Original Message- > From: Valek, Andrej > mailto:andrej.va...@siemens.com>> > Sent: Friday, January 28, 2022 6:39 AM > To: > openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>; > Bryan Evenson > mailto:beven...@melinkcorp.com>> > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary busybox > links during install > > Hello Bryan, > > So looks like, there is some kind of problem. > > Was you able to run the busybox command after upgrade like, "busybox ls /" > ? In this particular case, after upgrade both "busybox ls" and "ls" worked. However, that was partly because for this particular case the packages were identical but I just forced a version number change. None of the files were actually different after the upgrade. Failure to replace files didn't affect operation. When I was upgrading my image from the morty release to the dunfell release, there was a change in util-linux that conflicted with busybox if they both didn't upgrade cleanly and the update-alternatives installation step would fail for both. In that case "busybox ls" would still work but "ls" would not. Repeated upgrade attempts didn't fix it. I had to manually delete certain files that were not deleted during the initial upgrade attempt and then upgrade packages manually in a particular order to get the system fully operational again. > - If yes, there is a problem, that update alternatives hasn't been processed > correctly. Try direct command after reboot, if possible > - If no, lets continue with patch creation based on the master branch I will continue work on a patch based on master. I'm going to try testing a few other cases so I don't anticipate having a patch ready until early next week. Thanks, Bryan > > Cheers, > Andrej > > On Thu, 2022-01-27 at 14:39 +, Bryan Evenson wrote: > > Andrej, > > > > > -Original Message- > > > From: Valek, Andrej > > > mailto:andrej.va...@siemens.com>> > > > Sent: Saturday, January 22, 2022 2:26 AM > > > To: > > > openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>; > > > Bryan Evenson > > > mailto:beven...@melinkcorp.com>> > > > Subject: Re: [dunfell][PATCH RFC] busybox.inc: Create temporary > > > busybox links during install > > > > > > Hello again, > > > > > > Maybe a general question. Is it working in current master? I do not > > > want to brake dunfell, just applying something, which will create a > > > lot of divergence. > > > > > > > I wasn't able to build an image based on the latest master as of > > Monday. From the error messages I think it had something to do with > > the addition of setuptools3-base that wasn't complete yet. I was able > > to build and run an image based on the latest honister branch. > > The master branch has four commits for busybox that honsiter does not > > have. In those four commits, I see no changes to any of the > > installation steps. Based on this information, I'd say its safe to > > say that testing on the latest honister branch should confirm whether > > the problem is still present or not. > > > > To test, I first built my image and directly programm
[OE-core] [PATCH] busybox.inc: Create temporary links during install
Other packages may use busybox applets in their installation
scripts. If busybox is also being upgraded, other package upgrades
may run between when the old busybox alternative links are removed
and when the new alternative links are installed. This may prevent
other packages from installing correctly.
Copies the busybox binary and busybox.links files to a temporary
directory. Installs temporary alternative links for each listed
link that points to the temporary binary that are live during the
busybox installation process.
Removes the prerm and populate_packages_updatealternatives steps
that were intended for the same purpose.
Tested with an core-image-minimal based image which uses opkg for
its package manager and sysvinit for init.
Signed-off-by: Bryan Evenson
---
meta/recipes-core/busybox/busybox.inc | 156 +-
1 file changed, 78 insertions(+), 78 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index 622325aabb..c0b63ad2c0 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -387,95 +387,95 @@ python do_package:prepend () {
set_alternative_vars("${sysconfdir}/busybox.links.suid",
"${base_bindir}/busybox.suid")
}
-# This part of code is dedicated to the on target upgrade problem. It's known
-# that if we don't make appropriate symlinks before update-alternatives calls,
-# there will be errors indicating missing commands such as 'sed'.
-# These symlinks will later be updated by update-alternatives calls.
-# The update-alternatives.bbclass' postinst script runs firstly before other
-# postinst, but this part of code needs run firstly, so add this funtion.
-python populate_packages_updatealternatives:append() {
-postinst = """
-test -n 2 > /dev/null || alias test='busybox test'
-if test "x$D" = "x"; then
-# Remove busybox.nosuid if it's a symlink, because this situation indicates
-# that we're installing or upgrading to a one-binary busybox.
-if test -h ${base_bindir}/busybox.nosuid; then
-rm -f ${base_bindir}/busybox.nosuid
-fi
-for suffix in "" ".nosuid" ".suid"; do
-if test -e ${sysconfdir}/busybox.links$suffix; then
-while read link; do
-if test ! -e "$link"; then
-# we can use busybox here because even if we are using
splitted busybox
-# we've made a symlink from /bin/busybox to
/bin/busybox.nosuid.
-busybox rm -f $link
-busybox ln -s "${base_bindir}/busybox$suffix" $link
-fi
-done < ${sysconfdir}/busybox.links$suffix
-fi
-done
-fi
-if grep -q "^${base_bindir}/bash$" $D${sysconfdir}/busybox.links*; then
-grep -q "^${base_bindir}/bash$" $D${sysconfdir}/shells || echo
${base_bindir}/bash >> $D${sysconfdir}/shells
-fi
-
-"""
-d.prependVar('pkg_postinst:%s' % pkg, postinst)
-}
-
-pkg_postinst:${PN}:prepend () {
-# Need path to saved utils, but they may have be removed on upgrade of
busybox
-# Only use shell to get paths. Also capture if busybox was saved.
-BUSYBOX=""
-if [ "x$D" = "x" ] ; then
+pkg_postinst:${PN}:append () {
+if [ "x$D" = "x" ] ; then
+ # Older versions may have added a temporary directory and an
alternative
+ # to sh in a prerm step. Remove these if they are present.
for busybox_rmdir in /tmp/busyboxrm-*; do
if [ "$busybox_rmdir" != '/tmp/busyboxrm-*' ] ; then
- export PATH=$busybox_rmdir:$PATH
if [ -e $busybox_rmdir/busybox* ] ; then
BUSYBOX="$busybox_rmdir/busybox*"
+update-alternatives --remove sh $BUSYBOX
+rm -f $BUSYBOX
fi
fi
done
-fi
-}
-pkg_postinst:${PN}:append () {
-# If busybox exists in the remove directory it is because it was the
only shell left.
-if [ "x$D" = "x" ] ; then
- if [ "x$BUSYBOX" != "x" ] ; then
- update-alternatives --remove sh $BUSYBOX
- rm -f $BUSYBOX
- fi
+ # Remove the temporary alternatives
+ for busybox_preinstdir in /tmp/busyboxpreinst-*; do
+ if [ "$busybox_preinstdir" != '/tmp/busyboxpreinst-*' ] ; then
+ BUSYBOX_PREINST_DIR="$busybox_preinstdir"
+ BUSYBOX="$BUSYBOX_PREINST_DIR/busybox"
+ if [ -e $BUSYBOX ] ; then
+ for suffix in &
Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE
Enrico, > -Original Message- > From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Enrico Scholz via > lists.openembedded.org > Sent: Friday, February 4, 2022 9:16 AM > To: Alexander Kanavin > Cc: Jon Mason ; Yocto-mailing-list > ; Patches and discussions about the oe-core > layer ; OpenEmbedded > Devel List > Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE > > Alexander Kanavin writes: > > >> > For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" > would > >> > become "HALT, NO_NEW_TASKS and "WARN". > >> > >> I am not an native english speaker, but for "HALT" I will have to > >> think twice whether it will pause the operation or abort it. I would > >> stay at "ABORT" because it makes much more clear what happens. > > > > I'm not taking a stand here, but just providing the context for where > > the push for avoidance of 'abort' comes from: > > https://inclusivenaming.org/word-lists/tier-1/ > > > > Keep in mind that for non-native english speakers none of these words > > are emotionally charged; they're just terms. > > Yes; these are terms. But it should be possible to understand the meaning of > these terms without using a special "inclusivenaming" > dictionary. Else, we could just use "A", "B" and "C" for the actions above > and > explain these "terms" in some documentation later. > Would CANCEL be clearer to you than HALT? > > >> > BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS > >> > BB_SETSCENE_ENFORCE_WHITELIST -> > BB_SETSCENE_ENFORCE_IGNORE_TASKS > >> > BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS > >> > MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED > >> > >> The new variable names sound like boolean flags, not like lists. > > > > I'd say the context should make it clear that they are lists > > It is bad when a context is required to understand the meaning of a variable. > > And where do you see a context when local.conf contains > > | BB_HASHCONFIG_IGNORE_VARS = "true" Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more sense to you? Bryan > > > > Enrico -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161367): https://lists.openembedded.org/g/openembedded-core/message/161367 Mute This Topic: https://lists.openembedded.org/mt/88906624/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] gio-querymodules: error while loading shared libraries: libffi.so.6: cannot open shared object file
All, I'm having some upgrade issues related to upgrading libglib-2.0-0. I have a device that is based on the morty release that I am upgrading to a build based on the dunfell release. I am using opkg for a package manager. During upgrade I see the error message in the subject. I think I have an idea of what is happening and I'm looking for help on how to fix it. I seeh that libglib-2.0-0 depends on libffi. Between the morty release and the dunfell release, libffi upgraded from libffi6 to libffi7. When I upgrade my system, libffi upgrades from libffi6 to libffi7 prior to libglib-2.0-0 upgrading. When libglib-2.0-0 upgrades, it calls '/usr/libexec/gio-querymodules /usr/lib/gio/modules/' in its postrm script. This postrm script fails and gives the error listed the subject line. I'm assuming that this fails because gio-querymodules depends on libffi6 which is no longer installed. Has anyone run into a similar problem and found a way to fix it? I've tried a few different ways to force a different upgrade order and so far nothing works. Thanks, Bryan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161463): https://lists.openembedded.org/g/openembedded-core/message/161463 Mute This Topic: https://lists.openembedded.org/mt/88979156/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] gio-querymodules: error while loading shared libraries: libffi.so.6: cannot open shared object file
Alex,
> -Original Message-
> From: Alexander Kanavin
> Sent: Monday, February 7, 2022 1:58 PM
> To: Bryan Evenson
> Cc: Patches and discussions about the oe-core layer c...@lists.openembedded.org>
> Subject: Re: [OE-core] gio-querymodules: error while loading shared
> libraries: libffi.so.6: cannot open shared object file
>
> Upgrading from one yocto release to a different yocto release with a package
> manager is not supported or tested. You need to replace the image
> completely.
>
I traced back and I see the gio-querymodules call is inserted in the postrm by
gio-module-class.bbclass. Based on the commit notes, the postrm and postinst
steps are an optimization and are not required to succeed. Therefore I'd argue
this should fail gracefully; just because we haven't yet seen this fail during
minor upgrade attempts doesn't mean it can't. I'd propose changing the line:
${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/
in gio-module-cache.bbclass to:
${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/ || true
I tested this change and it fixed my upgrade issue. I still saw the error
message but libglib-2.0 completed its upgrade successfully. If you don't see
any issues with this change, I'll send a patch out later today.
Thanks,
Bryan
> Alex
>
> On Mon, 7 Feb 2022 at 19:49, Bryan Evenson
> wrote:
> >
> > All,
> >
> > I'm having some upgrade issues related to upgrading libglib-2.0-0. I have a
> device that is based on the morty release that I am upgrading to a build
> based on the dunfell release. I am using opkg for a package manager. During
> upgrade I see the error message in the subject. I think I have an idea of
> what
> is happening and I'm looking for help on how to fix it.
> >
> > I seeh that libglib-2.0-0 depends on libffi. Between the morty release and
> the dunfell release, libffi upgraded from libffi6 to libffi7. When I upgrade
> my
> system, libffi upgrades from libffi6 to libffi7 prior to libglib-2.0-0
> upgrading.
> When libglib-2.0-0 upgrades, it calls '/usr/libexec/gio-querymodules
> /usr/lib/gio/modules/' in its postrm script. This postrm script fails and
> gives
> the error listed the subject line. I'm assuming that this fails because gio-
> querymodules depends on libffi6 which is no longer installed.
> >
> > Has anyone run into a similar problem and found a way to fix it? I've
> > tried a
> few different ways to force a different upgrade order and so far nothing
> works.
> >
> > Thanks,
> > Bryan
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161514):
https://lists.openembedded.org/g/openembedded-core/message/161514
Mute This Topic: https://lists.openembedded.org/mt/88979156/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] gio-querymodules: error while loading shared libraries: libffi.so.6: cannot open shared object file
Alex,
From: Alexander Kanavin
Sent: Tuesday, February 8, 2022 11:59 AM
To: Bryan Evenson
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] gio-querymodules: error while loading shared libraries:
libffi.so.6: cannot open shared object file
On Tue, 8 Feb 2022 at 16:25, Bryan Evenson
mailto:beven...@melinkcorp.com>> wrote:
I traced back and I see the gio-querymodules call is inserted in the postrm by
gio-module-class.bbclass. Based on the commit notes, the postrm and postinst
steps are an optimization and are not required to succeed. Therefore I'd argue
this should fail gracefully; just because we haven't yet seen this fail during
minor upgrade attempts doesn't mean it can't. I'd propose changing the line:
${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/
in gio-module-cache.bbclass to:
${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/ || true
I tested this change and it fixed my upgrade issue. I still saw the error
message but libglib-2.0 completed its upgrade successfully. If you don't see
any issues with this change, I'll send a patch out later today.
This change will mask all failures that happen for any reason, not just the one
you saw, so I am not going to accept it. The correct fix is to figure out what
would be the correct order of updating and why opkg isn't able to perform the
mass-update in that order.
Alex
As best I can tell, this is breaking because libffi upgraded from libffi6 to
libffi7. The old version of glib-2.0 depends on libffi6 and the new version of
glib-2.0 depends on libffi7. Opkg starts to upgrade glib-2.0, but it first
upgrades the dependent packages. This removes libffi6 and installs libffi7.
Then, the postrm script runs for glib-2.0 using the old binaries. The
gio-querymodules call then fails because it tries to load libffi6 which no
longer exists. Even if I was able to defer upgrading libffi from libffi6 to
libffi7 until after glib-2.0 upgrades, I’d then run into a similar problem with
the postinst script. In that case, gio-querymodules would fail because it
would try to load libffi7 which would not be installed yet.
I understand that you don’t want errors to go through undetected. Would an
appropriate error message, such as:
${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/ || echo
“GIO module caching failed. You may need to manually update the GIO module
cache.”
Work for you?
Thanks,
Bryan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161525):
https://lists.openembedded.org/g/openembedded-core/message/161525
Mute This Topic: https://lists.openembedded.org/mt/88979156/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] gio-querymodules: error while loading shared libraries: libffi.so.6: cannot open shared object file
Alex,
> -Original Message-
> From: Alexander Kanavin
> Sent: Tuesday, February 8, 2022 4:38 PM
> To: Bryan Evenson
> Cc: Patches and discussions about the oe-core layer c...@lists.openembedded.org>
> Subject: Re: [OE-core] gio-querymodules: error while loading shared
> libraries: libffi.so.6: cannot open shared object file
>
> On Tue, 8 Feb 2022 at 21:36, Bryan Evenson
> wrote:
> > As best I can tell, this is breaking because libffi upgraded from libffi6 to
> libffi7. The old version of glib-2.0 depends on libffi6 and the new version
> of
> glib-2.0 depends on libffi7. Opkg starts to upgrade glib-2.0, but it first
> upgrades the dependent packages. This removes libffi6 and installs libffi7.
> Then, the postrm script runs for glib-2.0 using the old binaries. The gio-
> querymodules call then fails because it tries to load libffi6 which no longer
> exists. Even if I was able to defer upgrading libffi from libffi6 to libffi7
> until
> after glib-2.0 upgrades, I’d then run into a similar problem with the postinst
> script. In that case, gio-querymodules would fail because it would try to
> load
> libffi7 which would not be installed yet.
> > I understand that you don’t want errors to go through undetected. Would
> an appropriate error message, such as:
> > ${libexecdir}/${MLPREFIX}gio-querymodules ${libdir}/gio/modules/ ||
> echo “GIO module caching failed. You may need to manually update the GIO
> module cache.”
> > Work for you?
>
> That is not an error message, that is a warning message, and no, that is not
> appropriate either, because it's likely to go unseen, or discarded.
>
> I think you should study how desktop distributions handle this, both rpm-
> based and deb-based. How do their postinst/postrms look like, and in what
> sequence do they run?
For the Debian upgrade policy (flowchart here:
https://www.debian.org/doc/debian-policy/ap-flowcharts.html), successful events
occur in the following order:
1. Call prerm script from the old package
2. Call preinst script from the new package
3. Unpack new files and save backup of old files
4. Call postrm script from the old package
5. Delete old files
6. Call postinst script from the new package
7. Exit package upgrade
Opkg does something slightly different so it can operate with a smaller memory
footprint. For opkg the event order is:
1. Call prerm script from the old package
2. Call preinst script from the new package
3. Call postrm script from the old package
4. Unpack new files and delete old files
5. Call postinst script from the new package
6. Exit package upgrade
This saves space since there won't be a copy of every file in the package
during upgrade. It also reduces code complexity in opkg. But, it also means
the new files aren't available until the postinst stage. This is why I'm
seeing the failure that I am with opkg. So the postrm script is failing
because opkg isn't meeting the Debian policy.
However, I still think that a package upgrade should have a way to exit
gracefully for something that is an optimization and not required for
operation. In my case, my device isn't even using the GIO library and the
gio-querymodules serves no purpose. I don't know enough about the entire Glib
package to know If there is a way to make this functionality optional or not.
If there isn't, then I will continue with my own out-of-tree changes to fix the
operational problems I am seeing on my device.
Thanks,
Bryan
>
> As mentioned before, Yocto does not test or support mass-upgrades via
> package manager: if we want to fix this, we better do it properly from the
> start.
>
> Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#161651):
https://lists.openembedded.org/g/openembedded-core/message/161651
Mute This Topic: https://lists.openembedded.org/mt/88979156/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] gio-querymodules: error while loading shared libraries: libffi.so.6: cannot open shared object file
Alex, > -Original Message- > From: Alexander Kanavin > Sent: Friday, February 11, 2022 10:06 AM > To: Bryan Evenson > Cc: Patches and discussions about the oe-core layer c...@lists.openembedded.org> > Subject: Re: [OE-core] gio-querymodules: error while loading shared > libraries: libffi.so.6: cannot open shared object file > > On Fri, 11 Feb 2022 at 14:46, Bryan Evenson > wrote: > > > However, I still think that a package upgrade should have a way to exit > gracefully for something that is an optimization and not required for > operation. In my case, my device isn't even using the GIO library and the > gio- > querymodules serves no purpose. I don't know enough about the entire > Glib package to know If there is a way to make this functionality optional or > not. If there isn't, then I will continue with my own out-of-tree changes to > fix > the operational problems I am seeing on my device. > > Thanks, does rpm do something similar to debian? This does look as a > shortcoming in opkg design; what would help you is perhaps a comman line > option for opkg, --ignore-scriptlet-failures or similar. From what I have read, it appears RPM functions very similar to Debian. The new package files are installed prior to postrm, with the old files temporarily backed up and removed later. I'll look at some of the other opkg options to see if there are some ignore options that I haven't tried yet. Thanks, Bryan > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#161656): https://lists.openembedded.org/g/openembedded-core/message/161656 Mute This Topic: https://lists.openembedded.org/mt/88979156/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
