Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: /etc/udev/rules.d is administrator territory. Please move the rules file to /usr/lib/udev/rules.d (aka %{_udevrulesdir}). Version-Release number of selected component (if applicable): aoetools-36-5.fc22.x86_64
OK. I'll start on this. Can you please provide a link to the doc you're referring to with %{_udevrulesdir}? I'd like to make sure I've read it.
Please see udev documentation: http://www.freedesktop.org/software/systemd/man/udev.html#Rules%20Files .
Can you please comment on backwards compatibility? I tried using %{_udevrulesdir} on RHEL 6.6 expecting it to expand, but it did not. I suppose that I could check whether it's defined. If it is not, then it's an older system, so I can set it to the old value for backwards compatibility.
It was added in systemd-196, after udev was merged with systemd. In RHEL6 there's no systemd and udev from before the merge. So this change should not be applied to rhel < 7. All current versions of Fedora are fine though (F20+).
OK. I had to rebuild a lot of my dev environment for fedoraproject, and now I'm delayed by the fedoraproject.org storage downtime, but I'm still working on this.
Does the RPM from this scratch build look good to you? https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981
Sorry for the late reply. (In reply to Ed Cashin from comment #6) > Does the RPM from this scratch build look good to you? > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 Nope. You need to add BuildRequires: systemd to have necessary macros defined. Also, %global should be used instead of %define (https://fedoraproject.org/wiki/Packaging:Guidelines#.25global_preferred_over_.25define). Also, there's left-over "echo ... > /tmp/_udevrulesdir". While you're at it, you might want to use %{!?_licensedir:%global license %%doc} %license COPYING to conform to new guidelines (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text).
(In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > Sorry for the late reply. > > (In reply to Ed Cashin from comment #6) > > Does the RPM from this scratch build look good to you? > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 > Nope. > > You need to add BuildRequires: systemd to have necessary macros defined. No, my intention was to leave that out, so that when the systemd macro is not there, it is set in the spec file to the backwards-compatible value. > Also, %global should be used instead of %define > (https://fedoraproject.org/wiki/Packaging:Guidelines#. > 25global_preferred_over_.25define). I'll check that out, thanks. > Also, there's left-over "echo ... > /tmp/_udevrulesdir". Yes, I got rid of that just after the scratch build. Sorry for the distraction. > While you're at it, you might want to use > %{!?_licensedir:%global license %%doc} > %license COPYING > to conform to new guidelines > (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text). I'll check that out as well, thanks.
(In reply to Ed Cashin from comment #8) > > (In reply to Ed Cashin from comment #6) > > > Does the RPM from this scratch build look good to you? > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 > > Nope. > > > > You need to add BuildRequires: systemd to have necessary macros defined. > > No, my intention was to leave that out, so that when the systemd macro is > not there, it is set in the spec file to the backwards-compatible value. You are using the old value everywhere, because nothing defines the new values. Check the koji build above. You have to use something like (untested): %if 0%{?fedora} || 0%{?rhel} >= 7 BuildRequires: systemd %endif
(In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > (In reply to Ed Cashin from comment #8) > > > (In reply to Ed Cashin from comment #6) > > > > Does the RPM from this scratch build look good to you? > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 > > > Nope. > > > > > > You need to add BuildRequires: systemd to have necessary macros defined. > > > > No, my intention was to leave that out, so that when the systemd macro is > > not there, it is set in the spec file to the backwards-compatible value. > You are using the old value everywhere, because nothing defines > the new values. Check the koji build above. > > You have to use something like (untested): > %if 0%{?fedora} || 0%{?rhel} >= 7 > BuildRequires: systemd > %endif It's defined with the syntax described here: https://www.redhat.com/archives/rpm-list/2002-January/msg00377.html ... when it isn't already defined. There must have been something wrong with the scratch build you saw. I've done another. I'll give you a new link. I don't want to embed knowledge of version info in there if there's a more simple way.
(In reply to Ed Cashin from comment #10) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > > (In reply to Ed Cashin from comment #8) > > > > (In reply to Ed Cashin from comment #6) > > > > > Does the RPM from this scratch build look good to you? > > > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 > > > > Nope. > > > > > > > > You need to add BuildRequires: systemd to have necessary macros defined. > > > > > > No, my intention was to leave that out, so that when the systemd macro is > > > not there, it is set in the spec file to the backwards-compatible value. > > You are using the old value everywhere, because nothing defines > > the new values. Check the koji build above. > > > > You have to use something like (untested): > > %if 0%{?fedora} || 0%{?rhel} >= 7 > > BuildRequires: systemd > > %endif > > It's defined with the syntax described here: > > https://www.redhat.com/archives/rpm-list/2002-January/msg00377.html > > ... when it isn't already defined. > > There must have been something wrong with the scratch build you saw. I've > done another. I'll give you a new link. No, everything is as expected. If you do not add BuildRequires: systemd, /usr/lib/rpm/macros.d/macros.systemd will not be in the build filesystem, and %_udevrulesdir will not be defined, and your package will use the fallback value. > I don't want to embed knowledge of version info in there if there's a more > simple way. No, there's is nothing like "BuildRecommends" :)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #11) > (In reply to Ed Cashin from comment #10) > > (In reply to Zbigniew Jędrzejewski-Szmek from comment #9) > > > (In reply to Ed Cashin from comment #8) > > > > > (In reply to Ed Cashin from comment #6) > > > > > > Does the RPM from this scratch build look good to you? > > > > > > > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=10036981 > > > > > Nope. > > > > > > > > > > You need to add BuildRequires: systemd to have necessary macros defined. > > > > > > > > No, my intention was to leave that out, so that when the systemd macro is > > > > not there, it is set in the spec file to the backwards-compatible value. > > > You are using the old value everywhere, because nothing defines > > > the new values. Check the koji build above. > > > > > > You have to use something like (untested): > > > %if 0%{?fedora} || 0%{?rhel} >= 7 > > > BuildRequires: systemd > > > %endif > > > > It's defined with the syntax described here: > > > > https://www.redhat.com/archives/rpm-list/2002-January/msg00377.html > > > > ... when it isn't already defined. > > > > There must have been something wrong with the scratch build you saw. I've > > done another. I'll give you a new link. > No, everything is as expected. If you do not add BuildRequires: systemd, > /usr/lib/rpm/macros.d/macros.systemd will not be in the build filesystem, > and %_udevrulesdir will not be defined, and your package will use the > fallback value. > > > I don't want to embed knowledge of version info in there if there's a more > > simple way. > No, there's is nothing like "BuildRecommends" :) OK, thanks for the explanation. I will try your untested suggestion soon.
I think your suggestion works as intended. I used mock locally to check that epel-7 has the new udevrulesdir and epel-6 uses the old dir. Then I did a koji build for rawhide, which looks good to me: https://kojipkgs.fedoraproject.org//work/tasks/6687/10286687/build.log http://koji.fedoraproject.org/koji/taskinfo?taskID=10244728 Please let me know whether this looks OK to you.
Yes, location of 60-aoe.rules in aoetools-36-9.fc23.x86_64.rpm is correct.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
So what's the status here?
(In reply to Zbigniew Jędrzejewski-Szmek from comment #16) > So what's the status here? Do I need to manually merge master into all the appropriate branches (f22, f21, ...)? I see that f23 has the fix. What branches do you recommend?
You committed the changes to the master branch, but you didn't build the changed version. https://apps.fedoraproject.org/packages/aoetools shows that 36-6.fc23 is the latest version. Please do a non-scratch build build for master (rawhide) and update f23 branch to the same place and also build there.
OK, thanks. That has been done.