Re: building both monolithic command line program and shared library from single source package, ddcutil

[Paul Wise]

On Mon, Jan 27, 2020 at 4:50 PM Sanford Rockowitz wrote:

> True. ddcutil internals were reworked some time ago for what I call User
> Supplied Feature Definitions.

Another aspect of manufacturer-specific features is that they can be
used to do things that never should be allowed, like run arbitrary
code inside the monitor. I wonder if the Linux kernel should be
blocking access to at least the dangerous ones like Genesis' GProbe:

https://github.com/redballoonshenanigans/monitordarkly

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Adam Borowski]

On Mon, Jan 27, 2020 at 02:46:32PM +0100, Gürkan Myczko wrote:
> 14:40 < tarzeau> coreboot sources are partly GPL-2-only (aka GPL-2) some are
> GPL-2-or-later (aka GPL-2+), is it possible to clean that up?
> 14:40 < tarzeau> relicense to one?
> 14:40 < maxii> but cb_parse_framebuffer() doesn't seem to get called
> 14:40 < tarzeau> debian/ubuntu packaging effort details:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946959
> 14:41 < maxii> nico_h: I think I am seeing the problem, not the solution.
> But at least a possible reason/the origin of the problem
> 14:41 < nico_h> tarzeau: you can just ship it as GPL-2-only, if that makes
> it easier
> 14:42 < tarzeau> well not really an option, i'm not the authority of the
> source files, so only authority of them can do so (if i did, it'd be a fork)
> 14:43 < tarzeau> (and even if i did and wanted, i can't just relicense stuff
> that's already published by another license)
> 14:44 -!- r1mikey [~r1mikey@2620:10d:c092:200::1:2fbd] has joined #coreboot
> 14:44 < nico_h> tarzeau: there's the point, you can relicense it in this
> case. and if you ship binaries that are build from both GPL-2-only and
> GPL-2-or-later you implicitly relicense parts of it anyway

I don't see any problem either.  GPL-2-only and GPL-2-or-higher are very
compatible licenses.  If you combine them, the result is GPL-2-only
(although if someone picks just GPL2+ pieces, they revert to compatibility
with GPL3 and so on.

That's the very point of license alternatives.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from
⣾⠁⢠⠒⠀⣿⡁ the Y292B problem.  So let's move the Epoch by 43545140006400
⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it
⠈⠳⣄ unsigned -- that'll almost double the range.

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[John Scott]

> > If there really is a problem with those files I would appreciate your
> > letting me know what I missed. Otherwise I hope you can avoid the 
> > repacking trouble in the future.
> Probably not, but the repacking is not trouble.

Without a good reason, you really shouldn't repack [1]. I do not understand 
your motivation for removing those files since they don't end up in the binary 
packages.

Repacking means that you, collaborators, and volunteers working on quality 
assurance can't
* use tools like uupdate to upgrade to a new upstream version very easily
* can't verify the tarball against upstream's signature
* package those parts being removed from Coreboot later on without duplicating 
effort into another source package

Perhaps you're not aware that it is typical to disregard parts of the package 
that aren't built (yet). Otherwise I would like to know what advantage it has 
for my own potential applications, and you should explain in debian/copyright 
how the source differs [2].

> You can save you that pain. I already stole your watch file, now it
> says:
> E: coreboot source: debian-watch-file-pubkey-file-is-missing

I thought I had sent a merge request, but seeing no trace I must not have. I 
wanted it to have an explanation of how to modify the watch file to do the 
repacking for you.
It's necessary to put the Coreboot team's minimal OpenPGP
key in debian/upstream/signing-key.asc, and I didn't do it because of the 
sensitivity of the key material. The wiki [3] explains what you need to do, 
and to determine the key you need, GnuPG will say or complain which if you try 
verifying the tarball.

[1] https://perl-team.pages.debian.net/howto/repacking.html#0._INTRODUCTION
[2] https://wiki.debian.org/BenFinney/software/repack
[3] https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

signature.asc
Description: This is a digitally signed message part.

Re: building both monolithic command line program and shared library from single source package, ddcutil

[Sanford Rockowitz]

On 1/27/20 4:26 AM, Paul Wise wrote:
...

lintian detects a few minor issues in the source and binary packages
that I suggest polishing off. The main one for me is to include symbols
files so that dependencies on libddcutil2 can be minimised to the
version that introduced each of the used symbols, this won't do
anything right now but after a number of years of symbol additions, it
helps ease upgrades between Debian releases.

lintian --info --display-info --display-experimental --pedantic 
--show-overrides --color auto *.changes
https://wiki.debian.org/UsingSymbolsFiles

BTW, once the shared library is available in Debian you might want to
use pkg-abidiff and abipkgdiff (they are complementary) to ensure that
you don't break the ABI accidentally before every release.

https://github.com/lvc/pkg-abidiff
https://sourceware.org/libabigail/manual/abipkgdiff.html
https://lists.debian.org/msgid-search/192731475679...@web2g.yandex.ru

Thanks.
...

ddccontrol relies on its monitor database for feature interpretation.

It seems like ddcutil also needs a monitor database for the
interpretation of manufacturer specific features, according to the
`ddcutil capabilities` command, mine has seven, with six of them having
the interpretation unavailable.
True. ddcutil internals were reworked some time ago for what I call User 
Supplied Feature Definitions. (See the notes for release 0.9.3 in 
www.ddcutil.com/release_notes and http://www.ddcutil.com/c_api_93/.) 
What remains to be done is what I'll refer to as the externals.   
Presently, feature definitions are read from a file in the current 
directory having a homegrown format, which allowed for testing.  I 
expect to convert the file to YAML.  A proper search path for definition 
files needs to be implemented. The API needs a way to specify feature 
definitions. Perhaps ddcui should have a dialog for defining features.  
Etc, etc.

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Gürkan Myczko]

14:40 < tarzeau> coreboot sources are partly GPL-2-only (aka GPL-2) some 
are GPL-2-or-later (aka GPL-2+), is it possible to clean that up?

14:40 < tarzeau> relicense to one?
14:40 < maxii> but cb_parse_framebuffer() doesn't seem to get called
14:40 < tarzeau> debian/ubuntu packaging effort details: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946959
14:41 < maxii> nico_h: I think I am seeing the problem, not the 
solution. But at least a possible reason/the origin of the problem
14:41 < nico_h> tarzeau: you can just ship it as GPL-2-only, if that 
makes it easier
14:42 < tarzeau> well not really an option, i'm not the authority of the 
source files, so only authority of them can do so (if i did, it'd be a 
fork)
14:43 < tarzeau> (and even if i did and wanted, i can't just relicense 
stuff that's already published by another license)
14:44 -!- r1mikey [~r1mikey@2620:10d:c092:200::1:2fbd] has joined 
#coreboot
14:44 < nico_h> tarzeau: there's the point, you can relicense it in this 
case. and if you ship binaries that are build from both GPL-2-only and
GPL-2-or-later you implicitly relicense parts of it 
anyway

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Steffen Möller]

Heya,

Please contact upstream about that GPL-2 vs GPL-2+ issue. They may not
be aware.

Cheers,

Steffen 

On 27.01.20 13:19, Gürkan Myczko wrote:

Hi John,


The package is in great shape. The only challenge to getting the
package in
the archive seems to be the copyright file. Coreboot's README says
Some files are licensed under the "GPL (version 2, or any later
version)",
and some files are licensed under the "GPL, version 2". For some parts,
which were derived from other projects, other (GPL-compatible)
licenses may
apply. Please check the individual source files for details.


That'll be a pain to do but yes.


debian/copyright says most files are GPL 2+, but it my digging
indicates the
majority are GPL 2 only, and I think I saw additional licenses too.


I see, more work.


I believe upstream has recently expressed desire to make listings
files with
respective licenses and/or using SPDX identifiers, rather than their
lengthy
headers in the source. If that's true, checking out the Git version
might help
you parse the licenses.


I heard about that in #coreboot irc channel.


Speaking of which, you repacked Coreboot with the contents of 3rdparty/
removed. As a Libreboot user I thought I understood why, but as best
as I can
tell those files are free. On Coreboot's downloads page they appear to
distribute the blobs separately which is news to me.


Partly removed, half re-added for util/cbfstool to build.


If there really is a problem with those files I would appreciate your
letting
me know what I missed. Otherwise I hope you can avoid the repacking
trouble in
the future.


Probably not, but the repacking is not trouble.


Lastly, a small enhancement is to add a debian/watch file so that
tools can
check for and utilize new upstream versions automagically. I plan to
send a
Salsa merge request with details shortly.


You can save you that pain. I already stole your watch file, now it says:
E: coreboot source: debian-watch-file-pubkey-file-is-missing


I hope my feedback is useful for you to help your package.


Yes appreciated, thank you.

BTW, my latest work is here:
http://phd-sid.ethz.ch/debian/coreboot/
the 4.11 one.

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Gürkan Myczko]

Hi John,

The package is in great shape. The only challenge to getting the 
package in

the archive seems to be the copyright file. Coreboot's README says
Some files are licensed under the "GPL (version 2, or any later 
version)",

and some files are licensed under the "GPL, version 2". For some parts,
which were derived from other projects, other (GPL-compatible) licenses 
may

apply. Please check the individual source files for details.


That'll be a pain to do but yes.

debian/copyright says most files are GPL 2+, but it my digging 
indicates the

majority are GPL 2 only, and I think I saw additional licenses too.


I see, more work.

I believe upstream has recently expressed desire to make listings files 
with
respective licenses and/or using SPDX identifiers, rather than their 
lengthy
headers in the source. If that's true, checking out the Git version 
might help

you parse the licenses.


I heard about that in #coreboot irc channel.


Speaking of which, you repacked Coreboot with the contents of 3rdparty/
removed. As a Libreboot user I thought I understood why, but as best as 
I can

tell those files are free. On Coreboot's downloads page they appear to
distribute the blobs separately which is news to me.


Partly removed, half re-added for util/cbfstool to build.

If there really is a problem with those files I would appreciate your 
letting
me know what I missed. Otherwise I hope you can avoid the repacking 
trouble in

the future.


Probably not, but the repacking is not trouble.

Lastly, a small enhancement is to add a debian/watch file so that tools 
can
check for and utilize new upstream versions automagically. I plan to 
send a

Salsa merge request with details shortly.


You can save you that pain. I already stole your watch file, now it 
says:

E: coreboot source: debian-watch-file-pubkey-file-is-missing


I hope my feedback is useful for you to help your package.


Yes appreciated, thank you.

BTW, my latest work is here:
http://phd-sid.ethz.ch/debian/coreboot/
the 4.11 one.

Re: building both monolithic command line program and shared library from single source package, ddcutil

[Paul Wise]

On Mon, 2020-01-27 at 03:28 -0500, Sanford Rockowitz wrote:

> ddcui is not in Debian because, simply put, it's not ready for prime time.

Fair enough, I'll be glad to try it when it is.

> My question to the list was whether this is acceptable, which it
> appears to be.

Correct.

> If you're curious, the latest libddcutil and ddcui can be found at my
> PPA, https://launchpad.net/~rockowitz/+archive/ubuntu/ddcutil. 
> I'd very much appreciate any feedback you might have. 

lintian detects a few minor issues in the source and binary packages
that I suggest polishing off. The main one for me is to include symbols
files so that dependencies on libddcutil2 can be minimised to the
version that introduced each of the used symbols, this won't do
anything right now but after a number of years of symbol additions, it
helps ease upgrades between Debian releases.

lintian --info --display-info --display-experimental --pedantic 
--show-overrides --color auto *.changes
https://wiki.debian.org/UsingSymbolsFiles

BTW, once the shared library is available in Debian you might want to
use pkg-abidiff and abipkgdiff (they are complementary) to ensure that
you don't break the ABI accidentally before every release.

https://github.com/lvc/pkg-abidiff
https://sourceware.org/libabigail/manual/abipkgdiff.html
https://lists.debian.org/msgid-search/192731475679...@web2g.yandex.ru

> Because it's not in Debian.  Once it is, they will stop using a
> private copy. 

I may have misinterpreted "private copy", I had assumed you meant an
embedded code copy in one of their git repos, but it now sounds like
you meant they packaged a newer version in their apt repo. I probably
shouldn't have said "official version" as it sounds like you
interpreted that as "official Debian version", while I meant the
upstream version as I thought they had their own (modified) copy.
Sorry for the confusion here :)

> This is a very old project that was briefly resurrected a few years
> ago.  Its design makes it very brittle.

Thanks for the info, ddcutil definitely seems the better design.

> ddccontrol relies on its monitor database for feature interpretation.

It seems like ddcutil also needs a monitor database for the
interpretation of manufacturer specific features, according to the
`ddcutil capabilities` command, mine has seven, with six of them having
the interpretation unavailable.

BTW: in case you aren't aware of Repology, you can see which distros
carry ddcutil, which versions they carry etc here:

https://repology.org/project/ddcutil/packages

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: building both monolithic command line program and shared library from single source package, ddcutil

[Sanford Rockowitz]

On 1/26/20 11:45 PM, Paul Wise wrote:

On Sun, 2020-01-26 at 23:01 -0500, Sanford Rockowitz wrote:


I'm unaware of plans to support DDC in the Linux kernel.

I just discovered the ddcci-driver-linux project. It is available in
Debian in the ddcci-dkms binary package. I've tried it locally but it
doesn't appear to be very useful for me yet.

https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux
I checked out this project a couple years ago.  It could conceivably 
replace the very lowest layers of ddcutil. I will take a closer look.

a Qt based C++ GUI, ddcui

I note that this isn't available in Debian yet, I am assuming that is
why you have brought this discussion to the list.
ddcui is not in Debian because, simply put, it's not ready for prime 
time.  In particular, the Qt code related to layout and formatting needs 
to be reworked.  i's need to be dotted, and t's crossed.


The libddcutil API, on the other hand, is solid and stable, and so 
belongs in Debian.  There had been a suggestion that it was odd for the 
command line version of ddcutil to not use the library.  My question to 
the list was whether this is acceptable, which it appears to be.


If you're curious, the latest libddcutil and ddcui can be found at my 
PPA, https://launchpad.net/~rockowitz/+archive/ubuntu/ddcutil. 


I'd very much appreciate any feedback you might have.

On the other hand, there are things that ddcutil does to accommodate
variations in monitor DDC/CI implementations that probably don't
belong in the kernel.

I think the Linux kernel already deals with quirks for various types of
hardware, so I don't think it would be too much trouble to maintain the
code for the DDC quirk types in the Linux kernel and the application of
those quirks in udev. I think that this is typically how hardware
quirks are applied on Linux based distributions.


Finally, unifying brightness control means alternatively using ACPI for
laptop displays and DDC for others. It seems to me that even if the
kernel supported DDC, this ACPI/DDC unification is more appropriately
done at a higher level than the kernel, probably in xrandr.  For the
time being, an application can unify these facilities using libddcutil
for DDC.

The Linux kernel already exposes LED information and control, display
brightness and control and so on in standard ways, which are then
consumed by userland tools, either directly or via daemons. So I think
it isn't too much of a stretch for those to be available for DDC too.
xrandr isn't used by Wayland based shells so that isn't the appropriate
layer to introduce this feature. Keeping the DDC code out of the Linux
kernel means that every single desktop has to add support for
libddcutil instead of just adding it to Linux. Since Wayland shells run
as the user rather than root, Wayland apps are not allowed to be run as
root and accessing i2c devices on Linux typically requires root,
control of monitor brightness via DDC won't be available for Wayland
shells/apps, only via terminal or X11 applications run via sudo.


(The KDE-Neon folks currently use a private copy of libddcutil
for this purpose.)

Any particular reason they can't use the official version?


Because it's not in Debian.  Once it is, they will stop using a private 
copy.


PS: are you aware of the ddccontrol project (also in Debian)?
It has a monitor database, shared library, command-line tools and GUI.

https://github.com/ddccontrol/ddccontrol
https://github.com/ddccontrol/ddccontrol-db
This is a very old project that was briefly resurrected a few years 
ago.  Its design makes it very brittle.  See 
http://www.ddcutil.com/ddccontrol/#comparison-with-ddccontrol. Because 
ddcutil relies on /dev/i2c instead of trying to program I2C devices at 
the PCI level, ddcutil does a much better job of detecting and 
communicating with monitors, and coping with new device drivers.  
ddccontrol relies on its monitor database for feature interpretation.  
Trying to keep that up to date is like sweeping sand on a beach.  
ddcutil, on the other hand, relies on a detailed understanding of the 
Monitor Control Command Set (MCCS) specification for feature 
interpretation.  See the output of command "ddcutil vcpinfo --verbose", 
to get a sense of what ddcutil knows, or look at how ddcui reports 
features.

It would be great if yourself and the folks from ddcci-driver-linux and
ddccontrol could work together in order to come up with a modern design
and implementation for supporting control of monitors under Linux.