August 2016 - openSUSE Bugs - openSUSE Mailing Lists

[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 993025] New: do not show the packages that will not get updated in quiet mode
by bugzilla_noreply＠novell.com 18 Aug '19

18 Aug '19

http://bugzilla.suse.com/show_bug.cgi?id=993025 Bug ID: 993025 Summary: do not show the packages that will not get updated in quiet mode Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)forge.provo.novell.com Reporter: tchatzimichos(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When using zypper with -q, I see the following message: The following 157 package updates will NOT be installed: <various packages listed here> I would prefer the above not to be shown when in quiet mode, as it spams my logs on my daily auto-update script. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[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 994044] New: Kde-Live net installer is interrupted by screenlock
by bugzilla_noreply＠novell.com 02 Aug '19

02 Aug '19

http://bugzilla.suse.com/show_bug.cgi?id=994044 Bug ID: 994044 Summary: Kde-Live net installer is interrupted by screenlock Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Live Medium Assignee: coolo(a)suse.com Reporter: okurz(a)suse.com QA Contact: okurz(a)suse.com Found By: --- Blocker: --- ## observation While conducting an installation from the NET installer on Kde-Live the plasma screenlock kicks in which is especially annoying since the installer will vanish silently in the background upon completion because of boo#993885. ## steps to reproduce * start Kde-Live * call installation from within plasma session * wait * observe screenlock kicks in after some time ## expected result when installer is running the screenlock should never kick in. Alternative: screenlock disabled for the whole live medium which might be an easier approach. ## workaround probably the following should disable the screenlock for the active session ``` setterm blank 0 setterm powerdown 0 xset s 0 0 ``` -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 978282] New: vlc: SIGFPE, Arithmetic exception
by bugzilla_noreply＠novell.com 31 Jul '19

31 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=978282 Bug ID: 978282 Summary: vlc: SIGFPE, Arithmetic exception Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: dimstar(a)opensuse.org Reporter: mpluskal(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 675400 --> http://bugzilla.opensuse.org/attachment.cgi?id=675400&action=edit full backtrace When using TW+packman repos for tw and I execute following: /usr/bin/vlc -I dummy v4l:// --sout #transcode{vcodec=mp4v}: standard{access=http,mux=ogg,dst=hobo.local:8080} I get Arithmetic exception: (gdb) bt #0 0x00007f382deb578c in transcode_video_encoder_init (p_stream=p_stream@entry=0x7f380c4c9398, id=id@entry=0x7f381c000b20) at transcode/video.c:551 #1 0x00007f382deb60cb in transcode_video_process (p_stream=0x7f380c4c9398, id=id@entry=0x7f381c000b20, in=0x0, out=out@entry=0x7f382c446c90) at transcode/video.c:884 #2 0x00007f382deb167b in Send (p_stream=0x7f380c4c9398, id=0x7f381c000b20, p_buffer=<optimized out>) at transcode/transcode.c:661 #3 0x00007f383c1ec658 in sout_InputSendBuffer (p_input=0x7f381c0009a0, p_buffer=p_buffer@entry=0x7f38180008c0) at stream_output/stream_output.c:233 #4 0x00007f383c1795c4 in DecoderPlaySout (p_sout_block=0x7f38180008c0, p_dec=0x7f380c4d2a58) at input/decoder.c:1501 #5 DecoderProcessSout (p_block=0x0, p_dec=<optimized out>) at input/decoder.c:1556 #6 DecoderProcess (p_block=<optimized out>, p_dec=<optimized out>) at input/decoder.c:1787 #7 DecoderThread (p_data=0x7f380c4d2a58) at input/decoder.c:909 #8 0x00007f383c9ea424 in start_thread (arg=0x7f382c447700) at pthread_create.c:333 #9 0x00007f383c525add in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 990956] New: Missing categories in brp-check-suse (brp-30-desktop)
by bugzilla_noreply＠novell.com 26 Jul '19

26 Jul '19

http://bugzilla.opensuse.org/show_bug.cgi?id=990956 Bug ID: 990956 Summary: Missing categories in brp-check-suse (brp-30-desktop) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: luizluca(a)tre-sc.jus.br QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, I was writing a RPM file which packs a .desktop file. I used the categogy "Utility;TelephonyTools;" and OBS gave me: 'ERROR: No sufficient Category definition:' I checked the file /usr/lib/rpm/brp-desktop.data/applications.menu and it seems to be outdated when I compare with https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html or https://cgit.freedesktop.org/xdg/xdg-specs/tree/menu/menu-spec.xml. Even OpenSUSE suggests TelephonyTools category at https://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories So, something is not updated. Either all the checked sources or brp-check-suse. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[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 995367] New: Leap 42.2 ppc64le net install failure linuxrc or bad repo
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=995367 Bug ID: 995367 Summary: Leap 42.2 ppc64le net install failure linuxrc or bad repo Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: PowerPC-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: normand(a)linux.vnet.ibm.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Created attachment 689327 --> http://bugzilla.suse.com/attachment.cgi?id=689327&action=edit abanc_net_install_leap42_2_failure.log Leap 42.2 ppc64le net install failure linuxrc or bad repo I tried install of Leap 42.2 ppc64le using the net iso Build0112 from (1) Using the default setup, linuxrc is failing with "Please make sure your installation medium is available" as per (2) the failing repo is (3) Looking at the linuxrc.log the failure is a missing repo/content file. If I choose ...repo/oss in place of .../repo then the failure reported in linuxrc.log is a missing repo/oss/config I do not know from those data if the problem is a bad repo or an error in linuxrc (1) http://download.opensuse.org/ports/ppc/distribution/leap/42.2-Current/iso/ (2) linuxrc reporting bad installation medium === ... ending DHCP request to eth3... ok, ip = 9.101.18.90/24 Please make sure your installation medium is available. Choose the URL to retry. 0) <-- Back <-- 1) ftp://9.101.18.1/pub/linux/opensuse/42.2/ppc64le/os/ 2) http://download.opensuse.org/ports/ppc/distribution/leap/42.2/r 3) Enter another URL > === (3) http://download.opensuse.org/ports/ppc/distribution/leap/42.2/repo === -- You are receiving this mail because: You are on the CC list for the bug.

1 26

[Bug 991850] New: YaST2 > Software Manager tries to access skipped remository
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=991850 Bug ID: 991850 Summary: YaST2 > Software Manager tries to access skipped remository Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: Other OS: openSUSE 42.1 Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: opensuse.lietuviu.kalba(a)gmail.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Sometimes some custom repositories are not available. Then YaST2 Software manager is reading */repodata/repomd.xml for long time and fails, and ask user what to do; if user selects to Skip this repository, YaST2 still will try to access this repository (at stage of creating/updating catch for accesible repositories)! And YaST2 will again ask in same dialog what to do! I suppose, that YaST2 must remember, that used skipped repository, and not to try access it again. Tested and reproducible in openSUSE 13.2 and Leap 42.1 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 989493] New: mlocate security: normal user must be added to group nobody; wrong man page info about --require-visibility FLAG
by bugzilla_noreply＠novell.com 11 Jul '19

11 Jul '19

http://bugzilla.suse.com/show_bug.cgi?id=989493 Bug ID: 989493 Summary: mlocate security: normal user must be added to group nobody; wrong man page info about --require-visibility FLAG Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: studio(a)anchev.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The man page of update db says (excerpt): --------------- -l, --require-visibility FLAG Set the “require file visibility before reporting it” flag in the generated database to FLAG. If FLAG is 0 or no, or if the database file is readable by "others" or it is not owned by nobody, locate(1) outputs the database entries even if the user running locate(1) could not have read the directory necessary to find out the file described by the database entry. If FLAG is 1 or yes (the default), locate(1) checks the permissions of parent directories of each entry before reporting it to the invoking user. To make the file existence truly hidden from other users, the database group is set to nobody and the database permissions prohibit reading the database by users using other means than locate(1), which is set-gid nobody. Note that the visibility flag is checked only if the database is owned by nobody and it is not readable by "others". --------------- I made the following experiment: - Run updatedb as root with no extra options (supposing by default it will use flag 1 as per man page) - Checked the permission of the db file (it was 644) - Run "locate root" as normal user - I can see the contents of /root (which means the man page is wrong and by default flag is 0) - chown nobody: /var/lib/mlocate/mlocate.db - Run "locate root" as normal user - again I can see the contents of /root - chmod 640 /var/lib/mlocate/mlocate.db (as according to the documentation that is required in order the flag 1 to be respected) - same result Then I tried explicitly to run "updatedb -l 1" as root and I see that it recreates the db file but this time the permissions are 640. So even when owned by nobody a normal user cannot use the locate command: > locate root locate: can not open `/var/lib/mlocate/mlocate.db': Permission denied After adding my user to group nobody I was able to run "locate root" without seeing the files in "/root". This whole thing means that: 1. The man page is not correct as the default is FLAG 0 (insecure), not 1 (secure) 2. One is forced to use the first approach (adding each user to group nobody). I don't know what are the security implications of this but it doesn't sound as something normal, right? 3. The script /etc/cron.daily/mlocate.cron needs to be modified somehow in order to use explicitly FLAG 1 (is that possible?) -- You are receiving this mail because: You are on the CC list for the bug.

1 1