Bug 2129517 - Haxe install fails due to buildid conflict
Summary: Haxe install fails due to buildid conflict
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: haxe
Version: 37
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Andy Li
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-09-24 10:36 UTC by Cappy Ishihara
Modified: 2023-09-15 16:01 UTC (History)
2 users (show)

Fixed In Version: haxe-4.3.2-1.fc40
Clone Of:
Environment:
Last Closed: 2023-09-15 16:01:35 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 2066061 0 unspecified CLOSED Haxe conflicts with NekoVM 2022-09-24 10:39:31 UTC

Description Cappy Ishihara 2022-09-24 10:36:52 UTC
Description of problem:
Haxe fails to install

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. sudo dnf install haxe nekovm

Actual results:

Error: Transaction test error:
  file /usr/lib/.build-id/48/bc9d5a99376793d19c2621cadd6c59cd497761 conflicts between attempted installs of haxe-4.2.5-3.fc37.x86_64 and nekovm-2.3.0-9.fc36.x86_64


Expected results:
Haxe installs properly

Additional info:
This is the third time that this has happened since F34, Seems like every major rebuild causes this issue. Might actually need some downstream maintainence on this package.

Comment 1 Andy Li 2022-09-28 09:07:15 UTC
I've checked the contents of the two packages (haxe-4.2.5-3.fc37.x86_64 and nekovm-2.3.0-9.fc36.x86_64).
The binaries with conflicting build-ids are neko and haxelib:

    eu-readelf -n /nekovm/usr/bin/neko | grep 'Build ID:'
    Build ID: 48bc9d5a99376793d19c2621cadd6c59cd497761
    eu-readelf -n /haxe/usr/bin/haxelib | grep 'Build ID:'
    Build ID: 48bc9d5a99376793d19c2621cadd6c59cd497761

The haxelib binary is produced with the C source file produced by `nekotools boot -c haxelib.n`.
For reference, here is the haxelib C source file: https://gist.github.com/andyli/a82883dd5660091be0fc732830b04d1c

Other than the embeded haxelib neko bytecode (unsigned char program[]), the haxelib C source file is very similar to the neko source code (https://github.com/HaxeFoundation/neko/blob/v2-3-0/vm/main.c).
Probably this similarity is the cause of the same build-id, althought the two C source files are definitely not the same, thus should produce different build-ids.

I think this may be a bug in build-ids generation.

Comment 2 Richard W.M. Jones 2022-09-28 09:18:59 UTC
You might want to ask on the Fedora development list[0].  However the one
time I have seen this in the past is when two binaries were generated
without any debuginfo information inside them (ie. there was no -g option,
or the binaries were stripped by the upstream build system).  Because two
binaries with no debuginfo have effectively the same debuginfo, they
both got the same debuginfo buildid.  So you might want to check that
both are being built with -g and nothing is stripping them.

[0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/

Comment 3 Fedora Update System 2023-09-15 15:57:22 UTC
FEDORA-2023-c4f493d857 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c4f493d857

Comment 4 Fedora Update System 2023-09-15 16:01:35 UTC
FEDORA-2023-c4f493d857 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.