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
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
>
>
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
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 c
> 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+Ext
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
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
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
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
nding 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
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
| 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
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 -
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
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/bu
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
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 m
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
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
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.
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.
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
1 - 100 of 1070 matches
Mail list logo
