> > > > And I really think epel-* makes no sense since it's always "+" to
> > > > > something. EPEL guidelines spell out what is the official base distro
> > > > > for which EPEL (next or what not). That is something we could add next
> >
omething. EPEL guidelines spell out what is the official base distro
> > > > for which EPEL (next or what not). That is something we could add next
> > > > to the respective chroot in copr (just like the current remarks there).
> > >
> > > The 'epel-10&
> On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup
> > > > wrote:
> > > > >
> > > > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > > > to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
&g
On čtvrtek 15. srpna 2024 15:44:26, SELČ Pavel Raiskup wrote:
> The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
> like to have the same approach for `epel-10` once there's a rel
he epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > > to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
> > > > like to have the same approach for `epel-10` once there's a released
> > > > variant of
ek 15. srpna 2024 22:27:11, SELČ Florian Weimer wrote:
> > * Peter Lemenkov:
> >
> > > Hello All!
> > > I have a few Bodhi build overrides and I love to use them in Copr. Is
> > > it possible? At least is it possible to enable updates-testing
> > > reposito
On čtvrtek 15. srpna 2024 22:27:11, SELČ Florian Weimer wrote:
> * Peter Lemenkov:
>
> > Hello All!
> > I have a few Bodhi build overrides and I love to use them in Copr. Is
> > it possible? At least is it possible to enable updates-testing
> > repository?
>
On čtvrtek 15. srpna 2024 17:02:30, SELČ Michael J Gruber wrote:
> Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> > On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote:
> > >
> > > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > > to
* Peter Lemenkov:
> Hello All!
> I have a few Bodhi build overrides and I love to use them in Copr. Is
> it possible? At least is it possible to enable updates-testing
> repository?
You can request a side tag and reference its repository in the Copr
configuration. The repositori
Hello All!
I have a few Bodhi build overrides and I love to use them in Copr. Is
it possible? At least is it possible to enable updates-testing
repository?
--
With best regards, Peter Lemenkov.
--
___
devel mailing list -- devel
Neal Gompa venit, vidit, dixit 2024-08-15 16:14:30:
> On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote:
> >
> > The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> > to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
> > l
On Thu, Aug 15, 2024 at 9:45 AM Pavel Raiskup wrote:
>
> The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
> to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
> like to have the same approach for `epel-10` once there's a released
>
The epel-8-* and epel-9-* chroots in Fedora Copr are aliases
to the "rhel+epel-*" chroots from `mock-core-configs` package. We'd
like to have the same approach for `epel-10` once there's a released
variant of RHEL 10 GA.
For now though, there's the variant `centos-stream
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,
r 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
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 alternativ
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.
hing 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
s, 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
d? 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 i
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
on you are using (which last I checked was from Amazon). I
understand that (also last I checked) the cloud infrastructure was donated
to you for free. But that donation is not of much use if it does not include
a workable amount of storage for something like Copr nor an offer to extend
the st
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 compare
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 conte
On Mon, Jul 15, 2024 at 4:25 AM Pavel Raiskup wrote:
>
> Hello maintainers.
>
> This is a gentle heads-up (at least a year in advance) that we plan to
> address Fedora Copr storage consumption related to Fedora Rawhide
> builds. Currently, Rawhide build results are kept indefi
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 de
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) and that
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://do
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 are
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 possi
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
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
adical 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
&
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 copr a
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
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
> wan
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
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 no
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 no
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
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 con
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
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
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
porting 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
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 lik
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:
bu
ty 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
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
the
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:
y 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 rpma
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,
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 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
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
ange, 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
s 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
t
, 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
ange, 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
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 6 shoul
licy_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 w
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:
h
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
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
> s
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
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 di
pel-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 maintai
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
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
> des
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
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 syncing
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 architec
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 prelo
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
1 - 100 of 1001 matches
Mail list logo
