https://bugzilla.redhat.com/show_bug.cgi?id=1773720 Brandon Perkins <bperkins@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(bperkins@redhat.c | |om) | --- Comment #10 from Brandon Perkins <bperkins@xxxxxxxxxx> --- (In reply to Ryan O'Hara from comment #9) > > [ ]: License file installed when any subpackage combination is installed. > > - The license is definitely installed with the regular rpm and/or the -devel > package. Does this requirement also apply to debuginfo and debugsource > packages? I'm going to assume not. > So, this is a great question that, AFAICT has not been resolved: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx/thread/V3JDB74XPJQVNWO7SJVVDYFP3AR6GQD4/ and I don't get clarity from: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Subpackage_Licensing or https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/ I would say that we defer to the auto-generation done by the macros which appears to not include it. > [ ]: Package must own all directories that it creates. > Note: Directories without known owners: /etc/logrotate.d > > - I don't think this is optional. Having the "suggests" line is the spec > seems ok, but this package is creating a directory with no owner. > The /etc/logrotate.d directory is owned by the 'logrotate' package: $ rpm -qf /etc/logrotate.d logrotate-3.15.1-1.fc31.x86_64 This issue is properly satisfied by the logrotate 'Suggests' in the RPM: $ grep ^Suggests: SPECS/golang-github-haproxytech-dataplaneapi.spec Suggests: logrotate $ rpm -qp --suggests RPMS/golang-github-haproxytech-dataplaneapi-1.2.4-5.fc31.x86_64.rpm logrotate To me, it's better to have a possible orphan directory than to have this package become the owner of the directory. And, we certainly wouldn't be the first to go down this path. Quick query shows me: [bperkins@bperkins haproxytech]$ dnf repoquery --queryformat="%{NAME}" --whatsuggests logrotate mariadb-server plymouth However, many more do the ownership thing (which just seems wrong to me): [bperkins@bperkins haproxytech]$ dnf repoquery --queryformat="%{NAME}" --whatprovides /etc/logrotate.d bes copr-dist-git gap-pkg-scscp gerbera kdm-settings lightdm logrotate macromilter openqa ppp psad samba-common sssd-common yast2-filesystem Or, we could go down what I *really* think is wrong and just ignore the issue completely (which is by far the most popular path). I'm personally inclined to do what I did, but I can certainly change it. > [ ]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: > > - This seems like an issue with all Go modules, as mentioned above. > > [ ]: Fully versioned dependency in subpackages if applicable. > Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in golang- > github-haproxytech-dataplaneapi-devel > > - Can we do this? I know upstream is versioning the releases of the various > dataplaneapi components. I'm not sure if this works for go packages. > Using the %gopkg macro, I don't see how this could be accomplished. This really doesn't seem like a critical requirement to me. > > Rpmlint > ------- > Checking: golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.x86_64.rpm > > golang-github-haproxytech-dataplaneapi-devel-1.2.4-6.fc33.noarch.rpm > > golang-github-haproxytech-dataplaneapi-debuginfo-1.2.4-6.fc33.x86_64.rpm > > golang-github-haproxytech-dataplaneapi-debugsource-1.2.4-6.fc33.x86_64.rpm > golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.src.rpm > golang-github-haproxytech-dataplaneapi-devel.noarch: W: hidden-file-or-dir > /usr/share/gocode/src/github.com/haproxytech/dataplaneapi/.goipath > golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E: > description-line-too-long C This package provides debug sources for package > golang-github-haproxytech-dataplaneapi. > 5 packages and 0 specfiles checked; 1 errors, 1 warnings. > > > > > Rpmlint (debuginfo) > ------------------- > Checking: > golang-github-haproxytech-dataplaneapi-debuginfo-1.2.4-6.fc33.x86_64.rpm > 1 packages and 0 specfiles checked; 0 errors, 0 warnings. > > > > > > Rpmlint (installed packages) > ---------------------------- > perl: warning: Setting locale failed. > perl: warning: Please check that your locale settings: > LANGUAGE = (unset), > LC_ALL = (unset), > LC_CTYPE = "C.UTF-8", > LANG = "en_US.UTF-8" > are supported and installed on your system. > perl: warning: Falling back to the standard locale ("C"). > perl: warning: Setting locale failed. > perl: warning: Please check that your locale settings: > LANGUAGE = (unset), > LC_ALL = (unset), > LC_CTYPE = "C.UTF-8", > LANG = "en_US.UTF-8" > are supported and installed on your system. > perl: warning: Falling back to the standard locale ("C"). > golang-github-haproxytech-dataplaneapi.x86_64: W: invalid-url URL: > https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name > or service not known> > golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E: > description-line-too-long C This package provides debug sources for package > golang-github-haproxytech-dataplaneapi. > golang-github-haproxytech-dataplaneapi-debugsource.x86_64: W: invalid-url > URL: https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] > Name or service not known> > golang-github-haproxytech-dataplaneapi-debuginfo.x86_64: W: invalid-url URL: > https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name > or service not known> > golang-github-haproxytech-dataplaneapi-devel.noarch: W: invalid-url URL: > https://github.com/haproxytech/dataplaneapi <urlopen error [Errno -2] Name > or service not known> > golang-github-haproxytech-dataplaneapi-devel.noarch: W: hidden-file-or-dir > /usr/share/gocode/src/github.com/haproxytech/dataplaneapi/.goipath > 4 packages and 0 specfiles checked; 1 errors, 5 warnings. > > - I'd love to fix the URL issue since we've seen that in every package we've > reviewed for the dataplaneapi effort. Probably more important is the error > regarding the description line is too long. URL issue can be dealt with by running it semi-manually: $ sudo mkdir -p /var/lib/mock/fedora-rawhide-x86_64/root/root/.config $ echo "addFilter(r\"hidden-file-or-dir /usr/share/gocode/src/github\.com/.*/.*/.goipath$\")" > /tmp/rpmlint.config $ sudo cp /tmp/rpmlint.config /var/lib/mock/fedora-rawhide-x86_64/root/root/.config/rpmlint $ LANG=C.utf8 mock -q -r fedora-rawhide-x86_64 --no-bootstrap-chroot --no-cleanup-after --no-clean --enable-network --chroot -- rpmlint -f /root/.config/rpmlint golang-github-haproxytech-dataplaneapi golang-github-haproxytech-dataplaneapi-debuginfo golang-github-haproxytech-dataplaneapi-debugsource golang-github-haproxytech-dataplaneapi-devel golang-github-haproxytech-dataplaneapi-debugsource.x86_64: E: description-line-too-long C This package provides debug sources for package golang-github-haproxytech-dataplaneapi. 4 packages and 0 specfiles checked; 1 errors, 0 warnings. However, it does still show the line too long problem. > > # rpm -qip > golang-github-haproxytech-dataplaneapi-debugsource-1.2.4-6.fc33.x86_64.rpm > Name : golang-github-haproxytech-dataplaneapi-debugsource > Version : 1.2.4 > Release : 6.fc33 > Architecture: x86_64 > Install Date: (not installed) > Group : Development/Debug > Size : 2785503 > License : ASL 2.0 > Signature : (none) > Source RPM : golang-github-haproxytech-dataplaneapi-1.2.4-6.fc33.src.rpm > Build Date : Mon 13 Apr 2020 01:20:34 PM CDT > Build Host : wilco > URL : https://github.com/haproxytech/dataplaneapi > Summary : Debug sources for package > golang-github-haproxytech-dataplaneapi > Description : > This package provides debug sources for package > golang-github-haproxytech-dataplaneapi. > Debug sources are useful when developing applications that use this > package or when debugging this package. > > - So that looks too long: > > # echo "This package provides debug sources for package > golang-github-haproxytech-dataplaneapi." | wc -c > 88 > > - Can we shorten this? rpmlint sees this as an error. > Because of using the %gopkg macro, we're kind of stuck with what it creates. Outside of modifying the macro (which is a non-starter), the only thing that could be done would be to shorten the package name, which is also a non-starter. I think it's an error we just have to live with. Unless you have any other thoughts. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
