June 2017 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1043435] New: java-1_8_0-openjdk: java web start regression: Fatal: Initialization Error: Could not initialize application
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043435 Bug ID: 1043435 Summary: java-1_8_0-openjdk: java web start regression: Fatal: Initialization Error: Could not initialize application Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Java Assignee: fstrba(a)suse.com Reporter: astieger(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fstrba(a)suse.com Found By: Community User Blocker: --- There is a regression in the Java update for bug 1034849 on openSUSE: openSUSE-2017-662, this is a SLE imported update. This is a FUJITSU ServerView iRMC S4 Web Server, starting a jViewer server console. I can provide test access. Messages: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:813) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:532) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:936) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2393) at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:321) at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:734) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:285) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:403) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:805) ... 2 more net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line. at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:813) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:532) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:936) Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed. at net.sourceforge.jnlp.runtime.JNLPClassLoader$SecurityDelegateImpl.getClassLoaderSecurity(JNLPClassLoader.java:2393) at net.sourceforge.jnlp.runtime.JNLPClassLoader.setSecurity(JNLPClassLoader.java:321) at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:734) at net.sourceforge.jnlp.runtime.JNLPClassLoader.<init>(JNLPClassLoader.java:285) at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:357) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:429) at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:403) at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:805) ... 2 more netx: Initialization Error: Could not initialize application. (Fatal: Application Error: Cannot grant permissions to unsigned jars. Application requested security permissions, but jars are not signed.) App already has trusted publisher: false Jar found at ... been verified as UNSIGNED [...] Prior to the update, a user can confirm the unsigned jars via UI. Confirmed working: java-1_8_0-openjdk-headless-1.8.0.121-10.5.1.x86_64 java-1_8_0-openjdk-1.8.0.121-10.5.1.x86_64 Broken: java-1_8_0-openjdk-headless-1.8.0.131-10.8.1.x86_64 java-1_8_0-openjdk-1.8.0.131-10.8.1.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1042037] Apache upgrade runs /usr/share/apache2/apache-22-24-upgrade and issues a2enmod: command not found
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1042037 http://bugzilla.suse.com/show_bug.cgi?id=1042037#c5 --- Comment #5 from Petr Gajdos <pgajdos(a)suse.com> --- (In reply to Dario Savella from comment #4) > This error is not related with the issue (now fixed) that made me look at > the zypp log in the first place. I had understood that this way, yes. > I reported it only because it seems strange (to me) that (apparently) every > update of the apache2 package runs it again. The logic is poor, yes. But it is there for a long time and there was similar one called apache-20-22-upgrade in the past, you can imagine its age. Nevertheless I have little motivation to change it as the script will be dropped soon anyway (after sle15) and I wish to not introduce similar one in the future. > I understand that if the modules to be removed are not there there's > 'nothing to do', but that script also enables some modules (authn_core, > authz_core, log_config) and that may alter an otherwise working > configuration. I need to understand how. > My logged-in root user has the following: > PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/ > usr/bin/X11:/usr/games:/opt/bin:/opt/kde3/bin Can not imagine what went wrong. I have not 42.1 at hand (it is not supported anynmore, by the way) but on 42.2 and I have no such error in zypp/history. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043218] YaST crashes on installation of banshee
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043218 http://bugzilla.suse.com/show_bug.cgi?id=1043218#c3 --- Comment #3 from Michael Andres <ma(a)suse.com> --- @Lada: We can share or clone this bug. The UrlReplacer is in fact innocent. It's our own code (zypper as well as yast and even in libzypp itself).: In the crash above in yast-pkg-bindings/YRepo.h > zypp::MediaSetAccess_Ptr & YRepo::mediaAccess() > { > if (!_maccess) > { > y2milestone("Creating new MediaSetAccess for url %s", > (*_repo.baseUrlsBegin()).asString().c_str()); > ^^^^^^^^^^^^^^^^^^^^^^ We are used to the fact that repos _usually_ have at least one baseurl defined, but this is not necessarily true. baseUrls may be empty! We should check our code for occurrences of '*baseUrlsBegin()' and make sure it's protected by 'baseUrlsEmpty()'. If appropriate (e.g. in messages) you can also use RepoInfo::url(): > /** > * Pars pro toto: The first repository url > */ > Url url() const > { return( baseUrlsEmpty() ? Url() : *baseUrlsBegin()); } -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1037891] All YaST module window names show "ruby" instead of a more specifc name (was: Yast module windows in Plasma: generic x window icon and grouped as "ruby" in task manager)
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1037891 http://bugzilla.suse.com/show_bug.cgi?id=1037891#c30 --- Comment #30 from Josef Reidinger <jreidinger(a)suse.com> --- (In reply to Oliver Kurz from comment #29) > (In reply to Fabian Vogt from comment #27) > > In 42.2, where everything works fine, WM_CLASS = "YaST2", "YaST2", while in > > 42.3 and TW WM_CLASS = "ruby", "YaST2 - sw_single @ linux-lm3i.site" > > I hope I am not confusing the discussion more by stating that this is also > visible in the installer. In the installer popups show up that have that > quite long string "YaST2 - installation @ <hostname>" or similar. This > string can also be touching the border of the window which I consider a > visual regression. to be honest, I am quite confused by installation, as some already had this long string in past, e.g. when doing ssh -X installation, but in some other cases it was only YaST2? Currently it always shows the same, I can always also show YaST2 itself, but I really do not want to do some magic to display different stuff depending on communication method ( which from my POV was just mistake in past ). if you check https://openqa.suse.de/tests/925004#step/welcome/1 you see that even in past was there that YaST2 @ something. so maybe skip installation part, to not mention it is installation client? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043546] New: "Toggle Mode" in YaST AppArmor module does not work in non-English locale
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043546 Bug ID: 1043546 Summary: "Toggle Mode" in YaST AppArmor module does not work in non-English locale Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: belphegor(a)belbel.or.jp QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Build Identifier: While in English locale, YaST2 AppArmor module can switch modes between "enforce" and "complain" by "Toggle Mode" button in "Configure Profile Mode" dialog. But while in non-English locale (especially when "enforce" and "compain" are translated to another string, "強制" and "不平" for example (Japanese)), this module cannot recognize current mode and show an error message "Could not recognize mode". I think that this module recognizes the current mode from a string in GUI table, but this string may be translated to something different. This logic should be modified to recognize from original (not-translated) one. Reproducible: Always Steps to Reproduce: 1. Install "yast2-trans-ja" package. 2. Run "LANG=ja_JP yast2 apparmor". 3. Push "モード切り替え" (Toggle Mode) button in "プロファイルモードの設定" (Profile Mode Configuration) dialog. Actual Results: Shows error message "モードを認識できません" (Could not recognize mode). Expected Results: Can be switched between "enforce" and "complain". -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 966671] No application can be run after some uptime (No protocol specified)
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=966671 http://bugzilla.suse.com/show_bug.cgi?id=966671#c21 --- Comment #21 from Jiri Slaby <jslaby(a)suse.com> --- It didn't help for me. Right now I am there again: $ ls $XAUTHORITY ls: cannot access '/tmp/xauth-500-_0': No such file or directory And the timer seem not to trigger: # systemctl status systemd-tmpfiles-clean.timer ● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled) Active: active (waiting) since Tue 2017-05-30 08:56:26 CEST; 1 weeks 3 days ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) May 30 08:56:26 anemoi systemd[1]: Started Daily Cleanup of Temporary Directories. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043218] YaST crashes on installation of banshee
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1043218 http://bugzilla.suse.com/show_bug.cgi?id=1043218#c2 Michael Andres <ma(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|YaST2 |libzypp Assignee|yast2-maintainers(a)suse.de |zypp-maintainers(a)forge.prov | |o.novell.com QA Contact|jsrain(a)suse.com |qa-bugs(a)suse.de Flags|needinfo?(zypp-maintainers@ | |forge.provo.novell.com) | --- Comment #2 from Michael Andres <ma(a)suse.com> --- No, I this was not caused by some package. The installation of packages has been completed. It's most probably due to this repo: > /etc/zypp/repos.d/devel_languages_D.repo > -------------------------------------- > - alias : devel_languages_D > - name : The D programming language (openSUSE_Tumbleweed) > - enabled : 0 > - autorefresh : 0 > - type : NONE > - priority : 99 > - gpgcheck : D(Y) repoD(Y) sig? pkgD(Y) > - filePath: /etc/zypp/repos.d/devel_languages_D.repo It has no baseurl defined. Something in YASTS cleanup code seems to activate the UrlReplacer, which leads to the crash. I'm able to reproduce similar crashes locally with zypper. So I guess it's a libzypp issue in the first place. ->zypp-maintainers -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1040272] The keyboard layout selected in installer is not pre-selected in the yast configuration dialog in the installed system
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1040272 http://bugzilla.suse.com/show_bug.cgi?id=1040272#c7 Oliver Kurz <okurz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID Flags|needinfo?(okurz(a)suse.com) | --- Comment #7 from Oliver Kurz <okurz(a)suse.com> --- I could not reproduce the problem. I am sure I tested with a wrong setup selecting "the most recent" openSUSE Leap 42.3 on dist.suse.de which is not a correct version but a very very old one -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1029975] sash has binaries in /bin
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.suse.com/show_bug.cgi?id=1029975 http://bugzilla.suse.com/show_bug.cgi?id=1029975#c3 --- Comment #3 from Bernhard Wiedemann <bwiedemann(a)suse.com> --- This is an autogenerated message for OBS integration: This bug (1029975) was mentioned in https://build.opensuse.org/request/show/502445 Factory / sash -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1043514] New: Kgpg exports secret key and revokekey without asking for password from kgpg
by bugzilla_noreply＠novell.com 09 Jun '17

09 Jun '17

http://bugzilla.opensuse.org/show_bug.cgi?id=1043514 Bug ID: 1043514 Summary: Kgpg exports secret key and revokekey without asking for password from kgpg Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: x86-64 OS: openSUSE 42.2 Status: NEW Severity: Critical Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: stakanov(a)freenet.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- For what I am used, when a secret key is exported, the key password should be asked. The same applies for when a revoke key is exported. On this new install of 42.2 I experience the same problems as I have in the past. When they happen the system gets nearly unusable. They always come together, so I report them here. a) first problem you encounter is that the password insertion field does not react any more. After resetting the PC you find: 1) this is a luks encrypted system with password protected grub, a notebook. Before this event no problem. After(!) this event you have that external usb-keyboards works, until you reach LUKS. Then you are forced to enter the password over the notebook keyboard because the system does not recognize any USB any more (no mouse no keyboard). So now you enter the password via the notebook keyboard, the system starts and all seems normal again (note that this is not normal because a fresh install never has this problem). b) you reach the desktop, start kontact/kmail and since you protected the password with kgpg you find that the password does not react. Before I did not have any problem. Then, I installed kwalletmanager. After the install the password input worked again until the next reboot. This time I had to type the password 8 times to get the wallet to open. Now I wanted to see whether something was wrong and opened kgpg. So now I can export a public key, a secret key and a revoke without password? So that would mean if you use gpg-keys to protect you wallet, no problem to get hold on you secret key? I am used that you have to type in the password to export you secret key. And also issuing a revoke key should IMO always(!) require a password. Otherwise maybe I did misunderstand the principle of the need of a password in kgpg. Please let me know if this is a new feature. -- You are receiving this mail because: You are on the CC list for the bug.

1 1