> >> ## 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/dae90ef93d0f3eb43b09780368a236cb4f2b850f?branch=rawhide 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.rpmlintrc https://fedoraproject.org/wiki/Taskotron/Tasks/dist.rpmlint What do you think? -- Jun | He - His - Him _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
