[opensuse-packaging] cups: upgrade from 1.4.x to version 1.5.0
Hello, in the OBS project "Printing" there is now CUPS version 1.5.0 for various openSUSE and SLE versions. It may take a few hours until RPMs appear under http://download.opensuse.org/repositories/Printing/ For openSUSE:Factory there is submitrequest 86888 pending to upgrade CUPS in openSUSE:Factory to version 1.5.0. See https://bugzilla.novell.com/show_bug.cgi?id=722057 for background information. Basically: According to http://www.cups.org/roadmap.php CUPS 1.4.x is no longer maintained by upstream which is the reason to upgrade to version 1.5.0. Backward incompatible changes: * The main header cups/cups.h no longer includes the PPD header cups/ppd.h which may require code changes to applications. * CUPS no longer supports the old ~/.cupsrc or ~/.lpoptions files from CUPS 1.1.x. The ~/.cups/client.conf and ~/.cups/lpoptions files that were introduced in CUPS 1.2 must now be used. * The scheduler now requires that filters and backends have group write permissions disabled (security). This means: Compiling software which use the CUPS PPD API but do not explicitly include the <cups/ppd.h> header file would fail. This backward-incompatible change should show up during package build in OBS so that affected packages can be fixed. In old-style applications which still use ~/.cupsrc and ~/.lpoptions user default settings would no longer work. I have no idea how many such old-style applications may exits. Printer driver packages which install their own filters and backends with group write permissions would no longer work. I will check those packages in OBS. For third party printer drivers from manufacturers I cannot do anything (they may no longer work without manual adjustment). I appreciate any testing and feedback regarding CUPS 1.5.0. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [06.10.2011 12:21]:
Hello,
in the OBS project "Printing" there is now CUPS version 1.5.0 for various openSUSE and SLE versions.
[...]
Basically: According to http://www.cups.org/roadmap.php CUPS 1.4.x is no longer maintained by upstream which is the reason to upgrade to version 1.5.0.
[...]
I appreciate any testing and feedback regarding CUPS 1.5.0.
Hi Johannes, I installed it and it does not work as expected. I expected that, more or less ;-) First, my printer is configured to print on both sides of the paper. It does not do so now. When trying to look at the printer's config via https://localhost:631, I can click on the printer and see the printer page (which was not the case in CUPS 1.4.x with x < 3). But whatever action I chose in any of the select boxes, nothing happened. In 1.4.6, the respective action was started right then (modify printer, config printer, print test page, ...). Bad luck for me, since our company's Linux/Unix print servers run CUPS (on SLES 11). I think I should not update them ATM ;-) But because of the lack of upstream support, it was of course necessary to go away from 1.4.6 for the build service. Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6NtmMACgkQk33Krq8b42P+WwCcC9cFe64KWwoQKv+VNOFvJJa1 jrkAn0nDiRr9Skajz29SfYV2lBVIgufi =O1oV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Oct 6, 2011 at 9:08 AM, Werner Flamme <werner.flamme@ufz.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johannes Meixner [06.10.2011 12:21]:
Hello,
in the OBS project "Printing" there is now CUPS version 1.5.0 for various openSUSE and SLE versions.
[...]
Basically: According to http://www.cups.org/roadmap.php CUPS 1.4.x is no longer maintained by upstream which is the reason to upgrade to version 1.5.0.
[...]
I appreciate any testing and feedback regarding CUPS 1.5.0.
Hi Johannes,
I installed it and it does not work as expected. I expected that, more or less ;-)
First, my printer is configured to print on both sides of the paper. It does not do so now.
When trying to look at the printer's config via https://localhost:631, I can click on the printer and see the printer page (which was not the case in CUPS 1.4.x with x < 3). But whatever action I chose in any of the select boxes, nothing happened. In 1.4.6, the respective action was started right then (modify printer, config printer, print test page, ...).
I happened to notice that, after installing 1.5.0, the pages still said 1.4.6. Try shift-reload or clear your cache. For whatever reason, that did it for me and 1.5.0 worked fine for me. I also had to restart 1.5.0 twice on one of the machines. -- Jon -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Nelson [06.10.2011 16:26]:
On Thu, Oct 6, 2011 at 9:08 AM, Werner Flamme <werner.flamme@ufz.de> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johannes Meixner [06.10.2011 12:21]:
Hello,
in the OBS project "Printing" there is now CUPS version 1.5.0 for various openSUSE and SLE versions.
[...]
Basically: According to http://www.cups.org/roadmap.php CUPS 1.4.x is no longer maintained by upstream which is the reason to upgrade to version 1.5.0.
[...]
I appreciate any testing and feedback regarding CUPS 1.5.0.
Hi Johannes,
I installed it and it does not work as expected. I expected that, more or less ;-)
First, my printer is configured to print on both sides of the paper. It does not do so now.
When trying to look at the printer's config via https://localhost:631, I can click on the printer and see the printer page (which was not the case in CUPS 1.4.x with x < 3). But whatever action I chose in any of the select boxes, nothing happened. In 1.4.6, the respective action was started right then (modify printer, config printer, print test page, ...).
I happened to notice that, after installing 1.5.0, the pages still said 1.4.6. Try shift-reload or clear your cache. For whatever reason, that did it for me and 1.5.0 worked fine for me. I also had to restart 1.5.0 twice on one of the machines.
Jon, this did not work for me. At first try, the CUPS start page showed 1.5.0 all right. But even today, after the box was powered off for several hours, I get no action from the interface. The HTML code is <SELECT NAME="OP" ONCHANGE="document.administration.submit();"> and <SELECT NAME="OP" ONCHANGE="document.maintenance.submit();"> respectively. And there is a (hidden) submit button in the form. The HTML code is exactly the same as in 1.4.6 on our printservers, even the <FORM>-tags themselves are identical. The only difference is that there is no action in 1.5.0 :-( As I see now, the behaviour is restricted to Firefox (Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1). Pages are printed when I use Opera. Nice. CUPS seems not to like Firefox (or other way round). I remember the times when it became impossible to create a printer with Firefox, always a neverending loop in the last step (after selecting the PPD). Opera worked fine. The behaviour seems to be back :-( Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6OvIQACgkQk33Krq8b42OjFQCfcgFBGJGCzh0HQ3XUNB7VaCPV n90An2EtqLodFx9Z4S0jsZ3aYKz4NEC4 =mt73 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Oct 6 16:08 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
What is "my printer"? See http://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue Whether or not it prints duplex usually depends on the driver. I cannot imagine how a change of the base printing system changes what the driver does. Is it perhaps that the duplex setting in your case is still stored in the old ~/.cupsrc or ~/.lpoptions files? Since CUPS 1.5 the ~/.cups/client.conf and ~/.cups/lpoptions files that were introduced in CUPS 1.2 must now be used. In general regarding "Print Settings with CUPS" see http://en.opensuse.org/SDB:Print_Settings_with_CUPS at which places you may check where exactly the duplex setting is stored in your particular case.
When trying to look at the printer's config via https://localhost:631, I can click on the printer and see the printer page ... But whatever action I chose in any of the select boxes, nothing happened.
For me it works (i.e. I cannot reproduce it). But there have always been reports that in this or that particular case there are issues with the CUPS web interface. In some cases the root cause was that an old /etc/cups/cupsd.conf file with an outdated "DocumentRoot" entry from an old CUPS installation is still there. The DocumentRoot directive specifies the location of web content for the HTTP server in CUPS. This location has changed a few times in the past and by default there should be no "DocumentRoot" entry in /etc/cups/cupsd.conf which means that the currently running cupsd uses its built-in value which is set during compile time to "the currently right location". See the current cups.cpec file in the "Printing" project: https://build.opensuse.org/package/view_file?file=cups.spec&package=cups&project=Printing ------------------------------------------------------------------------- # As long as cups-1.4.3-default-webcontent-path.patch is applied # configure --with-docdir=... would be no longer needed # because cups-1.4.3-default-webcontent-path.patch changes the # default with-docdir path whereto the web content is installed # from /usr/share/doc/cups to /usr/share/cups/webcontent because the # files of the CUPS web content are no documentation, see CUPS STR #3578 # and http://bugzilla.novell.com/show_bug.cgi?id=546023#c6 # and subsequent comments # so that the new default could be used as is but upstream may accept # cups-1.4.3-default-webcontent-path.patch in general but change # its default # so that with-docdir is explicitely set here to be future proof: ./configure \ ... --with-docdir=%{_datadir}/cups/webcontent \ ------------------------------------------------------------------------- CUPS STR #3578 is http://www.cups.org/str.php?L3578 Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [07.10.2011 11:06]:
Hello,
On Oct 6 16:08 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
What is "my printer"?
The printer I use as system default, the only printer defined locally. BTW, it's a HP LaserJet 4200dtn, accessed via network.
See http://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue
Whether or not it prints duplex usually depends on the driver. I cannot imagine how a change of the base printing system changes what the driver does.
I did not change the printers PPD in /etc/cups/ppd nor did I change /etc/cups/printers.conf.
Is it perhaps that the duplex setting in your case is still stored in the old ~/.cupsrc or ~/.lpoptions files?
Will CUPS show (grayscale, 2-sided printing) to me in this case?
Since CUPS 1.5 the ~/.cups/client.conf and ~/.cups/lpoptions files that were introduced in CUPS 1.2 must now be used.
Since I don't have ~/.cupsrc or ~/.lpoptions, I don't think I have to move individual settings. ~/.cups/lpoptions exists (date: 28. Apr 16:24) and contains one line: Default hplaserjet4200
When trying to look at the printer's config via https://localhost:631, I can click on the printer and see the printer page ... But whatever action I chose in any of the select boxes, nothing happened.
For me it works (i.e. I cannot reproduce it).
That's OK, it might be a Firefox problem, as I said in Message-id: <4E8EBC84.1000908@ufz.de>. It works fine with Opera, too.
But there have always been reports that in this or that particular case there are issues with the CUPS web interface.
Yes *sigh*, I remember. Whenever any colleague tried to change the PPD file of any printer (last step in "modify printer"), Firefox built an endless loop. With Internet Exploder or Opera, everything went fine.
In some cases the root cause was that an old /etc/cups/cupsd.conf file with an outdated "DocumentRoot" entry from an old CUPS installation is still there.
No chance here ;-) [...]
Kind Regards Johannes Meixner
Thank you! Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6OxMwACgkQk33Krq8b42MSdgCfWHTNwe8wef76BVNu3Tph2YEz kx4AnRjPsnYIoVVz7IV+ZpUchdVyCDCj =KfPq -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Oct 7 11:22 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
The printer I use as system default, the only printer defined locally. BTW, it's a HP LaserJet 4200dtn, accessed via network.
What is the output of a command like lpoptions -p <queue_name> -l | grep -i duplex You may run "lpoptions -p <queue_name> -l" and extract those lines which seem to be of interest regarding "print on both sides".
But there have always been reports that in this or that particular case there are issues with the CUPS web interface.
Yes *sigh*, I remember. Whenever any colleague tried to change the PPD file of any printer (last step in "modify printer"), Firefox built an endless loop. With Internet Exploder or Opera, everything went fine.
For the "fun" an issue where it is the other way round: There is a change regarding the CUPS web interface to make it work better in particular for Epiphany and Internet Explorer: http://www.cups.org/str.php?L3455 ------------------------------------------------------------------ ... seems to work ok with Firefox3 ... with epiphany (webkit), it hangs forever ... differently than Safari ... Same error happens in chrome ... issue on webkit-based browser (epiphany, chromium...) ... where on firefox or seamonkey it works fine ... neither IE 7 nor IE 8 seem to be able to handle it ... still a problem ... with IE8 ------------------------------------------------------------------ Those browser-dependant issues with the CUPS web interface often depend not only on the browser and the browser version, but additionally on whatever specific settings for the browser which a particular user may have set. Regarding browser-dependant issues with the CUPS web interface it would be best to report such issues directly to upstream via http://www.cups.org/str.php?U so that there is a direct communication between the user who has such an issue with his particular browser and the upstream authors. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [07.10.2011 12:23]:
Hello,
On Oct 7 11:22 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
The printer I use as system default, the only printer defined locally. BTW, it's a HP LaserJet 4200dtn, accessed via network.
What is the output of a command like
lpoptions -p <queue_name> -l | grep -i duplex
You may run "lpoptions -p <queue_name> -l" and extract those lines which seem to be of interest regarding "print on both sides".
lpoptions -p hplaserjet4200 -l | grep -i duplex HPOption_Duplexer/: *True False Duplex/: None *DuplexNoTumble DuplexTumble
But there have always been reports that in this or that particular case there are issues with the CUPS web interface.
Yes *sigh*, I remember. Whenever any colleague tried to change the PPD file of any printer (last step in "modify printer"), Firefox built an endless loop. With Internet Exploder or Opera, everything went fine.
For the "fun" an issue where it is the other way round:
There is a change regarding the CUPS web interface to make it work better in particular for Epiphany and Internet Explorer: http://www.cups.org/str.php?L3455 ------------------------------------------------------------------ ... seems to work ok with Firefox3 ... with epiphany (webkit), it hangs forever ... differently than Safari ... Same error happens in chrome ... issue on webkit-based browser (epiphany, chromium...) ... where on firefox or seamonkey it works fine ... neither IE 7 nor IE 8 seem to be able to handle it ... still a problem ... with IE8 ------------------------------------------------------------------
Isn't that always the strategy? Build a product that is running well, and then go to a new version and "improve" something that hurts most other constellations? ;-) Currently, I care about SAP systems, so I know what I speak about ;-) In the present case, I can tell the colleagues to change the browser, so I do not see this as serious. Most of them run Windoze, anyway.
Regarding browser-dependant issues with the CUPS web interface it would be best to report such issues directly to upstream via http://www.cups.org/str.php?U so that there is a direct communication between the user who has such an issue with his particular browser and the upstream authors.
I tried to report a problem that I considered as a bug last year. The report was closed without any comment. I can not imagine that I will report anything at CUPS. BTW, it was the "-o job-sheets=none,none" addition to the file /etc/xinetd.d/cups-lpd that I was looking for - without even knowing that it exists. CUPS' docu was obviously written by its programmer... Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6O4gEACgkQk33Krq8b42OvsACeNV3BNDXnA3u/Bz9rg8B159GY +nQAn3mObu6ysAJuTDIDB58vWMOLYzSr =MIZM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Oct 7 13:26 Werner Flamme wrote (excerpt):
On Oct 7 11:22 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
it's a HP LaserJet 4200dtn, accessed via network.
lpoptions -p hplaserjet4200 -l | grep -i duplex HPOption_Duplexer/: *True False Duplex/: None *DuplexNoTumble DuplexTumble
Strange. With echo -en '\rOne\r\fTwo\r\f' | lp -d hplaserjet4200 you do not get "One" and "Two" printed on both sides of one sheet of paper? If not, does it perhaps help to enforce what should be used by default: echo -en '\rOne\r\fTwo\r\f' | lp -d hplaserjet4200 -o Duplex=DuplexNoTumble Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [07.10.2011 13:38]:
Hello,
On Oct 7 13:26 Werner Flamme wrote (excerpt):
On Oct 7 11:22 Werner Flamme wrote (excerpt):
First, my printer is configured to print on both sides of the paper. It does not do so now.
it's a HP LaserJet 4200dtn, accessed via network.
lpoptions -p hplaserjet4200 -l | grep -i duplex HPOption_Duplexer/: *True False Duplex/: None *DuplexNoTumble DuplexTumble
Strange.
With
echo -en '\rOne\r\fTwo\r\f' | lp -d hplaserjet4200
you do not get "One" and "Two" printed on both sides of one sheet of paper?
It works now. From the command line. Acrobat Reader shows a strange dialogue window (File -> Print -> Properties) with loads of emtpy lines, only two entries visible on the left side and somewhere an entry on the right side. Invisible only, I think, because I can select three lines on the right side when the first empty line on the left side is visible. Usually, Acroread just shows the options that are already selected as default. Just pressing the "OK" button printed on both sides. Now it doesn't, and I can't see the options. But this might be an issue of Acrobat together with KDE 4.7.2, I don't know. KPDF prints fine and shows the options correctly. Aargh :-( This leads into nowhere :-( Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6PAIYACgkQk33Krq8b42M0/wCfdlDbcdibN8S8HIimLXECiccy GQ8Aniu+XXepqpxVxxSK8cg7dg9u5hhy =29jk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Oct 7 15:37 Werner Flamme wrote (excerpt):
echo -en '\rOne\r\fTwo\r\f' | lp -d hplaserjet4200
you do not get "One" and "Two" printed on both sides of one sheet of paper?
It works now. From the command line.
O.k. - then it is very likely not a bug in CUPS 1.5.0.
Acrobat Reader shows a strange dialogue window (File -> Print -> Properties) with loads of emtpy lines, only two entries visible on the left side and somewhere an entry on the right side. Invisible only, I think, because I can select three lines on the right side when the first empty line on the left side is visible.
Usually, Acroread just shows the options that are already selected as default. Just pressing the "OK" button printed on both sides. Now it doesn't, and I can't see the options. But this might be an issue of Acrobat together with KDE 4.7.2, I don't know.
Does it perhaps help to move ~/.adobe/ away for a test? Perhaps the Adobe Reader stores printing related details there which need some kind of reset after a CUPS version upgrade? I have printing related stuff in ~/.adobe/Acrobat/9.0/Preferences/reader_prefs Proprietary software like the Adobe Reader may somehow depend on whatever implementation details in CUPS 1.4.x which might have changed in CUPS 1.5.0 or on whatever implementation details in whatever other software. Even if a change in CUPS lets the Adobe Reader print dialog no longer work well, only Adobe could adapt their proprietary software to work again with the current versions of free software packages and only Adobe could check if a change in whatever free software package would be actually a bug and report such a bug to the appropriate free software project because only Adobe knows how their proprietary software works.
This leads into nowhere :-(
This leads to a not really surprising finding about proprietary software. If other users of the Adobe Reader could confirm that since the upgrade from CUPS 1.4.x to CUPS 1.5.0 the Adobe Reader print dialog does no longer work well, please file a bug report so that the issue is at least known and reported to us. Of course because the Adobe Reader is proprietary software, all what we could do is to inform Adobe about the issue and then wait until Adobe releases an update of their proprietary software. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [07.10.2011 16:35]:
It works now. From the command line.
O.k. - then it is very likely not a bug in CUPS 1.5.0.
I happily agree :-)
Acrobat Reader shows a strange dialogue window (File -> Print -> Properties) with loads of emtpy lines, only two entries visible on the left side and somewhere an entry on the right side. Invisible only, I think, because I can select three lines on the right side when the first empty line on the left side is visible.
Usually, Acroread just shows the options that are already selected as default. Just pressing the "OK" button printed on both sides. Now it doesn't, and I can't see the options. But this might be an issue of Acrobat together with KDE 4.7.2, I don't know.
Does it perhaps help to move ~/.adobe/ away for a test?
Neither removing ~/.adobe nor removing ~/.acrobat gave any changes.
Perhaps the Adobe Reader stores printing related details there which need some kind of reset after a CUPS version upgrade?
I have printing related stuff in ~/.adobe/Acrobat/9.0/Preferences/reader_prefs
I have this file, too, and renamed ~/.adobe/Acrobat/9.0 to ~/.adobe/Acrobat/9.0.mist first, but nothing changed Then I removed ~/.adobe and ~/.acrobat, same result. Yes, acroread was closed when I did that :-)
This leads into nowhere :-(
This leads to a not really surprising finding about proprietary software.
Yes, into nowhere, since /no/body knows /where/ to find the reponsible code ;-)
If other users of the Adobe Reader could confirm that since the upgrade from CUPS 1.4.x to CUPS 1.5.0 the Adobe Reader print dialog does no longer work well, please file a bug report so that the issue is at least known and reported to us.
I think I will do so, when the dialog window is still empty on monday. Can I attach screenshots or should those pics be stored externally?
Of course because the Adobe Reader is proprietary software, all what we could do is to inform Adobe about the issue and then wait until Adobe releases an update of their proprietary software.
Unfortunately, I have to use it because we have several forms in the office that require this proprietary stuff. Best regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk6PEr8ACgkQk33Krq8b42MXagCeNxrUrpwQGzcuJN6rVNVHJRrX 1hUAnjKF7YR3oZYyfzdZAKVbtzO2denG =bSfW -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Might I offer a suggestion? Try to get a tcpdump (-w some_file -s 0 port 631) from both 1.4.x and 1.5.0 when using the proprietary software. That might offer a clue as to what's going on. -- Jon -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Oct 7 16:54 Werner Flamme wrote (excerpt):
Johannes Meixner [07.10.2011 16:35]: ...
If other users of the Adobe Reader could confirm that since the upgrade from CUPS 1.4.x to CUPS 1.5.0 the Adobe Reader print dialog does no longer work well, please file a bug report so that the issue is at least known and reported to us.
I think I will do so, when the dialog window is still empty on monday. Can I attach screenshots or should those pics be stored externally?
Please attach screenshots directly to the bug report (and specify the matching MIME type in Bugzilla). Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Donnerstag, 6. Oktober 2011 schrieb Johannes Meixner:
CUPS 1.4.x is no longer maintained by upstream which is the reason to upgrade to version 1.5.0.
Backward incompatible changes: [...] * CUPS no longer supports the old ~/.cupsrc or ~/.lpoptions files from CUPS 1.1.x. The ~/.cups/client.conf and ~/.cups/lpoptions files that were introduced in CUPS 1.2 must now be used. * The scheduler now requires that filters and backends have group write permissions disabled (security).
Those two changes should be mentioned in the release notes IMHO. Your text quoted above already looks good, the only thing I'd add is: If you use thirt party printer drivers from manufacturers, you might need to adjust the permissions manually. Regards, Christian Boltz -- Yes Karl, your machine has a battery! But no ac adapter :-) Unfortunately it is the battery in the BT Mouse and it won't be able to power your system for very long :-) [Stefan Seyfried in https://bugzilla.novell.com/show_bug.cgi?id=221999] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [06.10.2011 12:21]:
Hello,
in the OBS project "Printing" there is now CUPS version 1.5.0 for various openSUSE and SLE versions.
I appreciate any testing and feedback regarding CUPS 1.5.0.
Johannes, finally I found a real bug! And a workaround... In /etc/cups/cupsd.conf, I have lines like: ServerName printlpz1l.intranet.ufz.de ServerAlias printlpz1l ServerAlias 141.65.124.19 Whenever I try to access <https://printlpz1l.intranet.ufz.de:631>, I get "Bad Request". But: I can access <https://printlpz1l:631> or <https://141.65.124.19:631> without problems. lpstat -h printlpz1l.intranet.ufz.de -a - -> error lpstat -h printlpz1l - -> long list Five minutes ago, I added ServerAlias printlpz1l.intranet.ufz.de to /etc/cups/cupsd.conf and voilà - the host is accessible with its FQDN. Via web as well as via lpstat. Obviously, CUPS allows access to the ServerAlias only, and refuses access to ServerName. In /var/log/cups/error_log I see lines like Request from "141.65.31.19" using invalid Host: field "printlpz1l.intranet.ufz.de" That's an interesting bug. They may have invested a lot of brain power for that :-) BTW, The entry after ServerName is the "real" hostname... Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ydygACgkQk33Krq8b42PJ5QCfTCZronLjems0eVOWXFEsG++w XcUAn0Vb6WMrHv8bOcSRJSjexA3/uplG =px1E -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 3 12:12 Werner Flamme wrote (excerpt):
finally I found a real bug! And a workaround...
In /etc/cups/cupsd.conf, I have lines like:
ServerName printlpz1l.intranet.ufz.de ServerAlias printlpz1l ServerAlias 141.65.124.19
Whenever I try to access <https://printlpz1l.intranet.ufz.de:631>, I get "Bad Request". But: I can access <https://printlpz1l:631> or <https://141.65.124.19:631> without problems.
lpstat -h printlpz1l.intranet.ufz.de -a - -> error
lpstat -h printlpz1l - -> long list
Five minutes ago, I added
ServerAlias printlpz1l.intranet.ufz.de
to /etc/cups/cupsd.conf and voilà - the host is accessible with its FQDN. Via web as well as via lpstat.
Obviously, CUPS allows access to the ServerAlias only, and refuses access to ServerName. In /var/log/cups/error_log I see lines like
Request from "141.65.31.19" using invalid Host: field "printlpz1l.intranet.ufz.de"
That's an interesting bug. They may have invested a lot of brain power for that :-) BTW, The entry after ServerName is the "real" hostname...
Yes, they invested a lot of brain power to protect you against DNS rebinding attacks which unfortunately results in some cases that you get "overprotected". Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)? See for example the "cupsd no longer allows using cname (alias) must use hostname" mail thread on cups@easysw.com http://www.cups.org/newsgroups.php?gcups.general+T+Q%22cupsd+no+longer+allow... ------------------------------------------------------------------------- From: Michael Sweet ... You are running into the (relatively new) DNS rebinding attack protection code. Sadly, while we do our best at startup we don't always catch all of the aliases for a given server. To work around this, add ServerAlias directives to your cupsd.conf file, either the "allow anything" version: ServerAlias * or one per hostname, e.g.: ServerAlias name1.example.com ServerAlias name2.example.com ServerAlias name3.example.com ------------------------------------------------------------------------- or see the "cups server not responds by alias name since cups-1.3.9" mail thread on cups@easysw.com http://www.cups.org/newsgroups.php?gcups.general+T+Q%22cups+server+not+respo... If your particular issue is a different case, please report it on cups@easysw.com Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer
On Thu, Nov 3, 2011 at 8:38 AM, Johannes Meixner <jsmeix@suse.de> wrote:
Hello,
On Nov 3 12:12 Werner Flamme wrote (excerpt):
finally I found a real bug! And a workaround...
In /etc/cups/cupsd.conf, I have lines like:
ServerName printlpz1l.intranet.ufz.de ServerAlias printlpz1l ServerAlias 141.65.124.19
Whenever I try to access <https://printlpz1l.intranet.ufz.de:631>, I get "Bad Request". But: I can access <https://printlpz1l:631> or <https://141.65.124.19:631> without problems.
lpstat -h printlpz1l.intranet.ufz.de -a - -> error
lpstat -h printlpz1l - -> long list
Five minutes ago, I added
ServerAlias printlpz1l.intranet.ufz.de
to /etc/cups/cupsd.conf and voilà - the host is accessible with its FQDN. Via web as well as via lpstat.
Obviously, CUPS allows access to the ServerAlias only, and refuses access to ServerName. In /var/log/cups/error_log I see lines like
Request from "141.65.31.19" using invalid Host: field "printlpz1l.intranet.ufz.de"
That's an interesting bug. They may have invested a lot of brain power for that :-) BTW, The entry after ServerName is the "real" hostname...
Yes, they invested a lot of brain power to protect you against DNS rebinding attacks which unfortunately results in some cases that you get "overprotected".
Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)?
I had a *lot* of problems with previous versions of CUPS regarding this "feature". Specifically, it broke printing to a local CUPS server from VirtualBox / QEMU / KVM etc.... in many cases. -- Jon -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 3 08:41 Jon Nelson wrote (excerpt):
... it broke printing to a local CUPS server from VirtualBox / QEMU / KVM etc.... in many cases.
I assume you mean something like http://www.cups.org/str.php?L3811 "cups does no longer work with virtual guest (kvm)" where CUPS upstream replied that ---------------------------------------------------------------- this isn't something we a) can support or b) change without opening up a huge security hole. ---------------------------------------------------------------- If my assumption is right, this is not a new issue since CUPS 1.5.x which had worked with 1.4.6. Please do not misuse this mail thread which is about issues in CUPS because of the upgrade from 1.4.x to version 1.5 and do not misuse the opensuse-packaging@opensuse.org mailing list for general issues with upstream CUPS which you must instead discuss directly with CUPS upstream via http://www.cups.org/newsgroups.php Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Nov 3, 2011 at 9:16 AM, Johannes Meixner <jsmeix@suse.de> wrote:
Hello,
On Nov 3 08:41 Jon Nelson wrote (excerpt):
... it broke printing to a local CUPS server from VirtualBox / QEMU / KVM etc.... in many cases.
I assume you mean something like http://www.cups.org/str.php?L3811
Yes.
"cups does no longer work with virtual guest (kvm)" where CUPS upstream replied that ---------------------------------------------------------------- this isn't something we a) can support or b) change without opening up a huge security hole. ----------------------------------------------------------------
If my assumption is right, this is not a new issue since CUPS 1.5.x which had worked with 1.4.6.
Please do not misuse this mail thread which is about issues in CUPS because of the upgrade from 1.4.x to version 1.5 and do not misuse the opensuse-packaging@opensuse.org mailing list for general issues with upstream CUPS which you must instead discuss directly with CUPS upstream via http://www.cups.org/newsgroups.php
I was merely pointing out that the problem is not necessarily "new" in 1.5.0, but I'll be sure to keep your words in mind. -- Jon -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Johannes, On 03.11.2011 14:38, Johannes Meixner wrote:
Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)?
I'm pretty sure I had seen something like that on 11.4 or earlier when I had "print" in /etc/hosts and tried to access it as "print.domain". Adding all aliases of the server, including FQDNs to /etc/hosts made it work IIRC. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Seyfried [03.11.2011 16:07]:
Hi Johannes,
On 03.11.2011 14:38, Johannes Meixner wrote:
Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)?
I'm pretty sure I had seen something like that on 11.4 or earlier when I had "print" in /etc/hosts and tried to access it as "print.domain". Adding all aliases of the server, including FQDNs to /etc/hosts made it work IIRC.
All print servers are in DNS with their FQDN, and the error came up on all clients that tried to contact the print servers via FQDN. As soon as they switched to using the short name, everything went well. The DNS translates short name and FQDN to exactly the same address. I learned years earlier that I had to provide several aliases in CUPS. Sometimes, the intranet domain names change, and the addresses do not. So the print servers hat entries in cupsd.conf like ServerName pris5.leipzig.ufz.de (the "real" hostname) ServerAlias 141.65.x.y ServerAlias pris5 ServerAlias pris5.intern.ufz.de ServerAlias pris5.halle.ufz.de and so on. CUPS did not care a dime about this, but the certificate was issued containing all those names, so you could access it with the browser to investigate your print jobs. Before I added all those lines, the certificate was issued for the real hostname only, and every access with another name caused grief ;-) BTW, if DNS could not resolve the FQDN, IMHO I'd never get "Bad request", but "Connection timed out" or "Server not found" :-( Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6yt8YACgkQk33Krq8b42MylACfUe0++9cfY4oo888QoWw81g5Y xNgAnjD3SEz9r+rB4UVmYRYILSHtuwS9 =UwxT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 03.11.2011 16:48, Werner Flamme wrote:
Stefan Seyfried [03.11.2011 16:07]:
Hi Johannes,
On 03.11.2011 14:38, Johannes Meixner wrote:
Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)?
I'm pretty sure I had seen something like that on 11.4 or earlier when I had "print" in /etc/hosts and tried to access it as "print.domain". Adding all aliases of the server, including FQDNs to /etc/hosts made it work IIRC.
All print servers are in DNS with their FQDN, and the error came up on all clients that tried to contact the print servers via FQDN. As soon as they switched to using the short name, everything went well.
The DNS translates short name and FQDN to exactly the same address.
In my case it was the same. I needed to put them into /etc/hosts. I did not investigate it more deeply, just putting everything into /etc/hosts did work for me. I just wanted to spell out that this does not have to be a CUPS 1.5 issue, but that I had seen similar things in 1.4
BTW, if DNS could not resolve the FQDN, IMHO I'd never get "Bad request", but "Connection timed out" or "Server not found" :-(
This is not a DNS issue but has to do with who the cups server thinks he is, AFAICT. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stefan Seyfried [03.11.2011 16:52]:
On 03.11.2011 16:48, Werner Flamme wrote:
All print servers are in DNS with their FQDN, and the error came up on all clients that tried to contact the print servers via FQDN. As soon as they switched to using the short name, everything went well.
The DNS translates short name and FQDN to exactly the same address.
In my case it was the same. I needed to put them into /etc/hosts. I did not investigate it more deeply, just putting everything into /etc/hosts did work for me.
I just wanted to spell out that this does not have to be a CUPS 1.5 issue, but that I had seen similar things in 1.4
And I tried to say that in my case, everything went fine with the latest CUPS 1.4.6 in the Printing:SLE_11_SP1 repo. I never had problems with connecting to my CUPS servers. And the config wasn't changed by the update from 1.4.6 to 1.5.0.
BTW, if DNS could not resolve the FQDN, IMHO I'd never get "Bad request", but "Connection timed out" or "Server not found" :-(
This is not a DNS issue but has to do with who the cups server thinks he is, AFAICT.
Yes sir :-). And why would the CUPS server think it isn't the one specified as ServerName in cupsd.conf? Why do I enter a server name here? Of course this host name is written to /etc/hosts, with the correct IP address. Like 141.65.124.19 printlpz1l.intranet.ufz.de printlpz1l And the server responds when the URL starts with "http://141.65.124.19:631" or with "http://printlpz1l:631". But it does not respond when the URL starts with "http://printlpz1l.intranet.ufz.de:631" (same with "https://", same with "lpstat -h ... -a"). And the xinetd service cups-lpd works fine all the time... obviously (and luckily), there is no "spoof protection". Regards, Werner -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6zpcwACgkQk33Krq8b42NaaACeKEG2WlnhFRE5D8JyG6jJvbVU SPcAnjiVllPq6olJcVbQaDL5vhb0CQCa =vCWi -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, when an openSUSE user detects an issue in a free software package which is not caused by the openSUSE distribution efforts, then please you the openSUSE users out there show up at the matching free software upstream forum. E.g. for CUPS see http://www.cups.org/newsgroups.php for HPLIP see http://hplipopensource.com/hplip-web/support.html for Ghostscript see http://www.ghostscript.com/ for SANE see http://www.sane-project.org/ and so on... The Red Hat and Fedora users post there, the Ubuntu users post there. If you - the openSUSE users - do not show up at this or that free software upstream forum, the matching upstream authors can neither notice that you exist at all nor care about you. Alternatively if you pay SUSE for an appropriate support contract you could stay in the background and let those who you pay with your money do the job for you. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Meixner [03.11.2011 14:38]:
Hello,
On Nov 3 12:12 Werner Flamme wrote (excerpt):
finally I found a real bug! And a workaround...
In /etc/cups/cupsd.conf, I have lines like:
ServerName printlpz1l.intranet.ufz.de ServerAlias printlpz1l ServerAlias 141.65.124.19
Whenever I try to access <https://printlpz1l.intranet.ufz.de:631>, I get "Bad Request". But: I can access <https://printlpz1l:631> or <https://141.65.124.19:631> without problems.
lpstat -h printlpz1l.intranet.ufz.de -a - -> error
lpstat -h printlpz1l - -> long list
Five minutes ago, I added
ServerAlias printlpz1l.intranet.ufz.de
to /etc/cups/cupsd.conf and voilà - the host is accessible with its FQDN. Via web as well as via lpstat.
Obviously, CUPS allows access to the ServerAlias only, and refuses access to ServerName. In /var/log/cups/error_log I see lines like
Request from "141.65.31.19" using invalid Host: field "printlpz1l.intranet.ufz.de"
That's an interesting bug. They may have invested a lot of brain power for that :-) BTW, The entry after ServerName is the "real" hostname...
Yes, they invested a lot of brain power to protect you against DNS rebinding attacks which unfortunately results in some cases that you get "overprotected".
Is this really a new issue since CUPS 1.5.x (i.e. it worked with 1.4.6)?
Yes, it is. I did the update last week, and two hours later the Sun Ray admin asked why he could not access the printers any longer. And he discovered that it worked with the short name, but not with the FQDN. Before the upgrade, the last version from the Printing:SLE_11_SP1 repo was installed. BTW, the machines that still run CUPS 1.4.x answer on ServerAlias as well as on ServerName. Another BTW: cups-lpd worked well all the time, even on CUPS 1.5.0 boxes :-> That's why we were able to print from our SAP systems, I guess...
See for example the "cupsd no longer allows using cname (alias) must use hostname" mail thread on cups@easysw.com
The DNS entry is not a CNAME. This IP address is resolved directly, and the PTR record works as well. The host was installed with its IP Address and hostname, and neither did change. Why should it be that the FQDN works when used as a ServerAlias, but not as ServerName? If the "real" hostname was different from the ServerAlias entry, the ServerName requests should be honoured as well. There might be a reason for the ServerName directive to exist, and a reason to use it as well...
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22cupsd+no+longer+allow...
- -------------------------------------------------------------------------
From: Michael Sweet ... -------------------------------------------------------------------------
Well,
we have one ServerName entry and several (3 to 12) ServerAlias entries in cupsd.conf. The ServerName is always set to the name the server is used with most often.But there was never a necessity to have a ServerAlias saying the same name as ServerName - and the CUPS servers went all through the 1.4.x releases.
or see the "cups server not responds by alias name since cups-1.3.9" mail thread on cups@easysw.com
http://www.cups.org/newsgroups.php?gcups.general+T+Q%22cups+server+not+respo...
This
can't be us, since everything worked at least with 1.4.6 :-\
If your particular issue is a different case, please report it on cups@easysw.com
I think it is *sigh*
Kind Regards Johannes Meixner
Thank you, Werner - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6ytV8ACgkQk33Krq8b42MELACggzLuRLJA3R/A/Ptb+cLHkltG 7FAAn0VdgGR+JuKXjB14XL7aRb/YSRS3 =NcNp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (5)
-
Christian Boltz -
Johannes Meixner -
Jon Nelson -
Stefan Seyfried -
Werner Flamme