Bug#1080173: O: ddcui -- GUI for ddcutil

[Sanford Rockowitz]

Package: wnpp
Severity: normal
X-Debbugs-Cc: dd...@packages.debian.org, rockow...@minsoft.com
Control: affects -1 + src:ddcui

I intend to orphan the ddcui package.

I have updated the maintainer field in the control file of the most recent
package uploaded to mentors to packa...@qa.debian.org.  I believe that as a
non-DM this is the only place I can make this change.

The package description is:
 This package provides a graphical user interface for ddccutil.
 .
 ddcutil communicates with monitors implementing MCCS (Monitor Control Command
 Set). Normally, communication is performed using the DDC/CI protocol on the
 I2C bus.  Alternatively, communication can be performed over USB as per the
 USB Monitor Control Class Specification.

Bug#1080172: O: ddcutil -- Control monitor settings - Standalone command line application

[Sanford Rockowitz]

Package: wnpp
Severity: normal
X-Debbugs-Cc: ddcu...@packages.debian.org, rockow...@minsoft.com
Control: affects -1 + src:ddcutil

I intend to orphan the ddcutil package.

The maintainer field has been updated only in control file of the package in
the mentors queue.  As a non-DM, I believe that is the only place I can make
this change.


The package description is:
 ddcutil is used to query and change monitor settings.
 .
 ddcutil communicates with monitors implementing MCCS (Monitor Control Command
 Set). Normally, communication is performed using the DDC/CI protocol on the
 I2C bus.  Alternatively, communication can be performed over USB as per the
 USB Monitor Control Class Specification.

Bug#1065651: powerdevil: changes for libddcutil 2.1.4

[Sanford Rockowitz]

Package: powerdevil
Version: 4:5.27.8-0ubuntu1
Severity: normal
X-Debbugs-Cc: rockow...@minsoft.com

Dear Maintainer,

The version of ddcutil in Debian is being updated to release 2.1.4. Shared
library package libddcutil5 replaces libddcutil4.

The code in powerdevil should work unchanged.

In debian/control, consider adding:

Build-Depends: libddcutil-dev

Recommends: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4)
or
Suggests: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4)



-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-21-generic (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages powerdevil depends on:
ii  kio  5.110.0-0ubuntu1
ii  libc62.38-1ubuntu6.1
ii  libcap2-bin  1:2.66-4ubuntu1
ii  libkf5activities55.110.0-0ubuntu1
ii  libkf5authcore5  5.110.0-0ubuntu1
ii  libkf5bluezqt6   5.110.0-0ubuntu1
ii  libkf5completion55.110.0-0ubuntu1
ii  libkf5configcore55.110.0-0ubuntu1
ii  libkf5configgui5 5.110.0-0ubuntu1
ii  libkf5configwidgets5 5.110.0-0ubuntu1
ii  libkf5coreaddons55.110.0-0ubuntu1
ii  libkf5crash5 5.110.0-0ubuntu1
ii  libkf5dbusaddons55.110.0-0ubuntu1
ii  libkf5globalaccel-bin5.110.0-0ubuntu1
ii  libkf5globalaccel5   5.110.0-0ubuntu1
ii  libkf5i18n5  5.110.0-0ubuntu1
ii  libkf5idletime5  5.110.0-0ubuntu1
ii  libkf5kiowidgets55.110.0-0ubuntu1
ii  libkf5kirigami2-55.110.0-0ubuntu1
ii  libkf5networkmanagerqt6  5.110.0-0ubuntu1
ii  libkf5notifyconfig5  5.110.0-0ubuntu1
ii  libkf5screen-bin 4:5.27.8-0ubuntu1
ii  libkf5screen84:5.27.8-0ubuntu1
ii  libkf5screendpms84:5.27.8-0ubuntu1
ii  libkf5solid5 5.110.0-0ubuntu1
ii  libkf5widgetsaddons5 5.110.0-0ubuntu1
ii  libkf5xmlgui55.110.0-0ubuntu1
ii  libkworkspace5-5 4:5.27.8-0ubuntu1
ii  libpowerdevilcore2   4:5.27.8-0ubuntu1
ii  libpowerdevilui5 4:5.27.8-0ubuntu1
ii  libqt5core5a 5.15.10+dfsg-3
ii  libqt5dbus5  5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5widgets5   5.15.10+dfsg-3
ii  libqt5x11extras5 5.15.10-2
ii  libstdc++6   13.2.0-4ubuntu3
ii  libudev1 253.5-1ubuntu6.1
ii  powerdevil-data  4:5.27.8-0ubuntu1

Versions of packages powerdevil recommends:
ii  power-profiles-daemon  0.13-2
ii  systemsettings 4:5.27.8-0ubuntu1

powerdevil suggests no packages.

-- no debconf information

Bug#1065650: ukui-control-center: changes for libddcutil 2.1.4

[Sanford Rockowitz]

Package: ukui-control-center
Severity: normal
Tags: upstream
X-Debbugs-Cc: rockow...@minsoft.com

The version of ddcutil in Debian is being updated to release 2.1.4. Shared
library package libddcutil5 replaces libddcutil4.

Source packages ukui-control-center and ukui-settings-daemon have been
identified as using libddcutil.

References in files debian/control should be updated to specify:

Build-Depends:  libddcutil-dev (>= 1.4.1)
Depends:   libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4)

Function name ddca_create_display_ref() is deprecated and will be removed in a
future release.  It should be replaced in source code with the alternative name
ddca_get_display_ref(), which more accurately describes what the function does.


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-21-generic (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ukui-control-center depends on:
ii  dconf-cli0.40.0-4
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
pn  ddcutil  
ii  libc62.38-1ubuntu6.1
ii  libcanberra0 0.30-10ubuntu4
ii  libcrypt11:4.4.36-2
ii  libdconf10.40.0-4
pn  libddcutil4  
ii  libgcc-s113.2.0-4ubuntu3
ii  libglib2.0-0 2.78.0-2
ii  libglib2.0-bin   2.78.0-2
ii  libgsettings-qt1 0.2-5
ii  libgtk-3-0   3.24.38-5ubuntu1
ii  libkf5bluezqt6   5.110.0-0ubuntu1
ii  libkf5configcore55.110.0-0ubuntu1
ii  libkf5configgui5 5.110.0-0ubuntu1
ii  libkf5coreaddons55.110.0-0ubuntu1
ii  libkf5globalaccel-bin5.110.0-0ubuntu1
ii  libkf5globalaccel5   5.110.0-0ubuntu1
ii  libkf5i18n5  5.110.0-0ubuntu1
ii  libkf5screen-bin 4:5.27.8-0ubuntu1
ii  libkf5screen84:5.27.8-0ubuntu1
ii  libkf5windowsystem5  5.110.0-0ubuntu1
ii  libmatekbd4  1.26.1-1
ii  libmatemixer01.26.1-1
ii  libopencv-core4064.6.0+dfsg-13build1
ii  libopencv-imgcodecs406   4.6.0+dfsg-13build1
ii  libopencv-imgproc406 4.6.0+dfsg-13build1
ii  libpam0g 1.5.2-6ubuntu1.1
ii  libpolkit-qt5-1-10.114.0-2
ii  libpulse-mainloop-glib0  1:16.1+dfsg1-2ubuntu4
ii  libpulse01:16.1+dfsg1-2ubuntu4
ii  libqt5concurrent55.15.10+dfsg-3
ii  libqt5core5a 5.15.10+dfsg-3
ii  libqt5dbus5  5.15.10+dfsg-3
ii  libqt5gui5   5.15.10+dfsg-3
ii  libqt5network5   5.15.10+dfsg-3
ii  libqt5printsupport5  5.15.10+dfsg-3
ii  libqt5qml5   5.15.10+dfsg-2
ii  libqt5quick5 5.15.10+dfsg-2
ii  libqt5quickwidgets5  5.15.10+dfsg-2
ii  libqt5svg5   5.15.10-2
ii  libqt5widgets5   5.15.10+dfsg-3
ii  libqt5x11extras5 5.15.10-2
ii  libqt5xml5   5.15.10+dfsg-3
ii  libstdc++6   13.2.0-4ubuntu3
ii  libudev1 253.5-1ubuntu6.1
ii  libx11-6 2:1.8.6-1ubuntu1
ii  libxcursor1  1:1.2.1-1
ii  libxi6   2:1.8-1build1
ii  libxkbfile1  1:1.1.0-1build3
ii  libxklavier165.4-4build2
ii  libxml2  2.9.14+dfsg-1.3ubuntu0.1
ii  qml-module-qtgraphicaleffects5.15.10-2
ii  qml-module-qtquick-controls  5.15.10-2
ii  qt5-image-formats-plugins5.15.10-2

ukui-control-center recommends no packages.

Versions of packages ukui-control-center suggests:
ii  gsettings-desktop-schemas  45.0-1ubuntu1
ii  m

Bug#1065649: e17: changes for libddcutil 2.1.4

[Sanford Rockowitz]

Source: e17
Version: 0.25.4-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: rockow...@minsoft.com

The version of ddcutil in Debian is being updated to release 2.1.4. Shared
library package libddcutil5 replaces libddcutil4.

Source package e17 has been identified as using libddcutil.

File e_system_ddc.c should be modified to try opening libddcutil.so.5 before
libddcutil.so.4.

In debian/control, consider adding:

Recommends: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4)
or
Suggests: libddcutil4 (>= 1.4.1) | libddcutil5 (>= 2.1.4)


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 'mantic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-21-generic (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1031259: ddcutil requires module i2c-dev

[Sanford Rockowitz]

The upstream source has been changed to install file 
/usr/lib/modules-conf.d/ddcutil, which will ensure that module i2c-dev 
is loaded.  The change will appear in Debian once the code freeze for 
bookworm is lifted.

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Sanford Rockowitz]

On 3/13/23 07:42, Sebastian Ramacher wrote:

On 2023-03-13 07:25:41 -0400, Sanford Rockowitz wrote:

On 3/13/23 05:33, Sebastian Ramacher wrote:

On 2023-03-11 07:51:16 -0500, Sanford Rockowitz wrote:

[Reason ]
(Explain what the reason for the unblock request is.)
As noted, the unblock request addresses bug #1031259.  ddcutil requires
driver i2c-dev.  If it happens not to be built into the kernel, this entails
post-installation system configuration. Despite extensive documentation and
application warnings if the driver is not loaded, this can be challenging
for inexperienced users.


[ Impact ]
(What is the impact for the user if the unblock isn't granted?)

Manual post installation configuration will continue to be required as
previously.

[ Tests ]
(What automated or manual tests cover the affected code?)

None

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

The changes are trivial, ensuring that driver i2c-dev is loaded if it is not
already built into the kernel. Package libddccontrol0, an alternative to
ddcutil for monitor control, installs file ddccontrol-i2c-dev.conf, which
loads i2c-dev.  The contents of that file, a single line containing
"i2c-dev", is identical to the contents of the files to be installed by
ddcutil.  Additional examples of packages that install files in
/user/lib/modules-load.d are fwupd, which installs file fwupd-msc.conf, and
encryptfs-utils, which installs file ecryptfs.conf.

The prpoposed changes also introduce a policy violation:
/usr/lib/modules-load.d/libddcutil.conf installed in libddcutil4 is not
versioned the same way as the shared library. See section 8.2 for more
details.

Cheers


If the installed conf file were incorrect, the only effect would be an error
in the system log, and manual user configuration would still be required as
before.

The only (potential) known dependency within Debian is from KDE
PowerDevil.   However, PowerDevil, as installed by Debian, is built with use
of libddcutil if-tested out. (Recommended since its use of libddcutil is
"proof of concept" level code.)


[ Checklist ]
    [x] all changes are documented in the d/changelog
    [x ] I reviewed all changes and I approve them
    [x ] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

As I read section 8.2, there are two possibilities.  The first is to version
the name of the file installed in /usr/lib/modules-load.d, e.g.
libddcutil4.conf for package libddcutil4.  The second is to create an
additional package, named e.g. libddcutil-aux, that installs libddcutil.conf
and on which package libddcutil4 and successor packages libddcutilN depend.
The former has the advantage that it doesn't introduce an additional package
simply to install a single file, and the disadvantage that it relies on a
naming convention for the installed libddcutilN.conf file, which could
easily be overlooked when bumping the SONAME.

As we're in hard freeze, option 2 is not an option for bookworm.


A third alternative is to not install a modules-load.d conf file for
libddcutil, and instead rely on packages using the shared library to install
a conf file.   But that would multiply the number of packages installing
files in modules-load.d, and the potential for errors.

That doesn't really sound like a solution to the bug. It would leak
implementation details of libddcutil to all the reverse dependencies.

Cheers
Setting aside what's possible given the bookworm freeze, do you have a 
strong opinion as to whether the naming convention or separate package 
is preferable/acceptable? I don't feel strongly that the update has to 
go into bookworm.  I wanted to address the "bug report" promptly, but 
the change is more of an enhancement.  Nothing is really actually 
broken, it's just that a post installation step is necessary for some 
users, which it would be kind to avoid.

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Sanford Rockowitz]

On 3/13/23 05:33, Sebastian Ramacher wrote:

On 2023-03-11 07:51:16 -0500, Sanford Rockowitz wrote:

[Reason ]
(Explain what the reason for the unblock request is.)
As noted, the unblock request addresses bug #1031259.  ddcutil requires
driver i2c-dev.  If it happens not to be built into the kernel, this entails
post-installation system configuration. Despite extensive documentation and
application warnings if the driver is not loaded, this can be challenging
for inexperienced users.


[ Impact ]
(What is the impact for the user if the unblock isn't granted?)

Manual post installation configuration will continue to be required as
previously.

[ Tests ]
(What automated or manual tests cover the affected code?)

None

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

The changes are trivial, ensuring that driver i2c-dev is loaded if it is not
already built into the kernel. Package libddccontrol0, an alternative to
ddcutil for monitor control, installs file ddccontrol-i2c-dev.conf, which
loads i2c-dev.  The contents of that file, a single line containing
"i2c-dev", is identical to the contents of the files to be installed by
ddcutil.  Additional examples of packages that install files in
/user/lib/modules-load.d are fwupd, which installs file fwupd-msc.conf, and
encryptfs-utils, which installs file ecryptfs.conf.

The prpoposed changes also introduce a policy violation:
/usr/lib/modules-load.d/libddcutil.conf installed in libddcutil4 is not
versioned the same way as the shared library. See section 8.2 for more
details.

Cheers


If the installed conf file were incorrect, the only effect would be an error
in the system log, and manual user configuration would still be required as
before.

The only (potential) known dependency within Debian is from KDE
PowerDevil.   However, PowerDevil, as installed by Debian, is built with use
of libddcutil if-tested out. (Recommended since its use of libddcutil is
"proof of concept" level code.)


[ Checklist ]
   [x] all changes are documented in the d/changelog
   [x ] I reviewed all changes and I approve them
   [x ] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)


As I read section 8.2, there are two possibilities.  The first is to 
version the name of the file installed in /usr/lib/modules-load.d, e.g. 
libddcutil4.conf for package libddcutil4.  The second is to create an 
additional package, named e.g. libddcutil-aux, that installs 
libddcutil.conf and on which package libddcutil4 and successor packages 
libddcutilN depend.  The former has the advantage that it doesn't 
introduce an additional package simply to install a single file, and the 
disadvantage that it relies on a naming convention for the installed 
libddcutilN.conf file, which could easily be overlooked when bumping the 
SONAME.


A third alternative is to not install a modules-load.d conf file for 
libddcutil, and instead rely on packages using the shared library to 
install a conf file.   But that would multiply the number of packages 
installing files in modules-load.d, and the potential for errors.


Is one alternative clearly preferable to the others from the Debian 
perspective?


Thank you. Whether or not this change makes it into bookworm, the review 
process has been helpful.

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Sanford Rockowitz]

[Reason ]
(Explain what the reason for the unblock request is.)
As noted, the unblock request addresses bug #1031259.  ddcutil requires 
driver i2c-dev.  If it happens not to be built into the kernel, this 
entails post-installation system configuration. Despite extensive 
documentation and application warnings if the driver is not loaded, this 
can be challenging for inexperienced users.




[ Impact ]
(What is the impact for the user if the unblock isn't granted?)


Manual post installation configuration will continue to be required as 
previously.


[ Tests ]
(What automated or manual tests cover the affected code?)


None


[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)


The changes are trivial, ensuring that driver i2c-dev is loaded if it is 
not already built into the kernel. Package libddccontrol0, an 
alternative to ddcutil for monitor control, installs file 
ddccontrol-i2c-dev.conf, which loads i2c-dev.  The contents of that 
file, a single line containing "i2c-dev", is identical to the contents 
of the files to be installed by ddcutil.  Additional examples of 
packages that install files in /user/lib/modules-load.d are fwupd, which 
installs file fwupd-msc.conf, and encryptfs-utils, which installs file 
ecryptfs.conf.


If the installed conf file were incorrect, the only effect would be an 
error in the system log, and manual user configuration would still be 
required as before.


The only (potential) known dependency within Debian is from KDE 
PowerDevil.   However, PowerDevil, as installed by Debian, is built with 
use of libddcutil if-tested out. (Recommended since its use of 
libddcutil is "proof of concept" level code.)




[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x ] I reviewed all changes and I approve them
  [x ] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Sanford Rockowitz]

cutil-1.4.1/data/usr/lib/modules-load.d/libddcutil.conf 
ddcutil-1.4.2/data/usr/lib/modules-load.d/libddcutil.conf
--- ddcutil-1.4.1/data/usr/lib/modules-load.d/libddcutil.conf   1969-12-31 
19:00:00.0 -0500
+++ ddcutil-1.4.2/data/usr/lib/modules-load.d/libddcutil.conf   2023-02-21 
13:25:49.0 -0500
@@ -0,0 +1 @@
+i2c-dev
diff -Nru ddcutil-1.4.1/debian/changelog ddcutil-1.4.2/debian/changelog
--- ddcutil-1.4.1/debian/changelog  2023-01-26 04:00:00.0 -0500
+++ ddcutil-1.4.2/debian/changelog  2023-02-18 04:00:00.0 -0500
@@ -1,3 +1,15 @@
+ddcutil (1.4.2-1) unstable; urgency=medium
+
+  * New upstream release (Closes: #1031259)
+
+  * debian/ddcutil.install
+- install /usr/lib/modules-load.d/ddcutil.conf
+
+  * debian/libddcutil4.install
+- install /usr/lib/modules-load.d/libddcutil.conf
+
+ -- Sanford Rockowitz   Sat, 18 Feb 2023 05:00:00 -0400
+
 ddcutil (1.4.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru ddcutil-1.4.1/debian/ddcutil.install 
ddcutil-1.4.2/debian/ddcutil.install
--- ddcutil-1.4.1/debian/ddcutil.install2023-01-25 13:21:18.0 
-0500
+++ ddcutil-1.4.2/debian/ddcutil.install2023-02-16 18:49:46.0 
-0500
@@ -2,3 +2,4 @@
 /usr/share/man
 /usr/share/ddcutil/data
 /usr/lib/udev/rules.d
+/usr/lib/modules-load.d/ddcutil.conf
diff -Nru ddcutil-1.4.1/debian/libddcutil4.install 
ddcutil-1.4.2/debian/libddcutil4.install
--- ddcutil-1.4.1/debian/libddcutil4.install2021-01-29 22:31:56.0 
-0500
+++ ddcutil-1.4.2/debian/libddcutil4.install2023-02-16 18:50:41.0 
-0500
@@ -1 +1,2 @@
 usr/lib*/*/libddcutil.so.4*
+usr/lib/modules-load.d/libddcutil.conf

Bug#1031259: ddcutil requires module i2c-dev

[Sanford Rockowitz]

As I said, it's unclear to me whether it's appropriate for ddcutil 
installation to cause module i2c-dev to be loaded automatically.  I 
agree it would simplify ddcutil installation.  I will consult with those 
at a higher pay grade.


On 2/15/23 04:50, Eric Streit wrote:


hi,

when I installed ddcutil, the module was not loaded  and I had to 
modprobe it).


Maybe, a way this could be done automatically when installing ddcutil?

Eric

I think, that the module

Le 15/02/2023 à 10:24, Sanford Rockowitz a écrit :

It's not clear to me what's being reported here.

ddcutil does depend on kernel module i2c-dev.  This is extensively 
documented.  For example, see page Configuration Steps 
<https://www.ddcutil.com/config_steps/#kernel-module-i2c-dev> on the 
ddcutil web site.


On startup, ddcutil issues the following messages if i2c-dev is not 
loaded or built in:


  No /dev/i2c devices/exist.
  ddcutil requires module i2c-dev.

If that is not the case, it is a bug.  Please submit the contents of 
directory /dev BEFORE module i2c-dev is loaded.


Or you would like package ddcutil to install a file in 
/etc/modules-load.d or /usr/lib/modules-load.d that forces i2c-dev to 
be loaded at startup. It is unclear to me whether installing a file 
in these directories is appropriate behavior for an application.  In 
this, I have followed the lead of package i2c-tools, which is a basic 
package intimately connected with i2c-dev in that it exercises 
i2c-dev and was written by the author (Jon Delvare) of that module.


On 2/14/23 02:31, Eric Streit wrote:

Package: ddcutil
Version: 1.4.1-1
Severity: normal
X-Debbugs-Cc:e...@yojik.eu

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?
 installing ddcutil
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 installing the module i2c-dev
* What was the outcome of this action?
 working :D
* What outcome did you expect instead?
 working
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bookworm/sid
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddcutil depends on:
ii  i2c-tools 4.3-2+b3
ii  libc6 2.36-8
ii  libdrm2   2.4.114-1
ii  libglib2.0-0  2.74.5-1
ii  libkmod2  30+20221128-1
ii  libudev1  252.5-2
ii  libx11-6  2:1.8.3-3
ii  libxrandr22:1.5.2-2+b1
ii  pci.ids   0.0~2023.01.26-1
ii  usb.ids   2023.01.16-1
ii  usbutils  1:014-1

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information

Bug#1031259: ddcutil requires module i2c-dev

[Sanford Rockowitz]

It's not clear to me what's being reported here.

ddcutil does depend on kernel module i2c-dev.  This is extensively 
documented.  For example, see page Configuration Steps 
 on the 
ddcutil web site.


On startup, ddcutil issues the following messages if i2c-dev is not 
loaded or built in:


  No /dev/i2c devices/exist.
  ddcutil requires module i2c-dev.

If that is not the case, it is a bug.  Please submit the contents of 
directory /dev BEFORE module i2c-dev is loaded.


Or you would like package ddcutil to install a file in 
/etc/modules-load.d or /usr/lib/modules-load.d that forces i2c-dev to be 
loaded at startup. It is unclear to me whether installing a file in 
these directories is appropriate behavior for an application.  In this, 
I have followed the lead of package i2c-tools, which is a basic package 
intimately connected with i2c-dev in that it exercises i2c-dev and was 
written by the author (Jon Delvare) of that module.


On 2/14/23 02:31, Eric Streit wrote:

Package: ddcutil
Version: 1.4.1-1
Severity: normal
X-Debbugs-Cc:e...@yojik.eu

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?
 installing ddcutil
* What exactly did you do (or not do) that was effective (or
  ineffective)?
 installing the module i2c-dev
* What was the outcome of this action?
 working :D
* What outcome did you expect instead?
 working
*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bookworm/sid
   APT prefers testing
   APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddcutil depends on:
ii  i2c-tools 4.3-2+b3
ii  libc6 2.36-8
ii  libdrm2   2.4.114-1
ii  libglib2.0-0  2.74.5-1
ii  libkmod2  30+20221128-1
ii  libudev1  252.5-2
ii  libx11-6  2:1.8.3-3
ii  libxrandr22:1.5.2-2+b1
ii  pci.ids   0.0~2023.01.26-1
ii  usb.ids   2023.01.16-1
ii  usbutils  1:014-1

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information

Bug#1005191: ddcutil: requires undocumented manual setup to make it usable

[Sanford Rockowitz]

Samuel,

Thanks for your comments.

Questions like these have come up before.  In general, not wanting to be 
a bull in the proverbial system configuration china shop, I've hesitated 
to make system-wide changes.


On Debian, ddcutil requires i2c-tools. File DEBIAN/postinst in the 
i2c-tools .deb package creates group i2c if it does not already exist.  
Package i2c-tools also installs file 
/lib/udev/rules.d/60-i2c-tools.rules, which assigns the /dev/i2c* 
devices to group i2c:


SUBSYSTEM=="i2c-dev",KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

File 45-ddcutil-i2c.rules contains:

KERNEL=="i2c-[0-9]*", GROUP="i2c", MODE="0660"

While more precise than ddcutil's rule the one in i2c-tools.rules file 
should make ddcutil's unnecessary.


What installation path did you take that required you to manually 
install 45-ddcutil-i2c-rules?


Ensuring that i2c-dev is either built into the kernel or explicitly 
loaded has been to me less clear.  Would creating 
/etc/modules-load.d/i2c-dev.conf as you suggest always be safe? 
Presumably there would have to be checks as to whether i2c-dev is loaded 
by some other file in modules-load.d or is built into the kernel.


At the start of execution, ddcutil checks for i2c-dev.   If it's 
definitely missing ddcutil issues a message and terminates execution. 
Unfortunately, ddcutil can't always tell (there have been bug reports 
when the user's environment is non-vanilla), in which case there's only 
a warning message.


Bottom line, would forcing the load of i2c-dev always be safe? Would it 
be considered tampering with the user's environment. Should a modprobe.d 
file be created  if i2c-dev is built into the kernel?


Andrey Rahmatullin has been the sponsor for ddcutil.  He's been very 
helpful in getting ddcutil properly packaged, but he's not always been 
quick to respond.  I'm sure he wouldn't mind if you took over.   There's 
also new package ddcui which provides a GUI version of ddcutil, and 
which is in need of a sponsor.


As for maintaining ddcutil in salsa, my understanding is that packages 
there are debianized specifically for Debian.  The ddcutil repo is 
distribution neutral.  I have a collection of build scripts that build 
ddcutil for deb and rpm systems, submitting packages to launchpad, OBS 
(deb and rpm variants), and COPR.  Even within the deb family some files 
differ between Debian, launchpad, and OBS. There's also a feedback loop 
where packages are built for the several targets before the distribution 
tarball is released.  So it seems to me that a salsa repo would just be 
another artifact to manage.  But again, I have only a superficial 
understanding of salsa.


Though things should of course just work without the user having to dig 
through buried documentation, the i2c-dev requirements are documented. 
See pages www.ddcutil.com/config and www.ddcutil.com/kernel_module.  The 
"ddcutil environment" command checks that the user environment is 
adequately set up and makes recommendations.  (With the --verbose 
option, it produces voluminous information that I use for remote 
diagnosis.)


Thank you for whatever help or guidance you can provide.

Sanford

On Tue, 8 Feb 2022 19:14:38 + Samuel Henrique  
wrote:

> Package: ddcutil
> X-Debbugs-Cc: samuel...@debian.org
> Version: 1.2.1-1
> Severity: normal
>
> Hello Sanford, thank you for working on ddcutil :)
>
> I wanted to report on a few manual steps I had to take to make ddcutil
> usable for me (I'm using it through gnome-display-brightness-ddcutil).
>
> I would like to see the ddcutil package automate this setup, or at
> least ask the user if they want this to be done (if there are any
> security concerns). Alternatively there could also be better messaging
> on what's needed so we don't risk leaving users in the dark about it.
>
> First I had to load the kernel module for i2c-dev:
> # echo "i2c-dev" /etc/modules-load.d/i2c-dev.conf
>
> Then I had to copy the udev rule:
> # cp /usr/share/ddcutil/data/45-ddcutil-i2c.rules /etc/udev/rules.d
>
> So to summarize, anything that could be done to help users on these
> two steps would be awesome.
>
> Also, if by any chance you're looking for help, I would be happy to
> sponsor your uploads, and/or co-maintain the package and move it to
> salsa.
>
> Thanks,
>
> --
> Samuel Henrique 
>
>

Bug#1004840: ITP: ddcui -- graphical user interface for ddcutil

[Sanford Rockowitz]

Package: wnpp
Severity: wishlist
Owner: Sanford Rockowitz 
X-Debbugs-Cc: debian-de...@lists.debian.org, rockow...@minsoft.com

* Package name: ddcui
  Version : 0.2.1
  Upstream Author : Sanford Rockowitz 
* URL : http://www.ddcutil.com
* License : GPL
  Programming Lang: c++, c
  Description : graphical user interface for ddcutil

This program is a graphical user interface that uses shared library
libddcutil.so from existing package libddcutilN (source package ddcutil) to
manage monitor settings.

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

Joris, if there's been a loss of functionality of ddcutil 0.9.9 with 
kernel 5.8 (or earlier) vs kernel 5.10 (or later) I need to understand 
what that is, irrespective of the decision on inclusion of ddcutil in 
bullseye (well above my pay grade).   To date I've had no other problem 
reports in that category.   Please submit the output of "ddcutil 
environment --verbose" for ddcutil 0.9.9 on both kernel 5.9 (or earlier) 
and 5.10 (or later).  Thank you.


On 05/19/2021 10:55 AM, Joris wrote:

Hi,

After some digging, I think we should position it to grave. I was 
unable to find a scenario with ddcutil working in linux 5.10 but my 
test setups are limited.
The version number jumps may feel significant, but the changes 
(http://www.ddcutil.com/release_notes/ + 
http://www.ddcutil.com/prior_announcements/) appear to be limited (yet 
critical!) and "inside" the binary (heuristics) - but I'm not suited 
to properly judge that.
There are no reverse dependencies, so that really limits the risk of 
updating I think.


Kind regards,

Op za 15 mei 2021 om 17:35 schreef Andrey Rahmatullin <mailto:w...@debian.org>>:


    On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:
> ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor
(Andrey
> Rahmatulin) it was not moved to sid because of the freeze for
Bullseye.
If the package doesn't work with the bullseye kernel it's a grave
bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch
added to
the bullseye version.
What do you think?


> On 5/14/21 1:10 AM, Joris wrote:
> > Package: ddcutil
> > Version: 0.9.9-2
> > Severity: important
> > Tags: upstream
> > X-Debbugs-Cc: jo...@v5.be <mailto:jo...@v5.be>
> >
> >
> >
> >
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers testing-security
> >APT policy: (500, 'testing-security'), (500, 'testing')
> > Architecture: amd64 (x86_64)
> >
> > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8
(charmap=UTF-8), LANGUAGE=en_GB:en
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> >
> > Versions of packages ddcutil depends on:
> > ii  i2c-tools 4.2-1+b1
> > ii  libc6 2.31-11
> > ii  libdrm2   2.4.104-1
> > ii  libglib2.0-0  2.66.8-1
> > ii  libudev1  247.3-5
> > ii  libx11-6  2:1.7.0-2
> > ii  libxrandr22:1.5.1-1
> > ii  pci.ids   0.0~2021.02.08-1
> > ii  usb.ids   2021.03.31-1
> > ii  usbutils  1:013-3
> >
> > ddcutil recommends no packages.
> >
> > ddcutil suggests no packages.
> >
> > -- no debconf information
> >
> >
> > >From the release information on ddcutil
(http://www.ddcutil.com/release_notes/) it seems Linux kernel 5.10
made changes. They are listed as "docking stations" but in my
experience also apply to directly connected HDMI and Thunderbolt
displays.
> > Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel.
On my system bringing back the same capabilities I had under
kernel 5.8, whereas with ddcutil 0.9.9 on kernel 5.10 there was
simply no device detected.
> >
> > As 5.10 seems to be the default in the upcoming Debian
release, it would be very nice to get ddcutil updated as well.
> > I had no issue building ddcutil from source.
> >
>
>

-- 
WBR, wRAR

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

Kernel 5.10 addressed a long standing problem with the I2C 
implementation for DisplayPort Multi-Stream Transport.  Only I2C reads 
were implemented, not writes. (See the nearly 4 year long thread 
<https://gitlab.freedesktop.org/drm/intel/-/issues/37>at 
freedesktop.org.) As a result it was possible to read the EDID, but DDC 
communication failed. ddcutil reported such displays as "Invalid".


Unfortunately, there are problems with the implementation in 5.10 that 
ddcutil at least partially works around.  In particular, the same 
display can appear to be connected at 2 different /dev/i2c addresses, 
only one of which supports DDC.


All the connectors on a docking station, whether DP, DVI, or HDMI, are 
on a DisplayPort MST chain.  As Joris notes, the Thunderbolt connection 
on recent systems uses MST, so recent Type-C connected displays also 
didn't work.


Joris's report is the first indication I've had that there are displays 
(HDMI, not on a docking station) which ddcutil 0.9.9 successfully 
communicated with prior to kernel 5.10, but on on kernel 5.10 or 
later.   Modulo that, use of 0.9.9 with kernel 5.10 does not constitute 
a regression.   ddcutil 0.9.9 continues to work with the vast majority 
of displays on kernel 5.10.  It simply doesn't add functionality. Joris, 
if there really is a loss of functionality, can you submit, either here 
or on the ddcutil issue tracker 
<https://github.com/rockowitz/ddcutil/issues> at Github) the output of 
"ddcutil environment --verbose" for ddcutil 0.9.9  and "ddcutil 
environment --very-verbose" for ddcutil 1.1.0 for both kernel 5.10 and 
one earlier than 5.10.


There is no simple patch that would bring 0.9.9 up to the functionality 
of 1.1.0 for MST displays.  The changes were extensive.



On 5/15/21 11:34 AM, Andrey Rahmatullin wrote:

On Sat, May 15, 2021 at 10:36:23AM -0400, Sanford Rockowitz wrote:

ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey
Rahmatulin) it was not moved to sid because of the freeze for Bullseye.

If the package doesn't work with the bullseye kernel it's a grave bug, not
important, and the package should be fixed (or removed).
Ti be eligible for bullseye the update should be a minimal patch added to
the bullseye version.
What do you think?



On 5/14/21 1:10 AM, Joris wrote:

Package: ddcutil
Version: 0.9.9-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jo...@v5.be




-- System Information:
Debian Release: bullseye/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddcutil depends on:
ii  i2c-tools 4.2-1+b1
ii  libc6 2.31-11
ii  libdrm2   2.4.104-1
ii  libglib2.0-0  2.66.8-1
ii  libudev1  247.3-5
ii  libx11-6  2:1.7.0-2
ii  libxrandr22:1.5.1-1
ii  pci.ids   0.0~2021.02.08-1
ii  usb.ids   2021.03.31-1
ii  usbutils  1:013-3

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information


>From the release information on ddcutil (http://www.ddcutil.com/release_notes/) it seems 
Linux kernel 5.10 made changes. They are listed as "docking stations" but in my 
experience also apply to directly connected HDMI and Thunderbolt displays.
Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
bringing back the same capabilities I had under kernel 5.8, whereas with 
ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.

As 5.10 seems to be the default in the upcoming Debian release, it would be 
very nice to get ddcutil updated as well.
I had no issue building ddcutil from source.

Bug#988489: ddcutil: Kernel 5.10 changes require ddcutil 1.1

[Sanford Rockowitz]

ddcutil 1.1.0 was uploaded to mentors on 4/22.  Per the sponsor (Andrey 
Rahmatulin) it was not moved to sid because of the freeze for Bullseye.



On 5/14/21 1:10 AM, Joris wrote:

Package: ddcutil
Version: 0.9.9-2
Severity: important
Tags: upstream
X-Debbugs-Cc: jo...@v5.be




-- System Information:
Debian Release: bullseye/sid
   APT prefers testing-security
   APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ddcutil depends on:
ii  i2c-tools 4.2-1+b1
ii  libc6 2.31-11
ii  libdrm2   2.4.104-1
ii  libglib2.0-0  2.66.8-1
ii  libudev1  247.3-5
ii  libx11-6  2:1.7.0-2
ii  libxrandr22:1.5.1-1
ii  pci.ids   0.0~2021.02.08-1
ii  usb.ids   2021.03.31-1
ii  usbutils  1:013-3

ddcutil recommends no packages.

ddcutil suggests no packages.

-- no debconf information


>From the release information on ddcutil (http://www.ddcutil.com/release_notes/) it seems 
Linux kernel 5.10 made changes. They are listed as "docking stations" but in my 
experience also apply to directly connected HDMI and Thunderbolt displays.
Ddcutil 1.0.1 and 1.1.0 include workarounds for this kernel. On my system 
bringing back the same capabilities I had under kernel 5.8, whereas with 
ddcutil 0.9.9 on kernel 5.10 there was simply no device detected.

As 5.10 seems to be the default in the upcoming Debian release, it would be 
very nice to get ddcutil updated as well.
I had no issue building ddcutil from source.

Bug#944834: fixed in ddcutil-0.9.7-2

[Sanford Rockowitz]

Depends: hwdata was added in ddcutil-0.9.7-2

Bug#932817: Quote needed

[Sanford Rockowitz]

It looks like you got our name from some IBM list.  I'm afraid we can't 
help you.  We're software developers and that is our connection to IBM.


Regards,
Sanford Rockowitz

On 09/09/2019 03:26 PM, Jerry Edwards wrote:


Good day,

Can you please assist me with quote for the below product.

Lenovo Yoga C930 14" Intel® Core™ i7-8550U (1.80GHz, up to 4.0GHz, Win 
10,16GB DDR4 2400MHz,1TB SSD,UHD Graphics 620.


Thank you for your assistance.

Jerry Edwards
JC Window Fashions
6400 Fleet Street
Commerce, CA 90040
f...@jcwindowfashions.com <mailto:f...@jcwindowfashions.com>
Ph 909 359 2526

Bug#907735: new upstream release 0.9.2

[Sanford Rockowitz]

Package: ddcutil
Version: 0.9.2-1
Severity: Normal

New upstream release. Tarball at www.ddcutil.com/releases/ddcutil-0.9.2.tar.gz

Bug#900295: ddcutil: new upstream release 0.9.1

[Sanford Rockowitz]

Package: ddcutil
Version: 0.9.1-1
Severity: Normal

New tarball at www.ddcutil.com/releases/ddcutil-0.9.1.tar.gz

Bug#887770: ddcutil: new upstream release 0.8.6

[Sanford Rockowitz]

Package: ddcutil
Version: 0.8.5-1
Severity: Normal

New tarball at www.ddcutil.com/releases/ddcutil-0.8.6.tar.gz

Bug#881996: ddcutil: new upstream release 0.8.5

[Sanford Rockowitz]

Package: ddcutil
Version: 0.8.4-1
Severity: normal

New tarball at www.ddcutil.com/releases/ddcutil-0.8.5.tar.gz

Bug#861617: Fwd: Re: Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

Should have been sent to the entire list.


 Forwarded Message 
Subject: 	Re: Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor 
settings

Date:   Thu, 31 Aug 2017 14:41:21 -0400
From:   Sanford Rockowitz 
Organization:   Minaret Software
To: Andrey Rahmatullin 



I have uploaded a new copy of ddcutil, with a modified
debian/changelog.  It closes bug 858510, the original ITP bug,  not the
blocker 861617.  I hope this was the correct choice.

Sanford


On 08/31/2017 01:57 PM, Andrey Rahmatullin wrote:

On Thu, Aug 31, 2017 at 01:35:33PM -0400, Sanford Rockowitz wrote:

I assume you mean replace the dummy "Packaged for debian-mentors
submission." entry and update the timestamp.

Yes, and as I've said, and lintian have told you, you should have done it
at the very beginning.

There are 2 changelog related messages from lintian:

P: ddcutil: no-upstream-changelog

  As I wrote, that file (/usr/share/doc/ddcutil/ChangeLog) will be added in
the next upstream point release.

We were talking about the Debian changelog, why did you suddenly switch to
the upstream one?


W: ddcutil: new-package-should-close-itp-bug

  Your comment on this message was to ignore the warning for now:

 You don't write a separate changelog entry for a mentors "upload".

I didn't mean that, I meant you should write the correct changelog entry
from the very beginning and don't write a stub for a mentors "upload"
(because there is no such thing as a mentors upload wrt debian/changelog).


Can you give some guidance as to what should be in the initial changelog
entry?   Thanks.

* Initial release. (Closes: #NN)

I'm going to interpret the "it" that I should have done as being the
upstream changelog.

:-/

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

I assume you mean replace the dummy "Packaged for debian-mentors 
submission." entry and update the timestamp.  Can you give some guidance 
as to what should be in the initial changelog entry?   Thanks.


Sanford

On 08/31/2017 12:22 PM, Andrey Rahmatullin wrote:

Please fix the changelog entry and I'll upload this.

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

A new version of ddcutil has been uploaded to mentors.

Comments interspersed.

On 08/31/2017 06:58 AM, Andrey Rahmatullin wrote:

You should build your packages on sid and test them on sid.

After executing pdebuild on sid for distribution sid, messages unchanged:

  $ lintian -EI --pedantic ddcutil_0.8.4-1_amd64.changes
  W: ddcutil source: newer-standards-version 4.1.0 (current is 4.0.0)
  I: ddcutil source: testsuite-autopkgtest-missing
  P: ddcutil source: debian-watch-may-check-gpg-signature
  P: ddcutil: no-upstream-changelog
  W: ddcutil: new-package-should-close-itp-bug


Please remove --with autotools-dev lines from d/rules.
The comments re --with autotools-dev have been deleted.  The commented 
out "--with autotools-dev" line was left in the rules file, along with 
an explanation, to avoid confusion.  Most online documentation refers to 
autotools-dev, and it is still exists in other rules file variants that 
ddcutil uses.



You should not delete all COPYING files in dh_auto_install, especially not
those in the upstream source. If you don't want some files to be packaged,
delete them explicitly with rm(1) and full paths.


Fixed.

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

An updated copy of ddcutil has been uploaded to mentors reflecting 
Andrey's review.  Comments interspersed.


On 08/20/2017 12:02 PM, Andrey Rahmatullin wrote:

The package FTBFS:

dh_install
dh_install: Cannot find (any matches for) "/usr/bin" (tried in ., debian/tmp)

dh_install: ddcutil missing files: /usr/bin
dh_install: Cannot find (any matches for) "/usr/share/man" (tried in ., 
debian/tmp)

dh_install: ddcutil missing files: /usr/share/man
dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*rules" 
(tried in ., debian/tmp)

dh_install: ddcutil missing files: /usr/share/ddcutil/data/*rules
dh_install: Cannot find (any matches for) "/usr/share/ddcutil/data/*conf" 
(tried in ., debian/tmp)

dh_install: ddcutil missing files: /usr/share/ddcutil/data/*conf
dh_install: missing files, aborting
debian/rules:9: recipe for target 'binary' failed

   Fixed.   Deleted file debian/ddcutil.install


Please run lintian (with -EI --pedantic and against the binary .changes) and 
review its output.
After executing pdebuild on buster for distribution buster, the lintian 
output is as follows:


  W: ddcutil source: newer-standards-version 4.1.0 (current is 4.0.0)

  See below.

  I: ddcutil source: testsuite-autopkgtest-missing

   ddcutil has no test suite.

P: ddcutil source: debian-watch-may-check-gpg-signature

   There is no signature checking.  Simply put I haven't been able to 
get it to work.


P: ddcutil: no-upstream-changelog

   To be added in a future point release and installed in 
/usr/share/doc/ddcutil.  However, in the spirit of DRY entries will 
basically just point to the web site for detail.


W: ddcutil: new-package-should-close-itp-bug

   Should a mentors upload close the ITP bug?


Please update to the current Standards-Version (you've missed that in the
previous review).
Was at 3.9.8, the highest version recognized by lintian in mentors.   
I've now changed it to 4.1.0,  the version in the 2017-08-21 policy 
manual.   Of course, this means that no release of lintian I've yet 
encountered recognizes the version.




The first line of License: GPL-2.0+ block in d/copyright contradicts everything
else (and is not actually needed).

First line deleted.



Why do you need
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
?

Historic cruft.  Deleted.



Vcs-* don't point to the packaging repo.



Now we come to what I think is a substantive issue.  The Vcs-* entries 
pointed to the upstream repository.   Though it wasn't clear from the 
policy manual, I gather from your comment that the Vcs-* entries need to 
point to a debianized repository.   There currently is no such 
repository.  Trying to support the increasing number of variants for  
dpkg and rpm packaging in the upstream repository under autotools became 
an unwieldy mess.   It is being factored out.   The role of the upstream 
repo is simply to produce a distribution agnostic tarball.


Accordingly, I have deleted the Vcs-* entries.   The tarballs produced 
by upstream are published at http://www.ddcutil.com/releases/, and the 
watch file has been changed to point to that page instead of the git 
repository.


Are tarballs sufficient or is a debianized repo required?   Page 
https://wiki.debian.org/PackagingWithGit#pbuilder describes a process 
for maintaining one.  Is this the proper method?

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

Per Andrey Rahmatullin's comments. version 0.8.4-1 of ddcutil cleans up 
the debian directory.  It also eliminates the shared library version of 
ddcutil, as the API is still subject to significant change.


The debian/watch file does not include a cryptographic signature check 
as I was unable to get the pgpsigurlmangle option to work.


Sanford Rockowitz


On 07/24/2017 03:11 PM, Andrey Rahmatullin wrote:

Control: tags -1 + moreinfo

Please remove all unneeded files from debian/.
Please remove commented out sample lines from debian/rules.
You shouldn't "Bump Debian release for debian-mentors". Please remove all
changelog entries (both old upstream ones and recent bumps) and add oe
correct entry.
Please switch to the debhelper compat level 10.
B-D: libglib2.0-0 looks wrong.
Please update to the current Standards-Version version.
Please fix and uncomment Vcs-Browser.
Adding explicit Depends: on library packages is usually wrong.
Please remove unneeded comments from debian/control.
Please drop debian/menu.
Consider adding the symbols file.
Please don't ship .la.
I'd expect ddcutil to be linked against libddcutil0.

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

Andrey,

Thank you for your comments.  This being my fist debian submission, I 
want to make sure there are not too many cooks in the kitchen before 
uploading a new version.  Back at the beginning of May, Stephen Kitt had 
offered to co-maintain and sponsor the project.   However, nothing has 
happened since.   Stephen, what you you like me to do?


Assuming that I'm uploading a new version, some comments and questions.

1) I will create a debian directory that exists solely for the debian 
submission (i.e. not PPA, not OBS).  This should clean things up.
2) IIRC, I was forced to increment the Debian release by 
debain-mentors.  A failed submission "used up" a debian release number 
and blocked a corrected submission with the same release number.  Is 
there some way around this?
3) I will eliminate packages libddcutil0 and libddcutil-dev.  The shared 
library does not (yet) implement all the functionality needed by the 
command line application, which is why ddcutil is not linked against 
libddcutil0, and it is subject to change from user feedback and as the 
Python API is implemented. Those wishing to experiment the the API can 
get the shared library from my site or OBS.


Sanford



On 07/24/2017 03:11 PM, Andrey Rahmatullin wrote:

Control: tags -1 + moreinfo

Please remove all unneeded files from debian/.
Please remove commented out sample lines from debian/rules.
You shouldn't "Bump Debian release for debian-mentors". Please remove all
changelog entries (both old upstream ones and recent bumps) and add oe
correct entry.
Please switch to the debhelper compat level 10.
B-D: libglib2.0-0 looks wrong.
Please update to the current Standards-Version version.
Please fix and uncomment Vcs-Browser.
Adding explicit Depends: on library packages is usually wrong.
Please remove unneeded comments from debian/control.
Please drop debian/menu.
Consider adding the symbols file.
Please don't ship .la.
I'd expect ddcutil to be linked against libddcutil0.

Bug#858510: ITP: ddcutil -- control monitor settings

[Sanford Rockowitz]

Stephen,

I'd very much appreciate your help as co-maintainer and sponsor.  This
is my first attempt to submit a package to debian.   ddcutil has been
packaged on OBS and Launchpad for some time now, but I spent hours this
morning lost in the proverbial "maze of twisty little passages, all
alike", trying to figure out how to submit the package. I'm sure there's
a lot of cruddy details to be fixed up.

The ddcci driver is an interesting project.   It hides the gory details
of building and sending DDC packets.  But there also seems to be a lot
of missing functionality: e.g. EDID reads on slave address x50, only a
few DDC commands are supported.The ddccii driver   implementation of
the capabilities inquiry returns an error if any write/read sub-exchange
fails.  In my experience with marginal monitors, you need retry logic
for both the individual sub-exchanges and the entire meta exchange, what
ddcutil calls multi-part-exchanges - otherwise you just don't get lucky.

Because of the early experimentation, the layer that reads and writes
I2C packets is designed to be swapped, so it should be possible to use
ddcci as an alternative strategy.   However, ddcutil would still need to
use the i2c-dev interface for things the ddcci driver does not do, and
I'd prefer not to add a dependency on a driver that can't be relied on
to always be there. 

Given all these issues, I think the best relationship between ddcutil
and the ddcci driver would be to use ddcutil as a testing framework for
the driver.

I'll install the ddcci driver and play with it a bit. 

Sanford



On Sun, 26 Mar 2017 16:42:01 +0200 Stephen Kitt  wrote:
> Hi Sanford,
>
> On Wed, 22 Mar 2017 19:11:38 -0400, Sanford Rockowitz

> wrote:
> > * Package name : ddcutil
> > Version : 0.7.3
> > Upstream Author : Sanford Rockowitz 
> > * URL : http://www.ddcutil.com
> > * License : GPL
> > Programming Lang: C
> > Description : control monitor settings
> >
> > ddcutil is a Linux program for querying and changing monitor
settings, such
> > as brightness and color levels.
> [...]
> > I am the developer and presently the sole maintainer. maintain it?
inside a
> > packaging team
>
> This is very cool, thanks for developing ddcutil! I’m the maintainer of
> ddcci-driver-linux, and if you’re looking for a co-maintainer (and
sponsor)
> for ddcutil I’d be up for it.
>
> Incidentally, is there any chance ddcutil could support the ddcci module?
>
> Regards,
>
> Stephen

Bug#861617: RFS: ddcutil/0.8.0-6 [ITP] - control monitor settings

[Sanford Rockowitz]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "ddcutil"

 * Package name: ddcutil
   Version : 0.8.0-6
   Upstream Author : Sanford Rockowitz 
 * URL : https://github.com/rockowitz/ddcutil
 * License : GPL-2.0
   Section : utils

  It builds those binary packages:

ddcutil- Control monitor settings - Standalone command line version
libddcutil-dev - ddcutil - C development files
libddcutil0 - ddcutil - Shared libraries

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/ddcutil


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/d/ddcutil/ddcutil_0.8.0-6.dsc

  More information about ddcutil can be obtained from
https://www.ddcutil.com

  Changes since the last upload:

  ddcutil (0.8.0-6) unstable; urgency=low
 
* Bump Debian release for debian-mentors

ddcutil is a utility for querying and changing monitor settings, such as
brightness and color levels.   

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:
- To record and reset color related settings as part of color profile
management
- Switching monitor input
- Controlling brightness

The most closely comparable program is ddccontrol, which has not been
maintained
for several years.  The design of ddcutil differs from ddccontrol in two
fundamental
ways that should make it more robust in the face of hardware changes and
monitor
variation:

1) It uses the userspace i2c-dev interface instead of providing its own
I2C drivers,
so is less sensitive to video driver implementation.

2) Instead of relying on a database of features by monitor model, which can
never hope to be up to date, ddcutil bases its feature interpretation on
a detailed understanding of the MCCS specification.  The downside is that
can only give generic interpretation for MCCS Virtual Control Panel features
in the range reserved for manufacturer specific features.


  Regards,
   Sanford Rockowitz

Bug#858510: ITP: ddcutil -- control monitor settings

[Sanford Rockowitz]

Package: wnpp
Severity: wishlist
Owner: Sanford Rockowitz 

* Package name: ddcutil
  Version : 0.7.3
  Upstream Author : Sanford Rockowitz 
* URL : http://www.ddcutil.com
* License : GPL
  Programming Lang: C
  Description : control monitor settings

ddcutil is a Linux program for querying and changing monitor settings, such as
brightness and color levels.

ddcutil primarily uses DDC/CI (Display Data Channel Command Interface) to
communicate with monitors implementing MCCS
(Monitor Control Command Set) over I2C.  Normally, the video driver for the
monitor exposes the I2C channel as devices named /dev/i2c-n.  Alternatively,
there is support for monitors (such as Eizo ColorEdge displays) that implement
MCCS using a USB connection.

A particular use case for ddcutil is as part of color profile management.
Monitor calibration is relative to the monitor color settings currently in
effect, e.g. red gain.  ddcutil allows color related settings to be saved at
the time a monitor is calibrated, and then restored when the calibration is
applied.

ddcutil can be seen as a replacement for the no longer maintained ddccontrol.
It differs from ddccontrol in several ways that should make it more robust:

- It relies on the i2c-dev userspace interface to I2C rather than attempting to
program specific video cards at the PCI level.

- It uses detailed knowledge of the Monitor Control Command Specification
(MCCS) to interpret settings instead of hand crafted monitor-specific
configuration files.

I am the developer and presently the sole maintainer. maintain it? inside a
packaging team