http://bugzilla.opensuse.org/show_bug.cgi?id=966255
Bug ID: 966255
Summary: System does not boot
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: 2015*
Hardware: Other
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Bootloader
Assignee: jsrain(a)suse.com
Reporter: rjschwei(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
kernel 4.4.0.3
Has encrypted user partition. Hangs at
Ignoring BGRT: Invalid version 0 (expected 1)
This appears to happen right before the point where I would expect to enter my
passphrase.
--
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.
https://bugzilla.novell.com/show_bug.cgi?id=796918https://bugzilla.novell.com/show_bug.cgi?id=796918#c0
Summary: obs-service-source_validator continues after failing
to create TMPDIR
Classification: openSUSE
Product: openSUSE Factory
Version: 12.3 Milestone 1
Platform: Other
OS/Version: openSUSE 12.2
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Development
AssignedTo: ro(a)suse.com
ReportedBy: suse-beta(a)cboltz.de
QAContact: qa-bugs(a)suse.de
Found By: Beta-Customer
Blocker: ---
Created an attachment (id=519068)
--> (http://bugzilla.novell.com/attachment.cgi?id=519068)
patch for
/usr/lib/obs/service/source_validators/20-files-present-and-referenced
(copy&paste from a mail I'll send to opensuse-factory in a minute)
Am Samstag, 5. Januar 2013 schrieb Jan Engelhardt:
> First a full disk, now /tmp* is gone? :)
It's still a full disk ;-)
> ---------- Forwarded message ----------
> Subject: [obs submit-request 146816] openSUSE:Factory/canutils:
> declined by factory-auto
>
> Comment:
> Output of check script:
> Source validator failed. Try "osc service localrun source_validator"
> mktemp: failed to create directory via template
> `/var/tmp/check_if_valid_source_dir-7SUGOd': No space left on device
^^^^^^^^^^^^^^^^^^^^^^^
mktemp failed because of a full disk.
> /work/cd/lib/source_validators/20-files-present-and-referenced: line
> 108: /tmp.spec: Permission denied
Oh, how nice. The script continues with an empty $TMPDIR variable.
Using
mktemp -d ... || exit 1
would be a very good idea ;-)
Please apply the attached patch ;-)
--
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=726712https://bugzilla.novell.com/show_bug.cgi?id=726712#c0
Summary: x11-ssh-askpass is in /usr/lib regardless of
architecture
Classification: openSUSE
Product: openSUSE 12.1
Version: Factory
Platform: Other
OS/Version: SuSE Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: jeffm(a)suse.com
QAContact: qa(a)suse.de
Found By: Development
Blocker: ---
jeffm@jetfire:~> /usr/lib/ssh/ssh-askpass
/usr/lib/ssh/ssh-askpass: line 36: /usr/lib64/ssh/x11-ssh-askpass: No such file
or 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.
https://bugzilla.novell.com/show_bug.cgi?id=712683https://bugzilla.novell.com/show_bug.cgi?id=712683#c0
Summary: disable ipv6 break ssh X11 tunnel
Classification: openSUSE
Product: openSUSE 12.1
Version: Milestone 3
Platform: All
OS/Version: SuSE Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
AssignedTo: bnc-team-screening(a)forge.provo.novell.com
ReportedBy: diego.ercolani(a)gmail.com
QAContact: qa(a)suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20100101
Firefox/5.0
When you disable ipv6 from the yast2 network, system correctly remove the
assignation of ipv6 addresses from everywhere but there is an annoying bug in
openssh that break the possibility to make X11 tunnels because it seems that
ssh try to bind X11 tunnel to an ipv6 address even with ipv6 disabled causing
this kind of message in /var/log/messages:
Aug 17 16:47:28 franz2011 sshd[6300]: error: Failed to allocate internet-domain
X11 display socket.
this can avoided configuring correctly the file /etc/ssh/sshd_config with the
parameter:
AddressFamily inet
and restarting sshd.
This is done in according to this bug reported to debian bugsystem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422327#20
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
--
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.