Arch Linux User Repository

New attempt with papermerge-core.
New package to follow the upstream decision to split server and gui.
Sadly the new package has also a problem. There seems to be an issue with the pyproject.toml. But at least the groundwork is there.

Odd. In a clean container the build process runs for me.
Unless I include check(), which then fails with the django errors. Likely that it will fail the same way at runtime, but didn't look at that yet. But at least creating the package should work.
And likely dateutil is a runtime dep, but didn't verify that. Therefore only added as a checkdep.

The build process outputs a lot of long exception stack traces due to not finding the module named 'dateutil'.

Installing python-dateutil eliminates that problem at least.

Although if that is installed, new exceptions get triggered during the build execution; this time due to Django 4.2.7.

Hello MarsSeed,
thank you for your words and it's totally accepted.
It's definitively true that this PKGBUILD is kind of neglected in favour of the -core package. Probably not the best if the latter still isn't working. Therefore my fault ignoring that this also in a broken state.
Regarding the merge requests.. Yeah, not the best decision to stay silent, but my reasoning was the following: Firstly I didn't had the best experience with writing to the requests list without being subscribed. Should be possible, but is moderated. But it seemed no one was looking there, as my mail never appeared. Secondly the request has valid points and this would later happened anyway. Therefore I wanted the TU who checks on the request come to its own conclusion. If my pinned comment would be taken into consideration and the fact it wasn't abandoned.
Regarding the still orphaned dependencies: Yes, should have changed that after it was getting clear, that the -core PKGBUILD would take some more time. Ignored them, as they weren't needed for the new package. Will take a look on those.
Good that you mention one alternative. Depending on how the next big release of papermerge (2.2) behaves (which will again introduce greater changes as it seems) I may come to the conclusion to scrap all PKGBUILDs. As you also noticed, upstream prefers docker, and that makes classic packaging difficult as upstream often disregards that and are unwilling to change/adjust.

To summarize: I understand your points and it's totally fine now :)

See you around and best regards

Sorry @TrialnError, I've returned maintainership of AUR/papermerge to you.

I only acted because it was flagged since 2021-04-19, and several of its dependencies are abandoned and fail to build.

The orphan request was automatically accepted by the system.

The rationale behind what I did was as follows.

As there are 3000+ pending requests, it is very hard for Package Maintainers to catch up, and nearly impossible to prioritize. If the requester is also the allocated owner of a package, and of course if there are no other feedback by anyone else, then Package Maintainer can find it straightforward to process said request.

I thought you wouldn't object because you haven't replied for more than a month now to my merge request I submitted on 2023-10-17 (PRQ#49131).

But I agree that I should have consulted you first, and for failing to do so, I wholeheartedly apologize to you.

My consideration was also that neither you nor anyone else have adopted the orphan dependencies, nor did you or anyone else communicated with the maintainers of other required packages where build failures occur.

I did not deem the fact alone that papermerge-core is also unpackageable as of now to be a really strong reason for waiting with this merge.

The latter's pyproject.toml needs work to resolve its issues. Maybe (or maybe not) the latest, currently alpha release would help. Or trying out papermerge-core in older Python, because I suspect it is not compatible with Python 3.11+. Actually, the stable papermerge-core from PyPI also fails to build in a venv, due to its unbuildable older python-lxml dep.

The papermerge-core project recommends running it in a Docker container.

Meanwhile users might want to give paperless-ngx a try, whose upstream seems to be much better maintained and which works even off of AUR.

Thank you for reading my side of the story, and again please forgive my unintendedly rude, mechanistic behavior.

Thank you also for maintaining your packages on AUR, for the benefit of the community.

Cheers, Marcell (MarsSeed)

What the hell? Why was the orphan request granted? I'm not inactive.
Deleting/merging this was on my agenda, but as the newer package still had problems I let this stay for the time being. Therefore I didn't say a thing when you filed a request. But this now? There was never an attempt at communicating, just requests and now they're granted ignoring the procedure?

New attempt with papermerge-core.
New package to follow the upstream decision to split server and gui.
Sadly the new package has also a problem. There seems to be an issue with the pyproject.toml. But at least the groundwork is there.

This package is looking for a new maintainer. If you can get papermerge v2 working, please get in touch so this package can be updated.

No, sorry, I have no idea how to fix it.

I am not interested in maintaining it, was just looking for DMS to try at home, but since you asked I will see what I can do and report here soon.

Just tried to build from the git commit with the fix I linked in my previous comment, but unfortunately, it does not fix the issue.

We can, of course, work around it by simply commenting out the check() {...} function in the PKGBUILD. I haven't found out why yet, but if I do so (or even if I uninstall papermerge and reinstall 1.5.5), the migrations don't run and complain about missing "papermerge.contrib.admin.views" module.

If you know how to fix everything, I'd be happy to let you continue maintaining this package, since I am not using it anymore myself...