Hi,
I have built Milvus package on Copr and reviewed it with Fedora-review.
I fixed these items that are flagged as fail,but there are some items that are flagged as manual review needed. I am looking for someone who can help me review these items that need manual review.
Milvus package review request in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596
And I have two questions for the Fedora-review:
- The Fedora-review shows that: Package does not own files or directories owned by other packages, dirs in package are owned also by: /usr/lib/systemd(systemd), /usr/lib/systemd/system(systemd, plymouth), because i set the %dir /usr/lib/system and %dir /usr/lib/systemd/system in the spec file. But if I do not set this, it will show: No known owner of /usr/lib/systemd/system, /usr/lib/systemd.
- I set the field %license in my sep file, but the feodra-review show cannot run licensecheck,I am not sure how I am supposed to deal with this. Is this related to the version of fedora-review I installed? I installed it from the latest source code, https://pagure.io/FedoraReview. Or maybe it has to do with the mock buildroot I'm using, I used centos-stream-8-x86_64.
Lastly, I am always waiting for a reviewer to take my package reviewing.
Kind regards,
Yunmei Li.
From: "Benson Muite"<benson_muite@xxxxxxxxxxxxx>
Date: Wed, Feb 23, 2022, 16:42
Subject: Re: Self Introduction: Yunmei Li
On 2/23/22 6:42 AM, Yunmei LI wrote:
> Hi,
> Thanks for your help! I reworked the Milvus package for EPEL8 based on
> the comments I received, and updated theSpec URL and SRPMURL on
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2055596
>
> I am really lookingforward to someone reviewingMilvus package at the
> earliest convenience.
Not a review, but does it build on Copr[1] or Koji[2] ?
It may be helpful to check the Go SIG recommendations[3],[4].
You may also find OpenBuildService helpful[5].
[1] https://copr.fedorainfracloud.org/
[2] https://koji.fedoraproject.org/koji/
[3] https://fedoraproject.org/wiki/SIGs/Go
[4] https://fedoraproject.org/wiki/PackagingDrafts/Go
[5] https://openbuildservice.org/
>
> Thanks,
> Yunmei Li
> From: "Ben Beasley" >
> Date: Mon, Feb 21, 2022, 22:11
> Subject: Re: Self Introduction: Yunmei Li
> To: >
>
> All current versions of *Fedora* have CMake 3.20 or later, so you
> shouldn’t have any problems there.
>
> When packaging for EPEL, you rely on the package versions that were
> released with the corresponding version of Red Hat Enterprise Linux.
> RHEL aims to provide long-term stability, so these mostly get bugfix
> releases and security backports rather than significant updates over the
> life of the distribution. This is largely the same update philosophy as
> individual Fedora releases, but with a lifecycle on the order of a
> decade rather than a year. Since RHEL 7.0 was released in 2014, most of
> the packages you can use when building for EPEL7 are based on pretty old
> upstream versions.
>
> In most cases, if the dependency versions in a particular release of
> RHEL don’t meet your needs, it means that it is not practical to build
> your package for the corresponding version of EPEL. There are a few
> exceptions—for example, you can get a newer compiler toolchain by using
> one of the devtoolset releases, e.g. [1].
>
> If you can package for EPEL7 successfully, but only by doing things that
> don’t meet Fedora/EPEL guidelines (bundling dependencies without
> satisfying the conditions in [2], packaging your own
> newer-but-not-parallel-installable version of cmake to build with), then
> you might still be able to offer a package for EL7 distributions via
> COPR[3].
>
> You might find that EPEL8 or EPEL9 are still viable targets. You also
> might find that the epel-devel mailing list is a helpful place to ask
> questions.
>
> – Ben
>
> [1] https://src.fedoraproject.org/rpms/sleef/blob/epel7/f/sleef.spec
>
> [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling
>
> [3] https://docs.pagure.org/copr.copr/user_documentation.html#faq
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
