On 24/04/2025 14:57, Jocelyn Falempe wrote:
On 24/04/2025 01:06, Adam Williamson wrote:
On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote:
(but on a serious level, how does configuring keyboard layout / input
method work if all you have is a compositor and a terminal app?
presumably rea
Hello,
On Wed, 2025-04-23 at 10:34 -0700, Adam Williamson wrote:
> On Wed, 2025-04-23 at 18:17 +0200, Jocelyn Falempe wrote:
> > systemd has the localectl command to do that, it also generates a
> > file
> > /etc/vconsole.conf which has the keymap information.
>
> Hmm, but this is still problema
On Wed, Apr 23, 2025 at 04:06:15PM -0700, Adam Williamson wrote:
> On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote:
> > > > >
> > > > > (but on a serious level, how does configuring keyboard layout / input
> > > > > method work if all you have is a compositor and a terminal app?
> > > > >
I am sorry to repeat it for the 3rd time,
But for a "stupidly minimal" stack, cage, weston etc... all exist with foot,
weston-terminal, etc...
You will be solved of many problems small and big, once the *only* stack is the
wayland stack (maybe different protocols, but the same libraries).
All c
On Thu, Apr 24, 2025 at 12:02 PM Adam Williamson
wrote:
>
> On Thu, 2025-04-24 at 14:57 +0200, Jocelyn Falempe wrote:
> > >
> > > One thing that would need to be figured out is whether each of the
> > > Wayland-based console implementations actually provides a mechanism to
> > > switch between mul
On Thu, 2025-04-24 at 14:57 +0200, Jocelyn Falempe wrote:
> >
> > One thing that would need to be figured out is whether each of the
> > Wayland-based console implementations actually provides a mechanism to
> > switch between multiple configured xkb layouts. This is something users
> > of switche
On 24/04/2025 01:06, Adam Williamson wrote:
On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote:
(but on a serious level, how does configuring keyboard layout / input
method work if all you have is a compositor and a terminal app?
presumably read from a file...has the format and location b
On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote:
> I think I can do the same in kmscon, or maybe there is a better way than
> running an external command, and parsing the output. I will see if I
> find something.
Oh, and as for avoiding running an external command - I believe you can
qu
On Thu, 2025-04-24 at 00:25 +0200, Jocelyn Falempe wrote:
> > > >
> > > > (but on a serious level, how does configuring keyboard layout / input
> > > > method work if all you have is a compositor and a terminal app?
> > > > presumably read from a file...has the format and location been
> > > > sta
ompa wrote:
> >>>> On Wed, Apr 23, 2025 at 11:42 AM Adam Williamson
> >>>> wrote:
> >>>>>
> >>>>> On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
> >>>>>> Hi,
> >>>>>>
> >>&g
, Jocelyn Falempe wrote:
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
They can replace fbcon (The default kernel-based console), have more
features (like scrolling) and are more secure as they run in userspace.
* Kmscon: https://copr.fedorainfracloud.org/
On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
> > > > > Hi,
> > > > >
> > > > > I've packaged 3 userspace consoles, on my copr repository for Fedora.
> > > > > They can replace fbcon (The default kernel-b
On 23/04/2025 18:01, Adam Williamson wrote:
On Wed, 2025-04-23 at 11:43 -0400, Neal Gompa wrote:
On Wed, Apr 23, 2025 at 11:42 AM Adam Williamson
wrote:
On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
t; > > Hi,
> > > >
> > > > I've packaged 3 userspace consoles, on my copr repository for Fedora.
> > > > They can replace fbcon (The default kernel-based console), have more
> > > > features (like scrolling) and are more secure as they
On Wed, 2025-04-23 at 11:43 -0400, Neal Gompa wrote:
> On Wed, Apr 23, 2025 at 11:42 AM Adam Williamson
> wrote:
> >
> > On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
> > > Hi,
> > >
> > > I've packaged 3 userspace consoles, on my
On Wed, Apr 23, 2025 at 11:42 AM Adam Williamson
wrote:
>
> On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
> > Hi,
> >
> > I've packaged 3 userspace consoles, on my copr repository for Fedora.
> > They can replace fbcon (The default kernel-based con
On Tue, 2025-04-22 at 11:51 +0200, Jocelyn Falempe wrote:
> Hi,
>
> I've packaged 3 userspace consoles, on my copr repository for Fedora.
> They can replace fbcon (The default kernel-based console), have more
> features (like scrolling) and are more secure as t
On 22/04/2025 13:25, Neal Gompa wrote:
On Tue, Apr 22, 2025 at 5:52 AM Jocelyn Falempe wrote:
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
They can replace fbcon (The default kernel-based console), have more
features (like scrolling) and are more secure as
On 22/04/2025 15:23, Pramod V U via devel wrote:
Sorry for poking in, but why have kmscon, a complete re-implementation, run
over then DRM when a generic and well-tested combination of a wayland
compositor and a terminal emulator, like cage+foot, do the work just as well?
Yes, setup is initiall
On 22/04/2025 15:04, Neal Gompa wrote:
On Tue, Apr 22, 2025 at 8:46 AM Jocelyn Falempe wrote:
On 22/04/2025 13:25, Neal Gompa wrote:
On Tue, Apr 22, 2025 at 5:52 AM Jocelyn Falempe wrote:
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
They can replace
On Tue, Apr 22, 2025 at 9:24 AM Pramod V U via devel
wrote:
>
> Sorry for poking in, but why have kmscon, a complete re-implementation, run
> over then DRM when a generic and well-tested combination of a wayland
> compositor and a terminal emulator, like cage+foot, do the work just as well?
To
Sorry for poking in, but why have kmscon, a complete re-implementation, run
over then DRM when a generic and well-tested combination of a wayland
compositor and a terminal emulator, like cage+foot, do the work just as well?
Yes, setup is initially difficult. But it might be worth it.
An addition
On Tue, Apr 22, 2025 at 8:46 AM Jocelyn Falempe wrote:
>
> On 22/04/2025 13:25, Neal Gompa wrote:
> > On Tue, Apr 22, 2025 at 5:52 AM Jocelyn Falempe wrote:
> >>
> >> Hi,
> >>
> >> I've packaged 3 userspace consoles, on my copr repository
On 22/04/2025 13:25, Neal Gompa wrote:
On Tue, Apr 22, 2025 at 5:52 AM Jocelyn Falempe wrote:
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
They can replace fbcon (The default kernel-based console), have more
features (like scrolling) and are more secure as
On Tue, Apr 22, 2025 at 5:52 AM Jocelyn Falempe wrote:
>
> Hi,
>
> I've packaged 3 userspace consoles, on my copr repository for Fedora.
> They can replace fbcon (The default kernel-based console), have more
> features (like scrolling) and are more secure as they run in us
Hi,
I've packaged 3 userspace consoles, on my copr repository for Fedora.
They can replace fbcon (The default kernel-based console), have more
features (like scrolling) and are more secure as they run in userspace.
* Kmscon: https://copr.fedorainfracloud.org/coprs/jfalempe/kmscon/
*
cript started failing:
> > https://copr.fedorainfracloud.org/coprs/whot/libinput-git/builds/
> >
> > The failing part is... the mockbuild command?
> >
> Actually the failing part is /usr/bin/su
>
> >
> > Does anyone have any clue what's going on here? Thanks.
>
>
mmand?
Actually the failing part is /usr/bin/su
Does anyone have any clue what's going on here? Thanks.
https://github.com/fedora-copr/copr/issues/3631
--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
PR_OWNER=whot
COPR_PROJECT=libinput-git COPR_PACKAGE=\'"\'"\'\'"\'"\' COPR_RESULTDIR=/workdir
/script\'']
su: Permission denied
Finish: chroot ['su - mockbuild -c \'set -xe ; cd /workdir ; COPR_OWNER=whot
COPR_PROJECT=libinput
Hello packagers,
Fedora Copr now supports Fedora OpenID Connect [1]. You can try this new
login method on the Fedora Copr page [2] using the "OIDC login" button.
If you encounter any unexpected issues, please let us know by creating an
issue at https://github.com/fedora-copr/copr/iss
Hello packagers,
we have just disabled Fedora 39 chroots in Copr.
According to Fedora wiki [1], Fedora 39 reached the end of its life on
2024-11-26 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
That's a very good question, Nikita.
Depending on modules falls in the same category as module-hotfixes for us.
In the case of module-hotfixes, Copr only generates the `module_hotfixes=1`
line into the repofile, and in the case of module dependencies, Copr only
generates `config
On Wed, Oct 23, 2024 at 5:32 PM Jakub Kadlcik wrote:
> Hello everybody,
> I'd like to announce that all Modularity features in Copr (except for
> module hotfixes) are now deprecated, and we have a plan to slowly remove
> them from our codebase.
>
> For more reasoning and
Hello everybody,
I'd like to announce that all Modularity features in Copr (except for
module hotfixes) are now deprecated, and we have a plan to slowly remove
them from our codebase.
For more reasoning and the retirement schedule, please read my blog post -
https://frostyx.cz/posts
On Mon, Sep 30, 2024 at 5:49 PM Jiri Kyjovsky wrote:
>
>> Hi,
>>
>> There will be an outage starting at:
>>
>> ```
>> $ date --date '2024-10-03 11:00 UTC'
>> ```
>>
>> The outage will last approximately 3 hours. The copr-back
And the outage is over. I'll send release notes later today.
Happy building!
On Mon, Sep 30, 2024 at 5:49 PM Jiri Kyjovsky wrote:
> Hi,
>
> There will be an outage starting at:
>
> ```
> $ date --date '2024-10-03 11:00 UTC'
> ```
>
> The outage will la
Hi,
There will be an outage starting at:
```
$ date --date '2024-10-03 11:00 UTC'
```
The outage will last approximately 3 hours. The copr-backend storage (copr
build results) will stay mostly online during this outage but some downtime
is expected.
Reason for outage:
We'r
> > > > 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
1 - 100 of 1038 matches
Mail list logo
