It seems these isn't exactly clear now how to handle that and what, I just coming with some suggestion here.
We should offer all possible arches Gentoo can build on.
alpha
amd64
arm
arm64
hppa
ia64
ppc
ppc64
sparc
x86
mips
mips64
sparc64
That includes all official supported arches, which are verified by Slavek already build for Debian. The last three arches aren't really official Gentoo supported arches, but it seems used too for some people.
At least we shouldn't exclude someone. If there are problems, we can take some arch out.
Also I think there is not really a point to use testing for our ebuilds if we add them. Because it should be more or less clear, the whole overlay is always a bit of testing, because not official. So we don't want to bug people with forcing them to add keywords the whole time.
That means adding new stable ebuilds should have all that stable arch keywords directly. But if there is some new 14.0.7 for example, we could say that keeps to be ~xxx for some month or so.
Let me think about what you think here. 😸
It seems these isn't exactly clear now how to handle that and what, I just coming with some suggestion here.
We should offer all possible arches Gentoo can build on.
- alpha
- amd64
- arm
- arm64
- hppa
- ia64
- ppc
- ppc64
- sparc
- x86
- mips
- mips64
- sparc64
That includes all official supported arches, which are verified by Slavek already build for Debian. The last three arches aren't really official Gentoo supported arches, but it seems used too for some people.
At least we shouldn't exclude someone. If there are problems, we can take some arch out.
Also I think there is not really a point to use testing for our ebuilds if we add them. Because it should be more or less clear, the whole overlay is always a bit of testing, because not official. So we don't want to bug people with forcing them to add keywords the whole time.
That means adding new stable ebuilds should have all that stable arch keywords directly. But if there is some new 14.0.7 for example, we could say that keeps to be *~xxx* for some month or so.
Let me think about what you think here. :smile_cat:
Historically, KDE3 was keyworded "alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd", but I'm a little reluctant to proceed in adding too many arches without at least emulator testing.
Adding ~arm and maybe ~arm64 would be useful, due to the increasingly wide deployment of those arches. I'm already mostly set up to test-build for 32-bit arm (specifically, RPi3), so testing that one is practical.
The other arches are obsolete or exotic and have very small user bases. Adding their keywords offers very little return.
mips64 and sparc64 aren't separate arches under Gentoo, BTW—they're sub-arches of mips and sparc, and don't have their own keywords. It's nearly impossible to compare lists of Debian and Gentoo arches directly. I tried that once. ;P
Between potential sub-arch issues (the set of chips Debian supports for a given arch may not be the same as the ones Gentoo supports), the size of the userbases, and having to check the status of all dependency packages for these minor arches, I think we should stick to "~amd64 ~arm ~arm64 ~x86", and add a note to any relevant readmes or wikis that "TDE should also work on alpha hppa ia64 ppc ppc64 sparc mips, but has not been tested on those arches under Gentoo. If you're using one of those arches and the TDE ebuilds work for you, great! Please drop us a line so that we can update our KEYWORDS." (At that point, I get to reread "man sed", for maximum arch-adding efficiency.)
Has anyone tried riscv yet?
Historically, KDE3 was keyworded "alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd", but I'm a little reluctant to proceed in adding too many arches without at least emulator testing.
Adding ~arm and maybe ~arm64 would be useful, due to the increasingly wide deployment of those arches. I'm already mostly set up to test-build for 32-bit arm (specifically, RPi3), so testing that one is practical.
The other arches are obsolete or exotic and have very small user bases. Adding their keywords offers very little return.
mips64 and sparc64 aren't separate arches under Gentoo, BTW—they're sub-arches of mips and sparc, and don't have their own keywords. It's nearly impossible to compare lists of Debian and Gentoo arches directly. I tried that once. ;P
Between potential sub-arch issues (the set of chips Debian supports for a given arch may not be the same as the ones Gentoo supports), the size of the userbases, and having to check the status of all dependency packages for these minor arches, I think we should stick to "~amd64 ~arm ~arm64 ~x86", and add a note to any relevant readmes or wikis that "TDE should also work on alpha hppa ia64 ppc ppc64 sparc mips, but has not been tested on those arches under Gentoo. If you're using one of those arches and the TDE ebuilds work for you, great! Please drop us a line so that we can update our KEYWORDS." (At that point, I get to reread "man sed", for maximum arch-adding efficiency.)
Has anyone tried riscv yet?
I think we agree that amd64 and i386 are certainly tested. In addition, there are several architectures that can be considered tested with deb packages:
ppc64el (64bit, little-endian) – @tpearson uses the POWER9 machine.
powerpc (32bit, big-endian) – previously, we had users in France who used TDE on it. I don't know if they continue to use it.
armhf (32bit) – I tested it on PinebookPro.
mips (32bit, big-endian) – I tested it on old SGI Indy. There were some minor problems related to limiting the graphics card to 256 colors. At the same time, there was a problem with limited performance because the 133 MHz processor and 64 MiB RAM are not enough 😺
sparc (32bit, big-endian) – @denis tested it on DilOS and OpenIndiana.
I think we agree that **amd64** and **i386** are certainly tested. In addition, there are several architectures that can be considered tested with deb packages:
* **ppc64el** (64bit, little-endian) – @tpearson uses the POWER9 machine.
* **powerpc** (32bit, big-endian) – previously, we had users in France who used TDE on it. I don't know if they continue to use it.
* **armhf** (32bit) – I tested it on PinebookPro.
* **mips** (32bit, big-endian) – I tested it on old SGI Indy. There were some minor problems related to limiting the graphics card to 256 colors. At the same time, there was a problem with limited performance because the 133 MHz processor and 64 MiB RAM are not enough :smiley_cat:
* **sparc** (32bit, big-endian) – @denis tested it on DilOS and OpenIndiana.
I'm worried about a few things, none of which has to do with whether TDE will actually run on those arches once built.
Keywording of dependencies under Gentoo for exotic arches. The official policy in the dev manual (at https://devmanual.gentoo.org/keywording/index.html ) states that if a package has a ~arch keyword, all its dependencies must also be at least ~arch. The only way to guarantee that for exotic arches is either to manually examine all packages in the depgraph, or to actually use Portage to build and install TDE on that arch.
Subarches and testing. mips has three subarches (o32, mipsel, mips64). arm has five (armv4, armv4t, armv5te, armv6j, armv7a). A couple of the others have two with different bitness or endianness. If your list above is correct, not all of these have been tested. Neither have hppa or ia64 in any variation. I'm willing to play a bit fast-and-loose with arm because I think there are substantial benefits, but not with the other arches.
Weird explosions in the build system due to old or deficient tooling on exotic arches. Again, we can only test this by actually installing TDE to these arches via Portage on Gentoo, so that we can ensure nothing was cross-compiled and no part of the build system was affected by a difference in patching. (Official policy is not to keyword anything that hasn't been directly tested on Gentoo.)
We don't have to follow the official policy, but it would improve TDE's chances of being accepted into layman or even the official Portage tree in the future. (As to whether the latter is possible, well, the main hurdle, once we get everything working, would be finding an official Gentoo dev willing to collaborate on the proxy-maintenance of a couple of hundred packages. Very difficult, but not quite impossible.)
I'm worried about a few things, none of which has to do with whether TDE will actually run on those arches once built.
1. Keywording of dependencies under Gentoo for exotic arches. The official policy in the dev manual (at https://devmanual.gentoo.org/keywording/index.html ) states that if a package has a ~arch keyword, all its dependencies must also be at least ~arch. The only way to guarantee that for exotic arches is either to manually examine all packages in the depgraph, or to actually use Portage to build and install TDE on that arch.
2. Subarches and testing. mips has three subarches (o32, mipsel, mips64). arm has five (armv4, armv4t, armv5te, armv6j, armv7a). A couple of the others have two with different bitness or endianness. If your list above is correct, not all of these have been tested. Neither have hppa or ia64 in any variation. I'm willing to play a bit fast-and-loose with arm because I think there are substantial benefits, but not with the other arches.
3. Weird explosions in the build system due to old or deficient tooling on exotic arches. Again, we can only test this by actually installing TDE to these arches via Portage on Gentoo, so that we can ensure nothing was cross-compiled and no part of the build system was affected by a difference in patching. (Official policy is not to keyword anything that hasn't been directly tested on Gentoo.)
We don't have to follow the official policy, but it would improve TDE's chances of being accepted into layman or even the official Portage tree in the future. (As to whether the latter is possible, well, the main hurdle, once we get everything working, would be finding an official Gentoo dev willing to collaborate on the proxy-maintenance of a couple of hundred packages. Very difficult, but not *quite* impossible.)
Thanks for your constructive input here, @eliddell! 👍
You seems to be very into that and I see your point here and have looked a bit since yesterday and thought about what you wrote. The point about the maybe keyworded dependencies is some that came to my mind too. Not only that. It might be the case some of that dependencies, or future dependencies of TDE or of some TDE applications may be not existing for that arch at all - At least not in Gentoo. Otherwise, that one could be simply provided by our overlay, because if that upstream projects were just too old to work on that arch, TDE wouldn't run on that arch on Debian.
I wasn't exactly sure about the last three arches, but after talk with Slavek I did a quick search and found, some overlays have used that keywords in the past.
Meanwhile I looked at the old KDE3 ebuilds and eclasses and it seems at least for HPPA there had to be workarounds for building. That might be, like for most of that stuff, today not the case anymore for TDE. But it was some good point.
To be clear and I don't want to be pessimistic, that is absolutely not my nature normaly, but I don't see us to have that here ever included into the portage tree. I have too much read and experienced about that related to the ignorance of the developers here and I have already read what they think about TDE. We don't need them and as long as at least I use TDE on Gentoo, I would be willing to offer that here under the TDE umbrella, because I know the people here don't give a shit on what is done by me, to be directly.
But that is just about me - If you want to get it into portage, I would be willing to at least try it with all efforts. But TQt3 alone, which is very evil, because of a security hazard is a reason they never will include it. Starting that here was really because I saw, no one will do it after all and I am very happy you joined this efforts. 👍
Getting into layman could be some idea - To be honest, I haven't looked deeper into that. But with the right advertisement, we can spread the word about TDE as effective as beeing in Layman. At least I don't need any dictatorship from Gentoo. Right now we have all the freedom to do what we want with the overlay, get in touch with potential users and find solutions with them. It had some reason I copyrighted the ebuilds with TDE and not Gentoo. That said, I really love Gentoo, but I just get sick to see more and more ebuilds beeing removed and such things. After all it was about choice and freedom. I already plan to start some other overlay about that in future, which is some other topic. We will see.
From what you write, I get you want to handle this serious, which is fine and I like that. I want to do it that way too, but sometimes it is attracting more users to get involved if they just experience breackage at some point with some starting base, which only needs to be fixed to get something running. After all, that was the reason I joined TDE, with a half broken overlay as a base. If I hadn't even run it, I maybe never would have started to fix it. That is some psychological thing behind I thought it would be good to have support for all arches. Taking the number of the user base into account, if you honestly write down it isn't tested for all, but can be tested and you are open for fixes, isn't a good idea after all. That way Gentoo developers kick out ebuilds, because they think the large userbase will never use them - So that more and more Gentoo users are very unhappy they need to care about more and more ebuilds in their local overlays. I think we don't want to be that rude. 😸
At least one user I met in the IRC running TDE under Gentoo on ARM. I haven't asked more about that to that time. So ARM should be fine too and you can test it.
So after all, the stable ebuilds are a bit of your baby and if you are unhappy to get blamed they don't work or so, I am fine with that - But at least having PPC support would be some serious things, because if I think about KMilo, there is still that powerbook USE flag masked, I would likely get ride of at some point. 😅
Thanks for your constructive input here, @eliddell! :+1:
You seems to be very into that and I see your point here and have looked a bit since yesterday and thought about what you wrote. The point about the *maybe* keyworded dependencies is some that came to my mind too. Not only that. It might be the case some of that dependencies, or future dependencies of TDE or of some TDE applications may be not existing for that arch at all - At least not in Gentoo. Otherwise, that one could be simply provided by our overlay, because if that upstream projects were just too old to work on that arch, TDE wouldn't run on that arch on Debian.
I wasn't exactly sure about the last three arches, but after talk with Slavek I did a quick search and found, some overlays have used that keywords in the past.
Meanwhile I looked at the old KDE3 ebuilds and eclasses and it seems at least for *HPPA* there had to be workarounds for building. That might be, like for most of that stuff, today not the case anymore for TDE. But it was some good point.
To be clear and I don't want to be pessimistic, that is absolutely not my nature normaly, but I don't see us to have that here ever included into the portage tree. I have too much read and experienced about that related to the ignorance of the developers here and I have already read what they think about TDE. We don't need them and as long as at least I use TDE on Gentoo, I would be willing to offer that here under the TDE umbrella, because I know the people here don't give a shit on what is done by me, to be directly.
But that is just about me - If you want to get it into portage, I would be willing to at least try it with all efforts. But TQt3 alone, which is very *evil*, because of a *security hazard* is a reason they never will include it. Starting that here was really because I saw, no one will do it after all and I am very happy you joined this efforts. :+1:
Getting into layman could be some idea - To be honest, I haven't looked deeper into that. But with the right advertisement, we can spread the word about TDE as effective as beeing in Layman. At least I don't need any dictatorship from Gentoo. Right now we have all the freedom to do what we want with the overlay, get in touch with potential users and find solutions *with* them. It had some reason I copyrighted the ebuilds with TDE and not Gentoo. That said, I really love Gentoo, but I just get sick to see more and more ebuilds beeing removed and such things. After all it was about choice and freedom. I already plan to start some other overlay about that in future, which is some other topic. We will see.
From what you write, I get you want to handle this serious, which is fine and I like that. I want to do it that way too, but sometimes it is attracting more users to get involved if they just experience breackage at some point with some starting base, which only needs to be fixed to get something running. After all, that was the reason I joined TDE, with a half broken overlay as a base. If I hadn't even run it, I maybe never would have started to fix it. That is some psychological thing behind I thought it would be good to have support for all arches. Taking the number of the user base into account, if you honestly write down it isn't tested for all, but can be tested and you are open for fixes, isn't a good idea after all. That way Gentoo developers kick out ebuilds, because they think the large userbase will never use them - So that more and more Gentoo users are very unhappy they need to care about more and more ebuilds in their local overlays. I think we don't want to be that rude. :smile_cat:
At least one user I met in the IRC running TDE under Gentoo on *ARM*. I haven't asked more about that to that time. So *ARM* should be fine too and you can test it.
So after all, the stable ebuilds are a bit of your baby and if you are unhappy to get blamed they don't work or so, I am fine with that - But at least having *PPC* support would be some serious things, because if I think about KMilo, there is still that *powerbook* USE flag masked, I would likely get ride of at some point. :sweat_smile:
Keywording of dependencies under Gentoo for exotic arches. The official policy in the dev manual (at https://devmanual.gentoo.org/keywording/index.html ) states that if a package has a ~arch keyword, all its dependencies must also be at least ~arch. The only way to guarantee that for exotic arches is either to manually examine all packages in the depgraph, or to actually use Portage to build and install TDE on that arch.
Just FYI, those could be easily traced back with repoman. ;)
And for the record, I strongly appose (if I may) keywording any arch unless there is a confirmed build for it, request for keywording, and an assurance/promise that it works fine enough.
> Keywording of dependencies under Gentoo for exotic arches. The official policy in the dev manual (at https://devmanual.gentoo.org/keywording/index.html ) states that if a package has a ~arch keyword, all its dependencies must also be at least ~arch. The only way to guarantee that for exotic arches is either to manually examine all packages in the depgraph, or to actually use Portage to build and install TDE on that arch.
Just FYI, those could be easily traced back with repoman. ;)
And for the record, I strongly appose (if I may) keywording any arch unless there is a confirmed build for it, request for keywording, and an assurance/promise that it works fine enough.
It seems these isn't exactly clear now how to handle that and what, I just coming with some suggestion here.
We should offer all possible arches Gentoo can build on.
That includes all official supported arches, which are verified by Slavek already build for Debian. The last three arches aren't really official Gentoo supported arches, but it seems used too for some people.
At least we shouldn't exclude someone. If there are problems, we can take some arch out.
Also I think there is not really a point to use testing for our ebuilds if we add them. Because it should be more or less clear, the whole overlay is always a bit of testing, because not official. So we don't want to bug people with forcing them to add keywords the whole time.
That means adding new stable ebuilds should have all that stable arch keywords directly. But if there is some new 14.0.7 for example, we could say that keeps to be ~xxx for some month or so.
Let me think about what you think here. 😸
Historically, KDE3 was keyworded "alpha amd64 hppa ia64 ~mips ppc ppc64 sparc x86 ~x86-fbsd", but I'm a little reluctant to proceed in adding too many arches without at least emulator testing.
Adding ~arm and maybe ~arm64 would be useful, due to the increasingly wide deployment of those arches. I'm already mostly set up to test-build for 32-bit arm (specifically, RPi3), so testing that one is practical.
The other arches are obsolete or exotic and have very small user bases. Adding their keywords offers very little return.
mips64 and sparc64 aren't separate arches under Gentoo, BTW—they're sub-arches of mips and sparc, and don't have their own keywords. It's nearly impossible to compare lists of Debian and Gentoo arches directly. I tried that once. ;P
Between potential sub-arch issues (the set of chips Debian supports for a given arch may not be the same as the ones Gentoo supports), the size of the userbases, and having to check the status of all dependency packages for these minor arches, I think we should stick to "~amd64 ~arm ~arm64 ~x86", and add a note to any relevant readmes or wikis that "TDE should also work on alpha hppa ia64 ppc ppc64 sparc mips, but has not been tested on those arches under Gentoo. If you're using one of those arches and the TDE ebuilds work for you, great! Please drop us a line so that we can update our KEYWORDS." (At that point, I get to reread "man sed", for maximum arch-adding efficiency.)
Has anyone tried riscv yet?
I think we agree that amd64 and i386 are certainly tested. In addition, there are several architectures that can be considered tested with deb packages:
I'm worried about a few things, none of which has to do with whether TDE will actually run on those arches once built.
Keywording of dependencies under Gentoo for exotic arches. The official policy in the dev manual (at https://devmanual.gentoo.org/keywording/index.html ) states that if a package has a ~arch keyword, all its dependencies must also be at least ~arch. The only way to guarantee that for exotic arches is either to manually examine all packages in the depgraph, or to actually use Portage to build and install TDE on that arch.
Subarches and testing. mips has three subarches (o32, mipsel, mips64). arm has five (armv4, armv4t, armv5te, armv6j, armv7a). A couple of the others have two with different bitness or endianness. If your list above is correct, not all of these have been tested. Neither have hppa or ia64 in any variation. I'm willing to play a bit fast-and-loose with arm because I think there are substantial benefits, but not with the other arches.
Weird explosions in the build system due to old or deficient tooling on exotic arches. Again, we can only test this by actually installing TDE to these arches via Portage on Gentoo, so that we can ensure nothing was cross-compiled and no part of the build system was affected by a difference in patching. (Official policy is not to keyword anything that hasn't been directly tested on Gentoo.)
We don't have to follow the official policy, but it would improve TDE's chances of being accepted into layman or even the official Portage tree in the future. (As to whether the latter is possible, well, the main hurdle, once we get everything working, would be finding an official Gentoo dev willing to collaborate on the proxy-maintenance of a couple of hundred packages. Very difficult, but not quite impossible.)
Thanks for your constructive input here, @eliddell! 👍
You seems to be very into that and I see your point here and have looked a bit since yesterday and thought about what you wrote. The point about the maybe keyworded dependencies is some that came to my mind too. Not only that. It might be the case some of that dependencies, or future dependencies of TDE or of some TDE applications may be not existing for that arch at all - At least not in Gentoo. Otherwise, that one could be simply provided by our overlay, because if that upstream projects were just too old to work on that arch, TDE wouldn't run on that arch on Debian.
I wasn't exactly sure about the last three arches, but after talk with Slavek I did a quick search and found, some overlays have used that keywords in the past.
Meanwhile I looked at the old KDE3 ebuilds and eclasses and it seems at least for HPPA there had to be workarounds for building. That might be, like for most of that stuff, today not the case anymore for TDE. But it was some good point.
To be clear and I don't want to be pessimistic, that is absolutely not my nature normaly, but I don't see us to have that here ever included into the portage tree. I have too much read and experienced about that related to the ignorance of the developers here and I have already read what they think about TDE. We don't need them and as long as at least I use TDE on Gentoo, I would be willing to offer that here under the TDE umbrella, because I know the people here don't give a shit on what is done by me, to be directly.
But that is just about me - If you want to get it into portage, I would be willing to at least try it with all efforts. But TQt3 alone, which is very evil, because of a security hazard is a reason they never will include it. Starting that here was really because I saw, no one will do it after all and I am very happy you joined this efforts. 👍
Getting into layman could be some idea - To be honest, I haven't looked deeper into that. But with the right advertisement, we can spread the word about TDE as effective as beeing in Layman. At least I don't need any dictatorship from Gentoo. Right now we have all the freedom to do what we want with the overlay, get in touch with potential users and find solutions with them. It had some reason I copyrighted the ebuilds with TDE and not Gentoo. That said, I really love Gentoo, but I just get sick to see more and more ebuilds beeing removed and such things. After all it was about choice and freedom. I already plan to start some other overlay about that in future, which is some other topic. We will see.
From what you write, I get you want to handle this serious, which is fine and I like that. I want to do it that way too, but sometimes it is attracting more users to get involved if they just experience breackage at some point with some starting base, which only needs to be fixed to get something running. After all, that was the reason I joined TDE, with a half broken overlay as a base. If I hadn't even run it, I maybe never would have started to fix it. That is some psychological thing behind I thought it would be good to have support for all arches. Taking the number of the user base into account, if you honestly write down it isn't tested for all, but can be tested and you are open for fixes, isn't a good idea after all. That way Gentoo developers kick out ebuilds, because they think the large userbase will never use them - So that more and more Gentoo users are very unhappy they need to care about more and more ebuilds in their local overlays. I think we don't want to be that rude. 😸
At least one user I met in the IRC running TDE under Gentoo on ARM. I haven't asked more about that to that time. So ARM should be fine too and you can test it.
So after all, the stable ebuilds are a bit of your baby and if you are unhappy to get blamed they don't work or so, I am fine with that - But at least having PPC support would be some serious things, because if I think about KMilo, there is still that powerbook USE flag masked, I would likely get ride of at some point. 😅
Just FYI, those could be easily traced back with repoman. ;)
And for the record, I strongly appose (if I may) keywording any arch unless there is a confirmed build for it, request for keywording, and an assurance/promise that it works fine enough.