search for: repoclosure

On 16/10/19 02:31, Ranbir wrote: > Hello Everyone, > > Has anyone tried to install BackupPC v4 on CentOS 8 from epel? I just did and this happened: > > [root at resurrect ~]# dnf --enablerepo epel install BackupPC > Last metadata expiration check: 0:18:41 ago on Tue 15 Oct 2019 08:03:59 PM EDT. > Error: > Problem: conflicting requests > - nothing provides

Hi, I am trying to built an ISO with nodejs010 packages but when I run the command "repoclosure -a x86_64 -r <local-repository-name>" to check its further dependencies, it is giving unresolved dependencies error. Example: package: nodejs010-node-gyp-3.2.0-2.el7.centos.noarch from Harman (it's a local repo name) unresolved deps: npm(minimatch) < 0:4 npm(minimatch)...

...esting machine" you can try to enable epel-testing and > epel-playground and check if those deps are in those supplementary > repos. Caution because they are testing repos so if you need to use on > production wait releases. > > Hope that helps. It seems EPEL doesn't use a repoclosure test when pushing from testing to stable. Let me just take one simple example : I recently asked a pkg to be built for epel 8 (see https://bugzilla.redhat.com/show_bug.cgi?id=1755787) So that package itself was able to be built, and despite the fact that it was mentioned that it has some Requires:...

Hello Everyone, Has anyone tried to install BackupPC v4 on CentOS 8 from epel? I just did and this happened: [root at resurrect ~]# dnf --enablerepo epel install BackupPC Last metadata expiration check: 0:18:41 ago on Tue 15 Oct 2019 08:03:59 PM EDT. Error: Problem: conflicting requests - nothing provides par2cmdline needed by BackupPC-4.3.1-2.el8.x86_64 - nothing provides

Hello, Let's say your operating policy is "no patch updates without testing first in the test environment". Let's say it takes you 3 weeks to test. Over the course of the 3 weeks, the repo changes (new packages added, old removed). Is there a way to "freeze" a set of packages so that when I run "yum update" on a Prod server it'll get the same package

...ies > from your build host included/linked/required in the resulting rpm. Thanks Jim for responding. I tried with mock configuration, but, not sure, i am still getting the same errors via repoclosre tool:- This directory has got all the RPMs formed by mock. [root at localhost YUM_CISCO_RPMS]# repoclosure -r Cisco-yum-dep-check Reading in repository metadata - please wait.... Checking Dependencies Repos looked at: 1 Cisco-yum-dep-check Num Packages in Repos: 1515 package: nodejs010-nodejs-are-we-there-yet-1.0.4-1.el7.centos.noarch from Cisco-yum-dep-check unresolved deps: nodejs010-npm(rea...

Hi, I have built successfully all the dependent packages of nodejs010 and npm. I have used following command:- *rpmbuild --define 'scl nodejs010' --bb SPEC/name_of_spec.spec* Following is the list of RPMs cloned and built from GIT:- nodejs010-2.1-5.el7.centos.x86_64.rpm nodejs010-http-parser-2.0-6.20121128gitcd01361.el7.centos.x86_64.rpm

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...