Re: [foreman-dev] Koji repo sync metadata problem

Sorry we had public holiday here. We use mirrorselect with mrepo, sometimes it can pick slower mirror. Would be safer to pick particular mirrors if we plan to sync regularly, ideally something within AWS datacenters if there's any. LZ On Fri, Nov 17, 2017 at 4:53 PM, Eric D Helms

Re: [foreman-dev] Koji repo sync metadata problem

The update seems to have completed, with the new CentOS repository added to Koji and repositories regenerated. For the moment, the foreman-nightly*-rhel7-build tags have been updated to remove rhel as an external repository and have been replaced with CentOS (7.4). If you notice any oddities

Re: [foreman-dev] Koji repo sync metadata problem

I started an mrepo run after adding CentOS in a screen session. The run appears to be running a lot longer than previous and it's not clear to me what exactly it's doing at present or whats safe to do. Lukas could you check on it in your morning and see if you spot anything odd about why it seems

Re: [foreman-dev] Koji repo sync metadata problem

Those sound like good arguments, but if we don't test on older releases then we don't know for sure they work either. IMHO it's acceptable to explicitly only support EL 7.4 and up. We don't have the resources to support older versions especially since CentOS doesn't support that either. If

Re: [foreman-dev] Koji repo sync metadata problem

I would be against syncing regularly but I don't do much packaging so it's up to you. The problem I see is "random" breakage. You come to work on Monday after sync and if you don't realize the package was deleted from EPEL, you can burn hour or something to figure it out sometimes. This was pretty

Re: [foreman-dev] Koji repo sync metadata problem

I think we should sync & update. CentOS has no concept of supported minor releases and we should be testing with a supported release. On Wed, Nov 15, 2017 at 03:57:40PM -0500, Eric D Helms wrote: This now appears to be working again. One out standing question that affects nodejs- packaging

Re: [foreman-dev] Koji repo sync metadata problem

This now appears to be working again. One out standing question that affects nodejs- packaging builds. As part of the RHEL 7.4 release, http-parser was removed from EPEL. With this latest round of Koji external repositories update we now have a newer EPEL with this package removed. We did not

Re: [foreman-dev] Koji repo sync metadata problem

I had forgotten to run the repo-regen on Koji. That is finishing up now. I will run another test after and report back. On Wed, Nov 15, 2017 at 2:08 PM, Patrick Creech wrote: > On Wed, 2017-11-15 at 14:00 -0500, Patrick Creech wrote: > > On Wed, 2017-11-15 at 19:56 +0100,

Re: [foreman-dev] Koji repo sync metadata problem

I still get errors when building: http://koji.katello.org/koji/taskinfo?taskID=52363 http://koji.katello.org/kojifiles/work/tasks/2363/52363/root.log DEBUG util.py:439: Error downloading packages: DEBUG util.py:439:1:nodejs-6.10.3-1.el7.x86_64: failed to retrieve

Re: [foreman-dev] Koji repo sync metadata problem

Looks like everything is back up and working as expected. For packagers, keep in mind that this updated some of our external repositories to their latest versions if you see any oddities. This also means that Fedora 27 is available as an external repository for Pulp and Katello clients. On Wed,

[foreman-dev] Koji repo sync metadata problem

Hey, when I initiated mrepo -n (dry run) this morning to see how mrepo works on our koji in order to test if we are able to add Fedora 27 for Pulp, I learned that this "dry run" is actually a real run and mrepo initiated full resync of our content without metadata regeneration. This rendered our