>> ## Result
>>
>> ### 1.
>>
>> ruby.spec:20: E: use-of-RPM_SOURCE_DIR
>> You use $RPM_SOURCE_DIR or %{_sourcedir} in your spec file. If you have to
>> use
>> a directory for building, use $RPM_BUILD_ROOT instead.
>>
>> =>
>> The `%{_sourcedir}/%{ruby_archive}.tar.xz` can be replaced to
>> `%{SOURCE0}`? I am not sure.
> Yes, I think so.
~~~
$ fedpkg srpm
stat: cannot statx
'/home/vondruch/fedora-scm/own/ruby/%{name}-3.0.0-684649ea05.tar.xz': No
such file or directory
warning: Macro expanded in comment on line 20: %(stat --printf='@%Y'
%{_sourcedir}/%{ruby_archive}.tar.xz | date -f - +"%Y%m%d")
stat: cannot statx '%{SOURCE0}': No such file or directory
stat: cannot statx
'/home/vondruch/fedora-scm/own/ruby/%{name}-3.0.0-684649ea05.tar.xz': No
such file or directory
warning: Macro expanded in comment on line 20: %(stat --printf='@%Y'
%{_sourcedir}/%{ruby_archive}.tar.xz | date -f - +"%Y%m%d")
stat: cannot statx '%{SOURCE0}': No such file or directory
setting SOURCE_DATE_EPOCH=1614643200
Wrote:
/home/vondruch/fedora-scm/own/ruby/ruby-3.0.0-0.146.git684649ea05.fc35.src.rpm
~~~
The order in .spec file could be possibly different, but there would be
probably different issues. But I am open to suggestions.
Humm, thanks for checking.
>> ### 2.
>>
>> ruby-default-gems.noarch: W: summary-ended-with-dot C Default gems
>> which are part of Ruby StdLib.
>> Summary ends with a dot.
>>
>> =>
>> The summary ending dot needs to be removed.
> Yes.
>
Good catch:
https://src.fedoraproject.org/rpms/ruby/c/dae90ef93d0f3eb43b09780368a236c...
Thanks!
>> ### 3.
>>
>> ruby-libs.x86_64: E: missing-call-to-chdir-with-chroot
>> /usr/lib64/libruby.so.3.0.0
>> This executable appears to call chroot without using chdir to change the
>> current directory. This is likely an error and permits an attacker to break
>> out of the chroot by using fchdir. While that's not always a security
issue,
>> this has to be checked.
>>
>> =>
>> Not sure when this error came.
> This is probably inside some generic Ruby code. IMHO this is a false positive.
>
> E.g.
https://www.rubydoc.info/stdlib/core/Dir.chroot
Very likely false positive. But feel free to investigate deeper.
OK.
>> ### 5.
>>
>> ```
>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-did_you_mean
>> If a package is obsoleted by a compatible replacement, the obsoleted package
>> should also be provided in order to not cause unnecessary dependency
>> breakage.
>> If the obsoleting package is not a compatible replacement for the old one,
>> leave out the Provides.
>>
>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-openssl
>> If a package is obsoleted by a compatible replacement, the obsoleted package
>> should also be provided in order to not cause unnecessary dependency
>> breakage.
>> If the obsoleting package is not a compatible replacement for the old one,
>> leave out the Provides.
>>
>> ruby-default-gems.noarch: W: obsolete-not-provided rubygem-racc
>> If a package is obsoleted by a compatible replacement, the obsoleted package
>> should also be provided in order to not cause unnecessary dependency
>> breakage.
>> If the obsoleting package is not a compatible replacement for the old one,
>> leave out the Provides.
>> ```
> It think this should not be a warning, but a mere INFO. Note the 'IF'.
>
>> =>
>> The Provides line needs for the Obsolete line.
> I don't think we want to create Provides for those, as those are
"Default" gems.
The Obsoletes/Provides are always tricky. I think these are fine as they
are.
Could you explain more about the Obsoletes/Provides are always tricky?
Maybe I do not understand "Provides" syntax well.
Do you know a helpful web page explaining it?
>> ### 6.
>>
>> ```
>> rubygem-rbs.noarch: E: non-executable-script
>> /usr/share/gems/gems/rbs-1.0.0/bin/annotate-with-rdoc 644 /usr/bin/env
>> ruby
>> This text file contains a shebang or is located in a path dedicated for
>> executables, but lacks the executable bits and cannot thus be executed. If
>> the file is meant to be an executable script, add the executable bits,
>> otherwise remove the shebang or move the file elsewhere.
>> ```
>>
>> This is the same for other files (total 8 files) under
>> /usr/share/gems/gems/rbs-1.0.0/bin/.
This is low priority. I think it would be actually better, if upstream
have not shipped these files at all, because these are in fact
development dependencies. But feel free submit PR fixing these (by
adding the executable bits probably).
OK.
>> ### 7.
>>
>> ```
>> ruby-libs.x86_64: W: library-not-linked-against-libc
>> /usr/lib64/ruby/continuation.so
>> ruby-libs.x86_64: W: library-not-linked-against-libc
>> /usr/lib64/ruby/enc/big5.so
>> ...
>> ```
>>
>> => I may remember this warning happened for 1 so file in Ruby 2.7 last
>> year. Now I see it for the many so files.
> Shouldn't be an issue, as it's linked against Ruby, right?
Likely false positive. There is a bit more detail here:
https://bugs.ruby-lang.org/issues/16558
OK. Thanks for the reference.
>> ## rpms/ruby CI to add rpmlint test.
>>
>> Can we check the rpmlint issues on an early timing: pull-request and push?
>> I think adding the rpmlint check ro rpm/ruby CI is a possible way
>> related to this ticket.
> Yes, I agree we could add this for the CI (functional). I'm not sure some
generic checks aren't considered already for all PRs- I'll inquire abou it and
follow up with you on IRC.
>
>>
https://src.fedoraproject.org/rpms/ruby/pull-request/67
>> Shall we add it after the PR #67 will be merged?
The Zuul is running rpmlint on PR. You can check the PR you've
referenced above.
That's good news. I can see the running rpmlint there.
https://src.fedoraproject.org/rpms/ruby/pull-request/78#comment-70514
rpm-linter : FAILURE in 7m 26s
container: Run rpmlint
rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm
But this rpmlint command is not enough. The rpmlint for the
`ruby.spec` should be added like this.
Where can we report this issue?
```
$ rpmlint /root/src/src.fedoraproject.org/rpms/ruby/*.rpm /path/to/*.spec
```
And I love to see all the SUCCESS results as a default. Because the
default green status makes us notice new issues easily.
I think it's time to create ruby.rpmlintrc.
Seeing the example of python3.9 package, it seems that we can
intentionally ignore the false positive errors/warnings for a specific
file
https://src.fedoraproject.org/rpms/python3.9/blob/rawhide/f/python3.9.rpm...
https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint
What do you think?
--
Jun | He - His - Him