Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#13877 closed enhancement (fixed)

Find a better solution for the configure hang than backing out the fix for bug 762358

Reported by: gk Owned by: gk
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-gitian, ff38-esr
Cc: Actual Points:
Parent ID: #15772 Points:
Reviewer: Sponsor:

Description

For 4.0.2 and 4.5-alpha-2 we had to back out Mozilla's fix for bug 762358 as it broke our deterministic build setup. It seems it is running |configure| again during the |make build| step which should not be needed as we are not changing .mozconfig (again). Maybe having a .mozconfig file in the first place is already counted as "changing .mozconfig" here. |configure| does not like libfaketime but we need the latter for the |make build| step in order to cope with timestamps embedded, e.g. in libraries.

Child Tickets

TicketTypeStatusOwnerSummary
#13970defectclosedgklibfaketime exceptions are not passed down the Mozilla build system properly

Change History (6)

comment:1 Changed 5 years ago by gk

Running |python2.7 mach environment --format=client.mk| causes the problem. Avoiding a Firefox patch boils down to add python2.7 to FAKETIME_SKIP_CMDS. This works for Linux and Windows but not for OS X. Without python2.7 as the first command we get the hang at the beginning but without rsync as the first command we get the rsync hang (#10153). Thus, stalemate.

comment:2 Changed 5 years ago by gk

Keywords: ff38-esr added

We should get this fixed when switching to ESR 38 provided Mozilla is not backporting another change to the ESR 31 build system which needs the code that got backed out.

comment:3 Changed 5 years ago by gk

Parent ID: #15772

comment:4 Changed 5 years ago by gk

This turns out to be a libfaketime bug. I contacted the maintainer trying to upstream a patch for it. Quorting from that email:

The problem seems to be that strtok_r() is modifying the evnironment
variable directly. Quoting from the getenv(3) man page:

"As typically implemented, getenv() returns a pointer to a string within
the environment list. The caller must take care not to modify this
string, since that would change the environment of the process."

The result is that FAKETIME_SKIP_CMDS, having been, say,
"python2.7,make,rsync" is only "python2.7" after the first run.

We should strdup() the string and work on the result instead. This fixes our problem.

Version 0, edited 5 years ago by gk (next)

comment:5 Changed 4 years ago by gk

Resolution: fixed
Status: newclosed

Yay, my patch got upstreamed: 18f5ec0671705bac190787a8612fc2a58b1be1d1. Closing this and fixing in #16181.

comment:6 Changed 4 years ago by gk

Quoting my last comment in #16181

Sadly, I had revert the libfaketime commit we use and include the patch I upstreamed for OS X only. For some reason this broke our Linux builds. Given that libfaketime issues are not so easy to debug and we probably won't have to use libfaketime anymore starting with our switch to esr45 I decided that this workaround is enough for now.
Note: See TracTickets for help on using tickets.