warning: local is newer than core

Beemo · 2026-08-18 03:07:58

warning: amd-ucode: local (20260810-2) is newer than core (20260810-1)
warning: ca-certificates-mozilla: local (3.127-1) is newer than core (3.126-1)
warning: harfbuzz: local (14.3.1-1) is newer than extra (14.3.0-1)
warning: harfbuzz-icu: local (14.3.1-1) is newer than extra (14.3.0-1)
warning: linux-firmware-amdgpu: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-mediatek: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-other: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-realtek: local (20260810-2) is newer than core (20260810-1)
warning: linux-firmware-whence: local (20260810-2) is newer than core (20260810-1)
warning: nano: local (9.2-1) is newer than core (9.1-1)
warning: nss: local (3.127-1) is newer than core (3.126-1)

❯ sudo pacman -Syu --debug
...
:: Synchronizing package databases...
 core downloading...
 extra downloading...
debug: filesystem access has been restricted to /var/lib/pacman/sync/download-xbvAOh/, Landlock ABI is 9
debug: successfully restricted 83 syscalls via seccomp
debug: core.db: url is https://(redacted)/pub/archlinux/core/os/x86_64/core.db
debug: core.db: maxsize 134217728
debug: core.db: using time condition 1787014015
debug: core.db: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/core.db.part (wb)
debug: extra.db: url is https://(redacted)/pub/archlinux/extra/os/x86_64/extra.db
debug: extra.db: maxsize 134217728
debug: extra.db: using time condition 1787014016
debug: extra.db: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/extra.db.part (wb)
debug: core.db: curl returned result 0 from transfer
debug: core.db: response code 304
debug: core.db.sig: url is https://(redacted)/pub/archlinux/core/os/x86_64/core.db.sig
debug: core.db.sig: maxsize 16384
debug: core.db.sig: opened tempfile for download: /var/lib/pacman/sync/download-xbvAOh/core.db.sig.part (wb)
debug: core.db: file met time condition

So server sent a 304 even though the file is not up-to-date. Server timestamp is 1786965360 which is older than my 1787014015, but has newer package versions inside core.db.
When I last checked for update I might have used a VPN, or reflector happened to run, so it might have been a different server. It overwrote my local core.db with a older version.
I did not use pacman -Syy at any point.

What happened?

Was there a rollback? (no?)
Pacman uses local modification time to compare with server file modification time?
Mirrors don't sync file modification time but uses their own local modification time?

Last edited by Beemo (2026-10-04 22:34:21)

Beemo · 2026-08-18 03:34:54

To avoid this issue in the future: How to select only up-to-date mirrors in reflector? Should I use --delay or --age? How does the Arch mirror website tell which are "Out of Sync Mirrors"?

Beemo · 2026-08-18 04:06:16

--delay seems to be the right option.

There will be some delay between when package is updated in the repo and when it appears on the mirror, which is unavoidable. But what I wanted to avoid is a mirror being so outdated that it still serves stale files days later. (Though the original issue might still be a bug...)

https://archlinux.org/mirrors/status/ wrote:

The check script runs on a regular basis and polls for the lastsync file in the root of our repository layout. This file is regularly updated on the central repository, so checking the value within allows one to see if the mirror has synced recently.
μ Delay: The calculated average mirroring delay; e.g. the mean value of last check − last sync for each check of this mirror URL. Due to the timing of mirror checks, any value under one hour should be viewed as ideal.

Not sure about the detail of the checking script, but based on what's written on the website, this will select mirrors that sync frequently.
Might be overkill, as some mirrors may sync only when there is an actual package update? But there isn't a stat for that. So "delay" is the best we can get.

p.s.
But ofc, Gemini was adamant that I should use --age instead (which I think was slop), feel free to correct me if this is wrong...

Last edited by Beemo (2026-08-18 04:35:41)

killertofus · 2026-08-18 04:27:11

reflector --protocol https --sort rate --country "Country Here" --save /etc/pacman.d/mirrorlist

mpan · 2026-08-18 07:19:29

There was one, just one information in this log that mattered, if we wished to investigate the issue. The mirror name. That single information is replaced with “(redacted)”.

Being left with nothing to digest, only some generic response is possible. This kind of situation usually happens after the user changes mirrors, and the new mirror is older than the old. In that scenario it’s completely benign and may be ignored. The new mirror, if working correctly, catches up with databases you have locally within a day. If on the other hand the warning appears out of the blue, with no mirror change, or persists for a long time, it’s not normal. Usually some kind of mirror breakage that requires changing a mirror to another. But what, and if, we can’t tell without knowing what mirror that was.

There is no need to adjust reflector in any way. If you invoke reflector and it selects an older mirror, it falls into the first category above. The issue will go away by itself quickly. There is no indication here of the mirror being not up-to-date. It might be the case and we could tell if we knew what mirror it is. But with its name hidden, the assumption has to be nothing is out of order and you’re using a perfectly fine mirror.

As for killertofus’ suggestion: the `--country` option is not needed. With some number of niche exceptions it only reduces quality of the results. If you’re affected by these exceptions, you know that. Instead, look at the `--latest` option. This is going to reduce the number of mirrors tested, and also selects the most recently updated ones.

Last edited by mpan (2026-08-18 07:29:46)

Beemo · 2026-08-18 09:43:57

@mpan I have investigated the mirror, but it's not the one with the problem. Likely the one before it, which I don't the URL (because no --debug) and I couldn't find it in the log.
The timestamp on core.db is 2026-08-17 11:16, which agrees with other mirrors (including https://geo.mirror.pkgbuild.com/core/os/x86_64/).
Some mirrors don't show the same time, but it's likely just local time, e.g. https://hk.mirrors.cicku.me/archlinux/core/os/x86_64/ (2026-Aug-17 19:16:21) and https://ftp.u-strasbg.fr/linux/distribu … os/x86_64/ (2026-08-17 13:16)

To answer my own questions:

pacman saves & uses the file modification time sent by the server, per HTTP spec. Also tested: after pacman -Syy, the epoch time shown in --debug is indeed 11:16.
Mirrors do sync the actual modification time, far as I checked. But there was probably a buggy mirror that sent me a wrong time. And I'm guessing it sent date.now() instead of file time (1787014015 is about 2h before I made the post).

p.s. Unfortunately I prefer to keep the account anonymous online and the mirror URLs would reveal users' location.

Last edited by Beemo (2026-08-18 10:02:52)

olegkvapil14 · 2026-08-18 09:44:45

upate core obviosly

Beemo · 2026-10-04 22:34:10

Reopening this. The issue is real, there are many servers that send different "Last-Modified" time than source in HTTP header.
Still trying to parallelise my script so that it doesn't run forever. Will post result later.

Beemo · 2026-10-04 23:43:03

from concurrent.futures import ThreadPoolExecutor, as_completed

import requests

TRUTH_SOURCE = "https://geo.mirror.pkgbuild.com/"
SUFFIX_CORE = "core/os/x86_64/core.db"
SUFFIX_EXTRA = "extra/os/x86_64/extra.db"
THREADS = 12


def get_mtime(url):
    try:
        r = requests.head(
            url, timeout=10
        )  # Can error here, e.g. NetworkError (unreachable)
        r.raise_for_status()  # Can error here, HTTP status
        t = r.headers.get("Last-Modified")
    except Exception as e:
        print(f"Request error: {e}")
        t = ""
    return t


def check_mirror(m, time_core, time_extra):
    t1 = get_mtime(m + SUFFIX_CORE)
    t2 = get_mtime(m + SUFFIX_EXTRA)
    b1 = t1 != time_core
    b2 = t2 != time_extra
    return (m, b1, t1, b2, t2)


def main():
    time_core = get_mtime(TRUTH_SOURCE + SUFFIX_CORE)
    time_extra = get_mtime(TRUTH_SOURCE + SUFFIX_EXTRA)
    print(f"core.db: {time_core}")
    print(f"extra.db: {time_extra}")

    mirror_list = requests.get(
        "https://archlinux.org/mirrorlist/?country=all&protocol=http&protocol=https&ip_version=4&ip_version=6&use_mirror_status=on"
    ).text.splitlines()
    mirrors = [
        line.removeprefix("#Server = ").removesuffix("$repo/os/$arch")
        for line in mirror_list
        if line.startswith("#Server = ")
    ]
    print(f"Number of mirrors to check: {len(mirrors)}")

    naughty = []
    with ThreadPoolExecutor(max_workers=THREADS) as executor:
        futures = [
            executor.submit(check_mirror, m, time_core, time_extra) for m in mirrors
        ]
        for i, f in enumerate(as_completed(futures)):
            m, b1, t1, b2, t2 = f.result()
            print(f"{i}: {m}")
            if b1:
                print(f"Bad core.db: {t1}")
            if b2:
                print(f"Bad extra.db: {t2}")
            if b1 or b2:
                naughty.append(m)

    print("Naughty mirrors:")
    for s in naughty:
        print(s)


if __name__ == "__main__":
    main()

Beemo · 2026-10-04 23:54:54

< 406 / 795 mirrors have different "Last-Modified" time from geo.mirror.pkgbuild.com.
Script output here (list of bad servers at the end): https://privatebin.net/?f64126afd131ac6 … oU2VZgSqxe

Some of them you can see are probably returning current time or have wrong clock: (Script started at around 23:25)

core.db: Sun, 04 Oct 2026 15:25:18 GMT
extra.db: Sun, 04 Oct 2026 22:04:32 GMT

48: http://tw.mirrors.cicku.me/archlinux/
Bad core.db: Sun, 04 Oct 2026 23:17:46 GMT
Bad extra.db: Sun, 04 Oct 2026 23:17:46 GMT
109: http://kr.mirrors.cicku.me/archlinux/
Bad core.db: Sun, 04 Oct 2026 23:26:14 GMT
Bad extra.db: Sun, 04 Oct 2026 23:26:14 GMT

20: http://mirrors.pablonara.com/archlinux/
Bad extra.db: Sun, 04 Oct 2026 21:45:22 GMT
21: https://ord.mirror.rackspace.com/archlinux/
Bad extra.db: Sun, 04 Oct 2026 21:29:06 GMT
22: http://archmirror1.octyl.net/
Bad extra.db: Sun, 04 Oct 2026 21:45:22 GMT
170: https://mirror.osbeck.com/archlinux/
Bad core.db: Sun, 04 Oct 2026 21:50:19 GMT
Bad extra.db: Sun, 04 Oct 2026 22:13:37 GMT
421: https://mirrors.logal.dev/archlinux/
Bad core.db: Sun, 04 Oct 2026 15:30:33 GMT
Bad extra.db: Sun, 04 Oct 2026 22:05:42 GMT

mirrors.cicku.me appears a lot here.

p.s. Not all servers in the list are confirmed to be buggy. Some servers in the list had connection error because I don't have IPv6; Some of them might be not updated (tho I ticked "Use mirror status" in archlinux.org/mirrorlist/); And some have CAPTCHA.

Last edited by Beemo (Yesterday 00:26:47)

Beemo · Yesterday 00:12:25

How the issue in OP happens: old db mtime -> new db mtime -> access time.
Say I visit a server that's serving the new core.db and doesn't have the bug. pacman downloads core.db from the server, upgrades, and remembers the last-modified time.
Now if I visit a server hasn't synced the new file (is still serving the old one), and has a bug that always sends current time in "Last-Modified". Time is newer, so pacman downloads the old db from the server and warns "local is newer than core".
Then I visit the good server again, pacman reports a last-modified time newer than the server, so the server returns HTTP 304 and pacman doesn't upgrade core.db and still warns "local is newer than core".

It's also possible that the server is using its filesystem modification time instead of the timestamp on the core.db of the source. Same logic applies.

If possible, please notify the server owners to sync the timestamps on the file, otherwise HTTP 304's logic breaks on a distributed network.

Last edited by Beemo (Yesterday 00:18:20)

loqs · Yesterday 00:27:21

Tier 1 mirrors I believe sync every 15 minutes and tier 2 mirrors once an hour while Arch may have pushes in between your polls. Also I do not believe you have addressed mpan's point about why use reflector after your system has found a good mirror? I have been using the same primary mirror for well over a decade as I have found no reason to change it.

Beemo · Yesterday 00:39:46

@loqs
mpan did not say that... (if I read the post correctly)
Mainly because the list of mirrors change and I want the fastest mirror. Also one of my servers is in a location with... unusual network conditions and volatile mirrors, so reflector is necessary there.
Also it wouldn't be too good if everybody avoids the buggy servers and puts strain on the good half of the server.

Still, let it not distract from the fact that there is bug here.
I don't think core.db updates every hour? geo.mirror.pkgbuild.com is tier 1 yet has a much older time:

core.db: Sun, 04 Oct 2026 15:25:18 GMT

48: http://tw.mirrors.cicku.me/archlinux/
Bad core.db: Sun, 04 Oct 2026 23:17:46 GMT

Last edited by Beemo (Yesterday 00:53:58)

loqs · Yesterday 00:53:13

core.db is updated every time new packages are added to core. As core is relatively small package set compared to extra I would suggest extra.db as a better candidate. Determining the fastest mirror under volatile conditions may not be practically possible (even under optimal conditions serving a 4K package compared to a 4G package can produce different measurements of fast) and currently leads to this sub optimal result.

Beemo · Yesterday 01:00:28

As core is relatively small package set compared to extra I would suggest extra.db as a better candidate.

Uh what...? Why isn't core.db able to tell if there is problem? If the server doesn't do core.db correctly then it's still an issue.
I would say it's the opposite, the frequently updated extra.db hides the fact that the server is returning a newer time than it is.
I don't see why the time on 48 should be newer? Unless geo.mirror.pkgbuild.com itself is outdated.

loqs · Yesterday 01:15:50

Why are you not checking lastupdate? https://wiki.archlinux.org/title/Develo … quirements and https://gitlab.archlinux.org/archlinux/ … emplate.sh

geo.mirror.pkgbuild.com has multiple hosts providing it https://archlinux.org/mirrors/geo.mirror.pkgbuild.com/ tier 1 mirrors sync from rsync.archlinux.org which is considered authoritative but only accepts connections from tier 1 mirrors.

Have you checked the content differs or if it is only the mtime?
Edit:
I agree as pacman uses mtime the mirrors should be reporting it accurately. I would suggest raising it on the arch-mirrors mailing list.

Last edited by loqs (Yesterday 01:38:16)

mpan · Yesterday 16:23:49

It would be much easier, if it was a coherent report. Not spread across many posts, across external apps (why?!), touching an issue that doesn’t sound relevant to the original problem at all. Or at least I am missing that connection. That mtimes differ between different mirrors doesn’t sound like a bug. They are only relevant within the realm of a single mirror.

You’re right that I didn’t state an explicit question. It’s implicit: in the statement of what is missing. Without that, only a generic answer is possible. And that generic answer I provided.

If the problem described in the first post persists, name the exact mirror you are using. The mirror where packages database offers packages older than the one you downloaded from the same mirror before. Copy and paste here the exact `Server=…` line you are using, the entire line.

On a separate note: the output you have shown here suggests that at least some servers were accessed using HTTP instead of HTTPS.

Last edited by mpan (Yesterday 16:29:45)

Beemo · Today 01:49:13

I would be much easier if people's reactions weren't so defensive of a bug throughout this post
I'm done talking to trolls and people who lacks capacity to understand but putting a bunch nonsense on me to disprove. It feels like I'm talking with a bunch of AIs. I think I have done what I can and more than enough as one, user.
The only thing left is to debug pacman and see if it's indeed using mtime, but this situation sours the mood.

Let people who get the same issue in the future find this post and make their own judgement

Last edited by Beemo (Today 04:13:13)

Beemo · Today 01:55:10

Already sent the email yesterday but was held for review

From: (redacted)
Date: On Monday, 5 October 2026 at 6:10 UTC
Subject: Mirrors reporting incorrect "Last-Modified" time
To: arch-mirrors@lists.archlinux.org <arch-mirrors@lists.archlinux.org>

> Ello, I was told to email here about this issue:
> Half of the Arch mirrors are not returning the original modification time of the files as seen on geo.mirror.pkgbuild.com in the HTTP "Last-Modified" header. This causes the user to be unable to upgrade DB (with a server without this bug) due to server HTTP 304, even if there is a newer copy of the file available.
>
> Forum discussion (See #11 for how this bug works): https://bbs.archlinux.org/viewtopic.php?id=314636
> Test script: (redacted)
> Test script output: https://privatebin.net/?1ebe8ea20c10304 … GVxCKqzHLi
> (See a list of buggy servers at the end. Some of them might be just outdated. The output expires in 3 days.)
>
> A browser F12 screenshot of one of the affected servers is attached.
> At the moment the latest modification time of core.db is "Sun, 04 Oct 2026 15:25:18 GMT" but the server returns "Mon, 05 Oct 2026 02:57:27 GMT" which was close to when the screenshot was taken (but not exactly...).

Last edited by Beemo (Today 06:57:50)

mpan · Today 04:09:03

loqs: the `Last-Modified` header is not file metadata. It’s a part of HTTP caching mechanism. Used to determine if a cache entry is valid. An entry for the given, single URL. `Last-Modified` only needs to remain monotonic with regard to a single URL and to consecutive versions of the named resource, and has to be in agreement with the `Date` header. If the `Date` header drifts considerably compared to wall clock, the mirror operator should be notified. But not small inaccuracies in `Last-Modified` values.

Of course there may be some issue I don’t know with pacman, if `Last-Modified` is off. But none has been presented, despite the request to do so.⁽¹⁾ With nobody else reporting such an issue (weird, with over half of mirrors claimed broken), no clear theoretical reasons for such an issue, and myself using `Last-Modified` for 10+ years in debugging various mirror issues and never noticing anything either, I guess some solid example is needed.

Beemo: nobody is “defensive.” We are trying to find the cause of your problem, if it’s not yet explained by my first reply. You are free to follow your idea of a major bug in pacman, instead of accepting support in understanding the issue. Since that help can’t be given without us getting the relevant information, we are asking for it. Asking for necessary information is no being “defensive.” It’s your interpretation of events, that we are focused on your bug.

___
⁽¹⁾ For the purpose of giving help in understanding the problem, but in this context it would also serve as an example of the bug.

Last edited by mpan (Today 04:15:13)

Beemo · Today 04:23:44

How about if I explain it to you, you help me get the attention of the relevant people? :) (So that my time is not wasted)
And if I'm proven wrong down the track, I will apologise in this thread instead.

Last edited by Beemo (Today 04:23:52)

Beemo · Today 05:54:14

(OP)

❯ sudo pacman -Syu --debug
debug: core.db: using time condition 1787014015
debug: core.db: response code 304

Server timestamp is 1786965360 which is older than my 1787014015, but has newer package versions inside core.db.

How pacman decides the timestamp to send: https://gitlab.archlinux.org/pacman/pac … pm/dload.c

#include <sys/stat.h>

# L419
	if(!payload->force && payload->mtime_existing_file) {
		/* start from scratch, but only download if our local is out of date. */
		curl_easy_setopt(curl, CURLOPT_TIMECONDITION, CURL_TIMECOND_IFMODSINCE);
		curl_easy_setopt(curl, CURLOPT_TIMEVALUE, payload->mtime_existing_file);
		_alpm_log(handle, ALPM_LOG_DEBUG,
				"%s: using time condition %ld\n",
				payload->remote_name, (long)payload->mtime_existing_file);

# L1173
			struct stat deststat;
			if(stat(dest, &deststat) == 0 && deststat.st_size != 0) {
				payload->mtime_existing_file = deststat.st_mtime;
			}

So it calls a stat on the file on disk and get its mtime, and set it as the mtime to use.
How does pacman save the file previously:

# L387
curl_easy_setopt(curl, CURLOPT_FILETIME, 1L);

https://curl.se/libcurl/c/CURLOPT_FILETIME.html

If it is 1, libcurl attempts to get the modification time of the remote document in this operation.

So pacman tells curl to download the mtime from the server as well.
CURLOPT_FILETIME is "Last-Modified" in HTTP:
https://github.com/curl/curl/blob/master/lib/setopt.c

  case CURLOPT_FILETIME:
    /*
     * Try to get the file time of the remote document. The time will
     * later (possibly) become available using curl_easy_getinfo().
     */
    s->get_filetime = enabled;
    break;

https://github.com/curl/curl/blob/master/lib/http.c

#L 3424
  const char *v = (!k->http_bodyless &&
                   (data->set.timecondition || data->set.get_filetime)) ?
    HD_VAL(hd, hdlen, "Last-Modified:") : NULL;
  if(v) {
    if(Curl_getdate_capped(v, &k->timeofdoc))
      k->timeofdoc = 0;
    if(data->set.get_filetime)
      data->info.filetime = k->timeofdoc;
    return CURLE_OK;
  }

So that's the last hole closed.

Last edited by Beemo (Today 05:57:54)

seth · Today 06:12:31

The scenario is basically using a non-syncing server that sets future timestamps on the database.

1. get a core.db from last year but today's timestamp
2. realize "Oh shoot - I'm using a bogus mirror"
3. switch to a healthy mirror
4. pacman -Syu
5. pacman won't update the core.db because it was legit updated last yesterday, the file on disk looks newer

a) This is rarely a real-life problem because with the next update to core.db the healthy mirror will have a file that also looks newer than the one on your disk
b) this is *exactly* one of the only two reasons to use the otherwise permanently abused -Syy (the other one being a deliberate downgrades)
The details of the case don't matter - whether the bogus mirror fudges http, sets a bogus local mtime, deliberately (ok, at that point you can also be concerned that your system has been compromised) or accidentally or you ran into a captive portal and got a html for a core.db - it's all the same

if [[ $TIL == "Oh shoot - I'm using a bogus mirror" ]]; then pacman -Syyu; fi

Beemo · Today 06:14:06

Producible in curl:

❯ cd cicku/

❯ curl --remote-time --remote-name https://sg.mirrors.cicku.me/archlinux/core/os/x86_64/core.db
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100 127.3k 100 127.3k   0      0 229.0k      0                              0

❯ stat core.db
  File: core.db
  Size: 130377          Blocks: 256        IO Block: 4096   regular file
Device: 0,54    Inode: 7663848     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   beemo)   Gid: ( 1000/   beemo)
Access: 2026-10-06 06:08:34.000000000 +0000
Modify: 2026-10-06 06:08:34.000000000 +0000
Change: 2026-10-06 06:08:34.868203052 +0000
 Birth: 2026-10-06 06:08:34.852202915 +0000

❯ cd ../pkgbuild/

❯ curl --remote-time --remote-name https://geo.mirror.pkgbuild.com/core/os/x86_64/core.db
  % Total    % Received % Xferd  Average Speed  Time    Time    Time   Current
                                 Dload  Upload  Total   Spent   Left   Speed
100 127.3k 100 127.3k   0      0 114.9k      0   00:01   00:01              0

❯ stat core.db
  File: core.db
  Size: 130377          Blocks: 256        IO Block: 4096   regular file
Device: 0,54    Inode: 7663855     Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   beemo)   Gid: ( 1000/   beemo)
Access: 2026-10-06 05:14:58.000000000 +0000
Modify: 2026-10-06 05:14:58.000000000 +0000
Change: 2026-10-06 06:09:06.246472120 +0000
 Birth: 2026-10-06 06:09:05.881468997 +0000

Notice how the Modify time of ciku is newer than pkgbuild

Beemo · Today 06:16:35

@seth Yes a workaround is always nice / necessary. But it'd be better if the server operators are notified of the bug and fix it...

Arch Linux

#1 2026-08-18 03:07:58

warning: local is newer than core

#2 2026-08-18 03:34:54

Re: warning: local is newer than core

#3 2026-08-18 04:06:16

Re: warning: local is newer than core

#4 2026-08-18 04:27:11

Re: warning: local is newer than core

#5 2026-08-18 07:19:29

Re: warning: local is newer than core

#6 2026-08-18 09:43:57

Re: warning: local is newer than core

#7 2026-08-18 09:44:45

Re: warning: local is newer than core

#8 2026-10-04 22:34:10

Re: warning: local is newer than core

#9 2026-10-04 23:43:03

Re: warning: local is newer than core

#10 2026-10-04 23:54:54

Re: warning: local is newer than core

#11 Yesterday 00:12:25

Re: warning: local is newer than core

#12 Yesterday 00:27:21

Re: warning: local is newer than core

#13 Yesterday 00:39:46

Re: warning: local is newer than core

#14 Yesterday 00:53:13

Re: warning: local is newer than core

#15 Yesterday 01:00:28

Re: warning: local is newer than core

#16 Yesterday 01:15:50

Re: warning: local is newer than core

#17 Yesterday 16:23:49

Re: warning: local is newer than core

#18 Today 01:49:13

Re: warning: local is newer than core

#19 Today 01:55:10

Re: warning: local is newer than core

#20 Today 04:09:03

Re: warning: local is newer than core

#21 Today 04:23:44

Re: warning: local is newer than core

#22 Today 05:54:14

Re: warning: local is newer than core

#23 Today 06:12:31

Re: warning: local is newer than core

#24 Today 06:14:06

Re: warning: local is newer than core

#25 Today 06:16:35

Re: warning: local is newer than core

Board footer