On Friday 27 of December 2019 14:39:02 E. Liddell wrote: > > 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. > 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@xxxxxxxxxxxx, which is suitable for discussions about development. > > > 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. > 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. > > > 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. > 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. > > > 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. > 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. > > > 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. > The version of libart-lgpl in the TDE repository contains bug fixes - as far as I remember, it was the solution to some crashes. > -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
Attachment:
signature.asc
Description: This is a digitally signed message part.
