March 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1125718] pop up with 'Software changed' message after grub update
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

1 0

[Bug 1125718] pop up with 'Software changed' message after grub update
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1125718 http://bugzilla.suse.com/show_bug.cgi?id=1125718#c7 --- Comment #7 from David Diaz <dgonzalez(a)suse.com> --- (In reply to Josef Reidinger from comment #4) > (In reply to Stefan Schubert from comment #3) > > The bootloader makes changes in the package selection. So the proposal will > > be called again for the software selection. I have not found why it happens > > only sometimes. I have noticed that the booloader proposal will be called > > before software proposal in TW: > > https://openqa.opensuse.org/tests/856524#step/disable_grub_timeout/13 > > This is different to SLES. The software proposal will be called before > > bootloader proposal. > > Josef, do you know why ? Or perhaps you can see more than I am ? :-) > > I have to be called before. But why you think that it is called after > software proposal? I see it at > https://github.com/yast/skelcd-control-leanos/blob/master/control/control. > leanos.xml#L218 Do not confuse presentation order and real order in which it > is evaluated. Thank you for the clarification Josef. As it is confirmed, I am going to track it in our internal Trello board. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1125718] pop up with 'Software changed' message after grub update
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1125718 http://bugzilla.suse.com/show_bug.cgi?id=1125718#c6 --- Comment #6 from David Diaz <dgonzalez(a)suse.com> --- Created attachment 799279 --> http://bugzilla.suse.com/attachment.cgi?id=799279&action=edit Yast2 logs -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1125718] pop up with 'Software changed' message after grub update
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1125718 http://bugzilla.suse.com/show_bug.cgi?id=1125718#c5 --- Comment #5 from David Diaz <dgonzalez(a)suse.com> --- (In reply to Guillaume GARDET from comment #2) > (In reply to David Diaz from comment #1) > > Is there the possibility to have the logs? > > You now have logs available: > https://openqa.opensuse.org/tests/869420#downloads > Thank you so much, Guillaume. Please, note that it is better to attach them to the bug report itself. As far as I know, they stay in openQA for a limited time. I'll attach the YaST2 logs. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1091307] translation-update-upstream20180426 breaks other packages
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1091307 http://bugzilla.suse.com/show_bug.cgi?id=1091307#c9 Marketa Calabkova <mcalabkova(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED CC| |mcalabkova(a)suse.com Resolution|--- |FIXED --- Comment #9 from Marketa Calabkova <mcalabkova(a)suse.com> --- Looks like Dominique fixed it at least in Factory. I will thus close this bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1119186] kdevelop5: Code completion and parser don't work
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1119186 http://bugzilla.suse.com/show_bug.cgi?id=1119186#c22 --- Comment #22 from Wolfgang Bauer <wbauer(a)tmo.at> --- FYI: kdevelop 5.3.2 has been released today. I removed the %requires_eq, and added a Requires: clangX (corresponding to the libclangX-devel that's used for building) now: Requires: clang%(rpm -q --qf '%''{version}' clang-devel | cut -d. -f1) (inspired by what we have in the libqt5-creator package...) That should be safe enough I hope, and should also allow you to install a newer clang from 3rd party repos. https://build.opensuse.org/request/show/682480 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1127808] Please consider CONFIG_HARDENED_USERCOPY and CONFIG_SLAB_FREELIST_HARDENED
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1127808 http://bugzilla.suse.com/show_bug.cgi?id=1127808#c3 --- Comment #3 from Mel Gorman <mgorman(a)suse.com> --- First off, SLAB_FREELIST_HARDENED is not an option for us as it depends on SLUB which we never switched to. If we want that, we'd first have to consider the SLUB switch and what that means and then the SLAB_FREELIST_HARDENED so only HARDENED_USERCOPY was considered. Short answer -- I've no objection but there are limits to the testing methodology used to measure this. Networking loads appear to be the ones most likely to notice. Overall we're looking at a general hit of 0-8% hit depending on the workload. I'm somewhat wary of enabling it just because everybody else does but the type of attack it protects against is realistic. That said, I did not do a proper networking test between hosts and used localhost only. The changelog introducing the entry mentioned 5-8% drop on UDP on what I *think* was a host-to-host setup which is relatively rare. It looks like we take a hit communicating via localhost too. In the tests I did, there is measurable overhead but it's not too insane and it's not universal. I'd rather not have it but we've taken hits for security mitigation before. Very broadly speaking, there is an increase in system CPU usage but it's hard to detect from headline performance metrics. The most obvious hit is to networking loads running on localhost dbench (lots of copying) showed a mix of performance differences that were close to the noise but looks like it's about 3% at worst and usually around the 1% mark. System CPU usage is 1% higher. pgbench in a read-only small memory configuration (some kernel copying, mostly shared memory areas) showed very little difference. Roughly 0-2% of a hit but it was not a universal loss with results close to the noise. System CPU usage is 5% higher. specjbb shows almost no difference as it does not have a large kernel footprint. Overhead is negligible. Similarly the NAS Parallel Benchmark shows almost no difference as it has a negligible kernel component. This was known in advance but I just wanted to make the point that for some "high performance" workloads, there will be no impact due to this configuration change. Netperf TCP_STREAM and UDP_STREAM both take a 2-5% hit depending on the buffer size which is curious given that the system CPU usage is almost unchanged. I suspect in practice this might only be of concern on very high speed networks or host-to-host configurations. In those instances, they are likely to notice the check overhead in perf and disable accordingly. Similarly, tbench takes a 2-5% performance hit. Also similarly, hackbench communicating over sockets takes a 3% hit but communicating over pipes is fine. Compile-based workload (specifically a kernel build) was almost unaffected. I say almost because for some reason -j4 took a massive hit (20% on two separate machines with very different configurations) while other -j values show 0-1% differences well within noise. This is definitely the most curious result and I do not have a good explanation as to why -j4 matters so much. So overall, it's far from free no matter was Kees Cook says but I think relatively few people are going to notice and if they do, it's relatively trivial to detect with perf -- level of relative depending on comfort level with perf. Thanks for bringing me into the loop on this one Jiri. It's the type of thing I do not like to get blind sided by. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1128323] Add the latest pytest macros to python-rpm-macros from Factory
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1128323 http://bugzilla.suse.com/show_bug.cgi?id=1128323#c3 --- Comment #3 from Swamp Workflow Management <swamp(a)suse.de> --- This is an autogenerated message for OBS integration: This bug (1128323) was mentioned in https://build.opensuse.org/request/show/682470 Factory / python-rpm-macros -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1128276] New: Application:Geo/gdal: Bug
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1128276 Bug ID: 1128276 Summary: Application:Geo/gdal: Bug Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: bruno(a)ioda-net.ch Reporter: bruno(a)ioda-net.ch QA Contact: bnc-team-screening(a)forge.provo.novell.com CC: tzotsos(a)gmail.com Found By: --- Blocker: --- Last version with py rename create a self obsoletion [ 1254s] python2-GDAL.x86_64: W: self-obsoletion python-gdal obsoletes python-gdal = 2.4.0 [ 1254s] python2-GDAL.x86_64: W: self-obsoletion python2-gdal obsoletes python2-gdal = 2.4.0 [ 1254s] python3-GDAL.x86_64: W: self-obsoletion python3-gdal obsoletes python3-gdal = 2.4.0 [ 1254s] The package obsoletes itself. This is known to cause errors in various tools [ 1254s] and should thus be avoided, usually by using appropriately versioned Obsoletes [ 1254s] and/or Provides and avoiding unversioned ones. Provides: python3-%{name} = %{version} Obsoletes: python3-%{name} should be Provides: python3-%{name} = %{version} Obsoletes: python3-%{name} < %{version} in both case. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1127123] GCC 9: boost build fails
by bugzilla_noreply＠novell.com 07 Mar '19

07 Mar '19

http://bugzilla.suse.com/show_bug.cgi?id=1127123 http://bugzilla.suse.com/show_bug.cgi?id=1127123#c3 --- Comment #3 from Martin Liška <martin.liska(a)suse.com> --- I can confirm that on x86_64 openblas fix is not easy and we should probably wait for new release. On i586, python-numpy is going to finish soon: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:… and then you'll be able to: $ osc co openSUSE:Factory:Staging:Gcc7/boost $ cd .... $ osc build -- You are receiving this mail because: You are on the CC list for the bug.

1 0