Re: Question for fellow retro-computers : building kdelibs4 without nepomuk?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Trinity (TDE) Desktop Users]     [Fedora KDE]     [Fedora Desktop]     [Linux Kernel]     [Gimp]     [GIMP for Windows]     [Gnome]     [Yosemite Hiking]
  Powered by Linux