New package: flipper #210
New package: flipper #210
Conversation
|
It turns out that, at least on ppc64, if you have |
…, several fixes and improvements
|
There was a sneaky preinstall script which was hiding an otherwise disabled watchman config. Unfortunately that wasn't enough, so I started looking for watchman references all over the code and got rid of them. Still not enough, apparently in a purely node-ish fashion some deep deep dependency was still starting the damn thing, so I decided to take care of the problem at the root and I've crafted a very elaborate patch. Done. Adios :) |
|
I've added the electron wrapper as well. @PF4Public please let me know how to generate the |
|
In case that will get merged we will be able to drop |
…n everywhere, turns out flipper needs it at runtime
|
Turns out if you use nukes to kill mosquitoes it can backfire: flipper could potentially make use of watchman at runtime and the previous patch prevented that. So instead of nuking it altogether I spent a couple more hours debugging it and I ended up disabling it in the metro bundler. |
|
Sorry, couldn't reply earlier. Wow, that's a lot! I suppose, you've solved the watchman issue, but here are some things for consideration It looks for And here it calls a system watchman: Maybe
This could be expanded to other arches instead of downloading third-party binaries. What worries me is that it pulls in go. That's a huge dependency. So if you add dependency on app-builder, you'd better keep the old "hacky" way and make them if/else cases in element based on say
Here is the bash excerpt that I've cut from my script with mostly all the unrelated things removed. Might not work on the first try: at least you need to add additional place for searching for tmp_dir=$(mktemp -d)
# echo $tmp_dir
# tmp_dir="/tmp/tmp.jeKig0qsTv"
pushd "$tmp_dir" >/dev/null
wget $url
unzip -q *.zip
pushd */ >/dev/null
if [ -d "extensions" ]; then
mapfile -t locks < <(find extensions build -name yarn.lock 2>/dev/null)
fi
if [ -d "node_modules" ]; then
mapfile -t locks < <(find node_modules -name yarn.lock 2>/dev/null)
fi
locks+=('yarn.lock')
urls=()
echo "Locks: ${locks[@]}"
for i in "${locks[@]}"; do
mapfile -t urls_temp < <(grep resolved $i | sed -e 's/.*\"\(https[^#"]\+\).*/\1/')
urls+=("${urls_temp[@]}")
done
declare -A b
for i in "${urls[@]}"; do b["$i"]=1; done
cat /dev/null >/tmp/out_deps
for i in "${!b[@]}"; do
if [[ $i =~ ^.*(@[^/]+)/.*/([^/]+)$ ]]; then
out="$i -> ${BASH_REMATCH[1]}-${BASH_REMATCH[2]}"
else
out=$i
fi
echo -e "\t$out" >>/tmp/out_deps
done
sort -o /tmp/out_deps /tmp/out_deps
popd >/dev/null
popd >/dev/null
rm -rf $tmp_dir
I've rewritten that in Perl for the bot since then, but I suppose Bash is what you're after. |
Oh that might indeed be the issue: I completely forgot I have configured portage to use an ultra low priority and that could be why it fails (in fact I've tried to disable the sandbox and it keeps failing). Unfortunately a high niceness is a perfectly sane value for portage so we can't just assume that users won't run it at low prio.
That's basically what my first patch was doing, but the same library gets bundled into the app.asar and that would prevent Flipper from being able to use it (which is exactly what it's doing if watchman is installed). The solution I ended up with is the best of both worlds because it surgically disables watchman just for the metro bundling.
Of course we can do the same for whatever arch we want (but would be pointless unless electron builds on that arch). I personally don't like the fact that npm handles binaries and I would rather prefer to have binary packages handled by portage (I don't like using binaries at all in Gentoo, but that's personal preference). The main disadvantage of the "hacky" way (and the main reason why I wanted to part with it) is that it requires additional efforts to figure out how to package each and every application instead of simply leveraging the existing build system. Instead of doing so it would probably be better to additionally provide an |
|
Nice work - just gave this a try and it seems to work fine on ppc64le with It looks like As for getting |
I already did so and it works well, but I've decided to leave it out because we won't compress/decompress anything in this ebuild yet. |
I meant exactly this. Expand
My idea was that this setting could be adjusted somehow to use system watchman if available. |
|
By the way, @darkbasic Have you tried |
|
I'm pretty sure I did, but I will double check. |
I've taken inspiration from the
element-desktopebuild, but instead of going for the hacky way I decided I wanted to seamlessly build for ppc64 like if it was a supported architecture. So I've created anapp-builderebuild because no ppc64 binary is being bundled with the npm package and I also created some patches to bake ppc64 support intobuilder-util. I've also had to patch flipper itself because the build scripts were broken and we were unlucky enough to expose the bug. Note that we can't use electron's node because node 18 is mandatory, otherwise it will fail to generate theapp.asar.Use the online build (default) for the moment because I have no idea how to generate the
SRC_URIfor offline usage.Running the same exact commands in a normal shell results in a perfectly working flipper, but doing so using the ebuild results in the following error:
Could you give it a try on your system? Do you have any idea what's going on? Surely some sandbox sh*t with watchman but I'm really too tired to further look into it now.
If we can manage to get the ebuild working I will backport the new ppc64 build method into the
element-desktopebuild and I will add the electron wrapper to both as well.