[EPEL-devel] Re: pypolicyd-spf-2.9.3 crashes Postfix
Once upon a time, Todd Zullinger said: > Sylvain Jones via epel-devel wrote: > > It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x > > crashes Postfix unexpectedly. Perhaps a missing dependency? > > It looks like pypolicyd-spf-2.9.3-2 should be in > epel-testing now. That update will install python3-authres, > so you may way to clean up the pip-installed copy you > mention below. Except... for EPEL 9, there is no python3-authres. There is a request for it to be added though: https://bugzilla.redhat.com/show_bug.cgi?id=2142503 -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Request for pure-ftpd package
Once upon a time, Jonathan Wright said: > On Thu, Jul 21, 2022 at 9:37 AM Chris Adams wrote: > > Once upon a time, Jonathan Wright said: > > > I've replied and offered to co-maintain the package. If the current > > > maintainer doesn't reply in 2 weeks I'll petition releng to add me as a > > > co-maintainer per the packaging process guidelines for stalled EPEL > > > requests. > > > > If you do pick it up... looking at old pure-ftpd bugs, please see my > > comment in: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=502754 > > > > > Already working on some builds and reviewing that as well :) Looks like > the packages needs some TLC in general. Cool, thanks! I considered offering to co-maintain but I'm not sure I have the cycles to give it the TLC it should have. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Request for pure-ftpd package
Once upon a time, Jonathan Wright said: > I've replied and offered to co-maintain the package. If the current > maintainer doesn't reply in 2 weeks I'll petition releng to add me as a > co-maintainer per the packaging process guidelines for stalled EPEL > requests. If you do pick it up... looking at old pure-ftpd bugs, please see my comment in: https://bugzilla.redhat.com/show_bug.cgi?id=502754 -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Once upon a time, Josh Boyer said: > If the dependency is only needed at build time, which is what CRB > content is intended for If that's the intent, then it's not implemented correctly. For example, there are well over 100 perl modules in CRB 9. They may only be used _by Red Hat_ in building, but they are not exclusively build-time packages by a long shot. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Once upon a time, Andrew C Aitchison said: > On Wed, 8 Jun 2022, Maxwell G via epel-devel wrote: > >On Wednesday, June 8, 2022 2:54:51 PM CDT Michel Alexandre Salim wrote: > >>without messing with config files (which I > >>hate, because that means newer crb.repo changes won't be picked up). > > > >I thought files marked `%config(noreplace)` don't get updated automatically > >even > >if the user didn't modify it all. Am I missing something or are we talking > >about different things? > > My understanding is that those files *do* get updated if they have > not been modified. That's correct - unmodified files will still be updated by RPM. > This new idea will let you make a change to the config without > blocking updates from making non-conflicting changes. This would even be good to use for enabling/disabling repos, again so that a URL change or such would still be applied. Long term, it might be ideal to treat the RPM-distributed repo files as read-only and move them to something like /usr/share/yum.repos.d, with only local changes (enable/disable, exclude, alternate mirror/baseurl) in /etc/yum.repos.d. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
Once upon a time, Michel Alexandre Salim said: > This won't be ready until EPEL 10 or even 11, but one thing I've > discussed with the DNF maintainer is the possibility of having > something like /etc/yum.repos.d/reponame.repo.d/ where you can drop > overrides, similar to how you can drop overrides for systemd unit > files. I've wanted (and suggested) something like this for ages, for a different reason: ability to drop-in local mirror configs, again without modifying the RPM-packaged config. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: SPDX identifiers in old branches?
Once upon a time, Gary Buhrmaster said: > The follow up suggested that the license > field be differently formatted. > > I disagree with such explanatory > prefixes, as it requires yet more apps > to parse/support various prefixes. No, my suggestion of using "License: SPDX:" would not require any additional changes. Anything that cares about the License field will already need changes to recongize the SPDX values; this would just remove any ambiguity. And as very little parses the License field, so there's not some big effort to update required in any case. I just made this suggestion as a way to avoid anything unclear in the License field, but it would also allow any future alternate license strings to be clearly used. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: SPDX identifiers in old branches?
Once upon a time, Gary Buhrmaster said: > On Tue, May 24, 2022 at 11:29 PM Chris Adams wrote: > > Would it make sense to make ALL the new tags be SPDX:, at least for > > an interim period (of years most likely) where both old and new tags are > > allowed? > > I don't think that is going to work unless the rpm spec > file support would be backported to previous releases > (without another macro that tries to do some magic). > And the goal for some of us is to have one spec file > work across all currently supported releases. I'm not talking about a new tag or format, just literally making the License: tag be "SPDX:". -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: SPDX identifiers in old branches?
Once upon a time, Maxwell G via devel said: > I already brought this up previously, but how will we handle license > identifiers such as MIT that are valid in both SPDX and Fedora but have > different meanings? We won't know whether it's specifically referring to the > MIT/Expat License (SPDX) or a group of MIT-like licenses (Fedora) and we > won't > be able to tell which specfiles have been converted to use SPDX identifiers > and > which haven't. Would it make sense to make ALL the new tags be SPDX:, at least for an interim period (of years most likely) where both old and new tags are allowed? -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Certbot RPM
Once upon a time, Filip Bartmann said: > Hello, > how can I request cerbot rpm for epel 9? This is a work in progress, because of all the dependencies of certbot. See https://bugzilla.redhat.com/show_bug.cgi?id=2041142 -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] libaom update issue
Hi, I'm getting a yum update failure with seamonkey 2.53.7-4 which requires libaom (src rpm=aom), which doesn't have a clean update path: # yum update seamonkey libaom Loaded plugins: aliases, changelog, kabi, langpacks, post-transaction-actions, priorities, protectbase, ps, remove-with-leaves, : tmprepo, verify, versionlock Loading support for Red Hat kernel ABI 0 packages excluded due to repository protections Resolving Dependencies --> Running transaction check ---> Package libaom.x86_64 0:1.0.0-8.20190810git9666276.el7 will be updated --> Processing Dependency: libaom.so.0()(64bit) for package: seamonkey-2.53.7-4.el7.x86_64 ---> Package libaom.x86_64 0:3.1.1-1.el7 will be an update --> Finished Dependency Resolution Error: Package: seamonkey-2.53.7-4.el7.x86_64 (@epel) Requires: libaom.so.0()(64bit) Removing: libaom-1.0.0-8.20190810git9666276.el7.x86_64 (@epel) libaom.so.0()(64bit) Updated By: libaom-3.1.1-1.el7.x86_64 (epel) ~libaom.so.3()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Any thoughts why this happened? It's unclear to me exactly what the issue is (note the .so bump from .0 to .3). No doubt I could likely remove both and install again, but just thought I'd inquire before changing anything. I only have a few systems this issue, so not a big deal. Thanks! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: clusterssh for EPEL 8
Certainly! Done. Thanks for the polite pointer. On 7/17/20 9:01 AM, Patrick Riehecky wrote: > Can you open a bugzilla requesting this be added to EPEL8? > > Pat > > On Thu, 2020-07-16 at 22:01 -0400, Chris Schanzle wrote: >> Hi, >> >> Clusterssh is a nice tool to send input to multiple ssh sessions >> simultaneously -- handy for managing a cluster of systems. I don't >> know if there is much other interest for clusterssh, but I wanted to >> share my experience on building it and it seems like it would be >> fairly low effort to add these to EPEL 8. >> >> Using mock, I was able to rebuild to my local repo: >> >> clusterssh-4.14-2.fc32.src.rpm >> >> after building two dependencies: >> >> perl-X11-Protocol-0.56-33.fc32.src.rpm >> perl-X11-Protocol-Other-31-3.fc32.src.rpm >> >> No changes to src.rpm's were needed to build the packages. >> >> Thanks for your amazing work! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] clusterssh for EPEL 8
Hi, Clusterssh is a nice tool to send input to multiple ssh sessions simultaneously -- handy for managing a cluster of systems. I don't know if there is much other interest for clusterssh, but I wanted to share my experience on building it and it seems like it would be fairly low effort to add these to EPEL 8. Using mock, I was able to rebuild to my local repo: clusterssh-4.14-2.fc32.src.rpm after building two dependencies: perl-X11-Protocol-0.56-33.fc32.src.rpm perl-X11-Protocol-Other-31-3.fc32.src.rpm No changes to src.rpm's were needed to build the packages. Thanks for your amazing work! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
Once upon a time, Stephen John Smoogen said: > From my also little understanding of modularity, this is so you can > reinstall base perl packages. In some ways ( I am glossing over things > here), modular rpms always beat bare rpms because a module can put in rules > to say 'you can install this package but it does not work with these rpms > so they need to be removed'. So I think any modules we write which would > over-ride non-modular packages, we would also need to write a 'get me back > my f'ing defaults' module which stubs in a similar way the perl and some > other modules do. Thanks for the explanation - I agree with you, that if RHEL doesn't already have a base module (like the perl example you listed), then any EPEL module that overrides a base RHEL package needs to also proved the module to get back to RHEL. I get the desire/need for modularity... it just seems so complicated. As a really small-time packager, modularity has been over my head (but the few packages I have don't need it, so I also haven't tried super hard). -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
Once upon a time, Kevin Fenzi said: > Does this mean if there's a package foo that is a rhel package, but not > in a module, that it can be overlapped with a foo package thats in a > epel non default module? ie, does it only mean the modular case or does > it mean any rpm? As a consumer of EPEL, I'd rather nothing in the base RHEL (or really CentOS in my case) ever get replaced, up or downgrade, by something in EPEL. Unless... does RHEL have modules that replace base packages? I admit, I haven't fully got my head wrapped around all the effects of modularity. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Nasty Fail2Ban update for Centos 7
Once upon a time, Allan said: > Just noticed that Fail2Ban have generated a 6MB error log because > of the update, and FirewallD a 1MB log of errors ! > (not sure if any of those were really working after this) It might be helpful to actually post some of the errors and your local config (what you have changed from defaults). Without that, nobody can help figure out what is happening on your system. I'm the person that asked for the update - the previous firewalld config was incomplete (set banaction but not banaction_allports), and I wanted to see IPv6 support. I'm using the update on multiple CentOS 7 systems (some with firewalld and some with iptables) without errors. -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules
Once upon a time, Stephen John Smoogen said: > Honestly I don't understand the solution (and probably the problem) > enough to answer. My understanding of modules is about the same as a > layman's knowledge of quantum mechanics. I know it exists, I know it > does a lot of things, and I know it is full of conundrums which make > no sense to what I normally want to do. THIS! I've been hearing about modules for a while in Fedora, and now in RHEL 8, but I don't really have the faintest idea what they are, how I'll have to deal with them (both as an admin and as a packager), etc. Once CentOS 8 is out and I have some time, I'll work on getting my one useful EPEL package built for it, but hopefully that won't involve modules. I only have a couple of packages between Fedora and EPEL, and they so rarely need updates that every time I do anything, I have to go fumble through the steps required (trying to follow online documentation, which I usually screw up, like I think I checked my source tarball into git like a moron). -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
Once upon a time, Stephen John Smoogen said: > RHEL-8 was built with various packages which are not shipped in > BaseOS/AppStream/CRB. Some like screen are in the buildroot for the > packages which depend on them but were decided not to be shipped. Huh, that's... weird. As someone that's been using screen for, hmm, longer than Red Hat's been in business I think... that's annoying. I guess the CentOS side would be the more appropriate place to ask, but would it be practical to gather up these packages and make a CentOS "module" of them? Sorry if that doesn't make sense (like I said, still trying to get my head around modularity). -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Project plans for EL-8 (2019-05-15 good til 2019-05-22)
So, I don't have a handle on the whole modularity thing... still trying to understand what's what with that. But this caught my eye in your "Open Questions": - Some normally leaf packages like screen are inside of the Red Hat hidden buildroot package set. Having them built in EPEL is likely to cause conflicts on user systems and divergence with RHEL. EPEL maintains agreed upon policies for these cases so using the repo doesn’t cause pain for RHEL customers or users. What does that actually mean? I'm a consumer of CentOS rather than RHEL these days, so I haven't really dug into version 8 yet. I do use screen a lot, so what does "inside of the Red Hat hidden buildroot package set" mean for me? -- Chris Adams ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Koji Build Failure Due To Dependency EPEL Dependency Issue
Thanks a lot Kevin! I can confirm it built perfectly! (ref https://koji.fedoraproject.org/koji/taskinfo?taskID=33328352) I truly appreciate your help! Chris On Sat, Mar 9, 2019 at 1:16 AM Kevin Fenzi wrote: > On 3/8/19 6:01 PM, Chris wrote: > > Hi guys, > > > > I apologize if this is a bit premature to revisit this subject. The > thing > > is, the releng ticket Stephen created ( > https://pagure.io/releng/issue/8185) > > based on my Bugzilla ticket ( > > https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and > marked > > resolved, but the build process still continues to fail. > > > > Recent Koji Build Fail Source: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=33310604 > > > > I sat on this for a week thinking maybe it just took time for this change > > to propagate, but now that this was week #2 and it was still failing... i > > should bother you all again :). > > > > Is this a RedHat issue? Perhaps just waiting for the Bugzilla issue to > > close will actually rectify my issue? i realize this can take months; > but > > it's a perfectly acceptable answer. I guess i'm just looking for closure > > at this point. I'd love to share my app with the rest of the fedora > > community. > > > > Thanks in advance! > > Sorry this has been a pain. ;( > > Anyhow, it did get blocked but there was still a version of the package > tagged into epel7 so that was messing things up. I untagged that one and > (I hope you don't mind) resubmitted your scratch build... and now it > completes. :) > > So, you should be all good now I hope. > > kevin > > > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Koji Build Failure Due To Dependency EPEL Dependency Issue
Hi guys, I apologize if this is a bit premature to revisit this subject. The thing is, the releng ticket Stephen created (https://pagure.io/releng/issue/8185) based on my Bugzilla ticket ( https://bugzilla.redhat.com/show_bug.cgi?id=1684830) got closed and marked resolved, but the build process still continues to fail. Recent Koji Build Fail Source: https://koji.fedoraproject.org/koji/taskinfo?taskID=33310604 I sat on this for a week thinking maybe it just took time for this change to propagate, but now that this was week #2 and it was still failing... i should bother you all again :). Is this a RedHat issue? Perhaps just waiting for the Bugzilla issue to close will actually rectify my issue? i realize this can take months; but it's a perfectly acceptable answer. I guess i'm just looking for closure at this point. I'd love to share my app with the rest of the fedora community. Thanks in advance! Chris On Sat, Mar 2, 2019 at 4:46 PM Stephen John Smoogen wrote: > I have created https://pagure.io/releng/issue/8185 for the releng > ticket and referenced the bugzilla. > > On Sat, 2 Mar 2019 at 16:23, Chris wrote: > > > > > Can you file a releng ticket to retire the epel7 one? > > > Thats what needs to happen here. > > > > Thank you (and everyone else) very much for your fast responses and > help! I created https://bugzilla.redhat.com/show_bug.cgi?id=1684830 > which hopefully covers what was requested of me. :) > > > > Chris > > > > > > On Sat, Mar 2, 2019 at 3:00 PM Kevin Fenzi wrote: > >> > >> On 3/2/19 10:22 AM, Chris wrote: > >> > Hi everyone, > >> > > >> > I just wanted to see if anyone had any idea why the EPEL7 repository > would > >> > not identify python2-oauthlib package correctly? It almost appears as > >> > though the EPEL repository is broken (has been for at least a week - > maybe > >> > longer) 'with respect to the this package specifically'. > >> > > >> > Here is a failed koji build: > >> > https://koji.fedoraproject.org/koji/taskinfo?taskID=33139296 > >> > > >> > If i build using COPR (link: > >> > https://copr.fedorainfracloud.org/coprs/build/861900/) everything > works > >> > fantastic; so it's very specific to how the EPEL7 repositories are > sourced > >> > via Koji. > >> > > >> > The Koji error i get is: > >> > > >> > DEBUG util.py:490: BUILDSTDERR: No matching package to install: > >> > 'python2-oauthlib' > >> > DEBUG util.py:490: BUILDSTDERR: Not all dependencies satisfied > >> > DEBUG util.py:490: BUILDSTDERR: Error: Some packages could not be > found. > >> > > >> > > >> > Fedora and RedHat based repositories seem unaffected and correctly > identify > >> > python2-oauthlib and python3-oauthlib in their respected repositories. > >> > > >> > Any thoughts or advice? > >> > >> This is because python-oauthlib is in both epel7 and rhel7 base repo. > >> > >> Koji operates on source packages, so when both epel7 and rhel7 have the > >> same package name, epel7 wins. The epel7 python-oauthlib package does > >> not provide a python2-oauthlib subpackage (it only has python-ouathlib). > >> Because it's using the epel7 one, it ignores everything the rhel7 one > >> creates, so you don't get the python2-oauthlib from there either. > >> > >> In Copr the newest package wins, so you get the rhel7 one because it's > >> much newer than the old epel7 one. > >> > >> Can you file a releng ticket to retire the epel7 one? > >> Thats what needs to happen here. > >> > >> kevin > >> > >> ___ > >> devel mailing list -- de...@lists.fedoraproject.org > >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org > > > > ___ > > devel mailing list -- de...@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/de...@list
