Spec URL: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06981286-hare/hare.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhide-x86_64/06981286-hare/hare-0.24.0~rc1-1.fc40.src.rpm Description: Hare is a systems programming language designed to be simple, stable, and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well-suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks. Fedora Account System Username: mroche
Copr build: https://copr.fedorainfracloud.org/coprs/build/6982625 (failed) Build log: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2262452-hare/fedora-rawhide-x86_64/06982625-hare/builder-live.log.gz Please make sure the package builds successfully at least for Fedora Rawhide. - If the build failed for unrelated reasons (e.g. temporary network unavailability), please ignore it. - If the build failed because of missing BuildRequires, please make sure they are listed in the "Depends On" field --- 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.
Carrying over some important notes from the linked BZ: - This package will fail to build until qbe[0] and harec[1] update pull requests are merged. - A GA release[2] is slated for next week, this build is currently a release candidate. - The SRPM will contain a config for rpkg as it was required for SCM-based package building. [0] https://src.fedoraproject.org/rpms/qbe/pull-request/1 [1] https://src.fedoraproject.org/rpms/harec/pull-request/3 [2] https://lists.sr.ht/~sircmpwn/hare-dev/%3CCYTMKCULMVED.2ECNTW09YAQZ8%40taiga%3E
I'd like to share more feedback regarding the packaging as it stands today, and it will follow the same line as the previous one. I have recently needed to reinstall golang for work and I had forgotten how the package was structured on Fedora, and it reminded me of this ticket. It looks like a lot of inspiration was drawn from the golang packaging in Fedora to put together this hare packaging. I've always found this packaging jarring, but there must be good reasons for things to be put together as they were, but I can't help wonder about over-engineering: $ rpm -qR golang | grep go- go-filesystem $ rpm -ql go-filesystem /usr/share/gocode /usr/share/gocode/src $ rpm -ql golang | grep /usr/share/gocode /usr/share/gocode /usr/share/gocode/src /usr/share/gocode/src/bitbucket.org /usr/share/gocode/src/code.google.com /usr/share/gocode/src/code.google.com/p /usr/share/gocode/src/github.com /usr/share/gocode/src/golang.org /usr/share/gocode/src/golang.org/x What is the purpose of the go-filesystem package? It doesn't appear to have scriptlets. Back to hare, I only had a quick skim through the RPM spec, but I found the following packages: hare hare-bin hare-src hare-filesystem hare-cross-compile-gnu hare-cross-compile-llvm I feel that this really is a lot of packages for a project that aims at overall simplicity. Like I said in a previous message, we really have two things in the tool chain. The GPL-3.0-only hare and haredoc programs, and the MPL-2.0 standard library: hare hare-stdlib We should eventually provide RPM macros for hare (standard and) third-party libraries, but if the macros in question rely on the hare tooling to for example list dependencies, then we may get away with putting them in the main hare package. Packages can always be split later if they come short of use cases that may appear in the future. Regarding cross compilation, the hare tool chain will embed a default configuration, so we pick one and create the corresponding dependencies. If dependencies are too strong, we can recommend or suggest them instead. They are discoverable using the RPM command and they can even be mentioned in the package description, so users can figure out somehow that they simply need to install binutils-aarch64-linux-gnu to target aarch64. For me, the hare-cross-compile-* packages further complicate the picture instead of providing a neat and tidy abstraction. Power users will easily figure out how to tweak their cross-compilation environment anyway. Non-power-user-me managed to get there. I'm not insisting on simplicity out of nowhere. Besides my vested interest in not having a complicated setup, I picked it up from the upstream project. Some examples: https://harelang.org/blog/2022-04-25-announcing-hare/ https://drewdevault.com/talks/hare.html https://harelang.org/blog/2022-09-06-cross-builds-with-hare/ Unless there are guidelines that insist on not going with the straightforward solution, what I'm suggesting should be enough. I hope you will reconsider, start small, and expand as needed.
Taking this review.
Wait. Why this this a package review? The package exists.
Oh, I see. "harec" is the C-language bootstrap compiler for hare itself.
*** Bug 2154514 has been marked as a duplicate of this bug. ***
FWIW once qbe was updated to a snapshot in rawhide and harec to 0.24.0-rc2 I looked at upgrading my own hare spec and I found a couple gotchas. https://github.com/dridi/dotfiles/commit/2c2b735a246ccc66029ebdc8f3d100e0e6a1ac39 I'm not sure why the test suite is not failing for you, but while it passes for me on f39, I needed to add a patch to make all tests pass on f40: https://git.sr.ht/~sircmpwn/hare/commit/6f3e0d3bdaeb318938cc5e05dfa40e3cad5b2db4 And it's not just test cases that would fail with the less robust leap-seconds.list parsing. Any Hare application working with time would be lacking actual leap seconds support. I submitted a patch to ensure that haredoc is built with the configured linker flags: https://lists.sr.ht/~sircmpwn/hare-dev/patches/49393 But I realize now that it will likely go through at least a second revision, because I forgot to add the Signed-off-by line to my patch. Anyway, once we fix the upstream Makefile and configure LDLINKFLAGS properly we can leave _missing_build_ids_terminate_build alone. In my spec file I solved it like this: https://github.com/dridi/dotfiles/blob/2c2b735a246ccc66029ebdc8f3d100e0e6a1ac39/rpmbuild/SPECS/hare.spec#L1-L9 We get the same flags as those from %{build_ldflags}, except hardening flags, which should be fine for the not-long-running-with-elevated-privileges haredoc program. I added the -z noexecstack as recommended by the Hare folks, but in hindsight, I should have applied this one in config.mk: LDFLAGS = %{build_ldflags} -Wl,-z,noexecstack LDLINKFLAGS = %{ldlinkflags} -z noexecstack Not what I did, but I will: https://github.com/dridi/dotfiles/blob/2c2b735a246ccc66029ebdc8f3d100e0e6a1ac39/rpmbuild/SPECS/hare.spec#L87-L88 This way we pass as many desired system-wide linker flags as possible and stay consistent with other packages. One could argue that we should add -R to HAREFLAGS in config.mk but I have not studied the concrete effect of this option (besides skipping the debug module).
Apologies for the radio silence, I've been a bit busy but have been playing around with things locally. I'm working on a write up to address the previous comments.
I found another problem after porting my hare project to 0.24.0-rc2 and a little bit of QA. Cross compilation to riscv64 no longer works (at least on f39) because the assembler doesn't recognize the license comments. I added this to my spec file and it did the trick: # riscv64-linux-gnu-as doesn't recognize double-slash comments find %{buildroot}%{_usrsrc} -path '*riscv64*' -name '*.s' | xargs -n 1 sed -i 's:^//:#:' I put it at the end of %install, apparently hash comments are OK. Not sure which project to contact for this one. https://github.com/Dridi/dotfiles/commit/04f8a0aaab2581c095c383dcf1e38cb86b6154e1
Good news, hare 0.24.0 finally landed and the project is making it easier for Fedora and other distributions to plan breaking upgrades: https://harelang.org/blog/2024-02-16-hare-0.24.0-released/ It is essentially the same as the rc2, with one notable patch that I had picked up in my local packaging: https://git.sr.ht/~sircmpwn/hare/commit/f5118f8f7c45727296a96e0d50fda3431ae5d643 Meanwhile my own patch got merged despite not being signed off, presumably because it is trivial. And for my riscv64 fixup, it apparently concerned only one file and it was patched by someone else. So that's two patches from the master branch that can safely be applied to 0.24.0 on Fedora: - https://git.sr.ht/~sircmpwn/hare/commit/605a70a66aa6c34a0aee9929a54cfc9ed95575e8 - https://git.sr.ht/~sircmpwn/hare/commit/80e45e4d931a6e90d999846b86471cac00d2a6d5 I will update my local hare packaging to make sure these two are sufficient.