gimp-print-4.2.7 ebuild did not emerge the lexmark printer drivers. In fact a file search did not find any Lexmark files. A search inside /usr/portage/distfiles/gimp-print-4.2.7.tar.gz found a file print-lexmark.c which had apparently not been run by the ebuild. I downloaded the gimp-print-4.2.7 source from sourceforge and ran make and make install. This generated a large number of language directories under /usr/share/cups/model which contained a huge number of 'printername'.ppd.gz files. However lexmark-z52.ppd.gz was not gunzipped to /usr/share/cups/model as lexmark-z52.ppd by make install. After manual gunzip and a cups restart lexmark appeared in the cups' printer manufacturer list and the z52 in the printer list in the web based administrator. The z52 then installed and tested satisfactorily satisfactorily. Reproducible: Always Steps to Reproduce: 1.emerge cups gimp-print ghostscript and try to find lexmark printer. 2. 3. Actual Results: no lexmark printers Expected Results: installed lexmark ppd files
does it work with the 5.0_rcs?
Please try the 5.0_rc releases
portage does not contain any gimp-print release candidates googling does not find any gimp-print release candidate 5.0 google did find a gutenprint 5.0.0-rc1 on source forge my issue is not with gimp-print but rather with the gentoo ebuild implementation of it emerging gimp-print did not provide directory /usr/share/cups/model/C/ filled with gzipped ppd files including lexmark-z52.ppd.gz emerging gimp-print did not provide directory /usr/share/cups/model/C/ filled with ppd files including lexmark-z52.ppd emerging gimp-print did not provide directory /usr/share/cups/model/ filled with ppd files including lexmark-z52.ppd thus running web based admin could not find /usr/share/cups/model/lexmark-z52.ppd to copy it as /etc/cups/ppd/Z52.ppd download of gimp-print source and compiling it (make && make install) provided a directory /usr/share/cups/model/C/ filled with gzipped ppd files including lexmark-z52.ppd.gz ungzipped lexmark-z52.ppd.gz to /usr/share/cups/model/C/lexmark-z52.ppd copied /usr/share/cups/model/C/lexmark-z52.ppd to /usr/share/cups/model/lexmark-z52.ppd web based admin then built /etc/cups/Z52 I think emerge gimp-print should provide the full load of ppd files at /usr/share/cups/model/ and if not that, then the full load of ppd.gz files at /usr/share/cups/model/C/ with notes as to getting the needed ppd file to /usr/share/cups/model/
/usr/portage/media-gfx/gimp-print/gimp-print-5.0.0_rc1.ebuild oh yes, there is one .. try that please :)
thanks for the specific location, I was using emerge search gimp-print and getting nothing after renaming the /usr/share/cups/model directory and the /etc/cups/z52.ppd file; putting =media-gfx/gimp-print-5.0.0_rc1 ~and64 in package.keywords; running emerge =media-gfx/gimp-print-5.0.0_rc1 produced /usr/share/cups/model/gutenprint/5.0/C and /usr/share/cups/model/gutenprint/5.0/da and /usr/share/cups/model/gutenprint/5.0/de and 13 other language directries. each language directory containing bunches of ppd.gz files. Hooray!! running the web based cups admin demonstrated that these ppd.gz files were readable. The number of printer manufacturers in the dropdown increased dratically and included Lexmark. Hooray!! Selecting Lexmark and continuing lead to a dropdown conaining 16 entries for each Lexmark printer supporting linux. My Z52 was included. Hooray!! Unfortunately each of the 16 entries read: "Lexmark Z52-CUPS+Gutenprint v5.0.0_rc1(en)" The 16 listings presumably should be for each of 16 languages so "Lexmark Z52-CUPS+Gutenprint v5.0.0_rc1(da)" next and "Lexmark Z52-CUPS+Gutenprint v5.0.0_rc1(de)" after that and so on
(In reply to comment #5) I have to admit this didn't work for me: either with or without renaming /usr/share/cups/model Without renaming, the directory is unchanged, with renaming, a new one is not created. I followed the same path as below, except for the "~and64", wasn't sure what this would do and there was no *.ppd files in /etc/cups. /etc/cups/ppd has "EpsonCopier.ppd", which I did not change. I have not installed any gutenprint (or anything else), except via emerge. Any ideas? > after renaming the /usr/share/cups/model directory and the /etc/cups/z52.ppd > file; > putting =media-gfx/gimp-print-5.0.0_rc1 ~and64 in package.keywords; running > emerge =media-gfx/gimp-print-5.0.0_rc1 produced
Never mind...I didn't have "ppds" in my USE flag. Sorry, still getting used to Gentoo. My result is the same as Drake's, a lot of duplicate names. (In reply to comment #6)
This is fixed in the 5.0.0_rc releases
gimp-print-5.0.0_rc2 does not correct the appearance of 16 (en) copies although they do have a minor name change, i.e. "Lexmark Z52-CUPS+Gutenprint v5.0.0_rc2(en)"
try again with USE=-nls
With use= containing -nls, emerge gimp-print gives 1 language directory, C. if I do not restart cupsd, the web based cups admin will still show 16 entries {all (en)} per Lexmark printer type. After cupsd restart, the web based cups admin will show only 1 entry {(en)} per printer type. With use= blank with respect to nls, emerge gimp-print gives 16 language directories. If I do not restart cupsd, the web based cups admin will still show only 1 entry {(en)} per Lexmark printer type. It appears that cups start generates a list/db somewhere (an incorrect list/db) of nodes/manufacturers/printer drivers/languages based on the content of /usr/share/cups/model/gutenprint/5.0. If the locale/language in the presumed database is taken from the LanguageVersion: ; it is English in the Lexmark ppd.gz's in all the language directories, (maybe in all ppd.gz's, canon drivers in the taiwan directory were LanguageVersion: English. My thought is that first fix should be to have the 16 drivers be correct by language(locale) in the presumed cups database. Second fix that the web based admin use locale(s) to determine which drivers to display per printer. If the printer drivers have no language differences then one driver per printer. "equery hasuse nls" shows a lot of packages including cups but not gimp-print. I've not previously specified nls. There seems to be a threat that my next emerge --update --newuse --deep world might get exciting. As I am fine at the moment I will remove the -nls. I assume package.use -nls for cups would work as well.
