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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 67829@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 67829
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch