Weird behaviour on Arch Linux 32: Asking for overwriting files with no changes #159
Comments
|
Can you post the part of your configuration responsible for creating I think there might be a quirk where if you specify the default mode ( |
|
Sure, though this does not affect Arch64, and I don't specify the mode for most of the affected files. I have a system with "feature-variables" that are either auto detected or from a case statement on the hostname. All of these are done in IGNORED_PKGS=()
case $HOSTNAME in
minerva)
# New version breaks pyswip bindings, temporary workaround until upstream fixes this.
IGNORED_PKGS+=(swi-prolog)
;;
*)
;;
esac
f="$(GetPackageOriginalFile pacman /etc/pacman.conf)"
sed -i \
-e '/^#Color/s/^#//' \
-e '/^#ParallelDownloads/s/^#//' \
"$f"
if (( ${#IGNORED_PKGS[@]} > 0 )); then
oIFS="$IFS"
IFS=$' \t\n'
sed -i \
-e '/^#IgnorePkg/s/^#//' \
-e "s/IgnorePkg *=/IgnorePkg = ${IGNORED_PKGS[*]}/" \
"$f"
IFS="$oIFS"
fi
if [[ $CUST_USE_MULTILIB == 1 ]]; then
sed -i \
-e '/\[multilib\]/ { s/^#// ; n ; s/^#// }' \
"$f"
fi
# Helper to add a file based repo to pacman.conf
# $1 Repo name
_add_repo() {
local repo="$1"
cat >> "$f" <<-EOF
[${repo}]
SigLevel = Optional TrustAll
Server = file:///home/custompkgs/${repo}
EOF
CreateLink /etc/aurutils/pacman-${repo}.conf pacman-${CUST_PLATFORM}.conf
}
if [[ $CUST_PLATFORM == i686 ]]; then
_add_repo custom-32
fi
if [[ $CUST_TASK_GAMES -gt 1 ]]; then
_add_repo custom-games
fi
if [[ $HOSTNAME == athena ]]; then
_add_repo custom-t480
fi
if [[ $HOSTNAME == dragon ]]; then
_add_repo custom-r500
fi
if [[ $CUST_CPU == amd ]]; then
_add_repo custom-zen
fi
# HACK: Arch32 hack to disable this repo, need to find a better way
if [[ $CUST_LAPTOP == 1 && $CUST_PLATFORM == x86_64 ]]; then
_add_repo custom-laptop
fi
if [[ $CUST_IS_WORK == 1 ]]; then
_add_repo custom-work
elif [[ $CUST_PLATFORM == x86_64 ]]; then
# HACK: Another Arch32 hack to disable this repo, fix this too
_add_repo custom-personal
fi
if [[ $CUST_TASK_ARCHIVING == 1 || $CUST_TASK_EMULATION == 1 ]]; then
_add_repo custom-archiving
fi
if [[ $CUST_TASK_3D_SCAN == 1 || $CUST_TASK_CAD == 1 || $CUST_TASK_CAM == 1 ]]; then
_add_repo custom-cadcam
fi
if [[ $CUST_TASK_VIDEO_EDITING == 1 ]]; then
_add_repo custom-videoediting
fi
if [[ $CUST_TASK_OFFICE == 1 ]]; then
_add_repo custom-office
fi
_add_repo custom-compat
if [[ $CUST_PLATFORM == x86_64 ]]; then
# HACK: Arch32 strikes again
_add_repo custom
fi |
|
Thanks! I wanted to see this line:
So it's not the problem I was thinking about in my last post.
Nice, you are doing it right 🙂👍
This seems to indicate that aconfmgr is not seeing the files being modified on the filesystem. Try running the command If the output looks good, it's possible that there's a problem with the loop aconfmgr uses to read the paccheck output, which is a little non-trivial because aconfmgr wants to show the progress. |
$ paccheck --md5sum --files --file-properties --backup --noupgrade pacman
zsh: segmentation fault (core dumped) paccheck --md5sum --files --file-properties --backup --noupgrade pacmanWell! That explains it, though it is unexpected. Checking with gdb it crashes somewhere in |
|
Arch32 bug report: https://bugs.archlinux32.org/index.php?do=details&task_id=317&string=pacutils |
|
Aah, that's unfortunate. Is it this bug? andrewgregory/pacutils#50 |
|
Hm! That seems very similar indeed. Probably the same yes, since andrewgregory/pacutils#51 also adds |
|
I would be curious how other packages which depend / depended on pacutils deal with upstream abandonment, such as aurutils. Perhaps a community-maintained fork is in order? Perhaps one already exists? |
|
Good question! pacutils does seem to work for now on 64-bit though, so perhaps few people have noticed yet? Not that many use 32-bit any more (and I only set that up because I needed something with an actual serial port, USB->serial wasn't good enough, and a 32-bit laptop was the only such thing I had). |
|
Arch32 has a downstream fix now. I don't know about Arch Linux on ARM, though that may be 64-bit only? Feel free to close the bug here though. |
General description of the problem:
On ArchLinux32 aconfmgr will ask about overwriting and installing unchanged files for some reason.
For example:
And so on:
Again, these were just installed, so there should be no change.
If you have any suggestions where I can start to look into this I'd appreciate it! I realise debugging on Arch32 is probably not convenient for you, but I might need some hints about where to start digging at this.
Steps to reproduce the problem:
I'm using xfs instead of btrfs for the root file system on this computer, not sure if that is relevant.
Configuration:
# I have yet to figure out what causes it, but it seems premature to post my entire config, as that works perfectly on x86_64.Expected result:
Normal behaviour, where it knows what an empty diff is.
Actual result:
Lots of "fake" diffs reported that aren't actually different.
Log:
Additional context:
If you have any suggestions where I can start to look into this I'd appreciate it!
The text was updated successfully, but these errors were encountered: