11-21-2020, 06:47 AM
(This post was last modified: 11-23-2020, 03:53 AM by llsf.)
Yeah, signal-desktop won't work atm – the version running on the PBP runs with electron, and with most (all?) PinePhone distributions it will not run for lack of upstream electron Wayland support. Plus, it would be very slow.
I have added a (very, very, VERY!) experimental build of axolotl ( https://github.com/nanu-c/axolotl) though.
There are two versions available: axolotl-electron-git, which will not work on the PinePhone (see above), but seems to work fine on the PBP – main issue currently is that I couldn't get it to use the system electron, instead it seems to download its own version. Fortunately, that one seems to work.
Then there's axolotl-ut-git, based on the Ubuntu Touch releases. This will pull in many, many dependencies… but then to (mostly) launch fine. The way it's run is somewhat ugly, but well: it's an experiment ^^
Some of those dependencies might go away soon; seems there are upstream efforts to make it possible to run without depending on UT-only features that wouldn't be used on a PinePhone anyway.
For me, though, it then seems to crash (backend only, not the GUI) once sending a message – I couldn't test any further yet, though.
To make it very clear: The axolotl builds are very, very experimental. Using it with an existing Signal account might un-register your existing account (which would mean losing existing verifications, keys, messages etc.). Things might also just not work or any other terrible thing might happen.
So only use this if you know what you are doing and/or you are willing to lose any existing Signal related data!
One last thing: messages only, voice/video calls are not yet featured by axolotl.
--
@ pineitup : I haven't forgotten about you – I hope I'll get to work on your issues soon!
Is there any way to verify these packages are clean?
(03-24-2021, 04:26 PM)ImmyChan Wrote: Is there any way to verify these packages are clean?
That somewhat depends on what you mean by clean.
They're all signed with my key ( https://privacyshark.zero-credibility.ne...yshark.txt, A98C3D1364D8C16408143C2E2954CC8585E27A3F), so you can at least be sure that they're always put there by the same person.
You can either verify them by hand with gnupg, or have them verified by pacman automatically by adding that key to your pacman-keys and setting the appropriate SigLevel in your pacman.conf.
The build scripts / PKGBUILDs are all public at https://gitlab.com/ohfp/pinebookpro-things, https://gitlab.com/librewolf-community/browser/arch and https://gitlab.com/ohfp/caidao ; with librewolf and caidao even the build process jobs can be inspected as it's done with the gitlab CI at https://gitlab.com/ohfp/caidao/-/jobs and https://gitlab.com/librewolf-community/b...rch/-/jobs.
Other than that, there's no way to guarantee it. It might be possible to get it all done as reproducible builds, but if that was demanded, I'd recommend just taking the PKGBUILDs and building it directly in the first place – those can be inspected and you remain fully in control.
So basically: as clean as I can "promise", and if that's not sufficient, everything to build the packages yourself is provided – the repository is just offered as a "convenience" to make using packages with more complicated / lengthy build processes easier and to provide a few specific packages all in one place.
Sometimes packages even get upstreamed to the Manjaro repos (element/riot, bitwarden), which is the best possible outcome – but until then (one could probably ask over there for packages to be included, if desired), that's what I can offer 
Sorry for replying to a probably-dead chain already, but I'm having problems with node-gyp, any suggestions? Everything is up to date (I think) and I'm running a fresh copy of the install. Any help is appreciated.
I'm still here, no worries 
Yeah, that's more or less the reason why I'm currently not updating standardnotes-desktop/-git – that stupid node-sass dependency hates me and I haven't yet managed to find an at least somewhat not-insane workaround to stop it from just assuming it's on `x86_64` and throwing an `-m64` in there, which makes it all fail horribly. Env variables or global cflags/cxxflags don't seem to help as well.
I'm working on it, but honestly not with the highest priority because it's, well, one of those unnecessarily ugly issues that are no fun ^^
(05-09-2021, 09:29 AM)llsf Wrote: I'm still here, no worries
Yeah, that's more or less the reason why I'm currently not updating standardnotes-desktop/-git – that stupid node-sass dependency hates me and I haven't yet managed to find an at least somewhat not-insane workaround to stop it from just assuming it's on `x86_64` and throwing an `-m64` in there, which makes it all fail horribly. Env variables or global cflags/cxxflags don't seem to help as well.
I'm working on it, but honestly not with the highest priority because it's, well, one of those unnecessarily ugly issues that are no fun ^^ Ok, that makes sense! Thanks very much for the update.
(11-21-2020, 06:47 AM)llsf Wrote: and with most (all?) PinePhone distributions it will not run for lack of upstream electron Wayland support.
on Sailfish-OS (Wayland powered) there is WhisperFish (github) (openrepos) which runs on QML instead (though it's not feature complete yet).
That could be a starting point for a Wayland-friendly port to other PinePhone distros?
(05-18-2021, 05:00 PM)annahellrothsparent Wrote: (05-09-2021, 09:29 AM)llsf Wrote: I'm still here, no worries
Yeah, that's more or less the reason why I'm currently not updating standardnotes-desktop/-git – that stupid node-sass dependency hates me and I haven't yet managed to find an at least somewhat not-insane workaround to stop it from just assuming it's on `x86_64` and throwing an `-m64` in there, which makes it all fail horribly. Env variables or global cflags/cxxflags don't seem to help as well.
I'm working on it, but honestly not with the highest priority because it's, well, one of those unnecessarily ugly issues that are no fun ^^ Ok, that makes sense! Thanks very much for the update.
Just a quick note: I've tried (what it feels like) a thousand possible ways to get this to build, but still no luck.
For now, I do unfortunately have to give up on it – sorry about that!
I'll certainly try it again every now and then, but as of right now, I just have no idea what else to try. This seems to be even harder to build than signal ^^
Good news @ annahellrothsparent: standardnotes-desktop is back in the repo again, thanks to some extra motivation from https://github.com/standardnotes/forum/issues/1241 ^^
Just bought a pbp. Long time Arch user, not a fan of Manjaro, so looking to switch the OS. I made an SD following the instructions at https://github.com/SvenKiljan/archlinuxa...INSTALL.md
When I put the SD in my pbp and start it up, it boots into Manjaro. The SD shows up in Dolphin with BOOT_ALARM and ROOT_ALARM. I made another installation on another SD, same result.
The wrinkle I'm seeing is the file manager when I'm writing the SD card registers the card as mmcblk0 instead of sdX. I substituted the name in the instructions and followed them otherwise with apparent success. I'm using Gnome 40.4.0 on an Arch install.
Is the SD file naming scheme causing the boot loader to skip over it?
|
