net-print/c2esp depends on cups=<1.5, as it's last version to have cupsDitherNew() function It can't be build. It can't be fixed. It can only be removed. As we don't have non-automated bug requests, there are no users. https://bugs.gentoo.org/921087 https://bugs.gentoo.org/782610 https://bugs.gentoo.org/831390 https://bugs.gentoo.org/920314 Reproducible: Always
It's more complicated than that by a long shot. 1.6.0 was looooooong ago (2012!) and indeed at the time, cupsDitherNew was removed -- and moved to cups-filters, which is thereby a dependency of cups. It did work at the time of the most recent package update to c2esp: commit 3496e0734aea0e27e88cfe7b5bf804714c5fcba6 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: Mon Aug 27 15:43:13 2018 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: Mon Aug 27 17:05:32 2018 net-print/c2esp: Version bump to 27, EAPI 7 This now uses CMake, which is much less painful. Unfortunately my old printer turned out to be dead so this has only been build tested. Package-Manager: Portage-2.3.48, Repoman-2.3.10 --- net-print/c2esp/Manifest | 1 + net-print/c2esp/{c2esp-25c.ebuild => c2esp-27.ebuild} | 57 +++++++++++++++++---------------------------------------- net-print/c2esp/files/0001-Fix-various-missing-includes.patch | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 53 insertions(+), 40 deletions(-) copy net-print/c2esp/{c2esp-25c.ebuild => c2esp-27.ebuild} (10%) create mode 100644 net-print/c2esp/files/0001-Fix-various-missing-includes.patch Has this diff: +DEPEND=">=media-libs/jbigkit-2.0-r1:= + >=net-print/cups-1.6 + sys-libs/zlib:=" -DEPEND=">=media-libs/jbigkit-2.0-r1 - >=net-print/cups-1.4" In fact, cupsDitherNew existed until cups-filters 2.0.0, as it was a major part of the overall revamping of the cups ecosystem. It's not actually gone, that is just when this change was released: https://github.com/OpenPrinting/cups-filters/commit/eb24ac0bfe6aae4ac69c54a6ddcffeba5611a7ff And then the repository was split apart -- this code is now released distinctively as "libcupsfilters" instead of "cups-filters". Now, if we look at the c2esp configure script: #-lcupsdriver for cups < ver 1.6 AC_SEARCH_LIBS(cupsDitherNew, cupsdriver cupsfilters) if test "$ac_cv_search_cupsDitherNew" = "-lcupsdriver"; then : HAVE_LIBCUPSDRIVER="1" fi if test "$ac_cv_search_cupsDitherNew" = "-lcupsfilters"; then : HAVE_LIBCUPSFILTERS="1" fi It clearly supports cups version 1.6 (where the symbol was moved to cups-filters). Equally clearly, it hasn't adapted to cups-filters 2.0 where the symbol was renamed. That was packaged and handled in bug 923811. More insane yet: if test "$cupsversion" \< "1.6"; then AC_MSG_NOTICE([cups version is earlier than 1.6 - OK]) if test "$HAVE_LIBCUPSDRIVER" != "1"; then : AC_MSG_WARN([libcupsdriver was not found. Try installing a package like libcupsdriver1-dev and run configure again.]) fi else AC_MSG_NOTICE([cups version is 1.6 or later - OK]) if test "$HAVE_LIBCUPSFILTERS" != "1"; then : AC_MSG_WARN([HAVE_LIBCUPSFILTERS = $HAVE_LIBCUPSFILTERS libcupsfilters was not found. Try installing a package like libcupsfilters-dev and run configure again.]) fi fi Just a warning??? So - has it been broken since cups 1.6? No - has it been broken since cups 2? Yes. - is it impossible to fix? No. - does anyone use it? probably no! I suspect the reason for the automated bugs is actually because c2esp depends on cups, not cups-filters, and cups-filters is a PDEPEND of cups, which means it can be merged in any order and there has never been any guarantee at all that c2esp is installed only after cups-filters is installed. This is a flaw in that 2018 commit of 3496e0734aea0e27e88cfe7b5bf804714c5fcba6 but would not have been noticed because as long as cups has been installed in a different emerge, cups-filters would be as well. I'm not sure what the state of tooling was back then, but iwdevtools in particular wasn't released until several years later...
It is not supported upstream for the same reason it wasn't run-tested in the last update, lol. https://sourceforge.net/p/cupsdriverkodak/discussion/1107085/thread/07834beb/?limit=25#a571 > I cannot really support this project anymore. I no longer have any > Kodak printers running, so it's difficult to do any tests to try > and reproduce anyone's problems. I would treeclean it since it is not worth caring, even though we *could* port it to the new cups 2.x API.
