about
libssh2. However it's still not entirely clear to me.
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 rp
ow it should be possible.
> Is that possible by policy?
I think so...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedorapr
is no
> longer in RHEL8, then it should be permitted as a regular EPEL8
> package.
I agree, but... what about packages that are modules.
What does epel promise not to overlap with? Just bare rpms?
Any rpm in any modules also?
ie, would it have been ok to make a normal rpm of libssh2 befo
pel8-playground use CentOS-Stream.
I think we may be need more data? Like someone writing up all the pros
and cons? I think it might be nice to use stream, but not sure if
there's workflows that would break.
kevin
signature.asc
Description: PGP signature
>
> Seems nothing changed yet,
> > DEBUG util.py:596: No matching package to install: 'rust-toolset-1.35-rust'
> > DEBUG util.py:596: No matching package to install:
> > 'rust-toolset-1.35-cargo'
> > DEBUG util.py:596: No matching package to
remove the arch from mirrormanager. This would cause
errors for anyone who has the repo enabled and they would ask about it,
and we would tell them that it's no longer supported.
4. Some other more clever solution.
Thoughts?
kevin
signature.asc
Descri
> Is using excludearch my only option? How can I get this built?
I think there's work or at least attempts to ask for these deps on all
arches, but I think for now you just need to exclude them.
kevin
signature.asc
Description: PGP signature
__
ponent=cobbler
There's no way to be sure the maintainer(s) are watching this list,
or if the package gets handed off to someone else that they would know
about this, etc.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing
ith
it.
I really wish they hadn't pushed this out as an update. ;(
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedorapro
le_dependency_generator
> macro to EPEL7...
Yeah, this would be good to do.
Is anyone willing to drive this? :)
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To
w packages, it would be a mess.
>
> That said, technically:
>
> - it works either way
> - there is no real EPEL packaging guideline forcing one way or the other
I think we should encourage people to just use python3-foo now, but I
agree it would be a lot of work to try and c
skinfo?taskID=39186949
> >
> > https://pagure.io/releng/issue/9048
> >
> > Paul.
>
> Thanks. Hopefully this will get fixed soon.
I think it's fixed now. Please let us know otherwise on the above
ticket.
kevin
signature.asc
Description: PGP signature
_
of foo-2.1
I guess the expectation is that the maintainer should put the
packages.cfg back in place when merging back to epel8, but I could see
this getting forgotten.
So, perhaps the best way forward here is some reporting?
ie, check upgrade path between all epel8 and epel8-playground packages.
The p
On Fri, Oct 18, 2019 at 12:02:32PM -0500, Merlin Mathesius wrote:
> On Thu, Oct 10, 2019 at 9:32 AM Merlin Mathesius
> wrote:
>
> >
> >
> > On Wed, Oct 9, 2019 at 4:05 PM Kevin Fenzi wrote:
> >
> >> On Mon, Oct 07, 2019 at 01:16:47PM -0500, Merlin Math
r provide feedback as
> necessary. When it's ready, and I will prepare a PR for this to land in
> https://pagure.io/epel/blob/master/f/docs/source
That would be great...
kevin
--
>
> Regards,
>
> Merlin
>
> --
>
>
> *Regardi
On Tue, Oct 08, 2019 at 12:58:21PM -0700, Kevin Fenzi wrote:
> On Tue, Oct 08, 2019 at 03:48:35PM -0400, Irina Boverman wrote:
> > Ok, how will I know what test results are?
>
> We will be sure to share them back here to devel and epel-devel lists.
And... smooge and I just tested
On Tue, Oct 08, 2019 at 03:48:35PM -0400, Irina Boverman wrote:
> Ok, how will I know what test results are?
We will be sure to share them back here to devel and epel-devel lists.
kevin
--
>
> On Tue, Oct 8, 2019 at 2:56 PM Kevin Fenzi wrote:
>
> > On Tue, Oct 08, 2019 a
we have to try and test it.
So, options:
1) wait and let us test and see what the outcome is.
2) ExcludeArch: aarch64 for now and then pay attention to how the
testing comes out, if it works, drop your ExcludeArch.
kevin
signature.asc
Description: PGP signature
__
On Wed, Sep 25, 2019 at 11:40:19AM -0400, Stephen Gallagher wrote:
> On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa wrote:
> >
> > On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi wrote:
> > >
> > > After the announcement today of centos-stream, I wonder if it wou
, the
centos stream will become the next stable point release, so it would
allow people to test against that and get changes ready that they could
then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
kevin
signature.asc
Description: PGP signature
739804
>>
>> If any EPEL expert thinks the package should be unretired for now,
>> please do so.
>>
>>
>> Miro, please unretire the packages for the 2-3 weeks til CentOS 7.7 is
>> out in the CR repo. My apologies for not thinking of this when you
>
a modular repo compose
there (just some pungi config) and it clearly seperates the playground
from the more stable stuff.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
ll allow
> them to be merged cleanly. Pros: Optimum user experience (they get the
> default profiles installed when they use the simplified install
> command). Cons: We need to constantly monitor each RHEL AppStream
> release and ensure that we aren't ever over
On 8/13/19 11:15 AM, Miro Hrončok wrote:
> On 13. 08. 19 20:08, Kevin Fenzi wrote:
>> On 8/11/19 1:45 AM, Miro Hrončok wrote:
>>> On 11. 08. 19 9:59, Mohan Boddu wrote:
>>>> I unretired the packages and tagged the old builds, I think that
>>>> should
n we somehow:
>
> - keep the packages in the repos
> - but make Koji prefer the RHEL ones (they have higher EVR)?
Are they using the same source package name?
If so, the epel one will always be used.
If not, they should both be available.
kevin
signature.asc
get them from there.
Or we could try and do something with pungi that also gathers from
epel8, so epel8-playground would have all the epel8-playground packages
+ all the epel8 packages in it. (but that would use more disk space).
kevin
signature.asc
Description: OpenPGP digital signature
___
other systems.
What version of fedpkg do you have there?
It might be the version is too old to understand the epel8-playground
request?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedor
of module build service... I don't know of any plans to
hide those. Usually they aren't too much trouble to filer out from the
command line at least.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel m
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/20
> https://src.fedoraproject.org/rpms/python34/pull-request/35
>
> Starting here: https://bugzilla.redhat.com/show_bug.cgi?id=1719633
But we don't want to actually land that until 7.7 is out right?
kevin
sign
gt; verison of Python 3, to my knowledge.
I'd just let it fade away at it's end of life soon.
> Anything else you can think of?
Nope.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing li
es are intended to be frozen and unchanging, but this
> approach leaves open the possibility of tagging other builds into
> epel8-8.Y and regenerating the compose if the need arises. It will
> need to be communicated that these repositories will not receive
> updates and are intended to
ion of Zchunk?
It was a bug in a new version of bodhi that was deployed yesterday.
It's being fixed and the repos should already be fixed up, so no action
to take and sorry for the trouble.
kevin
signature.asc
Description: OpenPGP digital signature
_
pos in
> production which depend on EPEL.
> Or is this considered that unsafe we have to wait until EPEL 8 is done?
I don't think it would have any chance of working. The libraries in
rhel8 are completely different from rhel7. I don't think any epel7 rpms
will install, and
to handle this setup in order to support modular building
in epel8.
Thoughts? Anything we didn't think of?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscrib
On 5/2/19 11:28 AM, Fred Gleason wrote:
> On Thu, 2019-05-02 at 10:26 -0700, Kevin Fenzi wrote:
>> Sorry this is all so confusing. ;(
>
> Life can be complicated at times! :)
>
> I admit that the way this Python 3.4 => 3.6 update worked suprised me.
> I have bin
On 5/2/19 10:10 AM, Fred Gleason wrote:
> On Wed, 2019-05-01 at 16:17 -0700, Kevin Fenzi wrote:
>> Can you please refile that as two bugs? On python3-pycurl and
>> python3-mysql?
>>
>> The python34 component is only for python34 itself, you will need to
>> get
&
gzilla.redhat.com/show_bug.cgi?id=1705286
Can you please refile that as two bugs? On python3-pycurl and python3-mysql?
The python34 component is only for python34 itself, you will need to get
those other two packages to fix things.
Thanks,
kevin
signature.asc
Descr
e term is. They are so old that if they are really needed, they
> need to be rebuilt.
+1
I guess these don't show up in the updates-testing reports because they
have _some_ karma, just not enough to go to stable. Perhaps we should
see about getting that report fixed as well?
kevin
Hopefully we
can fix that this week.
>
> (ppc64, ppc64le and aarch64)
> 'nothing provides libgit2.so.26()(64bit) needed by
> kf5-ktexteditor-5.52.0-1.el7.ppc64'
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34025046
Might be the rhel7 package is x86_64 only there?
ke
4 packages. I don't think we want to keep them
around and supporting them forever. Obsoletes on everything will remove
the old python34 (and not pull in the new one) unless there's something
installed that actually needs python34.
kevin
signature.asc
Description: OpenPGP digital signat
t doesn't
provide /usr/bin/python3.
I'm +1 to add this to the update and give it some more baking time.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubs
alternatives are much
else. ;)
But we talked about this a lot on IRC.
Just make python36 obsolete the old version of python34 that had
/usr/bin/python3. This causes yum to install the new python34 and pull
in python36 for /usr/bin/python3.
It does mean people with 3rd party software are no
as...
ah, it's' called python2-libcomps there. So, perhaps we need to rebuild
koji for the different name? Can you file a bug on koji to that effect?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- e
nd possibly fedora-devel announce about it and mention
that it will go stable in 3 weeks if nothing serious is found.
And perhaps some blog posts or the like also?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list
nteered to do the
> rebuild. I'd rather the python-sig and/or developers give the final
> answer.
>
> Epel Python Sig (or whoever was in charge of the python34 to python36
> change), what should Benjamin do with his package?
You (or whoeve
st 2 weeks?
> If packagers want to update their python package for whatever reason,
> what should they do?
Build as usual, but ask someone to edit the update and remove the
previous one and add in the new one.
Thanks for building and coordinating everything!
kevin
signature.asc
De
el7 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
signature.asc
Description: OpenPGP digital signature
___
epel
s://fedoraproject.org/wiki/EPEL
Well, we have:
https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
I am not sure this belongs on the front page... but it might be nice to
be more visible yeah.
kevin
signature.asc
Description: OpenPGP digital signature
.rpm internal
>
> Are the above items where the buildrequires in a package are pulling
> them in or is there a buildroot directive adding them?
"internal" here means local to koji, ie, in epel.
expat21 is in epel. I have no idea why this bug wouldn't have hit
befor
e in
both rhel6 and rhel7.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Condu
tail around "it didn't work"?
What exactly happened when you clicked the login button on the
bodhi.fedoraproject.org page? Did it take you to a login/password
prompt? Did it error? did it just do nothing at all?
It would help us to track down the issue to know more if you have a
chance
ame/password
dialog? It said password incorrect? or any other messages/errors?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...
ing-appstream_using-appstream
I'd say everything like appstream.
>
>
> Some of what I wrote just might not make sense due to my limited
> understanding of modules.
I could also be wrong above, so hopefully if so someone will correct me.
kevin
signature.asc
Description: Ope
; "epel8" name?
>
> That is the part I am wondering about because of modularity and
> arbitrary branching. Does modular branches need to be epel8- or
> something else?
They just need to be arbitrary branches where the module config says to
also make them for epel8 (in
t;>
>> And then copy in your spec and sources, edit and go. There is no need
>> for a package review.
>>
>> That's certainly a few steps but far from the worst process in the
>> distro. What could we do to make it easier?
ers would prefer (since it's
already in, etc). We can look at moving to 3.7 or later down the road.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send
; * Cython
>> * PyYAML
>> * pip
>> * attrs
>> * requests
>> * mock
Yeah, I'd love to see us move this forward and get everything on 3.6...
Unfortunately I don't have a lot of time, but I can review/merge PR's
and do builds and such.
Perhaps we co
On 08/02/2018 08:43 AM, Richard Grainger wrote:
> This package has been in testing for a month:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-69e2ee28b8
>
> Can anyone push it to stable?
Looks like it has been now. :)
kevin
signature.asc
Description: OpenPGP digit
each, so we can garner some stats
I'm confused here. I doubt very much RHEL is going to drop python2 from
rhel7. Thus epe7 packages should be able to go on as they have...
kevin
signature.asc
Description: OpenPGP digital signature
___
epe
ainer. Some are able to look at
things quickly, others are maintaining things in their 'spare' time and
can't get to things very quickly at all.
Being detailed in your report, attaching possible fixes or talking
directly to upstream can all help.
kevin
signature.asc
s no i686 trees, only some few
.i686 packages in the x86_64 repo for multiarch support. I am pretty
sure this is not enough to build wine i686 for epel.
This might be something more fit for the other proposal recently (an
EPIC repo).
kevin
signature.asc
Description: OpenPGP digital
there eventually.
I don't think this is likely a winner: No other arch support, just
x86_64. Network and logistics problems possible, etc.
Anyhow, I think the proposal is doable, but the epic releng work would
be substantial. I think we need a dedicated person for all that, or
enough part time
EPEL7, upstream
https://releases.ansible.com/ansible/ or use
https://access.redhat.com/articles/3174981 to enable and get
Red Hat Ansible Engine from Red hat.
Thanks,
kevin
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
built a newer one in epel7-build with that set back.
Ideally we would come up with a better solution here, possibly in
epel-release so we don't need to rebuild this weird package every RHEL
release.
kevin
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
otherwise aware of if they
> want the "official Red Hat" build of it etc etc
Well, it's available to all, but I would think you would have to enable
it, but yes, an announcement would help people decide where to get
ansible from.
kevin
___
s
with all bugfixes that are landed then. EPEL will package those.
kevin
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
mething out this week or early next.
kevin
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
st push the
> packages to stable to clear them out? Maybe if they introduce a bug,
> somebody will at least pay attention to them.
I went and unpushed those of these that had -karma and pushed to stable
those that didn't.
kevin
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
hich will use the master mirrors for it.
As for fixing it on AWS, I suppose we could add some logic to our
mirroring to also copy up the latest epel-release version as that
'latest' link. We should make sure it auto updates though so we aren'
SCLs. ie, users can install and use it as they do now. If we ship things
that do have runtime dependencies on SCLs we need to make sure they can
install those (ie, how do they enable them in CentOS? In RHEL? what
error(s) would they get).
kevin
signature.asc
Description: OpenPGP digital
ocal mock builds, but won't do
anything for koji/epel. ;)
I think at this point it just needs someone to do the setup, and I think
Peter said he could. If not, I can put it on my list, but not sure when
I would get to it.
kevin
signature.asc
Description: OpenPGP digital signature
__
On 12/05/2017 10:57 AM, Mátyás Selmeci wrote:
> Hi,
>
> I haven't seen new 'orphaned packages' emails since July. Is that on
> purpose?
Tyll has done those in the past, and they are somewhat tied to the
Fedora release cycle. They should fire up again in the
and submitting one big update with all the python36 +
rebuilds.
We will need to also schedule and announce when the switch will take
place, as after this lands the 34 versions of the packages will
disappear and the 36 ones land...
kevin
signature.asc
Description: OpenPGP digit
may be something we get "for free" from it. Branches now have
a SLA in Fedora, we should be able to leverage that and expose it better
to users. Of course everything may change with modules, it's really
early to tell. We may be able to make different modules with diffe
and there's no way we could backport even security fixes to an
out of date 1.9 version. Sorry.
You can of course still use 1.9 if you wish, just realize that it
doesn't get any bugfixes or security updates.
kevin
signature.asc
Description: OpenPGP digital signature
___
e wrong place to ask this question, could you redirect me to the
> correct place?
There is already a bug on it.
Follow along at:
https://bugzilla.redhat.com/show_bug.cgi?id=1503874
kevin
signature.asc
Description: OpenPGP digital signature
___
On 10/07/2017 01:51 PM, Neal Gompa wrote:
> On Sat, Oct 7, 2017 at 4:48 PM, Kevin Fenzi wrote:
>> On 10/07/2017 01:14 PM, Neal Gompa wrote:
>>>
>>> Since Ansible was added as an "unsupported dependency" for the System
>>> Roles feature, it&#x
dora version if at all
possible.
I have no idea if thats changed, but I guess time will tell.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
index.html#technology_previews_red_hat_enterprise_linux_system_roles_powered_by_ansible
Accordingly, you can get ansible now from rhel extras channel, or CentOS
extras repo.
You can also get ansible rpms now from
http://releases.ansible.com/ansible/rpm/
Note that ansible continues to be available from epe
On 08/08/2017 07:40 AM, Stephen John Smoogen wrote:
> We did not have the meeting last week. Could I get an RSVP or something
> similar from committee members for this weeks meeting?
I should be around.
kevin
--
>
>
> #startmeeting EPEL (2017-08-09)
> #meetingname EPEL
>
On 08/04/2017 12:37 PM, Jason L Tibbitts III wrote:
>>>>>> "KF" == Kevin Fenzi writes:
>
> KF> I don't think we have any way to find out the version of a package
> KF> in all channels. At least I don't know of such a way. So, I think we
>
automatic reposync is done.
>>
>> Unfortunately not for aarch64: https://pagure.io/releng/issue/6926
>
> I was informed it was pushed to the CDN, smooge what's the status on this?
I think it's synced as of last night.
What package(s) were you waiting for?
kevin
ckage as soon as rhel started providing a source
package with the same name. If they are still different source packages
then the newest one would win.
I'm in favor... lets give it a try with some of the common ones. :)
kevin
signature.asc
Description: OpenPGP digital signature
also be
> useful. [Putting in a Summary that the package is deprecated may also be
> useful.]
> 2. Announce on epel-devel and epel-announce this is going to happen.
> 2. push the update out to users.
> 3. orphan the package in EPEL
> 4. remove it after a month after the update went
ness
> #info ???
> #topic Open Floor
> #endmeeting
I'd like to add a short topic:
#topic ansible in rhel-7-extras
thanks!
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-d
.org/metalink?repo=testing-epel7&arch=$basearch
Yum should work fine with either, but dnf needs the change to work.
So, both yum and dnf testing welcome. :)
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- ep
ilt for python 2. Is it fine if we bring
> it back in EPEL but make it python3 only?
As long as it's a new package called 'python3-greenlet' (or anything
except python-greenlet), sure.
If it's called python-geenlet it will override the rhel extras one.
So, a new pac
s.
Does that answer the question for all of them? Or is there another case
here?
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
start a VFAD wiki page and collect possible work items
and then look at scheduling something. It would be nice from my
viewpoint if it was during a Fedora freeze or between releases so it was
a bit quieter.
kevin
signature.asc
Description: OpenPGP digital signature
_
don't want to add an Epoch, because the idea is that we
keep the EPEL package "older" than the RHEL one so people who install
get the official one (if available on their arch).
kevin
signature.asc
Description: OpenPGP digital signature
__
de it,
but we could try.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
eed to figure out
how we can build just armv7 stuff against CentOS.
kevin
signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Any objections?
Not here. I think this is the best way to handle these kinds of
packages. We should also update the wiki that the same process for
limited arch can be used for this case as well.
kevin
signature.asc
Description: OpenPGP digital signature
__
taken them knowing that that
package existed and explicitly removing the ansible package and
installing it.
kevin
pgpLAW40BEwLK.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscri
On Fri, 13 Jan 2017 00:18:09 +
Peter Robinson wrote:
> On Thu, Jan 12, 2017 at 8:44 PM, Kevin Fenzi wrote:
> > Greetings.
> >
> > When ansible 2.0 was released there were some changes in playbook
> > handling made. For this reason, we created a backwards compatib
1.9 has known security vulnerabilities, backporting fixes is
impossible, we will be retiring the ansible1.9 package from EPEL.
All ansible 1.9 users are urged to update to 2.x as soon as possible.
kevin
pgpfDYljQ7fDE.pgp
Description: OpenPGP digital signature
with a way to do that, but no one yet
has had the time to try and implement it.
so, yes, we would like to, but not sure when it might happen.
kevin
pgpL8gecw3J_T.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists
pulled in an older version than what is in EPEL-7 so we
> will need to pull out the old package and rebuild all the packages
> that require it (python-cgit looks like one of them). Kevin Fenzi will
> have more on this later.
I retired python-cffi in epel... however there's likely so
What is the next step here?
I've retired speexdsp. It should be gone in the next updates push.
kevin
pgpj1E5XiJcu0.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
ops out of
support and we want to move to 1.10, we can just retire 1.8 and move to
1.10 without having a specific flag day that breaks everyone using 1.8.
kevin
pgpyU_TWkUD9Q.pgp
Description: OpenPGP digital signature
___
epel-devel mailing list -- epe
101 - 200 of 378 matches
Mail list logo
