Re: on rpms

On Mon, 30 May 2022 at 21:26, Neal Gompa wrote: > On Mon, May 30, 2022 at 11:20 PM Miroslav Suchý wrote: > > > > Dne 23. 05. 22 v 20:57 Kevin Fenzi napsal(a): > > > However, now a days we have a number of new apps that are deployed in > > > openshift and

Re: on rpms

o want others to be able to deploy it. Do you have some pointers? I'll easily admit we may have gone the easier route by assuming what our infra looks like in a few places, so I'm happy to fix that. > I've been able to evaluate those issues by packaging them as RPMs, > because RPM packa

Re: on rpms

ds need to allow someone to determine which > > software was installed, when it was installed, and what it was meant to be > > done (example: rpms or podman build scripts for containers). The goal is to > > be kind to our future selves at 2 am who need to figure out why a critical &

Re: on rpms

On Mon, May 30, 2022 at 11:20 PM Miroslav Suchý wrote: > > Dne 23. 05. 22 v 20:57 Kevin Fenzi napsal(a): > > However, now a days we have a number of new apps that are deployed in > > openshift and aren't using rpms, but pip or s2i or other things. > > Regarding pip applic

Re: on rpms

Dne 23. 05. 22 v 20:57 Kevin Fenzi napsal(a): However, now a days we have a number of new apps that are deployed in openshift and aren't using rpms, but pip or s2i or other things. Regarding pip applications - we have pyp2rpm and pyp2spec which can convert to rpm easily. And we have  https

Re: on rpms

ed on or havent yet and you have to reconcile that with them. > However in this case I think it's pretty different: we control both the > pinning and the packaging (well, image building). well, sure, but it makes it hard for someone else to package it if they want to. :) > In

Re: on rpms

use. > That's fair, it's a distro packager's hell. > However in this case I think it's pretty different: we control both the > pinning and the packaging (well, image building). > > In a way, using RPMs does not guarantee reproducibility either: if my app > depends on libA-X.Y and

Re: on rpms

pretty different: we control both the pinning and the packaging (well, image building). In a way, using RPMs does not guarantee reproducibility either: if my app depends on libA-X.Y and it works when I build it, but then libA's maintainer decides to update to X.Z and it breaks my app when I rebuild the

Re: on rpms

ds need to allow someone to determine which > > software was installed, when it was installed, and what it was meant to be > > done (example: rpms or podman build scripts for containers). The goal is to > > be kind to our future selves at 2 am who need to figure out why a critical >

Re: on rpms

o be > done (example: rpms or podman build scripts for containers). The goal is to > be kind to our future selves at 2 am who need to figure out why a critical > application is broken and how to rebuild and redeploy as needed. I like this approach. I don't think there's re

Re: on rpms

pm is optional. >> >> > How about: > > Applications in Fedora Infrastructure need to be deployed in an auditable > and repeatable way. These methods need to allow someone to determine which > software was installed, when it was installed, and what it was meant to be

Re: on rpms

On Mon, 23 May 2022 at 16:52, Kevin Fenzi wrote: > So, in the past we have always had a policy to package as rpms and get > into fedora/epel applications we deploy and are upstream for. > > There were a number of good reasons for this: > * We deployed everything on vm's using

on rpms

So, in the past we have always had a policy to package as rpms and get into fedora/epel applications we deploy and are upstream for. There were a number of good reasons for this: * We deployed everything on vm's using rpm. * Other users that wanted to reproduce our infrastructure could use

Re: 503 bug in rpms "Packages"

On Sun, Oct 17, 2021 at 10:57 PM Reon Beon wrote: > https://src.fedoraproject.org/rpms/numpy > Click packages and it gets this: 503 Service Unavailable > I've submitted a fix to Pagure to change the link on that button, and the code changes for redirecting https://apps.fedorapr

Re: 503 bug in rpms "Packages"

Hi Reon, could you file a ticket on pagure.io/fedora-infrastructure? As far as I remember the packages are being in process of replacing for some time. Michal On 18. 10. 21 5:56, Reon Beon wrote: https://src.fedoraproject.org/rpms/numpy Click packages and it gets this: 503 Service

503 bug in rpms "Packages"

https://src.fedoraproject.org/rpms/numpy Click packages and it gets this: 503 Service Unavailable "Service Unavailable The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later. Apache Server at apps.fedoraproject.org

Re: FBR: Enable delta RPMs in Pungi+Bodhi

On 11/01/2017 06:05 PM, Dusty Mabe wrote: > > > On 11/01/2017 11:53 AM, Patrick Uiterwijk wrote: >> Seems that this is disabled by default. >> Any +1s? >> >> >> diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 >> b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 >> index

Re: FBR: Enable delta RPMs in Pungi+Bodhi

On 11/01/2017 11:53 AM, Patrick Uiterwijk wrote: > Seems that this is disabled by default. > Any +1s? > > > diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 > b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 > index 140f3438e..1c6dc02f2 100644 > ---

Re: FBR: Enable delta RPMs in Pungi+Bodhi

+1 On 1 November 2017 at 12:26, Kevin Fenzi wrote: > On 11/01/2017 08:53 AM, Patrick Uiterwijk wrote: >> Seems that this is disabled by default. >> Any +1s? > > +1 > > kevin > > > ___ > infrastructure mailing list --

Re: F26 delta RPMs

On 11/01/2017 01:18 AM, Ron Yorston wrote: > Another big batch of F26 updates without any delta RPMs today: > libreoffice (again), wine, openjdk. Yeah, they were not enabled in the new compose setup we just switched to. As soon as we apply the freeze break on this list, they should appear

Re: FBR: Enable delta RPMs in Pungi+Bodhi

On 11/01/2017 08:53 AM, Patrick Uiterwijk wrote: > Seems that this is disabled by default. > Any +1s? +1 kevin signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To

FBR: Enable delta RPMs in Pungi+Bodhi

Seems that this is disabled by default. Any +1s? diff --git a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 b/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 index 140f3438e..1c6dc02f2 100644 --- a/roles/bodhi2/backend/templates/pungi.rpm.conf.j2 +++

Re: F26 delta RPMs

Another big batch of F26 updates without any delta RPMs today: libreoffice (again), wine, openjdk. Ron ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

F26 delta RPMs

Are delta RPMs for F26 broken again? I've just run an update involving glibc, the kernel and libreoffice and not one of the RPMs had a delta. Ron ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email

Re: Delta RPMs for F26

On 08/25/2017 06:25 AM, Ron Yorston wrote: > Over on the users mailing list we've been wondering why delta RPMs > don't seem to be available for F26. > > Any ideas, infrastructure people? Dennis Gilmore fixed this last week, so it should be working now. signature.asc Descript

Delta RPMs for F26

Hello, Over on the users mailing list we've been wondering why delta RPMs don't seem to be available for F26. Any ideas, infrastructure people? Ron ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email

Re: [patch] Allow all signers to read the key to upload signed rpms

Kevin Fenzi said the following on 08/05/2010 04:44 PM Pacific Time: On Thu, 5 Aug 2010 12:37:00 -0500 Dennis Gilmoreden...@ausil.us wrote: diff --git a/manifests/services/pkgsigner.pp b/manifests/services/pkgsigner.pp index 11af55c..4449934 100644 --- a/manifests/services/pkgsigner.pp

Re: [patch] Allow all signers to read the key to upload signed rpms

On Tue, 10 Aug 2010 15:37:29 -0700 John Poelstra poels...@redhat.com wrote: It seems to me that this is a very important group. Do we have an SOP that describes how this group is handled? Not that I know of... perhaps there should be one. Things like: a) What kind of controls do we have

[patch] Allow all signers to read the key to upload signed rpms

diff --git a/manifests/services/pkgsigner.pp b/manifests/services/pkgsigner.pp index 11af55c..4449934 100644 --- a/manifests/services/pkgsigner.pp +++ b/manifests/services/pkgsigner.pp @@ -17,7 +17,7 @@ class pkgsigner { folder { /etc/pki/pkgsigner/: owner = 'root', -group

Re: [patch] Allow all signers to read the key to upload signed rpms

+1 (assuming your kmail mangled he patch a bit ;-P) -Mike On Thu, 5 Aug 2010, Dennis Gilmore wrote: diff --git a/manifests/services/pkgsigner.pp b/manifests/services/pkgsigner.pp index 11af55c..4449934 100644 --- a/manifests/services/pkgsigner.pp +++

Re: [patch] Allow all signers to read the key to upload signed rpms

On Thu, 5 Aug 2010 12:37:00 -0500 Dennis Gilmore den...@ausil.us wrote: diff --git a/manifests/services/pkgsigner.pp b/manifests/services/pkgsigner.pp index 11af55c..4449934 100644 --- a/manifests/services/pkgsigner.pp +++ b/manifests/services/pkgsigner.pp @@ -17,7 +17,7 @@ class