December 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1157462] libdbus-1 uses abort() which is an absolute nogo for a system library
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.suse.com/show_bug.cgi?id=1157462 http://bugzilla.suse.com/show_bug.cgi?id=1157462#c12 --- Comment #12 from Dr. Werner Fink <werner(a)suse.com> --- Then you might do the update to 1.12.16 to get the security issue CVE-2019-12749 fixed for Tumbleweed/Factory as well accordingly to the policy Factory First. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1157462] libdbus-1 uses abort() which is an absolute nogo for a system library
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.suse.com/show_bug.cgi?id=1157462 http://bugzilla.suse.com/show_bug.cgi?id=1157462#c11 --- Comment #11 from Simon Lees <simonf.lees(a)suse.com> --- (In reply to Dr. Werner Fink from comment #10) > (In reply to Simon Lees from comment #9) > > (In reply to Dr. Werner Fink from comment #8) > > > SR#752324 -- could one have a review? Other than me! > > > > Sorry due to timezones I was done for Friday when you sent this, doing the > > update was on my today list if I hadn't heard a good reason to keep > > --enable-asserts. > > > > I this using --disable-asserts would be better then adding another patch, > > its also now how debian handle it. > > https://salsa.debian.org/utopia-team/dbus/blob/debian/master/debian/rules > > The udeb_configure_flags rule with --disable-asserts is used for the udeb > packages and those type of packages are only for internal build system for > debian packages. > > The patch is also from debian (not utopia!) Utopia is the team maintaining dbus within debian according to there documentation, It can also be confirmed by the fact that almost all the commits there are from debians dbus maintainer @smcv > > --- a/dbus/dbus-internals.c > +++ b/dbus/dbus-internals.c > @@ -185,7 +185,7 @@ const char *_dbus_no_memory_message = "Not enough > memory"; > > static dbus_bool_t warn_initted = FALSE; > static dbus_bool_t fatal_warnings = FALSE; > -static dbus_bool_t fatal_warnings_on_check_failed = TRUE; > +static dbus_bool_t fatal_warnings_on_check_failed = FALSE; > > static void > init_warnings(void) > > could you please explain what is wrong with this approach? If you like to > debug you are able to set the environment variable DBUS_FATAL_WARNINGS to 1. > Currently we do not set DBUS_FATAL_WARNINGS at all, that is with the current > default all customers and users out there do debugging their systems and do > not know about nor can handle this. This causes a lot of trouble and > bugzilla entries. Debian dropped this patch at the start of last year (see below), Red Hat doesn't carry it (atleast centos) which makes me nervous being the only distro using and testing the patch, it means that no one is really looking at what is going on after the abort meaning there could end up being any form of data corruption or security issues hiding after in failure code paths that no one is testing. I wouldn't really be comfortable without going through and having a good look at whats happening after. Currently I don't have time for that. * d/p/debian/Don-t-abort-on-fatal-warnings-by-default.patch: Remove patch. This was committed not long after the addition of the fatal-by-default _dbus_warn_check_failed() checks for programming errors, with the changelog message "This will be set to upstream default again at some point so if you have an application that prints a DBus warning get it fixed". -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1158159] Leap 15.2 fallout from GNOME update
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1158159 Ludwig Nussel <lnussel(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |1158161 -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1158158] New: openSUSE:Leap:15.2:Staging:B/python3-doc failed
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1158158 Bug ID: 1158158 Summary: openSUSE:Leap:15.2:Staging:B/python3-doc failed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other URL: https://build.opensuse.org/package/live_build_log/open SUSE:Leap:15.2:Staging:B/python3-doc/standard/x86_64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSUSE:Leap:15.2:Staging:B/python3-doc failed to build. Please see build log: https://build.opensuse.org/package/live_build_log/openSUSE:Leap:15.2:Stagin… -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1158035] Emacs: Unable to use pdflatex in LaTeX mode
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.suse.com/show_bug.cgi?id=1158035 http://bugzilla.suse.com/show_bug.cgi?id=1158035#c3 --- Comment #3 from Dr. Werner Fink <werner(a)suse.com> --- Other than AuC-TeX is IMHO not useful ... as texlive has nowadays four different engines like old LaTeX/TeX, LuaTeX, Omega, and XeTeX engine. And pdf generation is an option for all engines. I'm always used and still use Auc-TeX the last twenty years now. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1158154] New: home:oojah:mqtt/mosquitto: Bug cannot find RPM builds for Centos 6 and RedHat 6
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1158154 Bug ID: 1158154 Summary: home:oojah:mqtt/mosquitto: Bug cannot find RPM builds for Centos 6 and RedHat 6 Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: RHEL 6 Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: roger(a)atchoo.org Reporter: cesarjorgemartinez(a)gmail.com QA Contact: bnc-team-screening(a)forge.provo.novell.com Found By: --- Blocker: --- Hi, We cannot find the RPM builds for Centos 6 and RedHat 6 here: http://download.opensuse.org/repositories/home:/oojah:/mqtt/RedHat_RHEL-6/h… http://download.opensuse.org/repositories/home:/oojah:/mqtt/CentOS_CentOS-6… And we need also update the Mosquitto version to 1.6.7. Regards, Cesar jorge -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1157806] logical deadlock
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.suse.com/show_bug.cgi?id=1157806 http://bugzilla.suse.com/show_bug.cgi?id=1157806#c3 --- Comment #3 from Tomáš Chvátal <tchvatal(a)suse.com> --- (In reply to a b from comment #2) > To avoid missunderstandings: do you expect me to pick the code from > libreoffice.org or from > https://download.opensuse.org/repositories/LibreOffice:/ ? I would aim for https://download.opensuse.org/repositories/LibreOffice:/6.3/ as that one should be safe for you. But if you want the upstream one it should make no difference in this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1122561] New: Out of date package: openSUSE:Factory/mongodb is out of date
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1122561 Bug ID: 1122561 Summary: Out of date package: openSUSE:Factory/mongodb is out of date Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: sean(a)suspend.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- openSUSE:Factory/mongodb is out of date. Current upstream is available at: https://fastdl.mongodb.org/src/mongodb-src-r4.0.5.tar.gz. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1122267] New: MongoDB SSPL v1 license and the DFSG
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1122267 Bug ID: 1122267 Summary: MongoDB SSPL v1 license and the DFSG Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ilya(a)ilya.pp.ua QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Here is the original text from the Debian bugzilla. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537 I would like your opinion on whether MongoDB's new SSPL license is suitable for inclusion in the main archive. To give a bit of background, MongoDB was previously distributed under a mixed AGPL-3.0/Apache-2.0 license. On 2018-10-15, upstream did a commit replacing AGPL-3.0 with the new Server Side Public License Version 1[1] — of which MongoDB is the steward. The same change was backported to two stable branches, with the 3.6.9 and 4.0.4 stable revisions carrying the new license. MongoDB has submitted the license to OSI for review[2]; the discussion there is still ongoing, but the initial response seems to be negative. In essence, the license (at least v1 which is currently in use) is almost identical to AGPL-3.0, with the exception of Section 13, which states: > 13. Offering the Program as a Service. > > If you make the functionality of the Program or a modified version > available to third parties as a service, you must make the Service > Source Code available via network download to everyone at no charge, > under the terms of this License. Making the functionality of the > Program or modified version available to third parties as a service > includes, without limitation, enabling third parties to interact with > the functionality of the Program or modified version remotely through > a computer network, offering a service the value of which entirely or > primarily derives from the value of the Program or modified version, > or offering a service that accomplishes for users the primary purpose > of the Program or modified version. > > “Service Source Code” means the Corresponding Source for the Program > or the modified version, and the Corresponding Source for all programs > that you use to make the Program or modified version available as a > service, including, without limitation, management software, user > interfaces, application program interfaces, automation software, > monitoring software, backup software, storage software and hosting > software, all such that a user could run an instance of the service > using the Service Source Code you make available. What this section says (at least to my eyes), is that the SSPL requires *all software* interfacing with MongoDB to form a "service" to be licensed under the SSPL too. This is a much broader restriction than linking, but still does not seem to violate DFSG #9. It is also not a universal restriction, but one that is based on use/field of endeavor: + The same ancillary software, when made part of a "MongoDB service", must be licensed under the SSPL, while when used for other purposes may carry any license. + Conversely, when building a service around MongoDB, you are only allowed to use SSPL-licensed software to build that service, something that may turn out to be impractical or even impossible. Note that this does not violate DFSG #6, as it does not prohibit *using* MongoDB itself for specific purposes, but it places heavy restrictions on *other* software you are able to use alongside MongoDB to build a service (for instance you can use bacula to backup your personal MongoDB instance, but you can't use bacula to backup your MongoDB-as-a-service unless bacula switches to SSPL). This has been somewhat rectified in v2, which was submitted to OSI for review[3], but the spirit remains. Also note that judging whether something is a "MongoDB service" depends on how much of its value it derives from MongoDB, or whether its primary purpose is "MongoDB", criteria that are both rather vague in themselves. Finally, I worry that "enabling third parties to interact with the functionality of the Program […] remotely through a computer network" could be interpreted to also include Debian packages, in which case the above restrictions would apply to the Debian infrastructure as well. Given the above and the fact that I'm not aware of any similar precedent in the archive, I would like your opinion on the license's DFSG compatibility. My personal view is that while the license does not violate the DFSG directly, it also does not agree with the DFSG's spirit (esp. DFSG #6). If we deem the license to be DFSG-incompatible, then MongoDB will most likely have to be removed from the archive eventually; keeping the last AGPL-licensed version around without the ability to cherry-pick commits from upstream is not viable (definitely so for inclusion in stable), given the size and the complexity of the codebase. Regards, Apollon -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1158111] New: virt-manager fails to create a ppc64le virtual machine
by bugzilla_noreply＠novell.com 02 Dec '19

02 Dec '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1158111 Bug ID: 1158111 Summary: virt-manager fails to create a ppc64le virtual machine Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Tools Assignee: virt-bugs(a)suse.de Reporter: tjcw(a)cantab.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 825241 --> http://bugzilla.opensuse.org/attachment.cgi?id=825241&action=edit Screenshot of boot failure I am running Tumbleweed 20191128 on an x86-64 system. I want to install a ppc64le virtual machine from the ubuntu-18.04.3-server-ppc64el.iso DVD image. When I try this using virt-manager, the DVD fails to boot with a message about 'Not a bootable device!' ; see attached screenshot. virt-manager works properly for this under OpenSUSE Leap 15.1 . Also qemu-system-ppc64 -cdrom ubuntu-18.04.3-server-ppc64el.iso -m size=1024 boots as far as the ubuntu installer, but this system has no virtual disk so I cannot install with it. Also this command seems to take 2 passes through the grub menu before it boots. To reproduce the problem, install the 'kvm' virtualisation software and the 'qemu-ppc' package. Then virt-manager 'create a new virtual machine' offers an architecture option ppc64le and a machine type pseries. Point it as the ubuntu-18.04.3-server-ppc64el.iso file which is downloadable from http://cdimage.ubuntu.com/releases/18.04/release/ubuntu-18.04.3-server-ppc6… . Tumbleweed worked for this about a year ago; between then and now, qemu has changed from v3 to v4. -- You are receiving this mail because: You are on the CC list for the bug.

1 7