https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Bug ID: 2154514 Summary: Review Request: hare - The Hare programming language Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: timothee.floure@posteo.net QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-raw... SRPM URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-raw... 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: fnux
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Timothée Floure timothee.floure@posteo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|--- |If docs needed, set a value Depends On| |2154506
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2154506 [Bug 2154506] Review Request: harec - Hare boostrap compiler
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Depends On| |2154218
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2154218 [Bug 2154218] Review Request: harec - Hare compiler
https://bugzilla.redhat.com/show_bug.cgi?id=2154514 Bug 2154514 depends on bug 2154506, which changed state.
Bug 2154506 Summary: Review Request: harec - Hare boostrap compiler https://bugzilla.redhat.com/show_bug.cgi?id=2154506
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |DUPLICATE
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Flags| |fedora-review? Assignee|nobody@fedoraproject.org |benson_muite@emailplus.org CC| |benson_muite@emailplus.org
https://bugzilla.redhat.com/show_bug.cgi?id=2154514 Bug 2154514 depends on bug 2154218, which changed state.
Bug 2154218 Summary: Review Request: harec - Hare compiler https://bugzilla.redhat.com/show_bug.cgi?id=2154218
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Resolution|--- |RAWHIDE
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #1 from Benson Muite benson_muite@emailplus.org --- Tested qbe 0956b11331a8c0d5880fff1eb35e8f3ffdc452b8 harec d5d992c3 and hare ac4dfefc on Fedora Rawhide aarch64 and tests pass. A newer version of qbe than the release is required because of the 'blit' instruction. Can update the version of hare if versions of hare and qbe can be updated. It seems a 1.1 release of qbe is in preparation.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Benson Muite benson_muite@emailplus.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(timothee.floure@p | |osteo.net)
--- Comment #2 from Benson Muite benson_muite@emailplus.org --- qbe 1.1 is available https://c9x.me/compile/releases.html
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Timothée Floure timothee.floure@posteo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(timothee.floure@p | |osteo.net) |
--- Comment #3 from Timothée Floure timothee.floure@posteo.net --- I've just updated qbe - note that I am on long holiday until Mai/June, and mostly offline within that time.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #4 from Timothée Floure timothee.floure@posteo.net --- Spec URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-raw... SRPM URL: https://download.copr.fedorainfracloud.org/results/fnux/hare-lang/fedora-raw...
Now builds on aarch64 :-) Note that harec needs to be updated if we want to build the latest hare revision in rawhide (https://src.fedoraproject.org/rpms/harec/pull-request/2).
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Mike Rochefort mroche@omenos.dev changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mroche@omenos.dev
--- Comment #5 from Mike Rochefort mroche@omenos.dev --- I'm willing to take on maintainership of this project (qbe, harec, and hare) if it would be helpful. I have an updated build live on COPR that seems to be functional, but I would appreciate a review on it.
I've sent in PRs to the qbe and harec packages on s.fp.o, so besides their pending review, I would just need a review of the hare package:
SPEC: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid... SRPM: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid...
All three packages are build for both supported architectures, x86_64 and aarch64.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #6 from Maxwell G maxwell@gtmx.me --- I should be able to help review whichever package we want to go forward with.
Mike, note that the current config.mk is incorrect. The <ARCH>_AS, <ARCH>_CC, and <ARCH>_LD are used for cross compilation (hare has builtin support for cross compilation similar to go) and should be set to the appropriate binaries from cross-binutils and cross-gcc. See https://harelang.org/blog/2022-09-06-cross-builds-with-hare/.
``` AARCH64_AS = aarch64-linux-gnu-as AARCH64_CC = aarch64-linux-gnu-gcc AARCH64_LD = aarch64-linux-gnu-ld
RISCV64_AS = riscv64-linux-gnu-as RISCV64_CC = riscv64-linux-gnu-gcc RISCV64_LD = riscv64-linux-gnu-ld
<NATIVE_ARCH>_AS = as <NATIVE_ARCH>_CC = cc <NATIVE_ARCH>_LD = ld ```
You can look at Alpine's packaging for an example [1]. There is a separate config.${arch}.mk file for each architecture. `${arch}_<TOOL>` is always set to `<TOOL>` in `config.${arch}.mk` and then `<OTHER_ARCH>-<TOOL>` are set to the binaries from cross-binutils / cross-gcc.
I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.
You don't need the `%global elbuild` thing. Just run `%set_build_flags` unconditionally.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/hare
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #7 from Mike Rochefort mroche@omenos.dev ---
The <ARCH>_AS, <ARCH>_CC, and <ARCH>_LD are used for cross compilation
Ah, that makes a lot more sense. Thanks for the pointers there, I'll make those corrections.
I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.
As I haven't been playing super close attention, do you know if we have native riscv64 builders available for COPR builds? I can always kick off a scratch build, but it's nice to have things hosted somewhere as well for easy user testing.
You don't need the `%global elbuild` thing. Just run `%set_build_flags` unconditionally.
I was doing that initially but seeing the double output on Fedora builds was irking me 😆 If I'm the only one, I can set it back to that.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #8 from Maxwell G maxwell@gtmx.me --- You could probably do something like
``` %build [...] %{!?_auto_set_build_flags:%set_build_flags} [...] ```
instead of conditionalizing based on EPEL.
I would add best-effort support for riscv64 to the package as well for the sake of the Fedora RISCV project.
As I haven't been playing super close attention, do you know if we have native riscv64 builders available for COPR builds? I can always kick off a scratch build, but it's nice to have things hosted somewhere as well for easy user testing.
I'm not sure how to submit test builds for it. Fedora RISCV has its own Koji instance: http://fedora.riscv.rocks/koji/. It's not available in Copr. I would at least add a config for it and add it to ExclusiveArch even if you cannot run a test build.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Dridi Boukelmoune dridi.boukelmoune@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dridi.boukelmoune@gmail.com
--- Comment #9 from Dridi Boukelmoune dridi.boukelmoune@gmail.com --- May I suggest taking some inspiration from my local packaging of hare?
As of today it looks like this:
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd...
I solved the cross-compiling configuration and dependencies with Lua macros:
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd... https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd...
I also meant to make the qbe package install an RPM macro %{qbe_arches}:
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd...
But I did the work for my hare package:
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd...
The harec package should probably also expose a %{harec_arches} macro.
I also tried to extract linker flags from GCC LDFLAGS to feed the LDLINKFLAGS variable:
https://github.com/Dridi/dotfiles/blob/523fb5317185ce3da586ff82639e67de674cd...
It appears to work on my machine, but probably needs scrutiny.
There are other things to consider and off the top of my head I remember wanting to look at tzdata integration and never did.
Adding this is probably enough:
Requires: /usr/share/zoneinfo/leap-seconds.list
One strong recommendation I have is to separate the hare toolchain from the standard library. They have different licenses and purposes so that small complication simplify other things.
I tried to submit a patch upstream to make it easier to process module dependencies to add this to packaging, but my patch was conflicting with major ongoing refactoring, and until qbe and harec become recent-enough on my machine, I won't attempt a new patch. Right now my old rig is functional for my hare usage.
Hare packaging is currently not on my radar but I may remember other things now that it was brought up to my attention.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #10 from Dridi Boukelmoune dridi.boukelmoune@gmail.com ---
Adding this is probably enough:
Requires: /usr/share/zoneinfo/leap-seconds.list
Never mind, this is most likely not enough. The hare package should probably expose a %{hare_requires} macro with at least the above. All packages shipping hare programs should rely on having this file installed.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Fabio Valentini decathorpe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |decathorpe@gmail.com
--- Comment #11 from Fabio Valentini decathorpe@gmail.com --- (In reply to Dridi Boukelmoune from comment #10)
Adding this is probably enough:
Requires: /usr/share/zoneinfo/leap-seconds.listNever mind, this is most likely not enough. The hare package should probably expose a %{hare_requires} macro with at least the above. All packages shipping hare programs should rely on having this file installed.
Side note: Dependencies like this are discouraged (SHOULD NOT): https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directo...
And they will possibly be either broken or forbidden soon: https://pagure.io/fesco/issue/3097
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #12 from Maxwell G maxwell@gtmx.me ---
Side note: Dependencies like this are discouraged (SHOULD NOT)
Indeed.
This could simply be a Requires on tzdata. There is a no separate subpackage for /usr/share/zoneinfo/leap-seconds.list.
As for new `%{qbe_arches}` and `%{hare_arches}` macros, those should be added to redhat-rpm-config directly or a hare-srpm-macros package that's part of the default buildroot (I prefer the latter) so packaged can use `ExclusiveArch: %{hare_arches}`. That can be handled down the line.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #13 from Mike Rochefort mroche@omenos.dev ---
This could simply be a Requires on tzdata.
That's exactly what I did in my spec.
a hare-srpm-macros package that's part of the default buildroot
This is another thing I'm working on on the side, however I don't think this needs to be ready for the initial inclusion of Hare.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #14 from Mike Rochefort mroche@omenos.dev ---
I solved the cross-compiling configuration and dependencies with Lua macros
I have this fixed in my unpushed spec, but not using Lua. I don't think cross-compiling toolchains need to be installed by default or even as a recommends, so I have an optional -cross-compile-gnu subpackage that requires binutils and gcc for the correct non-native architectures.
The reason for the -gnu suffix is in the even that it is possible to use the llvm and clang utilities as a runtime override, then I'm giving it space to have a -cross-compile-llvm subpackage without needing to do any provides/obsoletes.
The config itself is still dynamically generated rather than having multiple architecture configs to select from, but it produces the correct output now.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #15 from Dridi Boukelmoune dridi.boukelmoune@gmail.com --- (In reply to Fabio Valentini from comment #11)
Side note: Dependencies like this are discouraged (SHOULD NOT): https://docs.fedoraproject.org/en-US/packaging-guidelines/ #_file_and_directory_dependencies
And they will possibly be either broken or forbidden soon: https://pagure.io/fesco/issue/3097
Hello Fabio!
Thanks for the heads up, I was aware of this policy but forgot about it. I was not aware of the incoming DNF change.
My main motivation is that the time::chrono module explicitly loads this file, and I remembered something about tzdata being split for containers (https://fedoraproject.org/wiki/Changes/tzdata-minimal) and this would have made the selection of the right package transparent. It looks like tzdata-minimal is gone on my f39 laptop, I was not aware of the change being reverted.
Not much time to follow changes these days...
(In reply to Mike Rochefort from comment #13)
This could simply be a Requires on tzdata.
That's exactly what I did in my spec.
This is not enough, Hare programs including the time::chrono module, even indirectly, need this file to be installed at run time.
Either a dependency generator can deduce that, or a %{hare_expires} macro is offered to all packages written in Hare. The precedent I'm aware of is %{systemd_requires} for having used it on $DAYJOB.
a hare-srpm-macros package that's part of the default buildroot
This is another thing I'm working on on the side, however I don't think this needs to be ready for the initial inclusion of Hare.
In my spec (for my current personal usage) I didn't bother making an SRPM sub-package, but I think this should be provided one way or another from the beginning.
(In reply to Maxwell G from comment #12)
As for new `%{qbe_arches}` and `%{hare_arches}` macros, those should be added to redhat-rpm-config directly or a hare-srpm-macros package that's part of the default buildroot (I prefer the latter) so packaged can use `ExclusiveArch: %{hare_arches}`. That can be handled down the line.
In my spec I made sure to distinguish between %{hare_build_arches} and %{hare_host_arches} as they may not always match. They currently don't.
(In reply to Mike Rochefort from comment #14)
I solved the cross-compiling configuration and dependencies with Lua macros
I have this fixed in my unpushed spec, but not using Lua. I don't think cross-compiling toolchains need to be installed by default or even as a recommends, so I have an optional -cross-compile-gnu subpackage that requires binutils and gcc for the correct non-native architectures.
The reason for the -gnu suffix is in the even that it is possible to use the llvm and clang utilities as a runtime override, then I'm giving it space to have a -cross-compile-llvm subpackage without needing to do any provides/obsoletes.
The config itself is still dynamically generated rather than having multiple architecture configs to select from, but it produces the correct output now.
How do you do that? The makefile that produces /usr/bin/hare with its default configuration for cross compilation, so from the sound of it you'd have to ship 3 hare binaries: one for the regular package and one for each cross toolchain.
Are you installing something like hare, hare-gnu and hare-llvm in %{_libdir}/hare/ and managing %{_bindir}/hare with update-alternatives?
As an end user this sounds like the opposite of the complications I'd want on day 1.
My 2 cents.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #16 from Mike Rochefort mroche@omenos.dev ---
This is not enough, Hare programs including the time::chrono module, even indirectly, need this file to be installed at run time.
As you said, that's something that can be handled by a dependency generator macro. For full transparency, right now I'm focusing on end-users being able to *use* Hare in Fedora, not maintainers packaging Hare authored software. If there needs to be a realignment on that, that's fine. I'm just focusing on what's absolutely needed for developers to start using the tool, and then performing incremental enhancements to round everything out.
How do you do that? The makefile that produces /usr/bin/hare with its default configuration for cross compilation, so from the sound of it you'd have to ship 3 hare binaries: one for the regular package and one for each cross toolchain.
I think we're talking past each other here a bit. The gnu/llvm split I mentioned would be contingent on Hare being able to accept build-time overrides for those tools. In looking through the Hare source, it doesn't seem like that's the case today, but it's a discussion I can start on the hare-dev list. And adding -gnu even if it's the only sub-package available just implies it's for the gcc/binutils cross-compile toolset considering Clang/LLVM don't require separate tooling to my knowledge.
[As a side note, both Alpine and your spec include a definition for arch-ar. I didn't see this referenced anywhere in the Hare source. I do see harec as giving the option of which archive tool to use for compiling its code, but that's it.]
As an end user this sounds like the opposite of the complications I'd want on day 1.
This just goes back to my earlier statement, I'm viewing things with two different end-users in mind: developers and package builders/maintainers. I have a number of things I'm thinking about from a macro standpoint, such as build and runtime dependency generators, a provides generator (for modules), and base variables. Right now I'm focusing on making it possible for a Fedora user to install and develop with Hare (hence my COPR).
I can continue to build things up that way if it's preferred and make sure the rpm/srpm macros are available as well before acceptance into Fedora, but in my opinion it would better to let people at least play with the technology and get involved in the language's ecosystem first.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #17 from Dridi Boukelmoune dridi.boukelmoune@gmail.com --- I guess I can't dissociate my developer self from my package maintainer self. I'm the kind of developer who ships "dist" archives and RPMs for $DAYJOB :)
Regarding AR in the toolchain, it went away in the big rewrite of the build driver, the same refactoring that made me postpone a patch that would greatly ease the generation of provides/requires for hare modules. I'm purposefully stuck at an old hare commit because I don't want to also maintain qbe and harec locally, but once your pull requests get merged I may catch up with Hare development. It's going to be painful though, already behind a couple hundred patches...
The reason why I wanted cross compilation working out of the box in my spec is inspired the hare command that manages all the dirty details on your behalf, so you don't use harec and the rest of the toolchain directly. I find it much more friendly than having to fail an attempt and then having to figure how to make it work.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #18 from Mike Rochefort mroche@omenos.dev ---
The gnu/llvm split I mentioned would be contingent on Hare being able to accept build-time overrides for those tools.
Based on a quick conversation on the hare-users[0][1] list, it appears that hare will respect the AS, LD, and CC environment variables at runtime, so the config.mk definitions are a convenience fallback in case environment variables aren't set.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #19 from Mike Rochefort mroche@omenos.dev --- Accidentally sent that early.
So the door is open to try and approach of having there be a -gnu and -llvm sub-meta-package that pulls in the desired toolchains (while defaulting to GNU components in the build config).
Alternatively, we could have the GNU toolset (explicitly stated or subpackage) be a recommends for the standard install, and have the LLVM toolchain be an available subpackage.
[0] https://lists.sr.ht/~sircmpwn/hare-users/%3C72c7169b-d8ca-43c4-ae32-b7056d72... [1] https://lists.sr.ht/~sircmpwn/hare-users/%3C82d9d0de-ab96-4c2d-ae72-93987363...
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #20 from Mike Rochefort mroche@omenos.dev --- Update to the latest commits as of last night for all three projects:
qbe-1.1^20231230.5af33410-1 harec-0.0.0^20231210.9d51b367-1 hare-0.0.0^20231228.f01c8eed-2
The hare package now provides the following RPMs
hare :: Required meta package with licensing and /usr/share/doc info hare-bin :: Executables and their man pages hare-src :: Hare standard library and root third-party directory hare-cross-compile-{gnu,llvm} :: Meta packages to obtain Hare cross compiling environments - GNU: binutils-{arch}-linux-gnu, gcc-{arch}-linux-gnu for non-%_arch packages, hare - LLVM: llvm, clang, lld, hare
Additionally I've added a convenience script to hare-bin, /usr/bin/harex. It is just a helper for running hare with non-GNU toolchains since they are already baked into the binary's config. It's controlled via the HARE_XCOMPILE_TOOLCHAIN environment var, presently looking for "llvm" as an accepted value. The only thing it sets are the AS, CC, and LD environment variables for a given run, and it checks if the user has defined any of those first before changing them. I tossed this in on a whim, but I have no qualms about removing it.
IMO, this is ready for inclusion in Fedora for end-users if approved, the next phase will be focused on making Hare code packager-friendly. But I'm still fully
The following two package PRs are required for Hare to build correctly:
https://src.fedoraproject.org/rpms/qbe/pull-request/1 https://src.fedoraproject.org/rpms/harec/pull-request/3
https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid... https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid...
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #21 from Mike Rochefort mroche@omenos.dev --- Did it again...
* But I'm still fully open to any and all feedback regarding the work done here.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #22 from Timothée Floure timothee.floure@posteo.net --- Hei Mike, thanks for your work. It looks good - but let's see the dependencies first.
As a side note: I'd rename the harex helper so that it doesn't look like it comes from upstream. Something around the line of `hare-cc-helper` or ``hare-fedora-cc-helper`?
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #23 from Mike Rochefort mroche@omenos.dev --- Update: Both qbe[0] and harec[1] merge requests are done and waiting to be merged.
Hare finally has tagged releases, to both harec and hare are now using 0.24.0-rc1 and are no longer snapshot based (goodbye logic!). In the future, the harec will be provided as part of the main hare package, so there will need to be some decisions made at that point how to handle the relationship between it and the bootstrap harec package. That and working on a hare-rpm-macros package are topics that would be a good starting place for a Hare SIG.
As for the harex helper, I've decided to scrap it. It adds an extra (long) variable that just masks setting AS, CC, and LD yourself. Arguably those belong in a build config at compile time, and exported or prepended in a shell for interactive compilation.
SPEC: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid... SRPM: https://download.copr.fedorainfracloud.org/results/mroche/hare/fedora-rawhid...
Alternative source view: https://pagure.io/mroche-copr-hare/hare
Final notes: the rpkg.conf is required for SCM builds on COPR to retrieve upstream tarballs; it will be removed if/when the package is approved for inclusion.
I have yet to do scratch builds on Fedora infra due to the QBE/harec requirements, but I do have F38, F39, Rawhide, and EPEL9 builds for x86_64 and aarch64 of all three packages in my COPR. Once the dependencies are fixed, I can take a look at verifying riscv64 builds.
[0] https://src.fedoraproject.org/rpms/qbe/pull-request/1 [1] https://src.fedoraproject.org/rpms/harec/pull-request/3
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #24 from Mike Rochefort mroche@omenos.dev --- A few quick followups:
1. It looks like 0.24.0 will GA on Wednesday (2024.02.07) barring any technical issues[0]. 2. I realized after sending the last message that Fedora does no officially support riscv64. So whenever Fedora gains mainline support for the architecture, the spec files will already be prepared.
[0] https://lists.sr.ht/~sircmpwn/hare-dev/%3CCYTMKCULMVED.2ECNTW09YAQZ8%40taiga...
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #25 from Maxwell G maxwell@gtmx.me --- Mike, can you please open a new review ticket for your package? You have to be the person who created the package review bug to be able to request a repo after the review is approved.
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
--- Comment #26 from Mike Rochefort mroche@omenos.dev --- Done: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2262452
https://bugzilla.redhat.com/show_bug.cgi?id=2154514
Maxwell G maxwell@gtmx.me changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |DUPLICATE Last Closed| |2024-02-05 05:29:02
--- Comment #27 from Maxwell G maxwell@gtmx.me --- Thanks, Mike! I'll close this as a duplicate for now to avoid confusion.
*** This bug has been marked as a duplicate of bug 2262452 ***
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com