fetchupdates fails about pacwall HOT 12 OPEN

Alright, nevermind. Clearing the pacwall cache, /home/$USER/.cache/pacwall/* fixed the problem.

Not sure what caused it to happen in the first place, if the issue pops up again i'll reopen.

from pacwall.

Hey, thank you! Was there anything else outputted? If not, I'm not really sure what it could be.

from pacwall.

Nothing else was outputted. If the issue arises again I will dig into it further.

from pacwall.

I am encountering this issue too and the above fix does not work. When running fetchupdates.sh manually, it shows an error: cp: cannot stat '/sync/*.db': No such file or directory, and indeed, /sync is empty.

from pacwall.

After looking through the source code, I realise I was using fetchupdates wrong, if I actually supply the same same arguments that pacwall does, then it does not throw an error. Given the error that is thrown, I think for some reason, opt.db is not being passed to the subprocess call correctly for some reason. As for why this is happening, I am unsure, but I am also not an expert in C.

from pacwall.

If you supply the same arguments pacwall does, does it output another error or nothing at all? Also, do you override db in your pacman.conf or let pacwall use the default location?

from pacwall.

I use the defaults, so, from my understanding, pacwall is calling /usr/lib/pacwall/fetchupdates.sh updates.db /var/lib/pacman. Running this from a shell throws no error and makes a folder called updates.db with all the expected contents, however, when pacwall calls it, for some reason, it returns error code 1.

from pacwall.

Could you manually add set -x at the top of /usr/lib/pacwall/fetchupdates.sh and rerun pacwall? We would see which command it chokes on.

from pacwall.

This is the output:

+ set -e
+ FAKEDB=updates.db
+ PACMANDB=/var/lib/pacman
+ [[ -f updates.db/db.lck ]]
+ mkdir -p updates.db/sync
+ ln -s /var/lib/pacman/local/ updates.db/
+ true
+ cp -u --preserve=timestamps /var/lib/pacman/sync/community.db /var/lib/pacman/sync/core.db /var/lib/pacman/sync/extra.db /var/lib/pacman/sync/multilib.db updates.db/sync/
+ fakeroot -- pacman -Sy --dbpath updates.db --logfile /dev/null
/usr/lib/pacwall/fetchupdates.sh returned 1

from pacwall.

So either the fakeroot invocation fails, or there is a bug in the C macro I wrote that waits for child processes. If you remove &> /dev/null from the end of the fakeroot invocation, will it output anything? --logfile /dev/null can also be replaced by --logfile /tmp/updates.log.

from pacwall.

This shows that there are pgp errors, which is strange, because pacman isn't having any issues with pgp errors when I update.

+ set -e
+ FAKEDB=updates.db
+ PACMANDB=/var/lib/pacman
+ [[ -f updates.db/db.lck ]]
+ mkdir -p updates.db/sync
+ ln -s /var/lib/pacman/local/ updates.db/
+ true
+ cp -u --preserve=timestamps /var/lib/pacman/sync/community.db /var/lib/pacman/sync/core.db /var/lib/pacman/sync/extra.db /var/lib/pacman/sync/multilib.db updates.db/sync/
+ fakeroot -- pacman -Sy --dbpath updates.db --logfile /tmp/updates.log
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
:: Synchronising package databases...
 core                                                 133.4 KiB  2.17 MiB/s 00:00 [-----------------------------------------------] 100%
 extra                                               1542.6 KiB  5.38 MiB/s 00:00 [-----------------------------------------------] 100%
 community                                              6.1 MiB  12.4 MiB/s 00:00 [-----------------------------------------------] 100%
 multilib                                             149.6 KiB  1943 KiB/s 00:00 [-----------------------------------------------] 100%
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: GPGME error: No data
error: failed to synchronize all databases (invalid or corrupted database (PGP signature))
/usr/lib/pacwall/fetchupdates.sh returned 1

Any ideas?

from pacwall.

Well, it's strange. Besides trying purging the pacwall cache (~/.cache/pacwall by default) one more time, I don't have anything else to suggest right now, unfortunately. I'll keep this issue in mind. I'll reply when I've got any ideas.

from pacwall.