867470 - CentOS Platform Standardize the version of hg

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[Justin Wood (:Callek)]

+++ This bug was initially created as a clone of Bug #864749 +++

CentOS bug to Standardize the version of hg

Comment 1

[Justin Wood (:Callek)]

Attachment: [binary-blob] tar.gz of Mercurial 2.5.4 rpms

These have been spot-checked to install fine,and work, on the centOS builders. Including spot-checked that the bundle file created from them (against current hg server) works against OSX10.7 and Win2k8 current mercurials.

I still have a few minor checks with hgtool to do, but wanted to get this up.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Comment on attachment 743977 [details]
[binary-blob] tar.gz of Mercurial 2.5.4 rpms

Clarifying description to include the version number.

Comment 3

[Justin Wood (:Callek)]

Open question, is what we should do about the *system* mercurial.

http://rpmfind.net/linux/rpm2html/search.php?query=mercurial shows absolutely no results for 2.5.4 other than for OpenSuse, I could hack up the srpm we have from an OLD ver of mercurial, but it does indeed look old and has lots of specific file copies/directories hardcoded in its spec that makes me wonder how useful that is.

this is going from 2.1.1-->2.5.4 for the mozilla* mercurial, however still leaves the system with 1.4-3.el6

I should note, that for our Linux builders at least, system mercurial is never used based on path (`hg --version` is currently 2.1.1)

coop, dustin, thoughts on this connundrum?

Comment 4

[Justin Wood (:Callek)]

Attachment: [puppet] v1

This is actually the only puppet patch we need for centOS builders, as far as I can tell. all things use => latest for mercurial on linux.

So we'd just need to populate the repos with it and be happy.

Comment 5

[Justin Wood (:Callek)]

Attachment: [diff-of-official-srpm] upgrade centOS provided mercurial as well

addressing the theory in c#3, here is a diff of the files in the srcrpm (ignoring the tarballs of said releases of course)

The patch is just a recreation of the 1.4 patch that was already applied per centos, and the spec changes were things that I learned needed changing building against the newer tarball.

I did not investigate if we should *add* anything to said spec, nor did I actually test the resulting rpms anywhere (yet), but this is here if you guys think we should update these files.

:coop, feel free to push this review to someone like dustin if you like.

Comment 6

[Justin Wood (:Callek)]

Attachment: [binary-blob] .tar.gz of new set of system mercurial 2.5.4 rpms

This is a set of rpms for the whole system, .tar.gz

This includes:

emacs-mercurial-2.5.4-1moz1.el6.i686.rpm
emacs-mercurial-2.5.4-1moz1.el6.x86_64.rpm
emacs-mercurial-el-2.5.4-1moz1.el6.i686.rpm
emacs-mercurial-el-2.5.4-1moz1.el6.x86_64.rpm
mercurial-2.5.4-1moz1.el6.i686.rpm
mercurial-2.5.4-1moz1.el6.src.rpm
mercurial-2.5.4-1moz1.el6.x86_64.rpm
mercurial-debuginfo-2.5.4-1moz1.el6.i686.rpm
mercurial-debuginfo-2.5.4-1moz1.el6.x86_64.rpm
mercurial-hgk-2.5.4-1moz1.el6.i686.rpm
mercurial-hgk-2.5.4-1moz1.el6.x86_64.rpm

and a full copy of   mercurial.spec

c#3 still leaves the idea of "do we use this" up for grabs, and as said in previous attachment, I haven't even tested these yet.

I chose to go with moz1 since until/unless this is accepted upstream it is a relver by us, and not upstream (so that we don't conflict if they do finally release a copy)

Comment 7

[Dustin J. Mitchell [:dustin] (he/him)]

Much of the reason for installing a custom Mozilla mercurial is to *not* change the system mercurial.  It has more to do with the system Python, but it's the same idea.  So I don't think we should replace the system mercurial - certainly not with a hand-rolled version at any rate.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

Oh, and I think we should be pinning the version of the Mozilla Mercurial RPM in puppet.  => latest is bad..

Comment 9

[Chris Cooper [:coop] (he/him)]

(In reply to Justin Wood (:Callek) from comment #3)
> Open question, is what we should do about the *system* mercurial.
>
> coop, dustin, thoughts on this connundrum?

I wouldn't touch it. This bug is about making sure the version we *use* is standard, regardless of other versions available. If the proper version of hg is first in the PATH, we're fine.

If we're really worried about it, we could change hgtool.py to spit out the hg version in use at the outset.

Comment 10

[Chris Cooper [:coop] (he/him)]

Comment on attachment 744044 [details] [diff] [review]
[diff-of-official-srpm] upgrade centOS provided mercurial as well

Review of attachment 744044 [details] [diff] [review]:
-----------------------------------------------------------------

I think we should just leave the base system as-is, i.e. no patch required.

Comment 11

[Chris Cooper [:coop] (he/him)]

Comment on attachment 744046 [details]
[binary-blob] .tar.gz of new set of system mercurial 2.5.4 rpms

Same as previous: let's just leave the base system as-is.

Comment 12

[Dustin J. Mitchell [:dustin] (he/him)]

(In reply to Chris Cooper [:coop] from comment #9)
> If we're really worried about it, we could change hgtool.py to spit out the
> hg version in use at the outset.

This is one of those things that's super-useful to already have in place the one time you need it.  +1

Comment 13

[Chris Cooper [:coop] (he/him)]

Attachment: Report the hg version in use before doing anything else

(In reply to Dustin J. Mitchell [:dustin] from comment #12)
> (In reply to Chris Cooper [:coop] from comment #9)
> > If we're really worried about it, we could change hgtool.py to spit out the
> > hg version in use at the outset.
> 
> This is one of those things that's super-useful to already have in place the
> one time you need it.  +1

Agreed, so here's a patch to do it.

Comment 14

[Justin Wood (:Callek)]

Comment on attachment 744304 [details] [diff] [review]
Report the hg version in use before doing anything else

Review of attachment 744304 [details] [diff] [review]:
-----------------------------------------------------------------

I was tempted to r- and have you do it in hgtool directly instead of as part of the mercurial method in this util, then I realized we have (at minimum) 4 copies of hgtool lying around, and this also catches other utils we call mercurial features from, so lgtm!

Comment 15

[Chris Cooper [:coop] (he/him)]

Comment on attachment 744304 [details] [diff] [review]
Report the hg version in use before doing anything else

https://hg.mozilla.org/build/tools/rev/2cf0918aca8c

Comment 16

[Justin Wood (:Callek)]

Attachment: [puppet] v1.1

This would land after the puppetAgain mirrors absorb the new rpm(s). So that we purge after we are sure new runs will pick up the new version.

Comment 17

[Justin Wood (:Callek)]

Comment on attachment 743977 [details]
[binary-blob] tar.gz of Mercurial 2.5.4 rpms

[[e-mail]3 ~]$ mv attachment.cgi\?id\=743977 mercurial.tar.gz
[[e-mail]3 ~]$ tar -xzf mercurial.tar.gz
[[e-mail]3 ~]$ ls
mercurial.tar.gz                                 mozilla-python27-mercurial-2.5.4-1.el6.x86_64.rpm
mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm  mozilla-python27-mercurial-debuginfo-2.5.4-1.el6.i686.rpm
mozilla-python27-mercurial-2.5.4-1.el6.src.rpm   mozilla-python27-mercurial-debuginfo-2.5.4-1.el6.x86_64.rpm
[[e-mail]3 ~]$ rm -rf mozilla-python27-mercurial-debuginfo-2.5.4-1.el6.*
[[e-mail]3 ~]$ rm -f mercurial.tar.gz
[[e-mail]3 ~]$ chmod 644 *.rpm
[[e-mail]3 ~]$ sudo chown puppetagainsync:puppetagainsync *.rpm
[[e-mail]3 ~]$ sudo cp -vi *.rpm /data/repos/yum/releng/public/CentOS/6/x86_64/
`mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm' -> `/data/repos/yum/releng/public/CentOS/6/x86_64/mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm'
`mozilla-python27-mercurial-2.5.4-1.el6.src.rpm' -> `/data/repos/yum/releng/public/CentOS/6/x86_64/mozilla-python27-mercurial-2.5.4-1.el6.src.rpm'
`mozilla-python27-mercurial-2.5.4-1.el6.x86_64.rpm' -> `/data/repos/yum/releng/public/CentOS/6/x86_64/mozilla-python27-mercurial-2.5.4-1.el6.x86_64.rpm'
[[e-mail]3 ~]$ rm -vf ./*x86_64.rpm
removed `./mozilla-python27-mercurial-2.5.4-1.el6.x86_64.rpm'
[e-mail]3 ~]$ sudo cp -vi *.rpm /data/repos/yum/releng/public/CentOS/6/i386/
`mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm' -> `/data/repos/yum/releng/public/CentOS/6/i386/mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm'
`mozilla-python27-mercurial-2.5.4-1.el6.src.rpm' -> `/data/repos/yum/releng/public/CentOS/6/i386/mozilla-python27-mercurial-2.5.4-1.el6.src.rpm'
[[e-mail]3 ~]$ sudo puppetagain-fixperms
[[e-mail]3 ~]$ sudo -u puppetagainsync createrepo --update /data/repos/yum/releng/public/CentOS/6/i386/
Spawning worker 0 with 2 pkgs
Workers Finished
Gathering worker results

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete
[[e-mail]3 ~]$ sudo -u puppetagainsync createrepo --update /data/repos/yum/releng/public/CentOS/6/x86_64/
Spawning worker 0 with 3 pkgs
Workers Finished
Gathering worker results

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

------
Rail then pointed out that 'we' don't store i686 in x86_64 in our releng repos by default.... so I ripped it out.
------

[[e-mail]3 ~]$ sudo rm -f /data/repos/yum/releng/public/CentOS/6/x86_64/mozilla-python27-mercurial-2.5.4-1.el6.i686.rpm
[[e-mail]3 ~]$ sudo -u puppetagainsync createrepo --update /data/repos/yum/releng/public/CentOS/6/x86_64/

Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

Comment 18

[Justin Wood (:Callek)]

now live, no apparent fallout