http://bugzilla.opensuse.org/show_bug.cgi?id=1185952
Bug ID: 1185952
Summary: [Build 20210510] PostgreSQL is not startable on s390x
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: S/390-64
URL: https://openqa.opensuse.org/tests/1734657/modules/post
gresql_server/steps/6
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: screening-team-bugs(a)suse.de
Reporter: ada.lovelace(a)gmx.de
QA Contact: qa-bugs(a)suse.de
Found By: openQA
Blocker: Yes
## Observation
openQA test in scenario
opensuse-Tumbleweed-DVD-s390x-textmode@s390x-zVM-vswitch-l2 fails in
[postgresql_server](https://openqa.opensuse.org/tests/1734657/modules/postgr…
All packages can be installed. The problem is that the PostgreSQL server can
not be started. The journal log is saying:
-- Logs begin at Mon 2021-05-10 22:41:06 EDT, end at Mon 2021-05-10 23:23:02
EDT. --
May 10 23:15:15 susetest systemd[1]: Starting PostgreSQL database server...
May 10 23:15:15 susetest systemd[1]: postgresql.service: Control process
exited, code=exited, status=1/FAILURE
May 10 23:15:15 susetest systemd[1]: postgresql.service: Failed with result
'exit-code'.
May 10 23:15:15 susetest systemd[1]: Failed to start PostgreSQL database
server.
May 10 23:15:15 susetest postgresql-script[12832]: Cannot find an active
PostgreSQL server binary. Please install one of the PostgreSQL
May 10 23:15:15 susetest postgresql-script[12832]: server packages or activate
an already installed version using update-alternatives.
## Test suite description
Maintainer: QE Yast
Installation in textmode and selecting the textmode "desktop" during
installation.
## Reproducible
Fails since (at least) Build
[20210510](https://openqa.opensuse.org/tests/1734657) (current job)
## Expected result
Last good: [20210507](https://openqa.opensuse.org/tests/1731697) (or more
recent)
## Further details
Always latest result in this scenario:
[latest](https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse…
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1100677
Bug ID: 1100677
Summary: trackerbug: packages do not build reproducibly from
compile-time CPU-detection
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: openSUSE Factory
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: bwiedemann(a)suse.com
Reporter: bwiedemann(a)suse.com
QA Contact: qa-bugs(a)suse.de
Depends on: 1100520
Blocks: 1081754
Found By: Development
Blocker: ---
e.g. bug 1100520
compiler options -march=native and -mtune=native
make the resulting machine code depend on the build system's CPU
which breaks reproducible builds.
affects at least: glucat form python-annoy legion trigger-rally
This is already fixed in: clpeak higan kyotocabinet
one common approach seems to do
sed -i "s|-march=native||g" $FILE
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1159231
Bug ID: 1159231
Summary: tesseract-ocr builds with march=native
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: All
OS: openSUSE Factory
Status: NEW
Severity: Major
Priority: P5 - None
Component: Development
Assignee: idonmez(a)suse.com
Reporter: bwiedemann(a)suse.com
QA Contact: qa-bugs(a)suse.de
CC: hiwatari.seiji(a)gmail.com
Found By: Development
Blocker: ---
While working on reproducible builds for openSUSE, I found that
the tesseract-ocr package binary varies depending on build machine CPU.
This is a bug that can cause crashes on machines older that the random build
machine.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1184786
Bug ID: 1184786
Summary: Deduplicate directory ownership with filesystem
package
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: dmueller(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Hi,
checksec pointed out that various directories in our /usr are 0755 while
they're 0555 on Fedora and Red Hat. For more hardened environments this might
make a difference, as it prevents a user "root" that doesn't have DAC_OVERRIDE
permission to no longer write/create files there.
In order to achieve that, only one package need to own the permissions of that
directory. currently we have various packages co-owning it, which means actual
permission would depend on installation order, and we'd get installation
conflicts.
This can be prevented by de-duplicating directory ownership. this is a tracker
bug that tracks the work related to it.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1191381
Bug ID: 1191381
Summary: gnu-compilers-hpc: Move rpm macros to %_rpmmacrodir
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: eich(a)suse.com
Reporter: lnussel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Blocks: 1191379
Found By: ---
Blocker: ---
rpm macros aren't config files for the administrator, as such they
should be installed into %_rpmmacrodir (ie /usr/lib/rpm/macros.d)
instead of /etc/rpm.
Please consider adjusting gnu-compilers-hpc
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1175587
Bug ID: 1175587
Summary: windows:mingw:win{32|64}/mingw{32|64}-filesystem:
Deprecated external dependency generator is used
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: 3rd party software
Assignee: fstrba(a)suse.com
Reporter: ralf.habacker(a)freenet.de
QA Contact: screening-team-bugs(a)suse.de
CC: fridrich.strba(a)bluewin.ch, hib(a)hiberis.nl,
idonmez(a)suse.com, mkbosmans(a)gmail.com
Found By: ---
Blocker: ---
On building packages there is always a message printed that a 'Deprecated
external dependency generator is used'.
The reason for this message is located in macros.mingw32
(https://build.opensuse.org/package/view_file/windows:mingw:win32/mingw32-fi…)
%_mingw32_package_header \
%global __strip %{_mingw32_strip} \
%global __objdump %{_mingw32_objdump} \
%global _use_internal_dependency_generator 0 \
%global __find_requires %{_mingw32_findrequires} \
%global __find_provides %{_mingw32_findprovides} \
%global __os_install_post %{_mingw32_install_post}
by specifing '_use_internal_dependency_generator 0' and overriding the
__find_requires and __find_provides.
Recent obs dependency support uses *.attr file as shown below:
cat /usr/lib/rpm/fileattrs/cmake.attr
%__cmake_provides %{_rpmconfigdir}/cmake.prov
%__cmake_path
^/usr/lib(64)?/cmake/.*/.*(Config\.cmake|-config\.cmake)
where the mentioned file cmake.prov does the work of generating a list of
packages that are provided by cmake configuration files.
Similar files exists for debuginfo
cat /usr/lib/rpm/fileattrs/debuginfo.attr
%__debuginfo_provides %{_rpmconfigdir}/debuginfo.prov
%__debuginfo_path ^/usr/lib/debug/
for pkgconfig files
cat /usr/lib/rpm/fileattrs/pkgconfig.attr
%__pkgconfig_provides %{_rpmconfigdir}/pkgconfigdeps.sh --provides
%__pkgconfig_requires %{_rpmconfigdir}/pkgconfigdeps.sh --requires
%__pkgconfig_path
^((%{_libdir}|%{_datadir})/pkgconfig/.*\.pc|%{_bindir}/pkg-config)$
for executables
cat /usr/lib/rpm/fileattrs/elf.attr
%__elf_provides %{_rpmconfigdir}/elfdeps --provides
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elf_requires %{_rpmconfigdir}/elfdeps --requires
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elf_magic ^(setuid,? )?(setgid,? )?(sticky )?ELF
(32|64)-bit.*executable
%__elf_flags exeonly
%__elf_exclude_path ^/usr/lib/debug/
for shared libraries
cat /usr/lib/rpm/fileattrs/elflib.attr
%__elflib_provides %{_rpmconfigdir}/elfdeps --assume-exec --provides
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elflib_requires %{_rpmconfigdir}/elfdeps --assume-exec --requires
%{?__filter_GLIBC_PRIVATE:--filter-private}
%__elflib_magic ^(setuid )?(setgid )?(sticky )?ELF (32|64)-bit.*shared
object
%__elflib_exclude_path ^/usr/lib/debug/
and others.
To take advantage of this type of support, the currently used files
mingw32-find-provides.sh and mingw32-find-requres.sh must be split into
implementations that handle a single category of corresponding files.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166537
Bug ID: 1166537
Summary: osc rq accept - forwarding request causes backtrace
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Development
Assignee: marco.strigl(a)suse.com
Reporter: suse-beta(a)cboltz.de
QA Contact: qa-bugs(a)suse.de
CC: suse-tux(a)gmx.de
Found By: ---
Blocker: ---
When accepting a SR to a devel project, osc asks if I want to forward the SR to
Factory. I answered "y", but got this nice backtrace instead of a SR to
Factory:
# osc rq accept 784420
Result of change request state: ok
openSUSE:Factory
Forward this submit to it? ([y]/n)y
Traceback (most recent call last):
File "/usr/bin/osc", line 41, in <module>
r = babysitter.run(osccli)
File "/usr/lib/python3.8/site-packages/osc/babysitter.py", line 64, in run
return prg.main(argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 344, in main
return self.cmd(args)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 367, in cmd
retval = self.onecmd(argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 501, in onecmd
return self._dispatch_cmd(handler, argv)
File "/usr/lib/python3.8/site-packages/osc/cmdln.py", line 1232, in
_dispatch_cmd
return handler(argv[0], opts, *args)
File "/usr/lib/python3.8/site-packages/osc/commandline.py", line 2652, in
do_request
project, package, html.escape(msg, quote=False))
NameError: name 'html' is not defined
Wild guess: missing "import html"?
Note: commandline.py has an "import html" in do_submitrequest(), but this
import isn't visible to do_request(). Also note that there are more functions
in this file that call html.escape() without importing html before and will
probably break in a similar way. Doing the "import html" in the file header
instead of inside the functions might be a good idea.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1176566
Bug ID: 1176566
Summary: Installing ignition leads to unbootable system
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: MicroOS
Assignee: kubic-bugs(a)opensuse.org
Reporter: rombert(a)apache.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I've installed ignition locally on Tumbleweed, to be able to validate ignition
files locally. After a reboot I was presented with an emergency shell, leading
down a wild goose chase for disabling ignition permanently.
It all went away after setting up a chroot and removing all traces of ignition,
but it would be much much better if installing it would not lead to a broken
system by default.
I saw some errors related to the ignition generator, and the systemd unit file
was broken, but could not save any logs unfortunately. But it should be easy
enough to reproduce if anyone cares:
# zypper in ignition
# reboot
(Might be related to #1172592)
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1189826
Bug ID: 1189826
Summary: Severe screen flickering with kernel 5.13.12-1-default
and i915
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Tumbleweed
Status: NEW
Severity: Major
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: javier(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
My laptop's screen flickers so much with 5.13.12 that it renders my laptop
unusable.
One workaround is to close and open the lid. After resuming, it works fine -
there is no flickering.
Booting up from the KDE Live image works fine. I have used the same Tumbleweed
version (20210820) as the one I have installed on my laptop. The only
difference is that I have an encrypted /home partition on my laptop's SSD.
Tested kernels:
5.10.16-1.3: OK
5.11.4-1.3: NON-OK
5.12.12-1: NON-OK
5.13.12-1: NON-OK
KDE Plasma 5.22.4
KDE Frameworks 5.85.0
Qt 5.15.2
See the attachments for more details.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1084017
Bug ID: 1084017
Summary: YaST in Leap 15 fails to set boot flags correctly
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: x86-64
OS: Other
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: Larry.Finger(a)lwfinger.net
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Created attachment 762755
--> http://bugzilla.suse.com/attachment.cgi?id=762755&action=edit
Compressed YaST2 logs
My system has a GPT partitioning scheme and does not use EFI. I also put the
boot block at the start of the active partition, and have generic boot code in
the MBR. The active partition is indicated with the legacy_boot flag.
A partial df for the system is:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 60213124 9954072 47170668 18% /
/dev/sda6 53826316 32795236 20576144 62% /var/tmp
/dev/sda7 51255784 20631016 28050216 43% /TW
/dev/sda4 60344404 22760752 36522788 39% /Leap42.3
/dev/sda5 711705020 393141448 282387980 59% /home
tmpfs 809360 20 809340 1% /run/user/1000
Looking at the partitions with parted:
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA Samsung SSD 850 (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 1049kB 9437kB 8389kB bios_grub
2 9437kB 16.8GB 16.8GB linux-swap(v1) swap
3 16.8GB 79.7GB 62.9GB ext4
4 79.7GB 143GB 62.9GB ext4 msftdata
5 143GB 883GB 741GB ext4 msftdata
6 883GB 939GB 56.1GB ext4 msftdata
8 939GB 971GB 31.5GB ext4
7 971GB 1024GB 53.5GB ext4 legacy_boot, msftdata
(parted) quit
In this case, partition number 7 will be booted. Running YaST => System => Boot
Loader changes nothing. If I want the automatic boot to choose Leap 15.0, I
need to manually toggle the legacy_boot flag on partitions 7 and 3.
Attached is a compressed copy of the /var/log/YaST2/ directory.
--
You are receiving this mail because:
You are on the CC list for the bug.