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.
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?
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.
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?
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.
E. Liddell
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
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.
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.
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 :)
E. Liddell
Cheers
On Fri, 27 Dec 2019 02:40:30 +0100 Slávek Banko slavek.banko@axis.cz 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi E.
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.
See https://wiki.trinitydesktop.org/TDE_Gitea_Workspace for a short introductory guide to TGW. For git, there is plenty of documentation available in the internet.
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.
xchrisx@uber.space This is the email he uses for TGW and ML
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.
Given that we have decided that TDE will build on TQt3, perhaps it's a good opprtunity to bump the TQt3 version to 14.x.y to match TDE version number. We will need to discuss this with Slavek at due time, probably something good for R14.1.0 release planned for next year.
Cheers Michele
On Fri, 27 Dec 2019 23:12:31 +0900 "Michele Calgaro via trinity-devel" trinity-devel@lists.pearsoncomputing.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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.
See https://wiki.trinitydesktop.org/TDE_Gitea_Workspace for a short introductory guide to TGW. For git, there is plenty of documentation available in the internet.
Someone please explain to me like I'm five what this thing expects for credentials, because I keep getting this:
# git push -u origin other/eapi7 Username for 'https://scm.trinitydesktop.org': eliddell Password for 'https://eliddell@scm.trinitydesktop.org': remote: invalid credentials fatal: Authentication failed for 'https://scm.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/'
(In other words, git is doing a very good job of reminding me why I use mercurial whenever I have the option. Unfortunate that hg-git doesn't have very good support for branches.)
E. Liddell
On Wednesday 01 of January 2020 00:51:33 E. Liddell wrote:
On Fri, 27 Dec 2019 23:12:31 +0900
"Michele Calgaro via trinity-devel"
trinity-devel@lists.pearsoncomputing.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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.
See https://wiki.trinitydesktop.org/TDE_Gitea_Workspace for a short introductory guide to TGW. For git, there is plenty of documentation available in the internet.
Someone please explain to me like I'm five what this thing expects for credentials, because I keep getting this:
# git push -u origin other/eapi7 Username for 'https://scm.trinitydesktop.org': eliddell Password for 'https://eliddell@scm.trinitydesktop.org': remote: invalid credentials fatal: Authentication failed for 'https://scm.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/'
Here's the simple reason: The TGW you need to push patches to is located at mirror.git.trinitydesktop.org, not scm.trinitydesktop.org. Although Gitea is now on scm.trinitydesktop.org, this instance is in read-only mode.
Therefore, you need to change the url for repository from https://scm.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/ to https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/
(In other words, git is doing a very good job of reminding me why I use mercurial whenever I have the option. Unfortunate that hg-git doesn't have very good support for branches.)
If this is the only problem, then using the git will be very cool :)
Note: I know it is a bit confusing when the primary GIT workspace is on a server whose name starts with mirror.git.. But that is unfortunately still due to Tim being unavailable and thus unable to set up DNS records. I firmly hope that this problem will also be resolved soon.
E. Liddell
Cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2020/01/01 10:35 AM, Sl�vek Banko wrote:
(In other words, git is doing a very good job of reminding me why I use mercurial whenever I have the option. Unfortunate that hg-git doesn't have very good support for branches.)
I don't use mercurial, so I can't compare directly. Anyhow git is a great tool. Takes a bit to learn how to move around with it, but once you do it is *extremely* powerful. I have been quite surprised by it :-)
Cheers Michele
On Wed, 1 Jan 2020 02:35:42 +0100 Slávek Banko slavek.banko@axis.cz wrote:
On Wednesday 01 of January 2020 00:51:33 E. Liddell wrote:
On Fri, 27 Dec 2019 23:12:31 +0900
"Michele Calgaro via trinity-devel"
trinity-devel@lists.pearsoncomputing.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
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.
See https://wiki.trinitydesktop.org/TDE_Gitea_Workspace for a short introductory guide to TGW. For git, there is plenty of documentation available in the internet.
Someone please explain to me like I'm five what this thing expects for credentials, because I keep getting this:
# git push -u origin other/eapi7 Username for 'https://scm.trinitydesktop.org': eliddell Password for 'https://eliddell@scm.trinitydesktop.org': remote: invalid credentials fatal: Authentication failed for 'https://scm.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/'
Here's the simple reason: The TGW you need to push patches to is located at mirror.git.trinitydesktop.org, not scm.trinitydesktop.org. Although Gitea is now on scm.trinitydesktop.org, this instance is in read-only mode.
Therefore, you need to change the url for repository from https://scm.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/ to https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging-gentoo/
Ah, I think I see what happened now (got confused because the URLs in the wiki are inconsistent and my pain meds weren't strong enough). Now it's pushing successfully, and we have a new branch. Thanks.
E. Liddell
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@chat.jabb.im, 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
On Mon, 30 Dec 2019 10:02:24 +0100 Slávek Banko slavek.banko@axis.cz wrote:
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.
Okay, I registered. Account name eliddell, since I can't be bothered to be creative.
(A note: Is there some way to make the registration page show what the password complexity requirements are, if you must have them at all? Counterintuitively, requirements like that actually make passwords slightly easier to crack when you have a tech-savvy userbase, because they reduce the number of possible passwords.)
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 :)
Normally, Gentoo uses one ebuild file per package version, and they're all held in one directory together. For instance, if we had a working overlay at this time, the directory for tdelibs would contain tdelibs-14.0.6.ebuild, tdelibs-14.0.7.ebuild, and tdelibs-9999.ebuild (by Gentoo convention, a "live" ebuild that pulls from source control rather than a prepackaged release is always version 9999). That's the direction I'm trying to head in.
If version 14.0.8 came out, I'd then copy tdelibs-14.0.7.ebuild to tdelibs-14.0.8.ebuild, then build and test the package to make certain that the ebuild didn't need to be modified.
If version 14.1.0 came out, I'd copy tdelibs-9999.ebuild to tdelibs-14.1.0.ebuild, fix the KEYWORDS variable, and build, test, etc.
How does the package manager know whether or not to install tdelibs-9999 if I ask for an update? That's what KEYWORDS is for. Release versions would be keyworded ~amd64 (non-stable keyword for x86_64 systems) and possibly ~arm (non-stable 32-bit ARM, like the Raspberry Pi) and/or ~x86 (non-stable 32-bit Intel x86) depending on how much testing I have the energy for. (As for stable keywords, they're not supposed to be issued by anyone other than official Gentoo devs or QA.)
9999 versions carry no keywords at all (again, this is Gentoo convention) and have to be unmasked specifically. It's generally understood that software with no keywords may fail to build, exhibit random runtime failures, turn your cat into a toaster, etc. (Gentoo's onetime reputation for being bleeding-edge came about for a reason.)
Splitting all of this into "master" and "stable" branches only means that the people pulling the "stable" branch might get stale/broken/no 9999 ebuilds. It just isn't supposed to work like that.
If you'd like a sample of how this kind of thing looks in practice, here's poppler in the official Gentoo ebuild repository, with three release ebuilds and one live ebuild:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/poppler
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.
The idea here is to keep people from having to download and compile tqt3-trinity-14.0.8.tar.xz if tqt3-trinity-14.0.7.tar.xz is already installed and provides the same code. Depending on the SLOT rather than the package version should work for this, but I have to make sure I know when to change the SLOT (it has to reflect API and ABI).
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.
In that case, I'll do an about-face and wait and see if anything blows up.
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.
I can only see one relevant commit, back in 2011:
https://mirror.git.trinitydesktop.org/gitea/TDE/libart-lgpl/commit/150562b89...
The rest seems to be CMake conversion, tweaks to informational files, and similar. In theory, I could try to submit the patches back to Gentoo. In practice, I have no idea what they do (what are "a number of problems"?) or whether they'd break any of the other ten reverse dependencies of media-libs/libart_lgpl (or whether it matters, given how old some of them are).
I'm not sure what the best move is here at this point. The quick-and-messy fix is to provide libart_lgpl-2.3.21-r99.ebuild to supersede the upstream libart_lgpl-2.3.21-r3.ebuild, but that's an ugly solution.
E. Liddell
On Monday 30 of December 2019 22:43:06 E. Liddell wrote:
On Mon, 30 Dec 2019 10:02:24 +0100
Slávek Banko slavek.banko@axis.cz wrote:
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.
Okay, I registered. Account name eliddell, since I can't be bothered to be creative.
You are now a Contributors team member - welcome :)
(A note: Is there some way to make the registration page show what the password complexity requirements are, if you must have them at all? Counterintuitively, requirements like that actually make passwords slightly easier to crack when you have a tech-savvy userbase, because they reduce the number of possible passwords.)
Good question. I don't recall that in Gitea there is any setting for it.
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 :)
Normally, Gentoo uses one ebuild file per package version, and they're all held in one directory together. For instance, if we had a working overlay at this time, the directory for tdelibs would contain tdelibs-14.0.6.ebuild, tdelibs-14.0.7.ebuild, and tdelibs-9999.ebuild (by Gentoo convention, a "live" ebuild that pulls from source control rather than a prepackaged release is always version 9999). That's the direction I'm trying to head in.
If version 14.0.8 came out, I'd then copy tdelibs-14.0.7.ebuild to tdelibs-14.0.8.ebuild, then build and test the package to make certain that the ebuild didn't need to be modified.
If version 14.1.0 came out, I'd copy tdelibs-9999.ebuild to tdelibs-14.1.0.ebuild, fix the KEYWORDS variable, and build, test, etc.
How does the package manager know whether or not to install tdelibs-9999 if I ask for an update? That's what KEYWORDS is for. Release versions would be keyworded ~amd64 (non-stable keyword for x86_64 systems) and possibly ~arm (non-stable 32-bit ARM, like the Raspberry Pi) and/or ~x86 (non-stable 32-bit Intel x86) depending on how much testing I have the energy for. (As for stable keywords, they're not supposed to be issued by anyone other than official Gentoo devs or QA.)
9999 versions carry no keywords at all (again, this is Gentoo convention) and have to be unmasked specifically. It's generally understood that software with no keywords may fail to build, exhibit random runtime failures, turn your cat into a toaster, etc. (Gentoo's onetime reputation for being bleeding-edge came about for a reason.)
Splitting all of this into "master" and "stable" branches only means that the people pulling the "stable" branch might get stale/broken/no 9999 ebuilds. It just isn't supposed to work like that.
If you'd like a sample of how this kind of thing looks in practice, here's poppler in the official Gentoo ebuild repository, with three release ebuilds and one live ebuild:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/poppler
Thank you, now I understand better. This means there is no need to create a branch. It also means that tde-packaging-gentoo will not be part of the 'tde' tree on r14.0.x branch.
Is there also a convention for preliminary packages? For example, as on Debian "~preXX", or on FreeBSD "+pXX"?
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.
The idea here is to keep people from having to download and compile tqt3-trinity-14.0.8.tar.xz if tqt3-trinity-14.0.7.tar.xz is already installed and provides the same code. Depending on the SLOT rather than the package version should work for this, but I have to make sure I know when to change the SLOT (it has to reflect API and ABI).
I'm afraid we're not careful here. For example, in the master branch, the TQt1 and TQt2 compatibility functions (which never existed as TQt) have been removed, but we still did not change the internal version number.
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.
In that case, I'll do an about-face and wait and see if anything blows up.
Yes, it probably can be left for later. We'll see if Chris devoted himself to it :)
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.
I can only see one relevant commit, back in 2011:
https://mirror.git.trinitydesktop.org/gitea/TDE/libart-lgpl/commit/15056 2b89b645c402f1bb837a09f8b84bf6e49ec
The rest seems to be CMake conversion, tweaks to informational files, and similar. In theory, I could try to submit the patches back to Gentoo. In practice, I have no idea what they do (what are "a number of problems"?) or whether they'd break any of the other ten reverse dependencies of media-libs/libart_lgpl (or whether it matters, given how old some of them are).
I'm not sure what the best move is here at this point. The quick-and-messy fix is to provide libart_lgpl-2.3.21-r99.ebuild to supersede the upstream libart_lgpl-2.3.21-r3.ebuild, but that's an ugly solution.
For deb packages, we have upgraded the libart-lgpl package version number to the TDE version number. But it is true that we probably did not increase the internal version number of the library.
E. Liddell
Cheers
On Tue, 31 Dec 2019 10:32:31 +0100 Slávek Banko slavek.banko@axis.cz wrote:
On Monday 30 of December 2019 22:43:06 E. Liddell wrote:
On Mon, 30 Dec 2019 10:02:24 +0100
Slávek Banko slavek.banko@axis.cz wrote:
On Friday 27 of December 2019 14:39:02 E. Liddell wrote:
[snip discussion of How Ebuilds Work]
Thank you, now I understand better. This means there is no need to create a branch. It also means that tde-packaging-gentoo will not be part of the 'tde' tree on r14.0.x branch.
Is there also a convention for preliminary packages? For example, as on Debian "~preXX", or on FreeBSD "+pXX"?
You would add "_preXX" to the version number. "XX" can either be a simple number or a compressed date (for instance, tdelibs-14.1.0_pre20201031.ebuild, for something that captures the state of the source as of next Halloween). Corresponding source tarballs would need to be available, though.
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.
The idea here is to keep people from having to download and compile tqt3-trinity-14.0.8.tar.xz if tqt3-trinity-14.0.7.tar.xz is already installed and provides the same code. Depending on the SLOT rather than the package version should work for this, but I have to make sure I know when to change the SLOT (it has to reflect API and ABI).
I'm afraid we're not careful here. For example, in the master branch, the TQt1 and TQt2 compatibility functions (which never existed as TQt) have been removed, but we still did not change the internal version number.
Portions of the API that aren't called by any current consumer of the package are of concern only in a perfect-world, abstract way, if you understand what I mean. Is it reasonable to expect a bump of the internal version if portions of the API in active use change?
E. Liddell
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Splitting all of this into "master" and "stable" branches only means that the people pulling the "stable" branch might get stale/broken/no 9999 ebuilds. It just isn't supposed to work like that.
If you'd like a sample of how this kind of thing looks in practice, here's poppler in the official Gentoo ebuild repository, with three release ebuilds and one live ebuild:
https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/poppler
Thank you, now I understand better. This means there is no need to create a branch. It also means that tde-packaging-gentoo will not be part of the 'tde' tree on r14.0.x branch.
Is there also a convention for preliminary packages? For example, as on Debian "~preXX", or on FreeBSD "+pXX"?
Personally I think it is still better to have a master and r14.0.x branch. For all maintenance releases (like R14.0.x) the various ebuild scripts can leave within the same branch, but at least when we change into a new minor release there is a clear separation between branches. Just my 2 cents. Cheers Michele
-
E. Liddell -
Michele Calgaro via trinity-devel -
Slávek Banko