Bug 266362 - ports-mgmt/portupgrade-devel: hangs at "Uninstalling the old version" phase
Summary: ports-mgmt/portupgrade-devel: hangs at "Uninstalling the old version" phase
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Eugene Grosbein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-09-11 13:24 UTC by Tomoaki AOKI
Modified: 2022-10-31 17:33 UTC (History)
8 users (show)

See Also:
fernape: maintainer-feedback? (bdrewery)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomoaki AOKI 2022-09-11 13:24:33 UTC
ports-mgmt/portupgrade-devel (maybe ports-mgmt/portupgrade, too) hangs at "Uninstalling the old version" phase on base main after git bced4d8b3e99efd46b5496c83e11755b25913c90.

Manually reverting the commit fixed the issue.

Not all ports seems to hang on upgrade, but at least graphics/libdrm, net/gupnp, graphics/vulkan-loader, graphics/sane-backends and graphics/poppler were affected.

/usr/local/sbin/pkg_deinstall, installed as a part of ports-mgmt/portupgrade[-devel] and used by /usr/local/sbin/portupgrade on "Uninstalling the old version", hangs waiting for `IO.popen("/usr/bin/file -bnf-", "r+") do |pipe|` to finish, maybe.

As the problematic commit seems to be cherry-picked (MFV) to fix something else, I'm not sure which should be fixed, base file or ports-mgmt/portupgrade[-devel].


For the record:
Output of `grep -n "file " /usr/local/sbin/pkg_deinstall` was as below.

105:    opts.def_option("-d", "--rmdir", "Remove empty directories created by file cleanup [*]") {
190:    PKGTOOLS_CONF            configuration file [$PREFIX/etc/pkgtools.conf]
341:      raise PkgDB::DBError, "The file #{path} is not properly recorded as installed"
344:      raise PkgDB::DBError, "The file #{path} is not properly recorded as installed by #{pkgname}"
380:    IO.popen("/usr/bin/file -bnf-", "r+") do |pipe|
382:    %r"^[^@\s]\S*/([^/\s]+\.so(?:\.\d+)+)$" =~ file or next
Comment 1 Tomoaki AOKI 2022-09-15 09:28:04 UTC
Bug 266386 seems to be a duplicate of this.
Added to "See also".
Comment 2 Tomoaki AOKI 2022-09-15 09:38:46 UTC
Can upstream PR/374: Endless busyloop in file_mbswidth [1] related to this?
If so, can updating to file 5.43 fixes this?


[1] https://bugs.astron.com/view.php?id=374
[2] https://bugs.astron.com/my_view_page.php
Comment 3 Terry Kennedy 2022-09-23 20:35:25 UTC
Subscribing because I'm seeing this too.
Comment 4 Tomoaki AOKI 2022-09-30 19:15:45 UTC
(In reply to Tomoaki AOKI from comment #2)

The file utility was updated to 5.43 on src main and stable/13 at
  main:      a2dfb7224ec9933ee804cae54d51848dce938b6b
  stable/13: dc9893d19419f16234ee9a4b4454f31e09d9b292
respectively, but unfortunately didn't fix the problem.

Still needs the patch proposed at Bug 266386.
You can create ports-mgmt/portupgrade-devel/files directory, and store the second (latest, mine) patch proposed at Bug 266386 [1] there, and forcibly update ports-mgmt/portupgrade-devel.

Or apply the first (older, by Katsuyuki Miyoshi) patch [2] over /usr/local/sbin/pkg_deinstall directly.

See Bug 266386 Comment 11 and following comments for more detail.

[1] https://bz-attachments.freebsd.org/attachment.cgi?id=236783

[2] https://bz-attachments.freebsd.org/attachment.cgi?id=236672
Comment 5 Terry Kennedy 2022-10-21 01:13:37 UTC
Can someone with modify privs on this bug change Component to "Package Infrastructure" and Importance to "Affects many people" in an attempt to raise this PR's visibility to developers who might be able to address the issue?

This PR has been open for nearly a month and a half and I have a few dozen systems that have backlogs of portupgrades to do, some security-related. I know I could try to patch to work around this, but the idea is to end up with a more standard system, not less.

Thanks!
Comment 6 Mark C 2022-10-26 06:33:48 UTC
I'm seeing this too, when trying to upgrade most ports.
Comment 7 Terry Kennedy 2022-10-26 06:41:44 UTC
(In reply to Mark C from comment #6)
This is fixed by a change to base, as described here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267221

The reason it hasn't impacted more people is probably because they're on various 12.3-pX versions, not -STABLE. It is only going to hit people running world at r372587 or higher. I didn't check to see when it landed in 13.
Comment 8 Mark C 2022-10-26 07:15:21 UTC
(In reply to Terry Kennedy from comment #7)
Great, thanks.  Yes, I'm on -STABLE. While I wait for the fix to make it to STABLE, I've applied the patch in:

https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236783

from

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266386

and that seems to make things work for now.
Comment 9 Fernando Apesteguía freebsd_committer freebsd_triage 2022-10-27 09:01:43 UTC
This has been recently committed:

https://cgit.freebsd.org/src/commit/?id=07dfb236c81483c2f08a3976f6d44ce307f4ceaf

It should be MFC'ed really soon.

Could you try that if you are running -CURRENT and in 3 days if you are running -STABLE?

Thanks!
Comment 10 Mark C 2022-10-27 12:34:27 UTC
Thanks, I'll check once it makes it into STABLE.
Comment 11 Tomoaki AOKI 2022-10-27 12:47:21 UTC
(In reply to Fernando Apesteguía from comment #9)

Manually cherry-picked the commit to stable/13 with backing out the patch to pkg_deinstall (proposed on Bug 266386) worked fine for me. Thanks!

 *Rebuilt and installed on usr.sbin/file/. No reboot.
Comment 12 Fernando Apesteguía freebsd_committer freebsd_triage 2022-10-30 10:27:00 UTC
The patch is in stable. This should be fixed now.
Comment 13 Eugene Grosbein freebsd_committer freebsd_triage 2022-10-31 00:32:26 UTC
Fixed in all supported branches restoring regression in file(1) utility. The fix will be included in upcoming 12.4-RC1 and 12.4-RELEASE.
Comment 14 Fernando Apesteguía freebsd_committer freebsd_triage 2022-10-31 17:33:44 UTC
^Triage: assigning to committer who resolved the issue

Note: at least by affinity :-)