opkg tries to remove package twice

[Stefan Agner]

Hi,

While using the Ångström distribution we see issues when upgrading some
packages. Specifically, libjpeg8 seems to get handled strange: opkg
tries to remove the old package twice! I looked at the package metadata,
it doesn't seem to have anything unusual:

Package: libjpeg8
Version: 8d+1.4.1-r0.6
Depends: libc6 (>= 2.22)
Provides: libjpeg-turbo, jpeg
Replaces: jpeg
Conflicts: jpeg
Section: base
Architecture: armv7at2hf-vfp-neon
Maintainer: Angstrom Developers <angstrom-d...@linuxtogo.org>
MD5Sum: a7b348f7dd4a347d0f636ff9ada3a0ed
Size: 195454
Filename: libjpeg8_8d+1.4.1-r0.6_armv7at2hf-vfp-neon.ipk
Description: libjpeg-turbo version 8d+1.4.1-r0 libjpeg-turbo is a
derivative of
libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate
baseline JPEG compression and decompression
OE: libjpeg-turbo
HomePage: http://libjpeg-turbo.org/
License: BSD-3-Clause
Priority: optional

However, when this package gets upgraded, opkg tries to remove the old
package twice, and the second remove fails due to missing rm scripts
(note "Removing package libjpeg8 from root"):

pkg_info_preinstall_check: Updating file owner list.
pkg_hash_fetch_best_installation_candidate: Best installation candidate
for libjpeg8:
pkg_hash_fetch_best_installation_candidate: apkg=libjpeg8 nprovides=2.
pkg_hash_fetch_best_installation_candidate: Adding libjpeg8 to
providers.
pkg_hash_fetch_best_installation_candidate: libjpeg8
arch=armv7at2hf-vfp-neon arch_priority=61 version=8d+1.4.1.
pkg_hash_fetch_best_installation_candidate: libjpeg8
arch=armv7at2hf-vfp-neon arch_priority=61 version=8d+1.4.1.
pkg_hash_fetch_best_installation_candidate: Candidate: libjpeg8
8d+1.4.1.
pkg_hash_fetch_best_installation_candidate: Candidate: libjpeg8
8d+1.4.1.
pkg_hash_fetch_best_installation_candidate: 2 matching pkgs for
apkg=libjpeg8:
pkg_hash_fetch_best_installation_candidate: libjpeg8 8d+1.4.1
armv7at2hf-vfp-neon
pkg_hash_fetch_best_installation_candidate: libjpeg8 8d+1.4.1
armv7at2hf-vfp-neon
opkg_prepare_upgrade_pkg: Comparing visible versions of pkg libjpeg8:
8d+1.4.1-r0 is installed
8d+1.4.1-r0.6 is available
-302 was comparison result
pkg_arch_supported: Arch armv7at2hf-vfp-neon (priority 61) supported for
pkg libjpeg8.
Upgrading libjpeg8 from 8d+1.4.1-r0 to 8d+1.4.1-r0.6 on root.
Downloading
http://feeds.toradex.com/angstrom/feeds/v2015.12/ipk/glibc/armv7at2hf-vfp-neon/base/libjpeg8_8d+1.4.1-r0.6_armv7at2hf-vfp-neon.ipk.
print_paths: Extracting '/tmp/opkg-mO9Qej/libjpeg8-9envY3/control'.
print_paths: Extracting '/tmp/opkg-mO9Qej/libjpeg8-9envY3/postinst'.
pkg_hash_fetch_best_installation_candidate: Best installation candidate
for libc6:
pkg_hash_fetch_best_installation_candidate: apkg=libc6 nprovides=2.
pkg_hash_fetch_best_installation_candidate: Adding libc6 to providers.
pkg_hash_fetch_best_installation_candidate: libc6 arch=armv7ahf-vfp-neon
arch_priority=56 version=2.22.
pkg_hash_fetch_best_installation_candidate: Candidate: libc6 2.22.
pkg_hash_fetch_unsatisfied_dependencies: satisfying_pkg=0xdd2010
pkg_hash_fetch_best_installation_candidate: Best installation candidate
for libc6:
pkg_hash_fetch_best_installation_candidate: apkg=libc6 nprovides=2.
pkg_hash_fetch_best_installation_candidate: Adding libc6 to providers.
pkg_hash_fetch_best_installation_candidate: libc6 arch=armv7ahf-vfp-neon
arch_priority=56 version=2.22.
pkg_hash_fetch_best_installation_candidate: Candidate: libc6 2.22.
Removing package libjpeg8 from root...
pkg_run_script: Running script ///var/lib/opkg/info/libjpeg8.prerm.
pkg_run_script: Running script ///var/lib/opkg/info/libjpeg8.postrm.
remove_maintainer_scripts: Deleting
///var/lib/opkg/info/libjpeg8.control.
remove_maintainer_scripts: Deleting
///var/lib/opkg/info/libjpeg8.postinst.
Removing package libjpeg8 from root...
You can force removal of packages with failed prerm scripts with the
option:
--force-remove
pkg_arch_supported: Arch armv7at2hf-vfp-neon (priority 61) supported for
pkg libjpeg8.
Installing libjpeg8 (8d+1.4.1-r0) on root.
To remove package debris, try `opkg remove libjpeg8`.
To re-attempt the install, try `opkg install libjpeg8`.
opkg_configure_packages: Configuring unpacked packages.
opkg_configure_packages: Reordering packages before configuring them...


The libjpeg8 section in the opkg status file looks as follows:

Package: libjpeg8
Version: 8d+1.4.1-r0
Depends: libc6 (>= 2.22)
Provides: libjpeg-turbo, jpeg
Replaces: jpeg
Conflicts: jpeg
Status: install ok installed
Architecture: armv7at2hf-vfp-neon
Installed-Time: 1459440337
Auto-Installed: yes

Any idea what goes wrong here?

Angstrom release 2015.12 based on jethro, opkg version is 0.3.0

--
Stefan

[Koen Kooi]

And a ‘me too’:

root@minnowboard-turbot:~# opkg install /tmp/foo/xf86-video-intel_2.99.917+git1+562ae1f29f-r0.0_corei7-64.ipk
Upgrading xf86-video-intel from 2:2.99.917+git0+8b8c9a3682-r0.6 to 2:2.99.917+git1+562ae1f29f-r0.0 on root.
Upgrading libpixman-1-0 from 1:0.32.6-r0.1 to 1:0.32.6-r0.2 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libpixman-1-0_0.32.6-r0.2_corei7-64.ipk.
Upgrading libpciaccess0 from 0.13.4-r0.2 to 0.13.4-r0.4 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libpciaccess0_0.13.4-r0.4_corei7-64.ipk.
Upgrading libxcb-util1 from 0.4.0-r0.1 to 0.4.0-r0.3 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libxcb-util1_0.4.0-r0.3_corei7-64.ipk.
Upgrading libxv1 from 1.0.10-r0.1 to 1.0.10-r0.4 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libxv1_1.0.10-r0.4_corei7-64.ipk.
Upgrading libxvmc from 1:1.0.9-r0.1 to 1:1.0.9-r0.3 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libxvmc_1.0.9-r0.3_corei7-64.ipk.
Upgrading xserver-xorg from 2:1.17.4-r0.6 to 2:1.17.4-r0.8 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/xserver-xorg_1.17.4-r0.8_corei7-64.ipk.
xserver-xorg: unsatisfied recommendation for xserver-xorg-security-policy
Upgrading libxfont1 from 1:1.5.1-r0.1 to 1:1.5.1-r0.3 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libxfont1_1.5.1-r0.3_corei7-64.ipk.
Upgrading libfontenc1 from 1:1.1.3-r0.1 to 1:1.1.3-r0.3 on root.
Downloading http://dominion.thruhere.net/angstrom/feeds/v2015.12/ipk/glibc/corei7-64/base/libfontenc1_1.1.3-r0.3_corei7-64.ipk.
Removing package xserver-xorg from root...
Removing package xserver-xorg from root...

You can force removal of packages with failed prerm scripts with the option:
--force-remove

Installing xserver-xorg (2:1.17.4-r0.6) on root.
To remove package debris, try `opkg remove xserver-xorg`.
To re-attempt the install, try `opkg install xserver-xorg`.
Configuring libxv1.
Configuring libxvmc.
Configuring libpixman-1-0.
Configuring libfontenc1.
Configuring libpciaccess0.
Configuring libxcb-util1.
Configuring libxfont1.
Collected errors:
* pkg_run_script: Internal error: xserver-xorg has a NULL tmp_unpack_dir.
* opkg_remove_pkg: not removing package "xserver-xorg", prerm script failed
* get_pkg_url: Package xserver-xorg is not available from any configured src.
* opkg_install_pkg: Failed to download xserver-xorg. Perhaps you need to run 'opkg update'?
* opkg_install_cmd: Cannot install package xf86-video-intel.

[Alejandro del Castillo]

this bug was introduced in v0.3.0 and is already fixed on master on
commit 7885da3974de2df1baba220200d55920fb530e25. I don't think the opkg
recipe on oe-core includes the patch....it probably should as it is a
serious bug....are you building using OE?

BTW, if you run the operation 2 more times, it will work.

[Stefan Agner]

On 2016-04-21 08:47, Alejandro del Castillo wrote:
> this bug was introduced in v0.3.0 and is already fixed on master on
> commit 7885da3974de2df1baba220200d55920fb530e25. I don't think the
> opkg recipe on oe-core includes the patch....it probably should as it
> is a serious bug....are you building using OE?

Yes, we are using OE, jethro branch. Yeah a backport would be nice...
Can you send a patch or should I create one?

>
> BTW, if you run the operation 2 more times, it will work.
>

Yes, I figured that, but not really nice solution anyway :-)

--
Stefan

[Alejandro del Castillo]

On 04/21/2016 11:17 AM, Stefan Agner wrote:
> On 2016-04-21 08:47, Alejandro del Castillo wrote:
>> this bug was introduced in v0.3.0 and is already fixed on master on
>> commit 7885da3974de2df1baba220200d55920fb530e25. I don't think the
>> opkg recipe on oe-core includes the patch....it probably should as it
>> is a serious bug....are you building using OE?
>
> Yes, we are using OE, jethro branch. Yeah a backport would be nice...
> Can you send a patch or should I create one?

I am at a conference this week, so the earliest I could submit a patch
would be next week....if you can submit the patch that would be great!

>> BTW, if you run the operation 2 more times, it will work.
>>
>
> Yes, I figured that, but not really nice solution anyway :-)

yep, just wanted to mention it as a quick and dirty out

[Stefan Agner]

On 2016-04-21 11:33, Alejandro del Castillo wrote:
> On 04/21/2016 11:17 AM, Stefan Agner wrote:
>> On 2016-04-21 08:47, Alejandro del Castillo wrote:
>>> this bug was introduced in v0.3.0 and is already fixed on master on
>>> commit 7885da3974de2df1baba220200d55920fb530e25. I don't think the
>>> opkg recipe on oe-core includes the patch....it probably should as it
>>> is a serious bug....are you building using OE?
>>
>> Yes, we are using OE, jethro branch. Yeah a backport would be nice...
>> Can you send a patch or should I create one?
>
> I am at a conference this week, so the earliest I could submit a patch
> would be next week....if you can submit the patch that would be great!
>

Backported, tested and sent for jethro.

The change has been committed after v0.3.1, and krogoth is (currently)
using v0.3.1... What is the plan for krogoth, will it get another opkg
update or should that get a backported fix too?

--
Stefan

[Alejandro del Castillo]

On 04/21/2016 04:19 PM, Stefan Agner wrote:
> On 2016-04-21 11:33, Alejandro del Castillo wrote:
>> On 04/21/2016 11:17 AM, Stefan Agner wrote:
>>> On 2016-04-21 08:47, Alejandro del Castillo wrote:
>>>> this bug was introduced in v0.3.0 and is already fixed on master on
>>>> commit 7885da3974de2df1baba220200d55920fb530e25. I don't think the
>>>> opkg recipe on oe-core includes the patch....it probably should as it
>>>> is a serious bug....are you building using OE?
>>>
>>> Yes, we are using OE, jethro branch. Yeah a backport would be nice...
>>> Can you send a patch or should I create one?
>>
>> I am at a conference this week, so the earliest I could submit a patch
>> would be next week....if you can submit the patch that would be great!
>>
>
> Backported, tested and sent for jethro.

thanks!

> The change has been committed after v0.3.1, and krogoth is (currently)
> using v0.3.1... What is the plan for krogoth, will it get another opkg
> update or should that get a backported fix too?

it should be backported to krogoth too since the next release of opkg is
scheduled to June (too late for krogoth). I'll reply to your patch on
the openembedded-core developer list to suggest it gets it's way into
krogoth too.

--
Cheers,

Alejandro

[stefan....@googlemail.com]

Am Samstag, 23. April 2016 22:41:17 UTC+2 schrieb Alejandro del Castillo:
> it should be backported to krogoth too since the next release of opkg is
> scheduled to June (too late for krogoth). I'll reply to your patch on
> the openembedded-core developer list to suggest it gets it's way into
> krogoth too.

This fix never landed in krogoth, and keeps making opkg look bad.

Best regards,
Stefan

[Alejandro del Castillo]

Armin: the following opkg patch was submitted for inclusion in krogoth,
but apparently never made it into the branch:

http://lists.openembedded.org/pipermail/openembedded-core/2016-April/120610.html

can you consider it for inclusion in krogoth? In my opinion, it does
meet the urgency bar to merit a backport.

--
Cheers,

Alejandro