Also does this mean in the future until the df ldp package is fixed that installing it on a new system requires you to sit and wait for the package webkit2gtk to build manually or is this just an issue with updating it?
Yeah so that didn’t work.. it just tried to do it again and installed all those junk packages…again
you need to remove the # in front of the line if not it will be ignored..
First of all.. you are using usercontent provided in the AUR by a user, nothing official supported by pacman or Archlinux itself.
If the AUR build really only works with old webkit 2.5 you will indeed need to use the one from AUR. Archlinux decided to not support that old version anymore.
this is a hacky workaround to get packages installed if they depend on webkit2gtk assuming they will work with the newer version installed with webkit2gtk-4.1 package.. it can work for you but i have no clue..
Oh i didn’t see it was commended
Alright that doesn’t really answer my question I’m aware that the ldp pack is not official. So i guess i am to assume that the next time i go to install it on something if the person hasn’t fixed the dependency by then that its either going to have to build it manually or try the hacky work around.
To layout the change that happened in a bit more detail, when a package is maintained in the official Arch repositories, it is pre-compiled for you, and what you download is a ready made binary.
You can access the PKGBUILD file for any package in the official repositories and install it yourself, but in most cases, that will mean your system now has to compile it. The compile step, is a service the official Arch repository provides, thankfully, as you can now see how long it takes to compile some packages, and the amount of dependencies necessary to do so.
When the webkit2gtk package was moved to the AUR, that compile step is removed. Pre-compiled binaries in the AUR are usually only available if the original developer provides them, and in the case of webkit2gtk, that doesn’t appear to be the case.
You should have caution around AUR packages that pull pre-compiled binaries from non-original sources. That’s akin to downloading random executables from an unfamiliar website and running it.
The responsibility in this case to resolve the webkit2gtk build issue somewhat falls to the maintainer of dwarffortress-linuxdwarfpack-appimage. I say somewhat because in the Arch ecosystem, it remains within your power to do something about it too. The webkit2gtk-is-webkit2gtk-4-1 package is perhaps an example of someone doing just that.
Yeah sadly this isn’t my first rodeo with things trying to compile it happened the first time i installed librewolf. I just know that the person who maintains the df ldp pack is going to be slow on fixing it just due to the fact that it runs on the old 47_05 version of the game. In version 50 the dev changed the entire way the game displays graphics removed keyboard controls and the text based terminal option from the game. I believe this is why the ldp pack hasn’t been updated since 2021 because it would be pretty much impossible to update it without breaking everything and a lot of the old players of the game have stuck to 47_05 because of the previously mentioned “upgrades” tarn made to the game myself included. Thankfully i was able to update my system and it ignored the package i was just curious of what to do in the future when it comes to a fresh install if the person hasn’t fixed the dependency by then.(hopefully they do)
Ok so what the webkit2gtk-is-webkit2gtk-4-1 package does, is basically wrap the official Arch webkit2gtk-4.1 package, and call it “webkit2gtk”.
That’s one way of solving the dwarffortress-linuxdwarfpack-appimage issue.
The other, is directly editing the dwarffortress-linuxdwarfpack-appimage PKGBUILD file yourself and changing the dependency from webkit2gtk, to webkit2gtk-4.1.
Both approaches are ultimately depending on the official webkit2gtk-4.1 package. It may not work, but it’s worth a shot.
This will download the dwarffortress-linuxdwarfpack-appimage package, enter that directory and modify its dependency from webkit2gtk to webkit2gtk-4.1:
yay -G dwarffortress-linuxdwarfpack-appimage
cd dwarffortress-linuxdwarfpack-appimage
sed -i "s/webkit2gtk/webkit2gtk-4.1/" PKGBUILD
Now try building and installing that:
makepkg -fsri
If that works, this is a classic example of how with Arch, you’re in control, and why I love this ecosystem.
Also while i have you guys here i wanted to ask a few quick questions about my i3 setup. So for some reason i would say about 30% of the time i login my compositor(picom) just doesnt show up to the party at all and i end up having to restart the system for it to work and i was curious why it does that and is that a common thing because on any other system i have running picom it does not do that. I’m just using the stock file and uncommended the lines in the i3 config so it’s not like i have messed with it or anything. The other thing i am curious about is why am i constantly being harassed about my wifi password. I’m currently hard wired but i do have a 2.4ghz adapter plugged in in case my cat5 line falls out of the computer i did some reading online and people said to go into advanced network config and set the band to 2.4ghz manually so i did that but at least once or twice a day it still probes me for wifi password. At this point i just hit cancel so it goes away since entering the password seems to do nothing and it just asks again later.
I’ll definitely have to try using the webkit2gtk-is-webkit2gtk-4-1 work around first if not i can try to change the dependency manually if the maintainer hasn’t done so by then. If that’s the case i may end up just doing my own version and maintaining it myself if the other person is that far behind or just ignoring the problem. For now i think I’m just going to stick with leaving webkit2gtk as an ignored package but i do have to fix another system that broke recently so that’s why i asked because i can see this being a problem in the future. I feel like whoever decided the webkit2gtk package needed to be moved didn’t really think about how this may affect the people currently using it. Call me crazy but i think there should have been some sort of warning or something obvious that this was going to cause problems maybe that would have saved me a couple hours of my day because had i known i would have just set the package to ignore right away and just went about my day instead i spent 5 hours messing with something i really should not have had to.
I’m not familiar with i3, so I can’t speak to whether it’s normal or not. But when this happens and you’ve had to restart to fix it, you might then run this to fetch the boot-log of that previous failing session. Hopefully this will provide some clues:
journalctl -b -1 | eos-sendlog
The -b -1 there instructs it to grab the previous session’s boot log. So it’s important that you only run this if you’ve restarted after just encountering that issue.
As for the WiFi issue, the way I’d personally resolve that is disabling WiFi while not needing it. I’m not sure if i3 has a flight-mode feature, or the ability to toggle WiFi. If not, the command for it is:
rfkill block wlan
Later, if you need to enable WiFi again:
rfkill unblock wlan
Yeah it’s strange i just experienced it and had to restart https://dpaste.com/F3JBT54BD. When it does do this i can launch it manually and it works but as soon as i close the terminal i used to launch it it’s gone again.
As far as the wifi issue I’ve went into nmtui and told it to disable that connection but it just keeps auto activating it randomly idk why I think my best assumption for the issue is that it’s a cheap usb wifi adapter from amazon but idk I’ve used it on other systems and never had an issue before like this but i guess if it persists i can just unplug it. I’m also sure that the rather ancient router downstairs is at least part of my woes when it comes to wireless internet but I’m not super pressed about it soon i will live elsewhere and if i have issues then i can dive into it.
Hah, yes of course that’s much simpler than messing with rfkill block wlan 
With respect to picom, the log certainly indicates it had issues:
Apr 26 17:29:23 Alder-lake systemd-coredump[1757]: Process 1480 (picom) of user 1000 terminated abnormally with signal 6/ABRT, processing...
Apr 26 17:29:23 Alder-lake systemd[1]: Created slice Slice /system/systemd-coredump.
Apr 26 17:29:23 Alder-lake systemd[1]: Started Process Core Dump (PID 1757/UID 0).
Apr 26 17:29:23 Alder-lake systemd-coredump[1758]: Process 1480 (picom) of user 1000 dumped core.
Stack trace of thread 1480:
#0 0x00007fef57a98a2c n/a (libc.so.6 + 0x98a2c)
#1 0x00007fef57a3e1a0 raise (libc.so.6 + 0x3e1a0)
#2 0x00007fef57a255fe abort (libc.so.6 + 0x255fe)
#3 0x0000560c1b2cf2ad n/a (/usr/bin/picom + 0xb2ad)
#4 0x0000560c1b302696 n/a (/usr/bin/picom + 0x3e696)
#5 0x0000560c1b2fe171 n/a (/usr/bin/picom + 0x3a171)
#6 0x0000560c1b2f3212 n/a (/usr/bin/picom + 0x2f212)
#7 0x00007fef5817e51b ev_invoke_pending (libev.so.4 + 0x551b)
#8 0x00007fef58182002 ev_run (libev.so.4 + 0x9002)
#9 0x0000560c1b2d0e96 n/a (/usr/bin/picom + 0xce96)
#10 0x00007fef57a276c1 n/a (libc.so.6 + 0x276c1)
#11 0x00007fef57a277f9 __libc_start_main (libc.so.6 + 0x277f9)
#12 0x0000560c1b2d2d95 _start (/usr/bin/picom + 0xed95)
ELF object binary architecture: AMD x86-64
Hmm that is strange i wonder why it did that. Just quickly searching google says that usually happens due to graphics driver conflict or improper config. Well as far as i know my graphics drivers are fine I have and AMD card and as far as i know drivers just come with kernal updates. If the config is improper that would be on whoever writes it for endeavour because I’ve never even opened it.
You could try refreshing the config, in case there’s something in there causing the issue.
Can you share the output of this please? Just trying to locate where your picom config might reside:
ls /etc/xdg/picom.conf ~/.config/picom/picom.conf ~/.config/picom.conf
No such file or directory.
Curious. Based on the Wiki they’re the locations where it’s supposed to reside 
Can you run this please:
find ~/ -name "picom.conf"
If i look in /etc/xdg picom.conf is there but no such directory exists in my .config because I’m not running a custom file. In the i3 config it says to uncomment a line if i am running a custom one but i never did because i never felt the need to mess with it the default is good enough for me.
I think you should probably create a new topic with this issue. You can share the boot log and even the specific error noted in that log, in the new topic.
I’m just poking around in the dark when it comes to i3 specifics, and so far, making little progress. Hopefully someone with more i3 experience could lend a hand in a topic dedicated to the issue.