810528 - Aurora and Beta MXR are out of date

Status: RESOLVED DUPLICATE of bug 803810

(Developer Services :: General, task)

Description

[:Gavin Sharp [email: [e-mail]]]

http://mxr.mozilla.org/mozilla-aurora/source/browser/config/version.txt shows "17.0a2". The current content of that file on aurora (per https://hg.mozilla.org/releases/mozilla-aurora/annotate/tip/browser/config/version.txt
) is "18.0a2".

The "blame" links point to changeset 7f77dbd943be, which was pushed on October 8th:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?changeset=7f77dbd943be

Beta is in a similar situation, but isn't as far out of date - its "blame" links point to a changeset pushed Oct 26:
https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?changeset=f7068a8403c8

Comment 1

[Dumitru Gherman [:dumitru]]

I found a lock for the daily cron (the one that generates the indexes for aurora and beta) from Oct. 26.
Removed it and manually triggered it...it takes a while.

Comment 2

[Dumitru Gherman [:dumitru]]

Looks like it got stuck again at this:

root     16494  0.0  0.0 106096  1272 pts/1    S+   11:50   0:00  |   \_ bash /root/bin/mxr-daily-cron
root     26968  0.0  0.0 106092  1176 pts/1    SN+  13:17   0:00  |                           \_ sh -c /data/www/mxr.mozilla.org/genxref /data/mxr-data/projects-central/projects >> /data/mxr-data/projects-central/genxref.log 2>/dev/null
root     26969 59.2  5.2 989184 858820 pts/1   RN+  13:17 143:51  |                               \_ /usr/bin/perl /data/www/mxr.mozilla.org/genxref /data/mxr-data/projects-central/projects

According to what I saw, mozilla-aurora and mozilla-beta were processed, but your URL still shows up 17.0a2 :\

Comment 3

[Shyam Mani [:fox2mike]]

Gavin,

I might need some help understanding this...so mxr HAS the info, just not showing it? If I go here :

http://mxr.mozilla.org/mozilla-aurora/source/browser/config/version.txt?rev=3bfbc73d1b58 it's showing 18.0a2?

Comment 4

[:Gavin Sharp [email: [e-mail]]]

That's interesting. I'm not sure how "rev" works exactly - if it just delegates entirely to the remote HG repo then it's not a useful test. What matters most for MXR is what version it has checked out and indexed. But it's possible that it's just the "hg update" step that's failing, rather than the "hg pull"? I don't recall how these update/indexing scripts work.

Comment 5

[Shyam Mani [:fox2mike]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #4)
> That's interesting. I'm not sure how "rev" works exactly - if it just
> delegates entirely to the remote HG repo then it's not a useful test.

I think that's what it does. It's just "Asking version control to show.."

Comment 7

[Jake Maul [:jakem]]

For the record: I'm fairly sure the job is *not* getting stuck in comment 2... look closely and you can see it's doing projects-central. That tree takes a *long* time to process (around 17 hours).

Other trees are processed in parallel, so this does not significantly hold up processing of the mozilla-aurora tree.

My last data for mozilla-aurora:

mozilla-aurora: Starting Sun Nov 11 01:08:19 PST 2012
mozilla-aurora: No files changed, skipping xref and indexing
mozilla-aurora: Ending Sun Nov 11 01:09:35 PST 2012

However, the last-processed file is too old:
-rw-r--r--  1 root root      0 Oct 25 05:06 last-processed

Something is causing the update-src.pl to break, I think. Investigating, and any results will be in bug 803810.

Comment 8

[Dumitru Gherman [:dumitru]]

(In reply to Jake Maul [:jakem] from comment #7)
> For the record: I'm fairly sure the job is *not* getting stuck in comment
> 2... look closely and you can see it's doing projects-central. That tree
> takes a *long* time to process (around 17 hours).

Did you look at the date? :)
It was in that state for 2 weeks. If this is not stuck, then what is it? :)

Comment 9

[Jake Maul [:jakem]]

(In reply to Dumitru Gherman [:dumitru] from comment #8)
> (In reply to Jake Maul [:jakem] from comment #7)
> > For the record: I'm fairly sure the job is *not* getting stuck in comment
> > 2... look closely and you can see it's doing projects-central. That tree
> > takes a *long* time to process (around 17 hours).
> 
> Did you look at the date? :)
> It was in that state for 2 weeks. If this is not stuck, then what is it? :)

I was referring to your comment 2, which was only a few hours after you cleared the lockfile in comment 1. I suspect (but have done minimal investigation) the lockfile in comment 1 may have been left around after a reboot... the system uptime is about right for that.