dev-games/aseprite: add 1.3.5

[winterheart]

Add new 1.3.5

[gentoo-bot]

Pull Request assignment

Submitter: @winterheart
Areas affected: ebuilds
Packages affected: dev-games/aseprite

dev-games/aseprite: @winterheart, @gentoo/proxy-maint

Linked bugs

Bugs linked: 924692

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-03-04 14:02 UTC
Newest commit scanned: 87c2788
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/e3f26e8f92/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-04-15 09:26 UTC
Newest commit scanned: 364c3b1
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/717ac0875e/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2024-04-15 11:19 UTC
Newest commit scanned: ca1f9ca
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/4f462df5c6/output.html

[juippis]

Sorry for the delay and thanks!

[eli-schwartz]

@juippis,

This PR reverts QA changes and shouldn't have been merged.

[eli-schwartz]

Was this tested? I think not. At minimum, you haven't patched the QA violation in the skia archive, nor have you upgraded the skia revision.

[juippis]

This PR didn't revert anything, it added a new version with a fix hopefully. If the proposed fix doesn't work, I guess the old workaround can be re-applied.

[eli-schwartz]

The proposed fix fails to work, because the proposed fix solves strict-aliasing issues but not ODR issues.

Updating to a new version and removing a QA fix certainly appears to be reverting a fix. But @winterheart says I'm not allowed to add QA fixes to ebuilds after several months of an open ticket, because it is a "violation of maintainer autonomy", which looks like it has something to do with the removal of the QA fix.

I cannot possibly disagree more.

[juippis]

Okay, I see there's some history here. I don't look at git log category/package before checking these bumps. The filter-lto could've potentially been there for years (via filter-flags, and no, didn't look at diff for deleted file with a bug link). What parameters you want me to test the 1.3.5 with? -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch? I'll add the flags back if it fails.

My POV:

• Gentoo maintainer is aware of the issue (upstream PR link by the Gentoo maintainer),
• upstream has an issue filed,
• upstream has a PR to fix the problem.

@winterheart is a long-standing contributor with good reputation, so obviously I'm willing to trust they've tested the patch. We often end up carrying these "workarounds" (like redundant seds) in ebuilds, so it's nice to see an attempt cleaning them out.

And to @winterheart : I admit it would've been nice to see a PR with you tagged to review it, but the truth also is that some things just need to be pushed or otherwise they'd end up rotting/waiting for different maintainers. In my opinion the filter-lto is a rather simple commit, and the bug was open long enough to react. So I really don't see that much harm in it.

But since upstream is aware of the issue, that's THE best place to fix it ultimately. Let's work with each other, rather than against each other here?

[thesamesam]

Yes, certain work falls under broad-scope QA. In this case, it's about damage limitation (reducing risk of miscompilation). If maintainers want to do further work to fix things properly, they can, although it might be a bit annoying sometimes if it blocks the LTO tracker when it's not strictly a blocker, even though it's related.

It's a shame that the additional Skia issue was missed, which Eli noted both on the bug and I would've expected @winterheart to spot when testing themselves, but mistakes happen.

[juippis]

So looks like with the patch append-flags -fno-strict-aliasing can be dropped, but filter-lto must be put back so -flto -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch will compile.

@eli-schwartz do you want me to author you, or should I just push it? And do you agree with this?

[eli-schwartz]

Yes, the patch should allow dropping -fno-strict-aliasing. I haven't tested it myself but I'm more than happy to take that on faith.

I know that -flto -Werror=strict-aliasing -Werror=odr -Werror=lto-type-mismatch will fail due to odr and lto-type-mismatch since I only added it a couple days ago and because I tested it with the upstream 1.3.5 and 1.3.6 releases (but didn't submit the updated versions, specifically to avoid stepping on the toes of the active maintainer -- I'm acting as an agent of QA here, and that begins and ends with LTO fixes).

Even 1.3.6 has the LTO errors upstream, and the patch doesn't include LTO fixes, only strict-aliasing fixes.

@eli-schwartz do you want me to author you, or should I just push it? And do you agree with this?

I don't mind one way or another who the author is. If the comment (after tweaking to adapt to strict-aliasing being obsolete) is substantially the same as mine, I suppose a reasonable argument can be made for Co-authored-by?

And yes -- re-adding the filter-lto on its own sounds correct.