Jrnl: Investigate support/automation for Arch Linux package deployment process

[micahellison]

A fair amount of users get jrnl from the Arch User Repository package, which is great, but there's a synchronization lag between jrnl releases and updating the package. It would be nice to automate it so Arch users can easily access the latest release right away.

I'll try to get in touch with the maintainer but wanted to put this issue out there as a starting point since it will probably have some small accompanying CI changes.

Some history:

• The AUR package was set up in 2014 (see issue #73) but the original creator isn't the maintainer anymore
• Some background is explained in the #779 bug report by @griffrawk (thank you!)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[wren]

Can we sign up for AUR and leave a comment so users can find the most current jrnl version? At least until one of the repo maintainers contacts us.

[wren]

The maintainer of the package, @flocomkoko, reached out in #883. I'm continuing the conversation here.

[wren]

Hi I am packaging the AUR, just got a comment about it.

Thank you for reaching out! Really! I know it's more work to maintain things than some people realize, so I just wanted to say thank you for helping spread jrnl to Arch users.

Could you point me to my mistake in packaging?

The problem we're running into is that the dependencies for the AUR package don't match what's in jrnl (specified in pyproject.toml). We're especially looking at the upper constraint. Issue #883 was caused because jrnl specified tzlocal = "^1.5" (which means tzlocal = ">=1.5,<2.0"), but the AUR package says python-tzlocal>=1.1. So, users with tzlocal >2.0 met the requirements of the AUR package, but not for jrnl itself (and got an error at runtime). In this particular case, we were able to update the requirement to tzlocal = ">1.5, <3.0" as a quick-fix, but it doesn't address the root problem that the dependencies don't match.

I am open to all suggestions since i am very new to the AUR and this is my first package I took over since the original maintainer orphaned it and I wanted to have the new version on my system.

I just want to say, again, that we appreciate your work in maintaining this, and are happy to help support you and the community.

If you are interested in maintaining yourself i would hand the package over to you.

We, unfortunately, can't maintain an Arch package. We've looked into it before, and the tools require running Arch in order to to successfully manage the package (which neither of us does). We are happy , though, to talk about what we can do to make maintaining the package easier for you, and answer questions. Does anything come to mind?

[ghost]

Thank you for your quick support, i will try to adjust the AUR files according to your instructions.

[ghost]

Hi, i updated the AUR skript accordingly so all dependencies now match the ones specified in the pyproject file.
Sadly this make jrnl impossible to build on Arch Linux. The python-keyring provided in the repository is 21.2.0 which is higher then the maximum allowed version in the lock file.

The tzdate issue should be fixed once you release an update with the tzlocal = ">1.5, <3.0" fix. The same fix could also be applied to the python-keyring problem.

[wren]

@flocomkoko Thanks for going through the dependencies. Per your feedback, @micahellison went through to update and test our dependencies.

You should be good to go with the latest in this repo. Can you give it a shot and see if you run into any more issues?

[ghost]

Thank you, i incorporated the python-keyring version bump and the git version builds and runs.
With the next release 2.3.2 the package should run smoothly again :)

[wren]

That's great news! The next version is going to be v2.4 (since it has new features), but I'm very glad to hear it's working from source. We'll have v2.4-beta out by Saturday, and we can go from there. Thanks for all the work on this!

[wren]

@flocomkoko v2.4-beta is now available. Can you please double-check that it works with the AUR packaging?

[eli-schwartz]

We, unfortunately, can't maintain an Arch package. We've looked into it before, and the tools require running Arch in order to to successfully manage the package (which neither of us does). We are happy , though, to talk about what we can do to make maintaining the package easier for you, and answer questions. Does anything come to mind?

Hmm, here's some brainstorming for you...

Note that there are two parts to maintaining an AUR package (other than the part which just takes a text editor):

• running makepkg --printsrcinfo > .SRCINFO to freeze the metadata
• testing that the package actually works

The former can actually be done on some distributions which provide a pacman package "for purposes of managing archlinux containers", e.g. Fedora, Alpine Linux.

The latter would need an arch system, but you could do this via CI, e.g. github actions + the "archlinux" docker container.

[ghost]

@flocomkoko v2.4-beta is now available. Can you please double-check that it works with the AUR packaging?

Thank you, it just needed a small change since the LICENSE file changed to LICENSE.md apperently?
played a bit around, everything seems to work :+1:

[benoliver999]

python-pytz has been updated, and it is now blocking arch users from doing a normal system upgrade (because jrnl requires the older version).

[wren]

v2.4.1 is already out.

@flocomkoko Can you make sure the AUR package gets updated?

Also, please use v2.4.1, and not v2.4 which has a critical bug that we patched out.

[benoliver999]

As far as I can tell, jrnl requires pytz 2019.1, but now it's at 2020.1, jrnl will not install on arch.

[ghost]

v2.4.1 is already out.

@flocomkoko Can you make sure the AUR package gets updated?

Also, please use v2.4.1, and not v2.4 which has a critical bug that we patched out.

Will do

[ghost]

As far as I can tell, jrnl requires pytz 2019.1, but now it's at 2020.1, jrnl will not install on arch.

This is correct which means jrnl is again not buildable on a current arch system.

[wren]

Cool! Looks like we'll update the new dependency in the the next patch (v2.4.2).

I'm curious if this is typical behavior for Arch? The pytz release on PyPI came out on April 28th, and this was filed very shortly afterward. Is there no time window built in to allow updates to filter out through the ecosystem?

[eli-schwartz]

It is typical behavior for Arch. AFAIK all packages in the official repos work fine with it, because none of the 37 packages which directly depend on it are pinning the version.

Note that the differences between pytz 2019.3 and pytz 2020.1 are:

• mark pytz.FixedOffset as public API
• upgrade the vendored copy of tzdata, the IANA zoneinfo database (the files in site-packages/pytz/zoneinfo)

And it has duly upgraded its own version to communicate the version of tzdata it exposes -- tzdata is version 2020a, so pytz converts this to the PEP 440 compatible 2020.1 and duly declares itself to be so.

If there's a worse dependency to decide needs pinning, I don't know what it is. The release cadence is entirely determined by the release cadence of the data files it references, it communicates zero assurances about API stability, and once a year it will update to a version that is "semver incompatible" simply because that is the version of the data files.

The 2017.3 release announcement contained the humorous message "This release contains rare code changes" to fix https://bugs.launchpad.net/pytz/+bug/1631989, which happened in a "point release" but that's okay because it is "rare code changes", not "we're breaking compat, here be dragons".

[wren]

@eli-schwartz I agree that the pytz package is very low risk (we already merged in the patch, and have it on our list to look into much more permissive pinning in our next dependency audit), but it's not the specific package I'm talking about here. It's the behavior of not allowing packages time to update that worries me a bit.