To reproduce, comment the last ${REINPLACE_CMD} call in post-install target of the devel/tortoisehg port. With the line commented, `make check-plist` results in Missing: share/pixmaps/tortoisehg/icons/16x16 Missing: share/pixmaps/tortoisehg/icons/22x22 ... Missing: share/pixmaps/tortoisehg/icons/scalable
autoplist uses setuptools --record output to produce the pkg-plist. This can be verified by looking at the various plist files in the $WRKDIR post-install All else being equal, it's very likely these files aren't packaged correctly upstream, in the sense that they aren't in the --record output, due to being 'specially handled' in some way. The usual method this takes place is custom build* or install* methods in setup.py, that override or replace the defaults in setuptools, which fail to add the files being processed to setuptools output files list that's used in --record output. Workaround: pkg-plist entries can be used in combination (complementary to) autoplist, so put those "missing" pkg-plist entries there, if they arent already, until the root cause is identified and resolved.
Here's one example where VERSION (file) wasn't in --record output due to upstreams use of a custom install_data method, subclassing the default (setuptools) "install_data" method: https://github.com/buildbot/buildbot/pull/8/commits/86a599b102bbcf67f4daf0438ba1b5feef7a29a7 See also: https://github.com/search?q=%22outfiles%22+setup.py&type=code (probably handy)
Ok, if this isn't our bug, let's close this.
It can be worked around either with adding those missing entries to pkg-plist, or fixing the setup.py (until upstream resolves)
Closing, as it is not our bug, but an upstream one. Reported it here: https://foss.heptapod.net/mercurial/tortoisehg/thg/-/issues/5705
We can and should fix the bug our end until upstream does. The fix here is to add the files to pkg-plist (autoplist and pkg-plist are complementary/cumulative, and can be used together)
@Gleb If you're not keen to resolve the issue (add the pkg-plist entries) feel free to re-assign to me or python@
(In reply to Kubilay Kocak from comment #7) It'd great if you do that!
Wait, I probably understood you wrong. I already worked around this problem in our ports tree, but delegated proper fix to upstream. Are willing to submit a proper fix?
Looks like this was resolved in ports r548242 via bug 249160 @Gleb If that's indeed the correct changeset, we consider the bug report (of the packaging failure) 'closed -> FIXED', as it was fixed via a change (commit), and feel free to close if so. I'm think its fine to wait for upstream to correct it while we carry local patches that resolves downstream.
(In reply to Kubilay Kocak from comment #10) > @Gleb If that's indeed the correct changeset, we consider the bug report (of the packaging failure) 'closed -> FIXED', as it was fixed via a change (commit), and feel free to close if so. That's correct, closing it.