542349 - Fix nightly deb versions

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aki Sasaki [:aki] (he/him)]

The buildid in deb_name.txt differs from the buildid in the xulrunner deb differs from the buildid in the fennec deb.

My vote is strongly strongly strongly strongly strongly for dropping the buildid from the filename altogether, as it is a cause of strife and pain and wasted time and it drinks all the orange juice except for maybe half a mouthful and puts the carton back in the fridge.

Also, updates worked with no buildid in the filename previously.

Alternately, once this bug is fixed and all the buildids are in sync in filenames and the deb_name.txt, I can fix bug 538699.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

From irc, mfinkle already working on this, so pushing his way.

Comment 2

[Aki Sasaki [:aki] (he/him)]

b6pre was updating to b6pre without a datetime string.
Now, 1.0.0 is updating to 1.0.0 without a datetime string.

Stuart's theory is that the dependent xulrunner deb's filename is updated, and that's triggering the update between the fennec debs with the same filename.

Could we verify this?  We could build 2 versions of fennec after we unify into a single deb, or build 2 versions of a dummy deb, with the same filename.  As long as we can differentiate the two installs in some way other than the filename, we can verify that it will or will not update if the deb name doesn't change.

Comment 3

[Aki Sasaki [:aki] (he/him)]

Attachment: potentially fix changing buildid

As I mentioned earlier, I'd rather the datetime go away in the filename, but if we need it, it needs to not change.  I'm going a little crazy with the := but I *think* this will work.

I'll try a build with this patch tomorrow.

Comment 4

[Aki Sasaki [:aki] (he/him)]

Attachment: new patch, only partially helps

So that first patch didn't do what we wanted... I was getting _~~datetime_armel.deb files.

This second patch still has differing datetimes in the deb_name.txt and actual deb name, but the additional $(PERL) statement adds the ~ in front of the a1, giving us fennec_1.1~a1~datetime_armel.deb.

Going to try two more builds, without datetime in the deb name.  I'll repack the second with a partner.js or something, and verify that the first updates to the second.

Comment 5

[Aki Sasaki [:aki] (he/him)]

I think success:

- Created two debs, same source revisions in hg, but one has a later buildid due to nuking objdir and re-creating deb later.  These are both named fennec_1.1~a2~pre_armel.deb
- Put deb #1 in repo. Installed on n810.  Checked for partner.js existence via about:config; not there.
- Repacked deb #2 with partner.js. Put in repo.  Checked for updates; got nothing... but clicked on the refresh in the bottom right and got fennec.
- Installed update. Checked for partner.js existence via about:config, and it's there.  fennec_1.1~a2~pre updates to fennec_1.1~a2~pre .

I can re-create the repo with the old & new debs for anyone else that wants to test.

I will re-verify my mobile-browser patch and attach for review.

Comment 6

[Aki Sasaki [:aki] (he/him)]

Attachment: this should do it

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 427256 [details] [diff] [review]
this should do it


>+DEB_PKG_VERSION = $(shell echo $(MOZ_APP_VERSION) | $(PERL) -pe 's/pre/~pre/; s/^([0-9.]+)([a-z][0-9]+)/$$1~$$2/')

wouldn't this fail for "1.1"?

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

would the patch on bug 545570 work as well?

Comment 9

[Aki Sasaki [:aki] (he/him)]

(In reply to comment #7)
> (From update of attachment 427256 [details] [diff] [review])
> 
> >+DEB_PKG_VERSION = $(shell echo $(MOZ_APP_VERSION) | $(PERL) -pe 's/pre/~pre/; s/^([0-9.]+)([a-z][0-9]+)/$$1~$$2/')
> 
> wouldn't this fail for "1.1"?

$ echo 1.1 | perl -pe 's/pre/~pre/; s/^([0-9.]+)([a-z][0-9]+)/$1~$2/'
1.1

nope.

Comment 10

[Aki Sasaki [:aki] (he/him)]

(In reply to comment #8)
> would the patch on bug 545570 work as well?

sure, as long as we never use the datetime.  also, not sure if you want the ~pre in there or not... i don't really care.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 427256 [details] [diff] [review]
this should do it

I think we should try this on nightlies and see how updates work. It's simpler than my patch.

Comment 12

[Aki Sasaki [:aki] (he/him)]

Ok. We should note that the first nightly won't update; 1.1a2~datetime will not update to 1.1~a2~pre aiui.

However, from that point on, after a manual uninstall and reinstall, 1.1~a2~pre should update to 1.1~a2~pre or 1.1~a2 .

Have we decided on 1.1a2pre as the version, or is the winmo alpha version still under debate?

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #12)
> Ok. We should note that the first nightly won't update; 1.1a2~datetime will not
> update to 1.1~a2~pre aiui.

I'll post in newsgroups and blog about it

> Have we decided on 1.1a2pre as the version, or is the winmo alpha version still
> under debate?

WinMo fourth alpha will be 1.1a1, so 1.1a2pre is good to go.

Comment 14

[Aki Sasaki [:aki] (he/him)]

Comment on attachment 427256 [details] [diff] [review]
this should do it

http://hg.mozilla.org/mobile-browser/rev/d4d80c7590b9

Comment 15

[Aakash Desai [:aakashd]]

verified FIXED on builds:

Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:1.9.2.2pre) Gecko/20100218 Namoroka/3.6.2pre Fennec/1.1a2pre

and

Mozilla/5.0 (X11; U; Linux armv6l; en-US; rv:1.9.3a2pre) Gecko/20100218 Namoroka/3.7a2pre Fennec/1.1a2pre