be aware anyone updating to binutils 2.40, looks like they broke gstrip

that's the reason for rev 1.110 in pkgsrc?

I just reverted that, was only half the story

be aware also that while GNU strip is _usually_ what causes problems, it all uses the same libbfd code, so really it's "anything GNU that alters objects"

so objcopy and things like that are very likely toxic too

Are we not using our own tools for all of that?

we don't have our own objcopy

for some reason people choose to run GNU strip a lot

and not shipping it (who knows what the fallout would be?) would still leave the other binutils broken, so it's not clear it would pay for itself, misery-wise

well then we should either fix them or simply drop those tools from all releases

[illumos-gate] 15344 Fix casts from (void *) to (void) -- Marco van Wieringen <marco.van.wieringen⊙pen>

when I notice something, I file upstream bugs, and they've fixed them (or at least made noises toward that)

I don't know whether jperkin does the same

THats one, but updates seem to keep braking things for us. 2.37 or 38 was bad for OI when it came out aswell.

So question is then what keeps breaking for us

2.37 or 2.38 just added a warning message you didn't notice, I believe?

just checking: usual practice for code.illumos.org gerrit is for the submitter to "abandon" changes after they land in illumos-gate?

I don't remember the details. But it means I actually need to pay attention to binutils when updating. Not to complain, it's not that many packages these days that break stuff in release.

I'd need to do quite a bit of testing to see if our strip works ok, one reason our bits currently require gnu strip is that they use -o to ditch broken stripped outputs in case anything went wrong, so there would be some reworking required there at least

sommerfeld: Yeah, abandon with a message like "Integrated"

sommerfeld: I was going to automate it, but got scared of what automating gerrit entails.

jperkin: our strip destroys Go binaries (why do people strip go? I don't know).

I'd asked folks affected who understood the Go linker to figure out who was at fault. elfdump has things to say about the correctness of Go binaries

so it creates empty relocation sections (which I'd hope were fine), but it also creates a buildid note that is smaller than a note section can really be.

which seems like the problem.

anyway, the specifics probably don't matter to you, but anything go in pkgsrc that for some reason strips will corrupt horribly

richlowe: yeh everything destroys go binaries, our Makefiles are basically *_SUPPORTED=no

our strip/mcs need a full rewrite to be less... like themselves, too

so to be clear, we have no moral highground here

everyone likes their own flavor and all that.

ha

next q: is there any way for me to update the "description" section of a bug I filed (illumos.org/issues/15347 specifically)? Put some out-of-date info in there because I inadvertently did my initial investigation on a really old tree.

→ FEATURE 15347: bringovercheck and sccscheck can go away. (New) | code.illumos.org/c/illumos-gate/+/2615

sommerfeld: if you clikc on 'expand properties', you should be able to edit all of that

I don't see an "expand properties" button anywhere.

(maybe my account isn't sufficiently blessed to be allowed to do that?)

jclulow: can you fix sommerfeld? I'm not sure how (again)

sommerfeld: if you click "edit" it's immediately under the word "Edit" in the box that pops up, if it works for you.

I have no idea why redmine makes it hard to find, this is actually the less-hard-to-find variant

but you may also not have the perm

Probably don't have the permission. I'm not listed as a "member" of any sort on illumos.org/projects/illumos-gate

Only thing under "Edit" in the edit pop-up is a "Notes" box which lets me add a note or attach files.

sommerfeld: try now?

I now see a "change properties" in the edit popup.

thank you!

Haha sorry I was afk -- thanks for getting that richlowe

jclulow: you might want to check I did it right :)

Looks right to me!