qtwebengine new failure on i686

  • Open
  • quality assurance status badge
Details
3 participants
  • Efraim Flashner
  • John Kehayias
  • Maxim Cournoyer
Owner
unassigned
Submitted by
Maxim Cournoyer
Severity
normal
M
M
Maxim Cournoyer wrote on 14 Dec 2023 21:33
(name . bug-guix)(address . bug-guix@gnu.org)
8734w48qxe.fsf@gmail.com
Hello,

qtwebengine was marked as newly failing by Cuirass on Berlin, as a
result to the xorg-server update in

Toggle snippet (27 lines)
v8_use_external_startup_data=false
CMake Error at /tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75 (message):

-- GN FAILED

ERROR at //BUILD.gn:1652:1: Assertion failed.

assert(

^-----

'target_cpu=x86' is not supported for 'target_os=linux'. Consider omitting
'target_cpu' (default) or using 'target_cpu=x64' instead.

See //BUILD.gn:1653:5:

is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
^-------------------------------------------------------------------

This is where it was set.

1

ninja: build stopped: subcommand failed.

I don't see how the two would be related, but I've CC'd John in case
they'd have some hunch.

Perhaps some non-deterministic issue with the 'gn' build system? It had
week ago.

--
Thanks,
Maxim
J
J
John Kehayias wrote on 15 Dec 2023 07:04
(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)
874jgkrogm.fsf@protonmail.com
Hello Maxim,

On Thu, Dec 14, 2023 at 03:33 PM, Maxim Cournoyer wrote:

Toggle quote (4 lines)
> Hello,
>
> qtwebengine was marked as newly failing by Cuirass on Berlin, as a

This "newly failing" is the same false alarm as we saw recently. I
think Cuirass gets confused on same package with different versions as
the only one I see on i686-linux building in the past year is v5.

Toggle quote (36 lines)
> result to the xorg-server update in
> <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8083c7abbf3a346162fcc4b8d5aa50555c0f3179>.
>
> v8_use_external_startup_data=false
> CMake Error at /tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75 (message):
>
>
> -- GN FAILED
>
> ERROR at //BUILD.gn:1652:1: Assertion failed.
>
> assert(
>
> ^-----
>
> 'target_cpu=x86' is not supported for 'target_os=linux'. Consider omitting
> 'target_cpu' (default) or using 'target_cpu=x64' instead.
>
> See //BUILD.gn:1653:5:
>
> is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
> ^-------------------------------------------------------------------
>
> This is where it was set.
>
> 1
>
> ninja: build stopped: subcommand failed.
>
> I don't see how the two would be related, but I've CC'd John in case
> they'd have some hunch.
>
> Perhaps some non-deterministic issue with the 'gn' build system? It had
> succeeded here: <https://ci.guix.gnu.org/build/2803939/details> about a
> week ago.

As for the actual error, no idea (I saw the same thing when I noticed
the "new failure"). But I'm cc'ing Efraim as having figured out the
fix for the other package (sorry don't remember which, qt something)
on i686 recently...

John
E
E
Efraim Flashner wrote on 16 Dec 2023 18:34
(name . John Kehayias)(address . john.kehayias@protonmail.com)
ZX3frUhH_OMwr8T1@3900XT
On Fri, Dec 15, 2023 at 06:04:30AM +0000, John Kehayias wrote:
Toggle quote (53 lines)
> Hello Maxim,
>
> On Thu, Dec 14, 2023 at 03:33 PM, Maxim Cournoyer wrote:
>
> > Hello,
> >
> > qtwebengine was marked as newly failing by Cuirass on Berlin, as a
>
> This "newly failing" is the same false alarm as we saw recently. I
> think Cuirass gets confused on same package with different versions as
> the only one I see on i686-linux building in the past year is v5.
>
> > result to the xorg-server update in
> > <https://git.savannah.gnu.org/cgit/guix.git/commit/?id=8083c7abbf3a346162fcc4b8d5aa50555c0f3179>.
> >
> > v8_use_external_startup_data=false
> > CMake Error at /tmp/guix-build-qtwebengine-6.5.2.drv-0/qtwebengine-everywhere-src-6.5.2/cmake/Gn.cmake:75 (message):
> >
> >
> > -- GN FAILED
> >
> > ERROR at //BUILD.gn:1652:1: Assertion failed.
> >
> > assert(
> >
> > ^-----
> >
> > 'target_cpu=x86' is not supported for 'target_os=linux'. Consider omitting
> > 'target_cpu' (default) or using 'target_cpu=x64' instead.
> >
> > See //BUILD.gn:1653:5:
> >
> > is_valid_x86_target || target_cpu != "x86" || v8_target_cpu == "arm",
> > ^-------------------------------------------------------------------
> >
> > This is where it was set.
> >
> > 1
> >
> > ninja: build stopped: subcommand failed.
> >
> > I don't see how the two would be related, but I've CC'd John in case
> > they'd have some hunch.
> >
> > Perhaps some non-deterministic issue with the 'gn' build system? It had
> > succeeded here: <https://ci.guix.gnu.org/build/2803939/details> about a
> > week ago.
>
> As for the actual error, no idea (I saw the same thing when I noticed
> the "new failure"). But I'm cc'ing Efraim as having figured out the
> fix for the other package (sorry don't remember which, qt something)
> on i686 recently...

Upstream chromium removed support for i686 so that's why it's failing.


There's two or three patches we can add to re-enable builds on i686, or
we can mark it as unsupported. I don't have a strong opinion either
way.

It also looks like debian doesn't support very many architectures with
qtwebengine@6


They also have limited architectures for qtwebengine@5


--
Efraim Flashner <efraim@flashner.co.il> ????? ?????
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoov0DD5VE3JmLRT3Qarn3Mo9g1EFAmV936oACgkQQarn3Mo9
g1GhIRAApw5o5Y5vzPDE8gm/jh2aZjCBRikMeWQvVfONjztVlP4dcOfjc+fJ+OW3
5Ms67F+zcHhO8VfvC5AQCA1SnSU7ffn+RIzeOXKCeOchPC3dzSoD6mToRUI6BpOM
0NRq10y9IcfjUcMPsckYdY+MVAvlVITsL8W8N6K/9tLRJgRyLdyXPuCTl4OrIY3U
+REKPyzqsspvON9oNJv9CMCqm4vOZ1tQbslO5Oc1AhEMgw24k+mCFdTlykqkrKbQ
I7lVPB3msK3QLOg286lZcLtmE/1XgL84QtTVmDtuPvEZa/DXPRm05XxcCKmzCw4e
c5p37lpjibRNi1eGbnNADRYwVaU6BuQbBAeRPU1YgVm8yFAVTffftRCL1agzs13O
6jBk6Nk4EN/XcRID12OK3yRs3Nixn84lEaJ4uHOVvkF3IcUVoTOpOIT8T/1U6jWZ
X63NyJQkQODn25V9mSk8111eg2XcDhXgpR7aUrX90MO8u5X2CG0R0LW6KCRqg5DD
kX8kePxDU2oek5IlyXj6XnREvaxajtORmbrx8PL2QVuzpqmwNFUHuZEVHfNcPup3
4EKSQAIFWDEOcrBJ/YEmOtK2ViT3ba/92kVmSftzoE5oJPIfptKYOnv2DgjA4Y86
coOOmHtz0lXRdfoKstcp+/aouV4S4HLlO7WB7FN2qpwk5SGb8/A=
=vp6u
-----END PGP SIGNATURE-----


M
M
Maxim Cournoyer wrote on 19 Dec 2023 17:46
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87edfi5edu.fsf@gmail.com
Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

[...]

Toggle quote (10 lines)
> Upstream chromium removed support for i686 so that's why it's failing.
>
> https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/support-i386.patch/
> https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/disable_32bit_node_check.patch/
> https://sources.debian.org/src/qt6-webengine/6.6.1%2Bdfsg-1/debian/patches/compressing_files.patch/
>
> There's two or three patches we can add to re-enable builds on i686, or
> we can mark it as unsupported. I don't have a strong opinion either
> way.

If Debian already did the hard work, the best option seems to use their
patches to enable the build on i686 at least :-). If it becomes to hard
to maintain and they lag on upstream, we could reconsider just marking
it as unsupported.

--
Thanks,
Maxim
?