Bug 1447517

> The spec file will likely require cleanup.  It's grown into a complex mess 

Indeed.

It will be very hard to find a reviewer for such a package, less a reviewer who would approve the package.

Please focus on building a small and easy to maintain Fedora package that attempts at following Fedora's packaging guidelines. Avoid all the superfluous "complex mess". Use Mock for doing local test-builds. No need to worry about Koji yet, which also uses Mock under the hood.

Per your suggestion, I have created a simple ddcutil.spec file for use only when creating Fedora distribution packages (i.e. no OBS, no SuSE).  The spec file creates only the standalone application version of ddcutil, not the shared library version, which is still subject to significant changes. 

The relevant updated URLs:

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.8.3-1.fc25.src.rpm

The package builds successfully for all available architectures and releases using mock locally, COPR, and as Koji scratch builds.  However, given that it performs low level I2c communication, it requires testing to verify that it works properly on alternative architectures.  Raspberry Pi users (aarch64) have reported success with the upstream version.  I'm unsure how to address this issue, so the spec file contains several ExcludeArch statements that are commented out, allowing ddcutil to at least build on the alternative architectures for now.  ddcutil builds only for Fedora releases, not EPEL. Mageia, etc.

Informal (UNOFFICIAL) Package Review
====================================
Thanks, great util, just two issues:
- package should own directories /usr/share/doc/ddcutil and /usr/share/ddcutil - should be added into %files section
- hidden directory usr/lib/.build-id should be removed

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Header files in -devel subpackage, if present.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "MIT/X11 (BSD like)", "GPL", "GPL (v2 or later)", "Unknown or
     generated", "BSD (3 clause)". 64 files have unknown license. Detailed
     output of licensecheck in /home/jkalina/Downloads/review-
     ddcutil/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[-]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/ddcutil/data,
     /usr/share/doc/ddcutil, /usr/share/ddcutil
[!]: Package must own all directories that it creates.
     Note: Directories without known owners: /usr/share/doc/ddcutil,
     /usr/share/ddcutil, /usr/share/ddcutil/data
[x]: %build honors applicable compiler flags or justifies otherwise: use macros
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[x]: Each %files section contains %defattr if rpm < 4.4
     Note: %defattr present but not needed
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target. (except mentioned /usr/lib/.build-id)
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 4 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: All build dependencies are listed in BuildRequires, except for any
     that are listed in the exceptions section of Packaging Guidelines.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[ ]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in ddcutil-
     debuginfo
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[?]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: ddcutil-0.8.3-1.fc27.x86_64.rpm
          ddcutil-debuginfo-0.8.3-1.fc27.x86_64.rpm
          ddcutil-0.8.3-1.fc27.src.rpm
ddcutil.x86_64: W: only-non-binary-in-usr-lib
ddcutil.x86_64: W: hidden-file-or-dir /usr/lib/.build-id
ddcutil.x86_64: W: hidden-file-or-dir /usr/lib/.build-id
3 packages and 0 specfiles checked; 0 errors, 3 warnings.




Rpmlint (debuginfo)
-------------------
Checking: ddcutil-debuginfo-0.8.3-1.fc27.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.





Rpmlint (installed packages)
----------------------------
sh: /usr/bin/python: No such file or directory
ddcutil.x86_64: W: only-non-binary-in-usr-lib
ddcutil.x86_64: W: hidden-file-or-dir /usr/lib/.build-id
ddcutil.x86_64: W: hidden-file-or-dir /usr/lib/.build-id
2 packages and 0 specfiles checked; 0 errors, 3 warnings.



Requires
--------
ddcutil (rpmlib, GLIBC filtered):
    libX11.so.6()(64bit)
    libXrandr.so.2()(64bit)
    libc.so.6()(64bit)
    libdl.so.2()(64bit)
    libdrm.so.2()(64bit)
    libglib-2.0.so.0()(64bit)
    libudev.so.1()(64bit)
    libudev.so.1(LIBUDEV_183)(64bit)
    libusb-1.0.so.0()(64bit)
    rtld(GNU_HASH)

ddcutil-debuginfo (rpmlib, GLIBC filtered):



Provides
--------
ddcutil:
    ddcutil
    ddcutil(x86-64)

ddcutil-debuginfo:
    ddcutil-debuginfo
    ddcutil-debuginfo(x86-64)



Source checksums
----------------
http://www.ddcutil.com/ddcutil-0.8.3.tar.gz :
  CHECKSUM(SHA256) this package     : 8d3b4650999849a346e2741287e253aba86eac59ba2da39ea65fd7633de9c507
  CHECKSUM(SHA256) upstream package : 8d3b4650999849a346e2741287e253aba86eac59ba2da39ea65fd7633de9c507


Generated by fedora-review 0.6.1 (f03e4e7) last change: 2016-05-02
Command line :/usr/bin/fedora-review -u https://bugzilla.redhat.com/show_bug.cgi?id=1447517
Buildroot used: fedora-rawhide-x86_64
Active plugins: Generic, Shell-api, C/C++
Disabled plugins: Java, Python, fonts, SugarActivity, Ocaml, Perl, Haskell, R, PHP
Disabled flags: EXARCH, DISTTAG, EPEL5, BATCH, EPEL6

Per Jan's review, the %files section has been changed so that package ddcutil owns directories /usr/share/doc/ddcutil and /usr/share/ddcutil.

I believe the rpmlint complaint about hidden directory /usr/lib/.build-id is a false positive.   See https://bugzilla.redhat.com/show_bug.cgi?id=1431408. 

The updated file locations are: 

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.8.4-1.fc25.src.rpm

New Spec and SRPM files to reflect recent upstream release 0.8.5.  For a description of changes, see http://www.ddcutil.com/release_notes.

Updated file locations:

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.8.5-1.fc27.src.rpm

 - Not sure what is this for:

rpm --version
rpmbuild --version

 - make DESTDIR=%{buildroot} install → %make_install

 - no need for %attr(755,root,root)' just:

%{_bindir}/ddcutil

 - Since you're upstream, it would be best if your install script doesn't install anything in docdir. It's better to do it in %files like this:

%doc     AUTHORS NEWS.md README.md ChangeLog
%license COPYING

Files will then be copied automatically.
I don't know what's needed for other distro though so maybe it's not possible.

(In reply to Robert-André Mauchin from comment #6)
>  - Not sure what is this for:
> 
> rpm --version
> rpmbuild --version

- Purely informational, dating from the time I was trying to create a single rpm spec file that worked everywhere.  Will remove.

>  - make DESTDIR=%{buildroot} install → %make_install

Will change

> 
>  - no need for %attr(755,root,root)' just:
> 
> %{_bindir}/ddcutil

Will change

> 
>  - Since you're upstream, it would be best if your install script doesn't
> install anything in docdir. It's better to do it in %files like this:
> 
> %doc     AUTHORS NEWS.md README.md ChangeLog
> %license COPYING
> 
> Files will then be copied automatically.
> I don't know what's needed for other distro though so maybe it's not
> possible.

This one is problematic.  At least for me, since packaging is not my thing.  Will investigate the impact on other distros.

A final question.  When I upload the updated package, should I bump the release number from 1 to 2, given that the package is still under review?

> When I upload the updated package, should I bump the release number from 1 to 2, given that the package is still under review?

It's not needed, no.

ddcutil.spec has been modified per Robert-André Mauchin's comments.

In particular, the %doc/%licence simplification has been implemented.  Having upstream not install the docdir files actually simplifies both the Debian and SuSE packaging as well.  However, upstream will not be changed until the next release, 0.8.6.  As a transitional aid, the %install step removes the COPYING file: 
   rm -f %{buildroot}/usr/share/doc/%{name}/COPYING

Architecture s390x is now explicitly excluded, since ddcutil makes no sense in that environment.  On the other hand, the commented out lines regarding armv7hl and aarch64 have been deleted, since ddcutil is known to work on those architectures.

File locations are unchanged:

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.8.5-1.fc27.src.rpm

The package is okay to be accepted imho. You still need a sponsor thogh, try introducing yourself to the fedora-devel mailing list.

New Spec and SRPM files to reflect recent upstream release 0.8.6.  For a description of changes, see http://www.ddcutil.com/release_notes.

Updated file locations:

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.8.6-1.fc27.src.rpm

New Spec and SRPM files to reflect recent upstream release 0.9.1.  For a description of changes, see http://www.ddcutil.com/release_notes.

Updated file locations:

Spec URL: http://www.ddcutil.com/fedora/ddcutil.spec
SRPM URL: http://www.ddcutil.com/fedora/ddcutil-0.9.1-1.fc28.src.rpm

Hi Sanford,

I am a sponsor and can take this to the finish line with you.

As per the following documentation:

https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

in the section "Show Your Expertise by Commenting on other Review Requests" please can you carry out a few informal review requests to demonstrate your understanding of the guidelines.

Any questions please give me a poke.

When that's done we can complete your sponsorship and get this package into Fedora :)

Just a comment since bugzilla is complaining of no action on NEEDINFO.  James Hogarth and I are in ongoing email communication re the informal review requests.

Sanford

(In reply to Robert-André Mauchin from comment #10)
> The package is okay to be accepted imho. You still need a sponsor thogh, try

The package no longer compiles as the spec file is missing:

BuildRequires: gcc


Apart from that the software seems to be not quite usable out of the box:

$ ddcutil detect
Open failed for /dev/i2c-0: errno=EACCES(13): Permission denied
Open failed for /dev/i2c-1: errno=EACCES(13): Permission denied
Open failed for /dev/i2c-2: errno=EACCES(13): Permission denied
Open failed for /dev/i2c-3: errno=EACCES(13): Permission denied
Open failed for /dev/i2c-5: errno=EACCES(13): Permission denied
Open failed for /dev/i2c-6: errno=EACCES(13): Permission denied

IMHO providing an appropriate udev rules which would allow users belonging to e.g. 'video' group an access to i2c bus would be greatly appreciated.

(In reply to Damian Wrobel from comment #15)
 
> The package no longer compiles as the spec file is missing:
> 
> BuildRequires: gcc

Latest spec and src.rpm is here -> https://copr-be.cloud.fedoraproject.org/results/rockowitz/ddcutil/fedora-29-x86_64/00862124-ddcutil/
I was able to compile on f30

Re not installing a udev rule, unfortunately there is no single right thing to do.  There may already be rules in /etc/udev/rules.d that affect the /dev/i2c devices (not all of which are necessarily for displays), and ddcutil should not stomp over them.  See http://www.ddcutil.com/i2c_permissions/ for a discussion.  A sample rules file is distributed in the package, and it is left to the user to modify and install the file as necessary.  Not great, but it's the best I felt I could do without being the proverbial bull in the china shop. 

If a rule affecting all /dev/i2c devices is to be installed automatically, it seems to me it would be more appropriately located in package i2c-tools.

Note that command "ddcutil environment" examines the system environment, particularly in regards to permissions, and suggests to the user what changes they need to make to their environment.

Actually, I was surprised to receive a message re this bug report.  I stopped receiving weekly notifications of inaction some time ago (IIRC at the time of the f29 release), and assumed the request for sponsor was dead.  I had sent a sample review to the person who had offered to sponsor the package, annotated with comments and questions as to how to deal with things where I disagreed with fedora-review, e.g. the complaint about the hidden .build-id directory, and hadn't heard back. I guess we both dropped the ball.

I have been following the Fedora developer list since the initial request for sponsor, and it is apparent that being a Fedora packager is a major commitment.  My focus is on the upstream: fielding user questions and bug reports, developing a GUI version and associated API, etc. I do maintain the Debian version, which has become straightforward, but that's the extent of my official downstream involvement.  (Ubuntu picks up ddcutil from Debian, and openSuSE picks it up because I use OBS for builds.) I'll continue to maintain a COPR build, but for now that needs to be the extent of my Fedora efforts. Please close the request for sponsor.

Have just received another notice for this bug report.  Per previous message I'm setting the status to closed.

Sorry to bother you here, do you mind if I submit a new review request on this package. I found this tool is very useful and am willing to maintain this. 

If you are still interested and link to maintain this on your own, I could do whatever I can to help (expect giving you sponsorship, I don't have the permission).

(In reply to Qiyu Yan from comment #20)
> Sorry to bother you here, do you mind if I submit a new review request on
> this package. I found this tool is very useful and am willing to maintain
> this. 
> 
> If you are still interested and link to maintain this on your own, I could
> do whatever I can to help (expect giving you sponsorship, I don't have the
> permission).

Feel free to open a new review request.

My email program indicates I responded to comment 20 from Qiyu Yan on 9/17.  Since the response doesn't seem to be in the bugzilla log, for completeness here it is again:

I'd be delighted if you took over maintaining ddcutil (and the upcoming GUI version ddcui)  in Fedora.  As I wrote in my comment of 2019-07-03, it had become apparent to me that maintaining the Fedora packages would entail significant, ongoing involvement in the Fedora maintainers community.  Developing and supporting the upstream code is my priority.

I'm also happy to hear that you find the program useful enough to take on maintaining it.  It's the kind of feedback that keeps me going.

Regards,
Sanford