[EPEL-devel] Re: Orphaned Packages in epel7 (2016-11-01)
On Tue, Nov 1, 2016 at 3:00 PM wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Taking python-keyring[epel7], because I use it and want it maintained. I have no experience with the package, though, so if another wants it, I'll gladly hand it over as soon as they step up. Also, after taking a package, how does one check to see if all of its dependencies are in a good state? (non-orphaned) Aside from these emails for passive notification, is there a way to get a smaller, personalized report, like on pkgdb, about a specific package's dependencies? Or a particular user's packages' dependencies? ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Orphaned Packages in epel7 (2016-11-01)
On Wed, Nov 2, 2016 at 3:23 PM Jason L Tibbitts III wrote: > >>>>> "C" == Christopher writes: > > C> Also, after taking a package, how does one check to see if all of its > C> dependencies are in a good state? (non-orphaned) > > Get the list of dependencies (with repoquery or "dnf repoquery" or > inspection of the spec. Then look them up in pkgdb. You can do those > lookups from the command line if you like using pkdgb-cli: > > pkgdb-cli acl python-keyring epel7 > > (the branch names are el5, el6 and epel7 for historical reasons) > > Will show you the four current maintainers of python-keyring in EPEL7. > Or you can make an API call and handle the returned json as you wish, if > you want to write something. > > C> Aside from these emails for passive notification, is there a way to > C> get a smaller, personalized report, like on pkgdb, about a specific > C> package's dependencies? > > pkgdb doesn't track dependencies, so all you can do is ask it about the > status of a particular package. You'll need to get the dependencies > from the package manager. > > That's unfortunate. These emails are a bit spammy, are not easily parsed, and are hard to track. Not only is it hard to tell the difference between notices sent directly to me, or sent to me via the mailing list, it also seems impossible to get an immediate report of a newly acquired package. It seems like it'd be useful for pkgdb (or some other system) to show the active/orphan/retire status of a package and all its dependencies, on demand, rather than wait for the next round of emails like this to see that one of your critical dependencies just got retired. Basically, I think we need a web UI for whatever system is currently generating these emails. > C> Or a particular user's packages' dependencies? > > That's just extracting from pkgdb the list of packages to which a user > has commit access (assuming commit access is what you want) and then > looking at that package in a loop. > > - J< > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Fedora EPEL 7 updates-testing report
ibrary for EPEL7 > > -------- > > > > > tripwire-2.4.3.2-1.el7 (FEDORA-EPEL-2017-c451d02b31) > IDS (Intrusion Detection System) > > > Update Information: > > update to 2.4.3.2 > > > References: > > [ 1 ] Bug #830999 - tripwire cron should send mail to configured > recipients > https://bugzilla.redhat.com/show_bug.cgi?id=830999 > > > > > > > xrootd-4.6.0-1.el7 (FEDORA-EPEL-2017-9b2cd39ee3) > Extended ROOT file server > > > Update Information: > > New version 4.6.0, release notes are here: > https://github.com/xrootd/xrootd/blob/v4.6.0/docs/ReleaseNotes.txt > > > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > -- Christopher ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: How to retire/delete an EPEL branch?
On Wed, Jan 10, 2018 at 1:53 AM Ding Yi Chen wrote: > I received a bug[1] asking to remove EPEL7 branch, as the package > LibRaw, is already in RHEL. > > How should I do that? > > Would (warning: this will lose history) `git push --delete origin epel7` work? It'd be a shame to lose history if it's not already reflected in another branch, though. Maybe do `git checkout master && git merge -s ours epel7 && git push origin master` first to preserve the history in the master branch without changing the code in that branch? > Regards, > > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=1526701 > -- > Ding-Yi CHEN > > Software Engineer, Globalization Group > Red Hat Asia-Pacific Pty Ltd > dc...@redhat.com > Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: Fedora EPEL 7 updates-testing report
On Fri, Apr 6, 2018 at 12:14 PM wrote: > The following Fedora EPEL 7 Security updates need testing: > Age URL > 1124 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 > dokuwiki-0-0.24.20140929c.el7 > 886 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f > mcollective-2.8.4-1.el7 > 469 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d > libbsd-0.8.3-1.el7 > 366 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe > mod_cluster-1.3.3-10.el7 > 198 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23 > libmspack-0.6-0.1.alpha.el7 > 135 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece > nagios-4.3.4-5.el7 > Some of these are several years old. Do we really need to get regular updates about these? Clearly, neither the users nor the maintainers care about these updates. Should there be a time limit in bodhi before it just gets deleted? Or... can somebody with elevated privileges just push the packages to stable to clear them out? Maybe if they introduce a bug, somebody will at least pay attention to them. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Re: EPEL Port oat package into
RHN is RHN, but not EPEL. http://pkgs.org/search/?keyword=sun-codemodel ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Port oat package into
Well I think RHN is not open for EPEL. So no answer. ;) Unless you package it into Fedora EPEL. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL need help in installing dom4j on rhel 6.4
Hi Upendra, dom4j is a package in jpackage project. Sent from S3 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL installing erlang on RHEL6
Repoforge is nearly dead now, as far as I can see. So please don't use too many repos, especially the ones are not an extension of EPEL. Repoforge is not compatible with EPEL. Please use yum option --disablerepo=repo* when install pkgs and try again to see if it works. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL installing erlang on RHEL6
Mhn.. Seems the command is incorrect...still pull in repoforge pkgs. Do you have anything important installed from repoforge? If not you can disable repo by editing /etc/yum.repos.d/ (I'm sorry I don't know its name now since we've used EPEL for years, but I think it's easy to find rf's repo file by name), in the repo file set enable=0. And try again... ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL sipcalc on 6
Ah, I think you can file a bug at bugzilla to notify him about this. http://bugzilla.redhat.com/enter_bug.cgi?product=Fedora%20EPEL ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Planning for LTSP -6
Any results here? I just received CVE alert of nbd, so Fedora nbd package will be updated now, what about the nbd in EPEL? We still lack nbd.ko on RHEL machine... PS. felicitate myself on searching my inbox before tried to update it ;) ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL dropbear update
Hi all, dropbear in EPEL6 will be updated to 2013.62 later in updates-testing with support of ECC. Full changelog is there: https://matt.ucc.asn.au/dropbear/CHANGES If you have any questions or objections, please reply here. Thanks. -- Yours sincerely, Christopher Meng Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт. http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL lynis is now in testing
Hi, I've created this package since 1.3.6 in EPEL branch so sysadmins you can use this awesome tools to check your system's security via `sudo yum install lynis`. Note please don't rely on this software blindly. Thanks. -- Yours sincerely, Christopher Meng Fєdоґa ї₴ al$о a кїпd оf нaт lїкє Яёd Haт. http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL epel7 planning and processes
branch from EPEL6? How to deal with systemd related things? Is it possible to branch from branches determined by packagers? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL epel7 planning and processes
On Wed, Dec 18, 2013 at 6:58 AM, Morten Stevens wrote: > My preference is also "el7", because we have also a "Packager" and "Vendor" > tag to declare these packages as Fedora EPEL (and not rhel) packages. Why should these 2 tags be used still? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Should I request epel7 branch in packaging?
Hi, I wonder if I need to add epel7 to the branch list or the system will do for me? I want to package for epel7 also. Thanks. -- Yours sincerely, Christopher Meng Noob here. http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Should I request epel7 branch in packaging?
On Jan 3, 2014 1:02 AM, "Kevin Fenzi" > When we are ready for branches we will announce and that will include > the process and what you need to do. Thanks, but what I've seen is that someone is requesting SCM on epel7. I was just curious about that. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Requesting i3* packages for RHEL7
I'm the i3* maintainer now. I will do this of course, but before RHEL7 pushed to final release, please don't rush. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
I would suggest you using pip to install these packages. First these packages in repo are old and may not match your need. https://bugzilla.redhat.com/show_bug.cgi?id=852998 Second these packages are used for Fedora infrastructure apps, and since the technology is moving forwardly, these packages may be retired. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Dependency broken for TurboGears-1.1.3-8.el7.noarch
On Fri, Mar 14, 2014 at 11:40 AM, Zhiwei Zhu wrote: > > Hi Christopher, > > > > Thanks for your quick response. I understand the situation and > Turbogears-1.1.3 may be old. > > > > I also tried Turbogears2 (which is TurboGears2-2.3.0) and got these errors: > > Error: Package: python-transaction-1.4.1-1.el7.noarch (epel) > >Requires: python-zope-interface > > Error: Package: python-zope-sqlalchemy-0.7.2-1.el7.noarch (epel) > >Requires: python-zope-interface > > Error: Package: python-kajiki-0.3.5-1.el7.noarch (epel) > >Requires: babel > > Error: Package: python-genshi-0.7-3.el7.x86_64 (epel) > >Requires: python-babel >= 0.8 > > Error: Package: python-repoze-who-2.1-1.el7.noarch (epel) > >Requires: python-zope-interface > > Error: Package: TurboGears2-2.3.0-0.2.git6da6959.el7.noarch (epel) > >Requires: python-jinja2 > > You could try using --skip-broken to work around the problem > > You could try running: rpm -Va --nofiles --nodigest > > > > Do you have any suggestion for this one? > > Thanks. For all packages which can be found from pypi, I'd recommend using pip to install them. I don't know the plan, maybe the missing packages will never get into EPEL7. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Concerning request for libupnp addition
I've taken the acl. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Amazon Linux and
Hi, I've seen the thread of LLVM on Amazon, recently I received a report that my package lnav doesn't work properly on Amazon Linux: lnav: undefined symbol: _ZN7pcrecpp2RE4InitEPKcPKNS_10RE_OptionsE From the symbol I can see there should be a problem in pcre package. Therefore here comes a question, what's the difference between RHEL(CentOS) and Amazon? Thanks. Yours sincerely, Christopher Meng Noob here. http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Amazon Linux and
Ok, I just found the crux after sending this email. [i@glusterfarm data]$ nm -aD /usr/lib/libpcrecpp.so.0 | grep Init 2ed0 T _ZN7pcrecpp2RE4InitERKSsPKNS_10RE_OptionsE U _ZNSt8ios_base4InitC1Ev U _ZNSt8ios_base4InitD1Ev The package in Amazon Linux is not the same version in RHEL. So recompiling is needed. Hence I'd like to suggest that we need to add some notes on the EPEL wiki page, ideas? Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Amazon Linux and
On Fri, May 9, 2014 at 9:57 AM, Matthew Miller wrote: > Quite a lot; they make no attempt at compatibility. I think I'd respond with > that. EPEL packages might work on Amazon Linux, and they might not. Matthew, thanks for your reply. I took the info from the bug, and found that pcre on amazon linux is 8.x, quite fresh, RHEL only has 7.x version for customers. So I believe it's worthwhile to add some notes on EPEL page to alert the incompatibility. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Maintaining libntlm for ppc64
NO. Feel free to do that. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL xfig is absent in epel-release-7-0.2
You'd better open a bug in the bugzilla under Fedora EPEL against the relevant component if it is available in the EPEL6. If not, open a bug under Fedora and request the epel7 branch. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL getting terminus-fonts added to 7
On Wed, Jul 9, 2014 at 11:21 AM, Matthew Miller wrote: > This requirement seems to be just in the fedora spec file -- it doesn't seem > to be part of the upstream. From the man page, this is set with the '-fn' > flag at runtime. I didn't look at xmonad, but there's nothing inherently in > dmenu which seems to need it. I removed terminus-fonts with --nodeps from a > test system, and it seems to run fine maybe that's an easier solution? Having a new font in the EPEL repo won't hurt anything, but if users lack one choice to do what they want, that would be a pity. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL getting terminus-fonts added to 7
Hi all, I strongly suggest that please also update this package to the latest version 4.39 instead of using 4.38. Thanks. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL getting terminus-fonts added to 7
On Wed, Jul 9, 2014 at 4:02 PM, Jens Petersen wrote: >> I strongly suggest that please also update this package to the latest >> version 4.39 instead of using 4.38. > > What is the advantage of 4.39? It is not in rawhide yet though... Version 4.39: - Added ballot, checkmark, heavy ballot and heavy checkmark. - Changed HT, LF etc. in sizes 14 and 18-hi2 to be proportional to the letter height, not the matrix height. - Added the powerline characters E0A0..E0A2 and E0B0..E0B3. - Added diameter (2300) - same gluph as empty set (2205). - Small improvements in size 32. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL getting terminus-fonts added to 7
On Wed, Jul 9, 2014 at 4:09 PM, Jens Petersen wrote: >> This requirement seems to be just in the fedora spec file -- it doesn't seem >> to be part of the upstream. From the man page, this is set with the '-fn' >> flag at runtime. I didn't look at xmonad, but there's nothing inherently in >> dmenu which seems to need it. I removed terminus-fonts with --nodeps from a >> test system, and it seems to run fine maybe that's an easier solution? > > Right I also put that idea to Christopher. > I am not really sure why dmenu requires terminus-fonts in particular: > though it does need some bitmap font to be installed to work. On Wed, Jul 9, 2014 at 4:12 PM, Jens Petersen wrote: >> Having a new font in the EPEL repo won't hurt anything, but if users >> lack one choice to do what they want, that would be a pity. > > Sure, it is good to have more fonts in EPEL. > > Nevertheless the question remains: does dmenu > really need an explicit requires on terminus-fonts? Quite frankly, it's no needed as a MUST. You could let users to install. When I claimed over this package months ago, it's already there. I could drop this requires, but I need time to verify the conf file and make sure dmenu works still(no major changes in the display). Unfortunately, I don't have time now. If someone can help test and feedback the pros and cons of the drop of the terminus, that's really helpful here... Thanks. Yours sincerely, Christopher Meng Noob here. http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL Orphan or retire the TurboGears (v1) stack in 7
On Thu, Jul 10, 2014 at 9:19 PM, Toshio Kuratomi wrote: > On Thu, Jul 10, 2014 at 05:39:40AM +, Zhiwei Zhu wrote: >> Hi Toshio, >> >> I have just noticed this message after I failed to install TurboGears (v1) >> on CentOS 7. >> >> We really need the TurboGears (v1) support via epel for el7. Migrating away >> from TurboGears V1 to V2 or to other framework seems impossible for us at >> the moment, though we know that we will have to migrate in future. >> >> Could you help to suggest what we could do to revive these packages and have >> epel7 will still support TurboGears( v1 )? >> > Sure! Become a package maintainer and maintain the packages that have > become orphaned in EPEL7. > > Note that you won't need to revive all of the packages -- some of those were > retired because they depend on TurboGears1 (for instance, bodhi). You'll > only need to revive the ones that TurboGears1 depends on (and those that > your applications need). "Best" solution. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL [Package Request] Thunar rpm for EL7 not ready.
On Mon, Jul 14, 2014 at 2:01 PM, Suse Shi wrote: > Hi Guru, > >I was tring to inst xfce on CentOS 7 release. (via epel repo) #yum > install @xfce > >it works without package Thunar, > > I checked following build stats that EL7 rpm is not ready yet, would you > help to add this rpm to repo line. thanks, Have you checked? http://koji.fedoraproject.org/koji/buildinfo?buildID=543666 Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL [Package Request] Thunar rpm for EL7 not ready.
Deps are satisfied already based on the successful build of the thunar. http://koji.fedoraproject.org/koji/buildinfo?buildID=543669 Thanks for the report. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL [Package Request] Thunar rpm for EL7 not ready.
On Mon, Jul 14, 2014 at 2:54 PM, Suse Shi wrote: > desktop-backgrounds I'm not sure. This package has been split up into 4 packages, and I doubt if RHEL really needs them. The package owners will decide what they want. Anyway he will receive the broken deps report if he really makes the broken xfdesktop in the EPEL7, so he will fix it soon. There are some xfce guys in this list, you can await their answers. Thanks. Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 package requests: pyephem, blt, tcllib, tdom
This list is not the right place to discuss these stuffs. If you want to let them land in the EPEL7, please fill bugs in Bugzilla against the relevant component. I'm sure most of the owners of those packages may not subscribe to this list. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 package requests: pyephem, blt, tcllib, tdom
I guess you even don't know how to use Bugzilla. I've closed your requests in the bugzilla. Standard procedure: 1. Check if someone has requested: http://bugz.fedoraproject.org/$(PACKAGE_NAME) Replace that PACKAGE_NAME with the actual name, like blt, tcllib. 2. If not, click the button in the page and report one. If this package has EL branch, file a bug under EL first, if you can't get any responses, file one under Fedora then. 3. Wait. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 broken deps and beta status update
yumex has wrong dep python-pexpect, it's pexpect in RHEL for a long time, although this package in RHEL7 has the same version of the one in RHEL6. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 package requests: pyephem, blt, tcllib, tdom
Actually the epel7 Request page should only be edited by the existing packagers, or someone may get annoyed. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL 7 package requests: pyephem, blt, tcllib, tdom
On Tue, Jul 22, 2014 at 9:20 AM, Zhiwei Zhu wrote: > Hi Christopher, > > I have removed the part added by me. Sorry for the mistake. Well no problem, you are new to here ;) We need to focus on these packages now as they are required by people. Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL importing a slew of packages into 7?
Have you asked the Fedora maintainer of those 21 packages? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL inotify-tools - centos7
https://bugzilla.redhat.com/show_bug.cgi?id=1110354 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL httpd-itk doesn't work with latest version of httpd-2.2.15
https://bugzilla.redhat.com/show_bug.cgi?id=1121148 -- Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL testing-epel7 : availability date
There are packages still notready for EPEL7 at least. -- Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL moving epel 7 out of beta
Good to hear. Thanks! -- Yours sincerely, Christopher Meng http://cicku.me ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL noip and pnp4nagios epel7 availibility
You can report a bug against noip: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=noip IMO noip should switch to systemd. I've written one and if noip Fedora maintainer won't maintain it in EPEL, I could offer a hand. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL noip and pnp4nagios epel7 availibility
On Sat, Aug 30, 2014 at 7:55 PM, LOEFFLER Peter wrote: > > I think it's a good idea to switch to systemd. > Did i get it right that i shoud report a bug that a systemd script is missing > and you will offer it at bugzilla? You can report a bug first, I will arrive there then. The systemd script problem should be fixed on all branches. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] EPEL package rebased upon RHEL update?
Hi, Redis in EPEL6 is pretty dated, I'd like to update it to the latest 2.x version but somehow I haven't done major update like this. Is it allowed to update the package from 2.4 to 2.8 for new RHEL 6.x like 6.8 release? Thanks. -- Yours sincerely, Christopher Meng http://awk.io ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] EPEL package rebased upon RHEL update?
* Versions lower than 2.8 had been dropped from supported lifecycle for a long time. * Backporting fixes to 2.4 doesn't make too much sense. * Config change is needed (https://raw.githubusercontent.com/antirez/redis/2.6/00-RELEASENOTES). -- Yours sincerely, Christopher Meng http://awk.io ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: [EPEL-devel] EPEL package rebased upon RHEL update?
On 10/18/15, Haïkel wrote: > Considering EPEL update policy, there's no argument not to skip 2.8 > and upgrade to 3.0. > 2.8 will be dropped when 3.2 will be released (WiP), and migrating > from 2.4 to 2.8 is not easier than 2.4 to 3.0 Migration from users can't be avoided I think, and I doubt if there are users using 2.4 since it's not supported and (may) full of security holes. -- Yours sincerely, Christopher Meng http://awk.io ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] qt5 dependency problem
Hi, In trying to install trojita, I got the following error: $ sudo yum install trojita Loaded plugins: langpacks Resolving Dependencies --> Running transaction check ---> Package trojita.x86_64 0:0.7-4.el7 will be installed --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libQt5WebKit.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libmimetic.so.0()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libqt5keychain.so.1()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Running transaction check ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Positioning.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Sensors.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be installed --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for package: qtkeychain-qt5-0.7.0-1.el7.x86_64 --> Running transaction check ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed --> Finished Dependency Resolution Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel) Requires: qt5-qtbase(x86-64) = 5.6.2 Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl) qt5-qtbase(x86-64) = 5.6.1-10.el7 Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel) Requires: qt5-qtdeclarative(x86-64) = 5.6.2 Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64 (@sl) qt5-qtdeclarative(x86-64) = 5.6.1-10.el7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest $ ...Any suggestions? Thanks, Chris ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Re: qt5 dependency problem
On 02/24/2018 02:15 PM, Sérgio Basto wrote: On Sat, 2018-02-24 at 17:45 +, Christopher Brown wrote: Hi, In trying to install trojita, I got the following error: $ sudo yum install trojita Loaded plugins: langpacks Resolving Dependencies --> Running transaction check ---> Package trojita.x86_64 0:0.7-4.el7 will be installed --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libKF5Gpgmepp-pthread.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libKF5QGpgme.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libQt5WebKit.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libmimetic.so.0()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Processing Dependency: libqt5keychain.so.1()(64bit) for package: trojita-0.7-4.el7.x86_64 --> Running transaction check ---> Package kf5-gpgmepp.x86_64 0:16.04.3-1.el7 will be installed ---> Package mimetic.x86_64 0:0.9.8-6.el7 will be installed ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Positioning.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Sensors.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5WebChannel.so.5(Qt_5)(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Positioning.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5Sensors.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: libQt5WebChannel.so.5()(64bit) for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 ---> Package qtkeychain-qt5.x86_64 0:0.7.0-1.el7 will be installed --> Processing Dependency: qtkeychain(x86-64) = 0.7.0-1.el7 for package: qtkeychain-qt5-0.7.0-1.el7.x86_64 --> Running transaction check ---> Package qt5-qtlocation.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtsensors.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtwebchannel.x86_64 0:5.6.1-10.el7 will be installed ---> Package qt5-qtwebkit.x86_64 0:5.6.2-1.el7 will be installed --> Processing Dependency: qt5-qtbase(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 --> Processing Dependency: qt5-qtdeclarative(x86-64) = 5.6.2 for package: qt5-qtwebkit-5.6.2-1.el7.x86_64 ---> Package qtkeychain.x86_64 0:0.7.0-1.el7 will be installed --> Finished Dependency Resolution Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel) Requires: qt5-qtbase(x86-64) = 5.6.2 Installed: qt5-qtbase-5.6.1-10.el7.x86_64 (@sl) qt5-qtbase(x86-64) = 5.6.1-10.el7 Error: Package: qt5-qtwebkit-5.6.2-1.el7.x86_64 (epel) Requires: qt5-qtdeclarative(x86-64) = 5.6.2 Installed: qt5-qtdeclarative-5.6.1-10.el7.x86_64 (@sl) qt5-qtdeclarative(x86-64) = 5.6.1-10.el7 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest $ ...Any suggestions? mock -r epel-7-x86_64-rpmfusion_free --install trojita works fine here, it installs qt5-qtdeclarative-5.6.2-1.el7 and qt5-qtbase-5.6.2-1.el7 from base repo Thanks for the reply. But I already use epel and nux, and when I install rpmfusion, I get many dependency errors reported for other packages. Is there another yum way (I mean, aside from downloading the individual packages and localinstall'ing them)? Chris ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
[EPEL-devel] Fast-moving packages in EPEL
Hi, the nextcloud server package is currently stuck at ancient version 10 (current is 20) in EPEL7 (It's not (yet) available EPEL8 repos). I'd like to fix that, but - upstream releases a new version roughly every 4 months - they support them only for roughly 1 year (officially it's "at least 8 months") - nextcloud receives A LOT of bug- and CVE-fixes, and there is no way I'll be able to backport all of those, so staying on an older version after upstream stopped support is not really an option. So, should this still be in EPEL even though it would receive major version updates or is it better to retire it from EPEL? I suspect that EPEL users would probably prefer to run it from upstream's containers anyways, so retiring might make more sense, but I'm open either way. Christopher ___ 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: Fast-moving packages in EPEL
On 11.10.20 13:57, Nicolas Chauvet wrote: > I'm fine with retiring it. > > But on the alternatives , you can have modules (or application > streams) for both epel and fedora. > It would be a good way forward. so it won't enforce nextcloud version > with a given fedora and or epel and would allow to update nextcloud at > users own pace. I'm sort of hesitant to dive into learning how modularity works, though ... although, maybe a good opportunity to learn. Christopher ___ 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: Fast-moving packages in EPEL
One thing I forgot that makes things even worse: - upstream does not support updates across more than one major version, so anybody who actually has the old v10 installed will have their installation completely broken by ANY update at this point - for the same reason, trying to limit major updates to whenever CentOS/RHEL release a new version won't work either. I think I'll retire and look into re-adding it via modularity. Christopher ___ 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: Fast-moving packages in EPEL
On 11.10.20 15:10, H wrote: > I'd like it updated, and kept updated, for EPEL 7. Do you happen to have a system with the current 10.0.something EPEL7 package set up & would you be willing to - if I make an updated package - test the upgrade process? I could set up something myself, but I think most problems are going to be with database changes, and that's not really testable on an empty test install ... Christopher ___ 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: Fast-moving packages in EPEL
On 11.10.20 23:29, Nick Howitt wrote: > How do you intend to handle the switch to PHP7.3? Not sure yet - I wanted to make sure it even makes sense to keep nextcloud in EPEL7 first. But that's another reason it's probably risky to jump people from NC10 to NC18+ (NC13 was the last release to support PHP5.x, so that's no use). Maybe Copr is the way to go here, people will definitely only get the package if they seek it out, and it's easier to leave instructions/caveats where people will see them. My current plan is - put current nextcloud, following their 'stable' path in epel-8-playground - see about creating nextcloud-XX and maybe nextcloud-latest modules for inclusion in epel8 - epel7: ??? Christopher ___ 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: Fast-moving packages in EPEL
On 12.10.20 12:09, Petr Pisar wrote: > RHEL releases a minor version every six months. And as I remember, EPEL8 > allows breaking upgrades at each new RHEL release. Thus technically, it's > possible to rebase the package every year without getting into conflict with > packaging guidelines. On the other hand, I'm not sure whether the users know > it and expect it. OK, that might work - somehow I remembered the minor versions being released more rarely. > You could package each new incompatible version into a separate module stream > and keep maintaining only the latest one. This way the users could switch > to the newer stream whenever they feel comfortable. If they slip switching > to the latest stream, then can migrate any later by hopping through all the > intermediary streams up to the latest one. That could be even automated by > a script. At As Nick Howitt pointed out, NC can be modified to skip the version check, so maybe the hopping isn't even necessary. Still, if the old streams remain available ... intriguing possibilities. > > There is a downside of the modules: There is no mechanism for tracking the > latest stream automatically. DNF team is willing to implement the mechanism, > but so far it's only a conception. It's also dubious whether the new mechanism > would be ported back to RHEL 8. So far users have to switch the streams > manually. I was thinking of offering a nextcloud-stable or -latest stream that simply follows upstream release channel (i.e. N+1.0 replaces N.x, even if N is still supported and receiving updates) in addition tonextcloud-. Or have a normal (ursine?) package for that. That way users can choose between an automatically updating or version-stable Nextcloud, and whatever they choose, they know what they're in for. Christopher ___ 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: Fast-moving packages in EPEL
On 12.10.20 10:49, Leon Fauster wrote: > Not sure but IIRC EPEL should not depend on software collections ...? Can someone confirm that? If the package can't depend on php7.2+, then the question of how to deal with EPEL7 is moot. Christopher ___ 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: Fast-moving packages in EPEL
On 13.10.20 12:14, Leon Fauster wrote: > My recall was this > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/DBAQB3V35TXPNUV4UKKHXUC52BENZJUQ/ OK, thanks, that clears that up. So I'll go ahead and retire the EPEL7 package. Maybe I can put an updated one on Copr instead. Thanks to all of you, you helped tremendously. Christopher ___ 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: Fast-moving packages in EPEL
On 14.10.20 19:32, Kevin Fenzi wrote: > We now allow scls if: > > * They only need to be used at build time (ie, the rpms produced do not > require users to install/enable any scls) > * They are approved by the epel steering comittee. > > So far we have only enabled devtoolset. (so for example, chromium uses > devtoolset to build with a newer gcc, but does not require users to > install or enable anything to use it). > > In the case of php, this would likely not work because it would require > users to install/enable php to get the webserver module or cmd line. Thanks for the clarification, but you're right, that won't help here, as NC has extensive runtime PHP7.2+ dependencies. Christopher ___ 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: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On 09.12.20 11:17, Miro Hrončok wrote: > However, since CentOS Linux 8 (and 9!) will be no more, do we have some > ideas how to handle this? Do we require all EPEL contributors to obtain > the developer RHEL subscription (seems like a huge pain)? Do we switch > to Oracle Linux (only half joking)? Do we try to fight this decision > (however I am afraid I've exhausted my fight capacity on different > decisions)? Intuitively, I think that requiring RHEL dev subscriptions would pretty much kill EPEL packaging on Copr. Unless you specifically want to create EPEL packages, why would you get and keep a RHEL dev subscription when you could just not check the EPEL-boxes? From a purely technical perspective, i.e. pretending it were CentFork Community Linux, are there reasons not to use Oracle Linux? Christopher ___ 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: Local mock builds for EPEL 8 (not Next) after CentOS Linux 8 EOL (also, EPEL 9)
On 09.12.20 15:20, Troy Dawson wrote: > Does anyone know of a group that is going to start their own RHEL Clone? I'm sure the Scientific Linux people will do something, given that they just recently decided to not release SL8 but rather use CentOS 8. I feel quite bad for them, actually ... Some tentative work seem to be happening here: https://github.com/hpcng/rocky but it's early days obviously. They seem to be interested in coordination with other attempts (https://github.com/hpcng/rocky/issues/2), which is good. ___ 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: Proposal: Dropping modules from EPEL-8. Not adding modules to EPEL-9
I found it useful to ship the nextcloud package as a module, particularly in EPEL, but if after multiple years there really are only 12 packages in the repo and even those may or may not work then that is a pretty clear argument for eating the sunk cost & abandoning the idea. -- Christopher ___ 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] Packages for PHP 8.1
Hello, I have a RHEL 9 system running PHP 8.1 from the Red Hat AppStream module. I tried to install php-sodium and php-pecl-imagick from EPEL 9 on it, but DNF gave an error that basically said those packages only work with PHP 8.0. Would it be possible to provide versions of those packages that are compatible with PHP 8.1 too? Thanks, Joseph C. Sible ___ 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
