On Fri, 27 Dec 2019 02:40:30 +0100
Sl�vek Banko <slavek.banko@...> wrote:

> On Thursday 26 of December 2019 22:39:00 E. Liddell wrote:
> > I'm trying to fix some Gentoo packaging stuff, since Fat-Zer hasn't
> > touched his overlay in nearly a year and only ever provided live ebuilds
> > (= packages that install directly from git main branch, not from
> > released versions).  There are a bunch of details in the packaging
> > apparatus that haven't been changed in a long time, and I'm pretty sure
> > that some of those details are incorrect.
> >  
> 
> I am very glad that you are interested in Gentoo builds! Some time ago, 
> Chris and I on IRC have been addressing that Fat-Zer's overlay is not very 
> well maintained, and that it would be good to set up an official one. For 
> this reason, a new tde-packaging-gentoo repository was created, which 
> contains a copy of the current Fat-Zer's repository.
> 
> https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo

Looks like the copy is all that's there right now.  I'll have to reread some 
documentation, since I mostly use mercurial rather than git, and register
myself with the current system.

Currently, I have tqt, tqt-interface, and dbus-1-tqt more-or-less working.
I'll see about getting this into source control once I've fixed the msg2tqm
thing (if I can) and have tdelibs working.

> The repository currently contains only the master branch, the r14.0.x 
> branch has not been created yet. I don't know how Gentoo overlay works - 
> whether it's possible to use branches. I don't even know if your plans are 
> directed only to the latest master branch or whether you want to maintain 
> a stable releases - currently r14.0.x branch. It's up to you.

Gentoo "packages" are more like build scripts, really.  It's normal to have
several different versions coexisting in one directory, and once one version
is working, version bumps are often as easy as copying a file under a new
name and running a single command over it.

Currently, my intention is to provide 14.0.6, 14.0.7, and a touched-up
version of the existing live ebuilds for those who want to live dangerously.
Having ebuilds for the stable versions will encourage normal users to
consider installing TDE, since anyone who's been with Gentoo for a while
tends to be very cautious about live ebuilds.

Also on my to-do list is a "bump everything" script that can walk the tree
of ebuilds and issue the necessary file-copy and manifest-creation commands
to produce the next version out of the previous one.  If I can pull that off,
the amount of required maintenance for the 14.x.y ebuilds should fall drastically.

> Chris has some plans, you have some plans, it would be good if you can work 
> together to make sure there is a well maintained official Trinity Gentoo 
> overlay. That would be great.

Do you have any additional contact data for Chris (email address, or whatever)?
It might be a good idea to talk about plans for this at a higher level than 
discussions on individual patches would allow.

> > Specific questions:
> >
> > Permitted licenses for tqt are still listed in the ebuild as "QPL-1.0
> > GPL-2 GPL-3", unchanged from qt3.  Am I correct in remembering that QPL
> > (Trolltech's proprietary license) is no longer valid for tqt?
> 
> That is a good question. I also think that only GPL remains valid for TQt.

In that case, I'll remove the reference.  Better to only mention licenses that
we're certain are applicable.

> > What is the actual version number of tqt?  Of tqtinterface? 
> > Historically, these followed a different version scheme from the main
> > desktop, but that seems to have changed. Currently, I'm dealing with the
> > version numbers, certain directory and file names, and a Gentoo SLOT
> > (mechanism for tracking multiple versions of the same package installed
> > in parallel) inconsistently, and I would like to clean things up.
> >  
> 
> Here are two numbers - the git repository versions and packages follow the 
> TDE version numbering as a whole. However, the internal version number of 
> the library is now 3.5.0. For deb packages, the package version is now 
> 14.0.7, where the so library version inside the package is 3.5.0.

Ugh.  That's messy.  Especially since the source releases only place the
14.x.y package version in the filename, which means that the ebuild needs
to know that number *anyway*, even though it's technically irrelevant.

I think I'm going to leave it as-is, with directory=tqt3, SLOT=3 (SLOT=3.5.0?
I'll have to see if that's allowed), but ebuild version 14.x.y.  It may lead to some 
people updating that package unnecessarily, but it won't actually break anything.

> > What, exactly, are msg2qm and qembed?  The ebuild I inherited for tqt
> > builds them separately, with comments reading "# Make the
> > msg2qm[/qembed] utility (not made by default)", and furthermore the
> > build mechanism is currently broken.  I need to know whether or not
> > fixing it is worth the effort.  Are these utilities used for building
> > and/or running anything?
> >  
> msg2tqm (tqembed) is a tool for converting data, such as images, into C++ 
> code that can be embedded as part of a binary. Unfortunately, I do not 
> remember whether / where this tool is actually used. However, for deb 
> packages it is also built as part of TQt.

I'd probably better try to sort it out, then.  At a guess, it's probably used for
some simple icon graphics somewhere.

> > More to come as I work my way through the tree, if I don't just give up
> > and crawl away into a corner somewhere the way I did the last two times
> > I tried this.
> >  
> 
> It will be great if you can join your efforts with Chris and possibly other 
> contributors. TGW is a great tool where you can discuss planned patches 
> using issues and pull-requests. It could help you not give up and don't 
> want to hide in a corner :)

What I did the last few times was bite off more than I could chew.  This time,
I'm not going to make the mistake of trying to write additional ebuilds (no
matter how much I would like to have k3b working again).  I'm just not good
enough with bash shell script or the C++ build toolchains to pull it off.

Right now, I'm trying to do a short list of things:

-Concentrate on the packages that I actually use, at least on the first pass.

-Fix the breakage that was preventing the existing ebuilds from working
(mostly, this was broken download URIs)

-Modernize to current Gentoo standards where possible (move from EAPI 5
to EAPI 7 and ditch the obsolete git-2 eclass).

-Aggressively cull anything that isn't absolutely needed, to reduce the 
maintenance burden.  This includes both code intended to support versions 
before 14.0.0, and alternative dependencies like qt3 (not tqt) and hal.
libart-lgpl is still in the main Gentoo tree, and TDE seems to work fine with
that version, so I'm removing it as well.

-Create the bump script.

Once all of that works, I'll consider looking at the packages that I don't use,
providing instructions on how to set up TDM, and trying to get the overlay
into layman (Gentoo's semi-official overlay manager).  The whole thing is 
going to take months.

E. Liddell