On Fri, 27 Dec 2019 02:40:30 +0100 Slávek Banko <slavek.banko(a)axis.cz> 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. 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. 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. 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. In that case, I'll remove the reference. Better to only mention licenses that we're certain are applicable. 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. I'd probably better try to sort it out, then. At a guess, it's probably used for some simple icon graphics somewhere. 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

On Fri, 27 Dec 2019 23:12:31 +0900 "Michele Calgaro via trinity-devel" <trinity-devel(a)lists.pearsoncomputing.net> wrote: 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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2020/01/01 10:35 AM, Sl�vek Banko wrote: 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 Friday 27 of December 2019 14:39:02 E. Liddell wrote: 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. 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 :) 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. 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. 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. 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 found several files in the source code that were generated by qembed. However, apparently at present there is nothing to use tqembed during build. 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 hope the joint effort succeeds! Cheers -- Slávek

On Monday 30 of December 2019 22:43:06 E. Liddell wrote: You are now a Contributors team member - welcome :) Good question. I don't recall that in Gitea there is any setting for it. 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"? 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. Yes, it probably can be left for later. We'll see if Chris devoted himself to it :) 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. Cheers -- Slávek

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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