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/192731475679616@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
Attachment:
signature.asc
Description: This is a digitally signed message part