René J.V. Bertin posted on Fri, 24 May 2024 12:38:29 +0200 as excerpted: > On Friday May 24 2024 04:37:39 Duncan wrote: > >>As I recall, for most of kde4, even with semantic-desktop disabled (to >>the degree possible) > > Do you happen to have a pointer to the most recent version of the patch > you mentioned? Any patches would be in the git repositories. The main gentoo repo carries both ~arch (testing) and arch-stabilized versions (and patches); the gentoo/kde project carries any betas/rcs not around long enough for the main repo along with live-git versions (both release-branch and master), with a project-repo first policy so everything that hits the main repo (barring limited integration stuff added to the main repo by others and synced back to the project repo) hits the gentoo/kde repo first. Organization of both repos is by package category (kde-frameworks, kde- apps, etc), package, with metadata and eclass (ebuild libraries used by many package ebuilds) directories also at the category level. Patches then appear in the files subdir within the package dir (within the category dir). Patch names generally contain the version number the patch was originally built for (tho it generally applies to later versions to... until it doesn't as it was upstreamed or upstream changed and the patch is rebased and retitled accordingly), and the patches themselves have a comment (often the same as the corresponding git log entry) at the top saying what they do. Of course for kde I generally use the live ebuilds so most closely follow the gentoo/kde repo, but the main gentoo repo should contain the last carried (probably the last released but as I'm "live" I don't follow kde in the main repo closely enough to know) 4.x version. Links: Gentoo/kde project git (choose your access method) https://gitweb.gentoo.org/proj/kde.git/ https://anongit.gentoo.org/git/proj/kde.git git+ssh://git@xxxxxxxxxxxxxx/proj/kde.git Also mirrored to github: https://github.com/gentoo-mirror/kde.git Gentoo main repo git: https://gitweb.gentoo.org/repo/gentoo.git/ (and presumably the other two methods too...) github mirror: https://github.com/gentoo-mirror/gentoo Meanwhile, probably more of interest to other gentooers than to you... while digging up the above I came across this page listing all the gentoo hosted repos including all sorts of niche and user repos, and was just /amazed/. https://gitweb.gentoo.org/ >>if you're on Intel-Mac hardware, > > Apple haven't yet ditched all support for the Intel architecture (though > surely will sooner rather than later given their track record in > dropping support for older models). The problem is that this entire > effort focusses on models even older than my own 2011 Mac. Heh. 2011 sounds familiar. My primary system's still a 2011 AMD fx6100 (three compute-modules, each with a pair of single-thread intteger cores sharing a single floating-point unit, so hardware 6-thread for integer, effectively hyperthreaded for floating point). I'm long since upgraded to SSDs, upgraded the graphics and have good monitors, but that 2011 fx is really getting a bit long in the tooth for building gentoo and I've been reluctantly using prebuilt binaries for the bigger packages (like the browsers, I'm avoiding qtwebengine, see below) as they're like 8-hour builds for a single package. (I can still do live- git kde due only to a smart-rebuild script that only rebuilds on update, and ccache caching the build artifacts so there's little actually recompiling in the usual case. The first rebuild after a qt or or gcc upgrade is murder tho, as that invalidates all the ccached build artifacts.) (I've been saying "this year" on an upgrade for three years now, but while the money's actually been in the bank for it for half that, turns out I kind of /like/ having that additional financial cushion, and between that and not having appropriate receiving arrangements to ship a multi- thousand-dollar computer...) > One of the big hurdles with KF5 was that Qt5 introduced their version of > KStandardPaths, and gave it a "proper Mac-native implementation". KDE > migrated to that class, but never bothered to update their build system. > So while the code is perfectly capable to find its runtime resources > where Qt says they should be, the build system installs them to the > places where the XDG standard says they should go. Yes, I actually had problems with qt5 in a similar context. But of course I'm on Linux and my case is was due to my "reverse-usrmerge" -- /usr -> . symlink so /bin and /lib(64) become the primary locations instead of /usr/bin and /usr/lib. (A more normal usrmerge has /bin -> /usr/bin and /lib(64) -> /usr/lib(64) instead, so the /usr locations are primary.) When qt5 did its thing with its standard paths its build system correctly detected and set the /lib64 and /bin locations, but the gentoo ebuilds still were coded for and installed to the /usr/* locations (reverse- usrmerge isn't an officially gentoo-supported option, but the general policy is do what you want as long as you can manage it, patch it when necessary, etc, and my guess is that many, perhaps most, gentooers who remain with it long enough, end up with their own not officially supported local installation quirks of one form or another... that quirk-friendly policy being one of the benefits of gentoo that make it worth sticking with for those who care for such things). I ended up with patches or sed- scripts (both auto-applied-on-update) to a few gentoo ebuilds to s:/usr::, where they hard-coded /usr in the build, plus a few bugs filed with upstream kde that turned out to be due to bad path-comparisons (one side was using the canonical path, the other the symlink path), resolved when they fixed it (for other bugs, mine were never actually traced) so both sides used the canonical path. FWIW I've not had similar problems with the qt6 build system and was able to drop my gentoo ebuild patches/seds (with the upstream kde fix still in place too). Like I said, I've noticed a /much/ more port-friendly "run it where you want to" upstream kde policy lately. While some devs don't care to do the extra work for such things themselves, often there's others within kde working on it, and the general policy is if you don't want to do it, fine, but don't get in the way of others that do. There was a discussion on the kde-core list not long ago where this played out, and (separately) I've seen the implications in the form of reverted commits because they can't depend on that version yet because the CI for some platform (Android, MSWindows, the BSDs with active kde support and devs, I believe I've seen Macs on the list too) doesn't have it yet, etc. I've also seen it in the willingness to give for example gentoo/kde devs commit rights (so it's not just author:gentoodev, it's also committedby:gentoodev, in the upstream kde git log) for patches to for example make building tests truly optional at build time (gentoo's often end-deployment-level builds without necessarily wanting build-time tests use-case tends to catch this sort of error more than most upstream or binary-distro developer use-cases would, because they tend to build and run tests, while their end-users don't build at all). Now, the cycle is submit the patch as a PR and get it approved, after which the distro-dev can apply it themselves, while before it was submit the PR, get it approved, wait for an upstream dev to apply it. OTOH, often mistakenly applied commits (by upstream core devs) get reverted due to lack of approval or because it breaks CI with an older version, as well. As I said, /much/ friendlier to downstreams, Linux or other platforms, than previously. Which was why I said if you ware starting from scratch it would likely be easier to do with qt6/kde6, because they're much more supportive of such things now than they were. But you're not starting from scratch, so... > One of the more OCD-pedantic Plasma developers even once said that he > felt like breaking all possibilities to build "his" code on the "wrong" > platform, "just because he could". These days there'd be significant pressure on such a developer to at least let others support those platforms even if they weren't interested... or "use their talents elsewhere" if they weren't willing to do that. And I'll just leave that right there, as any more would break my "if I'm not making a positive contribution I shouldn't be posting" personal policy... > I never even bothered with KDEPim5, actually. Partly because even > test-driving it means you can't go back to KDEPim4, partly because > another OCD-pedantic dev decided it'd use QtWebEngine throughout, which > is complete overkill for just displaying HTML email. I jumped off the kdepim train when kmail jumped the akonadi shark in mid- kde4 and wanted a full database installation just to do mail (badly, because the database kept corrupting). So I missed the kdepim5 qtwebenginification entirely. Unfortunately, kde6 in general has gone the same way with all the local help documentation, qtwebenginifying khelpcenter, which displays the kde help "handbooks". Without khelpcenter the default loads the online help from the web using the default browser, even if the documentation is installed locally and in theory they could load it in the browser locally. Since I've been on kde for years I don't use the help much, and I have cable internet, so that has been "OK-ish" here. And I set USE=-handbook (gentoo's method of turning off the individual kde app documentation build options) so the packages don't install the would-be-unused documentation, so it works. If I used the handbooks enough to care (or I was paying per-MB/GB for internet use), I'd probably just create a bash wrapper for the browser and call it khelpcenter, avoiding both the remote load of not having it, and the heavy and insecure dep of qtwebengine, which FWIW gentoo now ships with this disclaimer: >>> This version of Qt WebEngine is based on Chromium version ${QT6_CHROMIUM_VER}, with additional security fixes up to ${QT6_CHROMIUM_PATCHES_VER}. Extensive as it is, the list of backports is impossible to evaluate, but always bound to be behind Chromium's release schedule. In addition, various online services may deny service based on an outdated user agent version (and/or other checks). Google is already known to do so. tl;dr your web browsing experience will be compromised. <<< While neither the security nor "browsing experience" points apply to trusted/curated content such as these handbooks, it *definitely* applies untrusted mail that could be from *anyone*. (Ironic case in point: One of my credit card banks keeps sending me email saying I'm not reading their email. I most certainly am, but they most certainly won't know it because my email client doesn't blindly execute HTML from untrusted mail, thus not activating their web bugs and whatever other malware they have in their email. Meanwhile, my security policy of never clicking on links in emails claiming to be from the bank, actually going to the site using my preconfigured and trusted link and loading whatever from there instead, means the trackers in those links never activate. Given the implications I stopped using that card for general purchases and only use it for a pre-scheduled monthly charge of a fixed value (that I'll eventually drop as well), so I'll quickly know if their security behavior is similar to that they expect, almost demand, from their customers, and my account is breached due to /them/, not me.) So I guess I'm glad kdepim jumping the akonadi shark got me off of it before it jumped the qtwebengine shark as well! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman