Closed Bug 542349 Opened 15 years ago Closed 15 years ago

Fix nightly deb versions

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Maemo
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: mozilla, Assigned: mfinkle)

References

Details

Attachments

(1 file, 2 obsolete files)

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.
From irc, mfinkle already working on this, so pushing his way.
Assignee: nobody → mark.finkle
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.
Attached patch potentially fix changing buildid (obsolete) — Splinter Review
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.
Attached patch new patch, only partially helps (obsolete) — Splinter Review
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.
Attachment #426453 - Attachment is obsolete: true
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.
Attachment #426800 - Attachment is obsolete: true
Attachment #427256 - Flags: review?(mark.finkle)
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"?
would the patch on bug 545570 work as well?
(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.
(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 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.
Attachment #427256 - Flags: review?(mark.finkle) → review+
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?
(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.
Blocks: 542295
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Blocks: 550023
Component: Linux/Maemo → General
QA Contact: maemo-linux → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: