June 2023 - openSUSE Factory - openSUSE Mailing Lists

New Tumbleweed snapshot 20230622 released!
by Dominique Leuenberger 23 Jun '23

23 Jun '23

Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&versio… Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: brltty evolution icu (73.1 -> 73.2) libevdev (1.13.0 -> 1.13.1) librsvg libwebp nghttp2 (1.53.0 -> 1.54.0) nodejs20 (20.3.0 -> 20.3.1) open-vm-tools openexr (3.1.7 -> 3.1.8) python-gobject subversion tiff (4.5.0 -> 4.5.1) zlib-ng-compat (2.0.7 -> 2.1.2) === Details === ==== brltty ==== Subpackages: brltty-driver-at-spi2 brltty-driver-brlapi brltty-driver-speech-dispatcher brltty-driver-xwindow brltty-lang libbrlapi0_8 python3-brlapi system-user-brltty xbrlapi - Use conditionals for sysusers_requires to allow quilt setup - Remove workarounds for old TCL - Enable parallel build again - Don't use %tmpfiles_create_package anymore. This macro cannot work on transactional systems. However this macro was supposed to be used only when the tmpfiles stuff was needed in advance, which doesn't seem to be the case for brltty. ==== evolution ==== Subpackages: evolution-lang evolution-plugin-spamassassin - Add abdcc5af227972da8db1731f05e66a14eb4f6656.patch: fix "HTML attachment viewport is tiny" (glgo#GNOME/evolution#2400). ==== icu ==== Version update (73.1 -> 73.2) Subpackages: libicu73 libicu73-ledata - Update to release 73.2 * CLDR extends the support for âshortâ Chinese sort orders to cover some additional, required characters for Level 2. This is carried over into ICU collation. * ICU has a modified character conversion table, mapping some GB18030 characters to Unicode characters that were encoded after GB18030-2005. - Delete icu-UCHAR-uint16t.patch (merged) ==== libevdev ==== Version update (1.13.0 -> 1.13.1) Subpackages: libevdev-tools libevdev2 - update to 1.13.1: * include: sync event codes with kernel 6.2 * CI fixes ==== librsvg ==== Subpackages: gdk-pixbuf-loader-rsvg librsvg-2-2 rsvg-thumbnailer typelib-1_0-Rsvg-2_0 - Use %build_rustflags instead of the deprecated %__default_rustflags macro. Requires at least cargo-packaging 1.2.0+3 (boo#1212333). ==== libwebp ==== Subpackages: libsharpyuv0 libwebp7 libwebpdemux2 libwebpmux3 - Add libwebp-double-free.patch: Avoid a double free, upstream commit a486d800 (bsc#1210212 CVE-2023-1999). ==== nghttp2 ==== Version update (1.53.0 -> 1.54.0) - update to 1.54.0: * nghttpx: Consistent error handling and use of high-level API * h2load: Fix http3 upload stall * h2load: Use std::chrono::steady_clock for quic timestamp ==== nodejs20 ==== Version update (20.3.0 -> 20.3.1) Subpackages: npm20 - Update to version 20.3.1 (security fixes only). The following CVEs are fixed in this release: * (CVE-2023-30581, bsc#1212574): mainModule.__proto__ Bypass Experimental Policy Mechanism (High) * (CVE-2023-30584, bsc#1212575): Path Traversal Bypass in Experimental Permission Model (High) * (CVE-2023-30587, bsc#1212576): Bypass of Experimental Permission Model via Node.js Inspector (High) * (CVE-2023-30582, bsc#1212577): Inadequate Permission Model Allows Unauthorized File Watching (Medium) * (CVE-2023-30583, bsc#1212578): Bypass of Experimental Permission Model via fs.openAsBlob() (Medium) * (CVE-2023-30585, bsc#1212579): Privilege escalation via Malicious Registry Key manipulation during Node.js installer repair process (Medium) * (CVE-2023-30586, bsc#1212580): Bypass of Experimental Permission Model via Arbitrary OpenSSL Engines (Medium) * (CVE-2023-30588, bsc#1212581): Process interuption due to invalid Public Key information in x509 certificates (Medium) * (CVE-2023-30589, bsc#1212582): HTTP Request Smuggling via Empty headers separated by CR (Medium) * (CVE-2023-30590, bsc#1212583): DiffieHellman does not generate keys after setting a private key (Medium) ==== open-vm-tools ==== Subpackages: libvmtools0 open-vm-tools-desktop - Fix (bsc#1212143) - (CVE-2023-20867) - VUL-0: CVE-2023-20867: open-vm-tools: Authentication Bypass vulnerability in the vgauth module + Add patch: 2023-20867-Remove-some-dead-code.patch ==== openexr ==== Version update (3.1.7 -> 3.1.8) Subpackages: libIex-3_1-30 libIlmThread-3_1-30 libOpenEXR-3_1-30 - update to 3.1.8: * Support for DWA compression in OpenEXRCore * Fix OSS-fuzz 59070 Stack-buffer-overflow in DwaCompressor_readChannelRules ==== python-gobject ==== Subpackages: python311-gobject python311-gobject-Gdk python311-gobject-cairo - Add %{?sle15_python_module_pythons}: build additional python flavors besides the 'default' when building for SLE15. ==== subversion ==== Subpackages: libsvn_auth_gnome_keyring-1-0 libsvn_auth_kwallet-1-0 subversion-bash-completion subversion-perl - Update _constraints to avoid some aarch64 workers for subversion:testsuite to avoid to hang ==== tiff ==== Version update (4.5.0 -> 4.5.1) - Update to version 4.5.1: * Definition of tags reformatted (clang-format off) for better readability of tag comments in tiff.h and tif_dirinfo.c * Do not install libtiff-4.pc when tiff-install is reset. * Add versioninfo resource files for DLL and tools compiled with Windows MSVC and MINGW. * Disable clang-formatting for tif_config.h.cmake.in and tiffconf.h.cmake.in because sensitive for CMake scripts. * CMake: make WebP component name compatible with upstream ConfigWebP.cmake * CMake: make Findliblzma with upstream CMake config file * CMake: FindDeflate.cmake: fix several errors (issue #526). * CMake: FindLERC.cmake: version string return added. * CMake: export TiffConfig.cmake and TiffConfigVersion.cmake files * CMake: fix export of INTERFACE_INCLUDE_DIRECTORIES * Hardcode HOST_FILLORDER to FILLORDER_LSB2MSB and make 'H' flag of TIFFOpen() to warn and an alias of FILLORDER_MSB2LSB. tif_lerc.c: use WORDS_BIGENDIAN instead of HOST_BIGENDIAN. * Optimize relative seeking within TIFFSetDirectory() by using the learned list of IFD offsets. * Improve internal IFD offset and directory number map handling. * Behavior of TIFFOpen() mode "r+" in the Windows implementation adjusted to that of Linux. * TIFFDirectory td_fieldsset type changed from unsigned long, which can be 32 or 64 bits, to uint32_t (fixes issue #484). * tif_ojpeg.c: checking for division by zero (fixes issue #554). * LZWDecode(): avoid crash when trying to read again from a strip whith a missing end-of-information marker (fixes issue #548). * Fixed runtime error: applying zero offset to null pointer in countInkNamesString(). * Fixing crash in TIFFUnlinkDirectory() when called with directory number zero ("TIFFUnlinkDirectory(0)") as well as fixing incorrect behaviour when unlinking the first directory. * tif_luv: check and correct for NaN data in uv_encode() (issue #530). * TIFFClose() avoid NULL pointer dereferencing (issue #515). * tif_hash_set.c: include tif_hash_set.h after tif_config.h to let a chance for GDAL symbol renaming trick. * Fax3: fix failure to decode some fax3 number_of_images and add test for Fax3 decoding issues (issue #513). * TIFFSetDirectory() and TIFFWriteDirectorySec() avoid harmless unsigned-integer-overflow (due to gdal oss-fuzz #54311 and #54343). * tif_ojpeg.c: fix issue #554 by checking for division by zero in OJPEGWriteHeaderInfo(). * LZWDecode(): avoid crash when trying to read again from a strip whith a missing end-of-information marker (issue #548). - Drop no longer needed patches: * tiff-CVE-2023-0795,CVE-2023-0796,CVE-2023-0797,CVE-2023-0798,CVE-2023-0799.patch * tiff-CVE-2022-48281.patch * tiff-CVE-2023-0800,CVE-2023-0801,CVE-2023-0802,CVE-2023-0803,CVE-2023-0804.patch ==== zlib-ng-compat ==== Version update (2.0.7 -> 2.1.2) - Update to version 2.1.2: * Many improvements to the CMake scripts. * Improved support for detecting memory alignment functions. * Improved support for unaligned access by letting the compiler promote code to unaligned if supported by the CPU. * Remove x86 cpu feature detection for TZCNT, safely fallback to BSF. * Enable using AVX512 intrinsics with GCC <9. * Decompression is a lot faster (56% faster measured on AVX2-capable x86-64) * Compresson is improved for Level 9, at the cost of a little performance. * Compression is improved for Level 3, by switching from deflate_fast to deflate_medium. * Levels 3 and 4 have been reconfigured to provide a better gradual tradeoff for speed/compression between levels 2 and 5. * Deflate_quick (Level 1) has been improved to default to a bigger windowsize and support changing the window size like the other levels. * Deflate_rle has been optimized with its own compare_256 implementation. * Adler32 implementation using AVX512, AVX512-VNNI, VMX. * CRC32-B implementation using VPCLMULQDQ & IBM-Z. * Slide hash implementation using VMX. * Compare256 implementations using SSE2, Neon, & POWER9. * Inflate chunk copying using SSSE3 & VSX.

1 0

btrfs - space_cache v1 or v2 ?
by Joe Salmeri 23 Jun '23

23 Jun '23

There seems to be conflicting documentation regarding btrfs space_cache v1 and v2 as to which is really the default. man 5 btrfs says: **space_cache, space_cache=<version>, nospace_cache (nospace_cachesince: 3.2, space_cache=v1and space_cache=v2since 4.5, *default: **space_cache=v1**) * There are two implementations of the free space cache. The original one, referred to as v1, is the safe default. The v1space cache can be disabled at mount time with nospace_cachewithout clearing. * If a version is not explicitly specified, the default implementation will be chosen, which is **v1**. ** * https://btrfs.readthedocs.io/en/latest/Administration.html says: (/nospace_cache/since: 3.2,/space_cache=v1/and/space_cache=v2/since 4.5, *default:****/space_cache=v2/**)* There are two implementations of the free space cache. *The original one, referred to as****/v1/**, used to be a safe default but has been superseded by****/v2/**.* The/v1/space cache can be disabled at mount time with/nospace_cache/without clearing. * If a version is not explicitly specified, the default implementation will be chosen, which is****/v2/**.* Does anyone know which documentation is correct ? I would have expected the man pages to be correct, however, it would appear to me they are outdated and the btrfs.readthedocs .io is probably more current. My TW installation is from before v2 existed, did all the zypper dups I've done since TW installation update my btrfs root to v2 or is this something we need to manually do? If it needs to be done, it looks like it is fairly easy to do for a non-root fs, via clearing and remounting, but is there any docs for the root fs ? Has anybody with older TW installs switched or did you just stay with v1 ? It seems like it matters most for large many TB fs and may not matter for smaller fs ( like say 500 GB ). -- Regards, Joe

3 8

RFC: turn off ppc32 and ppc64 big endian builds on openSUSE:Factory:PowerPC
by Fritz Hudnut 23 Jun '23

23 Jun '23

> > Hi Thomas! > > On Fri, 2023-06-23 at 09:52 +0200, Thomas Zimmermann via openSUSE Factory > wrote: > > I use ppc64 and ppc64le for testing various DRM drivers. The ppc64 > > variant is mostly interesting for its big-endian feature. > > > > I wasn't aware of the ppc32 build. Do you have a link to the installer > > ISO? I'm interested in trying it. > > If Debian is okay for your testing purposes, you can use the Debian images > I am creating on a regular basis. These always contain the latest kernel > in Debian unstable. > > See: > > > https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/ > > I would love to do the same for openSUSE, but I haven't found anyone to > help > me with the effort. > > Adrian > > > > > > There hasn't been an installer medium for ppc32 for like ever... only > > ppc64 and ppc64le; IIRC, ppc32 is 'only' enabled to provide multi-arch > > support (aka -32bit packages) to ppc64. > > > > All published artefacts for ppc64/ppc64le (and the ppc32 rpms) are at > > http://download.opensuse.org/ports/ppc/tumbleweed > > > > Cheers, > > Dominique > > > > PS: and the ppc64 installer does not work since a long time and nobody > > cared sufficiently to get this in shape: > > https://bugzilla.opensuse.org/show_bug.cgi?id=1205401 > > bug boils down to 'installation-images' not being buildable due to > > multiple deps being broken > > I have an older install that I kept up-tp-date from time to time. So I > didn't notice. > > > > > Until like 3 weeks ago, we wasted openQA cycles on it: > > > https://openqa.opensuse.org/tests/overview?distri=microos&distri=opensuse&v… > > Given your's and Adrian's answers, I think I can live without ppc32 and > ppc64. > > et al: PPC linux has been the bastard child of linux for many years, back in '07 roughly was when I was looking for something to keep my PPC machines running, but the project was more or less abandoned over time . . . . I still have an iBook 32 bit that runs I think I got it to lubuntu 18.04??? I might have known about the Debian option, but back around '12 I dropped out of Debian due to the unfriendly forum behaviors . . . . Now I have two 64 bit Debian installs on my '12 Mac Pro, both run fine, Sid and Bookworm. I would check into running a Debian install on the iBook, except for the 946MB of RAM that it came with . . . not enough RAM to do anything on the 'Net . . . . Sayonara to PPC32 bit services. : - 0 F

1 0

Tumbleweed - Review of the week 2023/25
by Dominique Leuenberger 23 Jun '23

23 Jun '23

Dear Tumbleweed users and hackers, Finally back on the weekly review cycle – are we taking bets on how long I can keep it up (summertime is ‘terrible’ – it motivates too much to take Fridays off). Anyway, even without me there, you are used to Tumbleweed rolling. Lately, all the excellent work on Staging Is being performed by Ana. During this week, we managed to publish again 6 snapshots (the 7th was in QA, but took slightly longer to test than the next one needed to build). The 6 snapshots (0614, 0616, 0617, 0619, 0620, and 0620) brought you those changes: * Python 3.11 has been set as the default Python interpreter * libzypp: fix for stricter http/2 RFC 9113 server implementations: trim custom headers * Qt 5.15.10 * PHP 8.1.20 * LibreOffice 7.5.4.2 * poppler 23.06.0 * LLVM 16.0.6 * node.JS 20.3.0 * Mozilla Firefox 114.0.2 * KDE Plasma 5.27.6 Integration tests are currently being performed on these planned changes: * Linux kernel 6.3.9 * Protobuf 22.5: please help to sort out the failures in Staging:K * util-linux 2.39 * Mesa 23.1.3 * PHP 8.2.7: Nextcloud was updated to 26.0.3, which claims to support PHP 8.2 Cheers, Dominique

1 0

Anyone willing to maintain ckb-next ?
by Luigi Baldoni 23 Jun '23

23 Jun '23

Hello, not using hardware/ckb-next myself and not able to test its functionality since I don't own any compatible hardware.

1 0

Re: No X after today's TW snapshot
by j.reitsma＠hccnet.nl 23 Jun '23

23 Jun '23

Knurpht-openSUSE schreef op 23-06-2023 00:48: > Op vrijdag 23 juni 2023 00:38:21 CEST schreef j.reitsma--- via openSUSE > Factory: >> Root fs is btrs, so maybe go to an older snapshot? Never done that, >> seems a bit complicated from what I read on documentatie of snapper... > sudo snapper list > produces a list of snapshots. Pick the snapshot number (####) from > before the > dup. Then do > sudo snapper rollback #### > Reboot and that's done Hmm, that's indeed a lot simpler than I though to have read, thanks. Funny thing is there seems to be a snapshot gap: there are no snapshots between 1429 (of March 29) and 1452 (the 'pre' of first snapshot yesterday). Rollled back 1439, and (after a few reboots) I have a functionaliteit system again. Thanks! Back to zypper dup now, hope there's a usable nvidia set now. Regards, Jogchum .

1 0

Packages changed: MozillaFirefox (114.0.1 -> 114.0.2)
by Fritz Hudnut 23 Jun '23

23 Jun '23

Your package management system installs applications from rpms provided by > openSUSE mirrors. Such installations depend on system provided libraries, > and show > up in application menus automatically. They default to the application's > automatic > updating being totally disabled, impossible to enable, so that the package > management system can do its job. > > Mozilla provides archived self-contained (static) binaries to extract into > /home, > /opt or /usr/local. Usually it's up to you to determine how to facilitate > starting > them. They do not appear in the distro's package managment database. Most > default > to automatically updating under the covers so that you don't even know if > or when > updating happens, except by checking what is the currently installed > version. > -- > Evolution as taught in public schools is, like religion, > based on faith, not based on science. > > Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! > > Felix Miata > Felix M: Thanks for the reply . . . not sure if I saw your name on the bugzilla #1212101 thread, but last week Firefox update caused it to crash on launch . . . and it seemed like it was figured out, just checking to see if the fix had made it into the regular zyppering. Folks were downloading from the Mozilla site to get the fix installed, etc. > > > I think it's pretty clear as you can see from the line > > "do not enable LTO as it caused crashes now (boo#1212101)" > > that the known crash from boo#1212101 has been fixed. > > There are other crash fixes from upstream in 114.0.2 apparently but > those are something different. > > Wolfgang > Wolfgang: OK, thanks for the confirmation on the availability of the fixed FF in zypper dup, as the line you mentioned, "do not enable LTO as it caused crashes now (boo#1212101)" seems to indicate "caution in the LTO enablement arena" rather than, "this is now fixed." But, glad to hear that it is ready for prime time again . . . except for the other upstream crashing. F F

1 0

No X after today's TW snapshot
by j.reitsma＠hccnet.nl 22 Jun '23

22 Jun '23

(Just sent it with a wrong se der address) Hi, Running zypper dup - no-vendor-change one of the problems zypper detected was a missing nvidia rpm from the TW repo. I decided to go for the optioneel to get it from nvidia's repo, but that appears not to be a wise decision: I have no X anymore. Kernel is 6.3.7-1-default. rpm -qa | grep nvidia gives nvidia-glG05-525.85.12-1.x86_64 (plus some other version 525 packages) kernel-firmware-nvidia-20230531-1.1.noarch What can I do to get X back? Root fs is btrs, so maybe go to an older snapshot? Never done that, seems a bit complicated from what I read on documentatie of snapper... OR deleting the current nvidia rpm's and restart zypper dup after refreshing? Any help appreciated! Regards, Jogchum

2 1

openSUSE:Factory - Build fail notification
by DimStar / Dominique Leuenberger 22 Jun '23

22 Jun '23

Dear Package maintainers and hackers. Below package(s) in openSUSE:Factory have had problems for at least 4 weeks. We tried to send out notifications to the configured bugowner/maintainers of the package(s), but so far no fix has been submitted. This probably means that the maintainer/bugowner did not yet find the time to look into the matter and he/she would certainly appreciate help to get this sorted. - obs-service-tar_scm: Unresolvable Unless somebody is stepping up and submitting fixes, the listed package(s) are going to be removed from openSUSE:Factory. Kind regards, DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>

1 0

Packages changed: MozillaFirefox (114.0.1 -> 114.0.2)
by Fritz Hudnut 22 Jun '23

22 Jun '23

> > MozillaFirefox (114.0.1 -> 114.0.2) > > > > ==== MozillaFirefox ==== > Version update (114.0.1 -> 114.0.2) > Subpackages: MozillaFirefox-translations-common > > - Mozilla Firefox 114.0.2: > * Several crash fixes > * Web Extensions: Fixes for 114 regressions in Native Messaging > support > - do not enable LTO as it caused crashes now (boo#1212101) > > > For those of us residing in the great unwashed end user realm . . . does this now mean that running a dup in TW or Gecko rolling will now provide the fixed Firefox?? Or we still would have to download the rpm from mozilla and install it?? I skipped the 1556 package upgrade for TW on Monday, as there was a "firefox" listed in the to be upgraded, but tomorrow will be rotating back to the Gecko rolling edition that did blunder into the "instant crash" problem . . . . Hoping and praying that I can blithely zypper it back into full function?? I have been scanning the bug report, and seeing the "LTO" problem, but, being unwashed I don't know what that is or if it applies, etc. F

3 2