Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetchupdates fails #58

Open
vredesbyyrd opened this issue Nov 2, 2021 · 12 comments
Open

fetchupdates fails #58

vredesbyyrd opened this issue Nov 2, 2021 · 12 comments
Labels
bug Something isn't working

Comments

@vredesbyyrd
Copy link

vredesbyyrd commented Nov 2, 2021

Hi, thanks for sharing this tool, its great.

When trying to run pacwall -k on 2bwm it returns.:

/usr/lib/pacwall/fetchupdates.sh returned 1

I am struggling to narrow down what the issue could be, if you have any ideas I would love to hear them.

Thanks.

EDIT: I logged into budgie and same issue there. pacman version is 6.0.1-2

@vredesbyyrd
Copy link
Author

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.

@Kharacternyk
Copy link
Owner

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

@vredesbyyrd
Copy link
Author

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

@DAMO238
Copy link

DAMO238 commented Feb 19, 2022

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.

@DAMO238
Copy link

DAMO238 commented Feb 19, 2022

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.

@Kharacternyk
Copy link
Owner

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?

@Kharacternyk Kharacternyk reopened this Feb 19, 2022
@Kharacternyk Kharacternyk added the bug Something isn't working label Feb 19, 2022
@DAMO238
Copy link

DAMO238 commented Feb 20, 2022

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.

@Kharacternyk
Copy link
Owner

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.

@DAMO238
Copy link

DAMO238 commented Feb 20, 2022

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

@Kharacternyk
Copy link
Owner

Kharacternyk commented Feb 20, 2022

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.

@DAMO238
Copy link

DAMO238 commented Feb 20, 2022

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?

@Kharacternyk
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants