http://bugzilla.opensuse.org/show_bug.cgi?id=1098184
Bug ID: 1098184
Summary: systemd unit files for cfengine contain incorrect path
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: aeszter(a)gwdg.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
With the update to cfengine 3.11, CFE binaries moved to /usr/bin. However, unit
files still point to /usr/sbin.
Problem also exists in Factory and systemsmanagement.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1108846
Bug ID: 1108846
Summary: gmenudbusmenuproxy needs appmenu-gtk-module
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: KDE Workspace (Plasma)
Assignee: opensuse-kde-bugs(a)opensuse.org
Reporter: cornelis(a)solcon.nl
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
gmenudbusmenuproxy (part of plasma5-workspace) requires appmenu-gtk-module
during runtime, not unity-gtk-module. It is since a few days in Factory. Part
of the package "vala-panel-appmenu".
See also the build log.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1029919
Bug ID: 1029919
Summary: zypper crashes when baseurl does not contain
http/https
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: libzypp
Assignee: zypp-maintainers(a)forge.provo.novell.com
Reporter: wattersm(a)watters.ws
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
zypper crashes when a repo file is missing the protocol in the download URL.
For example, the following repo file causes zypper to crash.
[home_Ximi1970_openSUSE_Extra]
baseurl=download.opensuse.org/repositories/home:/Ximi1970:/openSUSE:/Extra/…
enabled=1
gpgcheck=1
gpgkey=download.opensuse.org/repositories/home:/Ximi1970:/openSUSE:/Extra/o…
priority=99
autorefresh=1
keeppackages=1
type=rpm-md
Running any zypper command results in a crash as follows.
linux-0yvh:~ # zypper search bacula
Unexpected exception.
Url scheme is a required component
Please file a bug report about this.
See http://en.opensuse.org/Zypper/Troubleshooting for instructions
--
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.opensuse.org/show_bug.cgi?id=1130084
Bug ID: 1130084
Summary: openSUSE:Leap:15.1/piglit failed
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
URL: https://build.opensuse.org/package/live_build_log/open
SUSE:Leap:15.1/piglit/standard/x86_64
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: mimi.vx(a)gmail.com
Reporter: lnussel(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
openSUSE:Leap:15.1/piglit failed to build. Please see build log:
https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.1/piglit…
Job gets stuck, rebuild doesn't help
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1096050
Bug ID: 1096050
Summary: sudo doesn't work after upgrade from leap 42,3
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.0
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: alarrosa(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
After upgrading to Leap 15.0 from 42.3, sudo shows an error in the first lines:
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
sudo: unable to open /var/lib/sudo/ts/antonio: Permission denied
Then it asks for the root password as usual, but it doesn't accept it (I can
log in as root, so I know it's correctly written). After writting it 3 times,
it fails with:
sudo: unable to send audit message: Operation not permitted
sudo: PERM_ROOT: setresuid(0, -1, -1): Operation not permitted
The user id output:
uid=1000(antonio), gid=100(users) groups=100(users),10(wheel),485(kvm)
The output from 'rpm -V sudo' is:
.M....... g /var/lib/sudo
.M....... g /var/lib/sudo/ts
So I reinstalled the package and ran 'rpm --setperms sudo' with no change. Btw,
the package seems to set the permissions of the /var/lib/sudo/ts directory to
000 but I had other working systems where the permissions are 700, so I set it
to that. In any case, the owner is root:root.
I also tried reinstalling pam and pam-config with no luck.
Any idea of what to try?
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1062518
Bug ID: 1062518
Summary: x2gothinclient(d) is missing File/Path/Expand.pm perl
module
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: x86-64
OS: openSUSE Factory
Status: NEW
Severity: Normal
Priority: P5 - None
Component: X11 3rd Party Driver
Assignee: xorg-maintainer-bugs(a)forge.provo.novell.com
Reporter: werner(a)suse.com
QA Contact: sndirsch(a)suse.com
Found By: ---
Blocker: ---
Starting x2gothinclientd cause the message
Can't locate File/Path/Expand.pm in @INC (you may need to install the
File::Path::Expand module) (@INC contains:
/usr/lib/perl5/site_perl/5.26.1/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.26.1
/usr/lib/perl5/vendor_perl/5.26.1/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.26.1
/usr/lib/perl5/5.26.1/x86_64-linux-thread-multi /usr/lib/perl5/5.26.1
/usr/lib/perl5/site_perl) at /usr/sbin/x2gothinclientd line 23.
AFAICS there is no such file below /usr/lib/perl5/ nor any provides of
'perl(File::Path::Expand)'
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1041794
Bug ID: 1041794
Summary: Recent update breaks some Youtube videos
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 42.2
Hardware: x86-64
OS: Linux
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: bnc-team-screening(a)forge.provo.novell.com
Reporter: james.knott(a)rogers.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
An update around mid May caused some Youtube videos to fail. When this
happens, loading the video stops, leaving only the dot going around a circle
showing. This happens with Firefox, Seamonkey and Chromium browsers. The
videos that fail play OK in Windows. To verify the problem, I tried the videos
with a VirtualBox VM or a fresh 42.2 install. The problem videos played. I
then cloned the VM and ensured the videos played. I then updated the clone to
the latest updates and now the videos fail. The original non-updated VM still
continued to play the videos. It appears the problem is related to the type of
codec used. For example, videos with the vp9 codec play, but those with
avc1.4d400d now fail.
Here are 2 links, this one plays OK:
https://www.youtube.com/watch?v=Rzqq581Q3Us
But this one doesn't:
https://www.youtube.com/watch?v=t8tdmaEhMHE
Again, this problem occurred recently. Videos that played a few weeks ago now
fail.
--
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=1079439
Bug ID: 1079439
Summary: New area for ARCES Inter-Department Research Center
Bologna
Classification: openSUSE
Product: openSUSE.org
Version: unspecified
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: OBS Request
Assignee: mrueckert(a)suse.com
Reporter: marco.giusti(a)posteo.de
QA Contact: adrian(a)suse.com
Found By: ---
Blocker: ---
We first reached OBS at ARCES[1] after the demand of porting our
application, Virtualbricks[2], to SLE 12. Even without any experience
with SUSE or RPM, OBS allowed us to easily create the needed packages
and to deliver the software to our partners. Convinced of the benefits
of OBS we want to exploit it more. Following the advice from adrianS_ in
#opensuse-buildservice here I ask for a dedicated space that could be
recognized as connected to us, ideally with arces.unibo.it in the name.
Here[3] you can see the results of my attempts made with my account.
For a confirmation of the officiality* of my request you can contact
Carlo Caini[4], Associate Professor at ARCES, who directed the development
of Virtualbricks the last years.
A few words about Virtualbricks and how it is exploited by ARCES.
Virtualbricks is a frontend for the management of Qemu Virtual Machines
(VMs) and VDE virtualized network devices (switches, channel emulators,
etc.). Although it can be used to manage isolated VMs, its peculiar aim
is to design and manage testbeds consisting of many VMs interconnected
by VDE elements. In other words, it allows to extend the concept of VM
to testbeds, which thanks to Virtualbricks can become entirely
software-defined.
Among the wide variety of possible applications, we have academic
research and teaching on computer networks. In particular, we would
like to use this space as main hub to distribute our software to the
students of the course Protocols and Architectures for Space Networks,
master degrees in TLC and Computer Engineering of the University of
Bologna, as well as to our research partners, including some European
space agencies (ESA, DLR).
Thank you for taking this request in account.
Marco
* Although this request received the consensus of the Director of ARCES,
this space will not be recognized as *official* by the University of
Bologna i.e. it will not receive any direct support from University of
Bologna outside our own effort to maintain it.
[1] http://www.arces.unibo.it/en
[2] https://github.com/virtualsquare/virtualbricks
[3] https://build.opensuse.org/project/show/home:marcogiusti
[4] https://www.unibo.it/sitoweb/carlo.caini/en
--
You are receiving this mail because:
You are on the CC list for the bug.