Manjaro and Arch repository with privacy oriented software
#71
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!
  Reply
#72
Is there any way to verify these packages are clean?
  Reply
#73
(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-thingshttps://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 Smile
  Reply
#74
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.     
  Reply
#75
I'm still here, no worries Wink

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 ^^
  Reply
#76
(05-09-2021, 09:29 AM)llsf Wrote: I'm still here, no worries Wink

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.
  Reply
#77
(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?
  Reply
#78
(05-18-2021, 05:00 PM)annahellrothsparent Wrote:
(05-09-2021, 09:29 AM)llsf Wrote: I'm still here, no worries Wink

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 ^^
  Reply
#79
Good news @annahellrothsparent: standardnotes-desktop is back in the repo again, thanks to some extra motivation from https://github.com/standardnotes/forum/issues/1241 ^^
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Working suspend on Manjaro brzegorz 1 51 Yesterday, 02:43 PM
Last Post: wdt
  Manjaro [ARM Stable Update] 2021-07-23 issues Bocanila 0 95 07-24-2021, 09:09 AM
Last Post: Bocanila
  Sound stuttering on Manjaro gnome after latest kernel upgrade? pjsf 0 125 07-13-2021, 10:37 PM
Last Post: pjsf
  Arch Linux ARM root filesystem SKiljan 13 1,176 07-09-2021, 01:24 PM
Last Post: dukla2000
  Kernel crash on Manjaro ARM mfashby 0 134 07-06-2021, 03:17 PM
Last Post: mfashby
  Manjaro wont recognize eMMC after booting with it disabled peasant 1 233 06-27-2021, 02:39 AM
Last Post: Arwen
  Pinebook pro nearly unusable after using manjaro-arm-installer TheCounselor 0 277 06-18-2021, 03:34 PM
Last Post: TheCounselor
  Pinebook Pro Manjaro Power Savinng Tips HelpMyBatteryIsDraining 1 389 06-15-2021, 08:42 AM
Last Post: moonwalkers
  [LibreOffice & Gimp] ARM support: no hardware acceleration on [Manjaro] Pinebook Pro regivanx 0 256 06-15-2021, 04:04 AM
Last Post: regivanx
Question Building custom kernel (5.11.x) for Manjaro? ppafin 4 859 06-02-2021, 04:17 AM
Last Post: ppafin

Forum Jump:


Users browsing this thread: 2 Guest(s)