Bug#803789: RFP: RasterView -- a simple GUI image viewer for CUPS and PWG Raster files
Package: wnpp Severity: RFP RasterView is a simple GUI image viewer which specializes in displaying CUPS raster and PWG Raster files. The CUPS and PWG Raster formats are used by CUPS in some printing workflows. Both can handle multi-page image files, and can embed job specific settings in page headers (such as page size or duplex settings). PWG Raster was specified by the Printer Working Group working on the upcoming "IPP Everywhere" standard which aims at ubiquituos "driverless printing" for all major OS platforms. It is one of the three core formats (besides JPEG and PDF) to be supported by print devices for compliance with the IPP Everywhere standard. A viewer for the generated raster files in such a printing workflow is important not just for debugging print problems... RasterView has a dependency on FLTK. It was written by Mike Sweet (CUPS developer). Its license is GPL v2. Its latest release is v1.4.1 (Aug 27, 2015). I was able to compile it on Debian Jessie "out of the box". License: GPL v2 Source Tarball: https://www.msweet.org/files/project7/rasterview-1.4.1.tar.gz URL: https://www.msweet.org/projects.php?Z7
Bug#379378: poster commandline utility and KDEPrint/kprinter's GUI frontend
2 days ago I blogged about kprinters GUI support for poster: http://www.kdedevelopers.org/node/3051 My openSUSE-10.2 system has the 2002 version installed, and for me it always worked fine, with no problem whatsoever. I even never thought that there were newer versions around So at the time I wrote the blog, I was unaware of any post-2002 additio- nal patches to poster. I only recalled the original ones Michael Goffioul did in 2002 (and which were accepted by the upstream poster author as well). In 2005 and 2006 more modifications were made, and it looks like these led to some (rather unspecified) problems. But I've not seen *any* step by step description how to reproduce the problem, nor an example PostScript file that can trigger it. In any case, for Debian to ship a 1999 version seems a bit odd (given the fact that the upstream author already agreed to ship the 2002 one). If Debian could decide to at least go for the 2002 version again, they'd do a big favor to all KDE users because they could use kprinter with poster again. As it stands now, all Debian KDE users who happen to install poster will get a very ugly error message once they open the Poster tab in kprinter. Peter, I wonder if you can recall any details that led you to the statement it was very buggy when you said I had updated the poster package to use the KDE version for some time, but it was very buggy Maybe you have some archive or access to more detailed user complaints that led you to that conclusion? I hope I can help find someone who works on this code again for a little while to remove the bugs anyone found, so a definite re-release of poster could be made some time in future, which will make all distros and all users happy. But more specific bug reports would definitely help tremendously in that. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425944: cupsdCallPamAuthHelper is a Debian bug!
Roger Leigh wrote: Kurt Pfeifle [EMAIL PROTECTED] writes: @Debian's CUPS-Patchers: What about properly closing the pipes again your (seetuid root!) helper utility opened? I'm still failing to see where the printing and CUPS-related wisdom of the Debian packagers is superior to the one living in the brains of the CUPS upstream developers. While I can't comment upon the quality of the patch in question, PAM is used for systemwide authentication and authorisation for all services on Debian systems, and this must include CUPS. I don't question the use of PAM. This is all about 'cupsdCallPamAuthHelper'. Which is not part of CUPS proper, but an invention of Debian packaging in order to make up for lost features and usability. These were lost by making CUPS on Debian run as non-root (essentially forking CUPS for no good reason). BTW, CUPS proper *does* work with PAM already... -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425944: cupsdCallPamAuthHelper is a Debian bug!
This certainly is not a CUPS upstream bug. CUPS proper does not have a function called cupsdCallPamAuthHelper. This is a bug introduced by the Debian/Ubuntu way of patching CUPS, and with that sh**load of patches effectively forking CUPS, for no good reason. @Debian's CUPS-Patchers: What about properly closing the pipes again your (seetuid root!) helper utility opened? I'm still failing to see where the printing and CUPS-related wisdom of the Debian packagers is superior to the one living in the brains of the CUPS upstream developers. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430919: Broken package python-pysnmp-common
Package: python-pysnmp-common Version: 4.1.7a-1 (DISCLAIMER: I'm not sure if this is the Debian-required/compliant procedure/way to submit a bug against Sid/unstable package problems. If not, I'm sure you guys will flame me, and make me somehow/someway find out what canonical procedure I should have used instead...) Summary: Package python-pysnmp-common does not install; it reports: Trying to overwrite pysnmp/__init__.py which is already provided by /usr/share/python-support/pysnmp-common Details: [EMAIL PROTECTED]:~# apt-get install python-pysnmp-common Reading package lists... Done Building dependency tree... Done Recommended packages: python-pysnmp4 (4.1.7a-1) The following NEW packages will be installed: python-pysnmp-common (4.1.7a-1) 0 upgraded, 1 newly installed, 0 to remove and 376 not upgraded. Need to get 0B/11.8kB of archives. After unpacking 41.0kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! python-pysnmp-common Authentication warning overridden. Selecting previously deselected package python-pysnmp-common. (Reading database ... 296723 files and directories currently installed.) Unpacking python-pysnmp-common (from .../python-pysnmp-common_4.1.7a-1_all.deb) ... Setting up python-pysnmp-common (4.1.7a-1) ... Traceback (most recent call last): File /usr/sbin/update-python-modules, line 294, in ? process(basedir,install_modules(py_installed)) File /usr/sbin/update-python-modules, line 162, in process func(basedir, dir, file) File /usr/sbin/update-python-modules, line 129, in install_modules_func raise Trying to overwrite %s which is already provided by %s%(os.path.join(dir,file),otherdir) Trying to overwrite pysnmp/__init__.py which is already provided by /usr/share/python-support/pysnmp-common dpkg: error processing python-pysnmp-common (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: python-pysnmp-common E: Sub-process /usr/bin/dpkg returned an error code (1) -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429715: Using Debian to print to a remote Debian CUPS server is dang hard
Btw, the current default is not entirely useless: When setting up a Samba server in combination with CUPS, Samba will import any printer offered by the local CUPS and make them available. Of course, they won't show on the IPP port unless you enable browsing as above, but they will still be available via Samba by default. How to configure Samba has *nothing* to do with *this* bug report. AFAIK, Samba usually serves printing to Windows clients which are no CUPS clients. And, BTW, Samba will import any printer offered... is only true if (a) there exists a [printers] section in smb.conf, plus (b) there is load printers = yes in smb.conf, plus (c) Samba is linked against the CUPS libraries (or CUPS is told to create a printcap) [but all 3 of these are enabled by default]. Whatever the default printing setup in a purely Debian environment is, it *IS* damn hard to discover for a user how to use and how to change it. I'm not sure, if there is a dpkg-reconfigure thingie (for a user to set it up by answering a few questions) for the cupsys, cupsys-client and cupsys-bsd packages in Debian... In any case, to make CUPS a little bit easier to use for Debian users, a dpkg-reconfigure should ask the user if he wants to use his local cupsys server for printing; and if no, which is the remote print server to use. Based on that info the client.conf should be set up. (If above question is answered yes, a check for installation of cupsys should happen, and recommend or initiate installation if not present). -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429715: Using Debian to print to a remote Debian CUPS server is dang hard
of the run, I found it curious that there were several POST / requests that all got 403 Forbidden responses, before finally a POST /printers/HPLJ1012 (hey--this program does know how to construct the URL, it just doesn't accept it!) It is not using an URL to assemble the job on the commandline. It just the -d printqueuename option. However, in the error_log you may find the URL (or the path part of it). succeeded. I don't know whether this represents a misconfiguration of the server, Most likely. or futility on the part of the client. And even after this, I never figured out how to use lpstat to get job status, etc. lpstat -o printqueuename # if you ask local cupsd lpstat -h cupsserver -o printqueuename # if you query a remote cupsd So in the end, I can at least print (though not query), but I still don't know how I was supposed to figure it out. If I missed something, maybe it could be documented more prominently. I rather think Debian should have sane, working default settings for (a) setting up CUPS as a print server (b) setting up CUPS for client systems Because, you know, if CUPS browsing were set up correctly on server and client, you would not even need to configure *anything*. And you could select your printer in the KDE print dialog (or the Gnome one) and have all print options at your finger tips *without* *even* *a* *need* *to* *install* *a* *driver* *locally*. I recommend to rename this bug report to Using Debian to print to a remote Debian CUPS server is dang hard. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423943: 127.0.0.1 localhost needs to be defined in your /etc/hosts
Your localhost/127.0.0.1 problem certainly is not an upstream issue, because
I often run pristine upstream SVN checkouts, and I test their default confi-
gurations quite often.
It is either a Debian thing (unlikely, because it would have caused lots
more report similar to yours), or it is a local mis-configuration.
Yes, 127.0.0.1 is localhost by definition. Sometimes. And only, if you run
IPv4. It is different for IPv6. And you can change that definition in your
local /etc/hosts file (for good or for bad).
Please run this command:
ping localhost
while you have the (standard) line 127.0.0.1 localhost commented *out*
from /etc/hosts. You will not get a response, and you will not get Apache
to respond on http://localhost/ and you will not get CUPS to respond on
http://localhost:631/ (if your network cable is disconnected).
However, you may still get the correct response of 127.0.0.1 if you ask:
nslookup localhost
because that is what any correctly configured name server will return.
And now Apache may respond (because its default configuration setting is
to do DNS hostname lookups), but CUPS will still not respond (because
its default configuration is HostNameLookups Off -- if you set it to
On it will also respond when an external DNS server returns 127.0.0.1
for the lookup of localhost).
Complicated? Yes. But so is TCP/IP networking in general, as soon as
you bother to go for the details.
BTW, try to ping 127.0.0.2. Do you get a response? Now ping 127.0.77.1.
And now 127.44.55.66... In case you wonder: these are all evenly legal
addresses to address the loopback interface (localhost is responding
because internally all addresses 127.0.0.2-127.255.255.254 are required
to be routed to 127.0.0.1; therefore your loopback interface will re-
spond to the pings).
Now for the RFCs out there. Yes, they define this stuff. Please refer
to RFC 3330 if you want to learn more about special and reserved IP
addresses.
So, to summarize:
Yes, you can easily confuse CUPS (as well as any other network daemon)
by incorrectly configuring some of your loopback/localhost/127.0.0.1
stuff.
And you can equally easily confuse CUPS (as well as any other network
daemon) by misconfiguring *its* *own* config files.
Please check your /etc/hosts for the localhost IP address, and also
check your
/etc/cups/cupsd.conf
/etc/cups/client.conf
~/.cupsrc
~/.client.conf
files (only the first two ones are guaranteed to exist on your system,
the others are optional) for what their content is in respect to the
(CUPS) ServerName. This will explain why in one case the web
interface may ask for a password (or may not respond at all) and in
the other case it may grant access.
Oh, and regarding the password question, where none of your passwords
works: your cupsd.conf may be using AuthType Digest (or BasicDigest).
In which cases a password may need to be set by first running the
lppasswd -a username command because *Digest authentication uses
a separate user database (in order to increase security, and allow
CUPS administration without ever needing root privileges).
CUPS by default ships with AuthType Basic (which works with the
standard system password database). But then, *buntu does not ship
with a root password, and therefor root may be blocked from accessing
the resource for lack of a password (while cupsd.conf may only allow
the root user to access the resource).
Other points where your config may be aiding and abetting some weird
things to happen:
* inconsistent use of both, 127.0.0.1 and localhost, to define
different access control schemes and AuthTypes for different
resources
* a setting of HostNameLookups {On|Off|Double} that does not work
with your overall DNS name resolution
You very likely have fallen prey to a distro setup where the packagers
have deviated from the upstream defaults without considering the
implications of *all* their changes.
Cheers,
Kurt
P.S.: I recommend to close this bug report after double-checking for
the correct 127.0.0.1/localhost settings in cupsd.conf and in
/etc/hosts on default Debian installations.
--
Kurt Pfeifle
System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS
Infotec Deutschland GmbH . Hedelfinger Strasse 58
A RICOH Company ... D-70327 Stuttgart/Germany
---
Infotec Deutschland GmbH
Hedelfingerstrasse 58
D-70327 Stuttgart
Telefon +49 711 4017-0, Fax +49 711 4017-5752
www.infotec.com
Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen
Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398
Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger
bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail
irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort
und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren
sowie die unbefugte Übermittlung komplett
Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin Pitt wrote: tag 427559 confirmed retitle 427559 cupsys: make backend permissions behaviour compatible to upstream thanks Hi Kurt, Kurt Pfeifle [2007-06-04 23:19 +0200]: * you have changed cupsd to run as user cupsys, while upstream CUPS developers have dropped this again (and they gave very good reasons for that) when they released 1.2.0. I had lots of conversations about this with upstream, and none of the reasons he gave justified running cups as root, but that's a different story. Do you have a link to these conversations (if they were held in public, not in private)? * in previous upstream versions when cupsd ran as an unprivileged user, it was possible to use RunAsUser No in cupsd.conf -- you have re- applied that old patch without keeping the user option to not follow your default. Right, because upstream does not want to reintroduce it, so I don't want to make incompatible configuration file options. You can't expect me to understand that logic without further explanations: So it looks like it is OK for you... ...to make incompatible source code patches, incompatible binary builds, incompatible startup scripts resulting in an incompatible runtime behaviour of cupsd and backends -- but you frown on... ...adding a single new (old) configuration file option that would at least re-enable runtime behaviour compatibility with upstream? * you have removed the possibility to run individual backends as root (by simply giving them 0700 permissions and root ownership). You can still do that, and it's done by default with lpd. The backends needs to be set to root:lp 4754. Thanks. I did not know this [and this change is (a) not documented, (b) not compatible with upstream's behaviour, (c) not compatible with upstream's documentation] I'll try it. However, I suspect that this will not work with some of the customer's backends since some of them are written as Shell scripts. You can't run shell scripts setuid root. Most of your problems seem to come from incompatible behavior of backend permissions. I agree that we need to do something about it. Documenting it would be one possibility, but I think it is even better to change our cups to become compatible with upstream again wrt. backend permissions. This could be done by a single suid root 'backend runner' instead of having lots of suid root backends. Do you already have a timescale for this? If so, please keep in in the loop. Feel free to mail me in private as soon as you have something that I can help testing and evaluating. BTW, upstream was never completely opposed to channges that would let the scheduler run as non-root. They just deemed the solution they used back then as not appropriate, and not adding any effective gain in security (while keeping the software fully functional). They also said that they did not yet come up with a good/better solution themselves, and that they are open to evaluate patches and code anyone feels he could contribute. So maybe your idea of a backend runner is one such contribution. About the real value of such an addition (possible gain in security) I'd rather like to see real security experts evaluate that. I'm not qualified for a verdict here. I'm only qualified for a verdict about having lost functionality, having lost compatibility, and having lost successful printouts. Thanks, Martin Cheers, Kurt -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Fon/Fax: +49-711-4017-5677/-2303 ... Mobile: +49-172-715.7017 Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.infotec.com Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung. This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to someone to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. No, you didn't read (or exactly memorize) what I wrote. I said it was his *test* print server. Please check. You said test server I'm glad that everyone who cares can read for himself if I wrote test printserver or else. and yet you report on how this latest upgrade alarmingly broke everything he is running on that. That makes it pretty clear that he depends upon that server for everyday life. Whatever. What I indeed did want to make pretty clear are these current facts: * your current way of upgrading to CUPS 1.2.11-2 from a previous CUPS 1.2.x version breaks currently working installations * if you do not change $whatever (code, documentation, buildtime configure, startup script, postinstall-script, $wildcard) by the time this upgrade happens in next stable, your users may be hit quite unprepared by some printing b0rkenness Please stop discussing your theories about how this customer may be relying on a Debian Unstable for a production print server. This theory's validity is completely irrelevant to the above two points. * it is totally legal and valid to report bugs and submit wishlist items against a Sid/unstable system irrespective of the fact whether these were acquired on a production system That you guys broke our system and it's gonna cost us a fortune to get it fixed moaning won't help their case, at any rate. OK, please forget this part of my mail. It was also irrelevant to my important points. It also proves that they actually rely upon that server for everyday use. * some people run Testing and Unstable *now* on their test and pilot systems because they have a long term plan to migrate hundreds of servers and 10s of thousands of workstations to Linux, away from a proprietary system (and by the time of the migration they hope to use a Stable or Testing version) In which case it's just a test server, not a system running a number of scripts and filters they noticably depend upon. They do not yet depend on these scripts and filters; but they will, once they migrate to Linux. And their decision to migrate will heavily depend on how well the current tests and pilots work. And current tests and pilots are being run in order to find out any problems now, and to help iron out what can be ironed out... Is that comprehensible? I didn't see you participate in any of the detailed discussions that took place on the upstream mailing lists about that particular topic; not once on many occasions over the last 2-3 years when they happened; therefore I do not deem you competent in uttering a verdict about upstream having a patently broken security model. I have been following the issue for longer than that, but whatever. It has become clear to me that you only came here to bicker and to push these maintainers into reverting every change that disagrees with how you would maintain this package. However, I have an even better proposal for you: become the CUPS maintainer in Debian, yourself, right now. I'm clearly not qualified to be a package maintainer, because I just know too little about building, packaging and Debian policies. My qualification lies elsewhere. One field is what you call bickering, yes. Start by triaging the bugs currently open against the package. In case you did not notice: I *did* already start. Last night. Even before I sent my first reply to you in this thread. And I suggested to close the bug in question (Bug #259774). Then submit patches that show what changes you would like to see in CUPS for Debian (and keep in mind our stated goal to keep differences between the Debian and Ubuntu packages minimal). I'd like to see as little changes compared to upstream pristine sources as possible. Especially, if they are undocumented for the end user. Especially if they change some fundamental behaviour of the software. Especially if they do not explain how to get back the original behaviour. Especially if they disallow to get back the original behaviour. If you do a good job at it, we'll gladly let Your Expertness take over the package's maintenance and, yes we mean it. :) I even trust you on this. Be assured, My Expertness is much more lowly educated than it may appear
Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Package: cupsys Version: 1.2.11-2 (I'm sorry to not be able to use reportbug; I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; I'm not running Sid, but I was able to ssh into his system for a few minutes and poke around a bit...) -- It looks like the 1.2.11-2 package changed a few very substantial things over the previous package (1.2.7-4?): * you have changed cupsd to run as user cupsys, while upstream CUPS developers have dropped this again (and they gave very good reasons for that) when they released 1.2.0. * in previous upstream versions when cupsd ran as an unprivileged user, it was possible to use RunAsUser No in cupsd.conf -- you have re- applied that old patch without keeping the user option to not follow your default. * you have removed the possibility to run individual backends as root (by simply giving them 0700 permissions and root ownership). This breaks all customized backends which need root permissions in order to do their job. In our case it was... (a) a custom pdf-creating backend (*NOT* the cups-pdf package) that was geared to work with SAP output, and write its results into specific directories owned by different system users (b) another custom pdf-creating backend (*NOT* the cups-pdf package) which was geared to work for MS Windows domain users via Samba and write its output to user-owned directories (c) a backend using Pykota (http://www.pykota.com/software/pykota) as a printjob accounting software (d) a backend using Tea4CUPs (http://www.pykota.com/software/tea4cups) to fan out (multiply) certain jobs to multiple production printers (e) a backend that reads a hidden file in each user's home directory containing a PIN and a USERCODE to insert these into the PostScript file to enable user specific locked printing on certain printers (f) and 3 more custom backends which I can't talk about here. This change caught the customer completely off guard; it looks like the upgrade did not warn him about such heavy-handed changes when the post- install script ran. He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). Moreover, while you introduced these changes (amounting to a de-facto fork from upstream IMHO), you did not sufficiently document these. In fact, the CUPS documentation you ship is still suggesting to the user that his cupsd runs as root. The way you introduced these changes in effect completely takes away users' freedom to run cupsd unchanged in its behavior from upstream's version; and I'm very doubtful if you even added any substantial gain in security with these modifications. If you think you need to protect users from security breeches your way (by adding a non-standard, now old feature back to your current CUPS (a feature that was dropped by the CUPS developers themselves), then please at least do it in a way that still allows to configure away your default (by also re-enabling the RunAsUser No directive in cupsd.conf). Hence, my feature requests: -- either return to the same setup as upstream CUPS sources, -- or do re-enable the RunAsUser No option in cupsd.conf -- and please do at least make it un-mistakenly clear in the CUPS docu at localhost:631/help what you changed and how the user can return to upstream's CUPS behavior for its scheduler and backends. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.infotec.com Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung. This E-Mail is for the exclusive use of the recipient and may
Bug#427559: [Pkg-cups-devel] Bug#427559: cupsd run as user changes in 1.2.11-2 breaks existing installations (no printing)
Martin-Éric Racine wrote: On 6/5/07, Kurt Pfeifle [EMAIL PROTECTED] wrote: Package: cupsys Version: 1.2.11-2 I'm reporting on behalf of a customer who called me today because important functions on his test printserver [running on Sid] broke after upgrading to CUPS 1.2.11-2; He can not use that system any more for now, until he pays money to some- one to fix everything (if that is at all possible; otherwise to migrate it to a non-Debian distro). I was gonna answer point by point to your very detailed wishlist, except Oh, I'm so sorry to have rubbed your skin the wrong way and to have made you giving up on that noble intention! that I have serious issues with your report on one specific aspect: Your customer is running Testing on a production server that he needs to depend upon for everyday work. No, you didn't read (or exactly memorize) what I wrote. I said it was his *test* print server. Please check. As far as cretinism goes, this one wins the jackpot. As far as shooting quickly, but not precisely and rudeness goes, this one surely does not take the last place. There are two possible solutions to the above bug report's main issues: 1) Your customer must acquire the brains Please stop calling anyone any names in a public, archived Debian forum. to realize that the only sensible release to run on production servers is Stable and he should therefore immediately downgrade to Etch. Please realize a few things: * it is his decision what he runs on his test printserver system(s) * it is his decision even if he'd run Sid on his production printserver system * it is totally legal and valid to report bugs and submit wishlist items against a Sid/unstable system irrespective of the fact whether these were acquired on a production system * you should be grateful to receive bug reports for Sid packages at all, wether they originate from user test or from user production systems * whatever Your Majesty may deem sensible for everyone, please do try to understand that *sometimes* Stable packages just do not have the features that someone needs in production, and that some people may have a strong need to run Unstable test systems so that their production systems running Testing or Stable can be early forwarned about upcoming problems * some people run Testing and Unstable *now* on their test and pilot systems because they have a long term plan to migrate hundreds of servers and 10s of thousands of workstations to Linux, away from a proprietary system (and by the time of the migration they hope to use a Stable or Testing version) * you can debate with me in private mail when and when not it is appro- priate to run Stable and/or Unstable; but this public thread started with a bug report/feature request that describes a real problem; that problem will make itself felt in Stable as soon as package makes the transition; therefor it is completely irrelevant if the current feed- back was won from a production or from a testing system. Is that comprehensible? 2) As he nonetheless chose to run Testing, he is invited to fix his software to match our changes and help us streamline the transition to non-root user operation, It is very revealing that you do not see this bug report as an occasion to streamline your changes, Your Honor. by reporting on actual bugs, rather than on features which we deliberately chose to close uptream's patently broken security model. I didn't see you participate in any of the detailed discussions that took place on the upstream mailing lists about that particular topic; not once on many occasions over the last 2-3 years when they happened; therefore I do not deem you competent in uttering a verdict about upstream having a patently broken security model. Moreover, while you introduced these changes (amounting to a de-facto fork from upstream IMHO), you did not sufficiently document these. In fact, the CUPS documentation you ship is still suggesting to the user that his cupsd runs as root. The Debian changelog makes it abundantly clear that we're aware that this is gonna break some things and that Lenny's development cycle exists to iron things out. Whatever. Please document it also in the *user* documentation, that every user looks at first: http://localhost:631/help/. This part of CUPS can be patched as well, ya know? Please do not tolerate that this documentation contradicts what behavior your source code patches along with your compile time changes do change for the user. Can you now say something to my requested changes, puh-leeze? Even if it is WONTFIX?! -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711
Bug#259774: this bug report can be closed
Why would CUPS apply/not apply lpoptions depending on the origin of the print job? Because the job originator (Windows) sent the job with the raw option? Or maybe CUPS did auto-type the received jobfile as application/octet- stream mime type -- which does only print as raw (that means no options will be applied), but only when raw printing for octet-stream files is enabled, or not print at all? (Check the auto-typing line in your CUPS error_log file written with LogLevel debug) The most recent releases of Samba 3.0.20+ now do include a new smb.conf parameter called cups options added. You can set this parameter to any single CUPS job option, or a part, or the complete list of options con- tained in your lpoptions file; whatever you want. I think this bug report can be closed. -- Kurt Pfeifle System Network Printing Consultant Linux/Unix/Windows/Samba/CUPS Infotec Deutschland GmbH . Hedelfinger Strasse 58 A RICOH Company ... D-70327 Stuttgart/Germany --- Infotec Deutschland GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.infotec.com Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Infotec Deutschland GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.infotec.com oder in jeder Infotec Niederlassung. This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of this communication, in whole or in part, is not permitted. Any views or opinions presented are those of the author and (unless otherwise specifically stated) do not represent those of Infotec Deutschland GmbH or their directors or officers; none of whom are responsible for any reliance placed on the information contained herein. Although reasonable precautions have been taken to ensure that no viruses are present, all liability is excluded for any loss or damage arising from the use of this email or attachments. For further information please see our website at www.infotec.com or refer to any Infotec office.
Bug#303629: [INVALID] Please support frames around multiple pages
Hi, this bug report is not accepted as valid by the KDEPrint maintainers. KDEPrint can already do what you want (and can do so since more than 5 years already). Please look for more details at the explanations given at http://bugs.kde.org/show_bug.cgi?id=142893 Cheers -- Kurt Pfeifle, KDEPrint Bugzilla Janitor --- Danka Deutschland Holding GmbH Hedelfingerstrasse 58 D-70327 Stuttgart Telefon +49 711 4017-0, Fax +49 711 4017-5752 www.danka.de Geschaeftsfuehrer: Elmar Karl Josef Wanderer, Frank Grosch, Heinz-Josef Jansen Sitz der Gesellschaft: Stuttgart, Handelsregister HRB Stuttgart 20398 Der Inhalt dieser E-Mail ist vertraulich und ist nur für den Empfänger bestimmt. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich an Sie adressiert wurde, verständigen Sie bitte den Absender sofort und löschen Sie die E-Mail sodann. Das unerlaubte Veröffentlichen, Kopieren sowie die unbefugte Übermittlung komplett oder in Teilen sind nicht gestattet.Private Ansichten und Meinungen sind, wenn nicht ausdrücklich erklärt, die des Autors und nicht die der Danka Deutschland Holding GmbH oder deren verantwortliche Direktoren und Angestellte. Eine Haftung für Schäden oder Verlust von Daten durch den Gebrauch dieser Email oder deren Anhänge wird ausgeschlossen. Weitere Informationen erhalten Sie im Internet unter www.danka.de oder in jeder Danka Niederlassung. This E-Mail is for the exclusive use of the recipient and may contain information which is confidential. Any disclosure, distribution or copying of this communication, in whole or in part, is not permitted. Any views or opinions presented are those of the author and (unless otherwise specifically stated) do not represent those of Danka Deutschland Holding GmbH or their directors or officers; none of whom are responsible for any reliance placed on the information contained herein. Although reasonable precautions have been taken to ensure that no viruses are present, all liability is excluded for any loss or damage arising from the use of this email or attachments. For further information please see our website at www.danka.de or refer to any Danka office.
Bug#370409: cupsys: When modifying a printer, the UI forgets the device URI
Whenever I modify a printer (ie, when the PPD file changes) the device URI defaults to socket (I'm using a HP with a JetDirect card in it). When means I then have to go back to the printer overview page and cut'n'paste the device URI. It seems to me that the modify page should have the current URI in the input box. Did you ever dare to click on Continue when that page was displayed? I did. Result: the next page does display the complete current device URI setting. So in fact, CUPS does not forget the setting. Caveat: I' currently running a self-compiled SVN trunk (r5630). So at least it works in this version without the annoyance you report. Please verify, if it works for your version too. Cheers, Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
