[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] 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
Re: EPEL Notes from .next discussion.
Once upon a time, Stephen John Smoogen said: > On 13 August 2014 06:28, Dennis Gilmore wrote: > > I disagree. FHS says that anything not part of the OS should go > > in /opt/ EPEL is an add on and not part of the OS. > > > In the past we did not do this because we were bound by the Fedora > Packaging Rules. I don't have the energy or want to try and fight that > Windmill but I am not going to stand in someone who wants to. "part of the OS" is somewhat vague. My personal feeling (for the zero it is worth) is that anything that is installed from yum repos (especially non-conflicting repos) can be considered "part of the OS". I usually consider /opt and /usr/local for stuff installed outside of the OS-provided package management tools (even if said tools are managing third-party repos). The problem I'd see with moving stuff to /opt in EPEL is that it doesn't get tested like that in Fedora, and causes definate diversion from Fedora's "norms", so it puts more burden on packages. Also, it makes it somewhat more difficult to move something from a Fedora install to a RHEL/CentOS+EPEL install (because paths would be different). -- Chris Adams ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Fwd: Re: how to withdraw glusterfs from epel?
Once upon a time, Kaleb S. KEITHLEY said: > If you haven't followed along in fedora-devel, here's (what I think > is) a fairly cogent, if terse, summary of what I'd like to do. Does it really make sense to package a README that just points to another repo somwhere else? Are there admins that find EPEL but can't find other repos? I definately see retiring the obsolete packages, but what is gained for EPEL to package READMEs telling people that bother to read them to install another repo. -- Chris Adams ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
