Mock v5.9 bugfix release

[Pavel Raiskup]

On pátek 27. září 2024 17:29:45, SELČ Pavel Raiskup wrote:
> On čtvrtek 26. září 2024 15:35:27, SELČ Pavel Raiskup wrote:
> > Hello maintainers!
> > 
> > I'm glad to announce the release of Mock v5.7, the chroot build
> > environment manager for building RPMs!
> > 
> > This update introduces a new mode for "hermetic" builds, a new
> > `--scrub-all-chroots` option to help clean Mock's `/var` data,
> > enhancements to the ccache plugin, several configuration updates, and
> > numerous bug fixes.
> > 
> > Full release notes:
> > 
> > https://rpm-software-management.github.io/mock/Release-Notes-5.7
> 
> Sorry for a weekend rush, but 5.7 was shipped with a broken chroot_scan
> plugin.  Here's a version 5.8
> 
> https://rpm-software-management.github.io/mock/Release-Notes-5.8
> 
> > The updated packages are in Bodhi (EPEL 10 and Fedora Rawhide went to 
> > stable already):
> > 
> > [Fedora 41]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-65d5599e38
> > [Fedora 40]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-90df40f12b
> > [Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3c60966886
> > [EPEL 9]: 
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-acc9bfc977
> > [EPEL 8]: 
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a0648ee6f1
> 
> I added new builds into those updates ^^^ (so the broken mock has not
> been actually shipped anywhere).

And, here we go - another issue (per report from one of those Bodhi
updates^^).  Bugfix went into release v5.9:
https://rpm-software-management.github.io/mock/Release-Notes-5.9

Pavel


signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.8 bugfix release

[Pavel Raiskup]

On čtvrtek 26. září 2024 15:35:27, SELČ Pavel Raiskup wrote:
> Hello maintainers!
> 
> I'm glad to announce the release of Mock v5.7, the chroot build
> environment manager for building RPMs!
> 
> This update introduces a new mode for "hermetic" builds, a new
> `--scrub-all-chroots` option to help clean Mock's `/var` data,
> enhancements to the ccache plugin, several configuration updates, and
> numerous bug fixes.
> 
> Full release notes:
> 
> https://rpm-software-management.github.io/mock/Release-Notes-5.7

Sorry for a weekend rush, but 5.7 was shipped with a broken chroot_scan
plugin.  Here's a version 5.8

https://rpm-software-management.github.io/mock/Release-Notes-5.8

> The updated packages are in Bodhi (EPEL 10 and Fedora Rawhide went to stable 
> already):
> 
> [Fedora 41]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-65d5599e38
> [Fedora 40]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-90df40f12b
> [Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3c60966886
> [EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-acc9bfc977
> [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a0648ee6f1

I added new builds into those updates ^^^ (so the broken mock has not
been actually shipped anywhere).

Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.7 released (and mock-core-configs v41.3)

[Pavel Raiskup]

Hello maintainers!

I'm glad to announce the release of Mock v5.7, the chroot build
environment manager for building RPMs!

This update introduces a new mode for "hermetic" builds, a new
`--scrub-all-chroots` option to help clean Mock's `/var` data,
enhancements to the ccache plugin, several configuration updates, and
numerous bug fixes.

Full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-5.7

The updated packages are in Bodhi (EPEL 10 and Fedora Rawhide went to stable 
already):

[Fedora 41]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-65d5599e38
[Fedora 40]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-90df40f12b
[Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-3c60966886
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-acc9bfc977
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-a0648ee6f1

Happy building!
Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

On pondělí 19. srpna 2024 10:23:09, SELČ Michael J Gruber wrote:
> Pavel Raiskup venit, vidit, dixit 2024-08-19 08:24:44:
> > Hello Michael,
> > 
> > On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote:
> > > Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
> > > > On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
> > > > > Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> > > > > > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup  
> > > > > > wrote:
> ...
> > > > > And I really think epel-* makes no sense since it's always "+" to
> > > > > something. EPEL guidelines spell out what is the official base distro
> > > > > for which EPEL (next or what not). That is something we could add next
> > > > > to the respective chroot in copr (just like the current remarks 
> > > > > there).
> > > > 
> > > > The 'epel-10' chroot in Copr and mock-core-configs makes sense for
> > > > user's convenience, and I believe we want to have it.  That's NB also
> > > > the default "dnf copr enable" choice on Enterprise Linux machines.
> > > 
> > > In mock-core-configs probably, because users don't have to look up which
> > > config is "for epel-9", e.g., or which release is "rawhide".
> > > 
> > > But there's a difference betwen mock and copr here:
> > > - If I built in mock f41 (last week) which is a link to rawhide I in
> > >   fact used the rawhide buildroot etc, not a copy of it. (disttag f41,
> > >   and methinks rawhide should link to f41, not vice versa, but that's a
> > >   different issue)
> > 
> > There was no f41 chroot in Copr until now (enabled them ~5 minutes ago,
> > you reminded me to do so, thanks!).
> > 
> > In a local mock build, yes.  The latest `mock-core-configs` update 
> > https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
> > did the change.
> > 
> > > - If I build in mock against chroots for linked mock configs I have
> > >   separate buildroots and builds.
> > > 
> > > I don't think we want the latter, but I may be wrong.
> > 
> > We do not enable the symlinked chroots in Copr, actually.  So this
> > should be fine?  I'm not sure I 100% understand your concern, so please
> > elaborate.
> 
> Mutual misunderstanding, I guess ;-)
> 
> What I meant was the following: Say we have two mock configs A and B
> which are "the same" (one links to the other), such as:
> 
> - fedora-rawhide and fedora-42 (as of now)
> - epel-7 and centos+epel-7 (now in eol)
> 
> Then local builds would use one buildroot for both A and B. OTOH, if
> copr offers A and B, then this would create 2 chroots and different
> builds.

Indeed.

> I (mis?)-understood your suggestion as having both A and B in copr in
> such cases. My suggestion was to offer, say, A only (not B) in copr and
> have "this is the same as B" as a description.
> 
> Looking at current state, we have for example:
> - mock core config: rhel+epel-9 (but no epel-9)
> - copr: epel-9 with description "Builds are done against RHEL + EPEL."
>   (but no rhel+epel)

/me nods

> So, if A="rhel+epel-9" and B="epel", we have A in mock core config (but
> not B) and B in copr with description "same as A". I guess it's almost
> what I suggest (with a mock config link from B to A missing).

Yeah, I think we originally wanted to created the link "by default" but
there was a community "agreement on disagreement" on which one should be
the default base distro (Alma/CentOS/Oracle/RHEL/Rocky).  I think this:

https://pagure.io/epel/issue/133

So instead, we implemented a helper method .. if you run
`mock -r epel-8-x86_64 ...` (or epel-9) for the first time on your local
machine, it offers you a creation of the desired "B => A" symlink :)

> Note that the status quo is different for centos-stream-9:
> - mock core config: centos-stream-9, centos-stream+epel-9, 
> centos-stream+epel-next-9
> - copr: centos-stream-9, centos-stream+epel-next-9

Indeed, we miss centos-stream+epel-9 in Copr.  Not sure it is worth
adding to Copr.  We don't necessarily add all the combinations, because
storage, because maintenance, ...

Pavel

> Cheers
> Michael
> 
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

Hello Michael,

On pátek 16. srpna 2024 11:31:15, SELČ Michael J Gruber wrote:
> Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
> > On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
> > > Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> > > > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup  
> > > > wrote:
> > > > >
> > > > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > > > to the "rhel+epel-*" chroots from `mock-core-configs` package.  We'd
> > > > > like to have the same approach for `epel-10` once there's a released
> > > > > variant of RHEL 10 GA.
> > > > >
> > > > > For now though, there's the variant `centos-stream+epel-10` in the new
> > > > > mock-core-configs release, though:
> > > > >
> > > > > 
> > > > > https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
> > > > >
> > > > > So we could make `epel-10-*` an alias to `centos-stream+epel-10` for 
> > > > > the
> > > > > time being, and do the switch to `rhel+epel-10` later on.  Do you 
> > > > > think
> > > > > this makes sense?  Or is it just too early?
> > > > >
> > > > 
> > > > For EPEL 10, we would never do that switch. CentOS Stream + EPEL is
> > > > the default case for EPEL 10 now. RHEL + EPEL configs are the
> > > > alternative.
> > 
> > Don't you have a documentation link for this?
> > 
> > > > So we would just have the alias and keep it "forever".
> > > 
> > > I think we're mixing "mock core config name" and "copr chroot name" in
> > > this dicussion.
> > 
> > One of the things Copr tries to do is to use mock-core-configs as-is
> > (unchanged);  while the previous epel-N chroots were tricky, the change
> > Neal mentioned seems to fix this!
> 
> We're on the same board here!
> 
> > > epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock.
> > > Everything else is explicit (centos-stream+epel, rhel+epel, ...).
> > > 
> > > The copr chroots epel-* etc always made me look twice what they actually
> > > are. Even switching the meaning "in between" makes it only.
> > 
> > Indeed, this is tricky.  Another best effort Fedora Copr goal was to
> > be as close to Fedora Koji as possible.  So if Koji builds particular
> > EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and
> > mock-core-configs, too) wants to do the same thing (even though by
> > default an official released set of packages is used instead of
> > pre-release official buildroot).
> 
> Yep!
> 
> > 
> > > And I really think epel-* makes no sense since it's always "+" to
> > > something. EPEL guidelines spell out what is the official base distro
> > > for which EPEL (next or what not). That is something we could add next
> > > to the respective chroot in copr (just like the current remarks there).
> > 
> > The 'epel-10' chroot in Copr and mock-core-configs makes sense for
> > user's convenience, and I believe we want to have it.  That's NB also
> > the default "dnf copr enable" choice on Enterprise Linux machines.
> 
> In mock-core-configs probably, because users don't have to look up which
> config is "for epel-9", e.g., or which release is "rawhide".
> 
> But there's a difference betwen mock and copr here:
> - If I built in mock f41 (last week) which is a link to rawhide I in
>   fact used the rawhide buildroot etc, not a copy of it. (disttag f41,
>   and methinks rawhide should link to f41, not vice versa, but that's a
>   different issue)

There was no f41 chroot in Copr until now (enabled them ~5 minutes ago,
you reminded me to do so, thanks!).

In a local mock build, yes.  The latest `mock-core-configs` update 
https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
did the change.

> - If I build in mock against chroots for linked mock configs I have
>   separate buildroots and builds.
> 
> I don't think we want the latter, but I may be wrong.

We do not enable the symlinked chroots in Copr, actually.  So this
should be fine?  I'm not sure I 100% understand your concern, so please
elaborate.

> > Can you give me the corresponding link to the EPEL guidelines?
> 
> I'm not sure whether the target base info is technically part of the
> policy in the policy page, but that's what I was thinking of:
> 
> https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy

Thanks.  It should document EPEL 10, too.  Requested here:
https://pagure.io/epel/issue/290

Pavel


> Cheers
> Michael
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

On čtvrtek 15. srpna 2024 15:44:26, SELČ Pavel Raiskup wrote:
> The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> to the "rhel+epel-*" chroots from `mock-core-configs` package.  We'd
> like to have the same approach for `epel-10` once there's a released
> variant of RHEL 10 GA.
> 
> For now though, there's the variant `centos-stream+epel-10` in the new
> mock-core-configs release, though:
> 
> https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
> 
> So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the
> time being, and do the switch to `rhel+epel-10` later on.  Do you think
> this makes sense?  Or is it just too early?

As previously discussed, EPEL 10 builds are designed to be built against
CentOS Stream 10 + EPEL, so enabling them in Copr right now should bring
no inconvenience.  I went ahead and enabled epel-10 chroots in Fedora
Copr.  Feel free to experiment!  Testing build:

https://copr.fedorainfracloud.org/coprs/praiskup/test-epel-10/build/7912610/

Enjoy the weekend, and happy building!
Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is it possible for Copr to use Bodhi build overrides?

[Pavel Raiskup]

On čtvrtek 15. srpna 2024 22:27:11, SELČ Florian Weimer wrote:
> * Peter Lemenkov:
> 
> > Hello All!
> > I have a few Bodhi build overrides and I love to use them in Copr. Is
> > it possible? At least is it possible to enable updates-testing
> > repository?
> 
> You can request a side tag and reference its repository in the Copr
> configuration.  The repositories have URLs like this one:
> 
>   
> 
> (I don't think I've ever tried this, but I don't see a reason why it
> wouldn't work, either.)

Yes, this would work!

NB. the particular overrides are added in the real Koji buildroot, which
itself may be accessed via baseurls (External Repositories in Copr)
like:

https://kojipkgs.fedoraproject.org/repos/f40-build/latest/x86_64/

(alternative to `mock -r fedora-40-x86_64 --enablerepo=local`)

Pavel



> Thanks,
> Florian
> 
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
> Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup  wrote:
> > >
> > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > to the "rhel+epel-*" chroots from `mock-core-configs` package.  We'd
> > > like to have the same approach for `epel-10` once there's a released
> > > variant of RHEL 10 GA.
> > >
> > > For now though, there's the variant `centos-stream+epel-10` in the new
> > > mock-core-configs release, though:
> > >
> > > 
> > > https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
> > >
> > > So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the
> > > time being, and do the switch to `rhel+epel-10` later on.  Do you think
> > > this makes sense?  Or is it just too early?
> > >
> > 
> > For EPEL 10, we would never do that switch. CentOS Stream + EPEL is
> > the default case for EPEL 10 now. RHEL + EPEL configs are the
> > alternative.

Don't you have a documentation link for this?

> > So we would just have the alias and keep it "forever".
> 
> I think we're mixing "mock core config name" and "copr chroot name" in
> this dicussion.

One of the things Copr tries to do is to use mock-core-configs as-is
(unchanged);  while the previous epel-N chroots were tricky, the change
Neal mentioned seems to fix this!

> epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock.
> Everything else is explicit (centos-stream+epel, rhel+epel, ...).
> 
> The copr chroots epel-* etc always made me look twice what they actually
> are. Even switching the meaning "in between" makes it only.

Indeed, this is tricky.  Another best effort Fedora Copr goal was to
be as close to Fedora Koji as possible.  So if Koji builds particular
EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and
mock-core-configs, too) wants to do the same thing (even though by
default an official released set of packages is used instead of
pre-release official buildroot).

> And I really think epel-* makes no sense since it's always "+" to
> something. EPEL guidelines spell out what is the official base distro
> for which EPEL (next or what not). That is something we could add next
> to the respective chroot in copr (just like the current remarks there).

The 'epel-10' chroot in Copr and mock-core-configs makes sense for
user's convenience, and I believe we want to have it.  That's NB also
the default "dnf copr enable" choice on Enterprise Linux machines.

Can you give me the corresponding link to the EPEL guidelines?

Pavel




> Cheers
> Michael
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
to the "rhel+epel-*" chroots from `mock-core-configs` package.  We'd
like to have the same approach for `epel-10` once there's a released
variant of RHEL 10 GA.

For now though, there's the variant `centos-stream+epel-10` in the new
mock-core-configs release, though:

https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1

So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the
time being, and do the switch to `rhel+epel-10` later on.  Do you think
this makes sense?  Or is it just too early?

Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: sysusers scriptlets: what to do if upstream includes the config files?

[Pavel Raiskup]

> There's a way around this: change the %sysusers_create_package stuff to 
use "%pre -f ".

Sorry for opening an old thread, but has anyone tried to do what Panu suggested?
Seems like we could:

%build
/usr/lib/rpm/sysusers.generate-pre.sh config-file > pre.file
%pre -f pre.file

The side benefit is that this would fail the build in case of any problem.
https://github.com/rpm-software-management/mock/pull/1367
Pavel
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

On čtvrtek 18. července 2024 3:48:30, SELČ Kevin Kofler via devel wrote:
> Pavel Raiskup wrote:
> > Have you considered to submit an RFE for this "Extend All" feature?
> > I think this convenience button (or even with API, if reasonably easy to
> > implement) sounds like an acceptable compromise to me.
> 
> I remember having once suggested that on this mailing list and having 
> received a quite negative reply from a Copr team member, saying that they 
> deliberately did not want to make it that easy to extend everything. But if 
> you think the RFE has a serious chance of being considered, I can file one.

Yes, I believe there are high chances to accept this (much harder will
to prioritize the feature).  If you know what you are doing, the point
should not be to make the prolonging process click-expensive - which it
admittedly is now, if you maintain dozens of long-term projects.  Note
that OTOH I still think that *we all* should actively push our users to
evacuate EOL Fedora releases.

IMO, the point is to keep the maintainer active, and get the response
periodically.  But sure, once we have the RFE, we'll have a proper place
to discuss it with the rest of the Copr team.

Pavel

> Kevin Kofler
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

On středa 17. července 2024 11:21:15, SELČ David Bold wrote:
> Adam Samalik wrote:
> > On Wed, 17 Jul 2024 at 10:54, Pavel Raiskup prais...@redhat.com wrote:
> > > On úterý 16. července 2024 15:22:56, SELČ Stephen Gallagher wrote:
> > > On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup prais...@redhat.com
> > > wrote:
> > > > [snip]
> > > > > Do you suggest moving rawhide to branched, and start with a fresh
> > > > > (empty)
> > > > > rawhide chroots for every branching?
> > > >
> > > > Yes, that was exactly what I was suggesting. (Well, possibly with
> > > > auto-triggering builds for the new chroot if the option to follow
> > > > Fedora branching is enabled).
> > >
> > > Starting from scratch would definitely be an alternative option (WRT to
> > > storage consumption), even more radical though.  Some of the projects in
> > > Copr require non-trivial bootstrapping procedures (not as complicated as
> > > Fedora itself, but still).
> >
> > What if you copied the latest build for each package to the "new"
> > rawhide chroot? That way all the builds should be able to continue
> > without bootstrapping as they do now, without having to store the
> > entire build history.
>
> But that would still keep those builds forever.

It would, indeed.  But wouldn't this be 100% equivalent to what we
already have?  Currently, when F41 branches from Rawhide, we do:

mkdir fedora-41-x86_64
ln fedora-rawhide-x86_64/foo.rpm fedora-41-x86_64/foo.rpm
...
createrepo_c fedora-rawhide-x86_64
... now we could rebuild the packages in rawhide, but not implemented ...

We _do not_ "branch" (link) all the RPMs in the repository, just the
latest versions (optimization from the time when we did `cp` instead of
`ln`, nowadays we could simply link everything I think).

What is proposed here is:

mv fedora-rawhide-x86_64 fedora-41-x86_64  # we need to avoid the race here!
mkdir fedora-rawhide-x86_64
cp fedora-41-x86_64/foo.rpm fedora-rawhide-x86_64
createrepo_c fedora-rawhide-x86_64
... now we could rebuild the packages as well ...

> Besides that, the branching would create additional chroots in the
> project.  I have a copr project that I only use for test builds, and I
> do not want additional chroots.

There's an opt-out knob for this feature, "follow fedora branching"

> Automatic branching would at some point either delete all my build,
> which is both annoying if I want to test multi-package changes as well
> as single package debugging, as in this case I cannot look at the
> build log of an hour ago.

We link all the files in the result directory, including log files.  On
top of that, you get the "forked" chroot build entry in web-UI, so
should be fine.

> I would like to have the options to delete all builds automatically
> after a month, instead I have to manually delete them.

Copr anyway keeps just the latest-greatesr NVR, so it's not a storage
concern itself.  I assume you are tired of seeing countless build
records in the web-UI - if so, please submit an RFE, or ideally send
us a patch!

> As far as I could see there is only an option to automatically delete
> the whole project, but not to delete builds after a given time.

Indeed.  Plus, per-package, you can set the max number of builds that
are being kept.

Pavel




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

On úterý 16. července 2024 15:22:56, SELČ Stephen Gallagher wrote:
> On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup  wrote:
>
> [snip]
>
> > Do you suggest moving rawhide to branched, and start with a fresh (empty)
> > rawhide chroots for every branching?
> 
> Yes, that was exactly what I was suggesting. (Well, possibly with
> auto-triggering builds for the new chroot if the option to follow
> Fedora branching is enabled).

Starting from scratch would definitely be an alternative option (WRT to
storage consumption), even more radical though.  Some of the projects in
Copr require non-trivial bootstrapping procedures (not as complicated as
Fedora itself, but still).

Automatic rebuilds - yes - sounds like a good RFE - but it wouldn't
solve the storage consumption problem (eventually, without the
ability to hardlink across chroots, the feature would consume even
more storage).  I thought we already have a ticket/RFE one for this, but
I can't find it...  But note, because of the bootstrapping issues above
- it would anyway be easier to start with "Fedora N-1" packages and
re-build everything against them, rather than start from scratch (or at
least have yet another option so user can choose the preferred rebuild
mode).

Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Why branched config pointed to rolling config?

[Pavel Raiskup]

On středa 14. února 2024 14:39:50, SELČ Mikhail Gavrilov wrote:
> Why branched config pointed to rolling config?
> 
> # ls -ln | grep fedora-40
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
> fedora-rawhide-aarch64.cfg
> lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
> fedora-rawhide-i386.cfg
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
> fedora-rawhide-ppc64le.cfg
> lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
> fedora-rawhide-s390x.cfg
> lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
> fedora-rawhide-x86_64.cfg

Seems that you need to update the mock-core-configs package

$ ls -alhs /etc/mock/fedora-41-x86_64.cfg 
0 lrwxrwxrwx. 1 root mock 25 čec 14 02:00 /etc/mock/fedora-41-x86_64.cfg -> 
fedora-rawhide-x86_64.cfg

Pavel

> 
> I build every day mesa snapshot, but today `mock -r fedora-rawhide-i386 ...` 
> beginning create packages of 41 branch. And I can't fix it by `mock -r 
> fedora-40-i386 ...` because 40 means rawhide now :(
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

Thank you for the reply, Kevin.

On úterý 16. července 2024 3:34:06, SELČ Kevin Kofler via devel wrote:
> Pavel Raiskup wrote:
> > This is a gentle heads-up (at least a year in advance) that we plan to
> > address Fedora Copr storage consumption related to Fedora Rawhide
> > builds.  Currently, Rawhide build results are kept indefinitely, but
> > this is going to change in the future.
> >
> > For the full story, see the blog post:
> > https://fedora-copr.github.io/posts/cleanup-rawhide-builds
> >
> > TL;DR: We plan to start monitoring build activity in Copr projects.
> > If no builds appear for a long time in these "rolling" chroots (such as
> > Fedora Rawhide), we'll disable such chroots, preserve the built results
> > for a while, and then delete them if no action is taken by the user.
> >
> > Hope this isn't going to cause too much inconvenience.  Feel free to
> > discuss this here or under the blog post.
>
> So Copr is going even further with this broken approach of deleting user
> data to "address storage consumption". As I have already stated several
> times, deleting user data by default (on an opt-out basis) is NEVER
> acceptable.
>
> Even more so if the opt-out requires one to fight Copr's dark patterns
> deliberately making it a pain in the neck: One has to log into Copr every so
> often, and each time click a whole bunch of "Extend" buttons one at a time.
> There is no way to opt out permanently nor even for a longer time period
> than the default, nor even an "Extend All" button.

Have you considered to submit an RFE for this "Extend All" feature?
I think this convenience button (or even with API, if reasonably easy to
implement) sounds like an acceptable compromise to me.

Pavel

> The real issue still appears to be that "Disk storage is the commodity that
> incurs the highest cloud costs.", which means that cloud might not be the
> right technology to use here. Or at least the particular cloud
> implementation you are using (which last I checked was from Amazon). I
> understand that (also last I checked) the cloud infrastructure was donated
> to you for free. But that donation is not of much use if it does not include
> a workable amount of storage for something like Copr nor an offer to extend
> the storage at a reasonable price (which Amazon's list price is apparently
> not).
>
>
> Kevin Kofler
>
>



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

On pondělí 15. července 2024 16:32:45, SELČ Stephen Gallagher wrote:
> On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý  wrote:
> >
> > Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
> >
> > Instead of always keeping "Rawhide" around as a separate buildroot,
> > why not just rename it at Branching and then create a NEW Rawhide
> > chroot?
> >
> > 1) Different workflow compared to the one we have in Fedora.
> 
> How do you mean?
>
> > 2) Create it with what? Empty content ("why you are forcing be to rebuild 
> > everything")? Copy everything (you end up in the same situation)? Rebuild 
> > packages from previous rawhide (what if it fails to build? what if it 
> > succeed but no one uses it anyway?).
> 
> Let me flip it around: how did you create "Fedora 40" when Rawhide
> branched for that? I'm just saying to do it the other way around.

Actually, I think the current Copr process is similar to what Fedora
does.  We hardlink the RPMs to branched chroot and run createrepo_c
(unless user decides this is unwanted behavior, and opts-out).
There's no need to re-sign the RPMs, sure - as the signature is shared
for all the project's chroots.

Do you suggest moving rawhide to branched, and start with a fresh (empty)
rawhide chroots for every branching?

Pavel


signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

On pondělí 15. července 2024 12:10:58, SELČ Sandro via devel wrote:
> On 15-07-2024 10:24, Pavel Raiskup wrote:
> > TL;DR: We plan to start monitoring build activity in Copr projects.
> > If no builds appear for a long time in these "rolling" chroots (such as
> > Fedora Rawhide), we'll disable such chroots, preserve the built results
> > for a while, and then delete them if no action is taken by the user.
> 
> Thanks for the very early heads up. Will you provide more details 
> regarding build retention? Without it it's kinda hard to judge the impact.
> 
> I can think of at least one project I'm looking after that won't see 
> many updates. It's kind of there for convenience.

Thank you for the reply.

The current idea is to have a 6-months period of inactivity (when no
build appears in given rolling chroot), then another 6-months period
when we keep the build results, but we notify the user about the future
removal (e-mail, and web-UI hints).  Then (if no action taken) remove
the chroot/build results.

> I'm regularly using the _delete after_ option as well as _max number of 
> builds_ for packages being automatically rebuilt. I'd like to see a 
> project wide option allowing me to specify max builds to keep regardless 
> of age or an option to rebuild for rawhide when its associated release 
> is incremented. The latter sounds more difficult to implement and may 
> have unintended side effects if not thought through.

Sure, there's an "epic" issue https://github.com/fedora-copr/copr/issues/2541
that would probably cover your configuration use-case.  If you need
something peculiar, feel free to submit RFE (or patch, that's
preferred).

Pavel


> -- Sandro
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

Hello maintainers.

This is a gentle heads-up (at least a year in advance) that we plan to
address Fedora Copr storage consumption related to Fedora Rawhide
builds.  Currently, Rawhide build results are kept indefinitely, but
this is going to change in the future.

For the full story, see the blog post:
https://fedora-copr.github.io/posts/cleanup-rawhide-builds

TL;DR: We plan to start monitoring build activity in Copr projects.
If no builds appear for a long time in these "rolling" chroots (such as
Fedora Rawhide), we'll disable such chroots, preserve the built results
for a while, and then delete them if no action is taken by the user.

Hope this isn't going to cause too much inconvenience.  Feel free to
discuss this here or under the blog post.
Pavel


signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Duplicate NEVRAs in Copr repositories - future breakage

[Pavel Raiskup]

Hello maintainers,

the Copr project is in the process of implementing the PULP storage
backend (RPM repo management technology):

https://github.com/fedora-copr/copr/issues/2533

We expect that this change will be slow and incremental (we will not move
all projects to PULP at once) and that it is going to be almost an 1:1
replacement.  See that tracker link above if you want more info.

There's one technical detail/change that seems to be clear right now and
is worth announcing in advance - the way we handle the duplicate NEVRAs in
the same repos is going to change (a bit).  Before or after the switch,
Copr simply allows you to build packages with the same/duplicate NEVRAs
into the same repository.  There's no reason to fail the build process.

The current (old) behavior though is that Copr keeps all the duplicates in
the RPM repository - and DNF is confused (when asked to install one of
such duplicate NEVRAs, it picks one of them by random, or by package ID,
or it is DNF version specific behavior, or - I don't really now).  Project
administrators can then come anytime later and decide which particular
build ID they want to keep, and delete the rest of the duplicate builds.
So the confusion can be resolved pretty easily.

The new (with PULP) behavior will be that the newer duplicates
will override the previous - this is on one hand good, because DNF
is not confused - always sees the latest "duplicate" NEVRA to install.
But on the other hand this also means that, when the latest NEVRA build is
removed, Copr will drop the NEVRA from the metadata (it will not present
the older builds).

This is just a headsup for you, feel free to comment here or ideally in
the corresponding Copr issue

https://github.com/fedora-copr/copr/issues/3262

Thank you, and happy building!

P.S. When you build only for the purpose of building (to check there's no
FTBFS) you are not affected.  If you bump Release regularly (you should),
you won't be affected.

Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Disabling Fedora 38 chroots in Copr

[Pavel Raiskup]

Hello,

tl;dr, we have just disabled Fedora 38 chroots in Copr.

According to the Fedora wiki [1], Fedora 38 reached the end
of its life [4] and therefore we are disabling it in Copr.

That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots:

- fedora-38-x86_64
- fedora-38-i386
- fedora-38-ppc64le
- fedora-38-aarch64
- fedora-38-armhfp
- fedora-38-s390x

Additionally, according to Outdated chroots removal policy [2], Copr is
going to preserve existing build results in those chroots for another
180 days and then automatically remove them unless you take an action
and prolong the chroots life span in your projects.  Read more about
this feature in the  Copr - Removing outdated chroots blog post [3].

[1] https://fedoraproject.org/wiki/End_of_life
[2] https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots
[4] https://fedorapeople.org/groups/schedule/f-40/f-40-all-tasks.html

Pavel


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Pavel Raiskup]

On sobota 13. dubna 2024 21:04:06, CEST Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Apr 13, 2024 at 01:38:49PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote:
> > > On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
> > >  wrote:
> > > >
> > > > Yes. But actually I think Rust is the optimal choice here. Writing
> > > > this in Python would be possibly slightly nicer, but we don't want
> > > > to pull the interpreter and packages into the buildroot. Python
> > > > also has the problem (challenge?) that it needs to be bootstrapped
> > > > once per year. The less packages are involved in the bootstrap, the
> > > > easier it is. And if the brp was written in Python, we'd need to
> > > > deal with that, and it would probably increase the number of builds
> > > > which are done without the cleanup. Having this as an indepedent
> > > > binary avoids some of the issues with bootstrap.
> > > 
> > > I think Rust *would* be a good choice here ...
> > > BUT add-determinism uses pyo3 to link to CPython, so it pulls in
> > > python3-libs anyway.
> > > So you get the downsides of pulling in Python without the upsides of
> > > using Rust ...
> > 
> > Yes, it currently pulls in python3-libs as a dependency, but not the
> > rest of the Python stack. Ideally, the dependency on python3-libs will
> > become optional, and we'll use it if found at runtime if found and
> > ignore otherwise. (Anything that creates pyc files will have python
> > installed, so it's fine if the pyc handler only works if there.)
> > How to best do this is something that needs to be figured out…
> 
> https://github.com/keszybz/add-determinism/pull/1 makes the dependency
> on libpython optional. One option would be to compile the binary
> twice, and use rich dependencies to install the heavyweight one if
> python3 is installed. If somebody has a better approach, I'm all ears.

I do not claim these are better approaches, but you could:

- you could consider using tooling "from host", not "from chroot"
  (adding a dependency to Mock seems just fine then)

- use dynamic buildrequires to detect what plugins are needed

Pavel

> Zbyszek
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: convert everything to rpmautospec?

[Pavel Raiskup]

On neděle 7. dubna 2024 17:15:16 CEST Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)

I'm -1 here.

I'm also -1 for baking the "actual build source data" into a git-log
history, instead of just plain checkout.  One of the reasons:
https://pagure.io/fedora-infra/rpmautospec/issue/227

Then retro: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2G6OSOSM76O2V6K4COIE2QHNXIBSXPFR/

1. git-log is not a %changelog, "generated like we do it" it has close
   to zero value.  Can we finally state that %changelog is not needed?
   Or just point at forge's git-log?

2. Release could be made build-system specific, and IMO _should_ be.

Pavel

> Zbyszek
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.5 released (and mock-core-configs v40.1)

[Pavel Raiskup]

Hello maintainers!

Let me announce a new release of Mock v5.5, the chroot build environment
manager for building RPMs.

First and foremost, this update ships with updated
mock-core-configs v40.1, bringing Fedora 40 configs as "branched"
separately from Fedora Rawhide (Fedora 41 now equals to Fedora Rawhide).

The Mock 5.5 release then mostly brings a few important bug-fixes (fix
for bash-completion multi-argument options, fixing in-chroot file and
process group ownership, root_cache invalidation by configuration
changes), but there are also a few new (rather small) features.

Since we needed to fix fedora-rawhide builds, this update also landed
Fedora Copr production yesterday.

In case of any trouble, please report issues upstream:
https://github.com/rpm-software-management/mock/issues

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-5.5

The updated packages are in Bodhi:

[Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1171d69465
[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-15b5461dd0
[EPEL 9]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-fd971ca651
[EPEL 8]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e9e1b2dad6

Happy building!
Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On úterý 16. ledna 2024 21:00:14 CET Chuck Anderson wrote:
> On Tue, Jan 16, 2024 at 08:02:28PM +0100, Pavel Raiskup wrote:
> > I just want to bump this thread; @kevin updated Fedora Koji today
> > - the Fedora 40+ (current Rawhide) builds are already handled with DNF5.
> > 
> > Happy (faster) building!  And should you face any issue, please report.
> > Pavel
> 
> In case it helps someone else, as documented here:
> 
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> 
> You need to do:
> 
> mock -r fedora-40-x86_64 --scrub=all
> 
> to allow "fedpkg mockbuild" to work again, otherwise one gets this error:
> 
> DEBUG util.py:461:  execv(/usr/bin/dnf5) failed: No such file or directory

Indeed, thank you.  It would be nice if Mock detected this situation, so
there's this RFE now:
https://github.com/rpm-software-management/mock/issues/1289

Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On pátek 5. ledna 2024 10:06:34 CET Pavel Raiskup wrote:
> On čtvrtek 4. ledna 2024 19:20:46 CET Pavel Raiskup wrote:
> > On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote:
> > > I just wanted to give you a quick heads-up that I plan to enable the
> > > BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
> > > gets distributed to mirrors.
> > 
> > This has happened now.  Fedora Copr builds F40 (Rawhide) with DNF5 now.
> > Should you face any issue, please report it.
> 
> Two more hints:
> 
> - I noticed that `dnf5` on Fedora Copr builders (F38) was buggy (old
>   version) because the latest update was not yet in the stable
>   repository.  This was breaking Rawhide builds in Copr projects with
>   `bootstrap=off` (using dnf5 on host).  This is no longer the case, the
>   DNF5 package has been updated to v5.1.10.  If you observed a
>   suspicious problem, please consider `bootstrap=on` or at least check
>   that DNF v5.1.10 is used.
> 
> - DNF5 isn't downloading filelists (resource cost optimization), which
>   in turn means that the packages can not (build)depend on random file
>   paths.  So just a small reminder that, per the updated packaging
>   guidelines https://pagure.io/packaging-committee/pull-request/1321 ,
>   you MUST NOT do things like `BuildRequires: /some/random/file/name`.

I just want to bump this thread; @kevin updated Fedora Koji today
- the Fedora 40+ (current Rawhide) builds are already handled with DNF5.

Happy (faster) building!  And should you face any issue, please report.
Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On čtvrtek 4. ledna 2024 19:20:46 CET Pavel Raiskup wrote:
> On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote:
> > I just wanted to give you a quick heads-up that I plan to enable the
> > BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
> > gets distributed to mirrors.
> 
> This has happened now.  Fedora Copr builds F40 (Rawhide) with DNF5 now.
> Should you face any issue, please report it.

Two more hints:

- I noticed that `dnf5` on Fedora Copr builders (F38) was buggy (old
  version) because the latest update was not yet in the stable
  repository.  This was breaking Rawhide builds in Copr projects with
  `bootstrap=off` (using dnf5 on host).  This is no longer the case, the
  DNF5 package has been updated to v5.1.10.  If you observed a
  suspicious problem, please consider `bootstrap=on` or at least check
  that DNF v5.1.10 is used.

- DNF5 isn't downloading filelists (resource cost optimization), which
  in turn means that the packages can not (build)depend on random file
  paths.  So just a small reminder that, per the updated packaging
  guidelines https://pagure.io/packaging-committee/pull-request/1321 ,
  you MUST NOT do things like `BuildRequires: /some/random/file/name`.

Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On středa 3. ledna 2024 8:46:22 CET Pavel Raiskup wrote:
> I just wanted to give you a quick heads-up that I plan to enable the
> BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
> gets distributed to mirrors.

This has happened now.  Fedora Copr builds F40 (Rawhide) with DNF5 now.
Should you face any issue, please report it.

Thanks!
Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On pondělí 18. prosince 2023 10:08:06 CET Pavel Raiskup wrote:
> On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote:
> > Hello maintainers!
> > 
> > Let me announce a new release of Mock Core Configs v39.3, aka
> > the configuration files for Mock, the chroot build environment manager
> > for building RPMs.
> > 
> > The notable change in this release is that we are switching the default
> > package_manager from DNF4 to DNF5, according to the F40 change:
> > https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> > Full release notes:
> >https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3
> > 
> > We plan to push this update into Fedora Copr to get some early testing
> > next week.  Then, depending on the releng team, we might push this into
> > Koji soon. The Bodhi updates links are here:
> > 
> > F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
> > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
> > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
> > EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
> > EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46
> > 
> > Note that we **will not** push these updates into Fedora stable earlier
> > than on Monday 2023-12-18 (but very likely we'll wait till the next
> > year, depending on the feedback).
> 
> And the push eventually happened, despite that I did not want it to
> happen, yet.  I probably messed up the Bodhi updates (I thought I
> disabled the stable-by-time feature).  Sorry, folks.
> 
> The builds often just work.  But there are two issues that blocks us
> from letting this update go to Fedora Copr at least:
> 
> - the builddep globbing issue
>   https://github.com/rpm-software-management/dnf5/pull/1088 which is
>   going to be fixed by a new release (just a new DNF5 release into
>   Rawhide means the problem is fixed)
> 
> - the weird hangs against Fedora Copr repositories
>   https://github.com/fedora-copr/copr/issues/3067 - this will probably
>   not hit you locally, but I am not sure yet.
> 
> In any case, if you need to - stay with DNF4 for a while - either do
> 
> $ cat ~/.config/mock/fedora-rawhide-x86_64.cfg 
> include("/etc/mock/fedora-rawhide-x86_64.cfg")
> config_opts["package_manager"] = "dnf"
> 
> ... or stay with the `mock-core-configs v39.2` a bit longer please.

Just a quick update, we already have DNF5 5.1.10 submitted for Fedora
Rawhide repos (should be in mirrors tomorrow).  This DNF5 release has no
known "blocker" issues.

I just wanted to give you a quick heads-up that I plan to enable the
BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
gets distributed to mirrors.

Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On pondělí 18. prosince 2023 11:46:07 CET Miro Hrončok wrote:
> On 18. 12. 23 10:08, Pavel Raiskup wrote:
> > In any case, if you need to - stay with DNF4 for a while - either do
> > 
> >  $ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
> >  include("/etc/mock/fedora-rawhide-x86_64.cfg")
> >  config_opts["package_manager"] = "dnf"
> > 
> > ... or stay with the `mock-core-configs v39.2` a bit longer please.
> 
> 
> Hi Pavel,
> this works locally, but not in Copr.
> 
> Our Python 3.13 Copr builds started failing today with the builddep globbing 
> issue.
> 
> What do we do?

I should work again actually, so no explicit action is needed.

I reverted the change for Fedora Copr, per
https://github.com/fedora-copr/copr/issues/3067

Pavel



signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote:
> Hello maintainers!
> 
> Let me announce a new release of Mock Core Configs v39.3, aka
> the configuration files for Mock, the chroot build environment manager
> for building RPMs.
> 
> The notable change in this release is that we are switching the default
> package_manager from DNF4 to DNF5, according to the F40 change:
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> Full release notes:
>https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3
> 
> We plan to push this update into Fedora Copr to get some early testing
> next week.  Then, depending on the releng team, we might push this into
> Koji soon. The Bodhi updates links are here:
> 
> F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
> EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
> EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46
> 
> Note that we **will not** push these updates into Fedora stable earlier
> than on Monday 2023-12-18 (but very likely we'll wait till the next
> year, depending on the feedback).

And the push eventually happened, despite that I did not want it to
happen, yet.  I probably messed up the Bodhi updates (I thought I
disabled the stable-by-time feature).  Sorry, folks.

The builds often just work.  But there are two issues that blocks us
from letting this update go to Fedora Copr at least:

- the builddep globbing issue
  https://github.com/rpm-software-management/dnf5/pull/1088 which is
  going to be fixed by a new release (just a new DNF5 release into
  Rawhide means the problem is fixed)

- the weird hangs against Fedora Copr repositories
  https://github.com/fedora-copr/copr/issues/3067 - this will probably
  not hit you locally, but I am not sure yet.

In any case, if you need to - stay with DNF4 for a while - either do

$ cat ~/.config/mock/fedora-rawhide-x86_64.cfg 
include("/etc/mock/fedora-rawhide-x86_64.cfg")
config_opts["package_manager"] = "dnf"

... or stay with the `mock-core-configs v39.2` a bit longer please.

Sorry again for the inconvenience,
Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.3 release

[Pavel Raiskup]

Hello maintainers!

Let me announce a new Mock release v5.3, the chroot build environment
manager for building RPMs.

The notable change in this release is the new rpm autospec plugin (for
generating %autorelease and %autochangelog "in-chroot"), and fixes for
building packages using %generate_buildrequires.  Full release notes:

   https://rpm-software-management.github.io/mock/Release-Notes-5.3

The Bodhi update links are here:

F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae0f48e479
F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-7b5c84e67a
EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-336a3b357a
EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-31a5c9462d

Happy building!
Pavel





signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

On Fri, Dec 1, 2023 at 4:09 PM Jonathan Wright via devel <
devel@lists.fedoraproject.org> wrote:

> Erm, I do already have dnf5 present within my f39 install where I was
> trying to run the mockbuild.
>
> $ which /usr/bin/dnf5
> /usr/bin/dnf5
>
> Any ideas as to the cause of the error?
>

I bet the bootstrap chroot is "cached" by Mock on your box.  Can you please
try:
$ mock -r fedora-rawhide-x86_64 --scrub=bootstrap  # or --scrub=all

Pavel



> On Fri, Dec 1, 2023 at 9:06 AM Jonathan Wright 
> wrote:
>
>> This is awesome!
>>
>> I grabbed the RPM and then attempted to run a `fedpkg --release rawhide
>> mockbuild` using it and ran into this error:
>>
>> INFO: Package manager dnf5 detected and used (direct choice)
>> Start: dnf5 update
>> execv(/usr/bin/dnf5) failed: No such file or directory
>>
>> Shouldn't it call dnf5 as a dep if it's going to be using it to make sure
>> that it is installed?
>>
>> On Fri, Dec 1, 2023 at 8:04 AM Pavel Raiskup  wrote:
>>
>>> Hello maintainers!
>>>
>>> Let me announce a new release of Mock Core Configs v39.3, aka
>>> the configuration files for Mock, the chroot build environment manager
>>> for building RPMs.
>>>
>>> The notable change in this release is that we are switching the default
>>> package_manager from DNF4 to DNF5, according to the F40 change:
>>> https://fedoraproject.org/wiki/Changes/BuildWithDNF5
>>> Full release notes:
>>>
>>> https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3
>>>
>>> We plan to push this update into Fedora Copr to get some early testing
>>> next week.  Then, depending on the releng team, we might push this into
>>> Koji soon. The Bodhi updates links are here:
>>>
>>> F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
>>> F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
>>> F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
>>> EL9
>>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
>>> EL8
>>> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46
>>>
>>> Note that we **will not** push these updates into Fedora stable earlier
>>> than on Monday 2023-12-18 (but very likely we'll wait till the next
>>> year, depending on the feedback).
>>>
>>> Happy (faster) building!
>>> Pavel
>>>
>>>
>>>
>>> --
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>>>
>>
>>
>> --
>> Jonathan Wright
>> AlmaLinux Foundation
>> Mattermost: chat
>> <https://chat.almalinux.org/almalinux/messages/@jonathan>
>>
>
>
> --
> Jonathan Wright
> AlmaLinux Foundation
> Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock Configs v39.3 released - DNF5 used for F40+ builds

[Pavel Raiskup]

Hello maintainers!

Let me announce a new release of Mock Core Configs v39.3, aka
the configuration files for Mock, the chroot build environment manager
for building RPMs.

The notable change in this release is that we are switching the default
package_manager from DNF4 to DNF5, according to the F40 change:
https://fedoraproject.org/wiki/Changes/BuildWithDNF5
Full release notes:
   https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3

We plan to push this update into Fedora Copr to get some early testing
next week.  Then, depending on the releng team, we might push this into
Koji soon. The Bodhi updates links are here:

F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46

Note that we **will not** push these updates into Fedora stable earlier
than on Monday 2023-12-18 (but very likely we'll wait till the next
year, depending on the feedback).

Happy (faster) building!
Pavel





signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to deal with COPR and RPMAutoSpec

[Pavel Raiskup]

On úterý 17. října 2023 22:47:23 CEST Richard Shaw wrote:
> I'm trying to test build packages before actually creating a side tag and
> doing real builds.
> 
> I'm using rpkg to do the test builds but openshading language uses
> RPMAutoSpec. I've tried creating empty commits to bump the release but it
> does not appear to be working.
> 
> What's the work around?

One of the ways might be:
$ copr-distgit-client clone --dist-git fedora 
$ cd 
$ git commit -m "bump" --allow-empty
$ copr-distgit-client sources
$ copr-distgit-client srpm
...
Wrote: /tmp/--.src.rpm

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Pavel Raiskup]

On úterý 24. října 2023 0:31:49 CEST Pavel Raiskup wrote:
> On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> > 
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> > 
> > == Summary ==
> > Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> > the default approach.
> > Packaging Guidelines and other documentation are adjusted to describe
> > this approach first.
> > Various tools that provide spec file templates are adjusted.
> 
> While on it, could we please make %changelog optional?

Whooops!  My INBOX got reordered, and it is obvious it is too late for
me :-) sorry for bumping this old thread (I have just been dealing with
autospec on multiple levels recently so I thought this thread was also
relevant).

> Packaging become an automatized task, and maintainers don't pay
> attention to %changelog beauty so they simply generate it from git-log
> (but I'd claim that git-log != %changelog).  Seems that
> %changelog become one of the most painful maintainers' headache :)
> 
> What do you think about a static changelog like:
> 
> %changelog
> * See https://src.fedoraproject.org/rpms//commits/rawhide
> 
> Aren't we ready to admit (something like) this is enough?
> 
> Pavel
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Pavel Raiskup]

On pátek 30. prosince 2022 20:01:55 CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
> the default approach.
> Packaging Guidelines and other documentation are adjusted to describe
> this approach first.
> Various tools that provide spec file templates are adjusted.

While on it, could we please make %changelog optional?

Packaging become an automatized task, and maintainers don't pay
attention to %changelog beauty so they simply generate it from git-log
(but I'd claim that git-log != %changelog).  Seems that
%changelog become one of the most painful maintainers' headache :)

What do you think about a static changelog like:

%changelog
* See https://src.fedoraproject.org/rpms//commits/rawhide

Aren't we ready to admit (something like) this is enough?

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock v5.0 released (and mock-core-configs v39)

[Pavel Raiskup]

On úterý 3. října 2023 21:48:24 CEST Kevin Fenzi wrote:
> On Tue, Oct 03, 2023 at 10:30:45AM +0200, Pavel Raiskup wrote:
> > 
> > Well, in what shape is our "layered image" build system?  Aren't we able
> 
> Terrible, and going to be decomissioned after f39 release. ;) 
> 
> But if you mean base images... those are fine.

I fear that doing this as additional full Fedora image would be a waste
of space in the Fedora registry?  Or not?  We basically need the base
image + python3-dnf-plugins-core:

Installing:
 python3-dnf-plugins-core  noarch 4.4.2-1.fc39   rawhide
   293 k
Installing dependencies:
 dbus-libs x86_64 1:1.14.10-1.fc40   rawhide
   155 k
 fonts-filesystem  noarch 1:2.0.5-12.fc39rawhide
   8.2 k
 js-jquery noarch 3.7.1-1.fc40   rawhide
   169 k
 python3-dateutil  noarch 1:2.8.2-10.fc39rawhide
   355 k
 python3-dbus  x86_64 1.3.2-4.fc39   rawhide
   157 k
 python3-distronoarch 1.8.0-6.fc39   rawhide
49 k
 python3-six   noarch 1.16.0-12.fc39 rawhide
41 k
 python3-systemd   x86_64 235-5.fc39 rawhide
   107 k
 web-assets-filesystem noarch 5-20.fc39  rawhide
   7.9 k
Installing weak dependencies:
 python-systemd-docx86_64 235-5.fc39 rawhide
75 k

For DNF5 images (41+), I hope we can put the dnf5-plugins
(dnf-plugins-core alternative in c++) directly into the base image since
it has no additional deps.

> > to create a new official image say `fedora-mock-bootstrap:`
> > that would be automatically built (ideally at least as frequently as the
> > base image is)?  This way we could optimize fedora builds for everyone.
> 
> Yes, we could. Just wouldn't be a layer, it would be it's own image. 

Do we have some HOWTO document how to start?  I suppose I have to
provide a kickstart file in fedora-kickstarts.git?  Would the image be
built automatically/when? :-)

Pavel

> kevin
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock v5.0 released (and mock-core-configs v39)

[Pavel Raiskup]

On neděle 20. srpna 2023 11:27:44 CEST Miroslav Suchý wrote:
> Dne 14. 08. 23 v 21:30 Michael J Gruber napsal(a):
> > Is this supposed to work now?
> >
> > With mock-5.0-1.fc38.noarch and after scrubbing, the image is pulled but
> > then not used because it is "not marked ready" (rawhide, f39, f38). Am I
> > holding it wrong?
> 
> 1) When image is not marked ready then it is still used. Only
>additional packages are installed into chroot when image is
>unpacked. It is still faster than installing whole chroot using
>DNF.
> 
> 2) Only RHEL images has all packages installed by default:
> 
> https://github.com/rpm-software-management/mock/commit/e7139e1ce10198066b13fd6d3e899e507c637bf8
> 
> Other images does not have necessary tools installed.
> 
> I do not expect that default Fedora images will have all packages
> installed by default. It does not make sense.
> 
> This is targeted for teams that do frequent builds and they can prepare
> the image tuned for their needs and mark it as ready. It will
> significantly lower the time before mock starts rpmbuild.

Well, in what shape is our "layered image" build system?  Aren't we able
to create a new official image say `fedora-mock-bootstrap:`
that would be automatically built (ideally at least as frequently as the
base image is)?  This way we could optimize fedora builds for everyone.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Copr - Mock v5.1

[Pavel Raiskup]

Hello again,

just a quick update that Mock 5.1 has been deployed into Fedora Copr,
too.  While on it, openSUSE Leap 15.3 is now EOL and 15.5 added.

Happy building!
Pavel

On pátek 15. září 2023 14:05:19 CEST Pavel Raiskup wrote:
> Hello maintainers!
> 
> Let me announce a new release of Mock v5.1 (the chroot build environment
> manager for building RPMs).
> 
> Mock 5.1 further stabilizes the (now default) --use-bootstrap-image
> feature, and adds a "fallback" mechanism which turns the feature OFF
> if Podman can not be used.  In case of temporary network issues, Mock
> repeatedly tries to "podman pull" the image.  It contains a
> compatibility fix with the new systemd-nspawn (rhbz#2238820) which was
> painful during the recent days.
> 
> In case of any trouble, please report issues upstream:
> https://github.com/rpm-software-management/mock/issues
> 
> Full release notes:
> https://rpm-software-management.github.io/mock/Release-Notes-5.1
> 
> The updated packages are in Bodhi:
> 
> [Fedora 39]: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-245c858aed
> [Fedora 38]: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-67a714a252
> [Fedora 37]: 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-fb5ab02f5e
> [EPEL 9]: 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-72c92e599a
> [EPEL 8]: 
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-45ace77fca
> 
> Happy building!
> Pavel
> 
> 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.1 released (and mock-core-configs v39.1)

[Pavel Raiskup]

Hello maintainers!

Let me announce a new release of Mock v5.1 (the chroot build environment
manager for building RPMs).

Mock 5.1 further stabilizes the (now default) --use-bootstrap-image
feature, and adds a "fallback" mechanism which turns the feature OFF
if Podman can not be used.  In case of temporary network issues, Mock
repeatedly tries to "podman pull" the image.  It contains a
compatibility fix with the new systemd-nspawn (rhbz#2238820) which was
painful during the recent days.

In case of any trouble, please report issues upstream:
https://github.com/rpm-software-management/mock/issues

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-5.1

The updated packages are in Bodhi:

[Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-245c858aed
[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-67a714a252
[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-fb5ab02f5e
[EPEL 9]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-72c92e599a
[EPEL 8]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-45ace77fca

Happy building!
Pavel





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Copr has Fedora 39 now, Was: Re: Disabling rawhide builds during branching - happening in 2hrs

[Pavel Raiskup]

On úterý 8. srpna 2023 19:12:36 CEST Tomas Hrcka wrote:
> Fedora Linux 39 is going to be branched in the upcoming hours as per
> the previous discussion[1] we are going to disable new koji builds for
> the duration of this event.
> 
> All builds that will be running at that time for the rawhide will be
> canceled and can be resubmitted by maintainers after the branching.
> 
> All rawhide updates that are in a pending state for rawhide will be unpushed.
> 
> Once Fedora Linux 39 is branched we will reenable builds in koji with
> notification to this list.

Just a quick update; we branched Rawhide to Fedora 39 in Fedora Copr
yesterday, and recently made the chroots available.

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v5.0 released (and mock-core-configs v39)

[Pavel Raiskup]

Hello maintainers!

Let me announce a new release of Mock v5.0 (the chroot build environment
manager for building RPMs).

This release release brings lots of changes, though the one that I'd
like to underline is that we turned --use-bootstrap-image ON by default.
This effectively means that Mock uses Podman to pull the bootstrap image
from image registries (instead of installing it from scratch with `dnf
--installroot`).  Thus Podman is now in `Recommends:`, not just
`Suggests:`. Should you have any issues, you can temporarily revert this
change with `--no-bootstrap-image` (--scrub=all first!).  Alternatively
set `config_opts["use_bootstrap_image"] = False` in configuration.

Mock 5.0 also stops using '/sbin/useradd' inside the chroot, but uses
'/sbin/useradd --prefix ' _on host_ to modify the in-chroot
/etc/passwd.  This change passed all our testing, but there's a
potential for bugs.

The mock-core-configs-v39 brings also the Fedora 39 configuration as it
is now branched from Rawhide (Rawhide is 40 now in Mock).  Several folks
already reported that Fedora Copr builds are broken for
fedora-rawhide-*, sorry for inconveniences.  This is being resolved
right now, we are pushing mock-5.0 into the Fedora Copr production.

In case of any trouble, please report issues upstream:
https://github.com/rpm-software-management/mock/issues

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-5.0

The updated packages are in Bodhi:

[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0ca9df2164
[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c65d483a5c
[EPEL 9]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e03c59145d
[EPEL 8]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-a5c155a6c0

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Anyone actively using `mock --no-clean`, or `mock --shell --no-clean`?

[Pavel Raiskup]

There's a potentially problematic patch (or maybe we are only
overcautious?).  If you belong to the $Subject group, we'd appreciate
if you could help us with testing of a pre-release Mock from

https://github.com/rpm-software-management/mock/pull/1103

Steps for testing are mentioned there.  Feel free to ping me on
#fedora-buildsys in case of any questions/issues.

Thank you!
Pavel



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedora-review workarounds for dnf5

[Pavel Raiskup]

On pondělí 17. července 2023 20:39:11 CEST Jerry James wrote:
> On Mon, Jul 17, 2023 at 10:54 AM Jerry James  wrote:
> > Like many of you, I have been quite inconvenienced because of
> > dnf5-related breakage of fedora-review.  I've been monkeying with it
> > today and finally got a successful run of fedora-review after making
> > the following changes [*].
> >
> > 1. Edit /etc/mock/templates/fedora-rawhide.tpl.  Change:
> >
> > config_opts['package_manager'] = 'dnf'
> >
> > to:
> >
> > config_opts['package_manager'] = 'dnf5'
> >
> > 2. Run 'mock -r fedora-rawhide-x86_64 --scrub=bootstrap'
> >
> > 3. Edit /usr/lib/python3.11/site-packages/FedoraReview/deps.py.  Change line
> >83 from:
> >
> > "dnf repoquery -q -C --requires --resolve " + " 
> > ".join(list(set(pkgs))),
> >
> >to:
> >
> > "dnf repoquery -q -C --requires " + " ".join(list(set(pkgs))),
> >
> >Change line 97 from:
> >
> > name = line.rsplit(".", 2)[0]
> >
> >to:
> >
> > name = resolve_one(line)[0].rsplit(".", 2)[0]
> >
> > Change line 286 from:
> >
> > "dnf repoquery -C -l " + " ".join(list(set(pkgs))),
> >
> >to:
> >
> > "dnf repoquery --files " + " ".join(list(set(pkgs))),
> >
> > Other changes may be needed.
> >
> > [*] Altering rpm-controlled files is generally a bad idea, and I do not
> > recommend it.  I am only doing so in this case because fedora-review 
> > does
> > not work at all without these changes.  I understand that my changes 
> > will
> > be overwritten the next time a mock-core-configs or fedora-review update
> > is installed.
> 
> Skip steps 1 and 2.  They are unnecessary.  Step 3 is all you need.

Note that the step 1 is going to happen soon for everyone:
https://github.com/rpm-software-management/mock/issues/1147

Don't forget to run 2 with Mock v5+ (once released).

Pavel

> -- 
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism

[Pavel Raiskup]

On pátek 14. července 2023 14:30:03 CEST Miroslav Suchý wrote:
> Dne 14. 07. 23 v 2:11 Kevin Fenzi napsal(a):
> > On Fri, Jul 14, 2023 at 12:26:27AM +0200, Miroslav Suchý wrote:
> >> Dne 13. 07. 23 v 23:59 Fabio Valentini napsal(a):
> >>> - rawhide mock / koji builds still default to dnf-3 (DNF 4)
> >> Support for DNF5 landed in Mock
> >>
> >> https://rpm-software-management.github.io/mock/Release-Notes-4.0
> >>
> >> In the meantime 4.1 was released.
> >>
> >> I hope that in week or two we release 4.2 and we can set
> >>
> >> config_opts['package_manager'] = 'dnf5'
> >>
> >> for fedora-rawhide config. I have just created
> >> https://github.com/rpm-software-management/mock/issues/1147
> >>
> >> Of course, Koji admins can do that independently in their configs.
> > Sure, but... our builders are Fedora 38.
> > Is the dnf5 in f38 expected to be ready to do bootstrap chroots?
> > Or only the rawhide one?
> 
> Hmm,
> 
> F39 has dnf5-5.0.15-4.fc39 
> 
> 
> F38 has dnf5-5.0.13-2.fc38 
> 
> 
> and there are some important changes (like module enable or forcearch) but 
> not sure if Koji will need this. Mock uses it 
> in some scenarions.

As I understand how DNF5 team works, they keep updating DNF5 quickly
enough even in Fedora 38 (but the 'dnf -> dnf-3' exists, instead of
'dnf -> dnf5').

I'm a bit lost in the minor numbers; and Mirek is right, not all the
missing features are actually important from the Koji perspective (e.g.
forcearch).

We keep the list of issues tracked here:
https://github.com/rpm-software-management/mock/issues/894
And namely, https://github.com/rpm-software-management/dnf5/issues/617
seems like a showstopper ATM.  At least as long as we have to check
GPG signatures at koji buildroot installation time.

Otherwise, Mock 4.1+ on Fedora 38 *host* (or in container) should just
work fine with fedora rawhide chroots and package_manager=dnf5.  Don't
forget to `mock -r fedora-rawhide-x86_64 --scrub=bootstrap` first,
because the root_cache tarball for bootstrap has the installed DNF4
packages, not DNF5, from previous calls.

Pavel





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On středa 14. června 2023 12:37:24 CEST Pavel Raiskup wrote:
> On čtvrtek 8. června 2023 17:42:13 CEST Pavel Raiskup wrote:
> > Hello maintainers!
> > 
> > Copr builders have been updated to Fedora 38 today (some old builders
> > might still be running F37 ATM, but when they finish the task(s) they
> > work on, they will be deleted). Our testsuite is passing just fine, so
> > you _should_ be fine too :-).  Please let us know if you have some
> > troubles.
> > 
> > There was one important change in Fedora 38 - RPM switched to the
> > Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
> > disallows Mock to properly check EL6 GPG signatures.  To allow further
> > builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
> > better work-around, let me know.
> 
> As it turns out, epel-6 config was based on CentOS 6 and EPEL 6, and the
> problem was with the CentOS 6 certificate (not EPEL 6).  With the 1-line
> change [1], epel-6 chroots were changed to RHEL+EPEL instead of
> CentOS+EPEL, so we can again use `gpgcheck=1` (even on F38).
> 
> [1] 
> https://pagure.io/fedora-infra/ansible/c/b9c69f5cac314c18a539c42d1ca3bf28e59dd51e

FTR, with DNF5 things just work for some reason.  Which was especially
confusing to me (dnf5 is the default package manager on my workstation):

https://github.com/rpm-software-management/dnf5/issues/617

Seems like the policy is entirely ignored with dnf5?  I'm not sure, but
if anything - worth debugging.

BTW. without the original problem in hand, this would be spotted much
later.

Pavel

> Pavel
> 
> 
> 
> > Pavel
> > 
> > 
> > 
> > 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On čtvrtek 8. června 2023 17:42:13 CEST Pavel Raiskup wrote:
> Hello maintainers!
> 
> Copr builders have been updated to Fedora 38 today (some old builders
> might still be running F37 ATM, but when they finish the task(s) they
> work on, they will be deleted). Our testsuite is passing just fine, so
> you _should_ be fine too :-).  Please let us know if you have some
> troubles.
> 
> There was one important change in Fedora 38 - RPM switched to the
> Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
> disallows Mock to properly check EL6 GPG signatures.  To allow further
> builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
> better work-around, let me know.

As it turns out, epel-6 config was based on CentOS 6 and EPEL 6, and the
problem was with the CentOS 6 certificate (not EPEL 6).  With the 1-line
change [1], epel-6 chroots were changed to RHEL+EPEL instead of
CentOS+EPEL, so we can again use `gpgcheck=1` (even on F38).

[1] 
https://pagure.io/fedora-infra/ansible/c/b9c69f5cac314c18a539c42d1ca3bf28e59dd51e

Pavel



> Pavel
> 
> 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On úterý 13. června 2023 16:57:42 CEST Neal H. Walfield wrote:
> On Thu, 08 Jun 2023 21:37:09 +0200,
> Ondřej Budai wrote:
> > RPM Sequoia's crypto policies can be configured, so you should be able to 
> > re-enable SHA-1. However, this would
> > be a global change, not only for EL6... See
> > https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/#hash-functions
> > ...
> > On Thu, Jun 8, 2023 at 5:42 PM Pavel Raiskup  wrote:
> > 
> >  Hello maintainers!
> > 
> >  Copr builders have been updated to Fedora 38 today (some old builders
> >  might still be running F37 ATM, but when they finish the task(s) they
> >  work on, they will be deleted). Our testsuite is passing just fine, so
> >  you _should_ be fine too :-).  Please let us know if you have some
> >  troubles.
> > 
> >  There was one important change in Fedora 38 - RPM switched to the
> >  Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
> >  disallows Mock to properly check EL6 GPG signatures.  To allow further
> >  builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
> >  better work-around, let me know.
> 
> I find this behavior surprising.  The default policy as set by
> fedora-crypto-policies is for rpm-sequoia is to accept SHA-1 (and
> DSA-1024, ...):
> 
>   
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/policies/FEDORA38.pol#L75
> 
> What policy are you using?

I was wrong.  The problem was *not* with the EPEL-6 signatures, but with
CentOS 6 signatures.  It is a bit harder to analyse, as
`sq-keyring-linter` is silent for that one:

$ sq-keyring-linter < 
/usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-CentOS-6
$ echo $?
0

Pavel

> Neal


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On sobota 10. června 2023 22:36:08 CEST Kevin Kofler via devel wrote:
> Pavel Raiskup wrote:
> > I'm not strongly against anything; but rather than weaker policy for
> > everything I slightly prefer keeping the _stricter default policy_ with
> > _disabled gpgcheck for EL6_ (we should phase epel-6 out entirely anyway
> > since it's long time EOL, but we still keep it for the distro upgrade
> > team(s)).  This is up to the community to decide, let us know in our
> > issue tracker if you are concerned.
> 
> Considering that Fedora buildroots always get killed off within days of the 
> EOL, I do not see why you are keeping epel-6 buildroots active 2½ years (!) 
> after its EOL.

Sorry to hear this is problematic, and potentially bringing
controversy.

The answer, from me (one of the Copr maintainers/devels payed by RH), is
that we did not have to care about the epel-6 chroots too much.  The
limiting factor of Fedora Copr is mostly storage.  For the context:

- epel-6 consumption now is 94GB (building still ON)
- fedora-36 decreases quickly to 1943GB (building OFF, recently)
- fedora-35 1193GB
- ...
- fedora-31 still 112GB (building OFF for a few years?)
- fedora-30 still 71GB ...

For more info see the stats [1].

If we really want to shut epel-6, I think we can do that?  Can we please
have an issue for this?  But this is going to be a political decision,
because technically it is a micro optimization for the bottleneck we
have.

[1] https://copr-be.cloud.fedoraproject.org/stats/distro.html

Pavel



> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On úterý 13. června 2023 16:57:42 CEST Neal H. Walfield wrote:
> On Thu, 08 Jun 2023 21:37:09 +0200,
> Ondřej Budai wrote:
> > RPM Sequoia's crypto policies can be configured, so you should be able to 
> > re-enable SHA-1. However, this would
> > be a global change, not only for EL6... See
> > https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/#hash-functions
> > ...
> > On Thu, Jun 8, 2023 at 5:42 PM Pavel Raiskup  wrote:
> > 
> >  Hello maintainers!
> > 
> >  Copr builders have been updated to Fedora 38 today (some old builders
> >  might still be running F37 ATM, but when they finish the task(s) they
> >  work on, they will be deleted). Our testsuite is passing just fine, so
> >  you _should_ be fine too :-).  Please let us know if you have some
> >  troubles.
> > 
> >  There was one important change in Fedora 38 - RPM switched to the
> >  Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
> >  disallows Mock to properly check EL6 GPG signatures.  To allow further
> >  builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
> >  better work-around, let me know.
> 
> I find this behavior surprising.  The default policy as set by
> fedora-crypto-policies is for rpm-sequoia is to accept SHA-1 (and
> DSA-1024, ...):
> 
>   
> https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/policies/FEDORA38.pol#L75
> 
> What policy are you using?

The `DEFAULT:SHA1`, but it is weird - I can not reproduce the build
failure now.  Is something changing in the backgrounds?

So lemme try to revert back to the nogpgcheck=1 variant.  Thank you for
the hint, Neal!

Pavel

> 
> Neal
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

On čtvrtek 8. června 2023 21:37:09 CEST Ondřej Budai wrote:
> RPM Sequoia's crypto policies can be configured, so you should be able to
> re-enable SHA-1. However, this would be a global change, not only for
> EL6... See
> https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/#hash-functions
> 
> Cheers,
> Ondřej

Thank you very much for the reference, Odřej!

I'm not strongly against anything; but rather than weaker policy for
everything I slightly prefer keeping the _stricter default policy_ with
_disabled gpgcheck for EL6_ (we should phase epel-6 out entirely anyway
since it's long time EOL, but we still keep it for the distro upgrade
team(s)).  This is up to the community to decide, let us know in our
issue tracker if you are concerned.

Pavel

> On Thu, Jun 8, 2023 at 5:42 PM Pavel Raiskup  wrote:
> 
> > Hello maintainers!
> >
> > Copr builders have been updated to Fedora 38 today (some old builders
> > might still be running F37 ATM, but when they finish the task(s) they
> > work on, they will be deleted). Our testsuite is passing just fine, so
> > you _should_ be fine too :-).  Please let us know if you have some
> > troubles.
> >
> > There was one important change in Fedora 38 - RPM switched to the
> > Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
> > disallows Mock to properly check EL6 GPG signatures.  To allow further
> > builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
> > better work-around, let me know.
> >
> > Pavel
> >
> >
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Copr builders updated to Fedora 38

[Pavel Raiskup]

Hello maintainers!

Copr builders have been updated to Fedora 38 today (some old builders
might still be running F37 ATM, but when they finish the task(s) they
work on, they will be deleted). Our testsuite is passing just fine, so
you _should_ be fine too :-).  Please let us know if you have some
troubles.

There was one important change in Fedora 38 - RPM switched to the
Sequoia crypto backend.  It refuses SHA-1 in crypto;  which basically
disallows Mock to properly check EL6 GPG signatures.  To allow further
builds, we switched to gpgcheck=0 for all epel-6 chroots.  If you know a
better work-around, let me know.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Mock v4.1 (bugfix) released (and mock-core-configs v38.6)

[Pavel Raiskup]

On úterý 6. června 2023 22:04:26 CEST Miroslav Suchý wrote:
> Dne 06. 06. 23 v 18:32 Miro Hrončok napsal(a):
> > On 05. 06. 23 10:39, Pavel Raiskup wrote:
> >> - Mock doesn't "Requires:" DNF anymore, just Suggests
> >
> > So how does this actually work?
> 
> If you really want to work without DNF then you have to flip the default
> 
> #config_opts['use_bootstrap_image'] = False
> 
> to True.
> 
> Hmm, I wonder... We should likely change this default.

JFTR, Mirek proposes it here:
https://github.com/rpm-software-management/mock/pull/1101

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v4.1 (bugfix) released (and mock-core-configs v38.6)

[Pavel Raiskup]

Hello maintainers,

let me announce a bugfix/follow-up Mock v4.1 release.  This release

- further stabilizes building with DNF5 in general
- builds with DNF4 are fixed for the future Fedora 39+ hosts where
  '/bin/dnf' is DNF5 not DNF4
- 'dnf5' is used for installing bootstrap when DNF4 is not found
- Mock doesn't "Requires:" DNF anymore, just Suggests

The `mock-core-configs` package brings updated openEuler configs
(metalinks used instead of baseurls) and fixed logic for installing the
/bin/default.cfg link on EPEL 8.

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-4.1

Bodhi updates here:
[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-aac9311480
[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-88b1e4b373
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-43755edca1
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-424b655bb6

Pavel

On pondělí 22. května 2023 15:44:32 CEST Pavel Raiskup wrote:
> Hello maintainers!
> 
> I'm glad I can announce that we have a new release of Mock v4.0 (the chroot
> build environment manager for building RPMs).  There are two rather big things
> in this release, therefore the bump of the major version:
> 
> - There's a new support for the DNF5 package manager (which should be the
>   default one since Fedora 39)
> 
> - The '--use-bootstrap-image' feature was fixed so it is less demanding,
>   and thus newly works even if you run `mock --use-bootstrap-image`
>   inside a Podman container (or toolbox).
> 
> Full release notes:
> 
> https://rpm-software-management.github.io/mock/Release-Notes-4.0
> 
> The updated packages are in Bodhi:
> 
> [Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-90a03d8d62
> [Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5c8d906435
> [EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-74629814f7
> [EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1652f46b68
> 
> Happy building!
> Pavel
> 
> 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Has anything changed in terms of how to build a signed kernel semi-recently?

[Pavel Raiskup]

On pondělí 29. května 2023 13:58:08 CEST Julian Sikorski wrote
> Am 18.05.23 um 00:41 schrieb Julian Sikorski:
> > Am 17.05.23 um 23:35 schrieb Julian Sikorski:
> >> Hello,
> >>
> >> I tried building a signed 6.3 kernel today after a while (6.1 
> >> timeframe). Unfortunately, it appears that I am hitting some issues 
> >> with pesign:
> >>
> >> + /usr/bin/pesign --certdir /etc/pki/pesign -t 'NSS Certificate DB' -c 
> >> 'Julians Secure Boot signing key - Julian Sikorski' -s -i 
> >> arch/x86/boot/bzImage -o vmlinuz.tmp
> >> pesign: Could not open NSS database ("security library: bad 
> >> database."): Permission denied
> >>
> >> I have updated to F38 since but everything is still in place:
> >> - pesign is running unlocked:
> >>$ sudo pesign-client -q
> >>token "NSS Certificate DB" is unlocked
> >> - I run mock with hosts's pesign folders exposed:
> >>$ sudo cat /etc/mock/site-defaults.cfg | grep bind
> >>
> >> config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign',
> >>  '/var/run/pesign'))
> >> - I run mock with --isolation=simple
> >>
> >> Summing up, I am still following the same guide as before [1]. Were 
> >> there any changes in the recent months which could influence this 
> >> workflow? Thanks!
> >>
> >> Best regards,
> >> Julian
> >>
> >> [1] https://gist.github.com/chenxiaolong/520914b191f17194a0acdc0e03122e63
> >> Hi all,
> > 
> > I figured it out, looks like this commit is to blame:
> > 
> > https://github.com/rhboot/pesign/commit/d8a8c259994d0278c59b30b41758a8dd0abff998
> > 
> > I fixed it by adding myself to pesign group.
> > 
> > Best regards,
> > Julian

Julian, thank you for reporting.

> Now with mock-4.0 I am getting permission denied again. I do not want to 
> be that guy, but aren't incompatible upgrades frowned upon during a 
> single release?

This is something we try to achieve most of the time, but as you can see
- problems sometimes happen.  Sorry to hear this.

> More importantly, how can I now configure mock so that it can use
> host's pesign and I can build signed kernel images again?

I believe you've hit a bug that should be reported upstream:
https://github.com/rpm-software-management/mock/issues
I'm going to report there if you aren't faster.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v4.0 released (and mock-core-configs v38.5)

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v4.0 (the chroot
build environment manager for building RPMs).  There are two rather big things
in this release, therefore the bump of the major version:

- There's a new support for the DNF5 package manager (which should be the
  default one since Fedora 39)

- The '--use-bootstrap-image' feature was fixed so it is less demanding,
  and thus newly works even if you run `mock --use-bootstrap-image`
  inside a Podman container (or toolbox).

Full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-4.0

The updated packages are in Bodhi:

[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-90a03d8d62
[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5c8d906435
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-74629814f7
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1652f46b68

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Real builds from forks fixed

[Pavel Raiskup]

Thank you for the info!

On úterý 2. května 2023 22:17:13 CEST Kevin Fenzi wrote:
> Greetings everyone.
> 
> Fedora Release engineering was made aware recently that some real builds
> seemed to have been done from commits not in any branch in the main
> repository for the package. All cases we are currently aware of were
> maintainers mistakenly building from a forked repo with a valid pull 
> request.
> 
> On investigation, this was found to be due to some changes in how koji
> does the buildSRPMFromSCM task and us being unaware of the implications
> of that change.
> 
> In short, when a pull request is created, pagure keeps track of those
> commits in refs/pulls. Previously koji did a 'git reset' to the exact
> commit, which would only work for commits on a branch. The new method 
> with 'git fetch' will follow refs and find the pull request commit.
> 
> Upstream koji developers have created a plugin for us to check policy
> after the checkout and require official builds to be from a commit that
> is in a branch. This plugin has been deployed and is active.

This seems like a thing that should be opt-out (for scratch builds
e.g.), rather than opt-in by a plugin.  Don't you have a link to the
corresponding Koji change?

Pavel

> Sorry for any confusion this issue may have caused.
> 
> kevin
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

HaveIBeenPwned database in Fedora somewhere?

[Pavel Raiskup]

Hello all!

Do we have HaveIBeenPwned database of hashes somewhere in Fedora, as a
file or service (regularly updated)?  I'd prefer checking my passwords
manually, without actually giving the passwords to the
https://haveibeenpwned.com service.  Speaking of that, I really dislike
that the service takes the real passwords on it's input.

I seem I was able to reproduce the steps-to-download (currently
downloading):
https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
But that will take quite some time...

Has anyone planed to at least package that dotnet utility?  How do you
do this?

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Copr drops sqlite databases and AppStream from repo metadata

[Pavel Raiskup]

Just a heads-up for a wider audience about two upcoming Copr changes.

We already have AppStream metadata disabled by default for new projects,
but there are many old projects where having this enabled causes
problems here and there.  So we plan to disable it manually even for old
projects:


https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org/thread/JP4TBPHD6HZOBWU4VEBKLGUHEC6CBDC3/

The SQLite dababases generated by `createrepo_c --database` consume
additional storage, and also computational power on Copr Backend.
According to info we have, it is unused by modern DNF stacks, and
optional for YUM on EL6+ (DB is generated if not already available).


https://lists.fedorahosted.org/archives/list/copr-de...@lists.fedorahosted.org/thread/4F6B643HQA3HYB65RFAG77CYB4PM6JJI/

If you feel this is the wrong decision, please speak up.  Thank you!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux 38 branched

[Pavel Raiskup]

On pátek 10. února 2023 11:38:25 CET Iñaki Ucar wrote:
> On Fri, 10 Feb 2023 at 11:35, Peter Robinson  wrote:
> >
> > On Fri, Feb 10, 2023 at 10:27 AM Iñaki Ucar  wrote:
> > >
> > > On Fri, 10 Feb 2023 at 09:44, Jakub Kadlcik  wrote:
> > > >
> > > > Hello Tomas,
> > > > thank you for the announcement.
> > > >
> > > > We also branched Fedora 38 in Copr so that everybody can submit builds
> > > > for it by now. Also, all projects with the "Follow Fedora branching"
> > > > option configured in their project settings have F38 chroots
> > > > automatically enabled and they contain the last build results from
> > > > Fedora Rawhide before the branch.
> > >
> > > Is this still ongoing? I don't see F38 in my projects.
> >
> > I do in all of my packages, you should just need to do a git pull to
> > get the new branches.
> 
> I meant in Copr.

Just confirming - Copr branching is a two-phase process;  we first link the
RPMs from rawhide to the branched release, and then we enable (when we know the
chroot is building fine).
https://docs.pagure.org/copr.copr/how_to_manage_chroots.html#branching-process

When Jakub announced, we just had those packages hardlinked, and RPMs available
on backend.  But the 38 chroots got enabled later (next day).

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v3.4 released

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v3.4.  There
are just two small new things, a better --forcearch check and
the device-mapper control file is exposed in chroot.  Full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-3.4

The updated packages are in Bodhi:

[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c3b827df24
[Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-389622bd06
[Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-993c7450c6
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-440fa7af21
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-a07aa4589e

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v3.2 released

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v3.2.

The -–list-chroots option is now faster, directories in /var/cached and /var/lib
dropped SGID bit, rpmbuild --noclean (cleanup_on_success=False) is not used
while building for EL6 chroots.  See full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-3.2

The updated packages are in Bodhi:

[Fedora 37]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-3b6ee0825e
[Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9f6d199630
[Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c4316e5c3f
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73bd121c67
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4e4f7442dc

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Mock v3.1 release, mock-core-configs v37.5

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v3.1.  This is
a small release with several minor fixes.  Most of the work has been done
in mock-core-configs package (mock configuration).  See full release notes:

https://rpm-software-management.github.io/mock/Release-Notes-3.1

The updated packages are in Bodhi:

[Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-438ee58218
[Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ec98b247c8
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-893a307ae7
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4e4f7442dc
[EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3fcd2b8a9a

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock v3.0 release, mock-core-configs v37.3

[Pavel Raiskup]

Hello maintainers!

I'm glad I can announce that we have a new release of Mock v3.0.  Even
though we bumped the major version here, this is just a normal update that
brings a few new features and shouldn't bring any troubles or backward
incompatibilities.  The reason we bumped the version this way is that we
feature-freezed the Mock v2.X, which stays in "bug-fix" mode and is going
to be updated until the EPEL 7 EOL (actually, Mock v2.17 was released  in
parallel with Mock v3.0, but only for EL7).

From the new things,
- there's a nice new option `--list-chroots`,
- we better copy the CA certificates from host to the build chroot,
- there's a first "library like" function simple_load_config() which was
  needed by the Fedora Review tool (thanks to Neal we also ship an updated
  fedora-review tool in the same Bodhi updates below!).
- there's a disabled SECCOMP for Podman commands (with a new opt-in config
  if someone wants to have it enabled).

We also shipped a new version of mock-core-configs v37.3 which
works-around issues with improperly signed Fedora ELN packages and
provides the epel-9-* configs to fix 'fedpkg mockbuild' (these are just
symlinks to C9S+EPEL — once the RHEL 9 is GA, we'll use the same approach
as we use for epel-8* configs).

[Release notes]: 
https://rpm-software-management.github.io/mock/Release-Notes-3.0
[Fedora 36]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-7a34e4d255
[Fedora 35]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d60cc8b586
[Fedora 34]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1e8c2e2791
[EPEL 9]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-df59848ff7
[EPEL 8]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-e86ba06e24
[EPEL 7]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-2eb57408f3

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v37

[Pavel Raiskup]

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
> > 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to make fedpkg --release epel9 mockbuild use crb?

[Pavel Raiskup]

On Sunday, February 6, 2022 8:35:15 PM CET Roman Inflianskas via devel wrote:
> Sorry, I've forgotten to reply yesterday.
> 
> I've installed these updates, but I still get this error:
> mockbuild.exception.ConfigError: Could not find included config file:
> /tmp/epel-9-x86_64.j_mo4dzgmockconfig/templates/centos-stream-9.tpl
> 
> Copying this templates/centos-stream-9.tpl doesn't help still.
> 
> I've decided to give permissions to epel-packagers-sig group to let them
> build it.

You need to update fedpkg and rpkg, too:

$ rpm -q fedpkg python3-rpkg
fedpkg-1.42-1.fc35.noarch
python3-rpkg-1.64-2.fc35.noarch

More info here: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/BNQ2TFWODJW3JSOBAG26AZQBOS5HHZMD/

Pavel

> On Sat, Feb 5, 2022 at 9:25 PM Neal Gompa  wrote:
> 
> > On Sat, Feb 5, 2022 at 2:15 PM Roman Inflianskas  wrote:
> > >
> > > Thanks for your answer.
> > >
> > > I get this this error:
> > > mockbuild.exception.ConfigError: Could not find included config file:
> > /tmp/epel-9-x86_64.j_mo4dzgmockconfig/templates/centos-stream-9.tpl
> > >
> > > Copying this templates/centos-stream-9.tpl doesn't help.
> > >
> > > I've tried this instead:
> > > sudo ln -s /etc/mock/centos-stream-9-x86_64.cfg
> > /etc/mock/epel-9-x86_64.cfg
> > >
> > > And I get this error:
> > > RPM build errors:
> > > + %pyproject_buildrequires -t
> > > /var/tmp/rpm-tmp.SeHyEg: line 32: fg: no job control
> > > error: Bad exit status from /var/tmp/rpm-tmp.SeHyEg
> > (%generate_buildrequires)
> > > Bad exit status from /var/tmp/rpm-tmp.SeHyEg
> > (%generate_buildrequires)
> > > Finish: rpmbuild python-executing-0.8.2-1.el9.src.rpm
> > > Finish: build phase for python-executing-0.8.2-1.el9.src.rpm
> > > ERROR:
> > Exception(/home/rominf/dev/fedora-scm/src/python-executing/python-executing-0.8.2-1.el9.src.rpm)
> > Config(centos-stream-9-x86_64) 0 minutes 55 secon
> > > ds
> > > INFO: Results and/or logs in:
> > /home/rominf/dev/fedora-scm/src/python-executing/results_python-executing/0.8.2/1.el9
> > > INFO: Cleaning up build root ('cleanup_on_failure=True')
> > > Start: clean chroot
> > > Finish: clean chroot
> > > ERROR: Command failed:
> > >  # ['bash', '--login', '-c', '/usr/bin/rpmbuild -br --target x86_64
> > --nodeps /builddir/build/SPECS/python-executing.spec']
> > >
> > > Could not execute mockbuild: Failed to execute command.
> > >
> >
> > You need the latest update for mock, mock-core-configs, and
> > distribution-gpg-keys:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-a7d4aaa6fe
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> >
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mock, %{buildroot}, fc35

[Pavel Raiskup]

On Wednesday, February 2, 2022 4:50:59 PM CET Vitaly Zaitsev via devel wrote:
> On 02/02/2022 16:35, Pavel Raiskup wrote:
> > And if not specified, mock tries to
> > pick the mock configuration according the host system (so it uses
> > '-r fedora-35-x86_64' on a fedora-35-x86_64 host system).
> 
> No. It uses /etc/mock/default.cfg.

Which should be a symlink to fedora-35-x86_64, sorry for not going too much into
details:
https://github.com/rpm-software-management/mock/blob/6b30e6bbf627e24e58b812255a5516e25e51fbeb/mock-core-configs/mock-core-configs.spec#L138-L146

Pavel

> -- 
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mock, %{buildroot}, fc35

[Pavel Raiskup]

On Wednesday, February 2, 2022 4:18:29 PM CET Ankur Sinha wrote:
> On Wed, Feb 02, 2022 16:07:38 +0100, Alain Vigne wrote:
> > Can someone explain to me why my  .srpm  [1]
> > is not building in mock ?
> > 
> > I ran
> > > mock filename.srpm
> 
> Have you had a chance to look at the mock man page, or this wiki page?
> https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds#How_do_I_use_Mock.3F
> 
> The command is of the form:
> 
> mock -r  --rebuild ./path/to/srpm

This _is_ a valid command:

$ mock 

The --rebuild is the default mode.  And if not specified, mock tries to
pick the mock configuration according the host system (so it uses
'-r fedora-35-x86_64' on a fedora-35-x86_64 host system).

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mock, %{buildroot}, fc35

[Pavel Raiskup]

On Wednesday, February 2, 2022 4:07:38 PM CET Alain Vigne wrote:
> Can someone explain to me why my  .srpm  [1]
> is not building in mock ?
> 
> I ran
> > mock filename.srpm

You did not provide the build logs.

> Will it work in COPR, Koji ?
> 
> [1] https://avigne.fedorapeople.org/libfungw-1.2.0-1.fc35.src.rpm

Feel free to try e.g. Copr by:
$ copr create PROJECTNAME --chroot fedora-35-x86_64
$ copr build PROJECTNAME 
https://avigne.fedorapeople.org/libfungw-1.2.0-1.fc35.src.rpm

See docs for more info:
https://docs.pagure.org/copr.copr/user_documentation.html#quick-start

Pavel



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock v2.16 release, mock-core-configs v37

[Pavel Raiskup]

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
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Z architecture support in Fedora Copr

[Pavel Raiskup]

Hello maintainers!

I'm glad to announce that the native s390x builders are now available in
Fedora Copr production.

Seems everything works, so we also added the 'epel-8-s390x' and 'epel-9-s390x'
chroots.

Note that the builders are hosted in IBM Cloud, Tokyo, so the connectivity
between builder and the rest of the Copr stack (North Virginia) might be a
bit slower (or behave differently).  Ditto for RPM repositories that are
not mirrored.  Overall, this is an early attempt so please be patient and
report issues: https://pagure.io/copr/copr/issues

Happy building!
Pavel

On Monday, January 17, 2022 2:18:04 PM CET Pavel Raiskup wrote:
> Hello all!
> 
> Red Hat subscribed builders (for EPEL 8) have been deployed to production.
> So any EPEL 8 build in Fedora Copr is now done against RHEL 8 + EPEL 8.  As
> always, please report back any issues.
> 
> There's though some problem related to the s390x native builders.  Please
> stay tuned on that part...  For now, s390x stays emulated (and as I noticed
> later after the announcement, we haven't enabled the epel-8-s390x chroot,
> yet - so there's no regression at least).  I hope these issues will be
> resolved by the end of the week.
> 
> Happy building,
> Pavel
> 
> On Monday, January 10, 2022 11:22:03 AM CET Pavel Raiskup wrote:
> > Hello maintainers.
> > 
> > Currently, we build all EPEL variants against CentOS "base" in Fedora
> > Copr, i.e.  epel-* configs means CentOS+EPEL.  By the end of January 2022
> > CentOS 8 mirrors will start disappearing, pushing us to change the configs
> > to avoid build failures.
> > 
> > We would like to start the migration to the RHEL base as soon as possible,
> > so we are at least a bit "ahead" the change.  So we can start resolving
> > the issues.
> > 
> > There doesn't seem to be a real blocker, or known issue.
> > 
> >   - We got enough subscriptions from Red Hat for Fedora Copr purposes to
> > start building against official RHEL channels.
> > 
> >   - The Mock + configs is stuck in Bodhi for now, but it doesn't block
> > Copr to apply for the change earlier.  This is mostly about community
> > decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
> > broken.
> > 
> >   - The remaining problem seemed to be the s390x architecture, as the
> > emulation being _currently_ done wouldn't work with Red Hat
> > subscriptions, see details in [1] discussion.  But thanks to IBM
> > sponsoring us IBM Cloud access we should be OK to deploy the s390x
> > arch support in Fedora Copr at the same time with the EPEL change
> > (this will go in a separate announcement).
> > 
> > **So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.**  If
> > everything works well at least.
> > 
> > Side note from me...  Note that EPEL 9 in Fedora Copr is still CentOS
> > Stream 9 + EPEL 9 ATM.  This will change to "RHEL 9 + EPEL 9" once RHEL 9
> > is generally available (subscribed content).  Might seem as a
> > complication for users, but it's actually not - it is good thing we can
> > start working on EPEL 9 now.  So I want to congratulate to EPEL community
> > here, the fact we have stream in place allows us to bring EPEL 9 up before
> > actually RHEL is available.  That's an awesome step (jump) forward
> > compared to previous releases!
> > 
> > [1] 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/
> > 
> > Pavel
> > 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Copr EPEL 8 being moved to RHEL+EPEL (and s390x native as bonus)

[Pavel Raiskup]

Hello all!

Red Hat subscribed builders (for EPEL 8) have been deployed to production.
So any EPEL 8 build in Fedora Copr is now done against RHEL 8 + EPEL 8.  As
always, please report back any issues.

There's though some problem related to the s390x native builders.  Please
stay tuned on that part...  For now, s390x stays emulated (and as I noticed
later after the announcement, we haven't enabled the epel-8-s390x chroot,
yet - so there's no regression at least).  I hope these issues will be
resolved by the end of the week.

Happy building,
Pavel

On Monday, January 10, 2022 11:22:03 AM CET Pavel Raiskup wrote:
> Hello maintainers.
> 
> Currently, we build all EPEL variants against CentOS "base" in Fedora
> Copr, i.e.  epel-* configs means CentOS+EPEL.  By the end of January 2022
> CentOS 8 mirrors will start disappearing, pushing us to change the configs
> to avoid build failures.
> 
> We would like to start the migration to the RHEL base as soon as possible,
> so we are at least a bit "ahead" the change.  So we can start resolving
> the issues.
> 
> There doesn't seem to be a real blocker, or known issue.
> 
>   - We got enough subscriptions from Red Hat for Fedora Copr purposes to
> start building against official RHEL channels.
> 
>   - The Mock + configs is stuck in Bodhi for now, but it doesn't block
> Copr to apply for the change earlier.  This is mostly about community
> decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
> broken.
> 
>   - The remaining problem seemed to be the s390x architecture, as the
> emulation being _currently_ done wouldn't work with Red Hat
> subscriptions, see details in [1] discussion.  But thanks to IBM
> sponsoring us IBM Cloud access we should be OK to deploy the s390x
> arch support in Fedora Copr at the same time with the EPEL change
> (this will go in a separate announcement).
> 
> **So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.**  If
> everything works well at least.
> 
> Side note from me...  Note that EPEL 9 in Fedora Copr is still CentOS
> Stream 9 + EPEL 9 ATM.  This will change to "RHEL 9 + EPEL 9" once RHEL 9
> is generally available (subscribed content).  Might seem as a
> complication for users, but it's actually not - it is good thing we can
> start working on EPEL 9 now.  So I want to congratulate to EPEL community
> here, the fact we have stream in place allows us to bring EPEL 9 up before
> actually RHEL is available.  That's an awesome step (jump) forward
> compared to previous releases!
> 
> [1] 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/
> 
> Pavel
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora Copr EPEL 8 being moved to RHEL+EPEL (and s390x native as bonus)

[Pavel Raiskup]

On Monday, January 10, 2022 11:22:03 AM CET Pavel Raiskup wrote:
> **So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.**  If
> everything works well at least.

Forgot to mention.  This is already deployed to the devel instance.  If you want
to give it a try, feel free:

https://copr-fe-dev.cloud.fedoraproject.org

Pavel

P.S. We can not _promise_ DEV will fully work, this week or anytime else, so
please tolerate outages. Feel free to ping me/us on #fedora-buildsys.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora Copr EPEL 8 being moved to RHEL+EPEL (and s390x native as bonus)

[Pavel Raiskup]

Hello maintainers.

Currently, we build all EPEL variants against CentOS "base" in Fedora
Copr, i.e.  epel-* configs means CentOS+EPEL.  By the end of January 2022
CentOS 8 mirrors will start disappearing, pushing us to change the configs
to avoid build failures.

We would like to start the migration to the RHEL base as soon as possible,
so we are at least a bit "ahead" the change.  So we can start resolving
the issues.

There doesn't seem to be a real blocker, or known issue.

  - We got enough subscriptions from Red Hat for Fedora Copr purposes to
start building against official RHEL channels.

  - The Mock + configs is stuck in Bodhi for now, but it doesn't block
Copr to apply for the change earlier.  This is mostly about community
decision that 'fedpkg mockbuild' is not aligned, yet, not that Mock is
broken.

  - The remaining problem seemed to be the s390x architecture, as the
emulation being _currently_ done wouldn't work with Red Hat
subscriptions, see details in [1] discussion.  But thanks to IBM
sponsoring us IBM Cloud access we should be OK to deploy the s390x
arch support in Fedora Copr at the same time with the EPEL change
(this will go in a separate announcement).

**So the plan is to move to RHEL + EPEL next Monday, 2022-01-17.**  If
everything works well at least.

Side note from me...  Note that EPEL 9 in Fedora Copr is still CentOS
Stream 9 + EPEL 9 ATM.  This will change to "RHEL 9 + EPEL 9" once RHEL 9
is generally available (subscribed content).  Might seem as a
complication for users, but it's actually not - it is good thing we can
start working on EPEL 9 now.  So I want to congratulate to EPEL community
here, the fact we have stream in place allows us to bring EPEL 9 up before
actually RHEL is available.  That's an awesome step (jump) forward
compared to previous releases!

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Copr success but no packages?

[Pavel Raiskup]

On Tuesday, January 4, 2022 8:51:58 AM CET Miroslav Suchý wrote:
> Dne 03. 01. 22 v 22:57 Steven A. Falco napsal(a):
> > On 1/3/22 04:38 PM, Elliott Sales de Andrade wrote:
> >> Here are direct links to the chroots:
> >>>
> >>> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-34-x86_64/03123050-kicad/
> >>>
> >>> https://download.copr.fedorainfracloud.org/results/stevenfalco/kicad/fedora-35-x86_64/03123050-kicad/
> > But then I tried a different link:
> >
> > https://copr-be.cloud.fedoraproject.org/results/stevenfalco/kicad/fedora-35-x86_64/03123050-kicad/
> >
> > and there I see the files.  So they must really be there, but the link is 
> > not working for me.  And no, I'm not running 
> > some sort of caching firewall.
> 
> The download.copr.f.o are cnames to CDN all around the world (provided by 
> AWS).
> 
> copr-be.cloud.f.o is the real name of the server.
> 
> So I guess it is may be some CDN issue. Which is pain to 
> investigate/replicate.

We documented the CDN problem some time ago [1]:

| Build succeeded, but I don’t see the built results? ¶
| 
| Fedora Copr uses the AWS CDN to spread the HTTP traffic on the built RPM
| repositories across the globe, and it implies a lot of caching on the AWS 
side.
| 
| When you (or anyone else in your territory) check the build directory while 
the
| build is still in progress, the web server directory listing gets cached in 
CDN
| - and then the contents of the directory appears unchanged for some time (even
| though the build might already be finished and thus the directory updated).
| 
| Don’t worry, this caching doesn’t affect the DNF/YUM behavior - so even though
| your browser is misled by caches, package managers always download the latest
| contents of the directories. Either please ignore the inconsistency, or visit
| the non-cached host variant.


[1] 
https://docs.pagure.org/copr.copr/user_documentation.html#build-succeeded-but-i-don-t-see-the-built-results

Pavel

> Miroslav
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Copr - look back at 2021

[Pavel Raiskup]

On Monday, January 3, 2022 11:30:42 AM CET Tomas Tomecek wrote:
> On Thu, Dec 30, 2021 at 3:35 PM Miroslav Suchý  wrote:
> 
> >
> >-
> >
> >Statistics:
> >-
> >
> >   Copr run 2,900,000 builds.
> >   -
> >
> >   People created 15 731 new projects.
> >
> >
> Whaaat! The whole list of things you have achieved is mega impressive but
> this one totally caught my eye: doing millions of builds per year.
> 
> I'm wondering how many of those projects were created by packit.

Frontend footer links this: https://copr.fedorainfracloud.org/db_dumps/
In case anyone wanted to do more analysis ...

coprdb=# select count(*) from copr where created_on > 1609459200 and created_on 
< 1640995200;
┌───┐
│ count │
├───┤
│ 15760 │
└───┘
(1 row)

coprdb=# select count(*) from copr where created_on > 1609459200 and created_on 
< 1640995200 and user_id = 5576;
┌───┐
│ count │
├───┤
│ 10037 │
└───┘
(1 row)

Most of the projects is from Packit.  Packit has though quite unusual use-case;
those projects are used for a short period of time (usually new project for
every PR), and contain only a few builds.

Builds statistics for Packit are not easy to get..  The old removed
projects (deleted=true, temporary projects...) have all the related Build
instances removed from DB.  But due to the nature of the CI builds I
suppose it will be somewhere below 100k.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Orphaned packages looking for new maintainers​​​

[Pavel Raiskup]

Hello Sumit, Blaise,

you both seem to be interested in maintaining plantuml, I believe you
could co-maintain that package together?  We use the package in our team
to automatically generate some diagrams, so it would be awesome if you
could take care it.

Per docs [1] I think you should go to the sponsors tracker [2] and formally try
to ask for sponsorship (I haven't seen your tickets there after a quick search
try)..

[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
[2] https://pagure.io/packager-sponsors/

Pavel

On Thursday, December 23, 2021 8:18:50 AM CET Sumit Garg wrote:
> Hello,
> 
> I am new to this group and not yet part of the Packager group.  I would like 
> to contribute in maintaining of orphan package plantuml, if I am allowed to 
> do so.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Pavel Raiskup]

On Wednesday, December 22, 2021 4:22:29 PM CET Neal Gompa wrote:
> On Wed, Dec 22, 2021 at 10:14 AM Pavel Raiskup  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.
&g

Re: Mock v2.16 release, mock-core-configs v36.4

[Pavel Raiskup]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[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





___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Pavel Raiskup]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[Pavel Raiskup]

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



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Mock v2.16 release, mock-core-configs v36.4

[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
> 
> 
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock v2.16 release, mock-core-configs v36.4

[Pavel Raiskup]

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


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Cloud image && virt-sysprep

[Pavel Raiskup]

On Monday, November 29, 2021 4:46:42 PM CET Daniel P. Berrangé wrote:
> On Mon, Nov 29, 2021 at 04:38:26PM +0100, Pavel Raiskup wrote:
> > On Monday, November 29, 2021 4:02:23 PM CET Daniel P. Berrangé wrote:
> > > On Mon, Nov 29, 2021 at 03:24:12PM +0100, Pavel Raiskup wrote:
> > > > Hello,
> > > > 
> > > > anyone had a successful experience with Fedora 35 Cloud images, and
> > > > guestfish/virt-sysprep?
> > > > 
> > > > Seems like we switched from ext4 or xfs to 'btrfs', and guestfish
> > > > doesn't work with the images, am I right?  At least I had problems
> > > > on EL8 hypervisors so far.  > 
> > > As a general rule, libguestfs is only guaranteed to work if the
> > > host OS is the same or newer than the guest OS. It might (and often
> > > does) work if the host OS is older than the guest, but that's pot
> > > luck.
> > > 
> > > The libguestfs appliance use the host kernel to access the filesystems,
> > > so if the guest OS kernel was newer, its filesystem may have used features
> > > that the host OS kernel doesn't understand.
> > > 
> > > IOW, my assumption is that Fedora 35 xfs is using fetures that RHEL8
> > > xfs doesn't support.
> > 
> > Ah, not xfs, but you helped me.  Now I understand what the message means :-)
> > 
> > $ virt-sysprep -a ...
> > [   0.0] Examining the guest ...
> > virt-sysprep: error: libguestfs error: inspect_os: mount exited with status 
> > 32: mount: /tmp/btrfse5L6v2: unknown filesystem type 'btrfs'.
> > 
> > This is the absence of 'btrfs' on EL8.  So there's no way out from this
> > on any currently supported RHEL, I bet.
> 
> I've not tried, but the container Neal points to in the other reply
> may still work, if it includes a Fedora kernel vmlinux that libguestfs
> can leverage. The host OS kernel is merely libguestfs' default choice,
> you can point it to other kernels if you have some available

I can confirm it works, libguestfs-appliance brings kernel-core into the
image.

Though, can I somehow manually point the host's libguestfs to the
alternative kernel (e.g. from extracted kernel-core.rpm from F35)?  I
mean.., it is really painful to fix our scripting to use the containerized
libguestfs.  If so, any command touching host filesystem needs to be
changed (e.g. copy-in/copy-out).  Also command-line arguments (-a) need to
be changed.

But it is indeed good enough for manual, one-time image tweaks (there are
some minor issues, like absence of Fedora 35 Dockerfile, the image isn't
in registries, etc.).

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 35 Cloud image && virt-sysprep

[Pavel Raiskup]

On Monday, November 29, 2021 4:02:23 PM CET Daniel P. Berrangé wrote:
> On Mon, Nov 29, 2021 at 03:24:12PM +0100, Pavel Raiskup wrote:
> > Hello,
> > 
> > anyone had a successful experience with Fedora 35 Cloud images, and
> > guestfish/virt-sysprep?
> > 
> > Seems like we switched from ext4 or xfs to 'btrfs', and guestfish
> > doesn't work with the images, am I right?  At least I had problems
> > on EL8 hypervisors so far.  > 
> As a general rule, libguestfs is only guaranteed to work if the
> host OS is the same or newer than the guest OS. It might (and often
> does) work if the host OS is older than the guest, but that's pot
> luck.
> 
> The libguestfs appliance use the host kernel to access the filesystems,
> so if the guest OS kernel was newer, its filesystem may have used features
> that the host OS kernel doesn't understand.
> 
> IOW, my assumption is that Fedora 35 xfs is using fetures that RHEL8
> xfs doesn't support.

Ah, not xfs, but you helped me.  Now I understand what the message means :-)

$ virt-sysprep -a ...
[   0.0] Examining the guest ...
virt-sysprep: error: libguestfs error: inspect_os: mount exited with status 
32: mount: /tmp/btrfse5L6v2: unknown filesystem type 'btrfs'.

This is the absence of 'btrfs' on EL8.  So there's no way out from this
on any currently supported RHEL, I bet.

Pavel

> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 35 Cloud image && virt-sysprep

[Pavel Raiskup]

Hello,

anyone had a successful experience with Fedora 35 Cloud images, and
guestfish/virt-sysprep?

Seems like we switched from ext4 or xfs to 'btrfs', and guestfish
doesn't work with the images, am I right?  At least I had problems
on EL8 hypervisors so far.

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock/Copr default epel-8-* configuration to be changed

[Pavel Raiskup]

Hello Fedora EPEL maintainers!

First I don't feel comfortable announcing this, I'm not happy about the
situation and so I don't want to be the lightning rod :-).  But I believe
that we can come to acceptable Copr/Mock solution and this needs to be
discussed...  so here we are.

By the end of the year 2021 we have to fix our default EPEL 8 Mock
configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
goes EOL by then.

The same thing needs to happen in Fedora Copr, with the epel-8-* chroots
(side note, in Fedora Copr we use the mock-core-configs package for builds
without any deployment specific modifications).

I am proposing (as PR against mock upstream ATM [1]) to switch the default
epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
(see the pull request [1]).

This would bring some consequences, namely newly with epel-8* chroots,

- builds will require a valid Red Hat subscription (the no-cost variant is
  OK as well, though [2])
- we will miss some build-time packages that Red Hat is not shipping, at
  least at the beginning till they are added (to RHEL CRB, or other
  currently unknown place).
- cross-arch compilation can not be used, Red Hat subscriptions don't
  allow that (using QEMU and rpm --forcearch), [3]

The positive thing is that the default configuration will be much closer
to the official EPEL builds (because Fedora Koji EPEL builds are actually done
also against RHEL).

For the Fedora Copr builders, we already have the necessary Red Hat
subscriptions in hand (will be deployed by the end of the year).  So we will
only loose the opportunity to build on emulated epel-8-armhfp permanently, and
epel-8-s390x temporarily (as we already work on the native s390x support).

Any thoughts?  Feedback is needed here.

[1] https://github.com/rpm-software-management/mock/pull/802
[2] https://rpm-software-management.github.io/mock/Feature-rhelchroots
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock v2.13 release

[Pavel Raiskup]

Hello!

I'm glad I can announce that we have a new release of Mock.  Two new
commandline options were added, and several bugs were fixed.  For more
info see the upstream release notes:

  https://rpm-software-management.github.io/mock/Release-Notes-2.13

Note that this release is likely the last v2 release being shipped both in
Fedora 33+ and EPEL 7+.  We'll keep v2 in bugfix mode for the purpose of
EPEL 7 builds, and elsewhere we'll forward with v3.  For more info see:
https://github.com/rpm-software-management/mock/issues/755

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

mock-core-configs-35-1 released

[Pavel Raiskup]

Hello,

I've just released the new mock-core-configs package:
https://github.com/rpm-software-management/mock/releases/tag/mock-core-configs-35-1

Updates are in Bodhi.

The new package ships Fedora 35 configuration;  and since we seem to already
have the composes available - I deployed the new configs to Fedora Copr and
enabled the Fedora 35 chroots (prepared by Jakub Kadlčík).

This update should also fix the recent Fedora Rawhide build failures,
sorry for the delay.

Pavel




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CentOS Sream 9 pre-release chroots added to Fedora Copr

[Pavel Raiskup]

On Friday, July 23, 2021 5:09:57 PM CEST Daniel P. Berrangé wrote:
> On Fri, Jul 23, 2021 at 03:25:15PM +0100, Daniel P. Berrangé wrote:
> > On Fri, Jul 23, 2021 at 04:03:06PM +0200, Pavel Raiskup wrote:
> > > The ppc64le doesn't seem to build on Power8 hardware we have [2], and
> > > s390x has some troubles with qemu emulation [3].  So those architectures
> > > are at least for now disabled.
> > 
> > 
> > > [3] Fatal glibc error: CPU lacks VXE support (z14 or later required),
> > > 
> > > https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz
> > 
> > I'm trying to find out from the s390x QEMU maintainers about the
> > likely fix requird to make this work.
> 
> It will be fixed in QEMU 6.1.0 which is coming out in a month-ish:
> 
>   https://wiki.qemu.org/Planning/6.1
> 
> and will be addressed by this patch series
> 
>   https://lore.kernel.org/qemu-devel/20210517142739.38597-1-da...@redhat.com/
> 
> This futur QEMU release will go into f35 rawhide, and virt-preview repo
> can be used if you will need it for f34

Nice, thank you for the reference!

I'm curious...  couldn't we run CentOS Stream 9 ppc64le builds through qemu
emulation as well?

Pavel

> Regards,
> Daniel
> -- 
> |: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

CentOS Sream 9 pre-release chroots added to Fedora Copr

[Pavel Raiskup]

Hi all,

just for the info, we enabled the `centos-stream-9-x86_64` and
`centos-stream-9-aarch64` chroots in Fedora Copr.  Note that we build
directly from composes [1] without mirrors (some failures can expected),
and that the packages are not GPG-signed.  You have been warned :-)

The ppc64le doesn't seem to build on Power8 hardware we have [2], and
s390x has some troubles with qemu emulation [3].  So those architectures
are at least for now disabled.

[1] https://github.com/rpm-software-management/mock/pull/751
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1985364
[3] Fatal glibc error: CPU lacks VXE support (z14 or later required),

https://download.copr-dev.fedorainfracloud.org/results/praiskup/ping/centos-stream-9-s390x/02135293-dummy-pkg/builder-live.log.gz

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Mock v2.12 release and mock-core-configs v34.5

[Pavel Raiskup]

Hello!

I'm glad I can announce that we have a new release of Mock + configs.
There are several small bugfixes, and many new configuration files (CentOS
Stream 9, Rocky, EPEL Next 8, Alma AArch64).  Release notes:
https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.12

Note that this release is likely the last v2 release being shipped both in
Fedora 33+ and EPEL 7+.  We'll keep v2 in bugfix mode for the purpose of
EPEL 7 builds, and elsewhere we'll forward with v3.  For more info see:
https://github.com/rpm-software-management/mock/issues/755

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Re: Do we need Mock supported on EL7?

[Pavel Raiskup]

On Saturday, July 17, 2021 3:18:02 PM CEST Stephen John Smoogen wrote:
> On Fri, 16 Jul 2021 at 17:59, Pavel Raiskup  wrote:
> >
> > We touched this topic several times before in our team.  Perhaps we should 
> > move
> > on and do it...  it would simplify a development (the yum/dnf hacks,
> > legacy systemd-nspawn hacks, podman requirement for building Fedora, etc.).
> >
> > I created an issue [1], can you please vote there if you are concerned?  If 
> > you
> > have a good argument for keeping the support, please write here or there (or
> > both).
> >
> > [1] https://github.com/rpm-software-management/mock/issues/755
> >
> 
> First off, what does this mean:
> 
> 1. you can't build EL7 packages anymore with mock? AKA we would need
> to stop building EPEL7

No.  E.g. Copr builders are on the latest Mock, on Fedora 34, and they build EL7
just fine.

> 2. you can't use "mock" on systems after the XYZ version?

Yes, Mock version XYZ will not be available on EL7. 

> Going from the graphs of growth, most of EL growth has been in EL7
> since last year. That said.. I expect that if there is a version which
> is 'known' to be the last working version of mock then people needing
> it can 'keep' that version on those systems as long as they need.

Exactly.
Pavel

> 
> > Thank you,
> > Pavel
> >
> >
> > ___
> > epel-devel mailing list -- epel-de...@lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-le...@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/epel-de...@lists.fedoraproject.org
> > Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> 
> 
> 
> -- 
> Stephen J Smoogen.
> I've seen things you people wouldn't believe. Flame wars in
> sci.astro.orion. I have seen SPAM filters overload because of Godwin's
> Law. All those moments will be lost in time... like posts on  BBS...
> time to reboot.
> ___
> epel-devel mailing list -- epel-de...@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@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/epel-de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] Do we need Mock supported on EL7?

[Pavel Raiskup]

On Saturday, July 17, 2021 9:08:48 PM CEST Nico Kadel-Garcia wrote:
> On Sat, Jul 17, 2021 at 9:19 AM Stephen John Smoogen  wrote:
> >
> > On Fri, 16 Jul 2021 at 17:59, Pavel Raiskup  wrote:
> > >
> > > We touched this topic several times before in our team.  Perhaps we 
> > > should move
> > > on and do it...  it would simplify a development (the yum/dnf hacks,
> > > legacy systemd-nspawn hacks, podman requirement for building Fedora, 
> > > etc.).
> > >
> > > I created an issue [1], can you please vote there if you are concerned?  
> > > If you
> > > have a good argument for keeping the support, please write here or there 
> > > (or
> > > both).
> > >
> > > [1] https://github.com/rpm-software-management/mock/issues/755
> > >
> >
> > First off, what does this mean:
> >
> > 1. you can't build EL7 packages anymore with mock? AKA we would need
> > to stop building EPEL7
> > 2. you can't use "mock" on systems after the XYZ version?
> >
> > Going from the graphs of growth, most of EL growth has been in EL7
> > since last year. That said.. I expect that if there is a version which
> > is 'known' to be the last working version of mock then people needing
> > it can 'keep' that version on those systems as long as they need.
> 
> I've done backports of mock for some operating systems, to get updated
> versions of mock-core-configs on Amazon Linux 2 for example.  You can
> still compile older operating systems on modern operating systems. The
> bigger problem is operating systems like Amazon Linux 2, or RHEL,
> where the basic software repositories are not publicly accessible to
> use on other systems. Either you have to use mock on those operating
> systems to build for them, or you need to set up an internal yum
> mirror with tools ike
> https://github.com/nkadel/nkadel-rsync-scripts/blob/master/reposync-rhel-6.sh
> .

We can build RHEL 7 just fine on RHEL 8 or on Fedora, without a local mirror.
https://github.com/rpm-software-management/mock/wiki/Feature-rhelchroots

If we faced with bottlenecks, going with bootstrap chroot or even bootstrap
image should help nowadays.

> EL 8 had its adoption poisoned by some very unwelcome choices by Red
> Hat. That's a long rant of its own, one I've stated before in the
> CentOS groups. But it means that EL 7 is going to be around a lot
> longer than people may wish. If we can keep mock working for EL 7 for
> longer, I'd be all on board. I especially want it for Amazon Linux 2,
> where I provided some support for the Samba developers to port current
> Samba releases to that EL 7 based but somewhat distinct environment.
> (python3 is python 3.7 there, and they have python 3.8 available:
> stuff built for RHEL 7 or CentOs 7 does not behave well there!)

The Mock on EL 7 should stay working for the extended life period.  Just
that it would not get updates with all bugfixes and new features.

Pavel


> Nico Kadel-Garcia
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Do we need Mock supported on EL7?

[Pavel Raiskup]

We touched this topic several times before in our team.  Perhaps we should move
on and do it...  it would simplify a development (the yum/dnf hacks,
legacy systemd-nspawn hacks, podman requirement for building Fedora, etc.).

I created an issue [1], can you please vote there if you are concerned?  If you
have a good argument for keeping the support, please write here or there (or
both).

[1] https://github.com/rpm-software-management/mock/issues/755

Thank you,
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning vim-syntastic, replacing with vim-ale

[Pavel Raiskup]

Hello, I'm orphaning the vim-syntastic package as I no longer use that
(I switched to vim-ale a few months back).  Feel free to pick that package,
if you happen to use it and you can not migrate - but upstream of syntastic
recommends the migration: https://github.com/vim-syntastic/syntastic/issues/2288

A typical bugreport there looks like rhbz#1834153 or rhbz#1955850.  The
packaging approach was kind of unsuccessful experiment (many
language-specific sub-packages depending on existing syntax checkers).
Perhaps, if anyone interested, that approach should be changed [see below].

I also observed there's a long-term issue in Fedora with excluding noarch
sub-packages.  By example, thing is that some language analyzers aren't
available on all Fedora architectures - but if some sub-package run-time
depends on such package - maintainer naturally wants to arch-exclude such
(noarch) sub-package from composes.  But there currently isn't a nice way
to do this.  https://pagure.io/pungi-fedora/issue/87

For vim-ale, I decided to go with simpler approach - where each user is
responsible for manually installing the backend syntax checkers.
Therefore, when vim-ale in installed, a complete set of vim configuration
(for all language checkers) is installed.  Vim-ale review request goes here:
https://bugzilla.redhat.com/show_bug.cgi?id=1974597

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

New Mock release v2.11 (mock-core-configs v34.4)

[Pavel Raiskup]

I'm pleased to announce that we have another Mock release:
https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.11

There are some bug-fixes, but also new features like the `%_platform_multiplier`
macro and `--install` command support for "external dependencies".  See the
release notes above for more info.

Bodhi update links:
Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9c978fcae6
Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8ee36d8295
EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b5054640a9
EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bea8f54571

Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

New Mock release v2.10

[Pavel Raiskup]

I'm pleased to announce that we have a new (small) Mock bugfix release.  Worth
mentioning is that there are many new config files in `mock-core-configs`
package.  Release notes are here:

https://github.com/rpm-software-management/mock/wiki/Release-Notes-2.10

Updates:

Fedora 34: https://bodhi.fedoraproject.org/updates/FEDORA-2021-281879244b
Fedora 33: https://bodhi.fedoraproject.org/updates/FEDORA-2021-63c40bf04d
Feodra 32: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7a8958c321
EPEL 8: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-df65033a42
EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-7c9d9cf44e

Happy building!
Pavel


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Kerberos and Fedora's 2FA UX

[Pavel Raiskup]

On Friday, April 23, 2021 7:40:14 AM CEST Miroslav Suchý wrote:
> I have been using 2FA with the new Fedora Account system and the UX is ... 
> can be improved. The question is how?
> 
> If you are not using 2FA yet then you may not know what I am talking about. 
> Here:
> 
> https://fedoraproject.org/wiki/Infrastructure/Kerberos#Command_line
> 
> You have to run:
> 
>  kinit -n @FEDORAPROJECT.ORG -c FILE:${HOME}/armor.ccache
> 
>  kinit -T FILE:${HOME}/armor.ccache @FEDORAPROJECT.ORG

Additional feedback, the prompt is misleading:

$ kinit -T FILE:${HOME}/.krb5-fedora-armor.ccache prais...@fedoraproject.org
Enter OTP Token Value:

But it actually wants Password+Token.

Pavel


> To obtain the Kerberos ticket.
> 
> I already created my personal alias for this in my bashrc, but can we create 
> some well known global alias for all 
> Fedora's devels? Any other idea how to improve the UX?
> 
> Miroslav
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure