Re: User SSH access to Copr builders
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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)
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)
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)
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)
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
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
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/hypervisor level, it's currently impossible to turn off. This is not someth
Re: ARM PAC on koji vs COPR
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On úterý 8. srpna 2023 19:12:36 CEST Tomas Hrcka wrote: > Fedora Linux 39 is going to be branched in the upcoming hours as per > the previous discussion[1] we are going to disable new koji builds for > the duration of this event. > > All builds that will be running at that time for the rawhide will be > canceled and can be resubmitted by maintainers after the branching. > > All rawhide updates that are in a pending state for rawhide will be unpushed. > > Once Fedora Linux 39 is branched we will reenable builds in koji with > notification to this list. Just a quick update; we branched Rawhide to Fedora 39 in Fedora Copr yesterday, and recently made the chroots available. Happy building! Pavel ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora Copr has Fedora 39 now, Was: Re: Disabling rawhide builds during branching - happening in 2hrs
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Copr - look back at 2022
Let me sum up what the Copr team did during 2022. The review of 2021 can be found at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R2MWYN7CRF34WKSRUUYNLAISQB47MHXI/ <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R2MWYN7CRF34WKSRUUYNLAISQB47MHXI/> Mock: * We did six releases of Mock <https://rpm-software-management.github.io/mock/#release-notes>Starting with a major upgrade to 3.x that dropped python2 support and EL7 as the host platform. * We added `--list-chroots` option. Allow better customization of used tar binary and adapt to the new split of qemu-user-static package. * We also added lots of new chroots: AlmaLinux, RockyLinux, EuroLinux, OpenEuler, and a few others… Copr: * We did nine releases of Copr <https://docs.pagure.org/copr.copr/release_notes.html>and upgraded Copr servers to Fedora 37. * We wrote two “4 cool new projects to try in Copr” <https://fedoramagazine.org/4-cool-new-projects-to-try-in-copr-for-august-2022/>articles for Fedora Magazine * Beside previously built of all gems from Rubygems.org we built all modules from PyPI as RPM packages Thousands of PyPI and RubyGems RPMs now available for RHEL 9 | Red Hat Developer <https://developers.redhat.com/articles/2022/06/07/thousands-pypi-and-rubygems-rpms-now-available-rhel-9>Big thanks to Karolina Surma from Python team on cooperation on this. As a side effect, we introduced pyp2spec as a second option to build directly from PyPI. * We presented <https://www.youtube.com/watch?v=LSgGno0oecs>at Fedora Nest. * We dropped APIv2. And provided guidance how to migrate your scripts https://fedora-copr.github.io/posts/api3-migration-helper <https://fedora-copr.github.io/posts/api3-migration-helper> * We added Kerberos authentication to command line tools and API https://fedora-copr.github.io/posts/how-to-use-kerberos-in-copr <https://fedora-copr.github.io/posts/how-to-use-kerberos-in-copr> * We cooperated with Packit on building SRPM in Copr https://packit.dev/postcs/copr-srpms/ <https://packit.dev/posts/copr-srpms/> * We started using IBM Cloud for native s390x builders https://pavel.raiskup.cz/blog/fedora-copr-uses-ibm-cloud.html<https://pavel.raiskup.cz/blog/fedora-copr-uses-ibm-cloud.html>As a side effect we packaged python modules for managing resources in IBM Cloud. * We spent lots of time optimizing the scheduler in Copr. E.g. o Builds from webhooks are now background jobs https://docs.pagure.org/copr.copr/release-notes/2022-02-03.html#webhook-rebuilds-are-background-jobs-now <https://docs.pagure.org/copr.copr/release-notes/2022-02-03.html#webhook-rebuilds-are-background-jobs-now> o We improved the throughput when the queue is bigger than 70k jobs https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#large-queue-improvements <https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#large-queue-improvements> o And we were able to increase quota of parallel builds for one user from 35 to 45. * We started using SHA256 for signing packages https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#signing-packages-with-sha256 <https://docs.pagure.org/copr.copr/release-notes/2022-03-21.html#signing-packages-with-sha256> * We started using OpenPGP v4 signatures and we were one of the first to discover issues with new Sequoia backend of RPM with older version of signatures. * We created a webUI statistics page that shows the utilization of resalloc <https://github.com/praiskup/resalloc>resources https://docs.pagure.org/copr.copr/release-notes/2022-06-22.html#resalloc-webui * We (finally) were able to count download statistics from CDN https://docs.pagure.org/copr.copr/release-notes/2022-08-18.html#rpm-download-statistics <https://docs.pagure.org/copr.copr/release-notes/2022-08-18.html#rpm-download-statistics> * You can submit more builds at once from command line https://docs.pagure.org/copr.copr/release-notes/2022-07-27.html#submitting-multiple-builds-at-once-via-copr-cli <https://docs.pagure.org/copr.copr/release-notes/2022-07-27.html#submitting-multiple-builds-at-once-via-copr-cli> * We upgraded aarch64 builders to stronger Graviton3 machines https://docs.pagure.org/copr.copr/release-notes/2022-11-28.html#updated-aarch64-builders-to-graviton3-processors <https://docs.pagure.org/copr.copr/release-notes/2022-11-28.html#updated-aarch64-builders-to-graviton3-processors> * We migrated our git project to GitHub https://docs.pagure.org/copr.copr/release-notes/2022-11-28.html#development-moved-to-github <https://docs.pagure.org/copr.copr/release-notes/2
Disabling Fedora 35 chroots in Copr
Hello, we have just disabled Fedora 35 chroots in Copr. According to the Fedora wiki [1], Fedora 35 reached the end of its life on 2022-12-13 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-35-x86_64 - fedora-35-i386 - fedora-35-ppc64le - fedora-35-aarch64 - fedora-35-armhfp - fedora-35-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: Scripts to rebuild dependencies in copr
On Thu, Dec 22, 2022 at 4:46 AM Kevin Fenzi wrote: > > On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote: > > I've been using an old review_pr.py script produced by the Fedora > > Stewardship SIG to rebuild the depedencies of a package in COPR to test > > changes/updates to packages. It's been incredibly useful. However, it > > seems that the github repo has disappeared. > > > > Is there anything else out there in use that is actively maintained? > > There's the mass pre build project that was recently announced here: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/ > > I've not tried it yet, but it's on my list to look at. I have tried it on a simple package with only a few dependencies, including a recursive one (for which I had already manually done all the usual processes needed to determine dependencies and rebuild so I already knew how things should be expected to go) and after a bit of a learning curve using a new tool, I found it worked rather well, and certainly was less error prone than doing things the way I had been doing them (manually) on the occasion I had needed to do such rebuilds. The project is certainly worth a look. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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: Scripts to rebuild dependencies in copr
Dne 22. 12. 22 v 5:45 Kevin Fenzi napsal(a): On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote: I've been using an old review_pr.py script produced by the Fedora Stewardship SIG to rebuild the depedencies of a package in COPR to test changes/updates to packages. It's been incredibly useful. However, it seems that the github repo has disappeared. Is there anything else out there in use that is actively maintained? There's the mass pre build project that was recently announced here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/ I've not tried it yet, but it's on my list to look at. I can just recommend it. It is great already and it quickly becomes even better. Vít It looks like it mostly does everything the review_pr.py script did, except you have to give it a src.rpm instead of just the pr. (possibly that could be a RFE on mass prebuild?) 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 OpenPGP_signature Description: OpenPGP digital 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: Scripts to rebuild dependencies in copr
On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote: > I've been using an old review_pr.py script produced by the Fedora > Stewardship SIG to rebuild the depedencies of a package in COPR to test > changes/updates to packages. It's been incredibly useful. However, it > seems that the github repo has disappeared. > > Is there anything else out there in use that is actively maintained? There's the mass pre build project that was recently announced here: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IT347SLVZ6QYNCMYRR3MNB25SJ7W5R3P/ I've not tried it yet, but it's on my list to look at. It looks like it mostly does everything the review_pr.py script did, except you have to give it a src.rpm instead of just the pr. (possibly that could be a RFE on mass prebuild?) 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
Scripts to rebuild dependencies in copr
I've been using an old review_pr.py script produced by the Fedora Stewardship SIG to rebuild the depedencies of a package in COPR to test changes/updates to packages. It's been incredibly useful. However, it seems that the github repo has disappeared. Is there anything else out there in use that is actively maintained? Thanks. -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic 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: copr and centos9 ?
To answer the first question about 'domain decomposition'.. I don't think it is something that 'most' or 'many' customers deal with. Fair enough, but for HPC scientific applications it is definitely a go-to functionality. In that case, the usual method is 'build it yourself' or 'work with others to build it in a 3rd party repository' like EPEL or similar ones. Ok, so unless someone happens to pick it up, I guess I will have drop binary builds for centos/redhat-9 for the time being. Possibly resort to adding as an additional source for my own builds (when I find time). The reasons for software not being in future RHEL is usually a split thing.. There are customers who want a specific version in RHEL and there are customers who do not unless because it is not the version they wanted. That usually makes the choice toward not including something because then no one is equally unhappy. I understand. This was always a bit limited on RedHat with lock in to some particular mpich or openmpi version. Better than debian/ubuntu, where they only have a single MPI vendor, but definitely less than SUSE with different MPI vendors/versions: - libptscotch-gnu-mpich-hpc-6.1.0 - libptscotch-gnu-mvapich2-hpc-6.1.0 - libptscotch-gnu-openmpi2-hpc-6.1.0 - libptscotch-gnu-openmpi3-hpc-6.1.0 - libptscotch-gnu-openmpi4-hpc-6.1.0 In any case, thanks for the feedback. It is certainly useful to know the root cause. Cheers! /mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and centos9 ?
On Wed, 21 Dec 2022 at 12:32, Mark Olesen wrote: > Yup, scotch doesn't seem to be in CBR either. > Doesn't even seem to be a metis library anymore either. This all seems > to be a bit odd - how do people manage domain decomposition without > metis, or scotch (and ptscotch)? Or is it expected that we should be > rolling this thirdparty software into our own builds? > Not bellyaching, just don't understand the roadmap here. > > To answer the first question about 'domain decomposition'.. I don't think it is something that 'most' or 'many' customers deal with. The fact that the software was only in 'Code Ready Builder' in EL8 means that it came with 'low' update/support mainly because it had been a build requirement of some other software in BaseOS or Appstream. The fact that it isn't in EL9 says that build requirement no longer exists and so the package was not needed to be built at all. In that case, the usual method is 'build it yourself' or 'work with others to build it in a 3rd party repository' like EPEL or similar ones. The reasons for software not being in future RHEL is usually a split thing.. There are customers who want a specific version in RHEL and there are customers who do not unless because it is not the version they wanted. That usually makes the choice toward not including something because then no one is equally unhappy. > /mark > > On 12/21/22 18:11, Stephen Smoogen wrote: > > > > > > On Wed, 21 Dec 2022 at 12:03, Sérgio Basto > <mailto:ser...@serjux.com>> wrote: > > > > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > > Checking my copr log, it seems that centos-stream-8 (and epel-8) > has > > > this: > > > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > > > I was mistaken about it working with epel-9. It also fails to load > > > there. So I guess my question has now evolved to "what replaces > > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > > > dnf --enablerepo=crb install librepo-devel > > > > > > No. I do not think that will not work as a replacement. scotch is used > > for graph functions and not 'librepo'. > > > > The package scotch and related packages are NOT in EL9, and nothing > > 'replaces' them. Instead someone will need to build them for either the > > COPR project they are using or EPEL. > > > > -- > > Stephen Smoogen, Red Hat Automotive > > Let us be kind to one another, for most of us are fighting a hard > > battle. -- Ian MacClaren > > -- > Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services ESI > Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 > 9710 149 | mark.ole...@esi-group.com www.openfoam.com | > www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de > Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas Renner > Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 > USt.-IdNr.: DE113842129 > > -- 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: copr and centos9 ?
On Wed, 2022-12-21 at 18:31 +0100, Mark Olesen via devel wrote: > Yup, scotch doesn't seem to be in CBR either. > Doesn't even seem to be a metis library anymore either. This all > seems > to be a bit odd - how do people manage domain decomposition without > metis, or scotch (and ptscotch)? Or is it expected that we should be > rolling this thirdparty software into our own builds? > Not bellyaching, just don't understand the roadmap here. > join on https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=scotch=Fedora=Fedora%20EPEL Attention , after review scotch was build for centos8 stream but not centos 9 stream https://gitlab.com/redhat/centos-stream/rpms/scotch/-/tree/c8s https://gitlab.com/redhat/centos-stream/rpms/scotch/-/commit/510c5b25db89c07f1ee0c48da615b0e1e8456425 > /mark > > On 12/21/22 18:11, Stephen Smoogen wrote: > > > > > > On Wed, 21 Dec 2022 at 12:03, Sérgio Basto > <mailto:ser...@serjux.com>> wrote: > > > > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > > Checking my copr log, it seems that centos-stream-8 (and > > epel-8) has > > > this: > > > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > > > I was mistaken about it working with epel-9. It also fails > > to load > > > there. So I guess my question has now evolved to "what > > replaces > > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > > > dnf --enablerepo=crb install librepo-devel > > > > > > No. I do not think that will not work as a replacement. scotch is > > used > > for graph functions and not 'librepo'. > > > > The package scotch and related packages are NOT in EL9, and nothing > > 'replaces' them. Instead someone will need to build them for either > > the > > COPR project they are using or EPEL. > > > > -- > > Stephen Smoogen, Red Hat Automotive > > Let us be kind to one another, for most of us are fighting a hard > > battle. -- Ian MacClaren > > -- > Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services > ESI > Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 > 9710 149 | mark.ole...@esi-group.com www.openfoam.com | > www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de > Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas > Renner > Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 > USt.-IdNr.: DE113842129 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > 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: copr and centos9 ?
Yup, scotch doesn't seem to be in CBR either. Doesn't even seem to be a metis library anymore either. This all seems to be a bit odd - how do people manage domain decomposition without metis, or scotch (and ptscotch)? Or is it expected that we should be rolling this thirdparty software into our own builds? Not bellyaching, just don't understand the roadmap here. /mark On 12/21/22 18:11, Stephen Smoogen wrote: On Wed, 21 Dec 2022 at 12:03, Sérgio Basto <mailto:ser...@serjux.com>> wrote: On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > this: > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > scotch-devel x86_64 6.0.5-3.el8 powertools > > I was mistaken about it working with epel-9. It also fails to load > there. So I guess my question has now evolved to "what replaces > powertools, scotch-devel" for redhat/centos-9 ?" > crb - CentOS 9 Stream from CentOS CRB repository. dnf --enablerepo=crb install librepo-devel No. I do not think that will not work as a replacement. scotch is used for graph functions and not 'librepo'. The package scotch and related packages are NOT in EL9, and nothing 'replaces' them. Instead someone will need to build them for either the COPR project they are using or EPEL. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services ESI Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 9710 149 | mark.ole...@esi-group.com www.openfoam.com | www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas Renner Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 USt.-IdNr.: DE113842129 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and centos9 ?
On Wed, 2022-12-21 at 12:11 -0500, Stephen Smoogen wrote: > > > On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote: > > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > > Checking my copr log, it seems that centos-stream-8 (and epel-8) > > has > > > this: > > > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > > > I was mistaken about it working with epel-9. It also fails to > > load > > > there. So I guess my question has now evolved to "what replaces > > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > > > dnf --enablerepo=crb install librepo-devel > > > > > No. I do not think that will not work as a replacement. scotch is > used for graph functions and not 'librepo'. librepo is a example of the command dnf --enablerepo=crb install scotch-devel but I just check no scotch package on centos 9s > The package scotch and related packages are NOT in EL9, and nothing > 'replaces' them. Instead someone will need to build them for either > the COPR project they are using or EPEL. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > 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: copr and centos9 ?
On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote: > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > > this: > > > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > > scotch-devel x86_64 6.0.5-3.el8 powertools > > > > I was mistaken about it working with epel-9. It also fails to load > > there. So I guess my question has now evolved to "what replaces > > powertools, scotch-devel" for redhat/centos-9 ?" > > > > crb - CentOS 9 Stream from CentOS CRB repository. > > dnf --enablerepo=crb install librepo-devel > No. I do not think that will not work as a replacement. scotch is used for graph functions and not 'librepo'. The package scotch and related packages are NOT in EL9, and nothing 'replaces' them. Instead someone will need to build them for either the COPR project they are using or EPEL. -- 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: copr and centos9 ?
On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote: > Checking my copr log, it seems that centos-stream-8 (and epel-8) has > this: > > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools > scotch-devel x86_64 6.0.5-3.el8 powertools > > I was mistaken about it working with epel-9. It also fails to load > there. So I guess my question has now evolved to "what replaces > powertools, scotch-devel" for redhat/centos-9 ?" > crb - CentOS 9 Stream from CentOS CRB repository. dnf --enablerepo=crb install librepo-devel > > On 12/21/22 17:25, Stephen Smoogen wrote: > > > > > > On Wed, 21 Dec 2022 at 11:05, Michael J Gruber > > > <mailto:m...@fedoraproject.org>> wrote: > > > > > The devel package are not included in CentOS repositories > > unless > > requested > > > > Yes, but Mark reports that his package builds "with EPEL, but > > not > > with CentOS". As for as I know, we have the following in copr: > > > > chroot "epel 9" has base RHEL9 and repos > > base+AppStream+CRB+Extras+EPEL > > chroot "centos stream 9" has base CentOS Stream 9 and repos > > base+AppStream+Extras+CRB > > > > So, where do the devel packages in Mark's build come from? They > > can't be in EPEL if the lib is in RHEL. > > > > Also: What is the "devel" repo mentioned in the centos FAQ, > > i.e. > > what is the proper dnf repo name and which copr chroot uses it? > > Every time I think I figured out the EL landscape it gets more > > complex ... > > > > > > The devel repo was something that was meant to be a stop-gap for > > packages needed for EPEL early on. It no longer exists and should > > be > > removed from the FAQ. > > > > I don't see any scotch package in RHEL-9, CentOS Stream-9, OR EPEL- > > 9 > > repositories. I don't know how this build was working previously. > > > > -- > > 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 > > -- > Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services > ESI > Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 > 9710 149 | mark.ole...@esi-group.com www.openfoam.com | > www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de > Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas > Renner > Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 > USt.-IdNr.: DE113842129 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > 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: copr and centos9 ?
Checking my copr log, it seems that centos-stream-8 (and epel-8) has this: ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools scotch-devel x86_64 6.0.5-3.el8 powertools I was mistaken about it working with epel-9. It also fails to load there. So I guess my question has now evolved to "what replaces powertools, scotch-devel" for redhat/centos-9 ?" On 12/21/22 17:25, Stephen Smoogen wrote: On Wed, 21 Dec 2022 at 11:05, Michael J Gruber <mailto:m...@fedoraproject.org>> wrote: > The devel package are not included in CentOS repositories unless requested Yes, but Mark reports that his package builds "with EPEL, but not with CentOS". As for as I know, we have the following in copr: chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL chroot "centos stream 9" has base CentOS Stream 9 and repos base+AppStream+Extras+CRB So, where do the devel packages in Mark's build come from? They can't be in EPEL if the lib is in RHEL. Also: What is the "devel" repo mentioned in the centos FAQ, i.e. what is the proper dnf repo name and which copr chroot uses it? Every time I think I figured out the EL landscape it gets more complex ... The devel repo was something that was meant to be a stop-gap for packages needed for EPEL early on. It no longer exists and should be removed from the FAQ. I don't see any scotch package in RHEL-9, CentOS Stream-9, OR EPEL-9 repositories. I don't know how this build was working previously. -- 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 -- Dr Mark OLESEN Principal Engineer - OpenFOAM Development - Services ESI Germany GmbH | Einsteinring 24 | 85609 Munich | Germany Mob. +49 171 9710 149 | mark.ole...@esi-group.com www.openfoam.com | www.esi-group.com Managing Director/Geschäftsführer: Dr. Cristel de Rouvray - Dr. Alain de Rouvray - Dr. Vincent Chaillou - Andreas Renner Commercial Register/Handelsregister Amtsgericht Offenbach | HRB 47146 USt.-IdNr.: DE113842129 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and centos9 ?
On Wed, 21 Dec 2022 at 11:05, Michael J Gruber wrote: > > The devel package are not included in CentOS repositories unless > requested > > Yes, but Mark reports that his package builds "with EPEL, but not with > CentOS". As for as I know, we have the following in copr: > > chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL > chroot "centos stream 9" has base CentOS Stream 9 and repos > base+AppStream+Extras+CRB > > So, where do the devel packages in Mark's build come from? They can't be > in EPEL if the lib is in RHEL. > > Also: What is the "devel" repo mentioned in the centos FAQ, i.e. what is > the proper dnf repo name and which copr chroot uses it? Every time I think > I figured out the EL landscape it gets more complex ... > The devel repo was something that was meant to be a stop-gap for packages needed for EPEL early on. It no longer exists and should be removed from the FAQ. I don't see any scotch package in RHEL-9, CentOS Stream-9, OR EPEL-9 repositories. I don't know how this build was working previously. -- 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: copr and centos9 ?
> The devel package are not included in CentOS repositories unless requested Yes, but Mark reports that his package builds "with EPEL, but not with CentOS". As for as I know, we have the following in copr: chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL chroot "centos stream 9" has base CentOS Stream 9 and repos base+AppStream+Extras+CRB So, where do the devel packages in Mark's build come from? They can't be in EPEL if the lib is in RHEL. Also: What is the "devel" repo mentioned in the centos FAQ, i.e. what is the proper dnf repo name and which copr chroot uses it? Every time I think I figured out the EL landscape it gets more complex ... ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and centos9 ?
Dne 21. 12. 22 v 16:14 Mark Olesen via devel napsal(a): I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for building on epel9 and centos-stream-9 (both x86_64). With the centos-stream-9 I get these messages: Updating Subscription Management repositories. Unable to read consumer identity This system is not registered with an entitlement server. You can use subscription-manager to register. This is just check. Not actually an error. And later No matching package to install: 'ptscotch-openmpi-devel' No matching package to install: 'scotch-devel' Seems to build ok with EPEL, but not with centos. Questions: - Should I be using centos-9 for builds? - Where can I determine who should be providing the scotch packages? Or are they just collateral to the subscription complaint? The devel package are not included in CentOS repositories unless requested https://wiki.centos.org/FAQ/develrepo The FAQ mention RHEL 8 but the process is the same for RHEL 9 (and CentOS Stream). Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
copr and centos9 ?
I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for building on epel9 and centos-stream-9 (both x86_64). With the centos-stream-9 I get these messages: Updating Subscription Management repositories. Unable to read consumer identity This system is not registered with an entitlement server. You can use subscription-manager to register. And later No matching package to install: 'ptscotch-openmpi-devel' No matching package to install: 'scotch-devel' Seems to build ok with EPEL, but not with centos. Questions: - Should I be using centos-9 for builds? - Where can I determine who should be providing the scotch packages? Or are they just collateral to the subscription complaint? Thanks for any info. /mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Build Failures for fedora-35-i686
On Sun, 2022-12-18 at 16:07 +0100, Vitaly Zaitsev via devel wrote: > On 18/12/2022 12:20, Frank Crawford wrote: > > Can anyone explain what is going on? > > Fedora no longer has i686 mirrors, so COPR or mock use Koji's > buildroot. > It was recently removed due to F35 EOL so you can no longer build F35 > i686 packages. Thank you Vitaly, that is understandable. Regards Frank ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and rpmautospec
On 18/12/2022 15:14, Michael J Gruber wrote: %autorelease needs the git history, and you are building from dist-git, so that part is fine. COPR has Git history. Example: https://copr-dist-git.fedorainfracloud.org/cgit/xvitaly/matrix/neochat.git/log/ -- 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
Re: COPR and rpmautospec
* Michael J. Gruber: > I'm afraid you're not holding it right ;) > > %autorelease needs the git history, and you are building from > dist-git, so that part is fine. But you are not using `Release: > %autorelease` but, instead, there are additional tags in there. And - > depending on your view on old vs. new version names - this is wrong > anyways, or rpmautospec should support it ;) I was building from dist-git, but not using the dist-git method. Apparently this makes all the difference. I tweaked the Release: line as well, just in case. Anyway, the combined effect is that the NVR in COPR matches Koji once more. Thanks for nudging me in the right direction. 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: COPR Build Failures for fedora-35-i686
On 18/12/2022 12:20, Frank Crawford wrote: Can anyone explain what is going on? Fedora no longer has i686 mirrors, so COPR or mock use Koji's buildroot. It was recently removed due to F35 EOL so you can no longer build F35 i686 packages. -- 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
Re: COPR Build Failures for fedora-35-i686
* Frank Crawford: > I'm trying to build a package (rdiff-backup) for multiple > architectures and releases of Fedora, and all of them work, except > fedora-35-i686, which comes up with the following complaint: > > This system is not registered with an entitlement server. You can use > subscription-manager to register. This is just a warning, not relevant to Fedora. > While I originally thought it may be related to the EOL for Fedora 35, > it is only affecting the i686 architecture, and all other > architectures build without an issue. For reference it is from Build > 5152928. > > Can anyone explain what is going on? It can't get the buildroot from Koji: | Errors during downloading metadata for repository 'local': | - Status code: 403 for https://kojipkgs.fedoraproject.org/repos/f35-build/latest/i386/repodata/repomd.xml (IP: 38.145.60.20) | Error: Failed to download metadata for repo 'local': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried That only happens for i686 because there is no compose that COPR can use, so it's configured to use the Koji buildroot directly. So the error for fedora-35-i686 is not unexpected, I would say. 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: COPR and rpmautospec
I'm afraid you're not holding it right ;) %autorelease needs the git history, and you are building from dist-git, so that part is fine. But you are not using `Release: %autorelease` but, instead, there are additional tags in there. And - depending on your view on old vs. new version names - this is wrong anyways, or rpmautospec should support it ;) In any (well ...) case, the bare case works (see e.g. https://copr.fedorainfracloud.org/coprs/mjg/mupdf/builds/ from a dist-git fork). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 Build Failures for fedora-35-i686
Folks, I'm trying to build a package (rdiff-backup) for multiple architectures and releases of Fedora, and all of them work, except fedora-35-i686, which comes up with the following complaint: This system is not registered with an entitlement server. You can use subscription-manager to register. While I originally thought it may be related to the EOL for Fedora 35, it is only affecting the i686 architecture, and all other architectures build without an issue. For reference it is from Build 5152928. Can anyone explain what is going on? Regards Frank ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: 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 and rpmautospec
On Sat, Dec 17, 2022, 20:59 Florian Weimer wrote: > It looks like COPR always produces 1 for %autorelease. Is this a known > issue? Is there a way around it? > > Here's a build that shows this: > > < > https://copr.fedorainfracloud.org/coprs/fweimer/modernc-1/build/5152562/> > > Thanks, > Florian > The problem is that rpmautospec can only determine correct release and changelog when run in a dist-git repo, which might not be available when in COPR. There should be at least two ways to work around this, I think: 1. Upload an SRPM file that was already pre-processed (i.e. the file produced by "fedpkg srpm"). It has correct Release and %changelog baked into it. 2. When using dist-git as package source directly, there should be a way to configure COPR to use "fedpkg srpm" to build the srpm file instead of fedpkg-minimal (or whatever COPR uses by default, which doesn't support rpmautospec). That should also produce srpm with correct Release and %changelog (though I have not tested this). Hope that helps. Fabio PS: Sorry for possibly weird formatting. Writing this on my phone, I'm not at my PC this weekend. ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: 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: COPR and rpmautospec
On 17/12/2022 20:59, Florian Weimer wrote: It looks like COPR always produces 1 for %autorelease. Is this a known issue? Yes. rpmautospec works correctly only in Fedora Koji. In rpmbuild, mock, COPR, it will always use 1. Is there a way around it? I didn't find it, so I reverted my packages back to the classic style. -- 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 and rpmautospec
It looks like COPR always produces 1 for %autorelease. Is this a known issue? Is there a way around it? Here's a build that shows this: <https://copr.fedorainfracloud.org/coprs/fweimer/modernc-1/build/5152562/> 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: Copr delete-by-default expiration policy still unacceptable
On Fri, Oct 14, 2022 at 09:24:05AM +0200, Miroslav Suchý wrote: > Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): > > At least allow the opt-out per maintainer. > > > > I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and > > then evaluate how many maintainers actually check that checkbox and how much > > resource usage is actually caused by it. Then after a year or two, decide > > whether to keep the checkbox or revert to the current status quo. Or drop it > > sooner if you really run out of disk space as quickly as you seem to expect. > > I will discuss this with the team. > > History lesson: > > in past, we did not deleted old repos. And it was on user to delete it. > And almost **nobody** clean up their repos. That is entirely predictable behaviour, seen by almost free service which doesn't have usage limits. When all the cost pressures fall on a 3rd party there is no incentive for people to moderate their usage, whether it be CPU burn, storage usage, network bandwidth, or something else. Any free service will almost inevitably end up imposing policies to control usage in areas where they're feeling the greatest burden, once their funding starts to look unsustainable, or the sponsoring orgs' priorities change. For storage it either ends up with old stuff being force deleted, or users accounts get finite quota applied as a means to force users to delete stuff themselves past a certain point, or both, depending on the usage patterns seen. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 16:24 Josh Boyer napsal(a): Would you be willing to pay for that feature? BTW I have been seriously probing for some time whether people would be willing to pay for private repositories. And this is my first time mentioning it in public space :) Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 17:18 PGNet Dev napsal(a): Another option is to get the containerized COPR efforts polished & available. Then, any/all could spin them up easily (aka, far easier than now), and deploy locally, &/or make available ... and, charge some reasonable fee for those downloads. https://pagure.io/copr/copr/pull-request/2193 Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 14:41 Kevin Kofler via devel napsal(a): At least allow the opt-out per maintainer. I would suggest to add the permanent opt-out checkbox, mark it "(BETA)", and then evaluate how many maintainers actually check that checkbox and how much resource usage is actually caused by it. Then after a year or two, decide whether to keep the checkbox or revert to the current status quo. Or drop it sooner if you really run out of disk space as quickly as you seem to expect. I will discuss this with the team. History lesson: in past, we did not deleted old repos. And it was on user to delete it. And almost **nobody** clean up their repos. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Copr delete-by-default expiration policy still unacceptable
Dne 13. 10. 22 v 15:27 Stephen Smoogen napsal(a): The problem is that they HAVE been running out of disk space quite regularly. This is not a new problem as COPR has bounced off of zero storage over time as various 'newer' hardware is moved over for their usage. Currently, the storage they are using is an aging disk service which will go out of warranty in about a year. This is situation we used to have. Nowadays we use a storage from AWS (we are grateful for their sponsoring). And we got it for free. The problem is that we just hit a glass ceiling of this unlimited service as you cannot create volume larger than 16 TB. Last month we spent some time investigating the options (EFS, RAIDs) and we decided to use RAID of several volumes. We have a WIP blogpost about this. The problem is not money right now, but maintainability. E.g., it take **days** to sync the volumes. And it took us two weeks of preparation to prepare for migration (which will happen in few days and is about to be announced) which will last just few hours. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
