In the guest I have a shared folder, fstab: Installed package: virtualbox-guest-modules-arch 5.2.10-3 Is this actually meant to be : diff -ru -color old/PKGBUILD new/PKGBUILD Most likely there's a mistake in lines #54f, where the symlinks which were just installed in lines #52f get overwritten. Hey a lot for packaging this for the AUR and maintaining. So it didn't fully remove the installed stuff? $ yay -Rns ventoy-binĪnyone know what's wrong and how I should fix this? I reaaaaaaly prefer not to just "rm -rf /opt/ventoy" - but that might be the solution I'll use, if nobody can/will explain a better solution/method?
Ventoy-bin: /opt/ventoy/tool/vtoyfat_64 exists in filesystemĮrrors occurred, no packages were upgraded. Ventoy-bin: /opt/ventoy/tool/vtoyfat_32 exists in filesystem Ventoy-bin: /opt/ventoy/tool/vtoy_gen_uuid exists in filesystem Ventoy-bin: /opt/ventoy/tool/mount.exfat-fuse_64 exists in filesystem Ventoy-bin: /opt/ventoy/tool/mount.exfat-fuse_32 exists in filesystem Ventoy-bin: /opt/ventoy/tool/mkexfatfs_64 exists in filesystem Ventoy-bin: /opt/ventoy/tool/mkexfatfs_32 exists in filesystem Ventoy-bin: /opt/ventoy/tool/hexdump exists in filesystem Ventoy-bin: /opt/ventoy/tool/VentoyWorker.sh exists in filesystem Ventoy-bin: /opt/ventoy/tool/ENROLL_THIS_KEY_IN_MOKMANAGER.cer exists in filesystem (1/1) checking for file conflicts 100%Įrror: failed to commit transaction (conflicting files)
ARCH LINUX ISO FILE INVALID UPGRADE
There's something wrong here, I couldn't upgrade ventoy-bin, so I uninstalled - then tried to re-install: (1/1) loading package files 100% Also and/or do you have any strong opinions about this ? Would it make more sense to just remove the color codes ? In case that I'm getting something completely wrong please let me know. Building would still work after a change. This is not the case when a variable is queried though.
That doesn't offend the recommendation in the packaging etiquette though, in my opinion, since it's not a subroutine.Īs I understand that wiki clause, internal makepkg functions should not be used because the build script could break when those functions are changed at some point. You're correct in that USE_COLOR is a variable defined by makepkg itself. The only (sensible) way to check if that flag is set or not, that I could come up with, is querying a variable that depends on it. I figured it would make much more sense anyways, to let the user switch off color explicitely via the -m/ -nocolor flag which you mentioned. It wouldn't prevent colored lines in the log, because makepkg redirects the data stream to the log file outside of the PKGBUILD's functions, and thus after that condition would be tested. The first idea I had earlier (to check if output goes to a tty or not), was a bit too quick.
0 kommentar(er)
