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@git.gentoo.org/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