-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Nelson [06.10.2011 16:26]:

On Thu, Oct 6, 2011 at 9:08 AM, Werner Flamme 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

-----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

-----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 -l | grep -i duplex

You may run "lpoptions -p -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

-----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

-----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

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

On Thu, Nov 3, 2011 at 8:38 AM, Johannes Meixner 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

On Thu, Nov 3, 2011 at 9:16 AM, Johannes Meixner 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

-----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

-----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

-----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