Bug 2129517

Summary:	Haxe install fails due to buildid conflict
Product:	[Fedora] Fedora	Reporter:	Cappy Ishihara <cappy>
Component:	haxe	Assignee:	Andy Li <andy>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	37	CC:	andy, rjones
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	haxe-4.3.2-1.fc40	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-09-15 16:01:35 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.