Solving problems related to the support of this overlay. #181

We need to decide what to do next.

Main tasks:

It is necessary to decide how this overlay will develop.
It is necessary to determine the procedure for solving problems.

The first solution to the problem is to choose who will maintain the main branch.
Another solution to the problem:
I can create a branch where I configure eclass and add functionality to build using the admin package. On the basis of this branch, it will be possible to agree on further development.
Once everyone is happy with the solution, you can add this branch to the main branch.

I tried to merge different branches into one, it turned out only starting with update/14.0.8 and ending with features/tdemultimedia-stable. Everything else causes conflicts. I think that you can add these PR to the main branch, everything else will have to either be deleted, or on the basis of this already add your own. I posted the result of the merge in the other/admin-build branch. While you can try what happened.

Yeah, sorry about that. I think I did something wrong in terms of how I created the branches. (I mentioned that git and I don't get along, right?)

Yeah, sorry about that. I think I did something wrong in terms of how I created the branches. (I mentioned that git and I don’t get along, right?)

It’s just that you created too many new PR, it’s not surprising that in the end something went wrong. You also need to redo the stable starttde(scripts and TSM_EXTRACT) and tdm(FILESDIR...).

Added to the ability to build using the admin module. If you wish, you can move ebuilds from the other/trinity-nomodules branch. If no one objects, we can merge the other/admin branch into the master branch. At least this branch will merge into the main branch without issue.
I think it will be easy to add ebuilds from other/trinity-nomodules to this branch, this will allow you to get the most working version.
Need testing.

Ugh, of course there would be something broken. I need to set up a proper testing environment—building this stuff in a chroot only goes so far.

Because PR #180 is huge, so it's practically impossible to revise, but it seems professionally prepared, from my point of view it seems reasonable to be the first to merge #180 and then work together to gradually update and merge the other PRs. What is your opinion?

As far as I can tell from skimming #180, the changes made are correct or at least harmless (some may be no-ops, but it isn't worth the effort of figuring out which).

If everyone agrees that it was worth removing the build flags from tqt, then I don't mind. After that, it's worth editing the eclass, similar to how it is done in other/admin-build. Next, will need to edit the 9999 version ebuilds, will need to add files to the unpacking list (which will not be deleted). Changes to eclass will make other/trinity-nomodules ebuilds compatible. Manifest will need to generate a new one, since the archive sources are different.

I would like to move forward here.

I made an effort to look at the individual patches from #180 – removing the options for tqtinterface seems to be no problem, because the TQt3 variant is always used for R14.x. The only thing that seems appropriate for me to change is the USE option hwlib, because it seems too general to me. I think it would be appropriate to add tde – for example tdehwlib. In any case, if such an adjustment will even seem appropriate to you, it can only be done after merging #180.

That's why I propose to start by merging #180. Do you agree?

The change of the flag name to hwlib in tdeioslaves is to make it match the name of the flag with similar purpose in tdelibs (thus reducing the number of flag declarations needed by one). It's really, really rare to have a desktop-specific prefix on a USE flag name (the only one I can find offhand is gnome-keyring), so I don't think that's necessary until and unless someone creates a conflicting flag.

Nearly all of the other patches in #180 are (long overdue) syntactic cleanup and don't change functionality. I vote to push it.

I already said that I do not mind. You shouldn't put it off any longer. I will soon forget the reason for some of the changes in the trinity-nomodules branch...

I suggest adding PR #182, it makes the 9999 branch ebuilds compatible with 14.0.9. This makes adding the 14.0.9 branch very fast. All that remains is to add KEYWORDS= to the lines in ebuilds of version 14.0.9.
The current stable ebuilds are not affected by these changes.
Also, now you can automate the assembly of ebuilds using the admin module for assembly.
This will allow you to get the most complete set of packages in the shortest possible time.
The multilib build for media-libs/libart_lgpl is required for compatibility with the Gentoo portage. For example for building gnome-base/libgnomecanvas, this will avoid build conflicts.

Regarding the brief discussion about Gentoo packaging maintenance in #168, it is clear that I am the least qualified person in terms of time available and actually using TDE, which is always a good idea for someone picking up responsibilities. I won't pretend for a second that I know anything about Trinity internals, even KDE SC 4 predates my downstream involvement apart from the odd MR and eventually helping with phasing it out. Incidentally that (and contributing the odd fix to KDE upstream) made me learn to use git properly, so that is perfectly possible for everyone @eliddell ;)

So basically anything I will ever contribute are syntactic in-place packaging fixes hopefully without breaking anything wrt the upstream build system. And there are a few remaining/new red flags in pkgcheck's output yet to fix.

@ormorph, @eliddell: Let me also suggest to actually add KEYWORDS="" to all the live ebuilds where it is missing, so that the basic ebuild structure remains intact on bumps and no script has to make guesses where to put it. Another option is to add if [[ ${PV} != *9999* ]] switches to them with any release version content defined within (like SRC_URI, KEYWORDS, S or whatever needs non-eclass adaptation) for making even easier version bumps, at the danger of running out of sync if someone adds new KEYWORDS to a release but forgets to also change the live version accordingly. But this is more of a concern in Gentoo ebuild repos where there are arch teams doing the keywording and stabilisation rather than everything under control of a handful of proj maintainers.

Also, this overlay needs to decide what it wants to be: A conservation effort of old KDE3 packages and all their dependencies, like it seems it started out to be, or a viable addon to an up to date Gentoo ebuild repo. The latter means that some results of the conservation effort should be put in question and reducing the amount of unmaintained 3rd party dependencies that were cleaned up from Gentoo ebuild repo for security vulnerabilities, build issues with no upstreams to fix etc. Besides putting a strain on maintenance (keeping packages does not come at zero cost), doing it properly quickly pulls in everything but the kitchen sink. The best example is the recent last-rites of sys-apps/consolekit, which now results in a missing dependency for trinity-base/tdelibs. As support for it was dropped from many packages, you would suddenly look at forking pam, xorg-server, display managers etc. Ideally TDE already works fine with either systemd or elogind for those people who don't rely on root permissions to manually mount USB sticks and shutting down their systems or changing WiFi networks, and you can simply drop the consolekit dependency. The other current red-flag issue is media-libs/libkarma in trinity-apps/amarok, which was last-rited in Gentoo in 2016 and depends on mono, which itself is a trainwreck and I would not pretend it works with what mono version is left in Gentoo repo that many years later.

Regarding the brief discussion about Gentoo packaging maintenance in #168, it is clear that I am the least qualified person in terms of time available and actually using TDE, which is always a good idea for someone picking up responsibilities. I won't pretend for a second that I know anything about Trinity internals, even KDE SC 4 predates my downstream involvement apart from the odd MR and eventually helping with phasing it out. Incidentally that (and contributing the odd fix to KDE upstream) made me learn to use git properly, so that is perfectly possible for everyone @eliddell ;) So basically anything I will ever contribute are syntactic in-place packaging fixes hopefully without breaking anything wrt the upstream build system. And there are a few remaining/new red flags in pkgcheck's output yet to fix. @ormorph, @eliddell: Let me also suggest to actually add `KEYWORDS=""` to all the live ebuilds where it is missing, so that the basic ebuild structure remains intact on bumps and no script has to make guesses where to put it. Another option is to add `if [[ ${PV} != *9999* ]]` switches to them with any release version content defined within (like `SRC_URI`, `KEYWORDS`, `S` or whatever needs non-eclass adaptation) for making even easier version bumps, at the danger of running out of sync if someone adds new `KEYWORDS` to a release but forgets to also change the live version accordingly. But this is more of a concern in Gentoo ebuild repos where there are arch teams doing the keywording and stabilisation rather than everything under control of a handful of proj maintainers. Also, this overlay needs to decide what it wants to be: A conservation effort of old KDE3 packages and all their dependencies, like it seems it started out to be, or a viable addon to an up to date Gentoo ebuild repo. The latter means that some results of the conservation effort should be put in question and reducing the amount of unmaintained 3rd party dependencies that were cleaned up from Gentoo ebuild repo for security vulnerabilities, build issues with no upstreams to fix etc. Besides putting a strain on maintenance (keeping packages does not come at zero cost), doing it properly quickly pulls in everything but the kitchen sink. The best example is the recent last-rites of `sys-apps/consolekit`, which now results in a missing dependency for `trinity-base/tdelibs`. As support for it was dropped from many packages, you would suddenly look at forking pam, xorg-server, display managers etc. Ideally TDE already works fine with either systemd or elogind for those people who don't rely on root permissions to manually mount USB sticks and shutting down their systems or changing WiFi networks, and you can simply drop the consolekit dependency. The other current red-flag issue is `media-libs/libkarma` in `trinity-apps/amarok`, which was last-rited in Gentoo in 2016 and depends on mono, which itself is a trainwreck and I would not pretend it works with what mono version is left in Gentoo repo that many years later.

@ormorph, @eliddell: Let me also suggest to actually add KEYWORDS="" to all the live ebuilds where it is missing, so that the basic ebuild structure remains intact on bumps and no script has to make guesses where to put it.

No problem adding KEYWORDS:

#!/bin/bash

while read file
do
	if ! grep -q "KEYWORDS" ${file} ; then
		sed '/DESCRIPTION/a KEYWORDS="~amd64 ~x86 ~arm ~arm64"' -i $file
	fi
done < <(find -type f -name "*-14.0.9.ebuild")

Adding KEYWORDS to branch 9999 will make it difficult to add new ARCH (~arm ..).
consolekit can be installed from third party overlays. Therefore, this dependency will not hurt yet, later it can be removed. For elogind needs a pam policy for TDM, otherwise problems may arise, for this I added the elogind flag. But I am not against removing this dependency.

Nah that's easy. You replace the whole if block with ekeyword ~{amd64,x86,arm,arm64} ${file} (prerequisite: KEYWORDS var exists already). And adding any subsequent arch would run it with that single argument, no need to re-create ebuilds. As a side effect ekeyword also takes care of correct sorting. It is part of app-portage/gentoolkit. If we use skel.ebuild and the devmanual for reference, then KEYWORDS should really be placed in the same block and between SLOT and IUSE, helps readability if the basic ebuild structure is to the same standard.

Well, besides CI can never be green if you rely on an external repository for a dependency, as I said without having consolekit support in those other packages either you end up with conflicts and runtime papercuts for end users. I am not saying it isn't doable, but you end up with more complicated instructions for using the overlay, and it would be an obstacle for adding it to Gentoo's list of repositories.

then KEYWORDS should really be placed in the same block and between SLOT and IUSE, helps readability if the basic ebuild structure is to the same standard.

But many ebuilds do not have SLOT and IUSE, they are present in eclass...
SLOT can be removed from ebuilds in trinity-apps directories in trinity-base. I think HOMEPAGE should also be removed from the ebuilds in these directories.
I don't mind adding KEYWORDS in the if [[$ {PV}! = * 9999 *]].

I would also like to remove the + from the malloc flag in the tdelibs ebuild, since it is only used by the x86_64 architecture. This flag is not suitable for assembly for ~arm64.

Changed #182
Removed the consolekit flag from tdelibs, added KEYWORDS in one.
Gwenview uses an admin module to build. If you need to switch to cmake, you need to remove the line CHECK_ADMIN="yes".
I only changed the live version of tdelibs as you will most likely have to get rid of the other versions and upgrade to 14.0.9.
If everyone is happy with these changes, then you can accept change #182 and then work on adding KEYWORDS in the next PR. Then you can quickly switch to version 14.0.9.

I thought that any remaining problems to solve here are way smaller than the unmaintained mess from kde-sunset.git so I did this now:

https://gitweb.gentoo.org/proj/kde-sunset.git/commit/?id=c03f36eaca6dcf313066312f49d94094e72e3e81

@SlavekB Is there something like a tde-packaging-gentoo maintainers bug mail alias that we can put into metadata.xml instead of  everywhere?

@SlavekB Is there something like a tde-packaging-gentoo maintainers bug mail alias that we can put into metadata.xml instead of  everywhere?

I also thought about exactly this topic. No such address is currently created. However, now there is no problem creating such an address on the @trinitydesktop.org domain – for example, packaging-gentoo@trinitydesktop.org, and we can decide whether to do it as an alias or a mailing list.

After a recent brief discussion in ML, we now have addresses for teams. They are created as mailing lists and subscription into them is moderated – see team-gentoo@trinitydesktop.org.

I expect it's time for you to sign up 😺