Bug 1447517 - Review Request: ddcutil - control monitor settings [NEEDINFO]
Summary: Review Request: ddcutil - control monitor settings
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: James Hogarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-NEEDSPONSOR
TreeView+ depends on / blocked
 
Reported: 2017-05-03 04:04 UTC by sanford rockowitz
Modified: 2019-10-22 10:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-22 10:10:29 UTC
Type: ---
james.hogarth: fedora-review?
james.hogarth: needinfo? (rockowitz)


Attachments (Terms of Use)

Description sanford rockowitz 2017-05-03 04:04:38 UTC
Spec URL: http://www.ddcutil.com/ddcutil.spec
SRPM URL: http://www.ddcutil.com/ddcutil-0.8.0-1.fc25.src.rpm
website:  http://www.ddcutil.com
source:   https://github.com/rockowitz/ddcutil
Fedora Account System Username: rockowitz@minsoft.com
OBS: http://download.opensuse.org/repositories/home:/rockowitz/
Copr: http://copr-be.cloud.fedoraproject.org/results/rockowitz/ddcutil/fedora-25-x86_64/00546070-ddcutil/

Successfully built on Koji using --scratch option, but I can find no record of the build under my account (rockowitz@minsoft.com).  Trying to submit a build without the --scratch option results in permissions error.

I am the developer of ddcutil.  This is my first Fedora package, and needs a sponsor.  And needless to say, I'm new to Koji. 

The spec file will likely require cleanup.  It's grown into a complex mess in that it serves for both Fedora and SuSE builds, both locally and on OBS.  But it does work on both Copr and Koji as well. 

Description:

ddcutil queries and changes physical monitor settings. 

ddcutil primarily uses DDC/CI (Display Data Channel Command Interface) to communicate with monitors implementing MCCS (Monitor Control Command Set) over I2C. Alternatively, there is support for monitors (such as Eizo ColorEdge displays) that implement MCCS using a USB connection.

Use cases for ddcutil include: 
 - as part of color profile management
 - to switch between a monitor's inputs
 - to control brightness

Comment 1 Michael Schwendt 2017-05-17 12:33:32 UTC
> 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.

Comment 2 sanford rockowitz 2017-05-20 19:31:21 UTC
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.

Comment 3 Jan Kalina 2017-06-01 11:08:47 UTC
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

Comment 4 sanford rockowitz 2017-07-22 15:21:55 UTC
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

Comment 5 sanford rockowitz 2017-11-23 11:32:10 UTC
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

Comment 6 Robert-André Mauchin 2017-11-28 21:18:45 UTC
 - 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.

Comment 7 sanford rockowitz 2017-11-29 02:51:17 UTC

(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?

Comment 8 Robert-André Mauchin 2017-11-29 13:15:56 UTC
> 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.

Comment 9 sanford rockowitz 2017-11-29 18:39:58 UTC
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

Comment 10 Robert-André Mauchin 2017-11-29 18:54:12 UTC
The package is okay to be accepted imho. You still need a sponsor thogh, try introducing yourself to the fedora-devel mailing list.

Comment 11 sanford rockowitz 2018-01-20 14:43:23 UTC
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

Comment 12 sanford rockowitz 2018-05-28 15:55:52 UTC
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

Comment 13 James Hogarth 2018-05-29 07:54:11 UTC
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 :)

Comment 14 sanford rockowitz 2018-06-20 14:58:27 UTC
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

Comment 15 Damian Wrobel 2019-07-03 10:51:04 UTC
(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.

Comment 16 Paweł 2019-07-03 15:53:07 UTC
(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

Comment 17 sanford rockowitz 2019-07-03 19:44:29 UTC
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.

Comment 18 sanford rockowitz 2019-07-03 20:30:41 UTC
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.

Comment 19 sanford rockowitz 2019-10-22 10:10:29 UTC
Have just received another notice for this bug report.  Per previous message I'm setting the status to closed.


Note You need to log in before you can comment on or make changes to this bug.