Search results for

New Tumbleweed snapshot 20240318 released!

by Dominique Leuenberger

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: akonadi discover6 dolphin exempi (2.6.3 -> 2.6.5) ffmpegthumbs gcc13 glibc kf6-kconfig kio-extras kmail libavif (1.0.3 -> 1.0.4) libopenmpt (0.7.3 -> 0.7.5) libplasma6 plasma6-workspace python-importlib-metadata (7.0.1 -> 7.0.2) python-pyOpenSSL (24.0.0 -> 24.1.0) python-rich (13.7.0 -> 13.7.1) qt6-declarative timezone virglrenderer (1.0.0 -> 1.0.1) wavpack (5.6.0 -> 5.7.0) yast2-bootloader (5.0.6 -> 5.0.7) yast2-trans (84.87.20240309.6826dab25a -> 84.87.20240317.9b1b5b2b95) === Details === ==== akonadi ==== Subpackages: akonadi-lang libKPim6AkonadiAgentBase6 libKPim6AkonadiCore6 libKPim6AkonadiPrivate6 libKPim6AkonadiWidgets6 libKPim6AkonadiXml6 - Make sure the old translation package gets uninstalled (boo#1221515) ==== discover6 ==== Subpackages: discover6-backend-flatpak discover6-backend-fwupd discover6-backend-packagekit discover6-lang discover6-notifier - Update recommended packages - Also obsolete plasma5-pk-updates-lang ==== dolphin ==== Subpackages: dolphin-part dolphin-part-lang dolphin-zsh-completion libdolphinvcs6 - Add upstream fix for disappearing panels (boo#1221513): * 0001-Remove-unneeded-code-for-toggeling-dockwidget-visibi.patch ==== exempi ==== Version update (2.6.3 -> 2.6.5) - update to 2.6.5: * Update XMPCore to Adobe XMP SDK v2023.12 - Bug fixes - C++17 compliance changes - Changes to remove deprecated APIs - Removing unimplemented APIs in XMPUtils header * Fix a potential nullptr dereference. * Update XMPCore to Adobe XMP SDK v2023.07 - Security Fixes. - Fix Exif Date missing seconds values. https://github.com/adobe/XMP-Toolkit-SDK/issues/50 * Fix some portability build issues with dlopen on BSD: * Added missing file type constants from the XMP_SDK. ==== ffmpegthumbs ==== - Add a kf5 flavor for applications not ported yet to Qt6 (boo#1221502, kde#483741) ==== gcc13 ==== Subpackages: cpp13 gcc13-locale libgccjit0-gcc13 libstdc++6-devel-gcc13 - Revert libgccjit dependency change. [boo#1220724] ==== glibc ==== Subpackages: glibc-32bit glibc-devel glibc-extra glibc-lang glibc-locale glibc-locale-base nscd - stdbit-builtins.patch: Use gcc __builtin_stdc_* builtins in stdbit.h if possible - sigisemptyset.patch: linux/sigsetops: fix type confusion (BZ #31468) - duplocale-global-locale.patch: duplocale: protect use of global locale (bsc#1220441, BZ #23970) ==== kf6-kconfig ==== Subpackages: kconf_update6 kf6-kconfig-imports libKF6ConfigCore6 libKF6ConfigCore6-lang libKF6ConfigGui6 libKF6ConfigQml6 - Add patch to fix missing config migration (kde#483795): * 0001-kconf_update-Also-run-.upd-files-if-times-match-but-.patch ==== kio-extras ==== Subpackages: kio-extras-lang libkioarchive6-6 - Make kio-extras conflict with kio-extras5 versions older than 24.02.0 - Recommend ffmpegthumbs ==== kmail ==== Subpackages: kmail-application-icons kmail-lang ktnef - Add fix for a potential kontact crash (kde#483844): * 0001-Fix-483844-kontact-segfaults-on-startup.patch ==== libavif ==== Version update (1.0.3 -> 1.0.4) - update to 1.0.4: * AVIF_ENABLE_WERROR is set to OFF by default. * Fix wrong alpha plane deallocation when decoded tile pixel format does not match reconstructed output image pixel format * Fix identical chunk skipping optimization when writing animation data * Fix ID selection for artificial grid alpha item when decoding a grid of tiles which each have an associated auxiliary alpha image item (https://crbug.com/oss-fuzz/65657) ==== libopenmpt ==== Version update (0.7.3 -> 0.7.5) - Update to 0.7.5: * [Sec] Null-pointer write (32bit platforms) or excessive memory allocation (64bit platforms) when reading close to 4GiB of data from unseekable files.. * [Sec] Write buffer overflow when reading unseekable files close to 4GiB in size. * [Sec] Possible out-of-memory (32bit platforms) or excessive memory allocation (64bit platforms) when reading malformed data from unseekable files. * [Sec] DMF: Possible null-pointer write or excessive memory allocation when reading DMF files. * IT: In the previous version, Zxx macros in IT files made with older MPT versions were no longer working. * There was a periodic click when playing a module using the Chorus or Flanger DMO plugin at a mix rate exceeding ~136.5 kHz. * An older bugfix for undefined behaviour in the Distortion DMO plugin was incorrect, causing the distorted sound to be different in some situations. * xmp-openmpt: Metadata retrievel for playlist items was broken. - Changes in 0.7.4: * [Bug] Makefile: libopenmpt 0.7.3 broke running the test suite for Emscripten builds. * openmpt123: openmpt123 now uses a narrower layout on terminal windows with a width of less than 72 characters. * Setting all possible load_skip flags resulted in nothing being loaded at all, instead of just not loading the selected module parts. * When playing all subsongs, set_position_seconds didnât always calculate the correct subsong to jump to. * IT: A few more compatibility flags are now disabled for modules saved with earlier Schism Tracker versions. * IT: MIDI macros were reset in IT 2.14 / 2.15 files that declared to be compatible with older IT versions (fixes spx-visionsofthepast.it). * OKT: Work around missing negative arpeggio implementation by transposing the notes up an octave. * OKT: Channel volume commands were sometimes lost over less important effects. * IMF: Ignore magic bytes in sample header. âLeaving All Behindâ by Karsten Koch uses unexpected magic bytes, Orpheus ignores them just like the instrument header magic bytes. ==== libplasma6 ==== Subpackages: libPlasma6 libPlasma6-lang libplasma6-components libplasma6-desktoptheme - Work around %preun in installed packages killing the session during upgrade (boo#1221405) ==== plasma6-workspace ==== Subpackages: plasma6-session plasma6-session-x11 plasma6-workspace-lang plasma6-workspace-libs sddm-qt6-branding-openSUSE - Let plasma6-session-x11 provide+obsolete plasma5-session to ensure that upgrades end up with the X11 session as well. ==== python-importlib-metadata ==== Version update (7.0.1 -> 7.0.2) - update to 7.0.2: * No significant changes. ==== python-pyOpenSSL ==== Version update (24.0.0 -> 24.1.0) - update to 24.1.0: * Removed the deprecated OpenSSL.crypto.PKCS12 and OpenSSL.crypto.NetscapeSPKI. OpenSSL.crypto.PKCS12 may be replaced by the PKCS#12 APIs in the cryptography package. ==== python-rich ==== Version update (13.7.0 -> 13.7.1) - update to 13.7.1: * Fixes some character widths ==== qt6-declarative ==== Subpackages: libQt6LabsAnimation6 libQt6LabsFolderListModel6 libQt6LabsQmlModels6 libQt6LabsSettings6 libQt6LabsSharedImage6 libQt6LabsWavefrontMesh6 libQt6Qml6 libQt6QmlCore6 libQt6QmlLocalStorage6 libQt6QmlModels6 libQt6QmlWorkerScript6 libQt6QmlXmlListModel6 libQt6Quick6 libQt6QuickControls2-6 libQt6QuickControls2Impl6 libQt6QuickDialogs2-6 libQt6QuickDialogs2QuickImpl6 libQt6QuickDialogs2Utils6 libQt6QuickEffects6 libQt6QuickLayouts6 libQt6QuickParticles6 libQt6QuickShapes6 libQt6QuickTemplates2-6 libQt6QuickTest6 libQt6QuickWidgets6 qt6-declarative-imports - Add patch to help fix PointHandler with HiDPI (kde#482580) - 0001-Fix-PointHandler-rejecting-click-events-near-window-.patch ==== timezone ==== - Drop the timezone-java (bsc#1213470). After thorough consideration of possible problems that arise from having a timezone package specifically for the Java ecosystem, Fridrich Strba and I have decided to drop the package altogether. Doing so means the JDK will use its built-in timezone data that is updated quarterly, when refreshed JDK versions are released. While this does mean there could be situations where there is a bit of a mismatch between the 'timezone' package's data, and the data that is used by JDK, in practice the difference will be minimal and short-lived. So we've established this to be the best course of action. - Remove _multibuild, not longer required. ==== virglrenderer ==== Version update (1.0.0 -> 1.0.1) - update to 1.0.1: * Fix 17 bugs, most of them securety related * Fix a number of issues uncovered by Coverity * Add meson option to enable unstable APIs and add the info to pkg-config * vtest: Stabilize protocol version 3 ==== wavpack ==== Version update (5.6.0 -> 5.7.0) - update to 5.7.0: * added: multithreaded encoding and decoding to libwavpack (optional) * added: option to specify multithreading in CLI programs (--threads) * added: multithreading support to Cool Edit filter (always enabled) * added: support for ID3v2.4 when importing tags (--import-id3) * added: optional bitrate specification to wavpack -c option * added: recognize WAV files with new fourcc of 'BW64' * fixed: decode non-compliant FFmpeg files over 8 channels * fixed: accept some common but non-compliant AIFF files * fixed: automatically delete newly obsolete correction files * fixed: don't delete source files if data loss warnings occur * improved: ID3v2 tag support (more items, multiple values, pics, etc) * improved: compression of 32-bit integer files (--optimize-int32) * improved: convert the man pages to mdoc(7) * improved: cmake & autoconf support - Build AVX2 enabled hwcaps library for x86_64-v3 ==== yast2-bootloader ==== Version update (5.0.6 -> 5.0.7) - Improve warnings and help text for secure boot on s390 to reflect state with new hardware. (bsc#1219989) - 5.0.7 ==== yast2-trans ==== Version update (84.87.20240309.6826dab25a -> 84.87.20240317.9b1b5b2b95) Subpackages: yast2-trans-af yast2-trans-ar yast2-trans-bg yast2-trans-bn yast2-trans-bs yast2-trans-ca yast2-trans-cs yast2-trans-cy yast2-trans-da yast2-trans-de yast2-trans-el yast2-trans-en_GB yast2-trans-es yast2-trans-et yast2-trans-fa yast2-trans-fi yast2-trans-fr yast2-trans-gl yast2-trans-gu yast2-trans-hi yast2-trans-hr yast2-trans-hu yast2-trans-id yast2-trans-it yast2-trans-ja yast2-trans-jv yast2-trans-ka yast2-trans-km yast2-trans-ko yast2-trans-lo yast2-trans-lt yast2-trans-mk yast2-trans-mr yast2-trans-nb yast2-trans-nl yast2-trans-pa yast2-trans-pl yast2-trans-pt yast2-trans-pt_BR yast2-trans-ro yast2-trans-ru yast2-trans-si yast2-trans-sk yast2-trans-sl yast2-trans-sr yast2-trans-sv yast2-trans-ta yast2-trans-th yast2-trans-tr yast2-trans-uk yast2-trans-vi yast2-trans-wa yast2-trans-xh yast2-trans-zh_CN yast2-trans-zh_TW yast2-trans-zu - Update to version 84.87.20240317.9b1b5b2b95: * Translated using Weblate (Catalan) * Translated using Weblate (Slovak) * Translated using Weblate (Dutch) * Translated using Weblate (Indonesian) * Translated using Weblate (Japanese) * New POT for text domain 'bootloader'. * New POT for text domain 'registration'. * New POT for text domain 'packager'. * Translated using Weblate (French) * Added translation using Weblate (French) * Translated using Weblate (Catalan)

7 months, 2 weeks

Re: [factory] pre-UEFI systems now require additional UEFI+ components???

by Felix Miata

Felix Miata composed on 2024-03-12 04:25 (UTC-0400): > Andrei Borzenkov composed on 2024-03-12 09:55 (UTC+0300): >> Felix Miata wrote: >>> This is new since under a week ago. When adding a longterm kernel it was a >>> simple matter of installing the kernel-longterm rpm. Not any more: >>> # grep yReq /etc/zypp/zypp.conf >>> solver.onlyRequires = true >>> # inxi -M | grep BIOS >>> BIOS: Phoenix v: 6.00 PG date: 06/27/2006 >>> # inxi -S >>> System: >>> Host: k8mmv Kernel: 6.6.11-1-default arch: x86_64 bits: 64 >>> Console: pty pts/0 Distro: openSUSE Tumbleweed 20240310 >>> # time zypper -v in kernel-longterm >>> ... >>> The following 15 NEW packages are going to be installed: >>> efibootmgr 18-1.5 >>> jq 1.7.1-1.2 >>> kernel-longterm 6.6.21-1.1 >>> libefivar1 38-2.2 >>> libjq1 1.7.1-1.2 >>> libonig5 6.9.9-1.2 >>> libtss2-esys0 4.0.1-4.2 >>> libtss2-mu0 4.0.1-4.2 >>> libtss2-rc0 4.0.1-4.2 >>> libtss2-sys1 4.0.1-4.2 >>> libtss2-tcti-device0 4.0.1-4.2 >>> pcr-oracle 0.5.4-4.1 >>> sdbootutil 1+git20240215.cb7e392-1.1 >>> sdbootutil-rpm-scriptlets 1+git20240215.cb7e392-1.1 >>> systemd-boot 254.9-2.1 >>> The following package requires a system reboot: >>> kernel-longterm 6.6.21-1.1 >>> 15 new packages to install. >>> Overall download size: 1.1 MiB. Already cached: 164.1 MiB. After the operation, additional 241.2 MiB will be used. >>> Note: System reboot required. >>> Continue? [y/n/v/...? shows all options] (y): >>> If I try to download in advance and install with rpm, this results: >>> # rpm -ivh /nfs/00srv/pub/Linux/Suse/Factory/kernel-longterm-6.6.18-1.1.x86_64.rpm >>> error: Failed dependencies: >>> suse-kernel-rpm-scriptlets is needed by kernel-longterm-6.6.18-1.1.x86_64 >>> # zypper -v in suse-kernel-rpm-scriptlets >>> ... >>> The following 14 NEW packages are going to be installed: >>> efibootmgr 18-1.5 >>> jq 1.7.1-1.2 >>> libefivar1 38-2.2 >>> libjq1 1.7.1-1.2 >>> libonig5 6.9.9-1.2 >>> libtss2-esys0 4.0.1-4.2 >>> libtss2-mu0 4.0.1-4.2 >>> libtss2-rc0 4.0.1-4.2 >>> libtss2-sys1 4.0.1-4.2 >>> libtss2-tcti-device0 4.0.1-4.2 >>> pcr-oracle 0.5.4-4.1 >>> sdbootutil 1+git20240215.cb7e392-1.1 >>> sdbootutil-rpm-scriptlets 1+git20240215.cb7e392-1.1 >>> systemd-boot 254.9-2.1 >>> 14 new packages to install. >>> Overall download size: 1.1 MiB. Already cached: 163.1 KiB. After the operation, additional 3.1 MiB will be used. >>> Continue? [y/n/v/...? shows all options] (y): n >>> Is it intended that all TW installations now must include these *efi* >>> and related packages? >> andrei@tumbleweed:~> zypper se --provides -x suse-kernel-rpm-scriptlets >> Loading repository data... >> Reading installed packages... >> S | Name | Summary >> | Type ---+------------------------------+--------------------------------------------------+-------- >> i+ | sdbootutil-rpm-scriptlets | Scripts to create boot entries on >> kernel updates | package >> | suse-module-tools-scriptlets | Kernel rpm scriptlets >> | package >> andrei@tumbleweed:~> >> Nothing prevents you from installing suse-module-tools-scriptlets. >> Whether it should be default is certainly subject to discussion. > Thank you yet again for identifying what I failed to see. Martin Wilck's > 16.0.43-508.1 had been installed, but I removed it /along with/ suse-modules-tools > using rpm --nodeps and followed it up by only installing OSS's 16.0.43-1.1 > suse-module-tools prior to the zypper dup that found no corresponding need for the > absent suse-module-tools-scriptlets, followed by kernel longterm installation > attempt. :p Possibly more context helps explain? # grep suse-module-tools /var/log/zypp/history | tail 2023-11-17 01:39:46|install|suse-module-tools-scriptlets|16.0.38-1.1|x86_64||OSS|97e4209838ad4c0c9b46aa051dd4eab5c4ddfcb78f7652b90e847e286b7f5a9285b91d71ea3f3dc0fe7545a3d4c36c84745972cf6c84b3830a5b9997c3fb2d3c| 2024-01-25 12:58:48|install|suse-module-tools|16.0.42-1.1|x86_64||OSS|a32aa21ca3ddc326c889617b473b235f668153cbbab4c1fff563f0d17e40fd07cfc2c00aacba9c5334f41f06852df7550c55ec6dc3bbe3fb88fc07350afb5e73| 2024-01-25 13:00:04|install|suse-module-tools-scriptlets|16.0.42-1.1|x86_64||OSS|a12571f6cf6ba3fb5645a0166537f434d3ec35b6f279b1b67ff43a5ef41944e1e7a9fd7af19af21b0c68ef10ccc0240ea5f4428a21ca0d16031a8b96eb2e13f6| 2024-01-25 13:09:10|command|root@k8mmv|'zypper' '-v' 'in' 'suse-module-tools-16.0.43' 'suse-module-tools-scriptlets-16.0.43'| 2024-01-25 13:09:15|install|suse-module-tools|16.0.43-508.1|x86_64|root@k8mmv|homeMwilckSMT|85d1779a78392c536766231fb9d544f9d428a986c84a5e7ef67432b956312b31fb28d49f8e4f34121b02c5927502dc6b026faf2910911961355f5ef2dacf3d82| 2024-01-25 13:09:19|install|suse-module-tools-scriptlets|16.0.43-508.1|x86_64|root@k8mmv|homeMwilckSMT|e7d607e216e9bd22bdfff65ca237e8e66dab848deb1eb26c4b5e6a6e9c93d48efb30ceda5208a93acfa426302e1b3e2100f8807a6ac78e10924a17e8482bfccc| 2024-03-11 22:41:01|command|root@k8mmv|'zypper' '-v' 'in' 'suse-module-tools'| 2024-03-11 22:41:03|install|suse-module-tools|16.0.43-1.1|x86_64|root@k8mmv|OSS|5f724f12e6d6d9b7832413cc22d3c37dc14c1c8c5c2f9aa6ee1ee811ce64fc0b574d3c9ff18d5402dfab6905f0c0e6d8e9fd4c2f89dffa36f63c1f7a069691ea| 2024-03-12 04:23:13|command|root@k8mmv|'zypper' '-v' 'in' 'suse-module-tools-scriptlets'| 2024-03-12 04:23:14|install|suse-module-tools-scriptlets|16.0.43-1.1|x86_64|root@k8mmv|OSS|78712187e512cf30a7d7721201295a9507b54bbf5a58e97899097ce78d5190d66771a2a696ebacd532aa972a094c0658451b48cf2596eed1781d00976d7f35ce| # rpm -qa | egrep 'boot|efi|grub|rpm|suse-mod' | sort gfxboot-4.5.93-1.2.x86_64 gfxboot-branding-openSUSE-84.87.20230227-4.3.noarch grub-0.97-203.7.x86_64 rpm-4.19.1.1-3.1.x86_64 rpm-config-SUSE-20240214-1.1.noarch ruby3.3-rubygem-cfa_grub2-2.0.0-1.21.x86_64 ruby3.3-rubygem-gem2rpm-0.10.1-23.1.x86_64 suse-module-tools-16.0.43-1.1.x86_64 suse-module-tools-scriptlets-16.0.43-1.1.x86_64 systemd-rpm-macros-24-1.5.noarch trinity-tdenetwork-tdefile-plugins-14.1.1-1.osstw.x86_64 yast2-bootloader-5.0.6-1.1.x86_64 # At the time of "zypper -v in kernel-longterm", I had rpm -e --nodeps removed suse-module-tool*. I have grub2* installed only on UEFI hosts. All others either retain Grub Legacy, or have no bootloader installed. -- 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

7 months, 2 weeks

Re: [factory] pre-UEFI systems now require additional UEFI+ components???

by Andrei Borzenkov

On 19.03.2024 18:29, Ludwig Nussel wrote: > Andrei Borzenkov wrote: >> On 16.03.2024 02:16, Martin Wilck via openSUSE Factory wrote: >>> On Tue, 2024-03-12 at 09:55 +0300, Andrei Borzenkov wrote: >>>> >>>> andrei@tumbleweed:~> zypper se --provides -x suse-kernel-rpm- >>>> scriptlets >>>> Loading repository data... >>>> Reading installed packages... >>>> >>>> S | Name | Summary >>>> | Type >>>> ---+------------------------------+---------------------------------- >>>> ----------------+-------- >>>> i+ | sdbootutil-rpm-scriptlets | Scripts to create boot entries on >>>> kernel updates | package >>>> | suse-module-tools-scriptlets | Kernel rpm scriptlets >>>> | package >>>> andrei@tumbleweed:~> >>>> >>>> Nothing prevents you from installing suse-module-tools-scriptlets. >>>> Whether it should be default is certainly subject to discussion. >>> >>> I'd expect it would still be, at least as long as sd-boot officially >>> becomes the bootloader of choice in openSUSE. >>> >>> Martin >> >> Then something needs >> >> Suggests: suse-module-tools-scriptlets > > So far sdbootutil-rpm-scriptlets conflicted with grub2. So unless the > system in question uses a custom boot loader I don't see how there's > even a choice. > Well, "no bootloader" is a valid choice in YaST, but I agree, this should be rather niche case.

7 months, 2 weeks

kind (Kubernetes in Docker), podman, cgroup controllers and Delegate=yes

by Johannes Kastl

Hi all, I packaged kind (Kubernetes in Docker) for openSUSE, as I needed it for a demo at work. The package works, but I noticed something along the way. > https://build.opensuse.org/package/show/devel:kubic/kind The kind docs state how to enable systemd "delegation" for a user, i.e. the cgroup controllers are delegated to the user. https://kind.sigs.k8s.io/docs/user/rootless/ I tried that on my openSUSE tumbleweed machine, and did not work. I added another directory /etc/systemd/system/user(a)1234.service.d (where 1234 is my uid on the machine, the account comes from LDAP), put the file in it and it also did not work. After several reboots and switching from 'yes' to 'True' and back, I could get it to work. And today it no longer works. Or so I thought. I think I have narrowed it down to "login shells have more cgroup controllers in the output of 'podman info'". Which means I can only use this on one of the virtual terminals, not inside Plasma or tmux or screen. I can prefix the command with "systemd-run --user --scope --property=Delegate=yes", but that makes it a little awkward. So, what would be the best way to solve this? How to get systemd to actually respect the files when starting Plasma? Without konsole having to start a login shell for each window? And regarding packaging, I dropped the idea of shipping the file in /etc/systemd/system/user@.service.d/ (or similar), but would add a README pointing to the docs. For the next one having this issue... :-( Kind Regards, Johannes

7 months, 2 weeks

Re: LLVM version pinning in spec file

by Aaron Puchert

Am 19.03.24 um 08:11 schrieb Shung-Hsi Yu: > Right now I'm using the suggestion in SR#1134405, aligning to > PostgreSQL's approach (product_libs_llvm_ver is defined in project > config to the latest major LLVM version): > > %if 0%{?product_libs_llvm_ver} > 17 > %define llvm_major_version 17 > %else > %define llvm_major_version %{nil} > %endif > ... > BuildRequires: llvm%{llvm_major_version}-devel The advantage of this approach is that you get the newest version that is (a) contained in the distribution and (b) supported by the package. On Tumbleweed, the package is typically the limiting factor, but on Leap you might actually support a newer LLVM than what is available. This will just select the highest version available then. > But I ran into unresolvable build for bpftrace[1] on OBS with the error > message: > > conflict for providers of llvm-devel needed by bcc-devel, (provider > llvm-devel obsoletes llvm17-devel) > > I'm guessing this comes from the following dependency tree: > > bpftrace --> llvm17-devel (product_libs_llvm_ver is 18) > | > +------> bcc-devel -----> llvm-devel[2] > (back when product_libs_llvm_ver was 17?) You should probably only use llvm-devel for BuildRequires, and then add Requires corresponding to the version it was built with. The best way to do it would probably be BuildRequires: llvm%{llvm_major_version}-devel Requires: llvm%{_llvm_sonum}-devel This uses the macro defined in %{_rpmconfigdir}/macros.d/macros.llvm, which is part of llvmX-devel. By writing it like that, the package gets a requirement to the LLVM version it was built with, ensuring ABI compatibility. Best regards, Aaron

7 months, 2 weeks

Re: maintaining musique: any interest?

by Scott Beamer

On 3/19/24 06:31, Martin Winter wrote: > > It looks like the upstream app author would need to do a decent > amount of work to adapt to the up-to-date taglib, based on what's > described in the "TagLib 2.0 Release - Jan 24, 2024" section here: > https://taglib.org/ > > I just checked how much effort it would be. It is limited to renaming > some occurrences of ItemListMap to ItemMap. ItemListMap was deprecated > since TagLib 1.10 released 9 years ago. At the same time ItemMap was > introduced as an alternative. > > > If any users want to be able to use it on Tumbleweed, it seems they > could be directed to file an issue at > https://github.com/flaviotordini/musique/issues for the work to update > the TagLib version compatibility (since such an issue doesn't yet > exist, interestingly)? > > I just opened such an issue. I think upstream could just replace that. > In the meantime I could just provide a patch. > > If nobody else is interested under these circumstances I could also > take over maintainership, even if I also don't use that program actively. > > Martin That would be great. I just learned of this program the other day and was sad to see there weren't any openSUSE packages. Scott

7 months, 2 weeks

Re: maintaining musique: any interest?

by John Kizer

It looks like the upstream app author would need to do a decent amount of work to adapt to the up-to-date taglib, based on what's described in the "TagLib 2.0 Release - Jan 24, 2024" section here: https://taglib.org/ So it would seem to fair to say that it's fundamentally incompatible with the current base of software that's out there, and therefore can't plausibly be packaged anymore anyway? I don't see any other distros out there with up-to-date taglib and up-to-date musique. If any users want to be able to use it on Tumbleweed, it seems they could be directed to file an issue at https://github.com/flaviotordini/musique/issues for the work to update the TagLib version compatibility (since such an issue doesn't yet exist, interestingly)? Thanks, John Kizer

7 months, 2 weeks

Re: maintaining musique: any interest?

by Richard Biener

On Mon, 18 Mar 2024, John Kizer via openSUSE Factory wrote: > It looks like the upstream app author would need to do a decent amount of work to adapt to the up-to-date taglib, based on what's described in the "TagLib 2.0 Release - Jan 24, 2024" section here: https://taglib.org/ > > So it would seem to fair to say that it's fundamentally incompatible > with the current base of software that's out there, and therefore can't > plausibly be packaged anymore anyway? I don't see any other distros out > there with up-to-date taglib and up-to-date musique. It might be sensible(?) and possible to build an old working TagLib from within musique and link it statically into the application for the time being. Iff musique is not the only victim having a secondary old taglib is another possibility. Of course only if there's an actual interest in continuing to have musique. Richard. -- Richard Biener <rguenther(a)suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

7 months, 2 weeks

Re: KDE Megarelease 6 in TW snapshot 20240311

by Roger Oberholtzer

My update failed. At some point when doing the installs, the system rebooted automatically. And I had a new sddm login screen, where I was expecting to see the completed zypper dup. On one display was a virtual keyboard, and on another was the sddm login. But with complaints about missing things. And a login failed, returning me back to the sddm login. The rollback failed. So I had to delete snapshots by hand to get to where I was before the attempted update. And now most of my system is read-only, even though the mounts are all rw. So, generally speaking, not a successful update. I'm now trying to see how to make the system not be read-only. The snapshot I am in is the most recent. On Sat, Mar 16, 2024 at 10:44 PM Alessio Biancalana via openSUSE Factory < factory(a)lists.opensuse.org> wrote: > For what it’s worth I had basically the same experience as Oliver, I don’t > remember if I had to just wait for the next snapshot or the next two. > > From my point of view (I’m trying to just use Wayland) I had to set again > the scaling factor to 200% for my 4K monitor and I noticed I have two VLCs > now, one installed via zypper, one installed via flatpak. Did it become an > hard dependency or what? I didn’t remember to have the zypper one before. > Maybe it’s just me tho. > > Apart from that, everything working pretty great on the laptop I’m using > with Plasma 6. Keep it up! > > Alessio > > > Il giorno 16 mar 2024, alle ore 10:30, Oliver Schwabedissen < > oliver(a)schwabedissen.name> ha scritto: > > > > For me, the update resulted in an unusable system. I updated from > snapshot 20240310 (probably not a "very old system") to snapshot 20240314. > So not only from Plasma5 to Plasma6, but also from kernel 6.7.7 to kernel > 6.7.9. > > > > As with some others, the KDE session crashed after about 2/3 of the > installation. The system did not reboot but did a complete shutdown. On > reboot I received several kernel error messages, presumably because the > postinstall scripts could not be executed. The system booted up to a gray > screen with 3 green squares. Nothing happened after that. > > > > I then switched to a previous snapshot (snapper rollback) and was able > to start the system again. > > > > Since I installed the "tumbleweed" package, I was then able to perform > the update step by step: > > > > Switch to a textmode console, init 3, tumbleweed switch 20240311, zypper > dup. > > > > I then rebooted and repeated the procedure, this time switching to > snapshot 20240313. > > > > Finally, do the same again with snapshot 20240314. > > > > After the 3rd reboot, the system started with Plasma6 without any > problems. But although I had previously worked exclusively with X11 and > Plasma5, I was forced to use Wayland. X11 was not available on the login > screen. I therefore installed plasma6-session-x11 and can now work with X11 > and Plasma6. > > > > Let's see what else no longer works as expected... > > > > Oliver > > > >> Am 13.03.24 um 20:41 schrieb Fabian Vogt: > >> Hi, > >> > >> the next TW snapshot 20240311 contains KDE Plasma 6.0.1, Gear 24.02.0 > and > >> Frameworks 6.0.0: https://kde.org/announcements/megarelease/6/ > >> > >> Plasma 5 will be replaced, it is no longer part of the repository. > >> > >> There are a few minor issues in this snapshot found by openQA but not > >> considered severe enough to actually block the snapshot from getting > >> published. They'll all be fixed with Plasma 6.0.2 in one of the next > >> snapshots, also for those installing or upgrading now. > >> > >> 1. For fresh installs, the GTK theme is not set correctly: > >> https://bugs.kde.org/show_bug.cgi?id=482763 > >> Workaround is to either set it manually in systemsettings or run > "kded5" once > >> in a terminal or krunner. > >> > >> 2. For upgrades (any version), the launcher icon switches to the Plasma > one: > >> https://github.com/openSUSE/plasma-opensuse/pull/25 > >> Workaround is to change the icon manually to "start-here-branding" for > now. > >> > >> 3. Upgrades from very old systems fail due to "libksysguard5-helper": > >> https://bugzilla.opensuse.org/show_bug.cgi?id=1221350 > >> When upgrading from Leap <= 15.3, you might encounter > >> > >> Problem: libksysguard5-plugins-5.27.10-2.2.x86_64 requires > >> libprocesscore.so.9()(64bit), but this requirement cannot be provided > >> > >> As workaround, select the "deinstallation of libksysguard5-helper" > option. > >> > >> 4. Plasmashell takes 25s during start if bluetooth not available: > >> https://bugs.kde.org/show_bug.cgi?id=481870 > >> If kdeconnect-kde is installed on a system without bluetooth HW, it > delays > >> Plasma start by 25s. Workaround is to disable the KDE Connect systray > icon. > >> > >> 5. The etesync resource is broken in kdepim-runtime 24.02.0. It will be > back in > >> one of the next snapshots. > >> > >> The Wayland session isn't default yet, that will have to be switched in > a > >> separate step later. This also makes it possible to differentiate > whether bugs > >> are more likely caused by Plasma 6 itself or the Wayland session. > >> > >> Have a lot of fun, > >> the openSUSE KDE packaging team > >> > > > > -- > > PGP Public Key available at https://pgp.mit.edu/ > > Key fingerprint = 3264 280C 05B1 572F 3F0B 42B8 1E7B 2D9D 063B D507 > -- Roger Oberholtzer

7 months, 2 weeks

Slowroll zypper dup keeps reinstalling the same kernel

by Larry Len Rainey

7 months, 2 weeks

openSUSE Factory search results for query "a"