search

ungoogled-software / ungoogled-chromium

Google Chromium, sans integration with Google
BSD 3-Clause "New" or "Revised" License
20.19k stars 817 forks source link

Armhf.deb for the Pinebook Pro #941

Closed pinebookfan closed 4 years ago

pinebookfan commented 4 years ago

Nothing more to say. Armhf.deb support for the Pinebook Pro Debian 9 Stretch. Still no private browser for this notebook out yet. Thanx!

ghost commented 4 years ago

Support for Debian 9 was dropped awhile ago. I do maintain a PPA for Ubuntu's arm ports but I know of no such resource for Debian 10 or otherwise.

pinebookfan commented 4 years ago

Can i install this port on pinebook debian 9?

ghost commented 4 years ago

I would not advise it. It was built for Bionic and Eoan. It's only likely to work in those environments. Isn't the Pinebook Pro compatible with a Bionic based environment?

pinebookfan commented 4 years ago

debian 10 armhf would be also great, because there will be hopefully an update soon...

ghost commented 4 years ago

I'm sure someone could build an armhf build for Debian 10 but I cannot do so. I have no such hardware. Maybe you could try building it yourself in the meantime if you prefer Debian that much. I suspect this problem could be solved if we ever manage to get OBS working. As it stands my PPA only has arm builds thanks to the Ubuntu build farm.

mbakke commented 4 years ago

GNU Guix has an AArch64 port of ungoogled-chromium which should work on Pinebook Pro, FWIW.

Guix is a package manager that can be installed on any system running the Linux kernel, and is designed to be completely isolated and independent from the "host" operating system.

Guix can also be used as a standalone operating system, there are patches to support Pinebook Pro here (this is much more involved than installing guix-the-package-manager on top of say Debian): https://issues.guix.gnu.org/issue/39617

Edit: added links

ghost commented 4 years ago

@pinebookfan what's stopping you from installing a different OS image? We already told you that the only ready to go armhf / aarch64 build is from the Ubuntu PPA for Bionic. There's already an image for Ubuntu Bionic MATE and it appears the default Debian 9 image uses MATE. So this would seem to be the most sensible option to give you what you want at this point in time.

More information is here about the image: https://wiki.pine64.org/index.php/Pinebook_Pro_Software_Release#Bionic_Mate

As for the PPA it can be found here: https://launchpad.net/~braewoods/+archive/ubuntu/ungoogled-chromium

pinebookfan commented 4 years ago

Sorry guys Ubuntu is spyware. they using amazon data collection. The armhf version is good for widevine means your streaming video services works! (I now netflix is spyware too :)) I tried a lot of os and i can say you that only the orginal debian runs really fast and good with the most support. Only the upgrade to debian 10 would be great, but they wait until it is smooth Guix is a great OS! I think for richard stallmann too :)

So if i install it this way: https://github.com/detrout/debian-guix It should work? And the installed apps running smooth? Not in a VM scenario?

pinebookfan commented 4 years ago

Oh no this link is for amd64 :D Sorry

ghost commented 4 years ago

Granted there's Amazon integration with the regular Ubuntu desktop but the MATE flavor does not have it to my knowledge.

pinebookfan commented 4 years ago

I think the easiest way is to wait for debian 10 update. So ich can install appimagelauncher. ungoogled chromium should work with this =)

pinebookfan commented 4 years ago

Or i'm wrong? okay good to know :) i'm not trusting ubuntu...

mbakke commented 4 years ago

@pinebookfan I recommend installing Guix with this shell installer script (as mentioned in the manual).

After logging out and in again, you should be able to guix pull and then guix install ungoogled-chromium, no root necessary. Obviously you can install any of the other 12k packages available in Guix too.

pinebookfan commented 4 years ago

AppImageLauncherNow works on Pinebook Pro: https://github.com/TheAssassin/AppImageLauncher/releases

So an armhf appimage is now possible! Make it's easier to make maybe :)

I try guix pull and guix install ungoogled chromium right now. But maybe it's not working with the installer script because it chose aarch64 and not armhf like you can find here: https://ftp.gnu.org/gnu/guix/

pinebookfan commented 4 years ago

So no chance with the script because the script want to use aarch64 architecture. I manual installed armhf but now the "guix pull" still runnning... i'm waiting...

pinebookfan commented 4 years ago

"Kernel Linux 4.4.213 aarch64" is my pinebook pro, but with the aarch64 i get only errors, so i think because of the 32bit debian version the armhf should be right? But the guix pull everytime stuck and freeze... i think, or is running way to long.

ghost commented 4 years ago

@pinebookfan Perhaps you would have an easier time installing Armbian which has a version based on Debian Buster. Or do you also distrust that?

See here: https://www.armbian.com/pinebook-pro/

mbakke commented 4 years ago

@pinebookfan oh sorry, I missed that you were running a 32-bit userland. However if your kernel is 64-bit then Guix should still work.

(Guix runs on 32-bit ARM too, but one of the ungoogled-chromium dependencies are failing to build)

Apparently guix pull has problems on AArch64 right now though: https://issues.guix.gnu.org/issue/39352

It is possible to avoid guix pull by cloning the Guix repository, running guix environment guix, then ./bootstrap && ./configure --localstatedir=/var && make -j4, after which you can use ./pre-inst-env guix install ungoogled-chromium.

Sorry for the inconvenience! I will shut up until Guix works properly on ARM again...

pinebookfan commented 4 years ago

guix pull worked, after 12 h compiling. So now i wait for the chromium install...

pinebookfan commented 4 years ago

oh okay i managed to get guix on armhf to work. And i try this with chromium. So you say i should use the aarch64 version? with cloning guix repository?

I told you that only the original debian build runs smooth on the pinebook with the best support. I won't use another os. And i want widevine, it's only on this version.

pinebookfan commented 4 years ago

ungoogled-chromium-79.0.3945.130-0.e2fae99.tar.xz 307.6MiB 1.4MiB/s 03:38 [##################] 100.0%

building /gnu/store/xgv1aic6p3p5fa7sm13igw0a30zsxk3b-node-10.16.0.drv...

pinebookfan commented 4 years ago

i had no problem to grab the repository for aarch64, but the build process allways will fail.

mbakke commented 4 years ago

@pinebookfan Glad you got it to work eventually. Not sure why AArch64 fails, but I'll try to fix the armhf build of ungoogled-chromium in the coming days.

pinebookfan commented 4 years ago

Thx that would solve my problem :)

mbakke commented 4 years ago

@pinebookfan The Guix CI servers are still working on it, but I believe ungoogled-chromium should work on armhf as of commit c3435e2e60be3382863b3ae3061dff0ec8642151.

So you can do guix pull --commit=c3435e2e60be3382863b3ae3061dff0ec8642151 and afterwards run guix weather ungoogled-chromium. Once the latter reports an available substitute, run guix install ungoogled-chromium and browse away. :-)

You can also watch this page to check when it is done building on the CI: https://ci.guix.gnu.org/build/2307865/details

Eloston commented 4 years ago

Closing because a solution was found. Feel free to continue discussing.

mbakke commented 4 years ago

@pinebookfan Eh, the CI says the build failed, but it did succeed!

$ guix weather -s armhf-linux ungoogled-chromium
computing 1 package derivations for armhf-linux...
looking for 1 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 165.9 MiB of nars (compressed)
  280.6 MiB on disk (uncompressed)
  0.260 seconds per request (0.3 seconds in total)
  3.8 requests per second

Let me know if it works for you!

pinebookfan commented 4 years ago

guix pull works!

guix pull --commit=c3435e2e60be3382863b3ae3061dff0ec8642151 not working: building /gnu/store/q38367rhbdi7xp5l80s5zgq19w52angm-guix-packages.drv... 56% [######################################## ]builder for `/gnu/store/q38367rhbdi7xp5l80s5zgq19w52angm-guix-packages.drv' failed due to signal 11 (Segmentation fault) build of /gnu/store/q38367rhbdi7xp5l80s5zgq19w52angm-guix-packages.drv failed View build log at '/var/log/guix/drvs/q3/8367rhbdi7xp5l80s5zgq19w52angm-guix-packages.drv.bz2'.

mbakke commented 4 years ago

@pinebookfan Bah, we've had problems with guix pull on ARM since the recent switch to Guile 3.0. It will hopefully be fixed within a week or three.

The CI is currently building the latest version of ungoogled-chromium for ARM and should be finished in about 15 hours(!). Sorry for the troubles!

pinebookfan commented 4 years ago

I tried to build the new ungoogled- chromium again with guix, but my system reboots after a while. I think a deb file with armhf structure from someone would be better. For building with guix the pinebook pro specs are to low

pinebookfan commented 4 years ago

tell me if the latest version works :) and what i should do

pinebookfan commented 4 years ago

tell me if the latest version works :) and what i should do

mbakke commented 4 years ago

@pinebookfan I've fixed a build timeout in Guix so the builds should be more stable now. It takes almost a day on the CI. That means it may take 24 hours after ungoogled-chromium or any of its dependencies have been updated in Guix until a binary substitute is available.

Use guix weather after guix pull to check (you can omit -s armhf-linux when running natively):

$ guix weather -s armhf-linux ungoogled-chromium
computing 1 package derivations for armhf-linux...
looking for 1 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  100.0% substitutes available (1 out of 1)
  at least 167.1 MiB of nars (compressed)
  284.1 MiB on disk (uncompressed)
  0.197 seconds per request (0.2 seconds in total)
  5.1 requests per second
  'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
$ guix describe
Generation 26   Mar 05 2020 23:57:34    (current)
  guix 83ac7cb
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: 83ac7cb42b7157a4317c1219521f6eb0046a9ed6

So if guix pull works (the ARM bug is not fixed yet..), you should be able to get the binary substitute. Good luck!

mbakke commented 4 years ago

@pinebookfan were you able to install ungoogled-chromium on the Pinebook eventually? I'm curious if hardware acceleration works; I believe it should though.

travankor commented 4 years ago

@mbakke I'm not sure but doesn't guix use its internal copy of mesa and not the system mesa?

For example, I'm using guix on a system where the system mesa 20.0.4 uses the iris driver by default. However on chrome://gpu, it lists mesa 19.3.4, which defaults to i965 (which is what guix is on).

In this case, guix does not have an aarch64 mesa version with the panfrost driver.

(Aside: ironically enough, modern intel (intel might start but video acceleration is broken), amd, and nvidia all require proprietary firmware so they don't work on guixSD)

mbakke commented 4 years ago

@travankor Guix' Mesa does build iris driver support (see ls $(guix build mesa)/lib/dri). So if your host system uses the iris driver, I would assume Mesa does too? Do you have GPU acceleration at all? If not that sounds like a bug that can and should be fixed!

Regarding AArch64, you are correct that panfrost is unsupported at the moment. We have enabled it on the special "core-updates" branch, so you can guix pull --branch=core-updates if feeling experimental (warning: binary substitutes are unavailable for lots of things); it will land on "master" in a few weeks.

Indeed Guix System (the full distro, formerly known as GuixSD) is in a tough spot since all modern GPUs require proprietary firmare. It's fairly easy to add the required firmwares via a third-party channel however. But it should not matter when using Guix on top of another distro.

travankor commented 4 years ago

Just to clarify, GPU acceleration works fine for me. However, typing ldd ~/.guix-profile/lib/chromium | grep mesa reveals that libgbm.so.1 => /gnu/store/hash-mesa-19.3.4/lib/libgbm.so.1 is required. This implies that guix uses it's internal copy of mesa and not the system mesa at /usr/lib.

Hence, hardware acceleration is probably broken with aarch64 builds without a panfrost_dri.so.

We have enabled it on the special "core-updates" branch,

Also, what's the difference between staging and core-updates? It seems like cuirass tracks all branches, but master is the right one for a "rolling-release" experience? Are grafts basically backports from staging into master? And how do you mix and match branches -- say you want a kernel and u-boot from wip-pinebook-pro, mesa from core-updates, and everthing else from master? Would you manually graft those packages to master?

BTW, the new guile 3.0 has created a huge speedup in guix! I'm quite impressed 😁 (it's still considerably slower than a C-based package manager, but oh well, maybe guile will get a chez scheme backend one day)

mbakke commented 4 years ago

@travankor Guix uses its own copy of everything by design, even on foreign distributions. It should not cause a problem in practice except for maybe very old kernels (though CentOS 7 is supported). Mesa is currently slightly outdated because the focus has been on the "core-updates" branch.

The difference between "staging" and "core-updates" is described in the manual. It has to do with the functional nature of Guix: because updating Mesa forces a rebuild of the 1915 packages that (directly or indirectly) depends on Mesa, we can not do it on the "rolling" master branch as it would take too long for the CI to provide binary substitutes, so it goes through the "staging" branch instead. "core-updates" is for full-rebuild changes such as GCC or glibc.

I'm glad you asked about mixing branches: it is a first-class supported use case. In the Guix CLI you can use guix time-machine --branch=core-updates -- install ungoogled-chromium to install a single package from another branch or revision. If you are using manifests to manage your profile, you can use inferiors to pin packages to a specific Guix revision (see here for an example). Inferiors can of course also be used in the configuration system if you are using the full Guix System distribution.

travankor commented 4 years ago

Interesting, thanks a lot. I read sections of the manual that I thought were relevant to me, so I never looked at #Submitting-Patches.

One last question -- the massive amount of rebuilds is not done to fix ABI breakage but to document a reproducible state of the repository after every commit? Dynamically linked programs do not change binary-wise if a library is updated unless the ABI gets bumped.

And don't grafts sort of break the above model?

mbakke commented 4 years ago

@travankor Right, the amount of rebuilds is because of the functional design that ensures a "self healing" and reproducible package graph. ABI breakage is not a concern in Guix since every consumer of the ABI will necessarily get rebuilt -- even when the ABI does not change.

Grafts are a mechanism to deliver in-place updates without having to rebuild everything. We do care about ABI compatibility for grafted packages of course, but they are only used to deliver security updates as it is a somewhat expensive operation that runs on end-user machines.

Luckily grafts do not break the reproducibility or immutability of Guix. They are simply applied later, on top of the "pristine" (non-grafted) package graph, computing new derivations for everything that uses vulnerable packages. Those derivations take the "ungrafted" binary package as input, and replaces all references to vulnerable /gnu/store/<hash> items with their grafted replacements. You can always pass --no-grafts to any Guix command to get the unfettered (and likely vulnerable!) binaries.

Hope that made sense! Happy to answer more questions. :-)