Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

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

Indeed.

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

/me nods

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

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

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

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

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

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

Pavel

> Cheers
> Michael
> 
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Michael J Gruber]

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

Mutual misunderstanding, I guess ;-)

What I meant was the following: Say we have two mock configs A and B
which are "the same" (one links to the other), such as:

- fedora-rawhide and fedora-42 (as of now)
- epel-7 and centos+epel-7 (now in eol)

Then local builds would use one buildroot for both A and B. OTOH, if
copr offers A and B, then this would create 2 chroots and different
builds.

I (mis?)-understood your suggestion as having both A and B in copr in
such cases. My suggestion was to offer, say, A only (not B) in copr and
have "this is the same as B" as a description.

Looking at current state, we have for example:
- mock core config: rhel+epel-9 (but no epel-9)
- copr: epel-9 with description "Builds are done against RHEL + EPEL."
  (but no rhel+epel)

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

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

Cheers
Michael
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

Hello Michael,

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

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

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

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

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

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

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

Pavel


> Cheers
> Michael
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

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

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

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

Enjoy the weekend, and happy building!
Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Michael J Gruber]

Pavel Raiskup venit, vidit, dixit 2024-08-16 11:06:21:
> On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
> > Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> > > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup  wrote:
> > > >
> > > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > > to the "rhel+epel-*" chroots from `mock-core-configs` package.  We'd
> > > > like to have the same approach for `epel-10` once there's a released
> > > > variant of RHEL 10 GA.
> > > >
> > > > For now though, there's the variant `centos-stream+epel-10` in the new
> > > > mock-core-configs release, though:
> > > >
> > > > 
> > > > https://rpm-software-management.github.io/mock/Release-Notes-Configs-41.1
> > > >
> > > > So we could make `epel-10-*` an alias to `centos-stream+epel-10` for the
> > > > time being, and do the switch to `rhel+epel-10` later on.  Do you think
> > > > this makes sense?  Or is it just too early?
> > > >
> > > 
> > > For EPEL 10, we would never do that switch. CentOS Stream + EPEL is
> > > the default case for EPEL 10 now. RHEL + EPEL configs are the
> > > alternative.
> 
> Don't you have a documentation link for this?
> 
> > > So we would just have the alias and keep it "forever".
> > 
> > I think we're mixing "mock core config name" and "copr chroot name" in
> > this dicussion.
> 
> One of the things Copr tries to do is to use mock-core-configs as-is
> (unchanged);  while the previous epel-N chroots were tricky, the change
> Neal mentioned seems to fix this!

We're on the same board here!

> > epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock.
> > Everything else is explicit (centos-stream+epel, rhel+epel, ...).
> > 
> > The copr chroots epel-* etc always made me look twice what they actually
> > are. Even switching the meaning "in between" makes it only.
> 
> Indeed, this is tricky.  Another best effort Fedora Copr goal was to
> be as close to Fedora Koji as possible.  So if Koji builds particular
> EPEL-N against {RHEL,CentOS,CentOS Stream}+EPEL, Fedora Copr (and
> mock-core-configs, too) wants to do the same thing (even though by
> default an official released set of packages is used instead of
> pre-release official buildroot).

Yep!

> 
> > And I really think epel-* makes no sense since it's always "+" to
> > something. EPEL guidelines spell out what is the official base distro
> > for which EPEL (next or what not). That is something we could add next
> > to the respective chroot in copr (just like the current remarks there).
> 
> The 'epel-10' chroot in Copr and mock-core-configs makes sense for
> user's convenience, and I believe we want to have it.  That's NB also
> the default "dnf copr enable" choice on Enterprise Linux machines.

In mock-core-configs probably, because users don't have to look up which
config is "for epel-9", e.g., or which release is "rawhide".

But there's a difference betwen mock and copr here:
- If I built in mock f41 (last week) which is a link to rawhide I in
  fact used the rawhide buildroot etc, not a copy of it. (disttag f41,
  and methinks rawhide should link to f41, not vice versa, but that's a
  different issue)

- If I build in mock against chroots for linked mock configs I have
  separate buildroots and builds.

I don't think we want the latter, but I may be wrong.
 
> Can you give me the corresponding link to the EPEL guidelines?

I'm not sure whether the target base info is technically part of the
policy in the policy page, but that's what I was thinking of:

https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy

Cheers
Michael
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Peter Lemenkov]

Thanks!
I've found it and added "latest"
(https://kojipkgs.fedoraproject.org/repos/f40-build/latest/x86_64/ )
to the list of extra repositories. Later I'll switch to side tags as
Florian suggested.


On Fri, Aug 16, 2024 at 11:11 AM Pavel Raiskup  wrote:
>
> On čtvrtek 15. srpna 2024 22:27:11, SELČ Florian Weimer wrote:
> > * Peter Lemenkov:
> >
> > > Hello All!
> > > I have a few Bodhi build overrides and I love to use them in Copr. Is
> > > it possible? At least is it possible to enable updates-testing
> > > repository?
> >
> > You can request a side tag and reference its repository in the Copr
> > configuration.  The repositories have URLs like this one:
> >
> >   <https://koji.fedoraproject.org/repos/f42-build-side-94256/>
> >
> > (I don't think I've ever tried this, but I don't see a reason why it
> > wouldn't work, either.)
>
> Yes, this would work!
>
> NB. the particular overrides are added in the real Koji buildroot, which
> itself may be accessed via baseurls (External Repositories in Copr)
> like:
>
> https://kojipkgs.fedoraproject.org/repos/f40-build/latest/x86_64/
>
> (alternative to `mock -r fedora-40-x86_64 --enablerepo=local`)
>
> Pavel
>
>
>
> > Thanks,
> > Florian
> >
> >
>
>
>
>


--
With best regards, Peter Lemenkov.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

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

Yes, this would work!

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

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

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

Pavel



> Thanks,
> Florian
> 
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

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

Don't you have a documentation link for this?

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

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

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

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

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

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

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

Pavel




> Cheers
> Michael
> 




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Florian Weimer]

* Peter Lemenkov:

> Hello All!
> I have a few Bodhi build overrides and I love to use them in Copr. Is
> it possible? At least is it possible to enable updates-testing
> repository?

You can request a side tag and reference its repository in the Copr
configuration.  The repositories have URLs like this one:

  <https://koji.fedoraproject.org/repos/f42-build-side-94256/>

(I don't think I've ever tried this, but I don't see a reason why it
wouldn't work, either.)

Thanks,
Florian

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Is it possible for Copr to use Bodhi build overrides?

[Peter Lemenkov]

Hello All!
I have a few Bodhi build overrides and I love to use them in Copr. Is
it possible? At least is it possible to enable updates-testing
repository?

-- 
With best regards, Peter Lemenkov.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Michael J Gruber]

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

I think we're mixing "mock core config name" and "copr chroot name" in
this dicussion.

epel-7-x86_64.cfg is the latest epel-* mock config I see in /etc/mock.
Everything else is explicit (centos-stream+epel, rhel+epel, ...).

The copr chroots epel-* etc always made me look twice what they actually
are. Even switching the meaning "in between" makes it only.

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

Cheers
Michael
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Early adopting EPEL 10 in Fedora Copr?

[Neal Gompa]

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

For EPEL 10, we would never do that switch. CentOS Stream + EPEL is
the default case for EPEL 10 now. RHEL + EPEL configs are the
alternative.

So we would just have the alias and keep it "forever".




--
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Early adopting EPEL 10 in Fedora Copr?

[Pavel Raiskup]

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

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

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

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

Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Iñaki Ucar]

On Thu, 18 Jul 2024 at 08:19, Pavel Raiskup  wrote:

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

AFAIK, the max number of builds option applies to *any* build, successful
or not. This is not useful, and I think I opened an RFE at some point. For
me, this would become useful if this value applies to successful and failed
builds separately. I would use it in this way to keep just the latest
successful build *and* the latest failed build in case a package breaks.
And this would save a lot of space. But with the current behavior, I just
cannot risk it.

-- 
Iñaki Úcar
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

Pavel Raiskup wrote:
> Yes, I believe there are high chances to accept this (much harder will
> to prioritize the feature).  If you know what you are doing, the point
> should not be to make the prolonging process click-expensive - which it
> admittedly is now, if you maintain dozens of long-term projects.  Note
> that OTOH I still think that *we all* should actively push our users to
> evacuate EOL Fedora releases.
> 
> IMO, the point is to keep the maintainer active, and get the response
> periodically.  But sure, once we have the RFE, we'll have a proper place
> to discuss it with the rest of the Copr team.

OK, I have filed the RFE:
https://github.com/fedora-copr/copr/issues/

I would have marked it with the RFE label, but I am not allowed to set 
labels as the reporter, only team members can do that.

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

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

[Pavel Raiskup]

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

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

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

Pavel

> Kevin Kofler
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

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

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

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

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

What is proposed here is:

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

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

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

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

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

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

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

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

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

Pavel




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

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

I remember having once suggested that on this mailing list and having 
received a quite negative reply from a Copr team member, saying that they 
deliberately did not want to make it that easy to extend everything. But if 
you think the RFE has a serious chance of being considered, I can file one.

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

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

[David Bold]

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

But that would still keep those builds forever.

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

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

I would like to have the options to delete all builds automatically after a 
month, instead I have to manually delete them.
As far as I could see there is only an option to automatically delete the whole 
project, but not to delete builds after a given time.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Adam Samalik]

On Wed, 17 Jul 2024 at 10:54, Pavel Raiskup  wrote:

> On úterý 16. července 2024 15:22:56, SELČ Stephen Gallagher wrote:
> > On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup 
> wrote:
> >
> > [snip]
> >
> > > Do you suggest moving rawhide to branched, and start with a fresh
> (empty)
> > > rawhide chroots for every branching?
> >
> > Yes, that was exactly what I was suggesting. (Well, possibly with
> > auto-triggering builds for the new chroot if the option to follow
> > Fedora branching is enabled).
>
> Starting from scratch would definitely be an alternative option (WRT to
> storage consumption), even more radical though.  Some of the projects in
> Copr require non-trivial bootstrapping procedures (not as complicated as
> Fedora itself, but still).
>

What if you copied the latest build for each package to the "new"
rawhide chroot? That way all the builds should be able to continue
without bootstrapping as they do now, without having to store the
entire build history.


>
> Automatic rebuilds - yes - sounds like a good RFE - but it wouldn't
> solve the storage consumption problem (eventually, without the
> ability to hardlink across chroots, the feature would consume even
> more storage).  I thought we already have a ticket/RFE one for this, but
> I can't find it...  But note, because of the bootstrapping issues above
> - it would anyway be easier to start with "Fedora N-1" packages and
> re-build everything against them, rather than start from scratch (or at
> least have yet another option so user can choose the preferred rebuild
> mode).
>
> Pavel
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Adam Samalik
---
Principal Software Engineer
Red Hat
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

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

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

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

Pavel



-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Stephen Gallagher]

On Tue, Jul 16, 2024 at 3:44 AM Pavel Raiskup  wrote:
>
> On pondělí 15. července 2024 16:32:45, SELČ Stephen Gallagher wrote:
> > On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý  wrote:
> > >
> > > Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
> > >
> > > Instead of always keeping "Rawhide" around as a separate buildroot,
> > > why not just rename it at Branching and then create a NEW Rawhide
> > > chroot?
> > >
> > > 1) Different workflow compared to the one we have in Fedora.
> >
> > How do you mean?
> >
> > > 2) Create it with what? Empty content ("why you are forcing be to rebuild 
> > > everything")? Copy everything (you end up in the same situation)? Rebuild 
> > > packages from previous rawhide (what if it fails to build? what if it 
> > > succeed but no one uses it anyway?).
> >
> > Let me flip it around: how did you create "Fedora 40" when Rawhide
> > branched for that? I'm just saying to do it the other way around.
>
> Actually, I think the current Copr process is similar to what Fedora
> does.  We hardlink the RPMs to branched chroot and run createrepo_c
> (unless user decides this is unwanted behavior, and opts-out).
> There's no need to re-sign the RPMs, sure - as the signature is shared
> for all the project's chroots.
>
> Do you suggest moving rawhide to branched, and start with a fresh (empty)
> rawhide chroots for every branching?
>

Yes, that was exactly what I was suggesting. (Well, possibly with
auto-triggering builds for the new chroot if the option to follow
Fedora branching is enabled).

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

Thank you for the reply, Kevin.

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

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

Pavel

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



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

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

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

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

Pavel


signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Miroslav Suchý]

Dne 16. 07. 24 v 3:34 dop. Kevin Kofler via devel napsal(a):

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


Amazon provides the infrastructure for free. Including the storage. But.

1) complexity of maintanance is not for free.

2) If your friend is like honey, you don't have to eat him all at once. 
(/Arabic proverb/)

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Pavel Raiskup]

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

Thank you for the reply.

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

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

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

Pavel


> -- Sandro
> 
> 



signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Kevin Kofler via devel]

Pavel Raiskup wrote:
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds.  Currently, Rawhide build results are kept indefinitely, but
> this is going to change in the future.
> 
> For the full story, see the blog post:
> https://fedora-copr.github.io/posts/cleanup-rawhide-builds
> 
> TL;DR: We plan to start monitoring build activity in Copr projects.
> If no builds appear for a long time in these "rolling" chroots (such as
> Fedora Rawhide), we'll disable such chroots, preserve the built results
> for a while, and then delete them if no action is taken by the user.
> 
> Hope this isn't going to cause too much inconvenience.  Feel free to
> discuss this here or under the blog post.

So Copr is going even further with this broken approach of deleting user 
data to "address storage consumption". As I have already stated several 
times, deleting user data by default (on an opt-out basis) is NEVER 
acceptable.

Even more so if the opt-out requires one to fight Copr's dark patterns 
deliberately making it a pain in the neck: One has to log into Copr every so 
often, and each time click a whole bunch of "Extend" buttons one at a time. 
There is no way to opt out permanently nor even for a longer time period 
than the default, nor even an "Extend All" button.

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

Kevin Kofler

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Stephen Gallagher]

On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý  wrote:
>
> Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
>
> Instead of always keeping "Rawhide" around as a separate buildroot,
> why not just rename it at Branching and then create a NEW Rawhide
> chroot?
>
> 1) Different workflow compared to the one we have in Fedora.

How do you mean?

>
> 2) Create it with what? Empty content ("why you are forcing be to rebuild 
> everything")? Copy everything (you end up in the same situation)? Rebuild 
> packages from previous rawhide (what if it fails to build? what if it succeed 
> but no one uses it anyway?).

Let me flip it around: how did you create "Fedora 40" when Rawhide
branched for that? I'm just saying to do it the other way around.

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Miroslav Suchý]

Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):

Instead of always keeping "Rawhide" around as a separate buildroot,
why not just rename it at Branching and then create a NEW Rawhide
chroot?


1) Different workflow compared to the one we have in Fedora.

2) Create it with what? Empty content ("why you are forcing be to rebuild everything")? Copy everything (you end up in 
the same situation)? Rebuild packages from previous rawhide (what if it fails to build? what if it succeed but no one 
uses it anyway?).


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Stephen Gallagher]

On Mon, Jul 15, 2024 at 4:25 AM Pavel Raiskup  wrote:
>
> Hello maintainers.
>
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds.  Currently, Rawhide build results are kept indefinitely, but
> this is going to change in the future.
>
> For the full story, see the blog post:
> https://fedora-copr.github.io/posts/cleanup-rawhide-builds
>
> TL;DR: We plan to start monitoring build activity in Copr projects.
> If no builds appear for a long time in these "rolling" chroots (such as
> Fedora Rawhide), we'll disable such chroots, preserve the built results
> for a while, and then delete them if no action is taken by the user.
>
> Hope this isn't going to cause too much inconvenience.  Feel free to
> discuss this here or under the blog post.

Rather than keep them indefinitely, why don't the "Rawhide" builds
just become the equivalent Branched buildroot?

Instead of always keeping "Rawhide" around as a separate buildroot,
why not just rename it at Branching and then create a NEW Rawhide
chroot?

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Sandro via devel]

On 15-07-2024 10:24, Pavel Raiskup wrote:

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


Thanks for the very early heads up. Will you provide more details 
regarding build retention? Without it it's kinda hard to judge the impact.


I can think of at least one project I'm looking after that won't see 
many updates. It's kind of there for convenience.


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


-- Sandro

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

The future Fedora Copr "rolling" chroot cleanup policy

[Pavel Raiskup]

Hello maintainers.

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

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

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

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


signature.asc
Description: This is a digitally signed message part.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Duplicate NEVRAs in Copr repositories - future breakage

[Pavel Raiskup]

Hello maintainers,

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

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

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

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

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

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

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

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

Thank you, and happy building!

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

Pavel


signature.asc
Description: This is a digitally signed message part.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Disabling Fedora 38 chroots in Copr

[Pavel Raiskup]

Hello,

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

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

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

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

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

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

Pavel


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: User SSH access to Copr builders

[Frederic Berat]

That's great news !

Thanks.

On Tue, Mar 19, 2024 at 12:56 PM Jakub Kadlcik  wrote:

> Hello,
> this may be a useful feature for many people, so I wanted to announce it
> separately.
>
> Debugging failed Copr builds became much easier with the last release.
> https://docs.pagure.org/copr.copr/release-notes/2024-03-07.html
>
> You can now enable SSH access to the builder, connect using your pubkey,
> and run any commands you need to debug the issue. Everything is explained
> in my blog post.
> https://frostyx.cz/posts/ssh-access-to-copr-builders
>
> Jakub
> --
> ___
> 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

User SSH access to Copr builders

[Jakub Kadlcik]

Hello,
this may be a useful feature for many people, so I wanted to announce it
separately.

Debugging failed Copr builds became much easier with the last release.
https://docs.pagure.org/copr.copr/release-notes/2024-03-07.html

You can now enable SSH access to the builder, connect using your pubkey,
and run any commands you need to debug the issue. Everything is explained
in my blog post.
https://frostyx.cz/posts/ssh-access-to-copr-builders

Jakub
--
___
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 Review feature in Copr and Fedora Review Service work again

[Jakub Kadlcik]

Hello fellow package maintainers,
we had multiple reports over the last weeks that the fedora-review feature
in Copr produces empty review.txt templates for F40 and Fedora Rawhide. And
as a consequence the Fedora Review Service points to empty review.txt files.

The issue is in the fedora-review tool and it is related to the migration
to DNF5 in new Fedora versions. I am proposing the following fix
https://pagure.io/FedoraReview/pull-request/513 but I decided not to wait
for it to get merged and released.

I applied the proposed patch on Copr builders so everything should work as
expected now. My apologies once again for the downtime.

Jakub
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Neal Gompa]

On Mon, Feb 19, 2024 at 10:18 AM Stephen Smoogen  wrote:
>
>
>
> On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel 
>  wrote:
>>
>> Stephen Smoogen wrote:
>> > 1. Drive size is not just what is needed but also throughput. The large
>> > drives needed to store the data COPR uses for its hundreds of chroots are
>> > much 'slower' on reads and writes even when adding in layers of RAID 1+0.
>> > Faster drives are possible but the price goes up considerably.
>> > 2. Throughput of individual drives also requires backplane speeds which
>> > match peek throughput of all the drives. Otherwise you end up with lots of
>> > weird stalling (as seen on certain builders which have such drives).
>>
>> What kind of throughput is needed for a repository that has not seen any new
>> builds for 2 years? Such a repository is going get only a handful downloads
>> and no uploads. Instead of deleting old repositories, they can be moved to a
>> low-throughput archive storage. This can be made transparent through
>> symlinks, union file systems, or even just at the HTTPS level if Copr itself
>> knows how to unarchive a repository when internally needed (e.g., if a new
>> build is submitted after 2 years of inactivity).
>>
>
> The throughput is actually in several places even for low/no usage 
> repositories.
> 1. RAID rebuilds will need to go through and check data. RAID-1 might seem 
> like a no-brainer but you tend to end up with 'which of these two disks is 
> the correct bit' over time problems.
> 2. web-spiders and such regularly peruse pretty much every package regularly. 
> Putting some repositories on slow disks and some on fast tend to cause web 
> front ends to pause out for unrelated tasks unless you set up your caching 
> and other middleware to deal with it. [This I know from when I tried to make 
> something more 'efficient' on downloads.fedoraproject.org and from some other 
> tooling.] It becomes a complete project of setting up the infrastructure to 
> best handle mixed loads. If you have a limited staff then it may be too much 
> work.
>
> That said, the above does sound like an interesting project to add to copr. I 
> do not know how much work it would take or who would be able to do it these 
> days. [My understanding is that COPR is 'one of many things' that the various 
> developers work on with most of the work done as a volunteer task.]
>

A lot of these problems may go away in the future once the Pulp
backend for COPR is ready. That will allow repository storage to move
from EBS to S3, and repositories in S3 can be set with different
policies wrt to CloudFront for transparent CDN performance.

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



-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted - pruning old rawhide chroots in Copr

[Stephen Smoogen]

On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Stephen Smoogen wrote:
> > 1. Drive size is not just what is needed but also throughput. The large
> > drives needed to store the data COPR uses for its hundreds of chroots are
> > much 'slower' on reads and writes even when adding in layers of RAID 1+0.
> > Faster drives are possible but the price goes up considerably.
> > 2. Throughput of individual drives also requires backplane speeds which
> > match peek throughput of all the drives. Otherwise you end up with lots
> of
> > weird stalling (as seen on certain builders which have such drives).
>
> What kind of throughput is needed for a repository that has not seen any
> new
> builds for 2 years? Such a repository is going get only a handful
> downloads
> and no uploads. Instead of deleting old repositories, they can be moved to
> a
> low-throughput archive storage. This can be made transparent through
> symlinks, union file systems, or even just at the HTTPS level if Copr
> itself
> knows how to unarchive a repository when internally needed (e.g., if a new
> build is submitted after 2 years of inactivity).
>
>
The throughput is actually in several places even for low/no usage
repositories.
1. RAID rebuilds will need to go through and check data. RAID-1 might seem
like a no-brainer but you tend to end up with 'which of these two disks is
the correct bit' over time problems.
2. web-spiders and such regularly peruse pretty much every package
regularly. Putting some repositories on slow disks and some on fast tend to
cause web front ends to pause out for unrelated tasks unless you set up
your caching and other middleware to deal with it. [This I know from when I
tried to make something more 'efficient' on downloads.fedoraproject.org and
from some other tooling.] It becomes a complete project of setting up the
infrastructure to best handle mixed loads. If you have a limited staff then
it may be too much work.

That said, the above does sound like an interesting project to add to copr.
I do not know how much work it would take or who would be able to do it
these days. [My understanding is that COPR is 'one of many things' that the
various developers work on with most of the work done as a volunteer
task.]


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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Kevin Kofler via devel]

Stephen Smoogen wrote:
> 1. Drive size is not just what is needed but also throughput. The large
> drives needed to store the data COPR uses for its hundreds of chroots are
> much 'slower' on reads and writes even when adding in layers of RAID 1+0.
> Faster drives are possible but the price goes up considerably.
> 2. Throughput of individual drives also requires backplane speeds which
> match peek throughput of all the drives. Otherwise you end up with lots of
> weird stalling (as seen on certain builders which have such drives).

What kind of throughput is needed for a repository that has not seen any new 
builds for 2 years? Such a repository is going get only a handful downloads 
and no uploads. Instead of deleting old repositories, they can be moved to a 
low-throughput archive storage. This can be made transparent through 
symlinks, union file systems, or even just at the HTTPS level if Copr itself 
knows how to unarchive a repository when internally needed (e.g., if a new 
build is submitted after 2 years of inactivity).

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

Re: Feedback wanted - pruning old rawhide chroots in Copr

[Miroslav Suchý]

Dne 19. 02. 24 v 14:59 Kevin Kofler via devel napsal(a):

Instead of coming up with new aggressive pruning schemes, Copr really needs
to come up with a reasonable amount of storage to satisfy user demands. HDDs
in the multi-TB-range are available for fairly low budgets (extremely low by
the standards of a company like IBM), and it just takes 2 of them to build a
RAID 1 that is safe against data loss. Of course, that means that Copr needs
to stop locking itself into third-party cloud providers that charge
ridiculously high prices for storage.


1) Fedora and Copr are using AWS. We are not locked there as Fedora infrastructure has Ansible playbooks for everything 
and we can migrate somewhere else in few days. The cost of AWS is very competitive - it costs Fedora $0. Zero dollars! 
Amazon is sponsoring Fedora this way. And I am really grateful for that.


2) While we still try to optimize the "cost", the maintainability is equally 
important now.

We already use RAID. This is RAID configuration of copr-backend:

# cat /proc/mdstat
Personalities : [raid1] [raid10]
md126 : active raid10 nvme5n1p1[1] nvme0n1p1[2] nvme4n1p1[0] nvme2n1p1[3]
 25769536512 blocks super 1.2 512K chunks 2 near-copies [4/4] []
 bitmap: 22/192 pages [88KB], 65536KB chunk

md127 : active raid1 nvme1n1p1[1] nvme6n1p1[0]
 16777081856 blocks super 1.2 [2/2] [UU]
 bitmap: 11/125 pages [44KB], 65536KB chunk

Raid check takes more than week. Backup takes days. We did the training exercise of restore from backup and it took 
several weeks. We identified places for improvements and get it down to a week. Traversing all repositories to delete 
old build takes almost a day (and we several times had to work on speed improvements there). Some improvements found the 
way back to basic tools like createrepo_c.


We can easily create 100TB volume using a RAID. Or even 1PB. But the maintenance would be a hell. And several parts of 
Copr would be painfully slow. It is like a things in a house. From certain size, moving to bigger house does not improve 
a situation and makes certain things harder: finding things, cleaning house...


If anyone think that the maintenance of Copr can be done better (I am sure, it can!) - then I want you to invite to join 
our group.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted - pruning old rawhide chroots in Copr

[Stephen Smoogen]

On Mon, 19 Feb 2024 at 08:59, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Miroslav Suchý wrote:
> > What **you** would find as acceptable policy for pruning rawhide chroots?
>
> As I mentioned several times, I already find the existing policy for
> pruning
> EOL release chroots unacceptable (because deleting data must never be the
> default – notifications can be and are still lost in spam filters, I still
> do not ever get any notification from Copr! – and because the UI to extend
> the lifetime follows dark patterns, requiring us to click separately for
> every single chroot instead of having an "Extend all" button).
>
> Instead of coming up with new aggressive pruning schemes, Copr really
> needs
> to come up with a reasonable amount of storage to satisfy user demands.
> HDDs
> in the multi-TB-range are available for fairly low budgets (extremely low
> by
> the standards of a company like IBM), and it just takes 2 of them to build
> a
> RAID 1 that is safe against data loss. Of course, that means that Copr
> needs
> to stop locking itself into third-party cloud providers that charge
> ridiculously high prices for storage.
>

Kevin,

I agree with your general concerns but have problems with your analysis of
costs.

1. Drive size is not just what is needed but also throughput. The large
drives needed to store the data COPR uses for its hundreds of chroots are
much 'slower' on reads and writes even when adding in layers of RAID 1+0.
Faster drives are possible but the price goes up considerably.
2. Throughput of individual drives also requires backplane speeds which
match peek throughput of all the drives. Otherwise you end up with lots of
weird stalling (as seen on certain builders which have such drives).
3. Outside of that you need to have a fast network switch speed of 10G
minimum and 40G to 100G to deal with the multiple builders and the storage
server. The larger the storage, the more bandwidth needed all the way
through as building software eats lots of space.
4. The builders need to be housed in a datacenter which charges for
   a. power
   b. cooling
   c. square footage used
   d. staff to deal with problems.
   e. racks and wiring and parts

Going from the costs 5 years ago, it took using storage systems from
45drives and systems elsewhere.. The capital costs for COPR was around
350k. The operating expenses were around 80k per year. At the time, chroots
and other things needed to be cleaned much more regularly than now. We
would probably need to double or triple those costs to meet what we have
now. [budgets like what was given then only came around 1/10 years or so.]

The amazon systems cost Fedora $0.00 as long as it stays within 'modest'
disk space and other resources. That said, I realize there will be a day
when you can clearly said "I told you this would happen" when being locked
in comes back to bite.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[David Bold]

> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber  wrote:
> I like this idea. Move things that were built for "rawhide" into the
> "fedora-40" chroot, and start Rawhide empty, requiring fresh builds of
> things.
> Since there is no equivalent to the mass rebuild in COPR, that would
> also solve the problem of "stale" packages in Rawhide chroots.
> 
> Fabio

Could you clarify what that would mean to a copr (e.g. [1]) that has only a 
rawhide branch.
Would that switch to fedora-41 on the next branching, and I have to manually 
recreate the rawhide branch every half year? Or will there be in addition an 
fedora-41 created, where all the builds will go and the rawhide branch will be 
empty?

What I would really like if there would be an option to say that builds get 
automatically deleted after a few months, but I could not find such an option, 
only to delete the whole copr after a given time, but that is not what I want.

Would such an option avoid the problem? If the user could specify when builds 
should get pruned?
And if the selected time is more then a year, they have to confirm every half 
year?

Looking at the storage statistics it is not quite clear to me to what extend 
"small" projects matter at all. It seems there are around 30 TB of storage, of 
which the two biggest user produce 5 TB each. Maybe an opt-in into deletion 
plus some communication with the biggest storage users could be a solution?

David

[1] https://copr.fedorainfracloud.org/coprs/davidsch/testing/
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Kevin Kofler via devel]

Miroslav Suchý wrote:
> What **you** would find as acceptable policy for pruning rawhide chroots?

As I mentioned several times, I already find the existing policy for pruning 
EOL release chroots unacceptable (because deleting data must never be the 
default – notifications can be and are still lost in spam filters, I still 
do not ever get any notification from Copr! – and because the UI to extend 
the lifetime follows dark patterns, requiring us to click separately for 
every single chroot instead of having an "Extend all" button).

Instead of coming up with new aggressive pruning schemes, Copr really needs 
to come up with a reasonable amount of storage to satisfy user demands. HDDs 
in the multi-TB-range are available for fairly low budgets (extremely low by 
the standards of a company like IBM), and it just takes 2 of them to build a 
RAID 1 that is safe against data loss. Of course, that means that Copr needs 
to stop locking itself into third-party cloud providers that charge 
ridiculously high prices for storage.

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

Re: Feedback wanted - pruning old rawhide chroots in Copr

[Sérgio Basto]

On Sun, 2024-02-18 at 23:45 +0100, Fabio Valentini wrote:
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber
>  wrote:
> > 
> 
> (snip)
> 
> > 
> > I see this somehow connected to the discussion about signing keys
> > that
> > we had recently. A radical solution would be: branch rawhide, not
> > from
> > rawhide. So, at the "F40 branch point we had last week", we would:
> > - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> > - rename rawhide chroots to f40 in copr
> > - set up new rawhide chroots ("follow [up] fedora branching")
> > 
> > In most cases, "forked" packages in copr are misleading - they are
> > in
> > a chroot without having been built against any version of it.
> > 
> > copr users would have to hit "rebuild", which should be OK.
> 
> I like this idea. Move things that were built for "rawhide" into the
> "fedora-40" chroot, and start Rawhide empty, requiring fresh builds
> of
> things.
> Since there is no equivalent to the mass rebuild in COPR, that would
> also solve the problem of "stale" packages in Rawhide chroots.


I like the idea , instead Fedora 40 have the fork of rawhide build, it
became rawhide that have the fork of Fedora 40 build ... 


I realize if build have {?dist} macro is easy if it is 3 or 4 release
old can be deleted . 
And if not have {?dist} macro  , they have the build date ... 

for example
https://download.copr.fedorainfracloud.org/results/sergiomb/SambaAD/fedora-rawhide-x86_64/01177931-samba/

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

-- 
Sérgio M. B.
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Fabio Valentini]

On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber  wrote:
>

(snip)

>
> I see this somehow connected to the discussion about signing keys that
> we had recently. A radical solution would be: branch rawhide, not from
> rawhide. So, at the "F40 branch point we had last week", we would:
> - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> - rename rawhide chroots to f40 in copr
> - set up new rawhide chroots ("follow [up] fedora branching")
>
> In most cases, "forked" packages in copr are misleading - they are in
> a chroot without having been built against any version of it.
>
> copr users would have to hit "rebuild", which should be OK.

I like this idea. Move things that were built for "rawhide" into the
"fedora-40" chroot, and start Rawhide empty, requiring fresh builds of
things.
Since there is no equivalent to the mass rebuild in COPR, that would
also solve the problem of "stale" packages in Rawhide chroots.

Fabio
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Miro Hrončok]

On 18. 02. 24 13:54, Miroslav Suchý wrote:
In Copr build system, we noticed that Fedora rawhide chroots can became large 
and they stay forever as rawhide is never EOLed.
We plan to work on this soon, but we are not sure what is best approach. I want 
to ask you - the users of Copr - what will be convenient for you?


The problem is described here https://github.com/fedora-copr/copr/issues/2933

tl;dr version is:

  * when you build into fedora-39 chroot then the chroot is one day declared as 
EOLed and if you did not act, then the chroot from the project is deleted and 
we reclaim the storage space.


  * when you build into rawhide chroot, then we keep last builds. Even if you 
do not submit to this project anything for years, we still keep this chroot. 
And such chroots can occupy gigabytes of storage.



The problem is that builds in the rawhide can be packaged configs, and they can 
be still usable despite the fact that no one rebuilds the RPM for years. Or it 
can be forgotten build that is not even installable in current chroot. We do 
not know. And testing installability of package regularly will be expensive task.


What **you** would find as acceptable policy for pruning rawhide chroots?



If a build wasn't done in the copr chroot for long time, I would consider it 
acceptable to get a notification that my chroot will be purged unless I take an 
action. I think the EOLed chroots behave similarly, correct?


A long time could be defined as a fixed period (e.g. 1 year, 2 years), or by 
the meaning of rawhide (e.g. when the last build was done when rawhide was the 
Fedora that goes EOL now, consider this rawhide chroot for purging).



Are there other chroots with the same problems? opensuse-tumbleweed, 
openmandriva-cooker, openmandriva-rolling, mageia-cauldron...


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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: Feedback wanted - pruning old rawhide chroots in Copr

[Michael J Gruber]

Am So., 18. Feb. 2024 um 13:54 Uhr schrieb Miroslav Suchý :
>
> In Copr build system, we noticed that Fedora rawhide chroots can became large 
> and they stay forever as rawhide is never
> EOLed.
> We plan to work on this soon, but we are not sure what is best approach. I 
> want to ask you - the users of Copr - what
> will be convenient for you?
>
> The problem is described here https://github.com/fedora-copr/copr/issues/2933
>
> tl;dr version is:
>
>   * when you build into fedora-39 chroot then the chroot is one day declared 
> as EOLed and if you did not act, then the
> chroot from the project is deleted and we reclaim the storage space.
>
>   * when you build into rawhide chroot, then we keep last builds. Even if you 
> do not submit to this project anything for
> years, we still keep this chroot. And such chroots can occupy gigabytes of 
> storage.
>
>
> The problem is that builds in the rawhide can be packaged configs, and they 
> can be still usable despite the fact that no
> one rebuilds the RPM for years. Or it can be forgotten build that is not even 
> installable in current chroot. We do not
> know. And testing installability of package regularly will be expensive task.
>
> What **you** would find as acceptable policy for pruning rawhide chroots?

I see this somehow connected to the discussion about signing keys that
we had recently. A radical solution would be: branch rawhide, not from
rawhide. So, at the "F40 branch point we had last week", we would:
- switch the "alias" rawhide from "meaning f40" to "meaning f41"
- rename rawhide chroots to f40 in copr
- set up new rawhide chroots ("follow [up] fedora branching")

In most cases, "forked" packages in copr are misleading - they are in
a chroot without having been built against any version of it.

copr users would have to hit "rebuild", which should be OK.

Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Feedback wanted - pruning old rawhide chroots in Copr

[Miroslav Suchý]

In Copr build system, we noticed that Fedora rawhide chroots can became large and they stay forever as rawhide is never 
EOLed.
We plan to work on this soon, but we are not sure what is best approach. I want to ask you - the users of Copr - what 
will be convenient for you?


The problem is described here https://github.com/fedora-copr/copr/issues/2933

tl;dr version is:

 * when you build into fedora-39 chroot then the chroot is one day declared as EOLed and if you did not act, then the 
chroot from the project is deleted and we reclaim the storage space.


 * when you build into rawhide chroot, then we keep last builds. Even if you do not submit to this project anything for 
years, we still keep this chroot. And such chroots can occupy gigabytes of storage.



The problem is that builds in the rawhide can be packaged configs, and they can be still usable despite the fact that no 
one rebuilds the RPM for years. Or it can be forgotten build that is not even installable in current chroot. We do not 
know. And testing installability of package regularly will be expensive task.


What **you** would find as acceptable policy for pruning rawhide chroots?

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Interesting difference between Koji and COPR (_isa macro)

[Sérgio Basto]

On Wed, 2024-01-24 at 17:56 +0100, Lumír Balhar wrote:
> Hello.
> 
> Today I found out an interesting difference between Koji and COPR. 
> autowrap package has this in its specfile:
> 
> Requires: python%{python3_pkgversion}-Cython%{?_isa}
> 
> Which is incorrect for noarch package but hold on. The resulting
> package 
> from Koji requires:
> 
> python3-Cython
> 
> but in COPR, the result requires:
> 
> python3-Cython(x86-64)
> 
> and that breaks subsequent builds in COPR because python3-Cython does
> not provide python3-Cython(x86-64).
> 
> In other words, if I rebuild autowrap in COPR and some other build
> later 
> tries to install it, the installation fails because nothing provides 
> python3-Cython(x86-64).
> 
> It seems like %{?_isa} is not defined for noarch packages in Koji but
> it 
> is in COPR. Is that a known problem/feature?
> 

Hi,
Maybe is off-topic, but I found other difference of building in corp
and building in koji and is trick one 

if I build a new package in copr, to exemplify, opencv where I removed
opencv.pc file, so every package that requires opencv.pc i.e. every
package which requires pkgconfig(opencv) will fail to build on koji ,
but not on copr, because koji works as just have one repo and there
just have the last opencv built while in copr opencv last build is
ignored and copr will use the previous opencv package that is in Fedora
repo.

In resume, please check if copr is pulling the correct packages to lead
to the right conclusions.  

Best regards,

> Thank you.
> 
> Lumír
> 
> P.S.: fix for autowrap: 
> https://src.fedoraproject.org/rpms/autowrap/pull-request/3
> --
> ___
> 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

-- 
Sérgio M. B.
--
___
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: Interesting difference between Koji and COPR (_isa macro)

[Miroslav Suchý]

Dne 24. 01. 24 v 18:02 Dan Horák napsal(a):

It seems like %{?_isa} is not defined for noarch packages in Koji but it
is in COPR. Is that a known problem/feature?

it could be because COPR always does an archful build (like plain mock
builds do), while koji knows noarch is a separate arch


Mock does not understand "noarch" build. It always run on machine with an arch. Just the 
result can be name "noarch".

This is first time I hear about this problem.

When you hit something like this, it is always good start to reproduce it 
localy with mock.

Config from Koji can be retrieved using:

   fedpkg mock-config

in specific branch of dist-git.

Config from Copr can be retrieved using:

copr-cli mock-config myproject fedora-rawhide-x86_64

and you can test it as

  mock -f ./config.cfg foo.src.rpm

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Interesting difference between Koji and COPR (_isa macro)

[Dan Horák]

On Wed, 24 Jan 2024 17:56:40 +0100
Lumír Balhar  wrote:

> Hello.
> 
> Today I found out an interesting difference between Koji and COPR. 
> autowrap package has this in its specfile:
> 
> Requires: python%{python3_pkgversion}-Cython%{?_isa}
> 
> Which is incorrect for noarch package but hold on. The resulting package 
> from Koji requires:
> 
> python3-Cython
> 
> but in COPR, the result requires:
> 
> python3-Cython(x86-64)
> 
> and that breaks subsequent builds in COPR because python3-Cython does 
> not provide python3-Cython(x86-64).
> 
> In other words, if I rebuild autowrap in COPR and some other build later 
> tries to install it, the installation fails because nothing provides 
> python3-Cython(x86-64).
> 
> It seems like %{?_isa} is not defined for noarch packages in Koji but it 
> is in COPR. Is that a known problem/feature?

it could be because COPR always does an archful build (like plain mock
builds do), while koji knows noarch is a separate arch


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

Interesting difference between Koji and COPR (_isa macro)

[Lumír Balhar]

Hello.

Today I found out an interesting difference between Koji and COPR. 
autowrap package has this in its specfile:


Requires: python%{python3_pkgversion}-Cython%{?_isa}

Which is incorrect for noarch package but hold on. The resulting package 
from Koji requires:


python3-Cython

but in COPR, the result requires:

python3-Cython(x86-64)

and that breaks subsequent builds in COPR because python3-Cython does 
not provide python3-Cython(x86-64).


In other words, if I rebuild autowrap in COPR and some other build later 
tries to install it, the installation fails because nothing provides 
python3-Cython(x86-64).


It seems like %{?_isa} is not defined for noarch packages in Koji but it 
is in COPR. Is that a known problem/feature?


Thank you.

Lumír

P.S.: fix for autowrap: 
https://src.fedoraproject.org/rpms/autowrap/pull-request/3

--
___
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: ARM PAC on koji vs COPR

[Jarek Prokop]

On 1/4/24 16:10, Jarek Prokop wrote:


On 1/4/24 10:47, Florian Weimer wrote:

* Jarek Prokop:


This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the
flag with pac-ret seems to be appended to libruby.so in the case of
the upstream fix [2].

>From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?


Not sure how I would check that.


By compiling on an ARM machine, duh!

Compiling with file test.c like this:
~~~
$ cat test.c
#include 
#include 

int main() {
    printf("%d", __ARM_FEATURE_BTI_DEFAULT);
    printf("%d", __ARM_FEATURE_PAC_DEFAULT);
    return 0;
}
$ gcc -mbranch-protection=standard -mbranch-protection=pac-ret test.c
test.c: In function ‘main’:
test.c:5:18: error: ‘__ARM_FEATURE_BTI_DEFAULT’ undeclared (first use in 
this function)

    5 | printf("%d", __ARM_FEATURE_BTI_DEFAULT);
  |  ^
test.c:5:18: note: each undeclared identifier is reported only once for 
each function it appears in

~~~
So it seems anything related to BTI gets actually skipped in the 
upstream Context.S file, since their only option is for `=pac-ret`.

And for completenes, same file, but with =standard:
~~~
$ gcc -mbranch-protection=standard test.c
$ ./a.out
11
~~~

tl;dr No, it doesn't seem to remain enabled if this double definition is 
done.


Thanks,
Jarek
--
___
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: ARM PAC on koji vs COPR

[Jarek Prokop]

On 1/4/24 10:47, Florian Weimer wrote:

* Jarek Prokop:


This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the
flag with pac-ret seems to be appended to libruby.so in the case of
the upstream fix [2].

 From what I understand, it shouldn't cause problems to have these 2
flags at the same time on the correct compilation artifacts, is that
correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?


Not sure how I would check that.

But `-mbranch-protection=standard` should currently be BTI+PAC:

"standard turns on all types of branch protection.
    Currently standard implies pac-ret+bti."
--
https://developer.arm.com/documentation/102433/0200/Applying-these-techniques-to-real-code

Whether we end up with generated code that's also BTI is not certain. In 
any case it actually seems like
we want to not use that configure branch at all for now, as we can use 
just =standard and achieve better effect

than with the uncertain result of the combined flags that is happening now.

and if I understand the text correctly, we on Fedora with that =standard 
do not actually therefore need =pac-ret

for the -mbranch-protection flag.

Digging deeper in Arm's documentation regarding this, it seems the 
generated assembly is actually reasonably compatible

across CPU variants, or well... has the ability to be if it is handwritten



Can't you put -mbranch-protection=standard into ASFLAGS?
We probably can, and it might be the way to go for Fedora Ruby based on 
the mentioned ARM developer article. At least for the moment.

I'll inspect and see.


The check is a bit weird:

diff --git a/configure.ac b/configure.ac
index 9286946fc15f4..18b4247991d42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [
AS_FOR(option, opt, [-mbranch-protection=pac-ret 
-msign-return-address=all], [
  RUBY_TRY_CFLAGS(option, [branch_protection=yes], 
[branch_protection=no])
  AS_IF([test "x$branch_protection" = xyes], [
+# C compiler and assembler must be consistent for 
-mbranch-protection
+# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition.
  RUBY_APPEND_OPTION(XCFLAGS, option)
+RUBY_APPEND_OPTION(ASFLAGS, option)
  break
  ])
  ])

<https://github.com/ruby/ruby/commit/1f89a670381859d1c1d1c640359f169b6db6759c.patch>

The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option.

That does sound better, I'll do some exploring for this.
Thanks for taking a look.



2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
up in the .so library and Ruby binary extensions link against that
solib, do the binary extensions also have to be compiled with that
exact option?

It depends on how fiber handling is implemented.  If fiber switching
relies on code in header files or that is statically linked into Ruby
extensions, then yes, these extensions will need to be compiled with PAC
support as well.  But I expect that this isn't the case, but haven't
checked it.  The relevant code should be in the Ruby DSO only and be
linked dynamically.
That seems to be our case, we do not ship static artifacts to link 
against AFAICT.

It also seems unlikely that many C extensions would be aware of fiber
switching, but I haven't checked that, either.
Quickly grepping through sources suggests that if extensions are aware 
of fiber switching,
they are doing it through the Ruby C-api that has responsible code in 
the DSO.


So I can probably scratch that concern off of my list.

3. If we do not fix this bug in Ruby 3.3.0 but wait with this for
3.3.1 where the fix will most probably land, will we by effect exclude
a subset of ARM CPUs, that actually have the PAC capability, for that
in-between period?

I think you should fix this with a backport.  It's going to impact quite
a few users.


4. Why do koji and copr have CPU flag set that differs so much? Is our
koji infra OK?

It's different machines, so they are expect to have different
capabilities.  This isn't even aarch64-specific.
I see. I didn't know how much different actually which was answered by 
other people here.



5. Why does it fail on copr and does not fail on koji? It seems the
paca/pacg have to be present and set on the CPU flags for the
segfaults to occur.

PAC is not process-switched on Linux.  If it is turned on at the
kernel/

Re: ARM PAC on koji vs COPR

[Florian Weimer]

* Jarek Prokop:

> This spawns a few questions for me:
> 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
> CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
> defaults,
> I see default CFLAGS contain `-mbranch-protection=standard` and the
> flag with pac-ret seems to be appended to libruby.so in the case of
> the upstream fix [2].
>
> From what I understand, it shouldn't cause problems to have these 2
> flags at the same time on the correct compilation artifacts, is that
> correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?

Can't you put -mbranch-protection=standard into ASFLAGS?

The check is a bit weird:

diff --git a/configure.ac b/configure.ac
index 9286946fc15f4..18b4247991d42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [
AS_FOR(option, opt, [-mbranch-protection=pac-ret 
-msign-return-address=all], [
 RUBY_TRY_CFLAGS(option, [branch_protection=yes], 
[branch_protection=no])
 AS_IF([test "x$branch_protection" = xyes], [
+# C compiler and assembler must be consistent for 
-mbranch-protection
+# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition.
 RUBY_APPEND_OPTION(XCFLAGS, option)
+RUBY_APPEND_OPTION(ASFLAGS, option)
 break
 ])
 ])

<https://github.com/ruby/ruby/commit/1f89a670381859d1c1d1c640359f169b6db6759c.patch>

The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option.

> 2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
> up in the .so library and Ruby binary extensions link against that
> solib, do the binary extensions also have to be compiled with that
> exact option?

It depends on how fiber handling is implemented.  If fiber switching
relies on code in header files or that is statically linked into Ruby
extensions, then yes, these extensions will need to be compiled with PAC
support as well.  But I expect that this isn't the case, but haven't
checked it.  The relevant code should be in the Ruby DSO only and be
linked dynamically.

It also seems unlikely that many C extensions would be aware of fiber
switching, but I haven't checked that, either.

> 3. If we do not fix this bug in Ruby 3.3.0 but wait with this for
> 3.3.1 where the fix will most probably land, will we by effect exclude
> a subset of ARM CPUs, that actually have the PAC capability, for that
> in-between period?

I think you should fix this with a backport.  It's going to impact quite
a few users.

> 4. Why do koji and copr have CPU flag set that differs so much? Is our
> koji infra OK?

It's different machines, so they are expect to have different
capabilities.  This isn't even aarch64-specific.

> 5. Why does it fail on copr and does not fail on koji? It seems the
> paca/pacg have to be present and set on the CPU flags for the
> segfaults to occur.

PAC is not process-switched on Linux.  If it is turned on at the
kernel/hypervisor level, it's currently impossible to turn off.  This is
not something the buildroot can control.  It's not actually a hardware
limitation, it's just how it has been implemented on Linux.  (Although
we would turn it on for the Fedora buildroots at this point.)

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: ARM PAC on koji vs COPR

[Peter Robinson]

On Wed, Jan 3, 2024 at 9:08 PM Stephen Smoogen  wrote:
>
>
>
> On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý  wrote:
>>
>> Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
>>
>> 4. Why do koji and copr have CPU flag set that differs so much? Is our koji 
>> infra OK?
>>
>> For convenience of readers:
>>
>> Koji:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm lrcpc dcpop asimddp ssbs
>>
>> Copr:
>> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
>> asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
>> uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
>>
>> In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn 
>> this machine in AWS you should be able to reproduce.
>
>
> My information may be old, but I believe the Fedora systems will be mostly 
> virtual machines running on Ampere systems from 2-3 years ago. I think there 
> are a couple of other systems which may be in usage also. The AWS systems are 
> a newer generation and different chipset. Another issue is that ARM like 
> Intel systems may be of the same generation but have different flags.
>

Ultimately builds should be using distro specified flags, not flags
based on detected build system features because that will lead to
builds that can't run on all supported platforms of a particular
architecture.
--
___
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: ARM PAC on koji vs COPR

[Stephen Smoogen]

On Wed, 3 Jan 2024 at 15:01, Miroslav Suchý  wrote:

> Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
>
> 4. Why do koji and copr have CPU flag set that differs so much? Is our
> koji infra OK?
>
> For convenience of readers:
>
> Koji:
> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp
> cpuid asimdrdm lrcpc dcpop asimddp ssbs
>
> Copr:
> Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
> asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
> uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng
>
> In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn this 
> machine in AWS you should be able to reproduce.
>
>
My information may be old, but I believe the Fedora systems will be mostly
virtual machines running on Ampere systems from 2-3 years ago. I think
there are a couple of other systems which may be in usage also. The AWS
systems are a newer generation and different chipset. Another issue is that
ARM like Intel systems may be of the same generation but have different
flags.



> Side note - hopefully in next release Copr will have functionality that will 
> allow you to SSH to host with the failed build 
> https://github.com/fedora-copr/copr/pull/2977 But that will take few weeks. :(
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Manager, Packit and CPT, #brno, #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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: ARM PAC on koji vs COPR

[Miroslav Suchý]

Dne 03. 01. 24 v 14:46 Jarek Prokop napsal(a):
4. Why do koji and copr have CPU flag set that differs so much? Is our koji infra OK? 


For convenience of readers:

Koji:
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
asimdrdm lrcpc dcpop asimddp ssbs

Copr:
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid 
asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit 
uscat ilrcpc flagm ssbs paca pacg dcpodp svei8mm svebf16 i8mm bf16 dgh rng

In Copr we use c7g.xlarge type from AWS as ARM builders. So if you spawn this 
machine in AWS you should be able to reproduce.

Side note - hopefully in next release Copr will have functionality that will 
allow you to SSH to host with the failed 
buildhttps://github.com/fedora-copr/copr/pull/2977  But that will take few 
weeks. :(

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

ARM PAC on koji vs COPR

[Jarek Prokop]

Hi,

recently Ruby 3.3 was released, we have noticed a failure to build on 
COPR's aarch64:

https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/
https://download.copr.fedorainfracloud.org/results/jackorp/ruby-builds/fedora-rawhide-aarch64/06848355-ruby/builder-live.log.gz

But we do not observe these failures on koji (see e.g. 
https://koji.fedoraproject.org/koji/taskinfo?taskID=111230891 )


What i have observed is that the hw_info.log reports different flags, 
visually I'd say koji has half the CPU flags, despite koji reporting to be

the equal CPU model Neoverse-N1 of the vendor ID of ARM as does copr report.

More details regarding the failures:
According to upstream bug report [0] the culprit is change introducing 
PAC/BTI support in some arm64 assembly [1] and the fix
to no longer have Ruby segfault is including 
`ASFLAGS=-mbranch-protection=pac-ret` [2] in addition to the same flag 
in XCFLAGS.


This spawns a few questions for me:
1. Since [1] the `-mbranch-protection=pac-ret` is needed in both CFLAGS 
and ASFLAGS, I am unsure how it interacts with the Fedora defaults,
I see default CFLAGS contain `-mbranch-protection=standard` and the flag 
with pac-ret seems to be appended to libruby.so in the case of the 
upstream fix [2].


From what I understand, it shouldn't cause problems to have these 2 
flags at the same time on the correct compilation artifacts, is that 
correct?


2. Since files compiled with `-mbranch-protection=pac-ret` seem to end 
up in the .so library and Ruby binary extensions link against that solib,

do the binary extensions also have to be compiled with that exact option?

3. If we do not fix this bug in Ruby 3.3.0 but wait with this for 3.3.1 
where the fix will most probably land, will we by effect exclude a 
subset of ARM CPUs,

that actually have the PAC capability, for that in-between period?

4. Why do koji and copr have CPU flag set that differs so much? Is our 
koji infra OK?


5. Why does it fail on copr and does not fail on koji? It seems the 
paca/pacg have to be present and set on the CPU flags for the segfaults 
to occur.


I tried answering the last question when reading on that in kernel docs 
[3], but I can't say I understand the text 100%.


Thanks,
Jarek Prokop

[0] https://bugs.ruby-lang.org/issues/20085
[1] https://github.com/ruby/ruby/pull/9306
[2] https://github.com/ruby/ruby/pull/9371
[3] https://www.kernel.org/doc/html/v6.4/arm64/pointer-authentication.html
--
___
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: Copr builds are stuck at package signing

[Miroslav Suchý]

Dne 06. 12. 23 v 12:52 František Šumšal napsal(a):

Hey,

Thanks to Packit I noticed that a lot of our jobs are running longer than usual, and a quick glance at the Copr task 
queue[0] tells me there's something fishy going on. I opened a couple of jobs[1][2][3] and all of

...
Looks like the last 20s sleep takes _way_ longer than 20s. Is this a known issue? 


Yes. Pavel, Jakub and Jirka was working on this most of today's date.

The culprit was that gpg key was not created for a project. We found that 'gpg2 --list-secret-keys` took 35 seconds to 
finish, but the client had a timeout 24 seconds. We solved it temporarily by spawning a beefier VM for sign server. Now 
gpg2 returns in 4 secs. It gives us time to look at how to solve it properly. In the meantime, your builds should build 
without a problem and the current queue is slowly processing.



--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Copr builds are stuck at package signing

[František Šumšal]

Hey,

Thanks to Packit I noticed that a lot of our jobs are running longer than 
usual, and a quick glance at the Copr task queue[0] tells me there's something 
fishy going on. I opened a couple of jobs[1][2][3] and all of them seem to be 
stuck in the same step - signing the build RPMs:

builder-live.log:
RPMResults finished

backend.log:
[2023-12-05 16:22:41,769][  INFO][PID:2234386] Calling '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' (attempt #2)
[2023-12-05 16:22:43,127][WARNING][PID:2234386] Command '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' failed with: 
unknown key: rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org
[2023-12-05 16:22:43,129][WARNING][PID:2234386] Going to sleep 20s and re-try.
[2023-12-05 16:23:03,130][  INFO][PID:2234386] Calling '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' (attempt #3)
[2023-12-05 16:23:04,949][WARNING][PID:2234386] Command '/bin/sign -u 
rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org -p' failed with: 
unknown key: rpmsoftwaremanagement#ci-libdnf5-pr1...@copr.fedorahosted.org
[2023-12-05 16:23:04,950][WARNING][PID:2234386] Going to sleep 20s and re-try.

Looks like the last 20s sleep takes _way_ longer than 20s. Is this a known 
issue?

[0] https://copr.fedorainfracloud.org/status/running/
[1] 
https://copr.fedorainfracloud.org/coprs/packit/cockpit-project-cockpit-19698/build/6726609/
[2] 
https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/CI-libdnf5-pr1008/build/6726763/
[3] 
https://copr.fedorainfracloud.org/coprs/eliasofwaffle/gnome-shell-patched/build/6727378/
--
___
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: How to deal with COPR and RPMAutoSpec

[Neal Gompa]

On Wed, Oct 18, 2023 at 11:18 AM Miroslav Suchý  wrote:
>
> Dne 18. 10. 23 v 16:12 Diego Herrera napsal(a):
> > What I usually do when I need for COPR to handle rpmautospec is to set
> > the source type to "Custom", and use the following script:
> >
> > #! /bin/sh -x
> > git clone  
> > cd 
> > spectool -g 
> > rpmautospec process-distgit  
> >
> > Set the Buildroot dependencies to "git rpmdevtools rpmautospec" and
> > the Result directory to the same  string used in the
> > script.
>
> This is great. I added this to our FAQ
>
> https://github.com/fedora-copr/copr/pull/2958
>

Note that you can use git-core instead to make the buildroot smaller.


-- 
真実はいつも一つ！/ 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to deal with COPR and RPMAutoSpec

[Miroslav Suchý]

Dne 18. 10. 23 v 16:12 Diego Herrera napsal(a):

What I usually do when I need for COPR to handle rpmautospec is to set
the source type to "Custom", and use the following script:

#! /bin/sh -x
git clone  
cd 
spectool -g 
rpmautospec process-distgit  

Set the Buildroot dependencies to "git rpmdevtools rpmautospec" and
the Result directory to the same  string used in the
script.


This is great. I added this to our FAQ

https://github.com/fedora-copr/copr/pull/2958


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: How to deal with COPR and RPMAutoSpec

[Diego Herrera]

What I usually do when I need for COPR to handle rpmautospec is to set
the source type to "Custom", and use the following script:

#! /bin/sh -x
git clone  
cd 
spectool -g 
rpmautospec process-distgit  

Set the Buildroot dependencies to "git rpmdevtools rpmautospec" and
the Result directory to the same  string used in the
script.

On Tue, Oct 17, 2023 at 5:47 PM 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?
>
> Thanks,
> Richard
> ___
> 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: How to deal with COPR and RPMAutoSpec

[Richard Shaw]

Never mind, I hadn't realized fedpkg had grown the ability to do COPR
builds.

Thanks,
Richard
___
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

[Fabio Valentini]

On Tue, Oct 17, 2023 at 10:47 PM 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?

The easiest would probably be to construct the .src.rpm with "fedpkg
srpm" locally and upload it to COPR.
The "rpkg" build method in COPR has no support for rpmautospec, as the
underlying code has been basically unmaintained for years.

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

How to deal with COPR and RPMAutoSpec

[Richard Shaw]

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?

Thanks,
Richard
___
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

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

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

[Neal H. Walfield]

Hi Pavel,

On Wed, 14 Jun 2023 11:27:35 +0200,
Pavel Raiskup wrote:
> 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

Thanks for investigating, I opened an issue on our issue tracker about
it here:

  https://gitlab.com/sequoia-pgp/keyring-linter/-/issues/20

Using https://www.centos.org/keys/RPM-GPG-KEY-CentOS-6, it appears
that the CentOS 6 key expired in July 2021.  The linter checks if a
certificate is invalid under the standard policy, but valid under the
standard policy + SHA-1.  Since the certificate is expired, it's
considered invalid in both cases, and it concludes that the
certificate doesn't have any issues.  Using faketime to examine the
certificate when it wasn't expired, we see:

  $ faketime 2021-01-01 sq-keyring-linter RPM-GPG-KEY-CentOS-6
  Certificate 0946FCA2C105B9DE is not valid under the standard policy: No 
binding signature at time 2020-12-31T23:00:00Z
  Certificate 0946FCA2C105B9DE contains a User ID ("CentOS-6 Key (CentOS 6 
Official Signing Key) ") protected by SHA-1
  Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
1 of the 1 certificates (100%) has at least one issue. (BAD)
  0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than 
the certificate and should be recreated. (GOOD)
  0 of the linted certificates were expired.
  1 of the non-revoked linted certificate has at least one non-revoked User ID:
1 has at least one User ID protected by SHA-1. (BAD)
1 has all User IDs protected by SHA-1. (BAD)
  0 of the non-revoked linted certificates have at least one non-revoked, live 
subkey:
0 have at least one non-revoked, live subkey with a binding signature that 
uses SHA-1. (GOOD)
  0 of the non-revoked linted certificates have at least one non-revoked, live, 
signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey 
with a strong binding signature, but a backsig that uses SHA-1. (GOOD)

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

[Panu Matilainen]

On 6/14/23 11:02, Pavel Raiskup wrote:

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?


There haven't been any related changes in the last couple of months 
(that I'm aware of), but it was different initially yes.


- Panu -

___
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

[Stephen Gallagher]

On Tue, Jun 13, 2023 at 8:44 AM Kevin Kofler via devel
 wrote:
>
> Kevin Kofler via devel wrote:
> > Gary Buhrmaster wrote:
> >> Well, EL6 ELS support is still available for (around)
> >> another year, so it is a nice to have to support those
> >> limping along with EL6, but I would generally agree
> >> with the principal that if supporting a product past
> >> official EOL becomes overly onerous that support
> >> should end, or be explicitly funded out of the ELS
> >> fees if the ELS community needs that support.
> >
> > EPEL is not covered by ELS, hence EPEL is already EOL.
>
> PS: I also do not see why Fedora should be supporting the users of a
> commercial subscription scheme with free services such as Copr.
>

First, let me be clear: I agree with you and Smooge that EPEL 6 should
already be dead in COPR. That said, Fedora *itself* is a free service
supporting the users of and funded by a commercial subscription
offering. No need to support good arguments with flawed ones.
___
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

[Neal H. Walfield]

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?


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

[Kevin Kofler via devel]

Kevin Kofler via devel wrote:
> Gary Buhrmaster wrote:
>> Well, EL6 ELS support is still available for (around)
>> another year, so it is a nice to have to support those
>> limping along with EL6, but I would generally agree
>> with the principal that if supporting a product past
>> official EOL becomes overly onerous that support
>> should end, or be explicitly funded out of the ELS
>> fees if the ELS community needs that support.
> 
> EPEL is not covered by ELS, hence EPEL is already EOL.

PS: I also do not see why Fedora should be supporting the users of a 
commercial subscription scheme with free services such as Copr.

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

Re: Fedora Copr builders updated to Fedora 38

[Stephen Smoogen]

On Tue, 13 Jun 2023 at 08:21, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Gary Buhrmaster wrote:
> > Well, EL6 ELS support is still available for (around)
> > another year, so it is a nice to have to support those
> > limping along with EL6, but I would generally agree
> > with the principal that if supporting a product past
> > official EOL becomes overly onerous that support
> > should end, or be explicitly funded out of the ELS
> > fees if the ELS community needs that support.
>
> EPEL is not covered by ELS, hence EPEL is already EOL.
>
> If we are going to support distros that had their EOL 2½ years ago, I want
> my Fedora 31 to 36 buildroots back! (Fedora 31 had its EOL only 6 days
> before EPEL 6, Fedora 32 to 36 had theirs more recently.)
>
>
I am in agreement with Kevin on this. While there are people who might
still want to build for their EL6 systems (including myself *cough*), I
think there is a point where its usage of the COPR project's limited
resources. If you really need to build stuff against end of life releases,
then one needs to do the work themselves or join together with other people
who can help pay for those resources.



> > I do not consider setting gpgcheck=0 overly
> > onerous for EPEL6
>
> I consider it a security risk and a no go.
>
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

[Kevin Kofler via devel]

Gary Buhrmaster wrote:
> Well, EL6 ELS support is still available for (around)
> another year, so it is a nice to have to support those
> limping along with EL6, but I would generally agree
> with the principal that if supporting a product past
> official EOL becomes overly onerous that support
> should end, or be explicitly funded out of the ELS
> fees if the ELS community needs that support.

EPEL is not covered by ELS, hence EPEL is already EOL.

If we are going to support distros that had their EOL 2½ years ago, I want 
my Fedora 31 to 36 buildroots back! (Fedora 31 had its EOL only 6 days 
before EPEL 6, Fedora 32 to 36 had theirs more recently.)

> I do not consider setting gpgcheck=0 overly
> onerous for EPEL6

I consider it a security risk and a no go.

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

Re: Fedora Copr builders updated to Fedora 38

[Gary Buhrmaster]

On Sat, Jun 10, 2023 at 4:36 PM Kevin Kofler via devel
 wrote:

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

Well, EL6 ELS support is still available for (around)
another year, so it is a nice to have to support those
limping along with EL6, but I would generally agree
with the principal that if supporting a product past
official EOL becomes overly onerous that support
should end, or be explicitly funded out of the ELS
fees if the ELS community needs that support.

I do not consider setting gpgcheck=0 overly
onerous for EPEL6, but I do think we should
want to avoid such actions becoming the
expected behavior for the next time (and there
will be a next time), where the workarounds
might require a much bigger effort.
___
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

[Kevin Kofler via devel]

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.

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

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

Re: Fedora Copr builders updated to Fedora 38

[Ondřej Budai]

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

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

Disabling Fedora 36 chroots in Copr

[Jiri Kyjovsky]

Hello,

we have just disabled Fedora 36 chroots in Copr.

According to the Fedora wiki [1], Fedora 36 reached the end of its life
on 2023-05‑16 and therefore we are disabling it in Copr.

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

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

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


[1] https://fedoraproject.org/wiki/End_of_life
[2]
https://docs.pagure.org/copr.copr/copr_outdated_chroots_removal_policy.html
[3] http://frostyx.cz/posts/copr-removing-outdated-chroots

Kind regards
Jiri Kyjovsky
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Sérgio Basto]

On Wed, 2023-05-10 at 09:44 +0200, Petr Pisar wrote:
> V Tue, May 09, 2023 at 09:20:30PM +0100, Sérgio Basto napsal(a):
> > I tested with Centos Stream 9.
> > xvfb-run have been fixed somehow in Centos Stream first,
> 
> CentOS Stream is a preview of the next RHEL minor release. It works
> as
> designed.
> 
> > any idea how xvfb-ruu was fixed ? I'd like understand the part of
> > running
> > graphics tests in the koji build why we got the segfault with
> > 1.20.11-
> > 11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
> > explanation ?
> > 
> Read the RPM package changelog.
> 

yeah, may be is this one 

* Wed Jan 26 2022 Adam Jackson  - 1.20.11-8
- Only disable the PCI-specific driver probe, since we do still want
fallback
to fbdev to work.
Resolves: #2029769

https://bugzilla.redhat.com/show_bug.cgi?id=2029769


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

-- 
Sérgio M. B.
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Petr Pisar]

V Tue, May 09, 2023 at 09:20:30PM +0100, Sérgio Basto napsal(a):
> I tested with Centos Stream 9.
> xvfb-run have been fixed somehow in Centos Stream first,

CentOS Stream is a preview of the next RHEL minor release. It works as
designed.

> any idea how xvfb-ruu was fixed ? I'd like understand the part of running
> graphics tests in the koji build why we got the segfault with 1.20.11-
> 11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
> explanation ?
> 
Read the RPM package changelog.

-- Petr


signature.asc
Description: PGP signature
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Kevin Fenzi]

On Tue, May 09, 2023 at 09:20:30PM +0100, Sérgio Basto wrote:
> On Tue, 2023-05-09 at 11:43 -0700, Kevin Fenzi wrote:
> > On Tue, May 09, 2023 at 07:19:49PM +0100, Sérgio Basto wrote:
> > > Hi,
> > > it builds in copr epel-9 (with RHEL-9) [1] but fail to build on
> > > koji
> > > [2]
> > > 
> > > the test with xvfb-run seg fault and fails on koji [3] any idea why
> > > ? 
> > > 
> > > Thank you 
> > 
> > Just retry now. 
> > 
> 
> It did the trick , 100944504 build (epel9-candidate, /rpms/python-
> pyopengl.git:d6f7912df1497bae43895b3ad6c8c06c5e3ff1c2) completed
> successfully
> 
> and is good to know that we can reproduce the builds with local mock ,
> I tested with Centos Stream 9.
> xvfb-run have been fixed somehow in Centos Stream first, I tested , any
> idea how xvfb-ruu was fixed ? I'd like understand the part of running
> graphics tests in the koji build why we got the segfault with 1.20.11-
> 11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
> explanation ?

No idea off hand. Might ask on a centos stream list?

kevin


signature.asc
Description: PGP signature
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Sérgio Basto]

On Tue, 2023-05-09 at 11:43 -0700, Kevin Fenzi wrote:
> On Tue, May 09, 2023 at 07:19:49PM +0100, Sérgio Basto wrote:
> > Hi,
> > it builds in copr epel-9 (with RHEL-9) [1] but fail to build on
> > koji
> > [2]
> > 
> > the test with xvfb-run seg fault and fails on koji [3] any idea why
> > ? 
> > 
> > Thank you 
> 
> Just retry now. 
> 

It did the trick , 100944504 build (epel9-candidate, /rpms/python-
pyopengl.git:d6f7912df1497bae43895b3ad6c8c06c5e3ff1c2) completed
successfully

and is good to know that we can reproduce the builds with local mock ,
I tested with Centos Stream 9.
xvfb-run have been fixed somehow in Centos Stream first, I tested , any
idea how xvfb-ruu was fixed ? I'd like understand the part of running
graphics tests in the koji build why we got the segfault with 1.20.11-
11.el9 and now with 1.20.11-17.el9 not ? if there is a simple
explanation ?

Thank you. 


> RHEL 9.2 is syncing out this morning, and our sync seems to have only
> gotten
> part of it. I synced the rest and regenerated the koji repos. 
> 
> 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

-- 
Sérgio M. B.
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Stephen Smoogen]

On Tue, 9 May 2023 at 14:33, Stephen Smoogen  wrote:

>
>
> On Tue, 9 May 2023 at 14:20, Sérgio Basto  wrote:
>
>> Hi,
>> it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji
>> [2]
>>
>>
> COPR is using
>
> DEBUG util.py:445:   xorg-x11-server-Xvfb x86_64 1.20.11-17.el9
>   appstream 897 k
>
> EPEL at the time you tried the build was using
> DEBUG util.py:445:   xorg-x11-server-Xvfbx86_64   1.20.11-11.el9
>build   895 k
>
> which says to me that the CDN sync from Red Hat isn't complete so koji may
> have some 9_2 and some 9.1 items in its build root. [Although I did not see
> any 9_2 in the koji output but did see them in the COPR one.]
>
> I think the Fedora infrastructure is trying to get a download for koji
> which may take some time. Try again tomorrow
>
>

Looks like the sync is done already. I see that the  `xorg-x11-server-Xvfb
x86_64 1.20.11-17.el9` is now downloaded. If retriggering does not work
I would put in a release engineering ticket to see if koji needs something
'kicked'.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Kevin Fenzi]

On Tue, May 09, 2023 at 07:19:49PM +0100, Sérgio Basto wrote:
> Hi,
> it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji
> [2]
> 
> the test with xvfb-run seg fault and fails on koji [3] any idea why ? 
> 
> Thank you 

Just retry now. 

RHEL 9.2 is syncing out this morning, and our sync seems to have only gotten
part of it. I synced the rest and regenerated the koji repos. 

kevin


signature.asc
Description: PGP signature
___
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: it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Stephen Smoogen]

On Tue, 9 May 2023 at 14:20, Sérgio Basto  wrote:

> Hi,
> it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji
> [2]
>
>
COPR is using

DEBUG util.py:445:   xorg-x11-server-Xvfb x86_64 1.20.11-17.el9
appstream 897 k

EPEL at the time you tried the build was using
DEBUG util.py:445:   xorg-x11-server-Xvfbx86_64   1.20.11-11.el9
   build   895 k

which says to me that the CDN sync from Red Hat isn't complete so koji may
have some 9_2 and some 9.1 items in its build root. [Although I did not see
any 9_2 in the koji output but did see them in the COPR one.]

I think the Fedora infrastructure is trying to get a download for koji
which may take some time. Try again tomorrow


> the test with xvfb-run seg fault and fails on koji [3] any idea why ?
>
> Thank you
>
>
>
> [1]
> https://copr.fedorainfracloud.org/coprs/build/5901019
>
> [2]
> https://koji.fedoraproject.org/koji/taskinfo?taskID=100929278
>
> [3]
> xvfb-run -a -s '-screen 0 1024x768x24 -ac +extension GLX +render -
> noreset' pytest PyOpenGL-3.1.6/tests
> --
> Sérgio M. B.
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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

it builds in copr epel-9 (with RHEL-9) but fail to build on koji

[Sérgio Basto]

Hi,
it builds in copr epel-9 (with RHEL-9) [1] but fail to build on koji
[2]

the test with xvfb-run seg fault and fails on koji [3] any idea why ? 

Thank you 



[1]
https://copr.fedorainfracloud.org/coprs/build/5901019

[2]
https://koji.fedoraproject.org/koji/taskinfo?taskID=100929278

[3]
xvfb-run -a -s '-screen 0 1024x768x24 -ac +extension GLX +render -
noreset' pytest PyOpenGL-3.1.6/tests 
-- 
Sérgio M. B.
___
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 38 support in Copr

[Jiri Kyjovsky]

Hello all,

Fedora 38 was released yesterday and we're excited to announce that Copr
fully supports building in Fedora 38 chroots. This means you can now build
packages for Fedora 38 with ease and ensure compatibility with the latest
version of the operating system for multiple architectures.

Don't hesitate to contact us if you have any questions or concerns

Happy building!

Jirka
___
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: Copr drops sqlite databases and AppStream from repo metadata

[Vitaly Zaitsev via devel]

On 14/03/2023 08:19, Pavel Raiskup wrote:

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:


Please keep it enabled for preloaded phracek/PyCharm[1] repo. We've been 
asked[2] several times to enable it for GNOME software integration.


[1]: https://copr.fedorainfracloud.org/coprs/phracek/PyCharm/
[2]: https://github.com/phracek/pycharm-community-edition/issues/47

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