On Mon, Feb 19, 2024 at 10:18 AM Stephen Smoogen wrote:
>
>
>
> On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel
> wrote:
>>
>> Stephen Smoogen wrote:
>> > 1. Drive size is not just what is needed but also throughput. The large
>> > drives needed to store the data COPR uses for its hundreds
On Mon, 19 Feb 2024 at 10:08, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Stephen Smoogen wrote:
> > 1. Drive size is not just what is needed but also throughput. The large
> > drives needed to store the data COPR uses for its hundreds of chroots are
> > much 'slower' on
Stephen Smoogen wrote:
> 1. Drive size is not just what is needed but also throughput. The large
> drives needed to store the data COPR uses for its hundreds of chroots are
> much 'slower' on reads and writes even when adding in layers of RAID 1+0.
> Faster drives are possible but the price goes
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
On Mon, 19 Feb 2024 at 08:59, Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Miroslav Suchý wrote:
> > What **you** would find as acceptable policy for pruning rawhide chroots?
>
> As I mentioned several times, I already find the existing policy for
> pruning
> EOL release
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber wrote:
> I like this idea. Move things that were built for "rawhide" into the
> "fedora-40" chroot, and start Rawhide empty, requiring fresh builds of
> things.
> Since there is no equivalent to the mass rebuild in COPR, that would
> also solve
Miroslav Suchý wrote:
> What **you** would find as acceptable policy for pruning rawhide chroots?
As I mentioned several times, I already find the existing policy for pruning
EOL release chroots unacceptable (because deleting data must never be the
default – notifications can be and are still
On Sun, 2024-02-18 at 23:45 +0100, Fabio Valentini wrote:
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber
> wrote:
> >
>
> (snip)
>
> >
> > I see this somehow connected to the discussion about signing keys
> > that
> > we had recently. A radical solution would be: branch rawhide, not
> >
On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber wrote:
>
(snip)
>
> I see this somehow connected to the discussion about signing keys that
> we had recently. A radical solution would be: branch rawhide, not from
> rawhide. So, at the "F40 branch point we had last week", we would:
> - switch
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
> want to ask you - the
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
12 matches
Mail list logo
