automated rpm signing woes
by John Florian
What is the recommended solution for this these days? What is
fedoraproject.org using?
I presently have a setup using Sigul on CentOS 7 but that's leading to
my current problem of being unable to upgrade anything. I can't find
anything workable with CentOS 8, meanwhile my Koji Hub is stuck at
1.21.1 because I'm unaware of any newer builds via epel7. My Koji
Builders are now stuck at Fedora 33 because tasks fail if they have a
newer version of Koji than the Hub.
My attempts at moving Sigul to CentOS 8 Stream have just led to one bug
after another using the only build I could find, located at
https://kojipkgs.fedoraproject.org/repos-dist/epel$releasever-infra/lates....
I've fumbled my way through a few fixes and would be happy to contribute
when I can or, at least, report bugs. However, whenever I go to
https://pagure.io/sigul/, the apparent upstream for the project, I see
the last commit as 10 months ago, the last comment on any issue as 7
months ago, no issues closed, no PRs merged. Is it dead?
1 year, 3 months
Re: Mock v2.16 release, mock-core-configs v36.4
by Pavel Raiskup
On Tuesday, December 21, 2021 5:49:34 PM CET Maxwell G wrote:
> On Tuesday, December 21, 2021 8:22:55 AM CST Miro Hrončok wrote:
> > On 19. 12. 21 22:39, Pavel Raiskup wrote:
> > > On Sunday, December 19, 2021 10:22:57 PM CET Pavel Raiskup wrote:
> > >> So it seems that fedpkg doesn't (yet) know there's ~/.config/mock* at all.
> > >
> > > Proposed fix: https://pagure.io/rpkg/pull-request/595
> >
> > It seems that this would only fix the issue if the symbolic link has already
> > been created. But before that, `fedpkg --release epel8 mockbuild` would still
> > fail, wouldn't it? Can we fix that as well, even if it's fixed in some
> > documentation only?
>
> Yes, I think `fedpkg --release epel8 mockbuild` should print the same error
> message mock does when no default has been set, instead of defaulting to a
> non-functional koji config.
Fedpkg _automatically_ downloads the relevant Koji config ('koji
mock-config' variant, which is broken for normal users) when mock doesn't
ship the appropriate config file (it doesn't by default).
@onosek, would it be too bad if we made the Koji config download feature
opt-in in fedpkg? Something like 'fedpkg mockbuild --use-koji-mock-config'?
- when used, all local mock configuration is ignored
- when not used, 'mock -r epel-8-x86_64' even if the config doesn't exist,
which would automatically trigger the new Mock error message
Pavel
1 year, 5 months
Re: Mock v2.16 release, mock-core-configs v36.4
by Pavel Raiskup
On Sunday, December 19, 2021 4:55:28 PM CET Maxwell G via devel wrote:
> On Thursday, December 16, 2021 12:25:12 PM CST Pavel Raiskup wrote:
> > Hello!
> >
> > I'm glad I can announce that we have a new release of Mock. See the full
> > release notes [1]. The major change that happened is the removal of
> > 'epel-8' config files, as a follow-up for [2] discussion (and of course on
> > *devel lists, big thanks to everyone for the discussion).
> >
> > Note that this is is the last v2 release being shipped to all supported
> > Fedora/EPEL versions. From now on, we'll move to v3 with development (in
> > 'main' branch) and EPEL 7 stays on v2 (in 'mock-2' branch, bugfix only).
> >
> > [1] https://rpm-software-management.github.io/mock/Release-Notes-2.16
> > [2] https://pagure.io/epel/issue/133
> > [Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe
> > [Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2021-0947974f0a
> > [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-2d0f959e00
> > [EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-82ccb8f2b7
> >
> > Happy building!
> > Pavel
>
> I have tested this update and found a couple problems. Please see my comment on the Fedora 35 update page (linked above) or see below:
>
> > Hi @praiskup et. al,
> >
> > There are a couple problems:
> >
> > - `fedpkg --release epel8 mockbuild ` does not work properly. It defaults to
> > rhel8, which does not work by default and results in a 403 error when
> > dnf/mock attempts to install packages. After running `ln -s
> > /etc/mock/alma+epel-8-x86
Mock doesn't default to RHEL, there must be some other problem. I quickly tried
running that command, and fedpkg seems to create some temporary configuration
directory and defaults to building from Koji repos (aka `--enablerepo local`?).
Thank you for the report though, I will take a look. ATM I'm curious if this is
a bug in Mock ...
> _64.cfg ~/.config/mock/epel-8-x86_64.cfg`, it breaks entirely:
> >
> > ```
> > $ fedpkg --release epel8 mockbuild --no-cleanup-after
> > Not downloading already downloaded ansible-core-2.12.1.tar.gz
> >
> > setting SOURCE_DATE_EPOCH=1638921600
> > Wrote: /home/gotmax/Sync/git-repos/packaging/fedora_rpms/forks.repos/ansible.repos/ansible-core/ansible-core-2.12.1-2.el8.src.rpm
> >
> > mockbuild.exception.ConfigError: Could not find included config file: /tmp/epel-8-x86_64.v230b0w7mockconfig/templates/almalinux-8.tpl
> >
> > ERROR: Error in configuration
> > Could not execute mockbuild: Failed to execute command.
> > ```
> >
> > It is possible to override the buildroot with `--root alma+epel-8-x86_64`, but that is cumbersome and shouldn't be necessary.
> >
> > - Using `alma+epel-8-x86_64` works with `mock` itself and with `fedpkg` after applying the aforementioned fix, but mock/dnf repeatedly prints out the following error when installing packages: `Invalid configuration value: failoverm
> ethod=priority in /var/lib/mock/alma+epel-8-x86_64/root/etc/dnf/dnf.conf; Configuration: OptionBinding with id "failovermethod" does not exist`.
This is an innocent warning, new DNF will not pollute the stderr:
https://github.com/rpm-software-management/libdnf/pull/1276
> > - Even if I wanted to use the `rhel+epel-8-*` configs, they don't work at
> > all, as `subscription-manager` is broken (rhbz#1995465) and it is impossible
> > to obtain an entitlement.
This is unfortunate, I hope we can get an update soon.
> > In my opinion, this update should not be pushed until these crucial issues are fixed.
This all looks like the same issue. There's no "RHEL default", same as no
"Alma default". According to the previous discussion.
Thanks again,
Pavel
> > Thanks,
> >
> > Maxwell
>
>
>
1 year, 5 months
Re: Mock v2.16 release, mock-core-configs v36.4
by Miroslav Suchý
Dne 18. 12. 21 v 22:09 Nico Kadel-Garcia napsal(a):
> Discarding RHEL 7 and CentOS 7 for
> EPEL, and by implication Amazon Linux 2, will discourage people
> further from using RHEL based releases at all, I'd not consider it an
> encouragement to switch to RHEL 8. Commercial users are avoiding
> CentOS 8. Discarding EPEL 7 is salting the earth for existing users
> of RHEL 7 and CentOS 7.
????
No one is discarding RHEL/CentOS. Mock will stay there. No one is going to delete it.
RHEL/CentOS 7 will be still supported and will be maintained. Security and fatal changes will be backported.
We are just marking new moment in development and some features will land only into v3 which will not go to EPEL 7.
And you will be still able to build for EPEL 7. Even with from v3.
Mind the difference of supporting it as host platform (i.e. from where you run it) and target platform (for which OS you
are building).
So what is the problem?
Miroslav
1 year, 5 months
Re: Mock v2.16 release, mock-core-configs v36.4
by Neal Gompa
On Sat, Dec 18, 2021 at 4:16 AM Nico Kadel-Garcia <nkadel(a)gmail.com> wrote:
>
> On Thu, Dec 16, 2021 at 1:55 PM Pavel Raiskup <praiskup(a)redhat.com> wrote:
> >
> > Hello!
> >
> > I'm glad I can announce that we have a new release of Mock. See the full
> > release notes [1]. The major change that happened is the removal of
> > 'epel-8' config files, as a follow-up for [2] discussion (and of course on
> > *devel lists, big thanks to everyone for the discussion).
>
> Why would v3 not be available for EPEL ?
Mock v3 will be available for EPEL 8+ and Fedora. We are deliberately
removing RHEL 7 host support from Mock in Mock v3, so it won't be
available in EPEL 7. Mock v2 will remain in EPEL 7.
Personally, I think people are nuts to use RHEL as a build host,
because it makes things quite difficult to work forwards, but if
you're going to use RHEL as a build host, you should always use the
latest RHEL instead of the oldest, even if that version of RHEL isn't
in production in the rest of your infrastructure yet.
--
真実はいつも一つ！/ Always, there's only one truth!
1 year, 5 months