http://bugzilla.opensuse.org/show_bug.cgi?id=1178604
Bug ID: 1178604
Summary: cups cannot print to remote cups: Could not start IPP
Backend (/usr/lib/cups/backend/ipp): 13 Permission
denied
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: Printing
Assignee: jsmeix(a)suse.com
Reporter: luizluca(a)tre-sc.jus.br
QA Contact: jsmeix(a)suse.com
Found By: ---
Blocker: ---
Hello,
For some time with Tumbleweed and now also with Leap 15.2, I cannot print to a
remote cups server directly polled with:
cupsd-browsed.conf:
BrowsePoll remote.cups.server.addr
LocalQueueNamingRemoteCUPS RemoteName
All remote cups printers are network printers. If I add that remote printer as
a local printer (with remote uri), it works as expected.
I can list all remote printers correctly and I can print manually from my
machine using:
lp -h remote.cups.server.addr -d printername -t testjob a.txt
While this fails:
lp -d printername -t testjob a.txt
with:
Could not start IPP Backend (/usr/lib/cups/backend/ipp): 13 Permission denied
I used strace to follow the calls from cups until ipp and saw this:
[pid 29201] execve("/usr/lib/cups/daemon/cups-exec",
["/usr/lib/cups/daemon/cups-exec", "-g", "7", "-n", "0", "-u", "4", "none",
"/usr/lib/cups/filter/texttopdf", ..., "/var/spool/cups/d00109-001"])
[pid 29201] execve("/usr/lib/cups/filter/texttopdf", [...,
"/var/spool/cups/d00109-001"])
[pid 29202] execve("/usr/lib/cups/daemon/cups-exec",
["/usr/lib/cups/daemon/cups-exec", "-g", "7", "-n", "0", "-u", "4", "none",
"/usr/lib/cups/backend/implicitclass", "implicitclass://printername/", ...])
[pid 29202] execve("/usr/lib/cups/backend/implicitclass",
["implicitclass://printername/", ...])
[pid 29203] execve("/usr/lib/cups/filter/gziptoany",
["ipp://remote.cups.server.addr:631/printers/printername", ...,
"/var/spool/cups/tmp/072125faaaeab"])
[pid 29204] execve("/usr/lib/cups/backend/ipp",
["ipp://remote.cups.server.addr:631/printers/printername",
"/var/spool/cups/tmp/072125fab6733"])
So cups switch to user 4(lp) group 7(lp), calls implicitclass, which calls
gziptoany and ipp. However, ipp cannot be used by lp:
-rwxr-xr-x 1 root root 23096 ago 25 16:42 /usr/lib/cups/backend/implicitclass
-rwx------ 1 root root 84104 out 26 13:42 /usr/lib/cups/backend/ipp
-rwxr-xr-x 1 root root 14384 out 26 13:42 /usr/lib/cups/filter/gziptoany
If I change ipp owner to lp, printing works as expected.
As it might be a good reason for 0700 permission, I'll not guess the correct
solution.
Anyway, the fix needs to be backported to 15.2
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=899330
Bug ID: 899330
Summary: Interfaces does not automatically show up in firewall
with NetworkManager
Classification: openSUSE
Product: openSUSE Factory
Version: 201408*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: razirazo_90(a)live.com.my
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When using NetworkManager, network interfaces does not listed in firewall.
I have to manually configure it using Wicked Service first, to make it
registered in firewall. And then use networkManager back.
This is troublesome, for example when setting up internet sharing you can't
proceed to zone assign and Network masquerade until you do the step above.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1102737
Bug ID: 1102737
Summary: Install does not work on Pentium III machine
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: srid(a)rkmail.ru
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I tried installing Tumbleweed on my Tualatin machine, but it fails to get to
repository with following error:
OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE
Tried booting with fips=0, it does not help.
I guess libssl wants something like SSE2, NX-bit or some other feature this old
CPU lacks.
Is there some chance of working around that issue? I know you'll likely don't
want to bother with such an old hardware, but 'i586' in iso name
'openSUSE-Tumbleweed-NET-i586-Snapshot20180723-Media.iso' is a little bit
confusing.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1174439
Bug ID: 1174439
Summary: [HPC, gcc10] Add build support for gcc10 to HPC
Libraries
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: SUSE Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: eich(a)suse.com
Reporter: eich(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: Development
Blocker: ---
gcc10 is available for quite a while already. Add build support to the HPC
packages.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1080259
Bug ID: 1080259
Summary: HPC modules show wrong summary
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: cgoll(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Most of the HPC lmod modules show the wrong summary. E.g. for the package
openmpi-gnu-hpc thethe command
module spider
outputs
openmpi: openmpi/1.10.7
Dependency package for openmpi_1_10_7-gnu-hpc-devel-static
which is self refering and useless. It should be
"A powerful implementation of MPI"
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1058563
Bug ID: 1058563
Summary: hdf5 transient make check errors in TW ring2 for
ppc64le
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: PowerPC
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: normand(a)linux.vnet.ibm.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 740535
--> http://bugzilla.suse.com/attachment.cgi?id=740535&action=edit
hdf5 build failures 20170910
hdf5 transient make check errors in TW ring2 for ppc64le
On two successive hdf5 build output from OBS (1)
the log is reporting different failing tests (2)
If I try locally an osc co + osc build locally on two different KVM Host I am
not able to recreate the problem.
(1)
https://build.opensuse.org/package/show/openSUSE:Factory:Rings:2-TestDVD/hd…
(2)
=== Rings:2 on 20170910:
[ 2046s] Testing h5watch TEST.h5/DSET_TWO
*FAILED*
[ 2046s] Testing h5watch --fields=field1,field2 TEST.h5/DSET_CMPD
*FAILED*
[ 2046s] Testing h5watch --fields=field2.b.a,field2.c TEST.h5/DSET_CMPD_TWO
*FAILED*
=== Rings:2 on 20170912:
[ 2087s] Testing h5watch TEST.h5/DSET_ONE
*FAILED*
[ 2087s] Testing h5watch TEST.h5/DSET_TWO
*FAILED*
[ 2087s] Testing h5watch --fields=field2.b.a --fields=field2.c
TEST.h5/DSET_CMP*FAILED*
[ 2087s] *FAILED*
[ 2087s] Testing h5watch --fields=field2.b --fields=field4
TEST.h5/DSET_CMPD_TW*FAILED*
[ 2087s] Testing h5watch --fields=field2.b.a,field2.c TEST.h5/DSET_CMPD_TWO
*FAILED*
[ 2087s] Testing h5watch --dim TEST.h5/DSET_ONE
*FAILED*
[ 2087s] Testing h5watch --width=30 TEST.h5/DSET_TWO
*FAILED*
===
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1154616
Bug ID: 1154616
Summary: darktable: fix exporting of EXIF data to webp
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: dmitry.ashkadov(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Hello,
could you apply this change
https://github.com/darktable-org/darktable/commit/d18b81f2c0d42c68939632b56…
to darktable please? It should fix a problem when darktable does not save EXIF
information to webp format.
Exported to webp format file does not contain exif information.
Thank you.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1135030
Bug ID: 1135030
Summary: LTO: ceph build fails
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: martin.liska(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Fails here:
https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:…
due to:
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to
`rados_aio_create_completion'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to
`rados_create_with_context'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_version'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_create2'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to
`rados_nobjects_list_next'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_env'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_set'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_create'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_ioctx_create2'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_parse_argv'
[ 8864s]
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld:
../../../lib/librados.so.2.0.0: undefined reference to `rados_conf_read_file'
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1165780
Bug ID: 1165780
Summary: Reduce the number of PID1 reloading triggered by
btrfsmaintenance units
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: fbui(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Apparently when btrfsmaintenance package is installed, the number of PID1
reloading increases from 0 to 4.
Reloading PID1 is a quite expensive operation therefore it would be nice if
this number could be reduced at its minimum and thus helping improving the boot
process.
Please note that enabling or disabling a unit implies a reload of PID1. If a
batch of units needs to be enabled/disabled, it would be better to reload PID1
only at the end of the whole operation (see systemctl "--no-reload" option).
For the context: this has been noticed in bnc#1137373, where the batch of PID1
reloading triggered by btrfsmaintenance makes a systemd race easier to happen.
--
You are receiving this mail because:
You are on the CC list for the bug.