Skip to content

Commit

Permalink
Ticket #4576: fix visual glitches by avoiding g_module_close on `NU…
Browse files Browse the repository at this point in the history 
…LL` while loading `libaspell`

Signed-off-by: Yury V. Zaytsev <yury@shurup.com>
  • Loading branch information
@zyv
zyv committed Aug 25, 2024
1 parent ac4305d commit 8765550
Showing 1 changed file with 4 additions and 2 deletions.
6 changes: 4 additions & 2 deletions src/editor/spell.c
View file
Original file line number Diff line number Diff line change
Expand Up @@ -174,8 +174,10 @@ spell_available (void)

spell_module = g_module_open ("libaspell", G_MODULE_BIND_LAZY);

if (spell_module != NULL
&& ASPELL_FUNCTION_AVAILABLE (new_aspell_config)
if (spell_module == NULL)
return FALSE;

if (ASPELL_FUNCTION_AVAILABLE (new_aspell_config)
&& ASPELL_FUNCTION_AVAILABLE (aspell_dict_info_list_elements)
&& ASPELL_FUNCTION_AVAILABLE (aspell_dict_info_enumeration_next)
&& ASPELL_FUNCTION_AVAILABLE (new_aspell_speller)
Expand Down

6 comments on commit 8765550

@alerque
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this be put out in a patch release? I'm trying to figure out whether I need to back-port the patch to Arch Linux packages or force people to install a spell checker so the package works around glitches, or just let it be and get the proper fix in the next upstream release.

@zyv
Copy link
Member Author

@zyv zyv commented on 8765550 Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @alerque, yes, please cherry pick it for the package. I think the point is still open for discussion. I've opened a GLib ticket:

https://gitlab.gnome.org/GNOME/glib/-/issues/3459

... and we are still arguing about broken wrappers:

https://midnight-commander.org/ticket/4575

So a point release is pointless at the moment, ha-ha :-/

On a related note, it's peculiar how we release a RC and wait a few weeks, and then after the final release, reports like this start coming in. I'm thinking maybe we should stop doing RCs and knowingly breaking things with every release. Also, point releases seem useless because everyone uses mc through the package managers, and it seems easier for distro maintainers to pull in a patch or two than to upgrade to a completely new version. And in any case, it takes time :(

@alerque
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you've analyzed the release situation upside down.

On a related note, it's peculiar how we release a RC and wait a few weeks, and then after the final release, reports like this start coming in. I'm thinking maybe we should stop doing RCs and knowingly breaking things with every release.

RCs don't get much use because people have to go out of their way to find and use them. The reports come rolling in on final releases because that's when they get pushed out to distros and it lands in people's lap whether they were looking for it or not.

Also, point releases seem useless because everyone uses mc through the package managers

This doesn't make any sense. Package managers push out point releases too, just not alpha/beta/RC releases.

and it seems easier for distro maintainers to pull in a patch or two than to upgrade to a completely new version. And in any case, it takes time :(

No, as an avid distro package maintainer on several distros this is just not true. Patching anything (even cherry picking existing patches) is easily an order of magnitude more time and effort that pushing out a new release. I can release bump a package on several distros in literally seconds with one CLI command. Patching means downloading, editing files, renaming them, figuring out patch depths, checking that it prepares, changing source array lengths, manually committing and explaining, etc. Even if patching can be done distro packagers would always rather reach for a new upstream release. Even if it wasn't harder, Arch even has a policy against patching software unless really necessary.

@zyv
Copy link
Member Author

@zyv zyv commented on 8765550 Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, as an avid distro package maintainer on several distros this is just not true.

So, as a distro maintainer, you would say that these days you'd prefer upstream to push out a release, then a point release that you can bump sometime later (a few weeks, a month?). At the same time, we can just forget about RCs (unless we have our own active testing community). And cherry-picking is something you can live with for a few trivial patches that apply cleanly, but in general it costs an order of magnitude more work?

I am just trying to figure out the way forward for both of us. There were times when we were actively rewriting things, so we did point releases, but nowadays it's mostly a few patches after a release is pushed out, and RCs don't seem to get any attention.

@alerque
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, as a distro maintainer, you would say that these days you'd prefer upstream to push out a release, then a point release that you can bump sometime later (a few weeks, a month?). At the same time, we can just forget about RCs (unless we have our own active testing community). And cherry-picking is something you can live with for a few trivial patches that apply cleanly, but in general it costs an order of magnitude more work?

Yes, that's about the shape of it from my side, and I think I can speak for many/most distro packagers in that regard. A patch release even the day after a release is a lot less work than having to patch bugs ourselves no matter how clean a patch is out there for it—by a long shot. And yes RC releases probably make sense when you have an active testing community or just want to test the release process itself internally, but for a mostly-stable app that people just use from their distro having things "fixed in upstream HEAD" or in an RC they have to go build and install themselves is just not a very useful state compared to "this package works out of the box on my distro".

@zyv
Copy link
Member Author

@zyv zyv commented on 8765550 Aug 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thanks for the feedback, much appreciated! We'll drop the RCs and think about reintroducing patch releases. Pushing out a release is a lot of work right now, but as we improve the infrastructure, it may become feasible for even a few patches.

Please sign in to comment.