Pacman

Historical bug tracker for the Pacman package manager.

The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues

This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
Tasklist

FS#45818 - [pacman] Without .db.sig file, pacman -Sy uses current time for time condition, says up to date

Attached to Project: Pacman
Opened by James Harvey (jamespharvey20) - Tuesday, 28 July 2015, 21:27 GMT
Last edited by Allan McRae (Allan) - Monday, 14 December 2015, 14:21 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: If pacman doesn't find .db.sig files, it appears to use the current time as the time condition passed to curl for downloading the .db files from the mirror, which means "pacman -Sy" will never do anything, requiring a "pacman -Syy".

For some reason, my fresh install doesn't have .db.sig files in /var/lib/pacman/sync. That's a separate issue from this bug report, though. (Perhaps even user error.) Every time I roll back to my initial install snapshot, I have had to run a "-Syy". (Now I can make a "new" inital snapshot with the .sig files.)

$ ls -l /var/lib/pacman/sync
total 4688
-rw-r--r-- 1 root root 2851522 Jul 22 19:09 community.db
-rw-r--r-- 1 root root 124553 Jul 22 11:36 core.db
-rw-r--r-- 1 root root 1787307 Jul 22 18:50 extra.db
-rw-r--r-- 1 root root 27362 Jul 22 18:33 localRepo.db

...
debug: config: finish section 'core'
debug: registering sync database 'core'
debug: database path for tree core set to /var/lib/pacman/sync/core.db
debug: "/var/lib/pacman/sync/core.db.sig" is not readable: No such file or directory
debug: sig path /var/lib/pacman/sync/core.db.sig could not be opened
debug: missing optional signature
debug: setting usage of 15 for core repoistory
debug: adding new server URL to database 'core': http://mirror.us.leaseweb.net/archlinux/core/os/x8
...
:: Synchronizing package databases...
debug: url: http://mirror.us.leaseweb.net/archlinux/core/os/x86_64/core.db
debug: maxsize: 26214400
debug: using time condition: 1438117474
debug: opened tempfile for download: /var/lib/pacman/sync/core.db.part (wb)
downloading core.db...
downloading core.db...
downloading core.db...
downloading core.db...
debug: curl returned error 0 from transfer
debug: response code: 200
debug: file met time condition
core is up to date
...

Time condition 1438117474 = Tue, 28 Jul 2015 21:04:34 GMT, which was the current time when running "pamcan -Sy".

If it doesn't see a .sig, I'm not sure what the policy is. If it's basically ignoring the existing .db file as I'm assuming it does, perhaps it should use time condition 0 instead.
This task depends upon

Closed by  Allan McRae (Allan)
Monday, 14 December 2015, 14:21 GMT
Reason for closing:  Not a bug
Comment by Allan McRae (Allan) - Tuesday, 28 July 2015, 23:34 GMT
There are no .db.sig files.

pacman compares the time the .db file was created on your computer to the time the database was updated on the server. If the remote database is newer, it is updated.
Comment by James Harvey (jamespharvey20) - Wednesday, 29 July 2015, 19:20 GMT
Ahh, OK, I misinterpreted the debug messages as to the cause, then. Any idea why on the first run it's using time condition NOW, rather than the timestamp on the .db files?

I'll re-run in debug mode next time I'm rolled back to post-initial install, but I don't think there were any messages regarding time condition other than what I quoted.
Comment by Allan McRae (Allan) - Thursday, 30 July 2015, 03:22 GMT
It will be using the mtiles of the files. When you rollback, you will set the files mtime to the current time. Doing two runs with --debug will show you the time not changing.

Using -Syyu after you rollback (or change servers) will fix your issue.

Loading...