Repository navigation
Investigate support/automation for Arch Linux package deployment process #783
Description
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 Could this be used on Arch Linux? #73) but the original creator isn't the maintainer anymore
- Some background is explained in the Issue with markdown export if jrnl entry already contains markdown formatting. #779 bug report by @griffrawk (thank you!)
Activity
stale commentedon Mar 4, 2020
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 commentedon Mar 7, 2020
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 commentedon Apr 9, 2020
The maintainer of the package, @flocomkoko, reached out in #883. I'm continuing the conversation here.
wren commentedon Apr 9, 2020
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.
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 specifiedtzlocal = "^1.5"(which meanstzlocal = ">=1.5,<2.0"), but the AUR package sayspython-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 totzlocal = ">1.5, <3.0"as a quick-fix, but it doesn't address the root problem that the dependencies don't match.I just want to say, again, that we appreciate your work in maintaining this, and are happy to help support you and the community.
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?
jrnl-org#783 Allow keyring >19.0, <22.0 instead of ^19.0
Update keyring version from "^19.0" to ">19.0, <22.0" (#914)
wren commentedon Apr 11, 2020
@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?
wren commentedon Apr 12, 2020
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!
Update keyring version from "^19.0" to ">19.0, <22.0" (#914)
Update keyring version from "^19.0" to ">19.0, <22.0" (#914)
wren commentedon Apr 18, 2020
@flocomkoko v2.4-beta is now available. Can you please double-check that it works with the AUR packaging?
eli-schwartz commentedon Apr 19, 2020
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):
makepkg --printsrcinfo > .SRCINFOto freeze the metadataThe 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.
benoliver999 commentedon May 4, 2020
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 commentedon May 4, 2020
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 commentedon May 4, 2020
As far as I can tell, jrnl requires pytz 2019.1, but now it's at 2020.1, jrnl will not install on arch.
wren commentedon May 5, 2020
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 commentedon May 5, 2020
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:
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 commentedon May 5, 2020
@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.
Update keyring version from "^19.0" to ">19.0, <22.0" (#914)