Could not find gn executable at: /ungoogled-chromium-debian/buildtools/linux64/gn OS: Ubuntu 22.04 #334
Comments
raphael10-collab
changed the title
|
Interesting, I'm using sbuild to build on a chroot, it looks similar but not quite. Seems to be an issue at https://commondatastorage.googleapis.com/chromium-browser-clang where the specified clang pre-compiled binaries is no longer available.
Checking... |
|
Indeed, to at tools/clang/scripts/update.py That should get you pass that line. |
|
Oh well, later on seems that we need a specific version otherwise it will fail. So yeah, we need to track the compatible version and try again, and so on as many times an issue is found. |
|
Hi @Ark74 ! |
|
So far, no idea. |
|
@raphael10-collab based on the open PR #328 there is already a PPA with the latest version. I've been testing it and it works and builds correctly, thanks to @jhonny-oliveira Regards. |
|
@Ark74 Thank you . Actually I need the source code, and the correct working way to build it |
Check this out: #328 (comment) You might no longer need the PRs (they were already merged) or you might needs new ones (with new fixes). For a matter of alignment, I usually download the source from here: https://packages.debian.org/sid/chromium. Hope this helps! Cheers! |
|
Hi @jhonny-oliveira ! Thanks for the links. I downloaded .deb file from here :https://packages.debian.org/sid/amd64/chromium/download But during the source extraction I get this error: |
|
@jhonny-oliveira I was able to build using your PPA source in amd64, for ppc64el I added this patch and some small changes in our helper, it is still building. armhf and arm64 were failing, I'll test back again once ppc64el finish, if the whole set succeeds it's possible we could integrate it on the trisquel repo. Cheers! |
|
@raphael10-collab dpkg-source -x works with tarballs and .dsc files, .deb are binaries, they don't have source in it, unless it's stated the binary contains the source, but that's not the case for this package. To get the source code go at the bottom of the page in: Download the 3 files, 2 tar.xz and 1 dsc on the same directory, then do, Then you'll have the sid chromium source (not ungoogled-chromium), keep in mind that is very likely Debian Sid dependencies won't be compatible with Jammy's ones, as Sid is the "unstable" branch. Regards. |
|
@Ark74 Thank you Luis Till the But the |
|
Hi @Ark74, could you elaborate on why ppc64el needs ThinLTO disabled? I can integrate such a change into the XtraDeb source if needed. (Please note that @jhonny-oliveira and I are still working on the automation to get ungoogled-chromium converted and updated automatically. Updates, let alone security updates, will be delayed until we have that in place. We will also be releasing the script we use to perform the Ubuntu conversion from the Debian source.) @raphael10-collab, note that the files under |
|
@iskunk I did several testing, and I always hit the same error, something along the lines: After not finding much information that Debian developers have decided to disable lto on chromium Debian#1015367 and comparing build environments for chromium and ungoogled-chromium I found that thin-lto is disabled in chromium, just by disabling thin-lto ppc64el started to build fine without any other change. arm64(/hf) had been failing, since I've updated to not use thin-lto they seem will finish building, so I'm looking to disable to all but amd64. ATTOW,
Which are the most progress or any of those archs. You may be able to confirm my findings on the PPA build nodes. Thank you guys for all the work you are putting here. |
|
I've restarted from scratch: It seems different now: I do not see the convert folder anymore |
|
@Ark74: Thank you for bringing this to my attention. I was able to reproduce that error using QEMU. It took some digging, but I was able to track down the issue to this bit in The GN logic appears to assume that if you're building for any of those architectures, then you're not using Clang---which is clearly incorrect in the case of ppc64el. Please try removing/disabling the What errors were you seeing on arm64 / armhf? Also, some clarifications on LTO:
@raphael10-collab: If you're not already comfortable with handling and building Debian source packages, then there is not much I can do to get you through it. Using the conversion framework I've put together requires experience in that area. Could you talk about why you wish to build this yourself, instead of using pre-built packages? If you have concerns about the integrity of the build, then there may be an alternative way of addressing that. |
|
@iskunk you are right, removing arm64/hf didn't show some clear error output, just failing randomly, I'm using a couple of RPi4 8GB RAM, but even if you get access to some AWS ARM metal servers, they also failed on my first tests. I'll run some new tests, and comment on the output, regards. |
|
@iskunk I can confirm now that ppc64el passes with that change.
I'm not sure if the v4l2 issues comes from trisquel or plain ubuntu, last time I succeed using this patch and disabling thin-lto. |
|
Yes, the v4l2 issue is due to Ubuntu jammy's kernel not being new enough. (Lunar and later are good.) That patch you linked is the right idea, but you should use these settings: This is what Debian uses in their bullseye build. See this bug for background. That One thing I forgot to mention earlier: If you can, try to wrap your builds with |
I guess linux-hwe-6.2 could work, but that would require a non-standard dependency, so yeah, I guess it's better to disable it for now. I've updated the logs for arm on a trisquel env, seems like the aws tripped somehow. Update: Here it is the AWS build log, success for arm64, I guess this proves the point so this could be proven to actually work for jammy, I'll continue testing on the rpi4, once I have room. |
|
@iskunk news on the armhf build on the rpi4. I guess the important part is: About This rpi has a 8GB swap file, I guess I could easily double that, but I'm not sure if that would work / be enough, any suggestion? Regards. |
|
@Ark74: I didn't expect the armhf build max RSS to top out at under 4 GB RAM. Can armhf programs not address more than that, like (32-bit) x86 with PAE? I'm currently running an armhf build in QEMU with In which case, the only way to build a ThinLTO-optimized Chromium for armhf would be to cross-compile. I don't believe the source package is set up to allow cross-compilation... @raphael10-collab: You might want to try ungoogled-chromium in the XtraDeb applications PPA. The source has been converted, and there are binary builds there too if you want. The downside is that the version is a bit behind---@jhonny-oliveira and I are still working on the update infrastructure. |
|
An update: I've confirmed that the final link, on armhf with ThinLTO enabled, is impossible. The build failed similarly at the My hope that there was some way a 32-bit program could access more than 4 GB memory was for naught :-( So that confirms, then, that building Chromium with ThinLTO is not possible on an armhf build host, and probably any 32-bit host as well (so also x86). Which is a bummer, because those platforms need all the speed-ups they can get. For the record, here are the stats on the bulk of my (armhf via QEMU) build. @Ark74's little RPi beat the snot out of my 8-CPU VM: |
|
@iskunk I wonder if linux-image-generic-lpae could make any difference on the memory usage. I'm running a test, we'll find out later in the week. Update: No change, so yeah seems like armhf should have thin-lto disabled. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
generate-ninjais installed :But following these building steps: https://github.com/ungoogled-software/ungoogled-chromium-debian :
UngoogleChromiumUbuntu22.04DesktopBuildingStepsFollowed.txt
I get this error:
Other info:
How to make it work?
The text was updated successfully, but these errors were encountered: