Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 751652 - >=sys-apps/systemd-tmpfiles-246: keyword request
Summary: >=sys-apps/systemd-tmpfiles-246: keyword request
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Keywording (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Georgy Yakovlev
URL:
Whiteboard:
Keywords: CC-ARCHES, KEYWORDREQ
Depends on:
Blocks: CVE-2017-18925
  Show dependency tree
 
Reported: 2020-10-29 06:48 UTC by Georgy Yakovlev
Modified: 2021-08-21 22:16 UTC (History)
0 users

See Also:
Package list:
>=sys-apps/systemd-tmpfiles-246 alpha arm hppa ia64 ppc s390 sparc x86 mips m68k
Runtime testing required: ---
nattka: sanity-check+

Attachments
Failed "two words" test on mips (ip30-systemd_tmpfiles-failed-testsuite-20210705.txt,1.59 KB, text/plain)
2021-07-07 03:42 UTC, Joshua Kinard 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Georgy Yakovlev archtester gentoo-dev 2020-10-29 06:48:27 UTC 
Please keyword.
Thanks!
Comment 1 Georgy Yakovlev archtester gentoo-dev 2020-10-30 00:01:38 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.
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-30 01:59:23 UTC 
x86 done
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-30 02:01:06 UTC 
arm done
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-30 02:04:04 UTC 
sparc done
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-10-30 02:05:23 UTC 
ppc done
Comment 6 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-28 11:32:55 UTC 
~hppa keyworded
Comment 7 Matt Turner gentoo-dev 2020-12-10 02:12:33 UTC 
alpha done
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-12-13 00:11:41 UTC 
s390 done
Comment 9 Joshua Kinard gentoo-dev 2021-07-07 01:44:58 UTC 
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.
Comment 10 Georgy Yakovlev archtester gentoo-dev 2021-07-07 02:23:54 UTC 
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
Comment 11 Georgy Yakovlev archtester gentoo-dev 2021-07-07 02:29:58 UTC 
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
Comment 12 Joshua Kinard gentoo-dev 2021-07-07 02:33:27 UTC 
(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.
Comment 13 Georgy Yakovlev archtester gentoo-dev 2021-07-07 02:47:12 UTC 
yeah maybe nuking will help.
as well as just running /usr/sbin/build-docbook-catalog
it should re-gen files if those are outdated
Comment 14 Joshua Kinard gentoo-dev 2021-07-07 03:42:38 UTC 
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".
Comment 15 Georgy Yakovlev archtester gentoo-dev 2021-07-07 07:37:48 UTC 
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.
Comment 16 Joshua Kinard gentoo-dev 2021-07-07 14:45:43 UTC 
(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.
Comment 17 Joshua Kinard gentoo-dev 2021-07-07 15:13:28 UTC 
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.
Comment 18 Larry the Git Cow gentoo-dev 2021-07-08 06:38:25 UTC 
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(-)
Comment 19 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-07-21 02:48:56 UTC 
ia64 done
Comment 20 Larry the Git Cow gentoo-dev 2021-08-21 22:15:41 UTC 
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(-)