November 2015 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 921221] New: Unable to install with UEFI Secure Boot if Windows is present
by bugzilla_noreply＠novell.com 26 Sep '19

26 Sep '19

http://bugzilla.opensuse.org/show_bug.cgi?id=921221 Bug ID: 921221 Summary: Unable to install with UEFI Secure Boot if Windows is present Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: rbrown(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Hardware: ASUS UX303LA with Windows 8.1, i7 5500U, 12GB RAM Steps to Reproduce: 1. Factory/Plain installation of Windows 8.1 2. Burn a Tumbleweed (or 13.2) USB stick - Tried with a NET, DVD, or Live ISO 3. Boot to it - Blue ncurses screen asking if you trust the SUSE Keys pops up 4. Click Yes 5. End up at a Grub2 command prompt, system refuses to boot into YaST - lots of different attempts to get it booted by setting linuxefi and initrdefi don't work 6. Clearing KEK, etc, in the Bios doesn't help 7. Trying different USB sticks doesn't help 8. The 'do you want to trust SUSEs Keys' ncurses window never appears again 9. Switching the BIOS to boot into Legacy mode, booting to a liveUSB in Legacy, wiping the hard drive and starting the process fresh works..but obviously, you have no opportunity to dual boot with Windows 8 Looks to me like there is something wrong with how we're currently trying to insert keys/shim/whatever into the EFI configuration present on a fresh Windows 8.1 install. This is a pretty serious problem if people want to easily install openSUSE on freshly purchased hardware. -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 939462] New: ibus-table input methods not working
by bugzilla_noreply＠novell.com 08 Sep '19

08 Sep '19

http://bugzilla.opensuse.org/show_bug.cgi?id=939462 Bug ID: 939462 Summary: ibus-table input methods not working Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: cycharlie(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This problem exists since openSUSE 13.2, and it continues to exist in Tumbleweed and Leap. THw whole bunch of ibus-table-* input methods can be installed and added in iBus. However, when those input methods are selected, iBus failed to utilize them, iBus stays at the input method that is currently using, instead of changing into the one that I just selected. Similar problem had occured in openSUSE 13.1, which ibus-table input methods even couldn't be added to iBus (packages installed but iBus did not list them out). There was a solution for this situation, but this time that solution does not work for what happens in openSUSE 13.2/Tumbleweed/Leap. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 930173] New: VUL-0: CVE-2015-0847: nbd: incorrect signal handling DoD
by bugzilla_noreply＠novell.com 28 Aug '19

28 Aug '19

http://bugzilla.suse.com/show_bug.cgi?id=930173 Bug ID: 930173 Summary: VUL-0: CVE-2015-0847: nbd: incorrect signal handling DoD Classification: openSUSE Product: openSUSE Distribution Version: 13.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- http://seclists.org/oss-sec/2015/q2/388 CVE-2015-0847 in nbd-server From: Florian Weimer <fw () deneb enyo de> Date: Thu, 07 May 2015 22:45:33 +0200 nbd-server uses signal handlers incorrectly, which leads to a denial of service vulnerability. We have assigned CVE-2015-0847 to this vulnerability. This was first reported to the Debian security team by Tuomas Räsänen, but we did not think this warranted an embargo. More details are available upstream: <http://sourceforge.net/p/nbd/mailman/message/34091218/> -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 902779] New: [Factory] Long boot delay "a start job is running for..."
by bugzilla_noreply＠novell.com 27 Aug '19

27 Aug '19

http://bugzilla.opensuse.org/show_bug.cgi?id=902779 Bug ID: 902779 Summary: [Factory] Long boot delay "a start job is running for..." Classification: openSUSE Product: openSUSE Factory Version: 201410* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: sb56637(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, My openSUSE Factory installation was taking at least 60 seconds longer than normal to boot. The delay always occurred on every boot. The delay occured before initializing the display manager with a message: "A start job is running for", and it would alternate between four different services: X display manager, Avahi, NetworkManager, and Modem Manager. I tried disabling the Modem Manager service, but it still kept hanging on Avahi and NetworkManager. I eventually tried disabling and later re-enabling the NetworkManager services, and it now boots quickly without hanging. I don't really know why this happened or what I did to fix it. Please let me know what additional information you need to prevent this bug from happening. Thanks a lot! -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 934055] New: yast2-network: Do not use .site as default TLD
by bugzilla_noreply＠novell.com 23 Aug '19

23 Aug '19

http://bugzilla.suse.com/show_bug.cgi?id=934055 Bug ID: 934055 Summary: yast2-network: Do not use .site as default TLD Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: mfilka(a)suse.com Reporter: lnussel(a)suse.com QA Contact: jsrain(a)suse.com Blocks: 923990 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #923990 +++ YaST should not set any domain at all anymore in /etc/hostname. The domain name entry box (eg https://openqa.opensuse.org/tests/67247/modules/yast2_lan/steps/3) should be removed. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 840485] New: Firefox 24.0/17.0.9esr security release
by bugzilla_noreply＠novell.com 16 Aug '19

16 Aug '19

https://bugzilla.novell.com/show_bug.cgi?id=840485 https://bugzilla.novell.com/show_bug.cgi?id=840485#c0 Summary: Firefox 24.0/17.0.9esr security release Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Firefox AssignedTo: bnc-team-mozilla(a)forge.provo.novell.com ReportedBy: wolfgang(a)rosenauer.org QAContact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- 2013-09-17 is the announced release date for the following Mozilla applications which contain security fixes (as always) (https://wiki.mozilla.org/Releases): Firefox 24.0 Firefox 17.0.9esr xulrunner 17.0.9esr Seamonkey 2.21 Thunderbird 17.0.9esr Thunderbird 24.0 (minimum NSPR 4.10 and NSS 3.15.1 requirements I think already met with last update round) I'll provide updates for openSUSE distributions as usual with one exception where I'd like to get some feedback: Thunderbird will do a big version update to 24.0 for non-esr versions. Since esr and non esr versions were 99,9% identical in the 17.0 series we have the choice to update to 17.0.9esr or 24.0 for released distributions which will only move the major upgrade around 12 weeks so I'm in favor to follow the big update now already. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 46

[Bug 954556] New: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote
by bugzilla_noreply＠novell.com 12 Jul '19

12 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=954556 Bug ID: 954556 Summary: After upgrading from 13.2 to Leap 42.1, Mercurial chokes on files locally deleted and ignored, but changed on the remote Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 URL: http://users.skynet.be/antoine.mechelynck/vim/vim-tony mec.bundle.bz2 OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: antoine.mechelynck(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm not sure if this bug is in the correct Component. It concerns a difference between the Mercurial versions for openSUSE 13.2 and openSUSE Leap 42.1. I'll describe below the problems I had (in a Mercurial repository with local changes) after upgrading to Leap 42.1, and how I solved them (probably not ideally), in the hope that something can be found to make life easier to anyone else running into the same (or a sufficiently similar) problem. FWIW I've uploaded at http://users.skynet.be/antoine.mechelynck/vim/vim-tonymec.bundle.bz2 a full bundle of my local Vim repository, including a clone of the Mercurial mirror at https://bitbucket.org/vim-mirror/vim with local changes. The bundle is 8.8 MiB for a repository occupying about 151 MiB so I didn't attach it to this bug. The tip before I upgraded to Leap 42.1 was the merge commit about 30 changesets from the present tip. The earlier changesets (0 to 7225) are probably not as interesting but I didn't know how else to let you look at it from my point of view. It might be possible to inspect the bundle without unpacking it, by declaring it as a "repository" by means of the -R argument to Mercurial. This past weekend I upgraded to Leap 42.1 and a few hours ago "hg in" displayed 27 new changesets. I tried to "fetch" them but instead of saying "remote changed runtime/doc/tags which local deleted" and asking me if I wanted to download the changes or keep deleted, Mercurial errored out with the new changesets applied, the "old" merge still current, no new merge done, and a message saying that it could not proceed because of a locally ignored file changed on the remote (the deleted file in question). I goofed around some, updated (not easily) to 0 and back to tip, including a couple of manual merges for which Mercurial invoked vimdiff as my preferred merge tool, and finally added one monstrous changeset by hg addremove followed by hg commit. Those "added" files are IIUC files ignored by my locally modified .hgignore on the other unnamed branch. After that I could finally merge my local changes with the monstrous changeset I had just added on top of Bram's official tip. After that I notice that "hg diff" on the locally deleted file does not give the same output as it used to before the upgrade to Leap. Previously it showed a diff between the remote version of the file and /dev/null, which was longish and looked messy, but, well, I used to think that was the way of things, at least with that version of Mercurial. Now it just says: diff --git a/runtime/doc/tags b/runtime/doc/tags deleted file mode 100644 which I find much neater even if it is not visually reversible. I am practically certain that what I did was not the "ideal" thing to do, but it is the best I could find to work around this change of behaviour and still get a working directory tree with which I could compile Bram's version with my local changes (which consist of one feature added and one disabled in src/feature.h, plus .hgignore lines for runtime/doc/tags which is regenerated by "make install" anyway, and for some directories and files not present on the remote, e.g. "shadow" directories allowing me to compile a Huge and a Tiny build in parallel from the same source with different config settings passed as environment variables). I hope Mercurial won't choke again the next time new changesets are added at the remote and I try to apply them. -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 956262] New: cobbler dependencies.
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=956262 Bug ID: 956262 Summary: cobbler dependencies. Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: osynge(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- The applications: cobbler-2.6.6-3.8.noarch cobbler-web-2.6.6-3.8.noarch Are separately packaged hence "cobbler" should not depend on apache. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 935339] New: gpgme fails to cleanly uninstall: install-info: No such file or directory for /usr/share/info/gpgme.info.gz
by bugzilla_noreply＠novell.com 05 Jul '19

05 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=935339 Bug ID: 935339 Summary: gpgme fails to cleanly uninstall: install-info: No such file or directory for /usr/share/info/gpgme.info.gz Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gp(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Uninstalling gpgme, I get the following: 1 package to remove. After the operation, 355.3 KiB will be freed. Continue? [y/n/? shows all options] (y): y (1/1) Removing gpgme-1.5.5-1.1 .........................................................................................................[done] Additional rpm output: install-info: No such file or directory for /usr/share/info/gpgme.info.gz warning: %postun(gpgme-1.5.5-1.1.x86_64) scriptlet failed, exit status 1 # rpm -ql gpgme | grep info /usr/share/info/gpgme.info-1.gz /usr/share/info/gpgme.info-2.gz /usr/share/info/gpgme.info.gz This looks similar to bug #929415 and may have the same fix? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 925561] New: NetworkManager should provide a way to designate any connection as a mobile data connection
by bugzilla_noreply＠novell.com 03 Jul '19

03 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=925561 Bug ID: 925561 Summary: NetworkManager should provide a way to designate any connection as a mobile data connection Classification: openSUSE Product: openSUSE Factory Version: 201503* Hardware: x86-64 OS: openSUSE 13.2 Status: NEW Severity: Enhancement Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: jrhodes(a)redpointsoftware.com.au QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Apper has an option in it's settings regarding when to automatically download and install updates. Under this setting there's an option "unless I am on a mobile data connection", which supposedly ensures that Apper doesn't download software updates while connected to a mobile (or metered) network. Unfortunately there doesn't appear to be any way in NetworkManager to designate a wireless or wired connection as being a mobile connection, i.e. a connection provided by a wireless hotspot or USB tethered phone. I'd really like to set Apper to automatically download and install updates as soon as they are available (I'm running on openSUSE Tumbleweed, which I believe is just Factory now?), but I can't do this because I occasionally have my laptop connected to my 4G hotspot, and I don't want to risk having packages download over 4G. -- You are receiving this mail because: You are on the CC list for the bug.

1 2