Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Qt 6 on X32 and HPPA ports: upstream requiring proof of usage
2 views
Skip to first unread message
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 11:52:00 AM2/2/23
to
Note: I'm not suscribed to debian-hppa, so please keep me and pkg-kde-talk
CCed
Hi!
Upstream has just required us for a proof that Qt 6 is being in use in your
ports:
<https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
cb357b65_46e7edcd>
If the outcome is "not working" or "not really being in use" they will
probably remove support from upstream's source code.
What is the current status of Qt 6 in your ports? Can you supply an image of
Qt 6 working on them?
Kinds regards, Lisandro.
CCed
Hi!
Upstream has just required us for a proof that Qt 6 is being in use in your
ports:
<https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
cb357b65_46e7edcd>
If the outcome is "not working" or "not really being in use" they will
probably remove support from upstream's source code.
What is the current status of Qt 6 in your ports? Can you supply an image of
Qt 6 working on them?
Kinds regards, Lisandro.
John Paul Adrian Glaubitz
Feb 2, 2023, 12:40:11 PM2/2/23
to
Hi Lisandro!
On Thu, 2023-02-02 at 13:48 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> Upstream has just required us for a proof that Qt 6 is being in use in your
> ports:
>
> <https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
> cb357b65_46e7edcd>
>
> If the outcome is "not working" or "not really being in use" they will
> probably remove support from upstream's source code.
>
> What is the current status of Qt 6 in your ports? Can you supply an image of
> Qt 6 working on them?
I'm not sure what they consider »support«, there are some pre-processor definitions
in the code which hardly can be considered a maintenance burden. Or are they going
to start adding large chunks of architecture-specific code? Not sure I understand
the motivation behind the question.
Besides that, the problem with Qt in this context are the large number of reverse
dependencies. If you break Qt on a given architecture, you will also break packages
such as Subversion and Git since they have transitive dependencies on Qt.
I don't think intentionally breaking Qt on a given architecture just because a maintainer
doesn't want to »maintain« a few lines of pre-processor code for it can be considered
good spirit.
Why would they do that?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Thu, 2023-02-02 at 13:48 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> Upstream has just required us for a proof that Qt 6 is being in use in your
> ports:
>
> <https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
> cb357b65_46e7edcd>
>
> If the outcome is "not working" or "not really being in use" they will
> probably remove support from upstream's source code.
>
> What is the current status of Qt 6 in your ports? Can you supply an image of
> Qt 6 working on them?
in the code which hardly can be considered a maintenance burden. Or are they going
to start adding large chunks of architecture-specific code? Not sure I understand
the motivation behind the question.
Besides that, the problem with Qt in this context are the large number of reverse
dependencies. If you break Qt on a given architecture, you will also break packages
such as Subversion and Git since they have transitive dependencies on Qt.
I don't think intentionally breaking Qt on a given architecture just because a maintainer
doesn't want to »maintain« a few lines of pre-processor code for it can be considered
good spirit.
Why would they do that?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 12:50:03 PM2/2/23
to
Hi Paul!
El jueves, 2 de febrero de 2023 14:35:40 -03 John Paul Adrian Glaubitz
escribió:
users, no matter how short/long it can be.
> Besides that, the problem with Qt in this context are the large number of
> reverse dependencies. If you break Qt on a given architecture, you will
> also break packages such as Subversion and Git since they have transitive
> dependencies on Qt.
Not for Qt 6... for now.
> I don't think intentionally breaking Qt on a given architecture just because
> a maintainer doesn't want to »maintain« a few lines of pre-processor code
> for it can be considered good spirit.
>
> Why would they do that?
Code maintenance. If they are not testing it on their CI and they do not find
real users of the code, they will simply remove it. We might or not agree with
them, but that's their code so their policies.
El jueves, 2 de febrero de 2023 14:35:40 -03 John Paul Adrian Glaubitz
escribió:
> Hi Lisandro!
>
> On Thu, 2023-02-02 at 13:48 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > Upstream has just required us for a proof that Qt 6 is being in use in
> > your
> > ports:
> >
> > <https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
> > cb357b65_46e7edcd>
> >
> > If the outcome is "not working" or "not really being in use" they will
> > probably remove support from upstream's source code.
> >
> > What is the current status of Qt 6 in your ports? Can you supply an image
> > of Qt 6 working on them?
>
> I'm not sure what they consider »support«, there are some pre-processor
> definitions in the code which hardly can be considered a maintenance
> burden. Or are they going to start adding large chunks of
> architecture-specific code? Not sure I understand the motivation behind the
> question.
Pruning whatever code they do not test on the CI and does not has active
>
> On Thu, 2023-02-02 at 13:48 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > Upstream has just required us for a proof that Qt 6 is being in use in
> > your
> > ports:
> >
> > <https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
> > cb357b65_46e7edcd>
> >
> > If the outcome is "not working" or "not really being in use" they will
> > probably remove support from upstream's source code.
> >
> > What is the current status of Qt 6 in your ports? Can you supply an image
> > of Qt 6 working on them?
>
> I'm not sure what they consider »support«, there are some pre-processor
> definitions in the code which hardly can be considered a maintenance
> burden. Or are they going to start adding large chunks of
> architecture-specific code? Not sure I understand the motivation behind the
> question.
users, no matter how short/long it can be.
> Besides that, the problem with Qt in this context are the large number of
> reverse dependencies. If you break Qt on a given architecture, you will
> also break packages such as Subversion and Git since they have transitive
> dependencies on Qt.
> I don't think intentionally breaking Qt on a given architecture just because
> a maintainer doesn't want to »maintain« a few lines of pre-processor code
> for it can be considered good spirit.
>
> Why would they do that?
real users of the code, they will simply remove it. We might or not agree with
them, but that's their code so their policies.
Sam James
Feb 2, 2023, 1:20:03 PM2/2/23
to
> On 2 Feb 2023, at 17:44, Lisandro Damián Nicanor Pérez Meyer <perez...@gmail.com> wrote:
>
> Hi Paul!
>
> El jueves, 2 de febrero de 2023 14:35:40 -03 John Paul Adrian Glaubitz
> escribió:
>> Hi Lisandro!
>>
>> On Thu, 2023-02-02 at 13:48 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>>> Upstream has just required us for a proof that Qt 6 is being in use in
>>> your
>>> ports:
>>>
>>> <https://codereview.qt-project.org/c/qt/qtbase/+/437349/comments/
>>> cb357b65_46e7edcd>
>>>
>>> If the outcome is "not working" or "not really being in use" they will
>>> probably remove support from upstream's source code.
>>>
>>> What is the current status of Qt 6 in your ports? Can you supply an image
>>> of Qt 6 working on them?
>>
>> I'm not sure what they consider »support«, there are some pre-processor
>> definitions in the code which hardly can be considered a maintenance
>> burden. Or are they going to start adding large chunks of
>> architecture-specific code? Not sure I understand the motivation behind the
>> question.
>
> Pruning whatever code they do not test on the CI and does not has active
> users, no matter how short/long it can be.
suggested adding cross HPPA (and maybe others) to their Docker setup. That could be a start.
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 1:30:03 PM2/2/23
to
El jueves, 2 de febrero de 2023 15:08:49 -03 Sam James escribió:
[snip]
to add yet another CI image except they have a big client requiring it :-/
I'll bring it up next week, but I will not have high expectations on this.
[snip]
> > Pruning whatever code they do not test on the CI and does not has active
> > users, no matter how short/long it can be.
>
> At
> https://codereview.qt-project.org/c/qbs/qbs/+/437296/comments/9b34cbab_87ce
> d2e4, someone suggested adding cross HPPA (and maybe others) to their Docker
> setup. That could be a start.
I'm quite in contact with the CI staff. I sincerely don't think they will want
> > users, no matter how short/long it can be.
>
> At
> https://codereview.qt-project.org/c/qbs/qbs/+/437296/comments/9b34cbab_87ce
> d2e4, someone suggested adding cross HPPA (and maybe others) to their Docker
> setup. That could be a start.
to add yet another CI image except they have a big client requiring it :-/
I'll bring it up next week, but I will not have high expectations on this.
Helge Deller
Feb 2, 2023, 2:00:07 PM2/2/23
to
On 2/2/23 19:21, Lisandro Damián Nicanor Pérez Meyer wrote:
> El jueves, 2 de febrero de 2023 15:08:49 -03 Sam James escribió:
> [snip]
>>> Pruning whatever code they do not test on the CI and does not has active
>>> users, no matter how short/long it can be.
>>
>> At
>> https://codereview.qt-project.org/c/qbs/qbs/+/437296/comments/9b34cbab_87ce
>> d2e4, someone suggested adding cross HPPA (and maybe others) to their Docker
>> setup. That could be a start.
>
> I'm quite in contact with the CI staff. I sincerely don't think they will want
> to add yet another CI image except they have a big client requiring it :-/
I think this will only be debian, and gentoo - both distributions support hppa.
> El jueves, 2 de febrero de 2023 15:08:49 -03 Sam James escribió:
> [snip]
>>> Pruning whatever code they do not test on the CI and does not has active
>>> users, no matter how short/long it can be.
>>
>> At
>> https://codereview.qt-project.org/c/qbs/qbs/+/437296/comments/9b34cbab_87ce
>> d2e4, someone suggested adding cross HPPA (and maybe others) to their Docker
>> setup. That could be a start.
>
> I'm quite in contact with the CI staff. I sincerely don't think they will want
> to add yet another CI image except they have a big client requiring it :-/
> I'll bring it up next week, but I will not have high expectations on this.
with other things to look into it. And, I was hoping someone would fix it
as it seemed trivial.
Beside the CI, we have two debian porterboxes for hppa, so testing is possible.
Helge
Helge Deller
Feb 2, 2023, 2:20:04 PM2/2/23
to
https://buildd.debian.org/status/logs.php?pkg=qt6-base&arch=hppa
I'd like to get it to build always...
I mentioned the porterboxes to ease build-testing for debian developers.
Helge
Sam James
Feb 2, 2023, 2:30:04 PM2/2/23
to
> On 2 Feb 2023, at 19:23, John David Anglin <dave....@bell.net> wrote:
>
> It's full of 32-bit issues:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030315
>
> But the main problem is linking a shared object against a non-PIC archive library.
>
> I was the one that provided the Q_PROCESSOR defines. At that time the package built successfully.
>
> I assume this is about money (Commercial contract support).
By the way, someone showed me https://lists.qt-project.org/pipermail/development/2023-February/043594.html,
But we should probably talk about that and other hassle on libc-alpha or the new distributions ML ;)
John David Anglin
Feb 2, 2023, 2:30:07 PM2/2/23
to
That's being snarky. qt6-base came out of experimental on 2022-12-30.
It's full of 32-bit issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030315
But the main problem is linking a shared object against a non-PIC archive library.
I was the one that provided the Q_PROCESSOR defines. At that time the package built successfully.
I assume this is about money (Commercial contract support).
Dave
It's full of 32-bit issues:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030315
But the main problem is linking a shared object against a non-PIC archive library.
I was the one that provided the Q_PROCESSOR defines. At that time the package built successfully.
I assume this is about money (Commercial contract support).
--
John David Anglin dave....@bell.net
Sam James
Feb 2, 2023, 2:30:10 PM2/2/23
to
believe it or not ;)
As for Debian: I guess Helge means "new build fails", not "the package isn't available".
Debian users do not build from source usually, so they wouldn't notice a problem.
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 2:40:03 PM2/2/23
to
El jueves, 2 de febrero de 2023 16:25:17 -03 Sam James escribió:
[snip]
[snip]
> > I assume this is about money (Commercial contract support).
>
> By the way, someone showed me
> https://lists.qt-project.org/pipermail/development/2023-February/043594.htm
> l, But we should probably talk about that and other hassle on libc-alpha or
> the new distributions ML ;)
Ha! Thiago is the one asking for the images. Fix the patch on HPPA/X32 and he
>
> By the way, someone showed me
> https://lists.qt-project.org/pipermail/development/2023-February/043594.htm
> l, But we should probably talk about that and other hassle on libc-alpha or
> the new distributions ML ;)
will probably just keep the status -quo ;-)
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 2:40:03 PM2/2/23
to
> It's full of 32-bit issues
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030315
>
> But the main problem is linking a shared object against a non-PIC archive
> library.
>
> I was the one that provided the Q_PROCESSOR defines. At that time the
> package built successfully.
>
> I assume this is about money (Commercial contract support).
works for TQtC. He just wants to keep code that is really being in use, and he
asks for this for non-common archs.
Diederik de Haas
Feb 2, 2023, 3:20:12 PM2/2/23
to
On 2 February 2023 20:38:10 CET Lisandro Damián Nicanor Pérez Meyer wrote:
> El jueves, 2 de febrero de 2023 16:25:17 -03 Sam James escribió:
> > https://lists.qt-project.org/pipermail/development/2023-February/043594.html
> El jueves, 2 de febrero de 2023 16:25:17 -03 Sam James escribió:
>
> Ha! Thiago is the one asking for the images. Fix the patch on HPPA/X32 and
> he will probably just keep the status -quo ;-)
FTR: Bullseye has 5.10; Buster has 4.19 'by default' although there is
> Ha! Thiago is the one asking for the images. Fix the patch on HPPA/X32 and
> he will probably just keep the status -quo ;-)
a 5.10 kernel available in Buster Backports.
Thorsten Glaser
Feb 2, 2023, 3:30:07 PM2/2/23
to
Lisandro Damián Nicanor Pérez Meyer dixit:
>> I assume this is about money (Commercial contract support).
>
>No, in fact the qtcore maintainer, the one asking for images, does not even
>works for TQtC.
Hmh. Thiago is big money, too, though, from what I could see
on the mailing list…
>What is the current status of Qt 6 in your ports? Can you supply an image of
>Qt 6 working on them?
(Note I haven’t been a porter for x32 for a while though I may
still jump in occasionally.)
I wasn’t even aware that Qt6 in Debian is a thing, given your
mail from a year or two ago writing that you have no intent to
package it, let alone that anything is using it. I do see that
qjackctl is apparently using it… colour me surprised. I mostly
switched from sid to bullseye though to avoid UsrMove.
I’d love to provide a working image of it but qt6-base does not
build on x32 because it attempts to use amd64-specific inline
assembly code and (rightfully) this fails. Apparently it hasn’t
been ported to x32 yet.
I *have* successfully used Qt5 on x32 for a long time, e.g.
with musescore{2,3}, if that helps.
bye,
//mirabilos
--
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
>> I assume this is about money (Commercial contract support).
>
>No, in fact the qtcore maintainer, the one asking for images, does not even
>works for TQtC.
on the mailing list…
>What is the current status of Qt 6 in your ports? Can you supply an image of
>Qt 6 working on them?
still jump in occasionally.)
I wasn’t even aware that Qt6 in Debian is a thing, given your
mail from a year or two ago writing that you have no intent to
package it, let alone that anything is using it. I do see that
qjackctl is apparently using it… colour me surprised. I mostly
switched from sid to bullseye though to avoid UsrMove.
I’d love to provide a working image of it but qt6-base does not
build on x32 because it attempts to use amd64-specific inline
assembly code and (rightfully) this fails. Apparently it hasn’t
been ported to x32 yet.
I *have* successfully used Qt5 on x32 for a long time, e.g.
with musescore{2,3}, if that helps.
bye,
//mirabilos
--
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles
kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Lisandro Damián Nicanor Pérez Meyer
Feb 2, 2023, 4:40:05 PM2/2/23
to
El jueves, 2 de febrero de 2023 16:58:04 -03 Thorsten Glaser escribió:
> Lisandro Dami�n Nicanor P�rez Meyer dixit:
[snip]
some stuff here and there, sometimes as liason between upstream and Debian.
> I’d love to provide a working image of it but qt6-base does not
> build on x32 because it attempts to use amd64-specific inline
> assembly code and (rightfully) this fails. Apparently it hasn’t
> been ported to x32 yet.
>
> I *have* successfully used Qt5 on x32 for a long time, e.g.
> with musescore{2,3}, if that helps.
Thanks for the feedback!
> Lisandro Dami�n Nicanor P�rez Meyer dixit:
[snip]
> >What is the current status of Qt 6 in your ports? Can you supply an image
> >of Qt 6 working on them?
>
> (Note I haven’t been a porter for x32 for a while though I may
> still jump in occasionally.)
>
> I wasn’t even aware that Qt6 in Debian is a thing, given your
> mail from a year or two ago writing that you have no intent to
> package it, let alone that anything is using it. I do see that
> qjackctl is apparently using it… colour me surprised. I mostly
> switched from sid to bullseye though to avoid UsrMove.
The main Qt maintainer is Patrick Franz, I'm just taking care of backports and
> >of Qt 6 working on them?
>
> (Note I haven’t been a porter for x32 for a while though I may
> still jump in occasionally.)
>
> I wasn’t even aware that Qt6 in Debian is a thing, given your
> mail from a year or two ago writing that you have no intent to
> package it, let alone that anything is using it. I do see that
> qjackctl is apparently using it… colour me surprised. I mostly
> switched from sid to bullseye though to avoid UsrMove.
some stuff here and there, sometimes as liason between upstream and Debian.
> I’d love to provide a working image of it but qt6-base does not
> build on x32 because it attempts to use amd64-specific inline
> assembly code and (rightfully) this fails. Apparently it hasn’t
> been ported to x32 yet.
>
> I *have* successfully used Qt5 on x32 for a long time, e.g.
> with musescore{2,3}, if that helps.
Thorsten Glaser
Feb 3, 2023, 6:40:03 AM2/3/23
to
Sam James dixit:
>By the way, someone showed me
>https://lists.qt-project.org/pipermail/development/2023-February/043594.html,
This is conflating 32-bit architectures with 32-bit time_t.
There have been 32-bit architectures with 64-bit time_t for
a very long time (I should know as MirBSD/i386 was one of
the first, if not the first in FOSS), and 32-bit Debian
architectures, these we’ll bring forward anyways, are going
to be converted to 64-bit time_t, if they don’t already use
it, like x32.
Incidentally, this has been a porting issue as software is
often not prepared for 64-bit time_t…
But there’s absolutely no reason to kill the others before
2038 either.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
>By the way, someone showed me
>https://lists.qt-project.org/pipermail/development/2023-February/043594.html,
There have been 32-bit architectures with 64-bit time_t for
a very long time (I should know as MirBSD/i386 was one of
the first, if not the first in FOSS), and 32-bit Debian
architectures, these we’ll bring forward anyways, are going
to be converted to 64-bit time_t, if they don’t already use
it, like x32.
Incidentally, this has been a porting issue as software is
often not prepared for 64-bit time_t…
But there’s absolutely no reason to kill the others before
2038 either.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Thorsten Glaser
Feb 3, 2023, 6:40:03 AM2/3/23
to
Lisandro Damián Nicanor Pérez Meyer dixit:
>> I wasn’t even aware that Qt6 in Debian is a thing, given your
>> mail from a year or two ago writing that you have no intent to
>> mail from a year or two ago writing that you have no intent to
>The main Qt maintainer is Patrick Franz, I'm just taking care of backports and
>some stuff here and there, sometimes as liason between upstream and Debian.
Ah okay.
>some stuff here and there, sometimes as liason between upstream and Debian.
>Thanks for the feedback!
If you get Qt6 ported to x32 I’ll gladly test what I’m able to,
even if it’ll be a M-A setup or a chroot, no full “boot into x32”
any more. That won’t be relevant for this, though.
bye,
//mirabilos
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für
ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist
Sam James
Feb 3, 2023, 6:40:04 AM2/3/23
to
> On 3 Feb 2023, at 11:25, Thorsten Glaser <t...@debian.org> wrote:
>
> Sam James dixit:
>
>> By the way, someone showed me
>> https://lists.qt-project.org/pipermail/development/2023-February/043594.html,
>
> This is conflating 32-bit architectures with 32-bit time_t.
taking the opportunity to bring it up wrt Qt portability.
(And because we still need to figure out plans for the transition
in the Linux world. Indeed, I wish there'd been a hard switch
in glibc years ago, but that ship has sailed.)
Lisandro Damián Nicanor Pérez Meyer
Feb 3, 2023, 8:20:09 AM2/3/23
to
El viernes, 3 de febrero de 2023 08:27:59 -03 Thorsten Glaser escribió:
> Lisandro Dami�n Nicanor P�rez Meyer dixit:
for Qt (that's why I'm not in Uploaders). So I'm afraid nothing will change if
it depends on me.
> Lisandro Dami�n Nicanor P�rez Meyer dixit:
> >> I wasn’t even aware that Qt6 in Debian is a thing, given your
> >> mail from a year or two ago writing that you have no intent to
> >
> >The main Qt maintainer is Patrick Franz, I'm just taking care of backports
> >and some stuff here and there, sometimes as liason between upstream and
> >Debian.
> Ah okay.
>
> >Thanks for the feedback!
>
> If you get Qt6 ported to x32 I’ll gladly test what I’m able to,
> even if it’ll be a M-A setup or a chroot, no full “boot into x32”
> any more. That won’t be relevant for this, though.
I personally lack any more free time to handle ports, I even lack proper time
> >> mail from a year or two ago writing that you have no intent to
> >
> >The main Qt maintainer is Patrick Franz, I'm just taking care of backports
> >and some stuff here and there, sometimes as liason between upstream and
> >Debian.
> Ah okay.
>
> >Thanks for the feedback!
>
> If you get Qt6 ported to x32 I’ll gladly test what I’m able to,
> even if it’ll be a M-A setup or a chroot, no full “boot into x32”
> any more. That won’t be relevant for this, though.
for Qt (that's why I'm not in Uploaders). So I'm afraid nothing will change if
it depends on me.
0 new messages