Bug 2364617

Copr build:
https://copr.fedorainfracloud.org/coprs/build/9005654
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2364617-apostrophe/fedora-rawhide-x86_64/09005654-apostrophe/fedora-review/review.txt

Found issues:

- A package with this name already exists. Please check https://src.fedoraproject.org/rpms/apostrophe, https://src.fedoraproject.org/flatpaks/apostrophe
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_conflicting_package_names

Please know that there can be false-positives.

---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

It looks like this was previously built in Fedora but was retired due to upstream issues (see rhbz#2291412 and rhbz#2290496).

Looking at the upstream repo, I don't think much has changed. The codebase doesn't seem to have been updated in 4 years.

While it's true that the codebase between 3.0 and 3.2 has been pretty stagnant, (though it seems like there's been a bit more activity since the 3.2 release,) my understanding of the previous reports is that most of the crashes were due to calling functions that didn't exist in  upstream libspelling and gtksouceview5, which have now been upstreamed into recent versions of those libraries.

I've been testing my builds for 3.2, and I haven't yet encountered the previous random crashes, though I have only tested relatively simple Markdown files so far (just text, links, headers, and images).

Don't have time for a full package review at the moment, but I tried a local Fedora flatpak build of this and it seems to be working just fine.  As soon as it's back in, I can reinstate the Fedora flatpak.

I'd prefer to see less wildcards in %check and %files, but otherwise I don't see any blatantly obvious problems in the spec file.

This looks a bit strange to me:

```
%forgeautosetup -p1
%setup -q -n %{name}-v%{version} -D -T -a1
```

You should very likely either use one or the other. Using more than one %*setup macro will do strange things.

First of all, thanks for trying to bring back Apostrophe to the Fedora repos. I've been unable to find a replacement that suits my needs since the package was retired.

(In reply to Alexander Lent from comment #3)
> While it's true that the codebase between 3.0 and 3.2 has been pretty
> stagnant, (though it seems like there's been a bit more activity since the
> 3.2 release,) my understanding of the previous reports is that most of the
> crashes were due to calling functions that didn't exist in  upstream
> libspelling and gtksouceview5, which have now been upstreamed into recent
> versions of those libraries.

As of version 3.3 the upstream patches for libspelling and gtksourceview have been dropped. I've tried a local build and it worked well with the system installed libraries. I was unable to reproduce bug 2291412.

(In reply to Yaakov Selkowitz from comment #4)
> I'd prefer to see less wildcards in %check and %files, but otherwise I don't
> see any blatantly obvious problems in the spec file.

For the .desktop and .xml files you can simply replace the asterisk with the already defined macro %{appid}. You may also want to run some tests in %check with:

%{py3_test_envvars} %python3 tests/test_regex_commonmark.py

Could you update to version 3.3? I'd be willing to take a shot at the review since I'd really like to see this package back in Fedora.

Thanks for the offer, and apologies that it's taken a week to get everything together. Let me know if you need me to handle a review or several down the line.

I think I've addressed all the comments so far as well as bringing the package up to date as of v3.3:
Spec URL: https://src.fedoraproject.org/fork/xanderlent/rpms/apostrophe/raw/3eb21eee31f3348da8e24b3d3ca6fc2a6bf03ca8/f/apostrophe.spec
SRPM URL: https://gist.github.com/xanderlent/865bec2cdc3279c08387c8da89a0b594/raw/0e9d4d47750304eb064754e2c435e706423c1fa2/apostrophe-3.3-1.fc44.src.rpm

Created attachment 2107949 [details]
The .spec file difference from Copr build 9005654 to 9625493

Copr build:
https://copr.fedorainfracloud.org/coprs/build/9625493
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2364617-apostrophe/fedora-rawhide-x86_64/09625493-apostrophe/fedora-review/review.txt

Found issues:

- A package with this name already exists. Please check https://src.fedoraproject.org/rpms/apostrophe, https://src.fedoraproject.org/flatpaks/apostrophe
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_conflicting_package_names

Please know that there can be false-positives.

---
This comment was created by the fedora-review-service
https://github.com/FrostyX/fedora-review-service

If you want to trigger a new Copr build, add a comment containing new
Spec and SRPM URLs or [fedora-review-service-build] string.

According to https://gitlab.gnome.org/World/apostrophe/-/blob/main/NEWS?ref_type=heads, Apostrophe had two releases last September.

Would it be possible that we have Apostrophe back in Fedora?

Many thanks for your work to all people involved (new maintainer and reviewers).

Hi,

I will help this one along.

* Builds.

  - Local x86_64: Good.
  - COPR: Good.

* RPM lint.

Things to review.

============================ rpmlint session starts ============================
rpmlint: 2.8.0
configuration:
    /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
rpmlintrc: [PosixPath('/tmp/tmp3_jwm6nt')]
checks: 32, packages: 2

apostrophe.noarch: E: spelling-error ('pandoc', '%description -l en_US pandoc -> pan doc, pan-doc, panda')
apostrophe.src: E: spelling-error ('pandoc', '%description -l en_US pandoc -> pan doc, pan-doc, panda')
apostrophe.noarch: W: no-manual-page-for-binary apostrophe
apostrophe.spec:51: W: mixed-use-of-spaces-and-tabs (spaces: line 20, tab: line 51)
apostrophe.noarch: W: hidden-file-or-dir /usr/lib/python3.14/site-packages/apostrophe/.pylintrc
apostrophe.noarch: E: explicit-lib-dependency libadwaita
apostrophe.noarch: E: explicit-lib-dependency libspelling
 2 packages and 0 specfiles checked; 4 errors, 3 warnings, 7 filtered, 4 badness; has taken 0.4 s

* Test run: Fail

Fails to start.

philwyett@ks-c3po:~/Downloads$ apostrophe 

(apostrophe:5663): Adwaita-WARNING **: 22:48:09.055: The resource style-dark.css is deprecated and shouldn't be used anymore. Use style.css with media queries instead.

(apostrophe:5663): Adwaita-WARNING **: 22:48:09.055: The resource style-hc.css is deprecated and shouldn't be used anymore. Use style.css with media queries instead.
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/apostrophe/text_view.py", line 139, in __init__
    self.markup = MarkupHandler(self)
                  ~~~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.14/site-packages/apostrophe/text_view_markup_handler.py", line 142, in __init__
    Process(target=self.parse, args=(child_conn,), daemon=True).start()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib64/python3.14/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ~~~~~~~~~~~^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 300, in _Popen
    return Popen(process_obj)
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
    self._launch(process_obj)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 47, in _launch
    reduction.dump(process_obj, buf)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^
TypeError: cannot pickle 'ApostropheTextView' object
when serializing dict item 'textview'
when serializing apostrophe.text_view_markup_handler.MarkupHandler state
when serializing apostrophe.text_view_markup_handler.MarkupHandler object
when serializing tuple item 0
when serializing method reconstructor arguments
when serializing method object
when serializing dict item '_target'
when serializing multiprocessing.context.Process state
when serializing multiprocessing.context.Process object
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/apostrophe/application.py", line 142, in do_activate
    self._set_color_scheme()
    ~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.14/site-packages/apostrophe/application.py", line 259, in _set_color_scheme
    window.textview.markup.on_style_updated()
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ApostropheTextView' object has no attribute 'markup'
Traceback (most recent call last):
  File "/usr/lib/python3.14/site-packages/apostrophe/application.py", line 142, in do_activate
    self._set_color_scheme()
    ~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.14/site-packages/apostrophe/application.py", line 259, in _set_color_scheme
    window.textview.markup.on_style_updated()
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ApostropheTextView' object has no attribute 'markup'

* Looking for upstream releases.

Regards

Phil

Hi, thanks for taking this review. I had poked at version 3.4 but had also received the same error.

It looks like the error was a change to how multiprocessing works in Python 3.14 - every other distro that ships this code with Python 3.14 will eventually encounter this issue - I should probably report it upstream. For now, patched downstream.

Spec URL: https://src.fedoraproject.org/fork/xanderlent/rpms/apostrophe/raw/484e4dd5d2622c53bc6568257a0bad7dbedebc28/f/apostrophe.spec
SRPM URL: https://gist.github.com/xanderlent/865bec2cdc3279c08387c8da89a0b594/raw/3ac57335cb1ca6b360c6addaa98ea67cbc4bc537/apostrophe-3.4-1.fc45.src.rpm

(In reply to Alexander Lent from comment #12)
> Hi, thanks for taking this review. I had poked at version 3.4 but had also
> received the same error.
> 
> It looks like the error was a change to how multiprocessing works in Python
> 3.14 - every other distro that ships this code with Python 3.14 will
> eventually encounter this issue - I should probably report it upstream. For
> now, patched downstream.
> 
> Spec URL:
> https://src.fedoraproject.org/fork/xanderlent/rpms/apostrophe/raw/
> 484e4dd5d2622c53bc6568257a0bad7dbedebc28/f/apostrophe.spec
> SRPM URL:
> https://gist.github.com/xanderlent/865bec2cdc3279c08387c8da89a0b594/raw/
> 3ac57335cb1ca6b360c6addaa98ea67cbc4bc537/apostrophe-3.4-1.fc45.src.rpm

Hi,

Do you have an upstream bug reported or pull request putting forth the fix?

Regards

Phil

Hi, I just found an upstream bug for this issue. I will cite it in the specfile in my next round of edits.

https://gitlab.gnome.org/World/apostrophe/-/issues/669