Closed stefson closed 3 years ago
after a review of ebuild appears only reason to keep it in the overlay is for x86 having broken stack protector. Best solution is to test.
how does a broken stack protector manifest itself? Is it a compile failure, or is the binary broken at runtime?
how does a broken stack protector manifest itself? Is it a compile failure, or is the binary broken at runtime?
It will show up during runtime testing.
I still don't know what should be showing up during runtime, but on armv7 I was able to reboot with the new sysvinit-2.97 from the gentoo tree. Is that enough testing then?
@gyakovlev any thoughts on this from you? sadly, the reason for having this in the overlay is not very well documented. I'm leaning slightly towards thinking that this only happens on x86, as the initial commit from 2018 said:
sys-apps/sysvinit: stack protector is broken on musl x86
https://github.com/gentoo/musl/commit/285b520a169db96d841536f648189097e488e829
so maybe dropping all keywords but x86 would be a good solution?
@gyakovlev any thoughts on this from you? sadly, the reason for having this in the overlay is not very well documented. I'm leaning slightly towards thinking that this only happens on x86, as the initial commit from 2018 said:
sys-apps/sysvinit: stack protector is broken on musl x86
285b520so maybe dropping all keywords but x86 would be a good solution?
I am in favor of dropping everything but x86 keyword. This is the arch that really needs the testing done on, all the rest are fine from what I can see.
hey there, I'm just about to update my armv7 musl installation.
can =sysvinit-2.97 be used on arm, or is a backport to the overlay required?