leading zeroes on revisions are lost in application.ini

NEW
Unassigned

Status

8 years ago
8 months ago

People

(Reporter: nthomas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
Symptoms: on TBPL, builds but not tests/talos showing for surkov's m-c rev 015684940860. On inspection the tests/talos have 15684940860 marked as the revision.

json-pushes:
 "15535": {
  "date": 1283828161, 
  "changesets": [
   "015684940860c96d8d9c4232efcb66b413aec469"
  ], 
  "user": "surkov.alexander@gmail.com"
 }, 

For the 10.5.2 opt build, properties:
got_revision	015684940860c96d8d9c4232efcb66b413aec469
revision	015684940860c96d8d9c4232efcb66b413aec469
sourcestamp	15684940860

Sendchanges went with the leading 0, and show up OK test builds (revision property is right). The get_build_info step outputs:
TinderboxPrint:<a href=http://hg.mozilla.org/mozilla-central/rev/15684940860 title="Built from revision 15684940860">rev:15684940860</a>

That's the main problem, although the sourcestamp property on the build is also worth investigation.
(Reporter)

Comment 1

8 years ago
From application.ini on the linux build:
 SourceStamp=15684940860

Someone's treating it as an int rather than a str.
Component: Release Engineering → Build Config
OS: Mac OS X → All
Product: mozilla.org → Core
QA Contact: release → build-config
Version: other → unspecified
(Reporter)

Updated

8 years ago
Summary: Revisions with leading 0 (zero) lose it in the maze of twisty passages, and tests don't show up on TBPL → leading zeroes on revisions are lost in application.ini
I thought I fixed this in bug 581516, is it still recurring?
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 581516
Oh, crap, this is a slightly different problem.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
So the problem is just that the leading zero is being dropped. :-/ Preprocessor.py tries to be smart and if a preprocessor define is all digits, it parses it as an int. Since this revision is all digits, it gets parsed as an int, and then when it's serialized, the leading zero is dropped.

*sigh*
Status: REOPENED → NEW
Depends on: 581516

Comment 5

8 years ago
I think this behavior of preprocessor.py is all wrong. All variables should be integers. When we try to treat them as numbers (e.g. using comparison operators) we should then try to parse them as numbers.

The only case where this might change current behavior is the == operator, which is apparently overloaded to be string-equality and number-equality currently (http://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#3045).

Updated

8 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.