Opened 9 years ago

Closed 4 years ago

Last modified 4 years ago

#11666 closed enhancement (fixed)

Build inconsistencies

Reported by: luroh Owned by: nobody
Priority: low Milestone: R1/beta2
Component: Build System Version: R1/Development
Keywords: Cc: degea@…
Blocked By: #11174, #11610, #11650 Blocking:
Platform: All

Description

As build inconsistencies have shown to manifest themselves in seemingly unrelated ways, the purpose of this ticket is to facilitate tracking such issues under one umbrella.

Please add tickets possibly related to build inconsistencies such as displayed in tickets #11174 and #11650.

Change History (14)

comment:1 by ttcoder, 9 years ago

Cc: degea@… added

With ticket:11174#comment:20 possibly being a key symptom, right ?

Also /me refrains from adding #11497 as of yet as the suspicion is very thin on that one, looks more like a "normal" bug.

in reply to:  1 comment:2 by luroh, 9 years ago

Replying to ttcoder:

With ticket:11174#comment:20 possibly being a key symptom, right ?

Right, although it may equally well be the other way around, broken nightly builds and working repos. On top of that, the same buildbots have been found to produce both broken as well as working nightly builds and repos (ticket:11650#comment:23).

Last edited 9 years ago by luroh (previous) (diff)

comment:3 by pulkomandy, 9 years ago

#11435 was identified and there was an actual bug behind it. Something to watch for is the fact that packagefs does not sort FS entries and they can have a "random" order depending on how the packages were created and when they were mounted. This can lead to this kind of problem when two files (drivers or so) are conflicting when loaded in the wrong order.

comment:4 by ttcoder, 9 years ago

Blocked By: 11708 added

Seems #11708 is another symptom of this nightlies & updates build problem

comment:5 by anevilyak, 9 years ago

Blocked By: 11708 removed

(In #11708) First of all, given that no one has come forward to say the same revision actually works for them, there is no inconsistency here. Second, considering that the issue which originally prompted creating the "inconsistencies" ticket was shown to be a result of a bug in a translator, and not an actual build problem, I'm hesitant to say that ticket still serves a purpose. At the end of the day, some bugs won't be reproducible for everyone, and that's simply the nature of things due to differences in hardware/environment/usage. Please don't start assuming that every random new problem is the result of some mystical build boogeyman without evidence.

comment:6 by ttcoder, 9 years ago

I'll wait for Adrien's call on this if you don't mind.. If he concurs I should do so, I'll create 4 new tickets for the 4 new issues that popped up when updating, thoroughly breaking the install (the rtl81xx code, the pkgman code, Pe's code ..etc whose code didn't even remotely change in the week since I last updated), as silly as that would seem to be.

Last edited 9 years ago by ttcoder (previous) (diff)

comment:7 by pulkomandy, 9 years ago

Blocked By: 11435 removed

#11666 is for tracking problems in a very specific case: things that happen on some nightly builds, but not others, so the error appears and disapears again as you update. Please don't include all "I updated Haiku and it doesn't work now" tickets as blocking this.

The fact that these problems come and go accross revisions makes them harder to track, and points to the issues being related to build-time randomness. For example in the case of #11435, there is an actual bug (the RTF translator trying to handle things it can't do), and the "randomness" making it appear either before or after the StyledEdit translator in the roster depending on how the package was created.

So, this ticket isn't "random things stop working for no apparent reason". It's rather "bug that happens on some nightly build, disappears in the next one, then comes back".

For #11708, there were recent changes to core system parts such as BMessage. If these introduced a bug, it's likely to affect many applications even though their code did not change.

For #11435, the issue is specific to ISO images, with anyboot working ok. No one has seen it go away and reappear.

comment:8 by luroh, 9 years ago

Blocked By: 11610 added; 11650 removed

Removing #11650 as that problem is now well understood. Adding #11610.

comment:9 by pulkomandy, 9 years ago

Blocked By: 11650 added

There is always an actual bug somewhere behind these issues. The fact that the actual bug is understood does not suddenly make the issues consistent and reproductible, so they should still be referenced here, and we should look for a way to make them consistent and reproductible (for example by making sure we always populate packages in the same order)

comment:10 by luroh, 9 years ago

Ah, sorry, I didn't realize the remaining issues in #11650 aren't consistently reproducible.

comment:11 by pulkomandy, 9 years ago

Milestone: R1/beta1Unscheduled
Priority: normallow
Type: bugenhancement

Assuming the real problems have all been identified except for the "sound stopped working" one - but our HDA driver always has been a bit random for me, so I don't think that is a build inconsistency issue.

I'm leaving the ticket open as we should still manage to build byte-for-byte identical images from sources. But this is not a beta1 problem anymore.

comment:12 by waddlesplash, 5 years ago

One major build inconsistency -- path handling -- is now partially solved with hrev52465, though ideally we would chdir() in Jam so that we are always using the exact same paths.

comment:13 by pulkomandy, 4 years ago

Resolution: fixed
Status: newclosed

No open "blocked by" remaining, and this particular ticket isn't about something in particular.

comment:14 by nielx, 4 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.