Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 04/04/2024 15:24, Eddie Chapman wrote: Since there appears to be some interest I'll put together a single email to the list later today detailing everything, as I needed to do more things overall in addition to replacing /usr/bin/xz. Below is a guide I've written to removing app-arch/xz-utils in case anyone else wants to do so. Attached is the current version of the Bash wrapper script I now use in place of /usr/bin/xz Comments, corrections on anything technical in the guide or script are welcome, apart from flames about how this is ridiculous and unnecessary :-). Best wishes, Eddie Guide to removing xz utils on a Gentoo system === Introduction === This guide is for people who wish to remove xz utils (app-arch/xz-utils) from a Gentoo system. I've been able to remove xz utils from two Gentoo workstations with 2412 packages and KDE 5.x as the desktop, and it has not been painful at all. I've gone on to remove it from several Gentoo server systems without any pain. These are all SElinux systems. In this guide we replace app-arch/xz-utils with app-arch/p7zip which will do all the work of uncompressing xz distfiles for Portage going forward. It works perfectly fine for that right now. I've written a bash wrapper script which is designed to be installed as /usr/bin/xz, which is referred to in the instructions below. It is attached to this email as xz.txt. It tries to takes care of decompressing .xz files transparently whenever Portage runs /usr/bin/xz, by behaving like it but using app-arch/p7zip in the background. You will need it if you want to get rid of app-arch/xz-utils. But don't blindly use it, check it yourself first of course. If you don't like it you will either need to write your own script, or hack emerge/Portage in various places to use something else to decompress xz files. You're mileage may vary with any of this, proceed at your own risk, don't blame me if you break your system or lose data. === Warnings / Caveats / Breakages === Before you do this, you should identify whether you have applications or scripts which use the Tukaani xz utils, or that link against liblzma.so.5. This could include non-Gentoo apps or scripts you run which call any of the xz utils (xz, unxz, xzgrep|xzegrep|xzfgrep, xzcat, xzcmp, xzdec, xzdiff, lzma, unlzma, lzgrep|lzegrep|lzfgrep, lzmainfo, lzmadec, lzcmp, lzdiff, lzcat). Those programs will all be gone, so you should not do this if you want or need them and cannot use alternatives. 99% of packages in Gentoo work fine without xz utils, it's just that some might optionally link against liblzma.so.5 in order to provide support for xz (de)compression along with other algorithms. We will rebuild those packages so they don't link against liblzma.so.5 anymore. xx utils is a relative newcomer to the Linux/OSS/GNU world so you will find there aren't any low level system packages that absolutely need it to do their main job. You are highly unlikely to render your system completely unbootable doing this. But removing it does carry some risk. You might discover along the way there is some application you have installed that cannot function without xz utils. You might just have to uninstall it and find an alternative, if the situation cannot be resolved by creating your own custom ebuild and tweaking configure/meson options. But worst case if you have to uninstall a package and other packages depend on it, you might have to remove them too, and I'm sure you know how that remove list can potentially turn into a long one once all deps are worked out. You will lose some things. I've had to uninstall the following two packages for now: media-gfx/gimp kde-apps/ark (and kde-apps/kdeutils-meta which depends on it) (I'll probably figure out later how to coax them into working without xz. There might even be upstream updates soon that make xz optional, who knows. I'll also need to add to my world file at some point everything that was in kde-apps/kdeutils-meta.) If you run another desktop (e.g. Gnome) I've no idea what might or might not need xz utils. The situation with your desktop environment may be worse, more painful, or impossible. You will lose lzma support in the core Python language (dev-lang/python) in 3.x versions and higher (not sure when exactly support was introduced but 2.7 does not have it, 3.11 & 3.12 do), so if you have python scripts that happen to need that, well, they will definitely throw a big error after this :-) But I was able to rebuild the 179 dev-python packages on my workstations and everything in app-portage and none of them complained. I've been able to go on and do plenty of rebuilding with Portage after this without any problem, so core Python functionality in Gentoo is fine (although see next paragraph about Gemato). There is one significant thing that breaks, which is Gemato (app-portage/gemato). Gemato requires lzma support in core python in order
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
> On Sat, 06 Apr 2024, Eddie Chapman wrote: > [...] this is ridiculous and unnecessary :-). Indeed. SCNR, Ulrich
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 2024.04.06 12:57, Eddie Chapman wrote: > On 04/04/2024 15:24, Eddie Chapman wrote: > > Since there appears to be some interest I'll put together a single > email > > to the list later today detailing everything, as I needed to do more > > things overall in addition to replacing /usr/bin/xz. > > Below is a guide I've written to removing app-arch/xz-utils in case > anyone else wants to do so. Attached is the current version of the > Bash > wrapper script I now use in place of /usr/bin/xz > > Comments, corrections on anything technical in the guide or script are > > welcome, apart from flames about how this is ridiculous and > unnecessary :-). > > Best wishes, > Eddie > >[snip method] "Because I can" is a good enough reason to do anything with Gentoo. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods arm64 pgpwyJRBN8PRl.pgp Description: PGP signature
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 06-04-2024 12:57:23 +0100, Eddie Chapman wrote: > There is one significant thing that breaks, which is Gemato > (app-portage/gemato). Gemato requires lzma support in core python in > order to do GPG signature verification. This means you will have to say > goodbye (for now) to verifying upstream GPG signatures on distfiles, and > verification of Portage metadata after doing an emerge --sync. These > features have been added to Portage relatively recently (2022?) so are > "nice to have", without them your system is just less hardened, but > still with the very high level of security that Gentoo systems have has > always had prior to these features, in my opinion. Personally I can live > without them for now. Verifying hashes in Manifest files still works > fine and that's the main thing. You may disagree in which case, well, > don't do this then. I'm going to figure out an alternative way I can > verify Portage metadata soon, as there are other ways if you are creative. If you just want to verify signatures and manifests after sync, qmanifest from portage-utils can help you do this. Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
[gentoo-dev] Update on the 23.0 profiles
Hi all, so here's a small update on the state of the 23.0 profiles: * For all arches, the 23.0 profiles are now marked at the same stability status (mostly for the CI and pkgcheck) as before the 17.x profiles. Most 17.x profiles have been downgraded to "exp". * All stage downloads (with the exception of hppa, where our builder is a tad slow) are now based on 23.0. * For all ISO / other boot media, the specs have been changed as of today, so that the next succeeding build will also be based on 23.0. The new builds need testing, so if you happen to have suitable hardware around... * With that we can nail down the timetable for the next steps: 2024-06-06 (in 2 months): deprecation of the 17.x profiles; binpkg builders for the 17.x profiles are stopped 2025-06-06 (1 year later): removal of the 17.x profiles from profiles.desc -??-?? (when infra has moved :o): removal of the 17.x profile trees in gentoo.git Comments and feedback welcome. I would really prefer to *not* extend the time until deprecation though, since maintenance (and CPU time) goes down as soon as we don't build twice the amount of packages... In general, our installation ISO need in my opinion some review regarding the package set and the detailed build instructions. As long as they work that is not really urgent though. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Eddie Chapman writes: > On 04/04/2024 15:24, Eddie Chapman wrote: >> Since there appears to be some interest I'll put together a single email >> to the list later today detailing everything, as I needed to do more >> things overall in addition to replacing /usr/bin/xz. > > Below is a guide I've written to removing app-arch/xz-utils in case > anyone else wants to do so. Attached is the current version of the > Bash wrapper script I now use in place of /usr/bin/xz > > Comments, corrections on anything technical in the guide or script are > welcome, apart from flames about how this is ridiculous and > unnecessary :-). For an experiment I'm doing (distinct from trying to purge xz-utils, just verification work), I've packaged the following: * app-arch/gxz (pure Go impl.) * app-arch/7zip (7zip upstream are supporting Linux now, app-arch/p7zip was an unofficial port) You might find those useful too. At a glance, it appears https://github.com/fpgaminer/rust-lzma and https://github.com/gendx/lzma-rs don't provide executables - just a library - so I didn't bother looking further. > > Best wishes, > Eddie > > > Guide to removing xz utils on a Gentoo system > > [...] > There is one significant thing that breaks, which is Gemato > (app-portage/gemato). Gemato requires lzma support in core python in > order to do GPG signature verification. This means you will have to > say goodbye (for now) to verifying upstream GPG signatures on > distfiles, and verification of Portage metadata after doing an emerge > --sync. These features have been added to Portage relatively recently > (2022?) so are "nice to have", without them your system is just less No.. much older. It was introduced around the time of the github mirror being hacked. It's not just theatre! Like, this is very much NOT hypothetical. It's not just about metadata, it's about the ebuilds if using rsync, or the whole git checkout if using git. > hardened, but still with the very high level of security that Gentoo > systems have has always had prior to these features, in my > opinion. Personally I can live without them for now. Verifying hashes > in Manifest files still works fine and that's the main thing. You may > disagree in which case, well, don't do this then. I'm going to figure > out an alternative way I can verify Portage metadata soon, as there > are other ways if you are creative. See grobian's reply which should help. > [...] > - Portage binary packages: You cannot use xz compression if you create > Portage binary packages. You will need to use one of bzip2, gzip, > lz4, lzip, lzop, or zstd in BINPKG_COMPRESS in make.conf instead of > xz (if that is what you were using, or is it the default?). I have zstd is the default for "new" installs (since a few years ago), yeah. > [...] > - sys-apps/fwupd might stop working properly (though it will still > build fine) due to what you have to change with dev-libs/libxmlb > below. I'm not sure as I haven't checked yet, I just suspect it > will. So bear that in mind if you need to rely on sys-apps/fwupd at > the moment. But this "might" is temporary, upstream has now decided > to make lzma optional, so this will trickle down to Gentoo soon. Just for completeness, this is https://blogs.gnome.org/hughsie/2024/04/03/fwupd-and-xz-metadata/. > [...]
[gentoo-dev] Last-rites: KDE Telepathy and net-libs/telepathy-logger-qt
# Andreas Sturmlechner (2024-04-06) # Dead upstream, as is the whole telepathy stack. Some parts depend on # dev-qt/qtwebengine:5. # Removal on 2024-05-06. Bug #926679 kde-apps/ktp-accounts-kcm kde-apps/ktp-approver kde-apps/ktp-auth-handler kde-apps/ktp-common-internals kde-apps/ktp-contact-list kde-apps/ktp-contact-runner kde-apps/ktp-desktop-applets kde-apps/ktp-filetransfer-handler kde-apps/ktp-kded-module kde-apps/ktp-send-file kde-apps/ktp-text-ui kde-apps/plasma-telepathy-meta net-libs/telepathy-logger-qt signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: telepathy related packages
On Freitag, 25. November 2022 04:24:15 MESZ Matt Turner wrote: > GNOME 43 will no longer need these packages. They seem to be in varying > states of decay upstream. > > - net-im/telepathy-connection-managers > - net-libs/farstream > - net-libs/sofia-sip > - net-libs/telepathy-farstream > - net-voip/telepathy-gabble > - net-voip/telepathy-rakia > - net-voip/telepathy-salut > > [...] > > I've dropped gnome@ as a maintainer of all of these packages. # Andreas Sturmlechner (2024-04-06) # Dead upstream for many years, in a state of decay and no revdeps. # Removal on 2024-05-06. Bug #926193 net-im/telepathy-connection-managers net-libs/sofia-sip net-libs/telepathy-accounts-signon net-libs/telepathy-farstream net-libs/telepathy-qt net-voip/telepathy-gabble net-voip/telepathy-rakia net-voip/telepathy-salut Note: This is leaving net-libs/farstream in ::gentoo since there are revdeps, both also unmaintained though: - net-im/gajim[jingle] - x11-plugins/pidgin-sipe[voice] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Update on the 23.0 profiles
On Sat, 2024-04-06 at 17:06 +0200, Andreas K. Huettel wrote: > Hi all, > > so here's a small update on the state of the 23.0 profiles: > Why was this silently added to make.defaults for all 23.0 profiles? > # This just makes sense nowadays, if only for distfiles... > USE="lzma zstd" It doesn't help with distfiles in any way, wasn't discussed here, doesn't belong there, and creates a mess on systems where they should be disabled. Use per-package defaults if they're important for certain packages.
Re: [gentoo-dev] Last-rites: telepathy related packages
On Sat, 2024-04-06 at 21:20 +0200, Andreas Sturmlechner wrote: > > # Andreas Sturmlechner (2024-04-06) > # Dead upstream for many years, in a state of decay and no revdeps. > # Removal on 2024-05-06. Bug #926193 > net-libs/sofia-sip This package also has open security bugs. I've added the relevant bug to the mask message. Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Fabian Groffen wrote: > If you just want to verify signatures and manifests after sync, > qmanifest from portage-utils can help you do this. > > Thanks, > Fabian Thanks for the pointer, and I see you are one of the authors, thanks for writing a very useful tool!
