On Thu, 18 Jul 2024 at 08:19, Pavel Raiskup wrote:
> Indeed. Plus, per-package, you can set the max number of builds that
> are being kept.
>
AFAIK, the max number of builds option applies to *any* build, successful
or not. This is not useful, and I think I opened an RFE at some point. For
me,
a proper place
> to discuss it with the rest of the Copr team.
OK, I have filed the RFE:
https://github.com/fedora-copr/copr/issues/
I would have marked it with the RFE label, but I am not allowed to set
labels as the reporter, only team members can
s like an acceptable compromise to me.
>
> I remember having once suggested that on this mailing list and having
> received a quite negative reply from a Copr team member, saying that they
> deliberately did not want to make it that easy to extend everything. But if
> you think th
gt; > Yes, that was exactly what I was suggesting. (Well, possibly with
> > > > auto-triggering builds for the new chroot if the option to follow
> > > > Fedora branching is enabled).
> > >
> > > Starting from scratch would definitely be an al
ing list and having
received a quite negative reply from a Copr team member, saying that they
deliberately did not want to make it that easy to extend everything. But if
you think the RFE has a serious chance of being considered, I can file one.
anching is enabled).
> > Starting from scratch would definitely be an alternative option (WRT to
> > storage consumption), even more radical though. Some of the projects in
> > Copr require non-trivial bootstrapping procedures (not as complicated as
> > Fedora itself, but
Starting from scratch would definitely be an alternative option (WRT to
> storage consumption), even more radical though. Some of the projects in
> Copr require non-trivial bootstrapping procedures (not as complicated as
> Fedora itself, but still).
>
What if you copied the latest build for
; Yes, that was exactly what I was suggesting. (Well, possibly with
> auto-triggering builds for the new chroot if the option to follow
> Fedora branching is enabled).
Starting from scratch would definitely be an alternative option (WRT to
storage consumption), even more radical though. Some of the
build? what if it
> > > succeed but no one uses it anyway?).
> >
> > Let me flip it around: how did you create "Fedora 40" when Rawhide
> > branched for that? I'm just saying to do it the other way around.
>
> Actually, I think the current Copr process is sim
Thank you for the reply, Kevin.
On úterý 16. července 2024 3:34:06, SELČ Kevin Kofler via devel wrote:
> Pavel Raiskup wrote:
> > This is a gentle heads-up (at least a year in advance) that we plan to
> > address Fedora Copr storage consumption related to Fedora Rawhide
> &g
ld
> > everything")? Copy everything (you end up in the same situation)? Rebuild
> > packages from previous rawhide (what if it fails to build? what if it
> > succeed but no one uses it anyway?).
>
> Let me flip it around: how did you create "Fedora 40&qu
tation you are using (which last I checked was from Amazon). I
understand that (also last I checked) the cloud infrastructure was donated
to you for free. But that donation is not of much use if it does not include
a workable amount of storage for something like Copr nor an offer to extend
t
On pondělí 15. července 2024 12:10:58, SELČ Sandro via devel wrote:
> On 15-07-2024 10:24, Pavel Raiskup wrote:
> > TL;DR: We plan to start monitoring build activity in Copr projects.
> > If no builds appear for a long time in these "rolling" chroots (such as
> >
Pavel Raiskup wrote:
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds. Currently, Rawhide build results are kept indefinitely, but
> this is going to change in the future.
>
>
On Mon, Jul 15, 2024 at 10:21 AM Miroslav Suchý wrote:
>
> Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
>
> Instead of always keeping "Rawhide" around as a separate buildroot,
> why not just rename it at Branching and then create a NEW Rawhide
> chroot?
>
> 1) Different workflow
Dne 15. 07. 24 v 2:57 odp. Stephen Gallagher napsal(a):
Instead of always keeping "Rawhide" around as a separate buildroot,
why not just rename it at Branching and then create a NEW Rawhide
chroot?
1) Different workflow compared to the one we have in Fedora.
2) Create it with what? Empty
On Mon, Jul 15, 2024 at 4:25 AM Pavel Raiskup wrote:
>
> Hello maintainers.
>
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds. Currently, Rawhide build results are
On 15-07-2024 10:24, Pavel Raiskup wrote:
TL;DR: We plan to start monitoring build activity in Copr projects.
If no builds appear for a long time in these "rolling" chroots (such as
Fedora Rawhide), we'll disable such chroots, preserve the built results
for a while, and then d
Hello maintainers.
This is a gentle heads-up (at least a year in advance) that we plan to
address Fedora Copr storage consumption related to Fedora Rawhide
builds. Currently, Rawhide build results are kept indefinitely, but
this is going to change in the future.
For the full story, see the blog
Hello maintainers,
the Copr project is in the process of implementing the PULP storage
backend (RPM repo management technology):
https://github.com/fedora-copr/copr/issues/2533
We expect that this change will be slow and incremental (we will not move
all projects to PULP at once
Hello,
tl;dr, we have just disabled Fedora 38 chroots in Copr.
According to the Fedora wiki [1], Fedora 38 reached the end
of its life [4] and therefore we are disabling it in Copr.
That effectively means that from this moment, it is no longer possible
to submit builds for the following chroots
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.pa
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
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
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
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
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 th
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
t; 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
> 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 rebui
ill 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 pr
. 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 cop
ot;, 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
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
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
&g
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
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
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
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
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
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
, 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 di
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
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
>>
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 pm
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
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
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
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
ump 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
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:
> >
> &
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 dependenci
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
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
o 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
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?
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 releas
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 s
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.fedorap
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
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 pa
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 wro
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 toda
et 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 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
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 toda
t; >
> > 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
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 b
ting 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:
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 t
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
>
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)
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
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!
> &
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 :
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
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
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
>
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
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 b
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 f
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:44
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 syn
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
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
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
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
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
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/mess
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
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
> > cha
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
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, i
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
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
, 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:
> &
1/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-
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
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
>
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
1 - 100 of 1091 matches
Mail list logo