Build Fedora packages #872
Comments
alerque
added
todo
tooling
|
My name is Jonny Heggheim [1], I'm a Fedora package maintainer and I would love to have SILE included in our official RPM repository. I am new to Lua and its eco-system and how to package it for Fedora. I have started with one of the missing dependencies [2]. [1] https://src.fedoraproject.org/user/jonny |
|
Dependency lua-cldr is also added for package review https://bugzilla.redhat.com/show_bug.cgi?id=2142653 |
|
This is great! Let me know if you need anything from me. It's been a long time since I worked with RPM packaging (and it was PLD Linux long before Fedora existed) but if you get stuck let me know. You might also be able to take some hints from the recently added OpenSUSE packaging since it is RPM based on they have all the Lua dependencies built now. The distro specific packaging macros are bound to be different but you can probably still take some clues from them. |
|
Thanks, I have looked at the OpenSUSE packaging, they are using luarocks RPM macros that is not included in Fedora. So my packages are mostly dropping files into /usr/share/lua/5.4/ |
|
I have made and added the following depenecies for package review:
I have started on lua-linenoise, but I am not sure how to package it, since Fedora does not want bundled libraries and it is built against a forked version of linenoise. |
|
I think you'll need somebody with Fedora expertise to answer that one. As a general rule Arch Linux doesn't like bundling libraries either and when possible we don't — but Arch also takes a pragmatism-above-principles approach and when there isn't another way to get the job done we do what works. That means there are some bundled libraries in packages. In the case of forked libraries and where the fork is (as in the case of Lua linenoise) the long stading defacto library to use for the ecosystem I think there should be a way to do it. |
|
I started building the dependencies at COPR while I am waiting for peer review approval https://copr.fedorainfracloud.org/coprs/jonny/SILE/packages/ You can use COPR for CI if you have a static build/check, then you get a large coverage of RPM distros/arches. |
|
I've only ever heard of COPR as a repository of user contributed packages, not as a CI tool. But I'm happy to consider adding CI runners to our toolking that trigger test builds on other platform. We already do this with Nix confirming that the Nix Flake builds and runs for everything that hits the master branch. If there is some way we can do that with other distros without adding the packaging itself to our repo then that might be a useful signal helping us not to break things for downstream folks. |
|
You do not need to distribute artifacts if they are not working. I would start by getting it to compile (and running tests), once you get a hang of it, then you can start by building RPMS for different distros.
https://docs.pagure.org/copr.copr/user_documentation.html#faq |
|
Here is a complete build that is using rpkg templates where they built an RPM for each commit: https://github.com/francescmm/GitQlient/blob/2976ce31b1cc0bad65db97b788da48c0415b96b9/contrib/rpm/gitqlient.spec You can also use Makefiles: |
It would be great to know if the dependency |
|
As of current versions, yes. We're assuming it's API including the bits above and beyond what Lua proper introduced. In practice most of what we use could probably be refactored to be 5.4 compatible and only need that rock as a shim for older versions, but that has not been done yet and it would come with some downsides for downstream class and package authors that would need to be aware of the differences instead of just being guarantied a consistent API. |
|
All of the missing dependencies have been built and I am running into my first SILE issue :) Do you see a configuration issue? Files in sile package: |
|
The build log, including commands and flags can be found here: https://copr.fedorainfracloud.org/coprs/jonny/SILE/build/5043639/ |
|
The above shows you are manually trying to build one chapter of the manual using a file that is a fragment not a complete document. The error is because the chapter files ASSUME they are fragments included into the master documentation file. Hence they do not specify the class and macros and various other things needed to build them. The If you want a quick and dirty test you can do something as simple as: $ echo -n '\document{foo}' | sile - -o foo.pdfThere is also a |
|
Thanks for the explanation, It's getting close for testing. Most of the examples are working. I got this error on |
|
That error message could be more friendly! I'll look into it, but in this case 'Invalid XQbject' just means it couldn't find the image it was asked to load. You seem to hake SILE.outputter:drawImage("content/examples/snake.png", ...Note I get the same result, but it works if you start from the same relative path as the resources. $ pwd
sile-typesetter.github.io/content/examples
$ sile snakes.sil
SILE v0.14.4 (Lua 5.4)
<snakes.sil> as sil
</usr/share/sile/core/sile.lua:363> as lua
libtexpdf:fatal: Invalid XObject ID: -1
$ cd ../../
$ pwd
sile-typesetter.github.io
$ sile content/examples/snakes.sil
SILE v0.14.4 (Lua 5.4)
<content/examples/snakes.sil> as sil
</usr/share/sile/core/sile.lua:363> as lua
[1]It would be possible to rewrite the example to use a path relative to the base file rather than to the CWD, it just so happens it wasn't written that way. I'll look into that as well as to a more friendly error message on the image loader. The other message you see is just that you don't have the Hack font used in some of the examples on your system. |
Allows examples to be built from *either* the project root *or* the examples directory without running into relative path issues. See sile-typesetter/sile#872 (comment)
|
I fixed the example so it will be more flexible about where you call it from. I also looked into fixing the error message and I think I'm going to duck out of that for now. We have an image package that provides an |
|
Ah, makes sense, I downloaded snakes from the home page, I did not think about that it was referencing a image |
|
I just tweaked the example on the site so that the example itself checks for the file up front so that you get a friendly error in case of people downloading standalone examples instead of the whole example directory. That should probably be addresses in the online gallery so examples that require more than one file are available as a zip or something like that. |
|
I saw there was some progress on Lua packages getting moved to core Fedora packaging. It looks like there are a few more to go, and then SILE itself. Again let me know if you need any help from me. When it does make it in, I'd love to see a PR that adds a section to the README and manual with the correct install command for Fedora. Also let me know at that point if there is somebody I should ping or some out of date flag mechanism I should trigger on future releases. Once we have install instructions documented, I'll probably mention it in a blog post. We still haven't announced the OpenSUSE packaging either so something short that points out the new options might be in order. |
Yes, it will probably take some time before all the dependencies are approved, all packages in Fedora are peer reviewed. It would be great if you could test the RPM package so that package bugs are detected early. How to test/install for now: The sile command will be installed in /usr/bin/sile. To list the files in the package you can run:
Would be great to have the install steps in the README so that your Fedora users know that it is easy to get going on Fedora. For up-to-date packages I like the usage of https://release-monitoring.org/ I tend to declare a new project if it is not already there. The service will create and assign a bug ticket to me when it noticed that there is a new version.
I think it would be great to write and prepare an article at https://fedoramagazine.org/ and publish it once SILE have been pushed to Fedora stable repository. |
I would be happy to see these provisional install instructions added to the README with a note that they will eventually change to official repos. Fell free to send a PR and we can tweak the wording again later when the steps change. I'll check it out when I get a chance, but if you got it to run at all and the |
|
Those steps don't quite get me there, at least not from a fresh Fedora docker image: [root@0fa9995cc78c /]# dnf copr enable jonny/SILE
No such command: copr. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(copr)'"I tried |
I would give |
|
Hmm.. looks like all the libertinus packages are tied to texlive, not sure why there is not an non-tex variant? |
|
Then I would suggest either not making a dependency at all (documents that use math will throw a warning, and people have the option to specify a math font or go get that font on their own) or alternatively package it as a stand along package yourself. Pulling in all of texlive to get SILE running is worse than not having the default math font. As for perl and all the modules, it is only needed for testing SILE as a developer, not for running it as an end user. The regression test suite uses it, but nothing else. |
|
(A pending PR #1563 already has better separation of developer-tooling dependencies vs. run time ones and by default |
I think perl might get pulled in because of texlive, there are no explicit dependencies on the build tools |
It seems like most other distros are packaging https://github.com/alerque/libertinus as a standalone font, not sure what the history for Fedora and texlive is. |
|
I am building [1] from https://github.com/alerque/libertinus now. I will update SILE later with new relaxed font dependencies. [1] https://copr.fedorainfracloud.org/coprs/jonny/SILE/package/libertinus-fonts/ |
|
There is a new SILE build on COPR, changelog:
|
|
I have made a RPM package for hack-fonts, it also live in the same SILE copr project https://copr.fedorainfracloud.org/coprs/jonny/SILE/build/5057377/ |
|
I found this corner-case / issue, had to use strace in order to figure out what was going on: sile will use libraries located in Would it be possible to patch the /usr/bin/sile for the RPM during build to make sure the packaged files have priority? |
|
It would be possible but would also have serious adverse effects. That path priority is not coming from SILE it is coming from the lua interpreter itself and the default package path. SILE deliberately plays nicely with the default LUA path and uses this as a mechanism for end users to override any part of SILE itself. Users can use document level, project level, user level, and system level overrides to either extend or change existing functionality. Preferring the /usr/local path is a way LuaRocks allows users to install something that overrides what their system might have installed. If you patch that out of SILE by extracting and dropping it from the default path you'll take away that standard pattern. I think your situation of having two versions installed, one manually and one system package installed is working as expected: the manual one takes precedence. That it is older in your case is an artifact of they way you played around with it. The correct way to fix it would be to |
|
I'm pretty sure the same is true on most linux systems with |
|
Ok, that makes sense, then I will not spend any time on trying to "fix" it |
|
I'm back from the road and just took another swipe at this. The install now asks for a set of lua dependencies and a "weak" font dependency that looks completely correct to me. I've never heard of a "weak" dependency but it sounds like just the ticket for covering default fonts that are assumed but not actually required to function. I'd be happy to see the COPR installation documented now and updated again for official repos later unless you think it will hit repos relatively soon, in which case we could wait. |
|
I seldom use weak dependencies, but Fedora guidelines demand [1] using fonts as weak dependency.
I think it will take a lot of time before all the packages are included in the main repository, so having them in COPR while waiting seems like a good plan. I will update the documentation at the COPR project settings, so it seems more polished. Once that is done, I will make a PR for the documentation/README. |
|
Complete overview of the remaining packages:
|
|
The process is slow due to all new packages needs to be peer reviewed and I do not have time to do review swaps. The remaining packages:
If you are interested and have time, then @alerque can be co-maintainer for the new packages that depends on SILE. I can also sponsor you to be a Fedora maintainer. See https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#comaintainer for more details |
|
@hegjon Reviewing the dependencies it looks like they have all been merged. Are there any next steps we can take on the main SILE package now? And yes if (probably after it initially merges) if you want to open an issue to add me as a co-maintainer I'd be happy to apply just to reduce the bus factor, but I'm glad an active Fedora user is spear-heading the packaging. |
|
Yes, all the dependencies should have been added to the official Fedora repository. The review of the final SILE package halted just before I moved my family from Norway to Crete in Greece, so it got down prioritized. The peer reviewer wanted me to look if it was possible to unbundle |
|
Hey, that puts you a lot closer to me! Still too far to swim, but... It is possible to unbundle |
Nice, let me know if you plan to go to Crete some day!
Thanks, I will update the review when 0.14.12 have been built. |
|
@hegjon Looks like the Fedora review system might be waiting for a poke from your side? |
|
It's coming: package! The first builds to hit stable repos will be v0.14.17 because it was much easier to proceed with the review process based on the package that was already working with all the dependencies already approved, but we'll be looking into adding any necessary Rust dependency packages and updating to v0.15.x soon after packages actually land. I'll probably hold off on the documentation and/or blog post announcement until the current version lands. In other news it looks like said announcement may also include Void Linux packages....finally back on their feet after being stuck on v0.9.x! |
Using a SILE official copy repository?
The text was updated successfully, but these errors were encountered: