https://bugzilla.novell.com/show_bug.cgi?id=735865https://bugzilla.novell.com/show_bug.cgi?id=735865#c0
Summary: add BuildRequires: python-cups to printer driver
packages
Classification: openSUSE
Product: openSUSE 12.1
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Printing
AssignedTo: jsmeix(a)suse.com
ReportedBy: lnussel(a)suse.com
QAContact: jsmeix(a)suse.com
Found By: ---
Blocker: ---
all printer driver packages should have
BuildRequires: python-cups
python-cups installs special rpm macros that adds Provides tags for the printer
drivers supported by the package.
See gutenprint for an example how the resulting rpm looks like.
See also bug 735864
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915483
Bug ID: 915483
Summary: a2ps:/etc/a2ps.cfg:220: invalid option `variable:'
Classification: openSUSE
Product: openSUSE Factory
Version: 201501*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: gp(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 621418
--> http://bugzilla.suse.com/attachment.cgi?id=621418&action=edit
Patch that fixes the configuration file
Using a2ps on a simple text file, with a2ps-4.14-1.1.x86_64 I get
% a2ps -o x.ps x
a2ps:/etc/a2ps.cfg:220: invalid option `variable:'
% ll /etc/a2ps.cfg
-rw-r--r-- 1 root root 15964 Dez 16 17:42 /etc/a2ps.cfg
`rpm -V a2ps` indicates I have the vanilla version of that file,
and indeed I never changed anything.
This seems to be due to a spelling of "variable" (lowercase) vs
"Variable", and can be fixed as follows (see attached patch):
-variable: ghostview a2ps-open
+Variable: ghostview a2ps-open
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=917728
Bug ID: 917728
Summary: Obsolete/deprecated config option still enabled
Classification: openSUSE
Product: openSUSE Factory
Version: 201502*
Hardware: x86-64
OS: SUSE Other
Status: NEW
Severity: Enhancement
Priority: P5 - None
Component: Kernel
Assignee: kernel-maintainers(a)forge.provo.novell.com
Reporter: zaitor(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Hi Kernel people.
Just installed the spiffy new 3.19 kernel from Kernel:stable, and when going
through journald logs to see if there was something new and exciting I came
over these warnings that I've seen for ages, but never cared for since it seem
to do no harm.
linux-ial4:~ # uname -r
3.19.0-1.g8a7d5f9-desktop
linux-ial4:~ # journalctl -b | grep CONFIG_ACPI_PROCFS_POWER
feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is
loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for battery is
loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
feb. 13 00:27:50 linux-ial4 kernel: ACPI: Deprecated procfs I/F for AC is
loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
linux-ial4:~ #
----
But today I took the time to google it, and found this bug from Arch
https://bugs.archlinux.org/task/25845
Snip from bug
ACPI: Deprecated procfs I/F for battery is loaded, please retry with
CONFIG_ACPI_PROCFS_POWER cleared
This was scheduled for removal in 2.6.39, but is still there. I suggest trying
to disable it for 3.1, if for nothing else than to discover what problems this
might cause so the appropriate bug reports can be filed.
>From Documentation/feature-removal-schedule.txt:
What: CONFIG_ACPI_PROCFS_POWER
When: 2.6.39
Why: sysfs I/F for ACPI power devices, including AC and Battery, has been
working in upstream kernel since 2.6.24, Sep 2007. In 2.6.37, we make the sysfs
I/F always built in and this option disabled by default. Remove this option and
the ACPI power procfs interface in 2.6.39.
Who: Zhang Rui <rui.zhang(a)intel.com>
----
Short story this was disabled on Arch back in 2011
Could we do this for openSUSE too?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=790151https://bugzilla.novell.com/show_bug.cgi?id=790151#c0
Summary: When I open nickle-2.70-1.src.rpm,YaST2 finds nothing
to install.
Classification: openSUSE
Product: openSUSE 12.2
Version: Final
Platform: x86-64
URL: http://nickle.org/release/nickle-2.70-1.src.rpm
OS/Version: openSUSE 12.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: giecrilj(a)stegny.2a.pl
QAContact: jsrain(a)suse.com
CC: hrvoje.senjan(a)gmail.com
Depends on: 684610
Found By: Community User
Blocker: No
+++ This bug was initially created as a clone of Bug #684610 +++
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.0) Gecko/20100101
Firefox/4.0
When I open nickle-2.70-1.src.rpm, YaST2 does not install anything.
Reproducible: Always
Steps to Reproduce:
1. Tell Dolphin to open nickle-2.70-1.src.rpm [1].
Actual Results:
1. YaST2 finds nothing to be installed.
Expected Results:
1. Let YaST2 install the source package.
___
[1] <URL: http://nickle.org/release/nickle-2.70-1.src.rpm >
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=712025https://bugzilla.novell.com/show_bug.cgi?id=712025#c0
Summary: openssh helpers wrongly uses %_libdir
Classification: openSUSE
Product: openSUSE 12.1
Version: Factory
Platform: x86-64
OS/Version: Linux
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jengelh(a)medozas.de
QAContact: qa(a)suse.de
Found By: Beta-Customer
Blocker: ---
I had a openSUSE 11.4 i586 installation on one machine, and as I was upgrading
its hardware to a 64-bit CPU, I did a x86_64 reinstall, and copied over the
configs from the previous install. Among that was /etc/ssh/sshd_config.
After this, sftp was no longer usable ("Connection closed by host"), hinting
towards the helper not being executable. sshd_config, having been inherited
from a i586 environment, contained:
Subsystem sftp /usr/lib/ssh/sftp-server
However, the sftp helper was installed in /usr/lib64/ssh (%_libdir/ssh), which
I consider the wrong place, because the helper is bitness-independent and thus
should go to %_libexecdir/ssh instead.
The problem persists by looking at the current /network/openssh/openssh.spec.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=536564
Summary: Packages creating user accounts do not select UID
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: All
OS/Version: Linux
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jengelh(a)medozas.de
QAContact: qa(a)suse.de
Found By: Beta-Customer
Some packages, such as openssh, do explicitly specify a UID/GID when creating
its users/groups:
/usr/sbin/groupadd -g 65 -o -r sshd 2>/dev/null || :;
On the other hand, the hal package does not:
/usr/sbin/groupadd -r haldaemon 2>/dev/null || :
So, which is correct? Should not hal also use a fixed ID? There are many
packages belonging to the latter category.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=518238
Summary: openSSH chroot security settings faulty
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: x86
OS/Version: openSUSE 11.1
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: marcus(a)swedcore.net
QAContact: qa(a)suse.de
Found By: ---
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11)
Gecko/2009060200 SUSE/3.0.11-0.1.1 Firefox/3.0.11
Whenever i tried to setup a chroot environment with OpenSSH the security
settings for the user folder must be root or OpenSSH doesn't work, the only
solution for now is to either create subfolders in the users chroot folder
where the user can have write permissions or land them one step up in the
hierarchy and thus making them see other chroot folder which is not good.
I followed this Wiki page to the letter:
http://en.opensuse.org/Openssh#SFTP_chroot_with_ChrootDirectory
I have Swedish community users trying to set this up to with same result as me.
This thread takes up the same issue:
http://marc.info/?l=openssh-unix-dev&m=122640731518850&w=2
But the solution mentioned there is not acceptable because as it stats on the
Wiki you make one folder the chroot folder and then mapping the users home
folder relative to the chroot folder, in this scenario the users should get
write permissions to his own folder, but that is not possible, thus breaking
the functionality intended.
So the question is, is this a bug or is it designed to act like this?
Reproducible: Always
Steps to Reproduce:
Done accordingly to this wiki entry: http://en.opensuse.org/OpenSSH
Actual Results:
Gets a read only home folder root
Expected Results:
Getting a writable home folder, where they can create on folder and upload
files directly to the root of their home folder.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=788344https://bugzilla.novell.com/show_bug.cgi?id=788344#c0
Summary: Improving go-doc package wanted
Classification: openSUSE
Product: openSUSE 12.2
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: ke(a)suse.com
QAContact: qa-bugs(a)suse.de
CC: graham(a)andtech.eu, speilicke(a)suse.com
Found By: Development
Blocker: ---
The go-doc package is rather bewildered.
Many links do not work. Many files are included that do not make sense in a
doc package (e.g., Makefile or the emacs mode (go-mode.el) that comes with a
different package).
Les is more. Please ship only those parts that are nicely interlinked via HTML
cross-references.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=735320https://bugzilla.novell.com/show_bug.cgi?id=735320#c0
Summary: go: %{go_make_install} breaks Make.cmd builds
Classification: openSUSE
Product: openSUSE 12.1
Version: Final
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: dmacvicar(a)suse.com
QAContact: qa(a)suse.de
CC: graham(a)andtech.eu, speilicke(a)suse.com
Found By: ---
Blocker: ---
If you build a go binary (not a package) you include Make.cmd instead of
Make.pkg.
Make.pkg installs in TARGDIR, which is set by the macro: %{go_make_install} to
TARGDIR=%{buildroot}%{go_sitearch}
This is right, as Make.pkg sets it as default to
$(GOROOT)/pkg/$(GOOS)_$(GOARCH)
But if you build a command, Make.cmd uses $GOBIN (/usr/bin), but it gets
overriden by %{go_make_install} resulting in the binary to be installed in the
package directory.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.