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

[rpms/rt] PR #3: Don't build-require files outside of permitted directories

[Pavel Raiskup]

praiskup opened a new pull-request against the project: `rt` that you are 
following:
``
Don't build-require files outside of permitted directories
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/rt/pull-request/3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@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

[EPEL-devel] Re: Cannot run fedpkg mockbuild for epel9 on f38

[Pavel Raiskup]

On neděle 4. června 2023 4:21:54 CEST Todd Zullinger wrote:
> bradb...@seanet.com wrote:
> > I misspelled centos as contos  Now fedpkg mockbuild works  with the proper 
> > links:
> > 
> >>ls -l $HOME/.config/mock
> > total 8
> > lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-8-x86_64.cfg -> 
> > /etc/mock/centos-stream+epel-8-x86_64.cfg
> > lrwxrwxrwx. 1 bradbell bradbell 41 Jun  3 19:09 epel-9-x86_64.cfg -> 
> > /etc/mock/centos-stream+epel-9-x86_64.cfg
> 
> That's not what you want for epel though.  It will build
> against centos-stream rather than rhel/alma/rocky, i.e. the
> stable EL.  While it might appear to work, it will
> inevitably build packages which link against the wrong
> versions of libraries, pick up bogus dependencies, etc.
> 
> You want to pick one of the *+epel-[89]-x86_64.cfg config
> files.
> 
> I thought that previous fedpkg or mock releases printed a
> large banner which explained this a bit and linked to
> further details?  I would have thought that was still in
> place, but perhaps not.

Mock prints the banner you expect iff the corresponding epel-* symlink
doesn't exist (if it exists, user already made the decision).  This is
at least the desired behavior;  if Mock misbehaves, please report.

Pavel


___
epel-devel mailing list -- epel-devel@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-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

[rpms/perl-DBD-Pg] PR #1: Rebuild for PostgreSQL 15 (side-tag)

[Pavel Raiskup]

praiskup merged a pull-request against the project: `perl-DBD-Pg` that you are 
following.

Merged pull-request:

``
Rebuild for PostgreSQL 15 (side-tag)
``

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

[rpms/perl-DBD-Pg] PR #1: Rebuild for PostgreSQL 15 (side-tag)

[Pavel Raiskup]

praiskup commented on the pull-request: `Rebuild for PostgreSQL 15 (side-tag)` 
that you are following:
``
Going to merge now, and build against PostgreSQL 15 (proven packager action).
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-DBD-Pg/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

[EPEL-devel] Re: how to do epel8 fedpkg mockbuild?

[Pavel Raiskup]

On Wednesday, February 9, 2022 10:46:44 AM CET Dave Love wrote:
> Pavel Raiskup  writes:
> 
> > I'd encourage anyone to update to the latest fedpkg (v1.42):
> > https://bodhi.fedoraproject.org/updates/?packages=fedpkg
> >
> > And Mock (configs v36.6):
> > https://bodhi.fedoraproject.org/updates/?packages=mock
> 
> What I was using, in the hope it would help, is the latest in
> epel-testing (fedpkg-1.41-2, mock-2.16-1, and mock-core-configs-37-1).

You need the fedpkg-1.42, and even updated rpkg (from the very same Bodhi
update) in case its update is not "enforced" by fedpkg's Requires:.

> > Then mock should give a verbose hint about what to do.  For more info:
> > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/BNQ2TFWODJW3JSOBAG26AZQBOS5HHZMD/
> 
> So it will stay broken in EPEL7?

Not sure whether you mean building for EPEL 7 (in epel-7 chroot), or
building on EPEL 7 host but both cases should OK.

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



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

[EPEL-devel] Re: how to do epel8 fedpkg mockbuild?

[Pavel Raiskup]

On Monday, February 7, 2022 11:45:12 AM CET Dave Love wrote:
> > What do you need to do these days to run an epel-8 mock build?
> > fedpkg mockbuild fails for me with
> >
> > Error: Error downloading packages:
> >   Status code: 403 for
> > https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm
> > (IP: 38.145.60.16)
> 
> It turns out that it works if you link, say, the alma+epel mock config
> into ~/.config/mock/epel-8-x86_64.cfg, per Richard Shaw's question at
> around the same time.  I might have guessed that was the problem if it
> reported an error about epel-8-x86_64.cfg rather than failing to
> download RHEL rpms.  (I just had alma linked to default.cfg on the RHEL8
> system I use, not to epel-8.)

I'd encourage anyone to update to the latest fedpkg (v1.42):
https://bodhi.fedoraproject.org/updates/?packages=fedpkg

And Mock (configs v36.6):
https://bodhi.fedoraproject.org/updates/?packages=mock

Then mock should give a verbose hint about what to do.  For more info:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/BNQ2TFWODJW3JSOBAG26AZQBOS5HHZMD/

Pavel


___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] 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/de...@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/
> > 
> > Pavel
> > 
> 
> 



___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] 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/de...@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/
> 
> Pavel
> 



___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] 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.


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

[EPEL-devel] 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/de...@lists.fedoraproject.org/thread/7T5N6SCPCWHNAUIFPFD54Z6CTLLZMJ6F/

Pavel


___
epel-devel mailing list -- epel-devel@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-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.
> > ERROR: Project page: https://rockylinux.org/
> > ERR

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

[EPEL-devel] 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


___
epel-devel mailing list -- epel-devel@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-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

[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-devel@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-devel@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-devel@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-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] Re: 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 -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 



___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] 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


___
epel-devel mailing list -- epel-devel@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-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

[EPEL-devel] Re: EPEL build target in COPR

[Pavel Raiskup]

On Wednesday, May 19, 2021 1:57:17 AM CEST Leon Fauster wrote:
> Dear all, the EPEL build target in COPR build packages based on
> CentOS Linux 8. What happens at EOL of CentOS Linux 8?  Any clues?

Copr just uses `mock-core-configs` package, and the `epel-*.cfg` files
there.

I believe that anyone who will need to do local builds (including Fedora
Copr) will be able to get the appropriate subscription [1], and so we'll
be able to change the epel-8 config from centos+epel to rhel+epel in
mock-core-configs.  Btw. there already are some `rhelepel-*` configs
(feel free to try them, as that's what will be in epel-*, see also [2]).

I also believe that we'll be able to have some subscription for
Fedora Copr builders that will allow us to continue using
mock-core-configs in default variant.

Cross-arch builds (--forcearch) will stop working till bz#1912847 is fixed, and
this would affect Copr.

> BTW, I assume that EPEL stuff are build on RHEL.

EPEL content is built in Koji _against_ RHEL+EPEL repos.

> RHEL8.4 is out now and new EPEL builds would be done on EL8.4 while COPR
> is bounded to CL8.3 ... mmh?

I thought that this is normal situation (8.4 release is fresh), and that
CentOS 8 is supported till the end of this year - so please correct me if
I'm wrong but CentOS 8 should still get the 8.4 update?

[1] 
http://miroslav.suchy.cz/blog/archives/2021/02/08/how_to_activate_no-cost_rhel_subscription/index.html
[2] https://github.com/rpm-software-management/mock/wiki/Feature-rhelchroots

Pavel

> --
> Leon



___
epel-devel mailing list -- epel-devel@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-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

Re: What do we think about always autoreconfing?

[Pavel Raiskup]

On Tuesday, April 13, 2021 3:50:18 PM CEST Florian Weimer wrote:
> * Neal Gompa:
> 
> > As I said previously[1], I think doing autoconf upgrades would be less
> > painful if we always did that.
> >
> > [1]: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZZG3SNLFS7BSXQ3JFJDOWUS3WWGTGLR2/
> 
> I think that's not actually true: If we do not build from source, it
> doesn't matter if the compiler produces a working executable program
> from the old sources.

This is interesting perspective, but I doubt that changing the status quo
would bring much practical difference.  As long as there are no problems,
people don't review the generated files like configure, config.status, ...
no matter if autoreconfed in Fedora, or upstream.

Doing so may also bring an additional level of non-determinism.

For packages that don't patch auto* inputs nowadays it can bring
significant build-time problems.

The problem is that autoconf macros are hard, often misunderstood, some
things change, older auto* versions are more tolerant, ... and fixing
FTBFSs is non-trivial for many package maintainers.

Btw., the fact that there are even now so many packages BuildRequiring
autotools brings the significant fear from actually updating autotools in
distributions (contrary to what I would wish, e.g. in EL).

> Apart from the build-from-source principle, there are other advantages.
> It may be easier to adopt new architectures and toolchain versions.

At least config.sub and config.guess are automatically replaced by
%configure even now.

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

Highlights from the 2021-03-17 Copr release

[Pavel Raiskup]

Hello!

We are pleased to announce that today, March 13 2020, a new Copr release landed
production.  The list of user visible changes is in the release notes document:

https://docs.pagure.org/copr.copr/release-notes/2021-03-17.html

Namely we introduced Fedora Review feature, and we plan to rename
'centos-stream' to 'centos-stream-8' very soon.

On Tuesday, March 16, 2021 10:52:38 AM CET Pavel Raiskup wrote:
> There will be an outage starting at:
> $ date --date '2021-03-17 12:15 UTC'

And the outage is over now.

Happy building!
Copr Team


___
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: Local/Copr Rawhide build failures due to GPG check [Was: Fedora 34 Mass Branching]

[Pavel Raiskup]

On Friday, February 12, 2021 7:05:28 PM CET Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 11, 2021 at 03:33:14PM +0100, Pavel Raiskup wrote:
> > On Thursday, February 11, 2021 2:24:28 PM CET Zbigniew Jędrzejewski-Szmek 
> > wrote:
> > > On Thu, Feb 11, 2021 at 10:19:25AM +0100, Pavel Raiskup wrote:
> > > > On Wednesday, February 10, 2021 2:49:00 PM CET Pavel Raiskup wrote:
> > > > > On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote:
> > > > > > On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote:
> > > > > > > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I were unable to find time in the schedule, at which the new 
> > > > > > > > F35 GPG key
> > > > > > > > would be activated to sign new builds.
> > > > > > >
> > > > > > > It will be done a week before mass branching, but we are thinking 
> > > > > > > of
> > > > > > > doing it a bit earlier to give more time.
> > > > > >
> > > > > > I think we should make the f36 key right now and add it to 
> > > > > > fedora-repos
> > > > > > and push it out to all branches. Then, when we get to f35 
> > > > > > branching, we
> > > > > > make the f37 key (ie, we stay 6 months ahead).
> > > > > >
> > > > > > This way everyone has the new key already and there's no scrambling.
> > > > > >
> > > > > > (or this week, doesn't have to be today, just soon)
> > > > >
> > > > > Yes please!  Something along those lines was proposed before, because 
> > > > > it
> > > > > significantly eases mock maintenance during the branching period.  
> > > > > E.g.
> > > > > now, at the time of F34 branching we already have released
> > > > > mock-core-configs (check updates-testing) with new F35 configuration 
> > > > > and
> > > > > everything should be working.
> > > > >
> > > > > Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos
> > > > > (still equivalent to rawhide), fedora-35-x86_64 config is symlink to
> > > > > rawhide, and builds against rawhide (still f34).  So the only thing 
> > > > > users
> > > > > will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily
> > > > > producing RPMs with fc34 %dist tag and this will automatically change 
> > > > > once
> > > > > the mirrors are updated.
> > > > >
> > > > > It works now because the gpg keys have been generated a bit in 
> > > > > advance for
> > > > > a few last fedora releases (in copr team we try to notify 
> > > > > administrators
> > > > > to do that), but having it 6 months in advance will be better (less 
> > > > > rush).
> > > > > I think we should dump this to the branching policy/howto documents 
> > > > > so we
> > > > > don't have to manually track that.  Finally, if we could document 
> > > > > there
> > > > > that updated distribution-gpg-keys and mock-core-configs packages 
> > > > > should
> > > > > be released, it would be an awesome help ...
> > > > 
> > > > And we forgot to bump one configuration option in mock-core-configs, 
> > > > which
> > > > eventually broke the fluent branching process in mock.  The related 
> > > > mock failure
> > > > looks like this:
> > > > 
> > > > >>  [SKIPPED] zlib-1.2.11-24.fc34.x86_64.rpm: Already downloaded
> > > > >>  warning: 
> > > > >> /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1613034650.541875/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm:
> > > > >>  Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY
> > > > >>  fedora  1.6 MB/s | 1.6 kB   
> > > > >>   00:00
> > > > >>  GPG key at 
> > > > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary
> > > > >>  (0x45719A39) is already installe

Re: Local/Copr Rawhide build failures due to GPG check [Was: Fedora 34 Mass Branching]

[Pavel Raiskup]

On Thursday, February 11, 2021 2:24:28 PM CET Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Feb 11, 2021 at 10:19:25AM +0100, Pavel Raiskup wrote:
> > On Wednesday, February 10, 2021 2:49:00 PM CET Pavel Raiskup wrote:
> > > On Wednesday, February 10, 2021 12:29:51 AM CET Kevin Fenzi wrote:
> > > > On Tue, Feb 09, 2021 at 06:19:41PM -0500, Mohan Boddu wrote:
> > > > > On Mon, Feb 8, 2021 at 7:18 PM Petr Menšík  
> > > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I were unable to find time in the schedule, at which the new F35 
> > > > > > GPG key
> > > > > > would be activated to sign new builds.
> > > > >
> > > > > It will be done a week before mass branching, but we are thinking of
> > > > > doing it a bit earlier to give more time.
> > > >
> > > > I think we should make the f36 key right now and add it to fedora-repos
> > > > and push it out to all branches. Then, when we get to f35 branching, we
> > > > make the f37 key (ie, we stay 6 months ahead).
> > > >
> > > > This way everyone has the new key already and there's no scrambling.
> > > >
> > > > (or this week, doesn't have to be today, just soon)
> > >
> > > Yes please!  Something along those lines was proposed before, because it
> > > significantly eases mock maintenance during the branching period.  E.g.
> > > now, at the time of F34 branching we already have released
> > > mock-core-configs (check updates-testing) with new F35 configuration and
> > > everything should be working.
> > >
> > > Sure, temporarily, the fedora-34-x86_64 chroot builds against 34 repos
> > > (still equivalent to rawhide), fedora-35-x86_64 config is symlink to
> > > rawhide, and builds against rawhide (still f34).  So the only thing users
> > > will observe that 'fedora-rawhide-*' and 'fedora-35-*' are temporarily
> > > producing RPMs with fc34 %dist tag and this will automatically change once
> > > the mirrors are updated.
> > >
> > > It works now because the gpg keys have been generated a bit in advance for
> > > a few last fedora releases (in copr team we try to notify administrators
> > > to do that), but having it 6 months in advance will be better (less rush).
> > > I think we should dump this to the branching policy/howto documents so we
> > > don't have to manually track that.  Finally, if we could document there
> > > that updated distribution-gpg-keys and mock-core-configs packages should
> > > be released, it would be an awesome help ...
> > 
> > And we forgot to bump one configuration option in mock-core-configs, which
> > eventually broke the fluent branching process in mock.  The related mock 
> > failure
> > looks like this:
> > 
> > >>  [SKIPPED] zlib-1.2.11-24.fc34.x86_64.rpm: Already downloaded
> > >>  warning: 
> > >> /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1613034650.541875/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm:
> > >>  Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY
> > >>  fedora  1.6 MB/s | 1.6 kB 
> > >> 00:00
> > >>  GPG key at 
> > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary
> > >>  (0x45719A39) is already installed
> > >>  fedora  1.6 MB/s | 1.6 kB 
> > >> 00:00
> > >>  GPG key at 
> > >> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary
> > >>  (0x45719A39) is already installed
> > 
> > 
> > I've just wrapped a new mock-core-configs release which has the fix, and 
> > updated
> > the builds in bodhi updates.
> 
> Hmm, I still see a failure:
> warning: 
> /var/lib/mock/fedora-rawhide-x86_64-bootstrap/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/fedora-gpg-keys-35-0.1.noarch.rpm:
>  Header V4 RSA/SHA256 Signature, key ID 9867c58f: NOKEY
> fedora
> 1.6 MB/s | 1.6 kB 00:00
> GPG key at 
> file:///usr/share/distribution-gpg-keys/fedora/RPM-GPG-KEY-fedora-34-primary 
> (0x45719A39) is already installed
> fedora
> 1.6 MB/s | 1.6 kB 00:00
> GPG key at