Weird behaviour on Arch Linux 32: Asking for overwriting files with no changes about aconfmgr HOT 10 OPEN

Can you post the part of your configuration responsible for creating /etc/group (or some other file affected by this)?

I think there might be a quirk where if you specify the default mode ($default_file_mode, by default 644) explicitly instead of leaving it blank on file creation, the file will appear as modified to aconfmgr.

from aconfmgr.

Sure, though this does not affect Arch64, and I don't specify the mode for most of the affected files. /etc/group is messy (built up with function, sorted at the end, etc). So lets do /etc/pacman.conf which is also affected by this:

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 02-properties.sh, and are named CUST_*, you will see them used below

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

from aconfmgr.

Thanks! I wanted to see this line:

f="$(GetPackageOriginalFile pacman /etc/pacman.conf)"

So it's not the problem I was thinking about in my last post.

(built up with function, sorted at the end, etc)

Nice, you are doing it right 🙂👍

::: Only in config: /etc/pacman.conf

This seems to indicate that aconfmgr is not seeing the files being modified on the filesystem. Try running the command sudo paccheck --md5sum --files --file-properties --backup --noupgrade pacman on this system. The output should look something like this:

pacman: all files match database
pacman: '/etc/makepkg.conf' modification time mismatch (expected 2022-11-01 12:44:59)
pacman: '/etc/makepkg.conf' size mismatch (expected 6.10 K)
pacman: '/etc/pacman.conf' modification time mismatch (expected 2022-11-01 12:44:59)
pacman: '/etc/pacman.conf' size mismatch (expected 2.84 K)
pacman: '/etc/makepkg.conf' md5sum mismatch (expected 79fce043df7dfc676ae5ecb903762d8b)
pacman: '/etc/pacman.conf' md5sum mismatch (expected de541390e52468165b96511c4665bff4)

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.

from aconfmgr.

$ paccheck --md5sum --files --file-properties --backup --noupgrade pacman
zsh: segmentation fault (core dumped)  paccheck --md5sum --files --file-properties --backup --noupgrade pacman

Well! That explains it, though it is unexpected. Checking with gdb it crashes somewhere in strnlen. Unfortunately upstream for pacutils is pretty dead in my experience. I'll look into this.

from aconfmgr.

Arch32 bug report: https://bugs.archlinux32.org/index.php?do=details&task_id=317&string=pacutils
pacutils bug: andrewgregory/pacutils#64

from aconfmgr.

Aah, that's unfortunate. Is it this bug? andrewgregory/pacutils#50

from aconfmgr.

Hm! That seems very similar indeed. Probably the same yes, since andrewgregory/pacutils#51 also adds -D_FILE_OFFSET_BITS=64

from aconfmgr.

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?

from aconfmgr.

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).

from aconfmgr.

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.

from aconfmgr.