False positives which causes an update
Recently after switching to version 7.1 (previously still using 5, because I missed the transition to [community]) I noticed some updates of packages that weren't at all updated.
A small log. hekate update is an alias for
repose -Jfv --pool=/var/cache/pacman/hekate --root=/var/cache/pacman/hekate hekate.db
$ hekate_update
updating xfce4-settings 4.12.1-1 [newer build] <-- didn't rebuild it, or whatever
updating flif-git r690.6bdc5ab-1 => r698.221a503-1 <-- expected result
writing hekate.db...
writing hekate.files...
$ hekate_update
updating xdg-utils-mimeo 1.1.1-5 [newer build] <-- didn't rebuild it, or whatever
writing hekate.db...
writing hekate.files...
$ hekate_update
updating volctl 0.4.r4.g4c6a59e-1 [newer build] <-- didn't rebuild it, or whatever
updating linux-Hekate-headers 4.9.6-1 [newer build] <-- didn't rebuild it, or whatever
writing hekate.db...
writing hekate.files...
$ hekate_update
updating xfce4-settings 4.12.1-1 [newer build] <-- didn't rebuild it, or whatever
writing hekate.db...
writing hekate.files...
$ hekate_update
updating volctl 0.4.r4.g4c6a59e-1 [newer build] <-- didn't rebuild it, or whatever
updating linux-Hekate-headers 4.9.6-1 [newer build] <-- didn't rebuild it, or whatever
writing hekate.db...
writing hekate.files...
$ hekate_update
updating xfce4-settings 4.12.1-1 [newer build]
writing hekate.db...
writing hekate.files...
$ hekate_update
updating volctl 0.4.r4.g4c6a59e-1 [newer build]
updating linux-Hekate-headers 4.9.6-1 [newer build]
writing hekate.db...
writing hekate.files...
$ hekate_update
updating xfce4-settings 4.12.1-1 [newer build]
writing hekate.db...
writing hekate.files...
And so on. But the timestamp of the files didn't change, nor has their checksums. And most of the time it stops after a while doing this. But currently it switches everytime between the packages.
And idea what could be the cause? Or how I could investigate it further (bisecting it would propably be a possibility, if it could be assumed it is an issue with repose)
There should only be one reason for this to happen: the package modified timestamp is newer than the database's modified timestamp. If you said the package timestamp isn't changing, is it possible the databases' timestamp is?
And, just to be thorough, we have ruled out clock drift, right?
Oh, for what its worth, if --pool isn't provided, it defaults to --root. So you don't need to specify it twice.
On 06.02.2017 06:53, Simon Gomizelj wrote:
Oh, for what its worth, if |--pool| isn't provided, it defaults to |--root|. So you don't need to specify it twice.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vodik/repose/issues/48#issuecomment-277592456, or mute the thread https://github.com/notifications/unsubscribe-auth/AFQJJPPF1GyTOB8InbqIJR6s0MoGp2FXks5rZrV1gaJpZM4L3oXq.
TIL. The man page should probably clarify that...
Well then... Noted.
I made some copies of the db and will check on the timestamp values there. Regarding the clock drift. Shouldn't this affect all packages?
And thanks for the note regarding --pool
Just to be sure. Does repose check on the file timestamp or does it check BUILDDATE?
Anyway. As an example for one of the packages, that is currently getting updated.
.pkg.tar.xz (made after run of repose, therefor the access time matching the third one)
LANG=C stat /var/cache/pacman/hekate/xdg-utils-mimeo-1.1.1-5-any.pkg.tar.xz
File: /var/cache/pacman/hekate/xdg-utils-mimeo-1.1.1-5-any.pkg.tar.xz
Size: 61496 Blocks: 128 IO Block: 4096 regular file
Device: 812h/2066d Inode: 1312562 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ omnius) Gid: ( 100/ users)
Access: 2017-02-06 20:05:56.836559483 +0100
Modify: 2017-01-20 23:35:18.381524326 +0100
Change: 2017-01-20 23:35:18.381524326 +0100
Birth: -
From the extracted db file (after it latest update from yesterday)
LANG=C stat Befor/xdg-utils-mimeo-1.1.1-5
File: For/xdg-utils-mimeo-1.1.1-5
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 30277684 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/ omnius) Gid: ( 100/ users)
Access: 2017-02-06 20:32:59.576561194 +0100
Modify: 2017-02-05 22:42:51.000000000 +0100
Change: 2017-02-06 20:32:40.559894507 +0100
Birth: -
After another run of repose, where this package got again detected as a newer build
$ LANG=C stat After1/xdg-utils-mimeo-1.1.1-5
File: After1/xdg-utils-mimeo-1.1.1-5
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 811h/2065d Inode: 30016715 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/ omnius) Gid: ( 100/ users)
Access: 2017-02-06 20:21:28.403227132 +0100
Modify: 2017-02-06 20:05:58.000000000 +0100
Change: 2017-02-06 20:19:32.529893676 +0100
Birth: -
And just for the record. Builddate in file stays the same
Did a bisect and it points to 479c092db25b75acf257f10cfb5148c7d0ad3001 which isn't that helpful
It's the mtime of the file that matters, and copying the files around will change the mtime..
Yeah, wasn't that smart of me (and for the fact not spending a thought on it). But still. Leaving the files in place, just running repose on that folder results in a modified db (just caused from some packages ). MTIME & CTIME don't change, only ATIME got adjusted (kinda)