Crash when selecting 8-way and switching sets

[gombosg]

Repro

• Open a new config
• Select 8-way for either stick
• Switch to another set
• Switch back to set 1 ...?
• 'antimicroX' terminated by signal SIGSEGV (Address boundary error)

Hope it crashes for you, too. :smile: Example file included.

gamepad.gamecontroller.zip

[gombosg]

Sorry, closing this @juliagoda , it doesn't happen on master, only in the latest release I was packaging. Maybe it's time for a new release...? :wink:

[juliagoda]

Okay, there will be a new release, but first I have to find bugs and fix them.

[gombosg]

I see. What is missing? I mean, a lot has been fixed since the last release (this 8-way bug, dark mode etc.) - it's really a noticeable quality improvement. Is there some breaking bug that prevents tagging a new release that could hit the Fedora repos right after a review approval?

[sirlucjan]

Hi,

There's nothing to prevent you from putting patches on the tagged, stable version that contain the features you mentioned. To do this, you can use the git format-patch or git diff and put them in the spec file.

Alternatively, you can create a spec for antimicro-dev or antimicro-git and build based on the latest or the commit you are interested in. In case of any problems write here or directly to an email to me, I will be glad to help.

Greetings from Poland!

[gombosg]

Hi, thanks for offering help! :slightly_smiling_face:

I know I could create a specfile from a commit or make patches, but I don't see much value in duplicating upstream work in non-critical cases. I usually encourage upstream not to forget about releases (because I'll get notified at https://release-monitoring.org/), but if they don't see it justified because of missing testing, bugs or whatever then why would I override that decision.

You can follow the Fedora submission in #118. If you are a packager, I'd appreciate if you could review the specfile!

@juliagoda if you have concerns about tagging a release, let me know if I could help with some testing for example.

[juliagoda]

Is there some breaking bug that prevents tagging a new release

Well, several critical bugs. I'm glad I fixed a bug that also appeared in your case, but other cases are also very important and I can't move them to a new release knowing about them. What is the point of doing this now when there are still problems that will appear in the new release. You won't have to wait too long until the next release anyway

[sirlucjan]

Sure, but if for some reason another stable version can't be released, it's worth considering patches that add the expected functionality. I have a bit of experience in packaging so you can count on help if needed.

[gombosg]

@juliagoda I totally understand, it's your call when to do a release, that's why I was asking - to better understand the situation.

If the mentioned critical bugs are also present in the current latest release 2.25, I don't see why you chould not do a 2.25.1 patch release on the other hand. No release is perfect, but if it patches some bugs it's already better than nothing - increases software quality and allows users to test the new/fixed functionality.

An exception is of course if these critical bugs were recently introduced or are regressions, then of course it makes sense to delay release a bit.

@sirlucjan I see. It is a possibility technically but this raises several questions that I don't really want to answer. :) (which commits to cherry pick from the 119 since the latest release, can they be used stand-alone, do they introduce bugs/regressions etc.)

[juliagoda]

An exception is of course if these critical bugs were recently introduced

Sure, some of the bugs were appearing on old AntiMicro and users keep coming in from old version with their problems to fix, but some are new