http://bugzilla.opensuse.org/show_bug.cgi?id=971006
Bug ID: 971006
Summary: rpmlint: no-dependency-on perl-base 5.22.1
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: 2015*
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: dimstar(a)opensuse.org
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
rpmlint does not understand how openSUSE specifies perl dependencies and falsly
reports:
no-dependency-on perl-base 5.22.1
in openSUSE, we use the macro
%perl_requires
which translates to:
Requires: perl(:MODULE_COMPAT_5.22.1)
It would be great to get this recognized as dependency being satisfied
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1008674
Bug ID: 1008674
Summary: Login difficulties with LightDM 1.20
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: SUSE Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: Markus.Elfring(a)web.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Today I dared to update the display manager to the version “LightDM
1.20.0-1.1”.
Unfortunately, I observed that the corresponding graphical login did not work
as expected. The information “exist status: 1” was recorded in the systemd
journal.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=920901
Bug ID: 920901
Summary: USB mouse disconnects every 60 seconds without X
Classification: openSUSE
Product: openSUSE 13.1
Version: Final
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-maintainers(a)forge.provo.novell.com
Reporter: oneukum(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Some mice need X to run or will disconnects and reconnect every 60 seconds. The
fix is a new quirk to always poll.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=993401
Bug ID: 993401
Summary: grub2-install for EFI installs an EFI entry that is
not bootable
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 42.1
Hardware: aarch64
OS: openSUSE 42.1
Status: NEW
Severity: Minor
Priority: P5 - None
Component: Bootloader
Assignee: jsrain(a)suse.com
Reporter: alan(a)softiron.co.uk
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Running grub2-install does not yield a bootable entry in EFI's boot menu. On
Leap and Tumbleweed, this means booting relies instead on the startup.nsh in
the EFI partition.
This occurs on Aarch64 with both AMD/AMI firmware and
Tianocore/edk2/OpenPlatformPkg firmware.
Steps to reproduce:
1. Install Leap 42.1 from the OEM image
2. Restart and boot the system
2a. Observe that the startup.nsh (in the EFI partition) is used to boot the
system.
3. Reboot again, but During boot-up, enter the EFI menu.
3a. Observe that in the boot manager in the EFI menus, there is no entry for
Leap.
4. Restart the system or select the UEFI shell option, booting from startup.nsh
5. From the command prompt in Leap, run:
grub2-install /dev/sda
6. Reboot the system
7. During start-up enter the EFI menu.
7a. Observe that in the EFI menu there is an entry called
opensuse-leap42.1-arm-jeos-devel-efi, or something like it.
8. Select the opensuse-leap* boot menu item and try to boot it.
9. Observe that it does not boot, and returns to the boot menu.
10. Select the UEFI Shell option, and observe that it will boot using
startup.nsh.
11. From the Linux command prompt, run "efibootmgr -v"
11a. Observe that the entry for opensuse-leap* is truncated :(
11b. Note the same can be observed by running "dumpstore" from the EFI
environment.
Note: The same thing happens if the bootloader is re-installed using "yast2
bootloader".
Note that this is broken in Leap, but works fine in SLES, probably because the
path and OS name for SLES is so much shorter.
Interestingly, if I try to add my own entry with the proper path:
efibootmgr -c -d /dev/sda -p 1 --loader
"EFI\\opensuse-leap42.1-arm-jeos-devel-efi\\grubarm64.efi" -L
Test_Entry_By_Alan
and then inspect it with:
efibootmgr -v
I see my entry is truncated too :(
Boot0007* Test_Entry_By_Alan
HD(1,800,64004,cb3a713f-f051-4c9c-b643-b9e1358f6c2d)File(EFI\opensuse-leap42.1-arm-jeos-devel-ef)
In summary, grub2-install and/or efibootmgr is simply putting a boot entry into
NVRAM that is truncated and not valid.
Thanks!
Alan.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1012825
Bug ID: 1012825
Summary: YaST2 hung "retrieving cracklib-dict-full.rpm
extension" if rpm passed in DUD
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: PowerPC-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: normand(a)linux.vnet.ibm.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Created attachment 704263
--> http://bugzilla.suse.com/attachment.cgi?id=704263&action=edit
installation_overview-y2logs.tar.bz2
YaST2 hung "retrieving cracklib-dict-full.rpm extension"
while investigating bug https://bugzilla.suse.com/show_bug.cgi?id=1009472
I tried to pass a DUD=*dud containing the rpm*.rpm
The consequence is that YaST2 hungs at "retrieving cracklib-dict-full.rpm
extension"
The y2log ends is stuck at Calling: extend,
note that there is no /var/log/extend in reported tarball
and no trace of extend in /var/log/linuxrc.log
steps:
===
$mkdud -c /tmp/boo1009472.dud --install instsys --force -d 20161122
/tmp/powerpc-utils-1.3.2-9.ppc64le.rpm /tmp/rpm-4.12.0.1-0.ppc64le.rpm
===
/var/lib/openqa/script/client jobs post
ISO=openSUSE-Tumbleweed-DVD-ppc64le-Snapshot20161122-Media.iso ARCH=ppc64le
BUILD=20161122 DESKTOP=minimalx DISTRI=opensuse DVD=1 FLAVOR=DVD HDDSIZEGB=40
MACHINE=ppc64le-multipath MULTIPATH=1 OFW=1 QEMU=ppc64 QEMUCPU=host QEMUCPUS=8
QEMURAM=4096 QEMUTHREADS=8 TEST=install_minimalx VERSION=Tumbleweed
Test=install_minimalx VGA=std WORKER_CLASS=qemu_ppc64le
DUD=http://stade.lab.toulouse-stg.fr.ibm.com/~normand/boo1009472.dud
=== extract y2log
install(8235) [Ruby] modules/InstExtensionImage.rb:386 Calling: extend
'cracklib-dict-full.rpm'
===
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=973590
Bug ID: 973590
Summary: weird layout of bootloader screen
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: dmueller(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
While updating the openQA needle for openSUSE on AArch64 people noted that the
"indentation" of the items in the ncurses ui looks slightly awkward.
Is it intended that there is this huge empty space at the top left corner?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=958483
Bug ID: 958483
Summary: 3rd party application UI is not behaving as required
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: 2015*
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: tchvatal(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
When using 3rd party module (like Virtualization) that tries to install
additional packages it at this moment works like this when you are in X
environment:
For each package there is pop-up showing progress and then this pop-up is
closed.
This causes severe issue if user runs compoziting enabled environment.
Imagine it like disco-bulb turning on and off as only on-top window is supposed
to be rendered right and all the underlying windows are greyed out.
More apps you install the more "funky" blinking you get.
Prefferable solution would be to somehow include the yast2 sw_single interface
that has the bottom progressbar and prints the installed packages.
Added value would be mostly for openSUSE, where the default DE's have enabled
compositing, but also for SLE case it would get at minimal prettier and at best
more understandable about what is happening for the installed packages.
For openSUSE it is quite commonly reported issue as I closed 3-4 during the
bugzilla cleanup mentioning this problem.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=966042
Bug ID: 966042
Summary: yast command-line usage emits "unable to close
filehandle properly" warning at exit
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: 2015*
Hardware: x86-64
OS: SUSE Other
Status: NEW
Severity: Minor
Priority: P5 - None
Component: YaST2
Assignee: yast2-maintainers(a)suse.de
Reporter: bk(a)ancilla.ca
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
Specifically, it says:
Warning: unable to close filehandle properly: Bad file descriptor, <STDIN> line
21 during global destruction (#1)
(S io) An error occurred when Perl implicitly closed a filehandle. This
usually indicates your file system ran out of disk space.
This happens with (as far as I can tell, I haven't tested exhaustively) all
command-line yast invokations that involve a module. So, e.g., "yast users
help" or "yast sysconfig help" will produce this message. "yast help" on its
own, however, won't.
It does not appear to affect yast's exit code, or it's ability to do its job;
if I run "yast sysconfig set LOADER_TYPE=none", it does the right thing and
then produces that message while exiting.
Despite the hint that it may be space-related, this happens on multiple
computers, all of them with plenty of space available on all filesystems. These
systems are all running recent (~2 weeks) versions of Tumbleweed.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=997317
Bug ID: 997317
Summary: grub2-branding lacks posttrans
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 42.2
Hardware: x86-64
OS: Linux
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Bootloader
Assignee: jsrain(a)suse.com
Reporter: ohering(a)suse.com
QA Contact: jsrain(a)suse.com
Found By: ---
Blocker: ---
grub2-branding creates a grub2.cfg in its %post.
this is a very expensive operation, in combination with os-prober.
there is nothing in that pkg which requires immediate action.
cumulate the required steps and do it once in a single %posttrans.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=952799
Bug ID: 952799
Summary: bogofilter-{db,sqlite3} insists on using wordlist.tc
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: 2015*
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: gour(a)atmarama.net
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
In the past, when using other Linux distros I was mostly using bogofilter with
sqlite3 back-end, but after switching to openSUSE I've decided to convert to
'default' (Berkeley) DB backend.
Unfortunately, after bogofilter package was updated in openSUSE, it looks it
does insist on using $HOME/.bogofilter/wordlist.tc for the database name even
if one uses Berkeley DB or Sqlite3 back-ends?
When I try to use my old wordlist.db, Bogofilter plugin (Claws & Evolution)
starts from the scratch and creates wordlist.tc.
I wonder about this line in *.spec:
%if 0%{?suse_version} > 1320
iow. whether the new Bogofilter package is ready to use existing setup with
appropriate back-end (not equal to TokyoCabinet)?
--
You are receiving this mail because:
You are on the CC list for the bug.