net-print/cnijfilter/cnijfilter-2.80.ebuild
Created attachment 140828 [details] net-print/cnijfilter/cnijfilter-2.80.ebuild
This is based on bug #177970 Supports the later Canon Pixma models (mp140, mp210, ip3500, mp520, ip4500 and mp610). It works on my amd64 system with a Pixma iP3500, so no testing on servicetools has been done. I appreciate any feedback.
well... theoretically, it's not a good idea to have portage interpret the ebuild's version number, because it should be possible to install any of these versions in parallel, as they all support different printers.
You're right in principle. One could slot the different 'versions' to be able to install them in parallel. However these ebuilds only bridge the time until opensource drivers are available. I think the most important point is, that there is a working solution. :)
(In reply to comment #2) > It works on my amd64 system with a Pixma iP3500, so no testing on servicetools > has been done. I appreciate any feedback. I can confirm that it works with x86 and ip4500. Only 600dpi though and I did not try any special paper yet, but the usual cups-test page looks good. Thanks for this workaround!
Is there a way to increase the max dpi?
Hi there, just tried this ebuild on my x86-64 system. I have a Canon Pixma MP210 and it works just fine.
Why is this bug resolved? It doesn't exist in portage so it should remain open.
reopening this so it can be found by a standard search...
Hi, thank you very much for the ebuild, installed and works great. But I couldn't find a option to print Grey scale picture instead of RGB color one anywhere. My MP210 only have RGB in color model option to choose from. That is the contents of ColorModel in my /usr/share/cups/model/cannonmp210.ppd: *OpenUI *ColorModel/Color Model: PickOne *DefaultColorModel: rgb *ColorModel rgb/RGB: "<</cupsColorOrder 0/cupsColorSpace 1/cupsCompression 0/cupsBitsPerColor 8>>setpagedevice" *CloseUI: *ColorModel I suppose that modify that it could do the trick, but don't know how. Seems my problem same like this: http://ubuntuforums.org/archive/index.php/t-900883.html but strange thing is I can't find in either Adobe Reader8 or Evince howto print a color pdf file in grey scale.
Tried to print in KPDF today, even set color mode to grayscale inside KPDF, it still print out a color one. So it seems to me something wrong with driver. Unless I change the source to print, there is no way that I can print a pdf document from this printer a grayscale output using this driver.
The 2.90 is available (for example iP100): http://software.canon-europe.com/products/0010626.asp
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Duplicate of bug #130645 ?
you do realize that those different versions all target different printer models? To integrate this properly and usably, we need to create an ebuild that automatically installs the correct version(s) of cnijfilter based on a printer selection by useflag.
I would not do it that complicated. Just provide the ebuild, and let the user figure out which version he needs. Preferably the ebuild would be slotable. Another idea would be to name the package net-print/cnijfilter_2.80 and create a -0 version, so the meta net-print/cnijfilter package could depend on the specific versions.
Additional download URL (existing two aren't working for me): http://gdlp01.c-wss.com/gds/1/0100000841/01/cnijfilter-common-2.80-1.tar.gz
The servicetools use flag requires libxml, which has just been hardmasked: # Samuli Suominen <ssuominen@gentoo.org> (18 Mar 2010) # Orphaned and vulnerable library. Use libxml2 instead. # # Bugs 281446 and 281444 # # Masked for removal in 30 days
Created attachment 227699 [details] updated URI and DEPEND ok, I've updated the ebuild to use the new download URL and to depend on ghostscript-gpl. I couldn't really test the servicetools with libxml2 since I don't have the printer here. But they seem to compile and some also start up. More testing appreciated.
Do the USE flags in this ebuild change the outcome of the compilation? Scanning through it, I didn't see how they changed the build process...
(In reply to comment #20) > Do the USE flags in this ebuild change the outcome of the compilation? > Scanning through it, I didn't see how they changed the build process... > Yes. In src_compile(): for i in `seq 0 ${_max}`; do if use ${_pruse[$i]} || ${_autochoose}; then _pr=${_prname[$i]} _prid=${_prid[$i]} src_compile_pr; fi done
(In reply to comment #19) > Created attachment 227699 [details] > updated URI and DEPEND > > ok, I've updated the ebuild to use the new download URL and to depend on > ghostscript-gpl. I couldn't really test the servicetools with libxml2 since I > don't have the printer here. But they seem to compile and some also start up. > More testing appreciated. Is 2.80 the latest version supporting your printers? If not, better try to bump ebuild to latest one. More suggestions: - Isn't your printed supported by opensource alternatives like gutenprint/sane-backends? - Try to bump ebuild to EAPI=4. Looks at: http://devmanual.gentoo.org/ebuild-writing/eapi/index.html for that. - License should be "GPL-2" and we would need to commit a "Canon" license to the tree per I can read in: http://support-asia.canon-asia.com/contents/ASIA/EN/0100084101.html - Update homepage to above one ;) - Try to use a SLOT for it -> 2.80 , that way we try to allow parallel installation with other driver versions. Other option would be to have a different package for each version, probably this needs more discussion (how would be better to handle this, slotting or separate packages?) - IUSE contents look to be wrong: most listed flags are not used in ebuild and, then, should be dropped from IUSE - DEPEND mixes runtime deps with buildtime ones, split them please listing buildtime only deps only under DEPEND and remaning ones under RDEPEND. - pkg_setup: * Drop LINGUAS checking, it doesn't look to be needed * servicetools looks to need gtk+1 and libxml, both are deprecated (libxml was removed), please recheck if that dependencies are ok (updated) and, if still needing that old stuff, simply remove its support always. * Are you setting /usr/local as prefix? It's wrong, it should use /usr or /opt if it's a binary only application: http://devmanual.gentoo.org/general-concepts/filesystem/index.html * /usr/lib/cups should also use get_libdir instead of plain "lib" * Drop "einfo" statements about USE flags, descriptions must go in metadata.xml files. * Is "nocupsdetection" really need for Gentoo? Maybe it could be renamed to "bindist" :-/ - src_compile: * Split commands to complaint src_configure and src_compile phases. Also think about src_prepare phase for other tasks. * Change all "make" invocations to use "emake" instead - src_install: * Use "emake" instead of "make" - pkg_postinst: * Use "elog" instead of "einfo": http://devmanual.gentoo.org/ebuild-writing/messages/index.html - src_compile_pr: * Drop sleep command if not really required Thanks a lot for taking care
Created attachment 296003 [details, diff] Proposed patch for jmpbuf build error
Created attachment 296005 [details] ebuild file that uses the setjmp patch The code no longer compiles due to a change in the libpng: as of libpng-1.5.0, the definition of png_struct moved to a separate .h file that is inaccessible to clients, so the code cannot access png_p->jmpbuf directly. I get the following build error from emerge: > bjfimage.c: In function 'png_image_init': > bjfimage.c:1578:6: error: dereferencing pointer to incomplete type The proposed cnijfilter-2.80-fix-jmpbuf.patch file that I just attached, along with the attached cnijfilter-2.80-r1.ebuild (which is identical to the 2010-04-14 ebuild except for two extra lines to call the patch), fixed the problem on my system.
I've used a similar patch and seems to work. More info from an Arch guy: http://paste.pocoo.org/show/549065/
Are you interested in maintaning this driver directly yourself in the new printer-drivers overlay [1]? If yes, just send me via personal e-mail at dilfridge@gentoo.org the following data, so we can give you git push access to the overlay: * the user name that you'd like to have * your public ssh key [2], so we can give you git push access to the overlay * your e-mail address * and your full name If you have a gnupg key, you should sign that e-mail [3]. Just a few rules: * Initially, the ebuilds should work for you, and not break anything else. * You enter yourself as maintainer in metadata.xml (together with the printing herd), and are then automatically cc'ed in bug reports on bugzilla. * We will guide you towards improving the ebuilds over the next months so they follow the rules and qa guidelines of the Gentoo main portage tree. In particular this means also using a recent EAPI (3 or perferably 4), and fixing repoman warnings [4]. Don't worry, we'll help you with that. * I hope this is never going to happen, but... ebuilds that "work but go against the guidelines" and do not see any improvement will be removed again one year after initial addition. There are many ways to get help. * You can directly ask me by personal e-mail (my time is limited, but I'll try), * you can ask on freenode, channel #gentoo-dev-help, * you can read the documentation (ebuild howto [5], devmanual [6]), * ... [1] http://git.overlays.gentoo.org/gitweb/?p=proj/printer-drivers.git;a=summary [2] http://www.gentoo.org/doc/en/articles/openssh-key-management-p1.xml [3] http://www.gentoo.org/doc/en/gnupg-user.xml [4] http://dev.gentoo.org/~zmedico/portage/doc/man/repoman.1.html [5] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2 [6] http://devmanual.gentoo.org/
*** Bug 130645 has been marked as a duplicate of this bug. ***
*** Bug 258244 has been marked as a duplicate of this bug. ***
*** Bug 446530 has been marked as a duplicate of this bug. ***
as mentioned in comment 15, those cnijfilter bug reports are for different versions of cnijfilter, which is neither forward or backward compatible with this one and are intended for different printers. Please unduplicate those three reports.
seems it was irritating some people cause there are no slots for this package I suggest you introduce slots for each of them and make them block each other in case there are file collisions. This is sane for driver ebuilds, cause it indicates that we have different set of features/compatibility here and users will not just want the latest version.
*** This bug has been marked as a duplicate of bug 446530 ***
If you are still interested in the 2.80 version, please request again the package for your printer series as explained in https://wiki.gentoo.org/wiki/Canon_Pixma_Printer. This way to sort between "no more needed" / "still needed" ones, and to avoid wasting time on obsolete / unused series.
