This is a binary distribution. The attached e-build (both the ebuild itself and the attached support files) allow me to use a Samsung SCX-4100 with CUPS for both printing and scanning (with SANE). Scanning is a bit quirky right now as I didn't want to install the libraries into /usr/lib but I don't know how to add an rpath to an existing .so (if such modifications of so's are possible, a bunch of the ones in this package should be cleaned up). As a result, LD_LIBRARY_PATH=/opt/samsungmfp/lib xsane is required.
Created attachment 91245 [details] Ebuild file for the samsung mfp usb printers
Created attachment 91246 [details] Archive also containing the required support files
And by the way, for some issues surrounding this binary release, take a look at http://hathawaymix.org/Weblog/2005-07-15. Basically everything depends on their custom qt library whose SONAME they didn't modify so it'll interfere with the regular one if installed in the usual path.
*** Bug 163325 has been marked as a duplicate of this bug. ***
Created attachment 107915 [details] app-misc/samsung-mfp-bin/samsung-mfp-bin-2.00.92.ebuild There is new, fully working ebuild for Samsung Unified Linux Drivers. It is merge of this bug ebuild and my ebuild from bug #163325. Most of TODOs from bug #163325 are done: - Companion apps are now installed if X, kde or gnome USE flags. - Added USE flag scanner with warning beep if it is not set. - Binary patch if USE flag fix-nopar set. Needed to be done: - Find out driver license (got from this bug ebuild as-is, but not sure). - Find out if we need to modify /etc/hotplug/usb/libsane.usermap and/or /etc/udev/rules.d/99-libsane.rules. Also, there is need in one of the most important things - feedback from users :).
Created attachment 107917 [details] samsung-mfp-bin.tar.bz2 - archive of ebuild and supplementary files (desktop and ld wrapper) Full file set for emerging drivers. app-misc/ app-misc/samsung-mfp-bin/ app-misc/samsung-mfp-bin/Manifest app-misc/samsung-mfp-bin/files/ app-misc/samsung-mfp-bin/files/samsung-mfp-bin-TonerReorder.desktop app-misc/samsung-mfp-bin/files/digest-samsung-mfp-bin-2.00.92 app-misc/samsung-mfp-bin/files/samsung-mfp-bin-HelpViewer.desktop app-misc/samsung-mfp-bin/files/samsung-mfp-wrap app-misc/samsung-mfp-bin/files/samsung-mfp-bin-Configurator.desktop app-misc/samsung-mfp-bin/samsung-mfp-bin-2.00.92.ebuild
I have found bug in one of my files - icon is not shown for HelpViewer menu entry: --- files/samsung-mfp-bin-HelpViewer.desktop.orig 2007-01-23 18:39:42.000000000 +0200 +++ files/samsung-mfp-bin-HelpViewer.desktop 2007-01-23 23:16:00.000000000 +0200 @@ -6,5 +6,5 @@ Comment=HTML help viewer utility Exec=/opt/samsung/mfp/bin/shhv Path=/opt/samsung/mfp -Icon=share/images/HelpViewer.png +Icon=/opt/samsung/mfp/share/images/HelpViewer.png Categories=Application;System;X-Samsung-Config-UD;
Also, there is an issue with network usage of scanner (via saned and net backend. Maybe it does not depend on smfp, but I can't check with another scanner and log has entries relative to mfp: Output to console: insmod: can't read '/lib/modules/2.6.19-gentoo-r4/kernel/drivers/mfpportctrl/mfpport.ko': No such file or directory [sanei_wire] sanei_w_array: DECODE: maximum amount of allocated memory exceeded (limit: 1048576, new allocation: 3180390528, total: 3181439104 bytes) Segmentation fault and output to system log: Jan 23 23:34:07 [xinetd] START: sane-port pid=31519 from=127.0.0.1 Jan 23 23:34:07 [rmmod] ERROR: Module mfpportprobe does not exist in /proc/modules_ Jan 23 23:34:07 [rmmod] ERROR: Module mfpport does not exist in /proc/modules_ Jan 23 23:34:07 [rmmod] ERROR: Removing 'lp': Operation not permitted_ Jan 23 23:34:07 [rmmod] ERROR: Module parport_pc is in use_ Jan 23 23:34:07 [rmmod] ERROR: Module ppdev does not exist in /proc/modules_ Jan 23 23:34:07 [rmmod] ERROR: Module parport is in use by lp,parport_pc_ Jan 23 23:34:07 [rmmod] ERROR: Removing 'lp': Operation not permitted_ Jan 23 23:34:07 [rmmod] ERROR: Module parport_pc is in use_ Jan 23 23:34:07 [rmmod] ERROR: Module ppdev does not exist in /proc/modules_ Jan 23 23:34:07 [rmmod] ERROR: Module parport is in use by lp,parport_pc_ Jan 23 23:34:07 [xinetd] EXIT: sane-port status=0 pid=31519 duration=0(sec) Possibly this should be fixed with another binary patch, but it would took too much time for me :( The best decision would be bugreport to samsung, but I havge almost no hope that they pay attention to it :(
As a quick note, the latest ebuild attached (with supplementary files) worked perfectly for me with my SCX-4200. Also the ebuild works fine too with the version incremented (to 2.00.95) and adjusted the download locations appropriately.(note the URLs in the currently attached version are now broken as Samsung appears to have removed the older version of the driver) Thanks for a good ebuild
I had to copy cdroot/Linux/x86_64/at_root/usr/lib64/cups/filter/rastertosamsungspl to /usr/libexec/cups/filter/ in order to make printing work with my SCX-4521F. Maybe the ebuild should do this? Scanning doesn't work so far, I'll dig into that later. Also v2.00.97 of the samsung driver has been released. Thanks for the ebuild!
Another thought: The foo2zjs ebuild has a variable called FOO2ZJS_DEVICES. What about doing the same thing for samsung-mfp-bin? I guess there would be an awful lot of possible values for this variable considering all the .ppd files in /usr/share/cups/model/samsung. Well, it's just a thought.
Sorry for all the posts but I found out what the problem was with rastertosamsungspl before. The problem is that the paths are different between x86 and amd64, this is how it looks in the cdroot directory: cdroot/Linux/i386/at_root/usr/lib/ cdroot/Linux/x86_64/at_root/usr/lib64 So I added a variable called LIBDIR where MFP_ARCH is set. It's no mistake that LIBDIR isn't used in this line since the paths are the same for both archs: doexe cdroot/Linux/${MFP_ARCH}/at_opt/lib/* cdroot/Linux/x86_64/at_opt/lib/ cdroot/Linux/i386/at_opt/lib/ I also had problem with the lib-compat dependency as it can't be installed on an amd64 system. AFAIU app-emulation/emul-linux-x86-compat is the same thing for amd64. This is also fixed in the updated ebuild. I also updated it to v2.00.97 Everything (even scanning) works now that all files are installed in the right place.
Created attachment 127126 [details] samsung-mfp-bin-2.00.97.ebuild (fixes for amd64, version bump)
I've done some more changes to the ebuild: * Replaced the fix-nopar USE flag with the already existing usb flag. The nopar fix is installed if this flag is enabled. I also added a warning about this. * The driver works fine without foomatic stuff as far as I know so I removed the note about that. None of the raster* files were linked against it. * Removed the line with Installer.htm. This file is not needed when there's an ebuild. * There's no gtk+ stuff here so i removed the X and gtk use flags in favor of kde and qt3. The binaries are installed if any of these flags are enabled. * The help files are only for qt3 help gui so they're not installed unless kde or qt3 are enabled. * Cleaned up old comments. Changed/added/removed some messages. I saw that the driver package also contains drivers for single function printers and thought that the name samsung-mfp-bin might be a bit misleading. The name should maybe reflect that it's both imaging and printer drives. What do you think?
Created attachment 127194 [details] updated samsung-mfp-bin-2.00.97.ebuild
Got this error with xsane :- Error during read: Error during device I/O. scanimage -L FATAL: Module lp not found. insmod: can't read '/lib/modules/2.6.23-gentoo-r1/kernel/drivers/mfpportctrl/mfpport.ko': No such file or directory Segmentation fault sane-find-scanner # sane-find-scanner will now attempt to detect your scanner. If the # result is different from what you expected, first make sure your # scanner is powered up and properly connected to your computer. # No SCSI scanners found. If you expected something different, make sure that # you have loaded a kernel SCSI driver for your SCSI adapter. found USB scanner (vendor=0x04e8, product=0x341b) at libusb:001:006 # Your USB scanner was (probably) detected. It may or may not be supported by # SANE. Try scanimage -L and read the backend's manpage. # Not checking for parallel port scanners. # Most Scanners connected to the parallel port or other proprietary ports # can't be detected by this program. # You may want to run this program as root to find all devices. Once you # found the scanner devices, be sure to adjust access permissions as # necessary.
try removing the ehci module, then it should work, as described in: http://ubuntuforums.org/showpost.php?p=2187134&postcount=14 , http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1488.html goodluck ! thanks to everybody involved getting this to work with gentoo & portage :)
(In reply to comment #15) > Created an attachment (id=127194) [edit] > updated samsung-mfp-bin-2.00.97.ebuild > It seems this is not for 2.00.97. SRC_URI for driver version unknown, and patch for 2.00.92. Change URI to http://org.downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?VPath=DR/200707/20070720165133984_UnifiedLinuxDriver.tar.gz and patch to http://jacobo.tarrio.org/files/soft/scx/fix-nopar-scx4200-2.00.95-2007061201.tar.gz
I suggest the following kde dependency in the ebuild for version 2.00.97: kde? ( kde-base/kde ) might be modified to include us who use the kde-meta bits and pieces instead of the kde all-in-one monoliths. Would it then be something along the lines: kde? ( || ( kde-base/kde kde-base/kde-meta ) ) Anyway, these binaries from Samsung act like divas -- one day they work perfectly, next weeks and months not at all, no matter how much re-emerging, checking configurations etc is given. (SCX-4100 user with another brand providing back-up when printing is desperately needed and Samsung is "down". Maybe the newer models work better?)
The site hosting the binary patches http://jacobo.tarrio.org/ is down since a few days. Could anybody provide the fix-nopar-* files? I don't know if the files are allowed to be attached here, but I currently have no better idea. Of course a private mail is appreciated too. But that does not help other people.
So, since nobody seems to be interested in helping me :-(, I helped myself :-). I have attached a tiny C program which solves the problem with root permissions for scanning. It bumps the I/O privilege level and then calls the program given in the command line. Compile: gcc -Wall -O2 -o iopl iopl.c Install: su cp iopl /usr/local/sbin chown root:root /usr/local/sbin/iopl chmod 4711 /usr/local/sbin/iopl Running scan app (e.g. kooka): /usr/local/sbin/iopl 3 "kooka whateverarguments &" PLEASE NOTE: THIS IS AN UGLY UGLY HACK. Not as bad as the Samsung driver ;-) but anyway. DONT'T use, if you don't know what you are doing. Tears a security hole into your system. You have be warned! The advantage is, that the scanned files belong to the calling user. The scan app does not have full root permissions (but may do ins and outs to I/Os and may disable IRQs!).
Created attachment 169196 [details] C source to bump I/O privelege level for running scan app with Samsung driver Must be run suid root, see my previous comment. You may restrict access to a certain group by using "chown root:myscangroup path-to-iopl; chmod 4710 path-to-iopl".
Seems this issue can be closed with WONTFIX. For scanning now sane-xerox_mfp (http://www.sane-project.org/lists/sane-mfgs-cvs.html#Z-SAMSUNG) can be used (available since media-gfx/sane-backends-1.0.20), works for me fine (~x86, Samsung SCX-4200). The only thing (if someone can route this to gentoo sane team or upstream, please do) I have to add usb id to xerox_mfp.conf: #Samsung SCX-4200 usb 0x04e8 0x341b For printing we can use net-print/splix.
Update to my previous comment - upstream already has it in git: http://git.debian.org/?p=sane/sane-backends.git;a=blob;f=backend/xerox_mfp.conf.in;h=8ff8acdc79b3c88f42c334b0ddfe3f00df179bb6;hb=HEAD
Created attachment 227965 [details] samsung-unifieddriver-3.00.62-r1.ebuild
*** Bug 347995 has been marked as a duplicate of this bug. ***
Created attachment 268259 [details] Bumped to the new version, i changed ebuild so that new rasterisers will be installed.
Created attachment 268261 [details] samsung-unifieddriver-3.00.83.ebuild
Sorry for the first attachment, please ignore it. Anyway, i updated ebuild so that it will now install new rasterisers that samsung added to the drivers.
I think, qt4 should be added to IUSE, shouldn't it? I was not able to perform an ebuild samsung-unifieddriver-3.00.83.ebuild manifest without.
Created attachment 269987 [details] samsung-unifieddriver-3.00.83-r1.ebuild Add the qt4 use flag and the depending tools to /opt/Samsung
Created attachment 280629 [details] Ebuild for samsung-unifieddriver-3.00.63 Hello! I've tried using the last ebuild attached. It doesn't work. Maybe it's just moving files on Samsung's server or something else, however there is no support for scanner devices in archive from link from that ebuild. No directories or files that have relation with SANE at all. So, I went to Samsung's site and found latest unified driver for linux from model SCX-4600 (because I've heard it's working with my SCX-4100). Here is the link: http://www.samsung.com/hk_en/consumer/computer-peripherals/printers-multifunction/monochrome-laser-multifunction-printers-faxes/SCX-4600/XSS/index.idx?pagetype=prd_detail&tab=support Direct link to the file is in ebuild itself. It has version 3.00.63 on the site, so this explains why ebuild is versioned like that. Also the original file is named UnifiedDriver_1.01 versus UnifiedDriver_0.95 from previous ebuild. After very simple tweaking of the original file I've created the new working (for me) ebuild, though it has lower version. Here it is.
digest ebuild files bring me both errors: /usr/portage/app-misc/samsung-mfp-bin office samsung-mfp-bin # ebuild samsung-unifieddriver-3.00.63-r5.ebuild digest !!! /usr/portage/app-misc/samsung-mfp-bin/samsung-unifieddriver-3.00.63-r5.ebuild does not seem to have a valid PORTDIR structure. office samsung-mfp-bin # ebuild samsung-unifieddriver-3.00.83-r1.ebuild digest !!! /usr/portage/app-misc/samsung-mfp-bin/samsung-unifieddriver-3.00.83-r1.ebuild does not seem to have a valid PORTDIR structure. What did I make wrong?!
It is probably since you have named the ebuild and the directory it resides in differently. And you should better use a local overlay tree and not put the ebuild into the Gentoo portage tree. ==> man make.conf Please don't continue asking questions about this here. It is completely unrelated to this bug. Go to e.g. the Gentoo user forum or just ask Google. Thanks.
Added new, corrected ebuild for newest unified Samsung drivers (3.00.71)
Created attachment 287077 [details] samsung-unifieddriver-3.00.71.ebuild
Too bad this version again has no sane support. Does anybody have this driver working with kernel >= 3.0.x?
Created attachment 291215 [details] ebuild for samsung unified driver 3.00.90 Ebuild update for driver v 3.00.90, which can be found here: http://www.samsung.com/ru/consumer/computers-peripherals/printers/mono-mfps/SCX-4623FN/XEV/index.idx?pagetype=prd_detail&tab=support This version works with libpng-1.5.5 (3.00.63 doesn't). But I ran into troubles with scanning. I suppose it is due to recent kernel upgrade to 3.1. Can anybody confirm this or any other version of the driver is working with kernel newer than 3.0.x?
Created attachment 291559 [details] Updated version of ebuild Forgot to copy netdiscovery tool in previous version. It is probably not necessary if only local printing is used, however it will warn you constantly in syslog about missing netdiscovery anyway. That's the reason to include it. Maybe it is better to create USE-flag for this?
(In reply to comment #37) > Too bad this version again has no sane support. > Does anybody have this driver working with kernel >= 3.0.x? Still unable to make the scanner work with smth >= 3.0.x. Tried to mimic the 2.6 kernel using Makefile like this: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 40 EXTRAVERSION = .8 Rebuilt kernel and modules, sane-backends and re-emerged samsung-unifieddriver - still no luck. Is anybody using SCX-4100 with recent kernels?
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/
Hmm, for a Samsung SCX-4200 I am currently using net-print/splix for printing and the Sane xerox_mfp driver (part of media-gfx/sane-backends with USE="xerox_mfp") for scanning. Both are working Ok for me and are open source afaik. I just (6 weeks ago or so) installed a new box having the Samsung attached and I did not encounter anything weird up to now. So, I would like to put up the question, how much this proprietary driver still makes sense. Flames go to /dev/null. Serious posts only please. Thanks, Ole
(In reply to comment #42) > Hmm, for a Samsung SCX-4200 I am currently using net-print/splix for > printing and the Sane xerox_mfp driver (part of media-gfx/sane-backends with > USE="xerox_mfp") for scanning. Both are working Ok for me and are open > source afaik. > > I just (6 weeks ago or so) installed a new box having the Samsung attached > and I did not encounter anything weird up to now. > > So, I would like to put up the question, how much this proprietary driver > still makes sense. Flames go to /dev/null. Serious posts only please. > > Thanks, Ole SCX-4100 I have is not supported at all by sane. Printing works fine with splix though. Currently, I am monitoring from time to time Samsung's site by hand checking for newer versions. (Does anybody know RSS or something to monitor it automatically?) However, latest available here 3.00.90 version doesn't work with >=3.x kernels as I've already mentioned above so it is not pretty much of use. Recently, 4.00.35 version popped out and I will test it and update the ebuild in a day or two, as soon as I'll return home from my trip. I will continue updating ebuilds as long as I am owning this SCX-4100 mfp.
Created attachment 320096 [details] samsung-unified-driver-4.00.35.ebuild Added ebuild for the latest driver version available: 4.00.35. There are several changes: * cups USE-flag introduced to enable printing support. Now it is possible to use this driver only for scanning and do printing via splix. Using this driver with enabled cups USE flag and splix at the same time is impossible. * network USE-flad introduced which installs netdiscovery tool. It is network printers discovery utility. * scanning requires USB_PRINTER option enabled in kernel config. I was unable to make scanner to be even detected without usblp module though I have libusb installed and, for example, cups works fine via libusb. With usblp module scanning works fine. If you've managed to make scanner work via libusb post the guide here please. * shipped Qt4 libs are no longer installed as GUI tools work good with the system-wide ones. If you will have any issues with it notify me. * minor changes like proper system-wide libtiff.so and libnetsnmp.so handling. Also renamed it to samsung-unified-driver because I've never understood why it had only `samsung` separated by hyphen.
Created attachment 327348 [details] samsung-unified-driver-4.00.36.ebuild Added ebuild for newer version of the driver: 4.00.36 Minor changes only: * Update ebuild to reflect changed file placement. * There are some known issues with 4.00.35 version, see: http://www.bchemnet.com/suldr/forum/index.php?topic=5.0 This version could fix this. * There is selinux policy file included in tarball from Samsung's site now. It is not installed, just know it is there and go grab it if you need it. Also driver version 4.00.39 is available, but without scanning support, i.e. no sane libs at all. I will update it as soons as they'll release proper tarball.
Any plan to have an ebuild for the new version here: http://downloadcenter.samsung.com/content/DR/201308/20130801155024703/ULD_Linux_V1.00.06.tar.gz ? Best.
(In reply to Jérôme Revillard from comment #46) > Any plan to have an ebuild for the new version here: > http://downloadcenter.samsung.com/content/DR/201308/20130801155024703/ > ULD_Linux_V1.00.06.tar.gz ? Hmm, I gave this tarball a quick look and it has significant changes from the previous driver releases. Most notable changes are arm support and no Qt4 gui. Since Samsung names their tarballs in a very strange manner could you please give me a link to the page on Samsung's site where I can grab this tarball and have an idea how this release should be versioned properly? Although, 4.01.xx series is available for some time now, I just haven't updated ebuild here. Will do soon probably, but still tarballs for 4.01.xx are also very different from the one you've suggested.
Yes, they changed apparently everything... here is a link from where you can get this driver: http://www.samsung.com/us/support/owners/product/CLX-4195N (Printing & Scan Driver (Driver) (ver.V1.00.06)) Best.
(In reply to Jérôme Revillard from comment #48) > Yes, they changed apparently everything... here is a link from where you can > get this driver: http://www.samsung.com/us/support/owners/product/CLX-4195N > (Printing & Scan Driver (Driver) (ver.V1.00.06)) Thanks for the link. This tarball is still questionable to me. Both Samsung's site and tarball internal files state that the version is 1.00.06. Supplied ppds are slightly different between this tarball and v4.01.xx one: 1.00.06 has about a dozen more files, but still missing some of the ppds from 4.01.xx (discontinued?). In general, ppds from 4.01.xx are a bit heavier. Also 4.01.xx relies on libmfp.so while 1.00.06 has no such lib. And tarballs for 4.01 series of drivers are named as blabla_1.02, which could mean that they are successors of 1.00.06. Still pre-install.sh from 1.00.06 has detection of legacy driver versions by checking for guiunistall binary, which is shipped with 4.00/.01 and missiong from 1.00.06. I guess Samsung decided to reset their numbering back to 1.xx. Unfourtunately, 1.00.06 tarball has no proper release date indication in its files.
I've checked Samsung's site pages where there were links to 4.01.xx drivers and found that they all are replaced with 1.00.06. Looks like it is really a new release. bchemnet, a friendly packager of Samsung's drivers for debian-based distros, has also announced this version as new here [0]. Alright, I'll look into this tarball and prepare ebuild. 4.01.xx series will be ignored then, we'll just move from 4.00.36 to 1.00.06. [0]: http://www.bchemnet.com/suldr/forum/index.php?topic=158.0
Great, thanks a lot. I will be happy to test ;-) Best, Jerome
Ok, I've prepared ebuild for 1.00.06 and slightly cleaned up ebuild for 4.00.36. Both of them work fine for me. I'll post them here in a few minutes with a small release notes, in the meantime you can grab them from my overlay here: git://bonespirit.org/bonespirit.git
Created attachment 356630 [details] samsung-unified-driver-4.00.36-r1.ebuild This is the last ebuild for samsung-unified-driver-4.xx series. This is also the last version with Qt4 gui. Download link is still working, but I can't say for how long they will keep tarballs on their servers. If you have any problems with 1.00.06 try stick to this one. Changes from previous revision: * Updated dependencies, now there are more of them. * Bump EAPI to 5. Switch SLOT to "legacy" * Minor ebuild cleanups, like less cp-r's.
Created attachment 356636 [details] samsung-unified-driver-1.00.06.ebuild Added ebuild for the latest version of the driver: 1.00.06. Changes from previous version (4.00.36): * Entirely dropped Qt4 gui. * Added arm support. arm binaries are statically linked, so on this architecture you will have to install very few deps, namely cups and/or sane-backends only. I have no such hardware so I don't know whether they work at all. * .cts files are now properly installed. * Scanning is handled via libusb, as opposed to libusb-only method in 4.xx. Related warning in ebuild was updated to reflect this change. * no more libstdc++-3 * libscmssc.so is not installed by default as it was before (into incorrect location though). ldd shows no binary that need it. If you have errors related to this library please post a comment here. * ebuild is significantly simplified, bump EAPI to 5.
(In reply to Coacher from comment #54) > * Scanning is handled via libusb, as opposed to libusb-only method in 4.xx. > Related warning in ebuild was updated to reflect this change. Should be * Scanning is handled via libusb, as opposed to usblp method in 4.xx. Related warning in ebuild was updated to reflect this change.
Hi, Thanks you very much for this really good and quick work ! Tested with CLX-4195 and it works like a charm (Printer + scanner over network) Best, Jerome
Created attachment 361230 [details] samsung-unified-driver-1.00.06.ebuild Remove unneeded deps like gmp, nettle, etc. It turns out that ldd works recursively on binaries and the proper way for discovering minimum set of needed libs is via readelf. Thanks to René 'Necoro' Neumann for pointing out my mistake and suggesting readelf tool.
Created attachment 361232 [details] samsung-unified-driver-4.00.36-r1.ebuild Also remove a number of unneeded deps (see my previous comment), other minor changes.
With your ebuilds I had to manually copy files from /usr/libexec/cups/filters to /usr/libexec/cups/filter to make things work so maybe there's an error in ebuild at "exeinto /usr/libexec/cups/filters". I had a lot of "Samsung: File "/usr/libexec/cups/filter/rastertosamsungspl" not available: No such file or directory" messages.
(In reply to Dusanc from comment #59) > With your ebuilds I had to manually copy files from > /usr/libexec/cups/filters to /usr/libexec/cups/filter to make things work so > maybe there's an error in ebuild at "exeinto /usr/libexec/cups/filters". > > I had a lot of "Samsung: File "/usr/libexec/cups/filter/rastertosamsungspl" > not available: No such file or directory" messages. Yes, this is indeed a typo. I am planning to release a new ebuild for 1.00.21 driver and will fix it there.
Created attachment 374758 [details] samsung-unified-driver-1.00.21.ebuild Added ebuild for the latest version of the driver: 1.00.21. Changes from the previous version (1.00.06): * Proper path for cups filters. Thanks to Dusanc for pointing this out. * Minor ebuild changes.
Created attachment 374760 [details] samsung-unified-driver-4.00.36-r2.ebuild Updated ebuild for the legacy version of the driver: 4.00.36-r2. Changes from the previous revision: * Proper path for cups filters. Thanks to Dusanc for pointing this out. * Minor ebuild changes.
(In reply to Coacher from comment #61) > Created attachment 374758 [details] > samsung-unified-driver-1.00.21.ebuild > > Added ebuild for the latest version of the driver: 1.00.21. > > Changes from the previous version (1.00.06): > * Proper path for cups filters. Thanks to Dusanc for pointing this out. > > * Minor ebuild changes. I've tested the ebuild (1.00.21), and I wasn't able to print without installing libscmssc.so. The debug info in cups error log wasn't too much informative, but the comment helped and now my printer works. I'm not sure about the print quality, though: black font appear to be sepia color, and some jpeg artefact can be seen around the edges. Tweaking with printer options produces no appreciable results. My printer is a CLX-3175.
(In reply to Michelangelo Scopelliti from comment #63) > I've tested the ebuild (1.00.21), and I wasn't able to print without > installing libscmssc.so. > The debug info in cups error log wasn't too much informative, but the > comment helped and now my printer works. I'm not sure about the print > quality, though: black font appear to be sepia color, and some jpeg artefact > can be seen around the edges. Tweaking with printer options produces no > appreciable results. > > My printer is a CLX-3175. Thank you for your report. A couple of additional questions to try and understand this better. Does cups error log has no mentions of libscmssc at all? Was your printer working with 1.00.06? Please try with 1.00.06 version with and without libscmssc installation. Ebuild for it can be found here (under obsolete attachments) or grabbed from git://bonespirit.org/bonespirit.git overlay. Speaking about printing quality I am afraid there is not much I can help you with apart from adjusting toner settings in cups interface/directly via buttons on printer. Also maybe emerging colord with extra-print-profiles may help. Unfortunately, I have never tried colord for myself. Though I'll give it a try in a couple of days and provide you with more detailed intructions if possible.
(In reply to Coacher from comment #64) > (In reply to Michelangelo Scopelliti from comment #63) > > I've tested the ebuild (1.00.21), and I wasn't able to print without > > installing libscmssc.so. > > The debug info in cups error log wasn't too much informative, but the > > comment helped and now my printer works. I'm not sure about the print > > quality, though: black font appear to be sepia color, and some jpeg artefact > > can be seen around the edges. Tweaking with printer options produces no > > appreciable results. > > > > My printer is a CLX-3175. > > Thank you for your report. > > A couple of additional questions to try and understand this better. Does > cups error log has no mentions of libscmssc at all? Was your printer working > with 1.00.06? Please try with 1.00.06 version with and without libscmssc > installation. Ebuild for it can be found here (under obsolete attachments) > or grabbed from git://bonespirit.org/bonespirit.git overlay. I've added ebuilds in overlay for 1.00.06 and 1.00.21 with libscmssc USE, which allows you to install libscmssc.so via specifying the said USE flag. This should ease libscmssc experiments for you and everyone.
(In reply to Michelangelo Scopelliti from comment #63) > I've tested the ebuild (1.00.21), and I wasn't able to print without > installing libscmssc.so. > The debug info in cups error log wasn't too much informative, but the > comment helped and now my printer works. I'm not sure about the print > quality, though: black font appear to be sepia color, and some jpeg artefact > can be seen around the edges. Tweaking with printer options produces no > appreciable results. > > My printer is a CLX-3175. I've also adjusted CMS files' installation paths in overlay, please try latest versions from there. It might fix your color problem right away. The problem is Samsung ppd files do not reference proper CMS file directly, so I hope cups will pick up appropriate CMS file automatically based on ppd name.
(In reply to Coacher from comment #64) [CUT] > A couple of additional questions to try and understand this better. Does > cups error log has no mentions of libscmssc at all? Was your printer working even enabling debug logging (cupsctl --debug-logging) there is no reference to libscmssc. > with 1.00.06? Please try with 1.00.06 version with and without libscmssc > installation. Ebuild for it can be found here (under obsolete attachments) > or grabbed from git://bonespirit.org/bonespirit.git overlay. * 1.00.06, no libscmssc: filter failed, no additional info * 1.00.06, libscmssc: working * 1.00.21, no libscmssc: filter failed, no additional info * 1.00.21, libscmssc: working what about a USE=+libscmssc? > > Speaking about printing quality I am afraid there is not much I can help you > with apart from adjusting toner settings in cups interface/directly via > buttons on printer. Also maybe emerging colord with extra-print-profiles may > help. Unfortunately, I have never tried colord for myself. Though I'll give > it a try in a couple of days and provide you with more detailed intructions > if possible. well, I've never tried it either, and after some time spent tryng to get rid of systemd/consolekit/policykit, a daemon which requires all of this... I don't know, I'll try, but maybe later. Thank you
(In reply to Michelangelo Scopelliti from comment #67) > * 1.00.06, no libscmssc: filter failed, no additional info > * 1.00.06, libscmssc: working > * 1.00.21, no libscmssc: filter failed, no additional info > * 1.00.21, libscmssc: working Thank for your info. Can you please tell me what revisions of the said packages you've been installing? > what about a USE=+libscmssc? I think I am going to remove this USE altogether and install libscmssc unconditionally. This library seems to be used for handling ppd files with shipped cts profiles for color adjustment(?) and it is logically to have it installed always when ppds are installed to avoid needless breakage such as in your case. ppds have an option to specify CMS file to use, but Samsung does not use CMS option to specify color profile though. Looks like it uses Emulator option to handle profiles. However, Emulator option appears in greyscale ppds as well. And cts profiles for greyscale devices are also present (not for mine though). Weird. Anyway, this will probably happen during the next driver release. > well, I've never tried it either, and after some time spent tryng to get rid > of systemd/consolekit/policykit, a daemon which requires all of this... I > don't know, I'll try, but maybe later. colord depends on systemd only when systemd USE is enabled for it, though it depends on polkit unconditionally. As far as I understood from googling, CUPS nowadays "just works" together with colord if the latter one is present. However, I was unable to switch CMS profile (through KDE's colord interface) used for printing to something different than default ("Default gray"). Guess it might be possible through some minor tuning of ppd file. > Thank you You are welcome.
(In reply to Coacher from comment #68) > (In reply to Michelangelo Scopelliti from comment #67) > > * 1.00.06, no libscmssc: filter failed, no additional info > > * 1.00.06, libscmssc: working > > * 1.00.21, no libscmssc: filter failed, no additional info > > * 1.00.21, libscmssc: working > > Thank for your info. > Can you please tell me what revisions of the said packages you've been > installing? As you suggested, I used the ebuilds from your overlay. So, 1.00.06-r2 and 1.00.21-r1 [CUT] > > well, I've never tried it either, and after some time spent tryng to get rid > > of systemd/consolekit/policykit, a daemon which requires all of this... I > > don't know, I'll try, but maybe later. > > colord depends on systemd only when systemd USE is enabled for it, though it > depends on polkit unconditionally. As far as I understood from googling, > CUPS nowadays "just works" together with colord if the latter one is > present. However, I was unable to switch CMS profile (through KDE's colord > interface) used for printing to something different than default ("Default > gray"). Guess it might be possible through some minor tuning of ppd file. OK, my bad, I wasn't clear. It is my opinion that systemd, consolekit and policikit belong to the same madness, and I consider them a whole block. In the specific case, there is no real dependence: colord works fine without polkit, so with a new ebuild I made some tests. Print quality is better, but blacks (and greys) are still sepia(ish). I think I'll stick with foo2qpdl for a while, until next release at least. Let me know if you need some other test.
(In reply to Michelangelo Scopelliti from comment #69) > As you suggested, I used the ebuilds from your overlay. So, 1.00.06-r2 and > 1.00.21-r1 > ... > Print quality is better, but blacks (and greys) are still sepia(ish). That's great. It is a bit unclear whether print quality improvement is due to colord running or simply using latest revision? > Let me know if you need some other test. OK. Thanks for your help.
(In reply to Coacher from comment #70) > (In reply to Michelangelo Scopelliti from comment #69) > > As you suggested, I used the ebuilds from your overlay. So, 1.00.06-r2 and > > 1.00.21-r1 > > ... > > Print quality is better, but blacks (and greys) are still sepia(ish). > > That's great. It is a bit unclear whether print quality improvement is due > to colord running or simply using latest revision? As far as I can tell, there is no quality difference in 1.00.06 and 1.00.21 - looking at the printed sheet. The difference cames out when colord kicks in: the jpeg artifacts are still these, but the dithering seems to be more efficient, and the effect is less evident. Still, in the black color management, and in the greyscale, yellow and magenta are visible around the borders, creating the sepia effect. But, I assume, this is a color management issue, not a driver one. > > > Let me know if you need some other test. > > OK. Thanks for your help.
Created attachment 379388 [details] samsung-unified-driver-1.00.21-r3.ebuild Here is an updated ebuild (compared to samsung-unified-driver-1.00.21-r2 from bonespirit overlay). It fixes numerous QA issue and uses some EAPI/eclass features to simplify code.
(In reply to Andrew Savchenko from comment #72) > Created attachment 379388 [details] > samsung-unified-driver-1.00.21-r3.ebuild > > Here is an updated ebuild (compared to samsung-unified-driver-1.00.21-r2 > from bonespirit overlay). It fixes numerous QA issue and uses some > EAPI/eclass features to simplify code. Hello. Just had a quick overview of your ebuild. Thanks for your work on it. Most of these changes are OK with me and I'll merge them to my repo's ebuilds soon so other people can easily get them. Though a couple of things caught my attention: * you've dropped ~arm keyword (probably by accident) * license rename What's the point?
Hi, (In reply to Coacher from comment #73) > Just had a quick overview of your ebuild. Thanks for your work on it. Most > of these changes are OK with me and I'll merge them to my repo's ebuilds > soon so other people can easily get them. Though a couple of things caught > my attention: > > * you've dropped ~arm keyword (probably by accident) I just can't test it on arm, so I removed keyword. Please add it back if you can test this package on arm. > * license rename > > What's the point? It's not just rename. 1. I used noarch/license/eula.txt from source tarball instead of license file from your overlay. Text is the same, but the former is plain text, while the latter is HTML. 2. This license is EULA and is quite restrictive (e.g. single user only). I added it to EULA license group, so that users must explicitly accept it prior to package installation. Rename was done to comply with common tendency to name EULA licenses as foo-eula (see /usr/portage/licenses).
(In reply to Andrew Savchenko from comment #74) > > * you've dropped ~arm keyword (probably by accident) > > I just can't test it on arm, so I removed keyword. Please add it back if you > can test this package on arm. Neither can I. As I'd mentioned previously I enabled arm support as it was added to the driver by Samsung and hoped that somebody on arm will test it eventually. > > * license rename > > > > What's the point? > > It's not just rename. > 1. I used noarch/license/eula.txt from source tarball instead of license > file from your overlay. Text is the same, but the former is plain text, > while the latter is HTML. Yeah, I've recently reviewed that file as well and left HTML version from 4.xx driver as it is more readable (to me). The text is the same so it seems there is no real issue with this. Also it causes a bit more trouble to keep separate licenses for 4.xx and 1.xx ebuilds (and they are still both availble in my repo and I'm lazy). I am planning to wipe 4.xx from repo completely after next ULD verbump. Probably then I'll switch to plain text version shipped with 1.xx. > 2. This license is EULA and is quite restrictive (e.g. single user only). I > added it to EULA license group, so that users must explicitly accept it > prior to package installation. Rename was done to comply with common > tendency to name EULA licenses as foo-eula (see /usr/portage/licenses). Adding license to license group is a nice touch. BTW, if you'll look into /usr/portage/profiles/license_groups EULA suffix is really not that common. I think it is more a matter of personal preference.
(In reply to Andrew Savchenko from comment #74) In any case thank you again for your feedback on these ebuilds and for submitting fixes.
Hello, (In reply to Coacher from comment #75) > (In reply to Andrew Savchenko from comment #74) > > > * you've dropped ~arm keyword (probably by accident) > > > > I just can't test it on arm, so I removed keyword. Please add it back if you > > can test this package on arm. > > Neither can I. As I'd mentioned previously I enabled arm support as it was > added to the driver by Samsung and hoped that somebody on arm will test it > eventually. If this package is to be ever included in the portage tree (and it is my best hope that it will be, so all users will be able to benefit from a proper hardware support), it should follow some common rules. As Gentoo devmanual states (see http://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html): "Please do not add other ARCHs into KEYWORDS unless the ebuild has been tested on that ARCH." > > > * license rename > > > > > > What's the point? > > > > It's not just rename. > > 1. I used noarch/license/eula.txt from source tarball instead of license > > file from your overlay. Text is the same, but the former is plain text, > > while the latter is HTML. > > Yeah, I've recently reviewed that file as well and left HTML version from > 4.xx driver as it is more readable (to me). The text is the same so it seems > there is no real issue with this. Yet again, there is a policy for this: http://devmanual.gentoo.org/general-concepts/licenses/index.html "When adding the license, use a plain text file (UTF-8 encoded) if at all possible." > > 2. This license is EULA and is quite restrictive (e.g. single user only). I > > added it to EULA license group, so that users must explicitly accept it > > prior to package installation. Rename was done to comply with common > > tendency to name EULA licenses as foo-eula (see /usr/portage/licenses). > > Adding license to license group is a nice touch. BTW, if you'll look into > /usr/portage/profiles/license_groups EULA suffix is really not that common. > I think it is more a matter of personal preference. Yes, you're right. Filename is a matter of choise. I don't mind here.
(In reply to Andrew Savchenko from comment #77) I am well aware of these policies, but I am not really interested in pushing this package to portage tree. At least with me as a maintainer. Sorry. I keep maintaining ebuilds for newer versions because I have no other way to make scanning on my MFD work. I am willing to share my efforts with others, but I am not ready to provide full maintainer-level support. Also getting cvs write access (proxy-maint can be super slow) is not simple and sometimes I just want to do another revbump (adding your changes is a good example), while in my overlay I can easily fix problems as soon as I am getting aware of them.
(In reply to Andrew Savchenko from comment #72) > Here is an updated ebuild (compared to samsung-unified-driver-1.00.21-r2 > from bonespirit overlay). It fixes numerous QA issue and uses some > EAPI/eclass features to simplify code. BTW, where did you get that QA_FLAGS_IGNORED warnings as I get none upon install? What version of portage are you running?
(In reply to Coacher from comment #79) > BTW, where did you get that QA_FLAGS_IGNORED warnings as I get none upon > install? > What version of portage are you running? Version of portage is of no meaning in this matter. (It is 2.2.10 if you're interested.) To get *FLAGS_IGNORED QA message you need to: 1) Add -frecord-gcc-switches to your *FLAGS. 2) Use developer profile. Obviously, for binary package user *FLAGS will be always ignored.
Hello. It's been a while since my last comment here. In the meantime several new versions of Samsung drivers were released. As usual they are ready to be tried out at my overlay, which is now also available at GitHub: https://github.com/Coacher/bonespirit Short changelog: scanner drivers now want oem.conf to be placed in a certain dir under /opt, otherwise scanner is not detected (path is hardcoded in libsane-smfp binary), arm support was dropped again by Samsung guys in version 1.00.35.
1.00.36 and 1.00.37 are out sometime in October and December 2015 respectively with new models added. As usual you can grab these in my overlay: https://github.com/Coacher/bonespirit
