30 Dec
2019
30 Dec
'19
9:02 a.m.
On Friday 27 of December 2019 14:39:02 E. Liddell wrote:
Here are a few options: Michele has already sent Chris an email address.
The fact is that Chris doesn't follow the mailing list too actively. For
active discussion it is usually present on IRC. Then there is the jabber
room tde-devs(a)chat.jabb.im, which is suitable for discussions about
development.
In that case, I'll remove the reference. Better to only mention
licenses that we're certain are applicable.
Yes, TQt requires a little house keeping. Together with Michele we have
already done some cleaning of obsolete code in the current master branch.
Clarifying the status of licenses will definitely be good.
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.
It's not as crazy as it may seem. TQt simply has a version that complies
with the TDE itself. So in stable branch it is now 14.0.7. That's why the
package version is 14.0.7 - I suppose you can use it for Gentoo anyway.
Libraries themselves have an internal version number determined by API /
ABI changes and backward compatibility. Therefore, it is not unusual for
individual libraries to have internal version numbers different from the
package version itself. For example, you can see libtqt-mt.so.3.5.0 and
libtqui.so.1.0.0 side by side in the same package. Regardless of the fact
that the version number of the package as a whole is 14.0.7.
I'd probably better try to sort it out, then. At a guess, it's probably
used for some simple icon graphics somewhere.
I found several files in the source code that were generated by qembed.
However, apparently at present there is nothing to use tqembed during
build.
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.
The version of libart-lgpl in the TDE repository contains bug fixes - as
far as I remember, it was the solution to some crashes.
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.
Michele has already sent a link to the TGW information. Once you have an
account, we will join you in the Contributors team. This will allow you to
create pull-requests. Later we will join you in the Packagers team. Then
you will be able to push the commits directly into the main branches.
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.
As you can see in tde-packaging for deb packages, it is recommended that
you manage to keep the code consistent between master and r14.0.x (stable)
branch. Usually we use cherry-pick from master branch to r14.0.x branch.
Therefore, it will be good to align your plans so that the intended goals
work for both branches. It is clear that this will require more discussion
than comments on pull-request :)
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.
I'm pleased. I fully understand that not every user wants to use the
development version (despite the fact that our master branch is usually
reliable enough) and prefer stable releases.
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. 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. 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. 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 :) -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
I hope the joint effort succeeds!
Cheers
--
Slávek