Request: xdo xdotool - Githubissues

Samueru-sama commented 2 weeks ago

mawk: It was a simple as running ./configure and make CC="gcc -static".
iotop-c: https://gist.github.com/Saoneth/02f08d4714e6fc035e7017c74b3ef29a I tried to build it but now the build is failing with libncursesw errors and trying it on alpine I get fatal error: bytecode stream in file 'bld/arr.o' generated with LTO version 14.0 instead of the expected 13.1 Welp, looks like that one iotop-c static binary that I have will be the one for a while lol.
xdo: Couldn't build it statically either, I get warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
xdotool: make static was all it took. The produced binary is named xdotool.static however running ldd shows that it really isn't a fully static binary.

Origin: https://github.com/xplshn/dbin/issues/7

Azathothas commented 2 weeks ago

Hopefully this isn't a critical request, as I am currently at a remote place with access to only my phone. I do intend to get back to my workstation in about a week, expect a resolution no sooner than then.

I believe iotop and xdo could be built using nix, but if they don't, I might have to add a help needed label and wait until someone provides a working build script.

xplshn commented 2 weeks ago

shows that it really isn't a fully static binary.

Have you tried using a Musl toolchain? Glibc does not support static linking at all.

Samueru-sama commented 2 weeks ago

shows that it really isn't a fully static binary.

Have you tried using a Musl toolchain? Glibc does not support static linking at all.

Tried on alpine and the produced binary isn't fully static.

Azathothas commented 2 weeks ago

I have added mawk & iotop-c

xdo & xdo-tool both depend a lot on x11/xcb libraries and even on alpine, there's no static versions of these libs. Compiling the usual way & both using nix-build failed with linking error. So I don't think a true static binary for them is possible. I am happy to be proven wrong.

If you are willing to accept a ~fake~ static binary made using staticx, that would be easy. I am attaching binaries built using staticx, test them and let me know if they work. If they do, I will push the build script & binaries to the repo.

https://pub.ajam.dev/temp/xdo https://pub.ajam.dev/temp/xdotool

Samueru-sama commented 2 weeks ago

Thanks, I see xdo works! but xdotool is partially broken, for some reason the option getwindowclassname no longer works:

/tmp/samuel/staticx-HnmgEA/xdotool: Unknown command: getwindowclassname

Btw, I'm sorry I didn't make this clear before, for iotop-c the name of the binary is iotop, I call it iotop-c to not be confused with the original iotop which iirc was written in python.

btw cool thing staticx, never heard of it before.

Azathothas commented 2 weeks ago

Partial broken is expected, staticx is not 100% perfect. If the binary works even 50% of its original functionalities, I see no reason not to add it. Unless, a better/complete/true static binary is available.

I am building iotop using nix-build, which has a separate iotop which uses http://guichaz.free.fr/iotop/. And it has iotop-c which uses https://github.com/Tomas-M/iotop as in your original request. I had like to stay with the official naming scheme, as it avoids confusion. I hope it's not too much of a compromise. The description should read: A top utility for IO so hopefully that tells you that it's indeed the one you are looking for.

Samueru-sama commented 2 weeks ago

Partial broken is expected, staticx is not 100% perfect. If the binary works even 50% of its original functionalities, I see no reason not to add it. Unless, a better/complete/true static binary is available.

But getwindowclass is like the most commonly used part of xdotool, that's like having fastfetch not print the distro logo so I don't think that's a good idea.

I am building iotop using nix-build, which has a separate iotop which uses http://guichaz.free.fr/iotop/. And it has iotop-c which uses https://github.com/Tomas-M/iotop as in your original request. I had like to stay with the official naming scheme, as it avoids confusion. I hope it's not too much of a compromise. The description should read: A top utility for IO so hopefully that tells you that it's indeed the one you are looking for.

Yes that's the original iotop which is a python application, on arch if you install iotop-c the binary name will be iotop, same if you clone and make the iotop-c repo, the resulting binary is named iotop.

I see no problem or confusion in using iotop for the name of the binary, unless toolpacks includes python applications?

Azathothas commented 2 weeks ago

I have duplicated iotop-c to iotop , so both are now valid and also avoids confusion. https://github.com/Azathothas/Toolpacks/commit/f908515d4ad1461fa80f322e872e4c81f8413bad

As for xdo & xdo-tool, I have now added the help-wanted label and will keep this issue open until a true/completely working binary is possible. Until then, the repo will contain the staticx versions.

Samueru-sama commented 2 weeks ago

Thanks for all this @Azathothas

I think for xdotool I will have to end up making an appimage lol

xplshn commented 2 weeks ago

Thanks for all this @Azathothas

I think for xdotool I will have to end up making an appimage lol

@Azathothas Will self-contained/static appimages be added to the repo, just like there are some programs suffixed with -staticx?

Azathothas commented 2 weeks ago

I believe https://github.com/Azathothas/Toolpacks/issues/28 already addresses this, so please keep the current issue related to the topic. We can continue discussion at: https://github.com/Azathothas/Toolpacks/issues/28

To give a brief answer, I would like to test these self contained/static appimages/pelfs/bundles you keep mentioning. Preferably, I would like a step by step instructions (including setting up the build environment, installing dependencies, assume I don't know anything other than basic unix) on how to create these. As an example, if you provide me a step by step instruction on the other issue or via GitHub gist, on a static/self contained mpv (or another widely used Linux app, but please no games), along with a binary I can test, then sure I will take a look. But to dive into this from scratch on my own seems like a bit too much in terms of time and commitment.

Once again, please reply at https://github.com/Azathothas/Toolpacks/issues/28 or somewhere else if it doesn't relate to xdo/xdotool

Samueru-sama commented 2 weeks ago

I've made an xdotool appimage using deploy everything mode of go-appimage and it works, or at least xdotool getactivewindow getwindowclassname isn't broken like with statix.

The resulting AppImage is 2.4 MiB in alpine linux while it is 5.4 MiB on ubuntu.

This test is using the alpine built appimage:

#!/bin/sh

export ARCH=x86_64
export APPIMAGE_EXTRACT_AND_RUN=1
REPO="https://github.com/jordansissel/xdotool.git"
GOAPPIMAGETOOL=$(wget -q https://api.github.com/repos/probonopd/go-appimage/releases -O - \
    | sed 's/[()",{} ]/\n/g' | grep -oi 'https.*continuous.*tool.*x86_64.*mage$' | head -1)
mkdir -p ./xdotool/xdotool.AppDir && cd ./xdotool/xdotool.AppDir || exit 1

# Build xdotool
if [ ! -d ./usr ]; then
    CURRENTDIR="$(readlink -f "$(dirname "$0")")"
    git clone "$REPO" && cd ./xdotool && make static && PREFIX="$CURRENTDIR/usr" make install
    cd .. && rm -rf ./xdotool
    mkdir -p ./usr/share/applications
    touch xdotool.png && ln -s ./xdotool.png ./.DirIcon
    cat <<- EOF > ./xdotool.desktop
    [Desktop Entry]
    Type=Application
    Name=xdotool
    Comment=x11 automation tool
    Icon=xdotool
    Exec=xdotool
    Terminal=true
    Categories=System;ConsoleOnly;
    Keywords=system;task
    EOF
    cp ./xdotool.desktop ./usr/share/applications/
fi

# make appimage
export VERSION=$(./usr/bin/xdotool --version 2>/dev/null | awk 'FNR==1 {print $3}')
[ -z "$VERSION" ] && echo "ERROR: Could not get version from xdotool" && exit 1
cd .. 
[ ! -f ./go-appimagetool ] &&  { wget -q "$GOAPPIMAGETOOL" -O ./go-appimagetool || exit 1; }
chmod +x ./*tool*
./go-appimagetool -s deploy ./xdotool.AppDir/usr/share/applications/*.desktop || exit 1
sed -i 's/export PYTHONHOME/#export PYTHONHOME/g' ./xdotool.AppDir/AppRun
./go-appimagetool -s ./xdotool.AppDir || exit 1
mv ./*.AppImage* .. && cd .. && rm -rf ./xdotool || exit 1
echo "All done!"

I will likely host the appimage on its own repo, but I will likely use the ubuntu runners since I don't know how to add an alpine runner @xplshn so it will 5.4 MiB of bloat

Azathothas commented 2 weeks ago

@Samueru-sama could you attach the binaries (after zipping) here, for both alpine/ubuntu? I would like to test them.

Samueru-sama commented 2 weeks ago

@Samueru-sama could you attach the binaries (after zipping) here, for both alpine/ubuntu? I would like to test them.

Just in case, the appimage made on any distro works on all other distros since it bundles everything, but I went ahead and still included the same appimage made in both ubuntu and alpine.

Ideally alpine is what should be used since it produces a smaller appimage.

appimages.zip

Azathothas commented 1 week ago

Seems like I will need to provision a regular linux distro with all the bells and whistles (WM, DE, Display etc) to test pkgs that depend on x11/wayland/window. Also for https://github.com/Azathothas/Toolpacks/issues/28

As the appimages you provided gave me the same errors as the staticx version.

Samueru-sama commented 1 week ago

As the appimages you provided gave me the same errors as the staticx version.

What errors do you get? I am able to get the appimage to print the window class name (and I've been using it in all my i3 scripts so far without issues) while the staticx binary can't do so.

xplshn commented 1 week ago

Seems like I will need to provision a regular linux distro with all the bells and whistles (WM, DE, Display etc) to test pkgs that depend on x11/wayland/window. Also for #28

As the appimages you provided gave me the same errors as the staticx version.

You could set up one with Alpine, then use setup-desktop to get XFCE, and then set up distrobox within it to use Fedora, Debian, Devuan, and others such as Void, within it.

leleliu008 commented 1 week ago

https://github.com/leleliu008/ppkg or https://github.com/leleliu008/ppkg-package-manually-build/actions

can generate fully statically linked executables for you

examples: https://github.com/fpliu1214/ppkg-package-manually-build/actions/runs/10725714561 https://github.com/fpliu1214/ppkg-package-manually-build/actions/runs/10725709911 https://github.com/fpliu1214/ppkg-package-manually-build/actions/runs/10725700980 https://github.com/fpliu1214/ppkg-package-manually-build/actions/runs/10723131687

Azathothas commented 1 week ago

Hi, @leleliu008 , nice to see you here.

I had actually checked the formulas for this but couldn't find, seems like they were added in the last few hrs. Thank you.

I will take a look at this tomorrow, for my ref: https://github.com/leleliu008/ppkg-formula-repository-official-core/blob/master/formula/xdo.yml https://github.com/leleliu008/ppkg-formula-repository-official-core/blob/master/formula/xdotool.yml

leleliu008 commented 1 week ago

@Azathothas Yes, these formula files are in https://github.com/leleliu008/ppkg-formula-repository-official-core I added these a few hours ago.

Azathothas commented 1 week ago

@Samueru-sama could you check the artifacts linked by @leleliu008 if they work as expected. xdo: https://pub.ajam.dev/temp/xdo xdo-tool: https://pub.ajam.dev/temp/xdotool

They are indeed static

🌀 ❯ file xdo xdotool
xdo:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=239e1db670ab513c87f8b38b103e2df16a43acd6, stripped
xdotool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aed3c9f1385637872e0e481a3059d1840c99c822, stripped

$ sha256sum *
72ba80641016b8bd9d99ede40e41337b2b0c5710e17bceca141923576721665e  xdo
695a009d5d31999ad49f48858e1274a8efd67a6eb7e67a204976952c2f4e9856  xdotool

If they work, I will go ahead and use ppkg to build these from now on.

Samueru-sama commented 1 week ago

@Samueru-sama could you check the artifacts linked by @leleliu008 if they work as expected. xdo: https://pub.ajam.dev/temp/xdo xdo-tool: https://pub.ajam.dev/temp/xdotool

They are indeed static
🌀 ❯ file xdo xdotool
xdo:     ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=239e1db670ab513c87f8b38b103e2df16a43acd6, stripped
xdotool: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=aed3c9f1385637872e0e481a3059d1840c99c822, stripped

$ sha256sum *
72ba80641016b8bd9d99ede40e41337b2b0c5710e17bceca141923576721665e  xdo
695a009d5d31999ad49f48858e1274a8efd67a6eb7e67a204976952c2f4e9856  xdotool
If they work, I will go ahead and use ppkg to build these from now on.

They work. I also had already tested the static binaries when @leleliu008 linked them and they worked as well, sorry I didn't mention that.

Thanks a lot @leleliu008 you saved me from making a very bloated xdotool lol

Azathothas commented 1 week ago

Thanks to @leleliu008 this is now resolved. https://github.com/Azathothas/Toolpacks/commit/652174ca91370a8a6e792705af4d9530af937444 The binaries will show up next time the build commences.

Azathothas / Toolpacks

Request: xdo xdotool #29