On Mon, Feb 10, 2020 at 01:46:14AM -0700, John M. Harris Jr wrote:
> So long as people are willing to maintain it, why restrict peoples' ability
> to
> work on something, especially while users are stuck on that version, or
> forced
> to move elsewhere if they cannot get a fix and cannot upgra
On Thursday, January 30, 2020 6:31:37 PM MST Kevin Fenzi wrote:
> On Thu, Jan 23, 2020 at 11:07:21AM -0700, John M. Harris Jr wrote:
> > EOL is not, literally, EOL. EOL just means the complete end of support, in
> > commercial products. Still doesn't mean systems with that version
> > installed
> >
On Thu, Jan 23, 2020, 9:04 AM Stephen John Smoogen wrote:
> On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote:
> >
> > Kevin Kofler wrote:
> > > IMHO, this whole "delete by default" concept is inherently flawed and
> > > dangerous and cannot be fixed. Notification e-mails can be lost in so
> many
On Thu, Jan 23, 2020 at 11:07:21AM -0700, John M. Harris Jr wrote:
>
> EOL is not, literally, EOL. EOL just means the complete end of support, in
> commercial products. Still doesn't mean systems with that version installed
> cease to exist. In Fedora, it simply means that it gets little attenti
On Thursday, January 23, 2020 7:05:14 AM MST Miroslav Suchý wrote:
> Dne 22. 01. 20 v 12:03 Kevin Kofler napsal(a):
>
> > I also do not understand why 6 TB of disk space is such an issue in times
> >
> > where one single HDD can carry up to 16 TB.
>
>
> Because you need more of them because of
On Wed, 22 Jan 2020 at 06:04, Kevin Kofler wrote:
>
> Kevin Kofler wrote:
> > IMHO, this whole "delete by default" concept is inherently flawed and
> > dangerous and cannot be fixed. Notification e-mails can be lost in so many
> > ways (wrong Fedora notification settings, e-mail provider issues, s
Dne 22. 01. 20 v 12:03 Kevin Kofler napsal(a):
> I also do not understand why 6 TB of disk space is such an issue in times
> where one single HDD can carry up to 16 TB.
Because you need more of them because of RAID. And because once you reach the
roof - 16 GB atm - the price does not grow
linear
On Wednesday, January 22, 2020 1:05:45 PM CET Kevin Kofler wrote:
> Miro Hrončok wrote:
> > Do you realize that copr is a free service (as in free beer in this
> > argument)?
>
> So is Fedora as a whole, yet it does not completely delete EOL releases,
> but puts them on archive.fedoraproject.org.
>
On 2020-01-22 12:03, Kevin Kofler wrote:
Kevin Kofler wrote:
IMHO, this whole "delete by default" concept is inherently flawed and
dangerous and cannot be fixed. Notification e-mails can be lost in so many
ways (wrong Fedora notification settings, e-mail provider issues, spam
filter false posi
On 22. 01. 20 13:05, Kevin Kofler wrote:
Miro Hrončok wrote:
Do you realize that copr is a free service (as in free beer in this
argument)?
So is Fedora as a whole, yet it does not completely delete EOL releases, but
puts them on archive.fedoraproject.org.
Gratuity (the state of being free as
Miro Hrončok wrote:
> Do you realize that copr is a free service (as in free beer in this
> argument)?
So is Fedora as a whole, yet it does not completely delete EOL releases, but
puts them on archive.fedoraproject.org.
Gratuity (the state of being free as in beer) is no excuse for deliberate
d
On 22. 01. 20 12:03, Kevin Kofler wrote:
Kevin Kofler wrote:
IMHO, this whole "delete by default" concept is inherently flawed and
dangerous and cannot be fixed. Notification e-mails can be lost in so many
ways (wrong Fedora notification settings, e-mail provider issues, spam
filter false positi
Kevin Kofler wrote:
> IMHO, this whole "delete by default" concept is inherently flawed and
> dangerous and cannot be fixed. Notification e-mails can be lost in so many
> ways (wrong Fedora notification settings, e-mail provider issues, spam
> filter false positives, out-of-quota mailbox, etc.) or
Jakub Kadlcik wrote:
> I am truly sorry to hear that. I am afraid, that there is no way to
> recover those data. Thank you for reporting it though, I have investigated
> the issue and did as much as I could to prevent it from happening in the
> future.
>
> I wrote some unit tests for the feature a
On Wednesday, January 22, 2020 8:35:32 AM CET Pavel Raiskup wrote:
> On Tuesday, January 21, 2020 11:59:50 PM CET Jakub Kadlcik wrote:
> > > For what it's worth, I never got the promised notification for my Coprs.
> > > The legacy chroots are just gone forever with no warning whatsoever.
> > > > I
On Tuesday, January 21, 2020 11:59:50 PM CET Jakub Kadlcik wrote:
> > For what it's worth, I never got the promised notification for my Coprs.
> > The legacy chroots are just gone forever with no warning whatsoever.
>
> I am truly sorry to hear that. I am afraid, that there is no way to recover
>
> For what it's worth, I never got the promised notification for my Coprs.
> The legacy chroots are just gone forever with no warning whatsoever.
I am truly sorry to hear that. I am afraid, that there is no way to recover
those data. Thank you for reporting it though, I have investigated the
issue
Neal Gompa wrote:
> * building containers, ISOs, disk images
+1 (at least installable live ISOs).
> using kiwi and/or appliance-tools+livecd-tools/lorax
I vote for livecd-creator from livecd-tools, it is the easiest to use
(and in particular, livecd-creator accepts kickstarts from livemedia-cre
Miroslav Suchý wrote:
> * We removed outdated chroots, which allowed us to reclaim terabytes of
> disk space. At the same time, we give you the option to keep those old
> repos if you want them.
> http://frostyx.cz/posts/copr-removing-outdated-chroots
For what it's worth, I never got the promised
> * something else - is something blocking you from using Copr? Please share
> it with us.
Right now, getting https://bugzilla.redhat.com/show_bug.cgi?id=1572596 fixed
will unblock building java packages on CentOS Stream / EPEL 8.
___
devel mailing l
Dne 08. 01. 20 v 17:59 Neal Gompa napsal(a):
> This is an interesting idea, but I'd really like to see an integrated
> registry offering in Copr
This would require MUCH bigger storage. I estimated it 100+ TB.
Red Hat donated us 20TB storage, but that is enough just for RPMs not for
container ima
On Wed, Jan 8, 2020 at 12:32 PM Iñaki Ucar wrote:
>
> On Wed, 8 Jan 2020 at 18:08, Neal Gompa wrote:
> >
> > * automatic rebuilds of packages when dependencies change
>
> But this doesn't even happen in Koji, right? Cross-repo is even more
> challenging. Besides, this is only needed when there's
On Wed, 8 Jan 2020 at 18:31, Iñaki Ucar wrote:
>
> * Task blocking based on dependencies per chroot. If I submit tasks
> [A, B, C] and [B, C] depend on A, I want [B, C] blocked in "pending"
> until A is successfully built. Maybe a couple of retries if A fails,
> and then [B, C] should be skipped i
On Wed, 8 Jan 2020 at 18:08, Neal Gompa wrote:
>
> * automatic rebuilds of packages when dependencies change
But this doesn't even happen in Koji, right? Cross-repo is even more
challenging. Besides, this is only needed when there's a soname bump.
Otherwise, it would be just a waste of resources.
On Wed, Jan 8, 2020 at 4:01 AM Miroslav Suchý wrote:
>
> * build Flatpak application from your project - we have a viable idea how to
> build Flatpak app from your project with
> just a few clicks, and we can upload the result to some registry. E.g., to
> https://quay.io/
This is an interestin
Le 08/01/2020 à 10:00, Miroslav Suchý a écrit :
* build Flatpak application from your project - we have a viable idea how to
build Flatpak app from your project with
just a few clicks, and we can upload the result to some registry. E.g., to
https://quay.io/
If it works as I understand it, tha
On Wed, Jan 8, 2020, 12:19 Miroslav Suchý wrote:
> Dne 08. 01. 20 v 11:15 Fabio Valentini napsal(a):
> > How do I actually enable this? I can't find it, neither in the web
> > interface, nor in copr-cli.
> > It would be useful to have this set up for my elementary-nightly COPR,
> > since there ar
Dne 08. 01. 20 v 11:15 Fabio Valentini napsal(a):
> How do I actually enable this? I can't find it, neither in the web
> interface, nor in copr-cli.
> It would be useful to have this set up for my elementary-nightly COPR,
> since there are 1+ builds in there, accumulated since 2015, and I
> rea
Dne 08. 01. 20 v 11:18 Dan Horák napsal(a):
> if COPR can utilize remote (cloud) resources, I would concentrate on
> such way. When we will know the requirements, we can work with our
> partners to allocate them.
Copr can use cloud. Or almost anything. We use OpenStack. We have AARCH64
builders i
On Wed, 8 Jan 2020 10:00:07 +0100
Miroslav Suchý wrote:
> I want to sum up what happened in Copr during 2019. At the end of
> this email, you can see our TODO list and cast your vote on what we
> should focus on.
>
> What are our plans for 2020? We have some mandatory tasks:
> * migrate to new d
On Wed, Jan 8, 2020 at 10:01 AM Miroslav Suchý wrote:
>
> I want to sum up what happened in Copr during 2019. At the end of this email,
> you can see our TODO list and cast your
> vote on what we should focus on.
Hi!
Thanks for all this work, COPR is super useful.
> During the year 2019:
>
> *
@all: Please note that "yes" is 1, on the left, in the form. I was
casting wrong votes assuming 5 meant more votes for that option
without actually reading it.
@msuchy, @praiskup and the rest of the team: Thanks for the great work!
Iñaki
On Wed, 8 Jan 2020 at 10:08, Miroslav Suchý wrote:
>
> I
This is awesome. Also I've been dreaming for a long time to simplified and
integrated this chain:
Playing with package in Copr → Review Request package from Copr and import it
to RHBZ in one click. This could save a lot of time and make easier maintainers
life. SUSE already did something like th
I want to sum up what happened in Copr during 2019. At the end of this email,
you can see our TODO list and cast your
vote on what we should focus on.
During the year 2019:
* we added native AARCH64 builders
* we added emulated ARMhfp builders
* released eight new versions of Mock including feat
34 matches
Mail list logo
