http://bugzilla.opensuse.org/show_bug.cgi?id=1047218
Bug ID: 1047218
Summary: trackerbug: packages do not build reproducibly from
including build time
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: SUSE Other
Status: CONFIRMED
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bwiedemann(a)suse.com
Reporter: bwiedemann(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: Development
Blocker: ---
See also https://reproducible-builds.org/
and https://reproducible-builds.org/specs/source-date-epoch/
When packages include the current time of build
it results in binaries that differ on every build
and thus trigger rebuilds of depending packages
and are published to mirrors and users
when actually nothing really changed.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1131931
Bug ID: 1131931
Summary: OCFS2: Defragmentation error: No space left on device
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: High Availability
Assignee: ha-bugs(a)suse.de
Reporter: weikai.wang(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 802412
--> http://bugzilla.suse.com/attachment.cgi?id=802412&action=edit
this script is used to generate disk framentation
when I used the defragfs.ocfs2 to clean up disk fragmentation that generated by
the attached shell script.
you could execute the scrip by command "./defragfs_test.sh -d DEVICE -m
MOUNT_POINT -n CLUSTER_NAME -s pcmk -o /tmp"
You should use the device on your cluster replace DEVICE, use the same way
replace MOUNT_POINT and CLUSTER_NAME.
Then use the command defragfs.ocfs2 MOUNT_POINT. And if no accident, you will
see some message like this:
“
defragfs.ocfs2 1.8.5
[1/201]/mnt/ocfs2/tmp_file:Success [ERROR]Move extent
failed:"/mnt/ocfs2/test_from_dd1" - No space left on device
[2/201]/mnt/ocfs2/test_from_dd1:Failed [ERROR]Move extent
failed:"/mnt/ocfs2/test_from_dd2" - No space left on device
[3/201]/mnt/ocfs2/test_from_dd2:Failed [ERROR]Move extent
failed:"/mnt/ocfs2/test_from_dd3" - No space left on device
”
but if you execute defragfs.ocfs2 MOUNT_POINT again, the error message will not
show again. and all the defragmentation will pass.
please make sure your device's capacity is more tha 1G.
Some times this error can make mount, unmount, and mkfs crushed.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1155207
Bug ID: 1155207
Summary: systemctl command line completion is very slow
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: carlos.e.r(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
systemctl command line completion is very slow
Suppose I type:
systemctl status smart[tab][tab]
and I get nothing. One second, two seconds... so I insist and hit tab several
times, and after several seconds I get (one line per second):
Isengard:~ # systemctl status smart
smartcard.target smartd.service smartd_generate_opts.path
smartd_generate_opts.service
Isengard:~ # systemctl status smart
smartcard.target smartd.service smartd_generate_opts.path
smartd_generate_opts.service
Isengard:~ # systemctl status smart
smartcard.target smartd.service smartd_generate_opts.path
smartd_generate_opts.service
Isengard:~ # systemctl status smart
and then I can type "d" and enter.
Why is it that slow? It is an M2 disk. ie, SSD technology. It responds
instantly when completing a normal command:
Isengard:~ # smart
smart_agetty smartctl smartd
Isengard:~ # smart
And that system is not busy at all, load 0.20. I can replicate the issue on
other machines, and has been so probably for a year or so. Google "systemctl
completion slow" finds reports on other distributions and several media.
<https://bugzilla.redhat.com/show_bug.cgi?id=1491668>
<https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1471723>
and:
<https://github.com/systemd/systemd/issues/7185>
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1126900
Bug ID: 1126900
Summary: health-checker: grub2-editenv: error: cannot open
`/boot/grub2/grubenv': Read-only file system.
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kubic
Assignee: iforster(a)suse.com
Reporter: kukuk(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
>From a health-checker run:
Clearing GRUB flag
+ grub2-editenv - set health_checker_flag=0
grub2-editenv: error: cannot open `/boot/grub2/grubenv': Read-only file system.
Starting health check
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1146936
Bug ID: 1146936
Summary: nmcli-examples: add examples of bonding + vlan +
bridge
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: william.brown(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Configuring a bond + vlan + bridge is not completely straightforward or clear
with nmcli. An example should be added such as:
nmcli conn add type bond con-name bond0 ifname bond0 mode 802.3ad ipv4.method
disabled ipv6.method ignore
nmcli connection add type ethernet con-name bond0-eth1 ifname eth1 master bond0
slave-type bond
nmcli connection add type ethernet con-name bond0-eth2 ifname eth2 master bond0
slave-type bond
nmcli connection add type bridge con-name net_18 ifname net_18 ipv4.method
disabled ipv6.method ignore
nmcli connection add type vlan con-name bond0.18 ifname bond0.18 dev bond0 id
18 master net_18 slave-type bridge
This is suitable for libvirt/vms to use the bridges.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1088738
Bug ID: 1088738
Summary: xhost setting fails to have affect in
/etc/gdm/Xsession --- "no protocol specified"
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: GNOME
Assignee: bnc-team-gnome(a)forge.provo.novell.com
Reporter: noah(a)chromakey.io
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
line 154 xhost+ si:localuser ... needs to be in
/etc/X11/xinit/xinitrc.d/what-ever.sh ...
... or maybe somewhere else all I know is that in Xsession it fails to have any
affect ... effectively breaking the X11 gnome access for remote logins/ssh/etc.
I'd expect a lot of bug reports of people angry, confused .. and complaining
about "no protocol specified" errors.
Thanks!
-noah
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1157881
Bug ID: 1157881
Summary: mount.nfs improve error reporting: "Connection
*WHERE*TO* timed out"
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: Other
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Network
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: 7eggert(a)gmx.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
When one of the nfs mounts times out, it gets reported as "Connection timed
out".
This is semi-helpful and thus semi-qualifies as a bug as well as a feature
request. Please forward this to upstream.
(Also not being able to mount triggers a bug in systemd to unmount unrelated
mounts. One of my nfs servers is currently unresponsive but the other servers
do work, yet systemd unmounts several other mounts. mount.nfs not reporting the
cause didn't help me to find the cause.)
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1127591
Bug ID: 1127591
Summary: zypper option "ssl_capath" not working for mirror URLs
from metalink file
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: x86-64
OS: SUSE Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: libzypp
Assignee: zypp-maintainers(a)forge.provo.novell.com
Reporter: cunix(a)bitmessage.ch
QA Contact: qa-bugs(a)suse.de
CC: security-team(a)suse.de
Found By: ---
Blocker: ---
Using zypper (version: 1.14.12) for the update repository of openSUSE Leap
15.0 with the option
baseurl=https://download.opensuse.org/update/leap/15.0/oss/?proxy=127.0.0.1…
does not use the here configured trusted root certificates for mirror URLs,
probably retrieved from a metalink file.
The configured path is used for the initial connection to download.opensuse.org
but following requests to mirrors seem to fallback to the system trusted certs
from /etc/ssl/certs.
If the mirrors' root CA is trusted in
"ssl_capath=/path/to/directory/with/c_rehash/rootCAs" but not in
/etc/ssl/certs, zypper,libzypp, multi-curl or something else aborts the
TLS-Handshake with failure "Unknown CA (48)" and falls futher back to http
(without transport layer encryption).
Question for cc'ed security-team to answer:
If using clear text is considered a security flaw where zypper is configured to
use (https-)encryption, this might have security implications.
Some Scenarios:
Assume download.opensuse.org is signed by CA A
and the mirror by CA B
Assume further,
ssl_capath=/path/to/directory/with/c_rehash/rootCAs
is directory C
and directory D is
/etc/ssl/certs
1.
If C includes A and B and in D at least B is not available, I would expect
zypper to encrypt both connection, but the request to the mirror is not.
2.
If A is not in C, no data (meta link file) is retrieved and therefore no mirror
is connected - Good!
No fallback of looking for A in D occurs.
3.
If A is in C and B in D, both connections are encrypted.
4.
If A is in C and B not in C and not in D, the mirror is contacted unencrypted -
here I'm unsure if using plain text in this scenario is correct or if it should
fail.
So, in my opinion, 1. is the bug, 3. a workaround and 4. perhaps needs a zypper
option to configure, if clear text fallback should be allowed.
Another question is, if /etc/ssl/certs should actually be consulted when the
option "ssl_capath" is used and pointing to a different directory.
https://bugzilla.opensuse.org/show_bug.cgi?id=933839
might be related (similar setup).
Problem and solution might be similar, too.
By the way, is there a debugging option to dump the traffic from inside the
encrypted connection?
Especially being able to read the metalink file with the listed mirrors is of
interest.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1051881
Bug ID: 1051881
Summary: clang can't find libc.so with -m32
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: ---
Running:
$ clang --version
clang version 4.0.1 (tags/RELEASE_401/final 305264)
$ cat a.c
int main() {}
$ clang -m32 a.c
/usr/bin/ld: skipping incompatible
/usr/bin/../lib64/gcc/x86_64-suse-linux/7/../../../libc.so when searching for
-lc
/lib/libc.so.6: error adding symbols: File format not recognized
clang-4.0.1: error: linker command failed with exit code 1 (use -v to see
invocation)
I've noticed we have openSUSE specific patches:
https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/clang-r…https://build.opensuse.org/package/view_file/openSUSE:Factory/llvm4/assume-…
But it does not work properly with -m32. Note the code in DetectDistro.cpp
checks for /etc/SuSE-release, which is legacy. One should use /etc/os-release.
I can fix that after we resolve this issue.
Thanks,
Martin
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1133084
Bug ID: 1133084
Summary: [META] GCC + LTO package failures
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: ---
Meta issue that will track all packages that fail with enabled Link Time
Optimization (LTO). For more detail description, please see:
https://en.opensuse.org/openSUSE:LTO
--
You are receiving this mail because:
You are on the CC list for the bug.