12:25 p.m.
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
2:45 p.m.
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 ?
6:40 a.m.
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!
10 a.m.
On Sat, 2021-12-18 at 07:40 -0500, Neal Gompa wrote:
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.
Hi,
The reasoning is sound of what is being done currently, but to say people choosing to use
RHEL as
the base build platform as "nuts" is inappropriate, offensive and wrong. As a
person who is dealing
with mental health issues and quite bright, I take great offence at your assertion my
friend.
Please could you apologise for word usage please?
Regards
Phil
--
*** Playing the game for the games own sake. ***
WWW: https://kathenas.org
Twitter: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
10:34 a.m.
On Sat, Dec 18, 2021 at 11:00 AM Philip Wyett <philip.wyett(a)kathenas.org> wrote:
On Sat, 2021-12-18 at 07:40 -0500, Neal Gompa wrote:
> 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.
>
>
Hi,
The reasoning is sound of what is being done currently, but to say people choosing to use
RHEL as
the base build platform as "nuts" is inappropriate, offensive and wrong. As a
person who is dealing
with mental health issues and quite bright, I take great offence at your assertion my
friend.
Please could you apologise for word usage please?
I'm sorry for the word choice, I don't mean to be offensive in that regard.
--
真実はいつも一つ！/ Always, there's only one truth!
10:42 a.m.
On Sat, 2021-12-18 at 11:34 -0500, Neal Gompa wrote:
On Sat, Dec 18, 2021 at 11:00 AM Philip Wyett
<philip.wyett(a)kathenas.org> wrote:
> On Sat, 2021-12-18 at 07:40 -0500, Neal Gompa wrote:
> > 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.
> >
> >
>
> Hi,
>
> The reasoning is sound of what is being done currently, but to say people choosing
to use RHEL
> as
> the base build platform as "nuts" is inappropriate, offensive and wrong.
As a person who is
> dealing
> with mental health issues and quite bright, I take great offence at your assertion
my friend.
> Please could you apologise for word usage please?
>
I'm sorry for the word choice, I don't mean to be offensive in that regard.
Hi Neal,
Thank you for that. We all can make bad word choices on occasion and I admire you for
being a
person big enough to apologise. As my mother said "good, not perfect" and we all
make mistakes. You
have a great weekend and holidays.
Regards
Phil
--
*** Playing the game for the games own sake. ***
WWW: https://kathenas.org
Twitter: @kathenasorg
IRC: kathenas
GPG: 724AA9B52F024C8B
3:09 p.m.
On Sat, Dec 18, 2021 at 8:03 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
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.
Many are unhappy with RHEL 8 and especially with CentOS 8 switching to
CentOS 8 Stream without up front discussion, and have issued internal
policies not to use it at all. 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.
I agree that RHEL can be awkward as a build platform, but Folks who
want it can use local RHEL mirrors. I've published tools for years, at
https://github.com/nkadel/nkadel-rsync-scripts, to help people build
internal RHEL mirrors for just such usages. They're a useful basis for
snapshotting RHEL, CentOS 8 Stream and EPEL for locked internal
mirrors, and useful for setting EPEL to use "rsync -a" rather than
"rsync -a --delete" and and locally running "createrepo" to aggregate
rather than prune EPEL repos for rolling back individual components.
5:10 p.m.
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
12:40 a.m.
On Sat, Dec 18, 2021 at 6:14 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
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.
I'm afraid that "no one" is perhaps overstated. Various companies are
discarding CentOS since the CentOS 8 Stream fiasco, and questioning
their use of RHEL or CentOS at all. I've had several interviews lately
included evaluating the company use of RHEL/CentOS after their seeing
various issues with CentOS 8, more properly described in the CentOS
mailing lists. I'm a big uer of mock for multi-platform compilation,
I'd like to be able to use whichever build host in whatever standard
build server I get to work with.
For mock v3, that's not how I read your quote:
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.
EPEL typically deletes old versions of software when new releases are
published though perhaps not if the new version is simply never
backported to the old OS, I'd expect an unsupported mock v2 to go the
way o the dodo when v3 is released, even if it is only released for
RHEL 8 compatible EPEL and for Fedora.
The statement sounds at first glance like even building for CentOS 7
and RHEL 7 is being discarded from mock v3. If you're saying it will
support building for RHEL 7, mock v3 simply won't run on RHEL 7, OK,
that seems far more sensible. I'm sorry I misread that..
So what is the problem?
Miroslav
Various companies I've worked with seek to standardize on base
platforms. So do I personally, for my mock build environments. There
is a great deal to dislike about RHEL 8 and CentOS 8 for that base
platform for doing mock builds. If there is no technological reason,
I'd prefer to have any advances in mock, such as any features of v3
available on my CentOS 7 basic build servers. I'd consider using my
Fedora testing server as a build server, but I update that every 6
months, and hesitate to use Fedora itself as my build server.
1:35 a.m.
I see there is a more specific thread where just these issues have
been discussed. I'll take this over to
https://github.com/rpm-software-management/mock/issues/755 . to avoid
cluttering a general Fedora maliling list.
9:55 a.m.
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
_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`.
- 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.
In my opinion, this update should not be pushed until these crucial issues are fixed.
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
PGP Keyserver: hkp://keyserver.ubuntu.com
gotmax(a)e.email
2:56 p.m.
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
3:22 p.m.
On Sunday, December 19, 2021 9:56:20 PM CET Pavel Raiskup wrote:
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 ...
Ok, I see it now:
$ fedpkg -v mockbuild -N
Creating repo object from /home/praiskup/rh/packages/mock
Not downloading already downloaded mock-2.16.tar.gz
Srpm found, rewriting it.
Running: rpmbuild --define '_sourcedir /home/praiskup/rh/packages/mock' --define
'_specdir /home/praiskup/rh/packages/mock' --define '_builddir
/home/praiskup/rh/packages/mock' --define '_srcrpmdir
/home/praiskup/rh/packages/mock' --define '_rpmdir
/home/praiskup/rh/packages/mock' --define '_rpmfilename
%%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' --define 'dist
%{?distprefix}.el8' --define 'rhel 8' --eval '%undefine fedora'
--define 'el8 1' --nodeps -bs /home/praiskup/rh/packages/mock/mock.spec
setting SOURCE_DATE_EPOCH=1639612800
Wrote: /home/praiskup/rh/packages/mock/mock-2.16-1.el8.src.rpm
Mock config /etc/mock/epel-8-x86_64.cfg was not found. Going to request koji to create
new one.
...
^Z
[1]+ Stopped fedpkg -v mockbuild -N
$ cat /tmp/epel-8-x86_64.zbs7jxysmockconfig/epel-8-x86_64.cfg
# Auto-generated by the Koji build system
....
So this is basically a config you also get by:
$ koji mock-config --target epel8-candidate --arch x86_64
And this config can not work, since we don't have that repository locally
available. But, doing this (or alike):
sudo ln -s /etc/mock/rhel+epel-8-x86_64.cfg /etc/mock/epel-8-x86_64.cfg
... fixes the problem for me. So it seems that fedpkg doesn't (yet) know
there's ~/.config/mock* at all.
Pavel
3:39 p.m.
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
Pavel
8:22 a.m.
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:49 a.m.
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.
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
PGP Keyserver: hkp://keyserver.ubuntu.com
gotmax(a)e.email
2:36 a.m.
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
3:49 a.m.
On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote:
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
I'm trying to propose this:
https://pagure.io/rpkg/pull-request/597
$ fedpkg mockbuild
Not downloading already downloaded pspg-5.5.2.tar.gz
setting SOURCE_DATE_EPOCH=1639353600
Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg
ERROR: There are those alternatives:
ERROR:
ERROR: [1] alma+epel-8-x86_64
ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against AlmaLinux 8 repositories, together with the official EPEL
repositories.
ERROR: Project page: https://almalinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [2] centos+epel-8-x86_64
ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against CentOS Linux 8 repositories, together with the official EPEL
repositories.
ERROR: This will reach end-of-life in January 2021.
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [3] rhel+epel-8-x86_64
ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together with the
official EPEL repositories.
ERROR: This mimics what is done in the official EPEL build system, but you need a Red
Hat subscription:
ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [4] rocky+epel-8-x86_64
ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against Rocky Linux 8 repositories, together with the official EPEL
repositories.
ERROR: Project page: https://rockylinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
Could not execute mockbuild: Failed to execute command.
Pavel
9:22 a.m.
On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup <praiskup(a)redhat.com> wrote:
On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote:
> 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
I'm trying to propose this:
https://pagure.io/rpkg/pull-request/597
$ fedpkg mockbuild
Not downloading already downloaded pspg-5.5.2.tar.gz
setting SOURCE_DATE_EPOCH=1639353600
Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg
ERROR: There are those alternatives:
ERROR:
ERROR: [1] alma+epel-8-x86_64
ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against AlmaLinux 8 repositories, together with the official EPEL
repositories.
ERROR: Project page: https://almalinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [2] centos+epel-8-x86_64
ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against CentOS Linux 8 repositories, together with the official EPEL
repositories.
ERROR: This will reach end-of-life in January 2021.
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [3] rhel+epel-8-x86_64
ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together with the
official EPEL repositories.
ERROR: This mimics what is done in the official EPEL build system, but you need a Red
Hat subscription:
ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
ERROR:
ERROR: [4] rocky+epel-8-x86_64
ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
ERROR: Builds against Rocky Linux 8 repositories, together with the official EPEL
repositories.
ERROR: Project page: https://rockylinux.org/
ERROR: Enable permanently by:
ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
Could not execute mockbuild: Failed to execute command.
This is why I suggested that fedpkg needed the alias system instead of
mock in the EPEL discussion. fedpkg already has a config file format
for setting keys and values, so fedpkg should be extended to allow
people to set the distro prefix to search for with epel targets (e.g.
alma, rhel, centos-stream, etc.). Mock is basically the "dumb builder"
whereas fedpkg is the high-level packager Swiss Army Knife tool to get
stuff done.
--
真実はいつも一つ！/ Always, there's only one truth!
10:26 a.m.
On Wednesday, December 22, 2021 4:22:29 PM CET Neal Gompa wrote:
On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup
<praiskup(a)redhat.com> wrote:
>
> On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote:
> > 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
>
> I'm trying to propose this:
> https://pagure.io/rpkg/pull-request/597
>
> $ fedpkg mockbuild
> Not downloading already downloaded pspg-5.5.2.tar.gz
>
> setting SOURCE_DATE_EPOCH=1639353600
> Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg
> ERROR: There are those alternatives:
> ERROR:
> ERROR: [1] alma+epel-8-x86_64
> ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> ERROR: Builds against AlmaLinux 8 repositories, together with the official EPEL
repositories.
> ERROR: Project page: https://almalinux.org/
> ERROR: Enable permanently by:
> ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> ERROR:
> ERROR: [2] centos+epel-8-x86_64
> ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> ERROR: Builds against CentOS Linux 8 repositories, together with the official
EPEL repositories.
> ERROR: This will reach end-of-life in January 2021.
> ERROR: Enable permanently by:
> ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> ERROR:
> ERROR: [3] rhel+epel-8-x86_64
> ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together with the
official EPEL repositories.
> ERROR: This mimics what is done in the official EPEL build system, but you need
a Red Hat subscription:
> ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots
> ERROR: Enable permanently by:
> ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> ERROR:
> ERROR: [4] rocky+epel-8-x86_64
> ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> ERROR: Builds against Rocky Linux 8 repositories, together with the official
EPEL repositories.
> ERROR: Project page: https://rockylinux.org/
> ERROR: Enable permanently by:
> ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> Could not execute mockbuild: Failed to execute command.
>
This is why I suggested that fedpkg needed the alias system instead of
mock in the EPEL discussion. fedpkg already has a config file format
for setting keys and values, so fedpkg should be extended to allow
people to set the distro prefix to search for with epel targets (e.g.
alma, rhel, centos-stream, etc.). Mock is basically the "dumb builder"
whereas fedpkg is the high-level packager Swiss Army Knife tool to get
stuff done.
Well, my opinion is quite the opposite: IMO it would be better if
fedpkg/pyrpkg know *nothing* about mock configuration (location, etc.).
The fact that this logic is implemented in fedpkg/pyrpkg/rhpkg/etc. makes
this fix complicated. And searching for the available Mock configs will become
super complicated once we move the configs from /etc/mock to /usr/share).
Also note that I for one have never used 'fedpkg mockbuild' for real. I
use plain mock. That said, I find the error message quite appropriate in
Mock, too.
I have nothing against implementing it also in pyrpkg/fedpkg/etc., but
don't count with me on such a code duplication efforts :-)
Pavel
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
buildsys mailing list -- buildsys(a)lists.fedoraproject.org
To unsubscribe send an email to buildsys-leave(a)lists.fedoraproject.org
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/buildsys@lists.fedoraprojec...
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
11:01 a.m.
On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
On Wednesday, December 22, 2021 4:22:29 PM CET Neal Gompa wrote:
> On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup <praiskup(a)redhat.com> wrote:
> >
> > On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote:
> > > 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
> >
> > I'm trying to propose this:
> > https://pagure.io/rpkg/pull-request/597
> >
> > $ fedpkg mockbuild
> > Not downloading already downloaded pspg-5.5.2.tar.gz
> >
> > setting SOURCE_DATE_EPOCH=1639353600
> > Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> > ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg
> > ERROR: There are those alternatives:
> > ERROR:
> > ERROR: [1] alma+epel-8-x86_64
> > ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> > ERROR: Builds against AlmaLinux 8 repositories, together with the official
EPEL repositories.
> > ERROR: Project page: https://almalinux.org/
> > ERROR: Enable permanently by:
> > ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> > ERROR:
> > ERROR: [2] centos+epel-8-x86_64
> > ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> > ERROR: Builds against CentOS Linux 8 repositories, together with the
official EPEL repositories.
> > ERROR: This will reach end-of-life in January 2021.
> > ERROR: Enable permanently by:
> > ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> > ERROR:
> > ERROR: [3] rhel+epel-8-x86_64
> > ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> > ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together with
the official EPEL repositories.
> > ERROR: This mimics what is done in the official EPEL build system, but you
need a Red Hat subscription:
> > ERROR: https://rpm-software-management.github.io/mock/Feature-rhelchroots
> > ERROR: Enable permanently by:
> > ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> > ERROR:
> > ERROR: [4] rocky+epel-8-x86_64
> > ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
> > ERROR: Builds against Rocky Linux 8 repositories, together with the official
EPEL repositories.
> > ERROR: Project page: https://rockylinux.org/
> > ERROR: Enable permanently by:
> > ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
> > Could not execute mockbuild: Failed to execute command.
> >
>
> This is why I suggested that fedpkg needed the alias system instead of
> mock in the EPEL discussion. fedpkg already has a config file format
> for setting keys and values, so fedpkg should be extended to allow
> people to set the distro prefix to search for with epel targets (e.g.
> alma, rhel, centos-stream, etc.). Mock is basically the "dumb builder"
> whereas fedpkg is the high-level packager Swiss Army Knife tool to get
> stuff done.
Well, my opinion is quite the opposite: IMO it would be better if
fedpkg/pyrpkg know *nothing* about mock configuration (location, etc.).
The fact that this logic is implemented in fedpkg/pyrpkg/rhpkg/etc. makes
this fix complicated. And searching for the available Mock configs will become
super complicated once we move the configs from /etc/mock to /usr/share).
I agree here. fedpkg/pyrpkg should be disconnected from mock as much as
possible. This may not be achievable overnight, but it's something that I
think is worth pursuing. It should be easy to adapt fedpkg to build backends
other than mock and likewise it should be easy to change mock out for
something else if we ever deem that necessary.
Also note that I for one have never used 'fedpkg mockbuild'
for real. I use
plain mock. That said, I find the error message quite appropriate in Mock,
too.
Me either. I run mock by itself before ultimately submitting builds using
fedpkg.
I have nothing against implementing it also in pyrpkg/fedpkg/etc.,
but
don't count with me on such a code duplication efforts :-)
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
11:29 a.m.
On Thu, Jan 6, 2022 at 12:01 PM David Cantrell <dcantrell(a)redhat.com> wrote:
On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
>On Wednesday, December 22, 2021 4:22:29 PM CET Neal Gompa wrote:
>> On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup <praiskup(a)redhat.com>
wrote:
>> >
>> > On Wednesday, December 22, 2021 9:36:01 AM CET Pavel Raiskup wrote:
>> > > 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
>> >
>> > I'm trying to propose this:
>> > https://pagure.io/rpkg/pull-request/597
>> >
>> > $ fedpkg mockbuild
>> > Not downloading already downloaded pspg-5.5.2.tar.gz
>> >
>> > setting SOURCE_DATE_EPOCH=1639353600
>> > Wrote: /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
>> > ERROR: Could not find required config file: /etc/mock/epel-8-x86_64.cfg
>> > ERROR: There are those alternatives:
>> > ERROR:
>> > ERROR: [1] alma+epel-8-x86_64
>> > ERROR: Use instead: mock -r alma+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
>> > ERROR: Builds against AlmaLinux 8 repositories, together with the
official EPEL repositories.
>> > ERROR: Project page: https://almalinux.org/
>> > ERROR: Enable permanently by:
>> > ERROR: $ ln -s /etc/mock/alma+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
>> > ERROR:
>> > ERROR: [2] centos+epel-8-x86_64
>> > ERROR: Use instead: mock -r centos+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
>> > ERROR: Builds against CentOS Linux 8 repositories, together with the
official EPEL repositories.
>> > ERROR: This will reach end-of-life in January 2021.
>> > ERROR: Enable permanently by:
>> > ERROR: $ ln -s /etc/mock/centos+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
>> > ERROR:
>> > ERROR: [3] rhel+epel-8-x86_64
>> > ERROR: Use instead: mock -r rhel+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
>> > ERROR: Builds against Red Hat Enterprise Linux 8 repositories, together
with the official EPEL repositories.
>> > ERROR: This mimics what is done in the official EPEL build system, but
you need a Red Hat subscription:
>> > ERROR:
https://rpm-software-management.github.io/mock/Feature-rhelchroots
>> > ERROR: Enable permanently by:
>> > ERROR: $ ln -s /etc/mock/rhel+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
>> > ERROR:
>> > ERROR: [4] rocky+epel-8-x86_64
>> > ERROR: Use instead: mock -r rocky+epel-8-x86_64 --resultdir
/tmp/pspg/results_pspg/5.5.2/1.el8 --rebuild /tmp/pspg/pspg-5.5.2-1.el8.src.rpm
>> > ERROR: Builds against Rocky Linux 8 repositories, together with the
official EPEL repositories.
>> > ERROR: Project page: https://rockylinux.org/
>> > ERROR: Enable permanently by:
>> > ERROR: $ ln -s /etc/mock/rocky+epel-8-x86_64.cfg
/home/praiskup/.config/mock/epel-8-x86_64.cfg
>> > Could not execute mockbuild: Failed to execute command.
>> >
>>
>> This is why I suggested that fedpkg needed the alias system instead of
>> mock in the EPEL discussion. fedpkg already has a config file format
>> for setting keys and values, so fedpkg should be extended to allow
>> people to set the distro prefix to search for with epel targets (e.g.
>> alma, rhel, centos-stream, etc.). Mock is basically the "dumb
builder"
>> whereas fedpkg is the high-level packager Swiss Army Knife tool to get
>> stuff done.
>
>Well, my opinion is quite the opposite: IMO it would be better if
>fedpkg/pyrpkg know *nothing* about mock configuration (location, etc.).
>
>The fact that this logic is implemented in fedpkg/pyrpkg/rhpkg/etc. makes
>this fix complicated. And searching for the available Mock configs will become
>super complicated once we move the configs from /etc/mock to /usr/share).
I agree here. fedpkg/pyrpkg should be disconnected from mock as much as
possible. This may not be achievable overnight, but it's something that I
think is worth pursuing. It should be easy to adapt fedpkg to build backends
other than mock and likewise it should be easy to change mock out for
something else if we ever deem that necessary.
>Also note that I for one have never used 'fedpkg mockbuild' for real. I use
>plain mock. That said, I find the error message quite appropriate in Mock,
>too.
Me either. I run mock by itself before ultimately submitting builds using
fedpkg.
I always use "fedpkg mockbuild" because it takes care of things like
fetching sources and configuring a local resultdir and such. It's nice
sugar on top of Mock itself.
--
真実はいつも一つ！/ Always, there's only one truth!
1:05 p.m.
On 06. 01. 22 18:29, Neal Gompa wrote:
On Thu, Jan 6, 2022 at 12:01 PM David Cantrell
<dcantrell(a)redhat.com> wrote:
>
> On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
>> Also note that I for one have never used 'fedpkg mockbuild' for real. I
use
>> plain mock. That said, I find the error message quite appropriate in Mock,
>> too.
>
> Me either. I run mock by itself before ultimately submitting builds using
> fedpkg.
>
I always use "fedpkg mockbuild" because it takes care of things like
fetching sources and configuring a local resultdir and such. It's nice
sugar on top of Mock itself.
Exactly. I use `fedpkg mockbuild` all the time, because it is more convenient
for me. The fact that is uses the mock's configuration by default means that I
can later use mock directly to do stuff like shell in or install additional
packages.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5:18 a.m.
Dne 06. 01. 22 v 20:05 Miro Hrončok napsal(a):
On 06. 01. 22 18:29, Neal Gompa wrote:
> On Thu, Jan 6, 2022 at 12:01 PM David Cantrell <dcantrell(a)redhat.com>
> wrote:
>>
>> On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
>>> Also note that I for one have never used 'fedpkg mockbuild' for
>>> real. I use
>>> plain mock. That said, I find the error message quite appropriate
>>> in Mock,
>>> too.
>>
>> Me either. I run mock by itself before ultimately submitting builds
>> using
>> fedpkg.
>>
>
> I always use "fedpkg mockbuild" because it takes care of things like
> fetching sources and configuring a local resultdir and such. It's nice
> sugar on top of Mock itself.
Exactly. I use `fedpkg mockbuild` all the time, because it is more
convenient for me. The fact that is uses the mock's configuration by
default means that I can later use mock directly to do stuff like
shell in or install additional packages.
The automatic `--scrub=all` after build is no starter and bad default.
Also while the "resultsdir" might rarely be convenient, it would just
cluttered my harddrive most of the time.
Vít
5:30 a.m.
On 07. 01. 22 12:18, Vít Ondruch wrote:
Dne 06. 01. 22 v 20:05 Miro Hrončok napsal(a):
> On 06. 01. 22 18:29, Neal Gompa wrote:
>> On Thu, Jan 6, 2022 at 12:01 PM David Cantrell <dcantrell(a)redhat.com>
wrote:
>>>
>>> On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
>>>> Also note that I for one have never used 'fedpkg mockbuild' for
real. I use
>>>> plain mock. That said, I find the error message quite appropriate in
Mock,
>>>> too.
>>>
>>> Me either. I run mock by itself before ultimately submitting builds using
>>> fedpkg.
>>>
>>
>> I always use "fedpkg mockbuild" because it takes care of things like
>> fetching sources and configuring a local resultdir and such. It's nice
>> sugar on top of Mock itself.
>
> Exactly. I use `fedpkg mockbuild` all the time, because it is more convenient
> for me. The fact that is uses the mock's configuration by default means that
> I can later use mock directly to do stuff like shell in or install additional
> packages.
>
The automatic `--scrub=all` after build is no starter and bad default. Also
while the "resultsdir" might rarely be convenient, it would just cluttered my
harddrive most of the time.
I don't think ti scrubs all. It definitively does not scrub the bootstrap
chroot for example.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
6:35 a.m.
Dne 07. 01. 22 v 12:30 Miro Hrončok napsal(a):
On 07. 01. 22 12:18, Vít Ondruch wrote:
>
> Dne 06. 01. 22 v 20:05 Miro Hrončok napsal(a):
>> On 06. 01. 22 18:29, Neal Gompa wrote:
>>> On Thu, Jan 6, 2022 at 12:01 PM David Cantrell
>>> <dcantrell(a)redhat.com> wrote:
>>>>
>>>> On Wed, Dec 22, 2021 at 05:26:26PM +0100, Pavel Raiskup wrote:
>>>>> Also note that I for one have never used 'fedpkg mockbuild'
for
>>>>> real. I use
>>>>> plain mock. That said, I find the error message quite
>>>>> appropriate in Mock,
>>>>> too.
>>>>
>>>> Me either. I run mock by itself before ultimately submitting
>>>> builds using
>>>> fedpkg.
>>>>
>>>
>>> I always use "fedpkg mockbuild" because it takes care of things
like
>>> fetching sources and configuring a local resultdir and such. It's nice
>>> sugar on top of Mock itself.
>>
>> Exactly. I use `fedpkg mockbuild` all the time, because it is more
>> convenient for me. The fact that is uses the mock's configuration by
>> default means that I can later use mock directly to do stuff like
>> shell in or install additional packages.
>>
>
> The automatic `--scrub=all` after build is no starter and bad
> default. Also while the "resultsdir" might rarely be convenient, it
> would just cluttered my harddrive most of the time.
I don't think ti scrubs all. It definitively does not scrub the
bootstrap chroot for example.
I don't use bootstrap chroot, that might make some difference. Dunno.
Vít
8:28 a.m.
New subject: Mock v2.16 release, mock-core-configs v37
Hello folks.
I know the current Mock+configs Bodhi updates have not meet stable so far.
The main problem being resolved is that 'fedpkg mockbuild' on 'epel8'
checked-out branch doesn't work properly ATM. I was informed by @onosek
(maintainer, in CC) that fedpkg/rpkg release is being prepared though, so
this should be OK very soon.
But after a 1.5 month from the previous announcement, there comes yet another
mock-core-configs update. The major changes now:
- CentOS 8 mirroring is already disabled — so the _old_ epel-8 mock
configuration doesn't work anymore. Therefore we are moving the
'centos-8' configuration to eol/ subdirectory in mock-core-configs, and
that shouldn't be used for anything but experiments.
- Fedora 36 is going to be branched soon. Therefore we provide fedora-36
configs and fedora-rawhide configs point at "soon to be" 37. Don't
worry, F35, F36 and also Rawhide configs work even now when not yet
branched (though you need to ignore the dist tag in results).
Note that we probably _should_ [1] push this to stable now, as keeping the
old variant doesn't bring any good anymore. The update links stay (see
previous e-mail below), but in the meantime we shipped Mock in EPEL 9, so
there's the update link [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2049024
[2] [EPEL 9] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ccce8805ef
Pavel
On Thursday, December 16, 2021 7:25:12 PM CET 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
4:07 a.m.
New subject: Mock v2.16 release, mock-core-configs v37
On Wednesday, February 2, 2022 3:28:30 PM CET Pavel Raiskup wrote:
Hello folks.
I know the current Mock+configs Bodhi updates have not meet stable so far.
The main problem being resolved is that 'fedpkg mockbuild' on 'epel8'
checked-out branch doesn't work properly ATM. I was informed by @onosek
(maintainer, in CC) that fedpkg/rpkg release is being prepared though, so
this should be OK very soon.
But after a 1.5 month from the previous announcement, there comes yet another
mock-core-configs update. The major changes now:
- CentOS 8 mirroring is already disabled — so the _old_ epel-8 mock
configuration doesn't work anymore. Therefore we are moving the
'centos-8' configuration to eol/ subdirectory in mock-core-configs, and
that shouldn't be used for anything but experiments.
- Fedora 36 is going to be branched soon. Therefore we provide fedora-36
configs and fedora-rawhide configs point at "soon to be" 37. Don't
worry, F35, F36 and also Rawhide configs work even now when not yet
branched (though you need to ignore the dist tag in results).
Note that we probably _should_ [1] push this to stable now, as keeping the
old variant doesn't bring any good anymore. The update links stay (see
previous e-mail below), but in the meantime we shipped Mock in EPEL 9, so
there's the update link [2].
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2049024
[2] [EPEL 9] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-ccce8805ef
Last call for testing. We plan to push this update to stable on Monday,
unless already pushed-by-karma by that time (or some major blocker bugs are
found).
Pavel
Pavel
On Thursday, December 16, 2021 7:25:12 PM CET 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
>
802
days inactive
859
days old
27 comments
9 participants
participants (9)
-
David Cantrell -
Maxwell G -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Nico Kadel-Garcia -
Pavel Raiskup -
Philip Wyett -
Vít Ondruch