rmd bundles all its dependencies, but they are not listed as such. Some are (wrongly) listed as BuildRequires, but none are listed as "Provides: bundled(foo)". I don't know why dependencies are included as BuildRequires since they're not even used during the build process at all [0]. This gives a false sense of "security" since the package is not actually built against system-provided versions of those go packages. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling The .spec file must list "Provides: bundled(golang(github.com/foo/bar)) = version" for all bundled dependencies. Since go is a statically compiled language and this package contains a built go binary, the License tag for the main package must also list its effective license, e.g. the "union" of all Licenses of rmd and all the bundled dependencies. A license breakdown (which bundled dependency is available under which license) must be added to the spec file as well, and must be maintained and updated for the latest status with each package update. The syntax for this is similar to SPDX license identifiers. See: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_dual_licensing_scenarios and the following paragraphs. By the way: The way the "vendored" dependency tarball is generated is highly unusual and leads to other problems, e.g. it containing the entire git history of all dependencies, and it also contains some pre-built binaries that MUST be deleted in %prep (or even better, not included at all). I am unsure how this package was ever approved for fedora, since it violates both the Packaging Guidelines (bundling, Golang packaging, etc.) and also has legal issues (wrong or no licenses specified, includes prebuilt binaries in the sources, etc.). [0]: For how to build Golang pacakges correctly, see: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/
(In reply to Fabio Valentini from comment #0) > rmd bundles all its dependencies, but they are not listed as such. > Some are (wrongly) listed as BuildRequires, but none are listed as > "Provides: bundled(foo)". I don't know why dependencies are included as > BuildRequires since they're not even used during the build process at all > [0]. > > This gives a false sense of "security" since the package is not actually > built against system-provided versions of those go packages. > > See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling > > The .spec file must list "Provides: bundled(golang(github.com/foo/bar)) = > version" for all bundled dependencies. > > Since go is a statically compiled language and this package contains a built > go binary, the License tag for the main package must also list its effective > license, e.g. the "union" of all Licenses of rmd and all the bundled > dependencies. A license breakdown (which bundled dependency is available > under which license) must be added to the spec file as well, and must be > maintained and updated for the latest status with each package update. > > The syntax for this is similar to SPDX license identifiers. > See: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > LicensingGuidelines/#_dual_licensing_scenarios and the following paragraphs. > > By the way: The way the "vendored" dependency tarball is generated is highly > unusual and leads to other problems, e.g. it containing the entire git > history of all dependencies, and it also contains some pre-built binaries > that MUST be deleted in %prep (or even better, not included at all). > > I am unsure how this package was ever approved for fedora, since it violates > both the Packaging Guidelines (bundling, Golang packaging, etc.) and also > has legal issues (wrong or no licenses specified, includes prebuilt binaries > in the sources, etc.). > > [0]: For how to build Golang pacakges correctly, see: > https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ Hi, If I summarize on the issues mentioned above, 1. We need to add the bundled packages present in rmd-extra.pkg.tar.gz in rmd spec file as "Provides: bundled(golang(github.com/foo/bar)) = version" Example: Provides: bundled(golang(github.com/casbin/casbin)) = v1.9.1 >>Since go is a statically compiled language and this package contains a built go binary, the License tag for the main package must also list its effective license, e.g. the "union" of all Licenses of rmd and all the bundled dependencies. A license breakdown (which bundled dependency is available under which license) must be added to the spec file as well, and must be maintained and updated for the latest status with each package update. 2. I didnt understand clearly about the built-in go binary? What exactly are you referring to? We pull all the source code of different packages present in go.mod file and compile using Go compiler. Please clarify us so that we can fix the issues accordingly.
(In reply to ArunPrabhu Vijayan from comment #1) > Hi, > > If I summarize on the issues mentioned above, > > 1. We need to add the bundled packages present in rmd-extra.pkg.tar.gz in > rmd spec file as "Provides: bundled(golang(github.com/foo/bar)) = version" > Example: Provides: bundled(golang(github.com/casbin/casbin)) = v1.9.1 Exactly, this is what I mean. For bundled dependencies, you should not list them as BuildRequires, but list them as as Provided bundled(), like in your example above (though without the "v" version prefix). > >>Since go is a statically compiled language and this package contains a built go binary, the License tag for the main package must also list its effective license, e.g. the "union" of all Licenses of rmd and all the bundled dependencies. A license breakdown (which bundled dependency is available under which license) must be added to the spec file as well, and must be maintained and updated for the latest status with each package update. > > 2. I didnt understand clearly about the built-in go binary? What exactly are > you referring to? We pull all the source code of different packages present > in go.mod file and compile using Go compiler. > > Please clarify us so that we can fix the issues accordingly. sure, the go compiler builds rmd and all its dependencies and links them together in a statically linked binary. And because that results in the "rmd" package shipping all the code from both rmd *and* all its dependencies, you need to list the licenses that apply to all dependencies. You'll need to verify them all manually, list them separately in the spec file, and "compute" the correct License tag for the "union" of them.
(In reply to Fabio Valentini from comment #2) > (In reply to ArunPrabhu Vijayan from comment #1) > > Hi, > > > > If I summarize on the issues mentioned above, > > > > 1. We need to add the bundled packages present in rmd-extra.pkg.tar.gz in > > rmd spec file as "Provides: bundled(golang(github.com/foo/bar)) = version" > > Example: Provides: bundled(golang(github.com/casbin/casbin)) = v1.9.1 > > Exactly, this is what I mean. For bundled dependencies, you should not list > them as BuildRequires, but list them as as Provided bundled(), like in your > example above (though without the "v" version prefix). > > > >>Since go is a statically compiled language and this package contains a built go binary, the License tag for the main package must also list its effective license, e.g. the "union" of all Licenses of rmd and all the bundled dependencies. A license breakdown (which bundled dependency is available under which license) must be added to the spec file as well, and must be maintained and updated for the latest status with each package update. > > > > 2. I didnt understand clearly about the built-in go binary? What exactly are > > you referring to? We pull all the source code of different packages present > > in go.mod file and compile using Go compiler. > > > > Please clarify us so that we can fix the issues accordingly. > > sure, the go compiler builds rmd and all its dependencies and links them > together in a statically linked binary. > > And because that results in the "rmd" package shipping all the code from > both rmd *and* all its dependencies, you need to list the licenses that > apply to all dependencies. You'll need to verify them all manually, list > them separately in the spec file, and "compute" the correct License tag for > the "union" of them. Thanks for the clarification. Can you please provide some example go application or spec file doing a similar job. It would be of great help to do the same for RMD as well. All packages used in RMD are opensourced in github,golang.org or gopkg.
For example, caddy seems to handle this nicely: https://src.fedoraproject.org/rpms/caddy/blob/master/f/caddy.spec Though it does not change the License tag when switched to vendored dependencies (which it should). cri-tools does something similar, but also doesn't list licenses of bundled dependencies: https://src.fedoraproject.org/rpms/cri-tools/blob/master/f/cri-tools.spec grafana also bundles dependencies but also doesn't list their licenses: https://src.fedoraproject.org/rpms/grafana/blob/master/f/grafana.spec syncthing at least lists all licenses of its bundled dependencies: https://src.fedoraproject.org/rpms/syncthing/blob/master/f/syncthing.spec#_12
By the way, caddy has a nice way to generate the tarball of bundled sources: https://src.fedoraproject.org/rpms/caddy/blob/master/f/caddy.spec#_37 You should probably do it like that as well to avoid bundling up git histories and prebuilt binaries (which will also make the file much much smaller).
Hi, I also have one more doubt. We did the bundling of packages as per suggestions given in https://bugzilla.redhat.com/show_bug.cgi?id=1826621. [nhorman@hmswarspite SPECS]$ diff -u ~/1826621-rmd/srpm/rmd.spec ./rmd.spec --- /home/nhorman/1826621-rmd/srpm/rmd.spec 2020-05-19 13:51:10.014546923 -0400 +++ ./rmd.spec 2020-05-19 15:13:43.579637705 -0400 @@ -5,6 +5,7 @@ License: ASL 2.0 URL: https://github.com/intel/rmd Source0: https://github.com/arunprabhu123/rmd/blob/master/rmd-1.0.tar.gz +Source1: rmd-extra-pkgs.tbz2 BuildRequires: go BuildRequires: make @@ -61,8 +62,13 @@ %prep %setup -q - +mkdir app + %build +mkdir _pkg +tar -C _pkg -x -v -f %{SOURCE1} +find _pkg -type d -exec chmod 755 {} \; +export GOPATH=$PWD/_pkg:/usr/lib/golang make %{?_smp_mflags} %install Have you changed something in fedora related to the bundled exceptions?
> Have you changed something in fedora related to the bundled exceptions? No. You just got bad / wrong advice from your reviewer ... The package also doesn't follow the Packaging Guidelines for Go packages at all :( I would recommend something like the following steps: - download upstream sources (from https://github.com/intel/rmd, not from https://github.com/arunprabhu123/rmd ) - extract them - run "go vendor" (see: https://golang.org/cmd/go/#hdr-Make_vendored_copy_of_dependencies ) - compress the "vendor" directory into a version-dependent tarball - include it in the package and update the vendor tarball with these same steps for each upstream update - extract the vendor tarball after extracting the upstream sources and place the "vendor" directory inside the upstream source tree - this will make "go build" etc. use the bundled dependencies automatically - every time you update the vendor tarball, check the list of vendored dependencies (modules.txt), check their licenses, and update the "License" header accordingly I just tried to create the vendor tarball myself like this, and the rmd-vendor-0.2.1.tar.gz file I built is just 3.7 MB (which should also solve your problem with slow source uploads).
(In reply to Fabio Valentini from comment #7) > - run "go vendor" (see: Sorry, typo, that was meant to be "go mod vendor". It creates the "vendor" directory and a list of included packages (modules.txt), which is exactly what you need.
Hi, I updated as per your advice. Could you please review now. https://github.com/arunprabhu123/rmd/blob/master/rmd.spec https://github.com/arunprabhu123/rmd/blob/master/rmd-0.3-1.fc32.src.rpm Please let me know how to update the licence file? regards Arun
I'm not sure how this is better :( - still not using upstream tarball from https://github.com/intel/rmd - still not using separate vendored sources (created manually instead of automatically with "go mod vendor") - still not updated to use Golang packaging guidelines It's considered bad practice to host your own self-created tarballs for packaging. If at all possible (which it is in this case), please rely on the official sources from https://github.com/intel/rmd and only modify / augment with vendored sources as needed. You'll also probably be unable to use the upstream Makefile, since it runs the build in a way that's incompatible with how Go packages are expected to be built with fedora. It also overrides LDFLAGS etc. with values that are incompatible with the default build flags in fedora. Using the standard packaging macros for Go should make things much simpler (and actually make it use the correct LDFLAGS for fedora packages, which you can still augment with the arguments in https://github.com/intel/rmd/blob/master/scripts/build.sh#L54 ). As an example, here's how I'm doing that in the syncthing package: https://src.fedoraproject.org/rpms/syncthing/blob/9a6d7f9417e35f2c9e70bc9e0fb4d7f1bc2b4506/f/syncthing.spec#_255
sorry for some confusion. I will try to update again and send you an update.
if I understand you correctly, 1. upstream source tarball should be from release --> Source0:https://github.com/intel/rmd/archive/v0.3.tar.gz 2. I need to add in spec file like instead of doing go mod vendor? # golang.org/x/crypto : BSD Provides: bundled(golang(golang.org/x/crypto)) = 123391f 3. Can you please let me know what is missing in golang guidelines? 4. Should run the compilation directly from spec file instead of calling makefile?
(In reply to ArunPrabhu Vijayan from comment #12) > if I understand you correctly, > 1. upstream source tarball should be from release --> > Source0:https://github.com/intel/rmd/archive/v0.3.tar.gz Yes, exactly. > 2. I need to add in spec file like instead of doing go mod vendor? > # golang.org/x/crypto : BSD > Provides: bundled(golang(golang.org/x/crypto)) = 123391f No, you need to do both. > 3. Can you please let me know what is missing in golang guidelines? The Go Packaging Guidelines are pretty comprehensive, for example there are sections about how to correctly build and install golang binaries: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_packaging_a_binary_the_build_section > 4. Should run the compilation directly from spec file instead of calling > makefile? I think that will be easier than to add a downstream patch for the makefile. I see no reason to need special build machinery that's provided by the Makefile, using the packaging macros should not be too hard.
Hi Fabio, https://github.com/intel/rmd/pull/61 includes the following changes: 1.Change in how the go packages are bundled in the rmd.spec file. The license tag in the spec file also includes the licenses of the bundled dependencies. 2.The upstream tarball for rmd is from the intel/rmd repo. https://github.com/intel/rmd/archive/v0.3.1.tar.gz will be available once this pull request is merged. 3.Change in the makefile for make package command 4.The go.sum file is added. This file contains the checksum of direct and indirect dependency required along with the version. The checksum present in go.sum file is used to validate the checksum of each of direct and indirect dependency to confirm that none of them has been modified. 5.Change to avoid bundling of the git history of all dependencies in the srpm file. Could you please review the spec file changes and confirm if it addresses the issues in https://bugzilla.redhat.com/show_bug.cgi?id=1870539 ? Regards, Gargi
Hi Gargi, As far as I can tell, some things look much better with the linked PR. However, there are some remaining issues: 0) The Fedora dist-git is to be the considered the canonical source for a package's .spec file. Any changes must originate there: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity I suggest to actually use the pull-request workflow provided on src.fedoraproject.org to iterate on package .spec files. 1) The breakdown and list of bundled golang packages looks good, with one remaining issue: There's no need to list Licenses for BuildRequires and Requires which are not statically linked into the resulting package. Please drop the Licenses for pam-devel, systemd, and systemd-rpm-macros. If intel-cmt-cat-devel is statically linked into the resulting binary, keeping it is OK, otherwise, drop that one too. 2) I cannot judge the upstream tarball, as it does not exist yet. But it looks like it will miss bundled sources for golang dependencies, and the vendor tarball is gone from the .spec file. I should note again that this workflow is backwards from a distribution point of view. Upstream changes and releases come fist, downstream packaging changes come second. 3) The Makefile changes do not look like they address my concerns. I would rather see no Makefile used and building rmd with the standard Go packaging tooling provided by Fedora, which should also make sure that it uses the correct build flags (which is required for distribution-wide security hardening purposes). This requirement can only be dropped in exceptional cases, for example, when specific build flags break the software. 4) Adding go.sum and go.mod to the upstream repository is a good idea in general, but it won't help much with Fedora packaging other than for the packager to verify that the bundled sources are OK. 5) Yes, the git histories are gone, but as far as I can tell, source code for all dependencies is gone entirely ... --- Technical issues aside, I am wondering about what's going on with this package. The original reviewer and packager sponsor (who is now weirdly the main point of contact for the package?) should be taking the responsibility of guiding the original packager with fixing all those issues - because that's what a sponsor is for. But he was removed from the CC list of this bug without giving a reason. I am doing my best to help the guys from Intel with getting this right, but I am really not the one who should be doing this. There are others who are more up-to-speed with current Go packaging standards in Fedora. I reported the broken packaging problem because I stumbled upon it by "accident" while digging through Fedora 33 mass rebuilds failures, and not because I have any interest in this package or want to fix it myself. That's just not my job. (I'm not getting paid to work on Fedora at all, for that matter.)
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
Hi Fabio, Could you please review the change to build and install the rmd from the spec file without using the make package ? The change is available in : https://github.com/intel/rmd/pull/61/ The instructions to build from the spec file is shared in https://github.com/gargisau/rmd/blob/master/packaging/README.md . Since the upstream tar ball is not available yet, please follow the below mentioned steps. The tarball will be available after the RMD Release is done. 1.git clone https://github.com/gargisau/rmd.git Rename the folder to get the tar file name as v0.3.1.tar.gz: 2. mv rmd/ rmd-0.3.1/ 3. tar cvfz v0.3.1.tar.gz rmd-0.3.1/ 4. rpmdev-setuptree Copy the spec file and the tar file to the rpmbuild directory: 5.cp v0.3.1.tar.gz ~/rpmbuild/SOURCES/ 6.cp rmd-0.3.1/packaging/rmd.spec ~/rpmbuild/SPECS To build 7.rpmbuild -ba ~/rpmbuild/SPECS/rmd.spec To install: 8. yum install ~/rpmbuild/RPMS/x86_64/rmd-0.3.1-1.fc32.x86_64.rpm Regards, Gargi
Hi Fabio, If the changes are fine we will go forward to release this RMD change. Could you please help us in reviewing the changes? Thanks & Regards, Gargi
1. As Fabio has stated, the canonical location for Fedora packages is our dist-git. If you want to provide a spec file upstream, you can do so, but it doesn't really matter as far as our packaging. 2. The Makefile is irrelevant to us as well; you should use the Go macros https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/ You can use `go2rpm` to generate a spec that follows these guidelines, or read the examples on that page. 3. All of the packages you have marked as bundled are available in Fedora; you should drop the vendoring tarball, and just use the rmd one from GitHub _without_ vendored code, and then BuildRequires everything again. However, you should BuildRequire using the import path, as noted in the Guidelines. Again, using `go2rpm` will set this all up for you.
- BuildRequires: systemd should not be needed - You should follow https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation to create the user in %pre # rmd.sysusers #Type Name ID GECOS u rmd - "rmd user" g rmd - m rmd rmd r - 500-900 Source1: %{name}.sysusers […] %pre %sysusers_create_compat %{SOURCE1} - There only one missing package, github.com/prashantv/gostub, you should package it instead of bundling everything - No need to specify %{_builddir}/%{name}-%{version}/ when installing file, you are cd to that directory at the start of %build and %install - Can't you copy the whole etc/rpm to %{buildroot}%{_sysconfdir} instead of installing each file separately - I think you need a logrotate file for your log, see https://docs.fedoraproject.org/en-US/packaging-guidelines/#_logrotate_config_file - I'm not entirely sure what you do in %post and %preun but you should use macros for the directories - This is not necessary: rm -rf /etc/pam.d/rmd It is handled by the %files directive. - I don't think you should remove the log file on package removal rm -rf /var/log/rmd/ - Is this necessary: LOGFILE="/var/log/rmd/rmd.log" if [ ! -d ${LOGFILE%/*} ]; then mkdir -p ${LOGFILE%/*} chown $USER:$USER ${LOGFILE%/*} fi I would assume rmd would create its log file automatically - Can't you do that in install? Add the file in %files and it would be automatically removed. DBFILE="/var/run/rmd/rmd.db" if [ ! -d ${DBFILE%/*} ]; then mkdir -p ${DBFILE%/*} chown $USER:$USER ${DBFILE%/*} fi The shows should go in %files with %attr(-,rmd,rmd) - Same here: PAMSRCFILE="/etc/rmd/pam/rmd" PAMDIR="/etc/pam.d" if [ -d $PAMDIR ]; then cp $PAMSRCFILE $PAMDIR fi Do that in install. - I think it should go in install as well: DATA="\"logfile\":\"$LOGFILE\", \"dbtransport\":\"$DBFILE\", \"logtostdout\":false" gen_conf -path /etc/rmd/rmd.toml -data "{$DATA}" - these dirs should be owned: %dir %{_sysconfdir}/rmd/cert/ %config(noreplace) %{_sysconfdir}/rmd/cert/* %dir %{_sysconfdir}/rmd/acl/ %config(noreplace) %{_sysconfdir}/rmd/acl/* %config(noreplace) %{_sysconfdir}/rmd/*.toml %config(noreplace) %{_sysconfdir}/rmd/*.yaml %dir %{_sysconfdir}/rmd/pam/ %dir %{_sysconfdir}/rmd/pam/test/ %config(noreplace) %{_sysconfdir}/rmd/pam/test/rmd %config(noreplace) %{_sysconfdir}/rmd/pam/rmd - Use go2rpm to generate a draft of the SPEC: # Generated by go2rpm 1.3 %bcond_without check %global LOGFILE "%{_localstatedir}/log/rmd/rmd.log" %global DBFILE "%{_localstatedir}/run/rmd/rmd.db" # This package does not support big endian arch so far, # and has been verified only on Intel platforms. # HW support is documented in https://github.com/intel/rmd/blob/master/docs/Prerequisite.md %global go_arches %{ix86} x86_64 # https://github.com/intel/rmd %global goipath github.com/intel/rmd Version: 0.3.1 %gometa %global common_description %{expand: RMD is a system daemon providing a central interface for hardware resource management tasks on x86 platforms.} %global golicenses LICENSE %global godocs docs CHANGELOG.md README.md Name: rmd Release: 1%{?dist} Summary: Resource Management Daemon-RMD # Upstream license specification: Apache-2.0 License: ASL 2.0 URL: %{gourl} Source0: %{gosource} Source1: %{name}.sysusers BuildRequires: intel-cmt-cat-devel BuildRequires: pam-devel BuildRequires: systemd-rpm-macros BuildRequires: golang(github.com/casbin/casbin) BuildRequires: golang(github.com/emicklei/go-restful) BuildRequires: golang(github.com/fsnotify/fsnotify) BuildRequires: golang(github.com/globalsign/mgo) BuildRequires: golang(github.com/globalsign/mgo/bson) BuildRequires: golang(github.com/gobwas/glob) BuildRequires: golang(github.com/golang/glog) BuildRequires: golang(github.com/sirupsen/logrus) BuildRequires: golang(github.com/spf13/pflag) BuildRequires: golang(github.com/spf13/viper) BuildRequires: golang(golang.org/x/sys/unix) BuildRequires: golang(go.etcd.io/bbolt) %if %{with check} # Tests BuildRequires: golang(github.com/prashantv/gostub) BuildRequires: golang(github.com/smartystreets/goconvey/convey) %endif %description %{common_description} %prep %goprep sed -i "s|github.com/etcd-io/bbolt|go.etcd.io/bbolt|" $(find . -name "*.go" -type f) %build for cmd in cmd/* ; do %gobuild -o %{gobuilddir}/bin/$(basename $cmd) %{goipath}/$cmd done %install install -m 0755 -vd %{buildroot}%{_bindir} install -m 0755 -vp %{gobuilddir}/bin/* %{buildroot}%{_bindir}/ install -m 0755 -vd %{buildroot}%{_mandir}/man8 install -m 0644 -vp rmd.8 %{buildroot}%{_mandir}/man8 ln -sf %{_mandir}/man8/rmd.8 %{buildroot}%{_mandir}/man8/gen_conf.8 install -m 0755 -vd %{buildroot}%{_datadir}/%{name}/scripts install -m 0644 -vp scripts/setup_rmd_users.sh %{buildroot}%{_datadir}/%{name}/scripts install -m 0755 -vd %{buildroot}%{_unitdir} install -m 0644 -vp scripts/%{name}.service %{buildroot}%{_unitdir} install -m 0755 -vd %{buildroot}%{_sysconfdir}/ cp -aR etc/rmd %{buildroot}%{_sysconfdir}/ install -m 0755 -vd %{buildroot}%{_sysconfdir}/pam.d/ cp -aR etc/rmd/pam/rmd %{buildroot}%{_sysconfdir}/pam.d/ install -m 0755 -vd %{buildroot}%{_sysusersdir}/ install -m 0644 -vp %{SOURCE1} %{buildroot}%{_sysusersdir}/%{name}.conf install -m 0755 -vd %{buildroot}%{_localstatedir}/run/%{name} DATA="\"logfile\":\"%LOGFILE\", \"dbtransport\":\"%DBFILE\", \"logtostdout\":false" %{gobuilddir}/bin/gen_conf -path %{buildroot}%{_sysconfdir}/rmd/rmd.toml -data "{$DATA}" %if %{with check} %check %gocheck %endif %pre %sysusers_create_compat %{SOURCE1} %post %systemd_post %{name}.service %preun %systemd_preun %{name}.service %postun %systemd_postun_with_restart %{name}.service %files %license LICENSE %doc docs CHANGELOG.md README.md %{_bindir}/* %{_mandir}/man8/rmd.8.* %{_mandir}/man8/gen_conf.8.* %dir %{_sysconfdir}/rmd/cert/ %config(noreplace) %{_sysconfdir}/rmd/cert/* %dir %{_sysconfdir}/rmd/acl/ %config(noreplace) %{_sysconfdir}/rmd/acl/* %config(noreplace) %{_sysconfdir}/rmd/*.toml %config(noreplace) %{_sysconfdir}/rmd/*.yaml %dir %{_sysconfdir}/rmd/pam/ %dir %{_sysconfdir}/rmd/pam/test/ %config(noreplace) %{_sysconfdir}/rmd/pam/test/rmd %config(noreplace) %{_sysconfdir}/rmd/pam/rmd %config(noreplace) %{_sysconfdir}/pam.d/rmd %{_sysusersdir}/%{name}.conf %{_datadir}/%{name}/ %attr(-,rmd,rmd) %{_localstatedir}/run/%{name} %{_unitdir}/%{name}.service %changelog * Mon Jun 22 2020 ArunPrabhu Vijayan <arunprabhu.vijayan> - 0.3-1 - New release 0.3 * Thu Jun 04 2020 ArunPrabhu Vijayan <arunprabhu.vijayan> - 0.2.1-1 - RMD package version 0.2.1 I have not tested this SPEC beyond building it without the tests.
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days