Summary: | >=sys-apps/systemd-tmpfiles-246: keyword request | ||||||
---|---|---|---|---|---|---|---|
Product: | Gentoo Linux | Reporter: | Georgy Yakovlev <gyakovlev> | ||||
Component: | Keywording | Assignee: | Georgy Yakovlev <gyakovlev> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | normal | Keywords: | CC-ARCHES, KEYWORDREQ | ||||
Priority: | Normal | Flags: | nattka:
sanity-check+
|
||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Package list: |
>=sys-apps/systemd-tmpfiles-246 alpha arm hppa ia64 ppc s390 sparc x86 mips m68k
|
Runtime testing required: | --- | ||||
Bug Depends on: | |||||||
Bug Blocks: | 751415 | ||||||
Attachments: |
|
Description
Georgy Yakovlev
2020-10-29 06:48:27 UTC
I've enabled proper tests, so please run tests. should obviously work fine on all arches systemd is keyworded on, but let's get it done properly. x86 done arm done sparc done ppc done ~hppa keyworded alpha done s390 done I am unable to compile systemd-tmpfiles on mips at the moment. It looks like xsltproc is failing to fetch an external resource because it gets passed the --nonet flag, so it fails immediately: /usr/bin/xsltproc -o man/systemd-tmpfiles.8 --nonet --xinclude --maxdepth 9000 --stringparam man.output.quietly 1 --stringparam funcsynopsis.style ansi --stringparam man.authors.section.enabled 0 --stringparam man.copyright.section.enabled 0 --stringparam systemd.version 248 --path /usr/obj/portage/sys-apps/systemd-tmpfiles-248.3/work/systemd-tmpfiles-248.3-build/man:/usr/obj/portage/sys-apps/systemd-tmpfiles-248.3/work/systemd-stable-248.3/man ../systemd-stable-248.3/man/custom-man.xsl ../systemd-stable-248.3/man/systemd-tmpfiles.xml I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" compilation error: file ../systemd-stable-248.3/man/custom-man.xsl line 12 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl I tried running the command manually and removing --nonet, which seems to fix the issue, though it does take its time and one just has to be patient. I have the required app-text/docbook-xml-dtd and app-text/docbook-xsl-stylesheets packages installed, so I am not sure why it is attempting to fetch these resources externally. I don't know much about docbook and xml scares me, but on my system
redirects seem to be working
from /etc/xml/catalog
> <delegateSystem systemIdStartString="http://docbook.sourceforge.net/release/xsl/" catalog="file:///etc/xml/docbook"/>
> <delegateURI uriStartString="http://docbook.sourceforge.net/release/xsl/" catalog="file:///etc/xml/docbook"/>
installed slots of app-text/docbook-xml-dtd are:
4.1.2
4.2
4.4
4.5
removed all but 4.2 and 4.5 and still works qlist -Iv | grep -E "xml|xslt" app-text/docbook-xml-dtd-4.5-r2 app-text/docbook-xml-dtd-4.2-r3 app-text/xmlto-0.0.28-r6 dev-libs/libxml2-2.9.12-r3 dev-libs/libxslt-1.1.34-r1 dev-python/lxml-4.6.3-r1 (In reply to Georgy Yakovlev from comment #10) > I don't know much about docbook and xml scares me, but on my system > redirects seem to be working > > from /etc/xml/catalog > > > <delegateSystem systemIdStartString="http://docbook.sourceforge.net/release/xsl/" catalog="file:///etc/xml/docbook"/> > > <delegateURI uriStartString="http://docbook.sourceforge.net/release/xsl/" catalog="file:///etc/xml/docbook"/> > > > installed slots of app-text/docbook-xml-dtd are: > > 4.1.2 > 4.2 > 4.4 > 4.5 Yeah, my amd64 system had no issues. I checked the installed packages it has with what is on the mips machine, and they are vortually identical. Ditto for /etc/xml/catalog's contents. I am going to try the nuke-it-from-orbit approach and just remove anything docbook and re-install those packages in case something went missing. yeah maybe nuking will help. as well as just running /usr/sbin/build-docbook-catalog it should re-gen files if those are outdated Created attachment 722485 [details]
Failed "two words" test on mips
Yup, nuking it from orbit fixed whatever was wrong, so it finally compiled.
Tried running the testsuite, it went through a few of them, but then failed on the "two words" test. See the attached text file with the error.
It does not look like anything related to the actual machine architecture, so it is either something related to this system being split-/usr, or the portage tree is mounted over NFSv4. The return code was 73, which looks like EDOTDOT. Not much to go on there, and the comment in the headers (/usr/include/asm-generic/errno.h) says "RFS specific error".
indeed, looks like it depends on fs layouyt/symlinking and it detects something it does not like. is there any extra symlinks involved? I can't quite figure it out. https://github.com/systemd/systemd-stable/commit/7f0704da9454d36d19920e033ddadf06c9c6441e could you test it on a flatter layout without separate usr or extra symlinks? I think pointing PORTAGE_TMPDIR somewhere flatter, without symlinks will work. or maybe simply try using bind-mount instead of symlinks. it will make syscalls canonicalize paths differently, I think. (In reply to Georgy Yakovlev from comment #15) > indeed, > looks like it depends on fs layouyt/symlinking and it detects something it > does not like. > > is there any extra symlinks involved? I can't quite figure it out. > > https://github.com/systemd/systemd-stable/commit/ > 7f0704da9454d36d19920e033ddadf06c9c6441e > > could you test it on a flatter layout without separate usr or extra symlinks? > > I think pointing PORTAGE_TMPDIR somewhere flatter, without symlinks will > work. > > or maybe simply try using bind-mount instead of symlinks. > it will make syscalls canonicalize paths differently, I think. I think I have an idea of the problem. It's tied to me having sandbox disabled, but still having /usr/obj/portage owned by portage:portage. If I turn the sandboxing options back on in FEATURES, but keep 'usersandbox' disabled, then the 'test' phase will complete without issue. But it looks like there's some bugs with sandbox on mips that are cropping up again that I forgot about, which is probably why I turned sandbox off in the first place. I'll add the keywords to sys-apps/systemd-tmpfiles later today. Already did a install on the mips machine and gave it a full boot cycle, and it boots fine, so the base functionality works. And a rebuild of sandbox resolves all remaining issues. Sandbox is fully-enabled now, and the test phase of sys-apps/systemd-tmpfiles passes without error. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=836b0a12615dd4d076432fea78430f7b0c885a2a commit 836b0a12615dd4d076432fea78430f7b0c885a2a Author: Joshua Kinard <kumba@gentoo.org> AuthorDate: 2021-07-08 06:38:00 +0000 Commit: Joshua Kinard <kumba@gentoo.org> CommitDate: 2021-07-08 06:38:00 +0000 sys-apps/systemd-tmpfiles: Added ~mips to KEYWORDS Bug: https://bugs.gentoo.org/751652 Signed-off-by: Joshua Kinard <kumba@gentoo.org> Package-Manager: Portage-3.0.20, Repoman-3.0.3 sys-apps/systemd-tmpfiles/systemd-tmpfiles-248.3.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ia64 done The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d31d9a9d59be4b73f2d531fce5749c0b9c23859f commit d31d9a9d59be4b73f2d531fce5749c0b9c23859f Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2021-08-21 16:14:18 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2021-08-21 22:15:15 +0000 sys-apps/systemd-tmpfiles: Keyword 249.2 for ~m68k The tests pass. Closes: https://bugs.gentoo.org/751652 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: James Le Cuirot <chewi@gentoo.org> sys-apps/systemd-tmpfiles/systemd-tmpfiles-249.2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |