<div dir="ltr"><div>sbopkglint is fine -- it complains exactly as it should. I built<br>rubygem-ast (orphaned, no deps, unmodified doc pipeline) and linted it:<br><br>  Running test: 10-docs...<br>  --- ERR: bad ownership (should be root:root) in doc dir:<br>  -rw-r--r-- 1 root wheel 1089 Jan 23  2021 usr/doc/rubygem-ast-2.4.2/LICENSE.MIT<br>  -rw-r--r-- 1 root wheel  482 Jan 23  2021 usr/doc/rubygem-ast-2.4.2/<a href="http://README.YARD.md">README.YARD.md</a><br>  FAILED<br><br>So a new rubygem submission written to the current template fails the<br>lint we tell submitters to run. That's the whole of the problem.<br><br>I need to correct my own explanation, though: it's not the packager's<br>uid, it's the group, and it's hardcoded. Every entry in a gem is<br>recorded with the *name* wheel:<br><br>  $ tar -x -O --file=ast-2.4.2.gem data.tar.gz | tar -tvz<br>  -rw-r--r-- wheel/wheel    1089 2021-01-23 20:56 LICENSE.MIT<br>  -rw-r--r-- wheel/wheel     482 2021-01-23 20:56 <a href="http://README.YARD.md">README.YARD.md</a><br>  -rw-r--r-- wheel/wheel     586 2021-01-23 20:56 lib/ast.rb<br>  [...]<br><br>RubyGems' tar_header.rb defaults uname and gname to "wheel" and never<br>sets uid/gid, so gems carry uid 0 / gid 0 / uname wheel / gname wheel.<br>GNU tar as root resolves the names before the numbers unless you give it<br>--numeric-owner. There's no wheel user, so uid falls back to 0 -> root.<br>There is a wheel group -> root:wheel.<br><br>What makes it unambiguous is that the gem records wheel/wheel for<br>*every* file, including lib/*.rb -- but those come out root:root in the<br>package, because gem install writes them itself. Only the files that go<br>through tar are affected. Same build, same source archive:<br><br>  drwxr-xr-x root/root   usr/doc/rubygem-ast-2.4.2/<br>  -rw-r--r-- root/wheel  usr/doc/rubygem-ast-2.4.2/LICENSE.MIT<br>  -rw-r--r-- root/wheel  usr/doc/rubygem-ast-2.4.2/<a href="http://README.YARD.md">README.YARD.md</a><br>  -rw-r--r-- root/root   usr/doc/rubygem-ast-2.4.2/rubygem-ast.SlackBuild<br><br>The SlackBuild in that same directory is root:root because it's written<br>with cat. 2 offending entries out of 73.<br><br>rubygem-template is the only template with no "chown -R root:root ."<br>anywhere, and that second tar is the one place in it where ownership is<br>restored from an archive rather than created by the process doing the<br>writing. --no-same-owner (or --numeric-owner) on that line fixes it.<br><br></div>ps. I used a translation tool and hope everything is ok now :)</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Στις Δευ 10 Αυγ 2026 στις 12:37 μ.μ., ο/η B. Watson <<a href="mailto:urchlay@slackware.uk">urchlay@slackware.uk</a>> έγραψε:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On Mon, 10 Aug 2026, Yiannis wrote:<br>
<br>
> --no-same-owner: yes, this works.<br>
> It does exactly what "chown -R root:root ." does, symlinks included.<br>
> Both leave every entry root:root, and both leave the symlink's target<br>
> outside the tree untouched -- chown -R defaults to -P, so it lchown()s<br>
> the link rather than following it. I could not find a case where they<br>
> differ. The option predates any Slackware we still support, so its age<br>
> isn't a concern.<br>
<br>
Thanks for this analysis.<br>
<br>
> One place where --no-same-owner is a bug fix, not a simplification ruby/ as example look here:<br>
> <a href="https://git.slackbuilds.org/slackbuilds/tree/ruby/rubygem-parallel/rubygem-parallel.SlackBuild?h=15.0&id=608168806da9306799ec6aec884828f38a85e8d4" rel="noreferrer" target="_blank">https://git.slackbuilds.org/slackbuilds/tree/ruby/rubygem-parallel/rubygem-parallel.SlackBuild?h=15.0&id=608168806da9306799ec6aec884828f38a85e8d4</a><br>
> <br>
> rubygem-template has no chown/find pass at all, but it does this:<br>
>   tar -x -O --file=$CWD/$SRCNAM-$VERSION.gem data.tar.gz \<br>
>     | tar -xz -C $PKGDOC --file=- <documentation><br>
> <br>
> That second tar runs as root with --same-owner in effect, writes<br>
> straight into $PKG, and nothing corrects it afterwards. If built a<br>
> synthetic gem to check: the doc file landed in $PKGDOC owned by the<br>
> upstream packager's uid, and that's what makepkg ships. Adding<br>
> --no-same-owner to that second tar fixes it. Worth doing regardless of<br>
> what happens to the rest of this.<br>
<br>
Interesting. So we have a bunch of ruby/ packages that fail<br>
sbopkglint? It really should complain about those... bug or just an<br>
oversight, maybe.<br>
<br>
> --no-same-permissions: no! this one doesn't hold up.<br>
> umask can only clear bits, never set them, so it can't do the job the<br>
> find/chmod block exists for.<br>
<br>
Right. I looked into it and found the same thing.<br>
<br>
> The question is, is it worth the effort to change a few thousand SlackBuilds for no real reason?<br>
>  I mean, if it's just to change `chown -R root:root .` with `tar --no-same-owner -xvf ...`<br>
<br>
No, I'm not talking about changing every existing script.<br>
<br>
I'm talking about changing the template. New builds will be<br>
based on the new template, but we're not going to change existing<br>
(working!) builds just to update to the new template. You're right,<br>
it wouldn't be worth the effort.<br>
<br>
If this becomes the new template, we'll encourage maintainers to make<br>
this change in their scripts, when they're already in the process of<br>
updating them (e.g. a version update, editing the script anyway, might<br>
as well align it with the latest template), but we won't *require* it.<br>
<br>
> I would suggest you focus on SBo/ruby/* for that alone.<br>
<br>
I'll have a look._______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div>