Bug 258721
| Summary: | print/freetype2: does not package on main armv6 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Martin Birgmeier <d8zNeCFG> | ||||
| Component: | Individual Port(s) | Assignee: | freebsd-desktop (Team) <desktop> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Only Me | CC: | diizzy, jcfyecrayz | ||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(desktop) |
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
This doesn't appear to be something new as the old version also failed https://lists.freebsd.org/archives/freebsd-pkg-fallout/2021-September/105389.html (armv6) https://lists.freebsd.org/archives/freebsd-pkg-fallout/2021-September/110194.html (armv7) This is strange - here the previous upgrade to 2.10.4 worked without problems. -- Martin Can you try to use a WRKDIRPREFIX that does not have a sym link? Maybe just define WRKDIRPREFIX to be `realpath $WRKDIRPREFIX`. It looks like in your build /d is a sym link to /usr/tmp/d (or the other way around). I think trying to use cpio (with which COPYTREE_SHARE is implemented) to extract to a directory containing sym links some implementations of cpio do not know how to handle that very well. (In reply to John Hein from comment #3) p.s. Normally 'cpio -dumpl' should created any destination directories that don't exist. You are right, there are some symlinks in the WRKDIRPREFIX. I have now circumvented the issue by disabling DOCS. For the time being I am closing this report. -- Martin |
Created attachment 228175 [details] portmaster logfile when building print/freetype2 Scenario: - FreeBSD main at 08b9cc316a319fba95af8bb13b262fe0d5526ec3 - latest ports - using portmaster to upgrade freetype2 from 2.10.4 to 2.11.0 - using qemu-arm-static and also native on a Raspberry Pi B+ Result: - Packaging fails with a missing staging directory "/usr/local/share/doc/freetype2" - Log file attached Notes: - The portmaster runs succeeded on 12.2 (latest) amd64 and i386, and on main 08b9cc316a319fba95af8bb13b262fe0d5526ec3 on amd64 -- Martin