automated too.
See https://bodhi.readthedocs.io/en/latest/user/fedora-flavored-markdown.html
you can add rhbz#n to your changelog/git commit and bodhi will see
it and associate that bug with that update.
kevin
signature.asc
Description: PGP signature
--
__
also be desired in EPEL N+1. It might
only work with an older stack, it might be something that is soon to be
replaced, we can't really know.
kevin
signature.asc
Description: PGP signature
--
___
epel-devel mailing list -- epel-devel@lists.fedo
age didn't
change otherwise. Also, there might be cases where the dependent package
does have to change... ie, foo-1.0 works with django-3.2, but when 4.2
lands you have to upgrade to foo-2.0 to work with it?
Anyhow, I think this is a pretty reasonable process, but we shoul
On Mon, Jan 29, 2024 at 06:40:19AM -0800, Troy Dawson wrote:
> On Mon, Jan 29, 2024 at 6:37 AM Neal Gompa wrote:
> >
> > This seems reasonable to me.
> >
>
> I agree with Neal, this looks good to me.
> Thank you for the nice explanation/write-up.
Yeah, same he
cy for lack-of-time retirements), but my preference would be
> to retire it ASAP.
Retiring seems reasonable here.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe sen
t; example: https://bugzilla.redhat.com/show_bug.cgi?id=2184351
>
> So, it was a general feasibility request. For those that slip into
> such situation; there are still the repo archives, that get a copy
> when a minor release happens (this one I
move from epel.
That looks pretty good, but I might suggest adding something more
explicit at the end:
Note that this issue is purely informational, you do not need to take any
actions at this time.
But perhaps thats overkill. ;)
kevin
signature.asc
Description: PGP signature
___
at least the version of the
> collection in ansible, and optionally higher while giving due diligence to
> avoiding breaking changes.
That sounds mostly reasonable. I guess I could come up with a crazy case
like 'the version in ansible has some problem that wasn't noticed, so I
should be) closely tied together, the seperately packaged ansible
collections should be free to update as long as they continue to work ok
with ansible-core thats provided/etc.
So, in practice I personally have been thinking of 'ansible' as the
stable collection of collections, and the s
Could anybody please merge them and build the packages or shall I do it
> myself?
Done. Building now.
Thanks for the pr's
kevin
--
>
> Thanks,
> Jitka
>
> On 12/6/22 04:40, Maxwell G via epel-devel wrote:
> > On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova
at the
respective
build is available in the build root for subsequent builds. "
But if you can see a way to be more clear there, perhaps you could put
in a PR?
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-de
> 2. We can send out one announcement to epel-announce about which packages are
> going to be retired and when that'll happen, instead of retiring packages in
> a
> piecemeal manner.
>
> 3. The maintainers won't have to remember to do it.
>
> 4. If we fi
> It looks like I needed to do another "koji wait-repo " between the
> tag-pkg and build, but I will say that it is not obvious in any of the
> documentation I could find, that this needed.
:( Which documentation were you looking at for this?
We should try and update it...
The wait r
here. ;(
I wonder if we could get some cycles from developers to adjust
pagure-dist-git for this case to make it more self-service.
(taking orphan packages over).
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-
g is unclear there, please do let us know.
While RHEL may be moving to jira with RHEL10, EPEL is very likely to
stay with whatever Fedora is using (currently bugzilla).
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list --
an EPEL 9 Next Koji scratchbuild and it got e.g.
> pyproject-rpm-macros-1.0.1-1.el9.
It's not using rhel9 (yet) just a snapshot of stream9 back when it was
tracking 9.0.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing l
Looks like your orig message didn't get to epel-devel, perhaps you
aren't subscribed?
On Thu, Apr 21, 2022 at 04:03:20PM +0200, Michael Trip wrote:
> Hi Kevin,
>
> What does that mean for the ansible rpm package in general? Do we have
> to remove the ansible RPM from o
that time I will be retiring the ansible 2.9.x package in epel7.
In epel8 I will be converting the 'ansible' epel8 package into the
upstream ansible-5 meta collections package (which also pulls in
ansible-core).
epel7 and epel8 ansible users are advised to plan for this
retiremen
onflicts with that channel, but I'm not sure there's any
> > easy way there. kevin
> >
> > Apologies for replying to this old thread, but unless I'm mistaken, this
> > is still a problem. More recently, there were two blog posts from Red Hat
> > that exto
On Thu, Mar 24, 2022 at 07:09:33PM -0400, Neal Gompa wrote:
> On Thu, Mar 24, 2022 at 6:38 PM Kevin Fenzi wrote:
> >
> > On Thu, Mar 24, 2022 at 07:56:15AM -0700, Troy Dawson wrote:
> > > It was talked about December 2021, and pushed off to the new year.
> > >
e of our 'will it install' or
broken deps type checks will know that it is now not working. ;(
If we don't add HA and RS to the base epel repos, I guess we could just
allow people to build those things they need in epel, but then of course
they get to maintain them. ;(
Perhaps
use compatiblity packages
instead.
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.fedoraproject.org
Fedora Code of Conduct:
htt
On Mon, Jan 31, 2022 at 06:48:21PM +, Gary Buhrmaster wrote:
> On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi wrote:
>
> > The limited arch policy we had for epel7 had a number of problems.
> > At first we just said 'rebuild the exact rhel version' and then we
lived as it's not
> just a matter of "we can persuade RH to ship it in CRB, it's not
> supported anyway"
I personally don't much care, but we should pick one. ;)
> - should we come up with review guidelines for this? fedora-review seems
> overkill as
ist a bunch of things, or just say 'ok, approved'". I would typically
look closely at those and find things that were missed. I also recall
several reviews that I blocked due to legal reasons where the reviewer
didn't understand things correctly.
That said, the volume of new pa
root repos and made sure it wasn't going to delete
them, so it should be all back to working. If you have the non working
repodata cached, you make need to do a mock --clean or the like.
We still need to adjust koji to use the 'release' repos for epel9.
kevin
signature.asc
Descr
d to be sure)).
There's no longer any plans to mass rebuild, those packages that need a
rebuild for some reason can be rebuilt by their maintainer(s).
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-dev
make it non-default and tell people that rollbacks require an
> --enablerepo= option, though.
This would work for Fedora now with the archive repo above.
I suppose we could look at setting up a similar setup with epel.
kevin
signature.asc
Description: PGP signature
it.
wow... consensus in 1.5 hours. :)
Perhaps this should be discussed at the next meeting? To allow
interested parties to actually see it and comment?
Anyhow, I'm personally fine with it, but note that 3 days leaves very
little time for testing. One of those days is likely m
If we do choose to go with Plan B or C we will need to make the decision
> fairly quickly.
I like A. ;)
I think B is risky because of the possible changes between beta and ga,
and I think C is breaking the 'we build against rhel' implied promise as
well as leaving a window with no
epel8/9.
Users using EL7 for a control host should look at moving to EL8 before
ansible 2.9 goes EOL.
Thanks,
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email
he misfiled bugs that will definitely appear (I do
that for fedora/distribution a lot).
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-
On Thu, Sep 16, 2021 at 08:18:30PM +0200, Leon Fauster wrote:
> On 16.09.21 19:47, Kevin Fenzi wrote:
> > On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote:
> > > I believe ansible-core includes a "dependency manager" depending on your
> > > defin
7; metapackage require all those collections and
ansible-core, so
when someone does 'dnf install ansible' they get hopefully pretty
close to what upstream ansible is now.
I'm not sure if there will be problems with that yet tho. ;)
I'm hoping to basically do this for Fedora
Just a heads up that ansible-core (the engine part of ansible) is now in
CentOS stream 9:
https://gitlab.com/redhat/centos-stream/rpms/ansible-core
Note that this is the engine, you will likely want to install
collections for modules and roles, etc.
kevin
signature.asc
Description: PGP
nents blocked.
Right.
Instead we need to tech our bugzilla sync to sync EPEL modules to
'Fedora EPEL Modules/$name' like our Fedora modules are made under
'Fedora Modules/$name'.
I've filed:
https://pagure.io/fedora-infra/toddlers/issue/82
about this.
ke
On Tue, Aug 03, 2021 at 02:57:50AM +0200, Miro Hrončok wrote:
> On 03. 08. 21 2:10, Kevin Fenzi wrote:
> > On Tue, Aug 03, 2021 at 01:55:52AM +0200, Miro Hrončok wrote:
> > > Hello,
> > >
> > > I've opened the following two pull requests to introduce %
ess because
they were while I was on PTO and I missed them when catching up.
Usually a ping in PR would let me know about them...
> A meta question: Should the epel-sig group co-maintain the package?
They could if desired.
kevin
signature.asc
Description: PGP signature
___
> If people could give any cases for, or against these, please respond here.
> The EPEL Steering Committee will have a vote at our next meeting (July 28).
I guess I'm fine with changing it, but it's hard to say how much effect
it will have. Per
RHEL9.0 GA, cs9 may well have already moved on to
9.1... so that might result in stuff that doesn't work/install/depsolve
with 9.0? Or am I missing something there...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- ep
or can we just
> directly tag them for stable compose?
In order to get a base of rhel9 packages out quickly, I would say just
make a stable compose with them. Then, all future ones use bodhi.
kevin
signature.asc
Description: PGP signature
___
epel-d
ckage(s) are added to RHEL CRB, retire your -epel
> package.
>
> ---
> Sorry, this is a little rushed. I wanted to get something out sooner,
> rather than later.
Looks great to me aside the nitpicks above.
kevin
signature.asc
Description: PGP signature
__
n sync... I think we would want
some automation here to notify when such a package updates in rhel,
otherwise while we might update it at first, it will get forgotten after
a while.
Outside of that on the technical side... if these are from stream they
might not always
in the process of being moved from a vm to a openshift
project.
I've disabled the vm version now, so hopefully that will fix this.
kevin
--
>
> On Tue, Jun 8, 2021 at 11:48 AM Andrew C Aitchison
> wrote:
>
> >
> > I get two copies of the steering meeting reminders
and after successfully
> doing kinit d...@fedoraproject.org.
Can you make a ticket at https://pagure.io/fedora-infrastructure and
include the output of the failing commands with:
"KRB5_TRACE=/dev/stdout" prepended (that will give debugging output).
Thanks,
kevin
stop shipping a known vulnerable package and get
it off my dashboard with all it's CVE's. I'm pretty sure 1.4.11 isn't
actually going to work, but happy for someone to prove me wrong. I don't
really have the time to investigate further myself.
So,
On Mon, May 17, 2021 at 08:56:06PM +0100, Nick Howitt wrote:
>
>
> On 17/05/2021 19:32, Kevin Fenzi wrote:
> > roundcubemail in epel7 is very old at this point, and can never be
> > upgraded because epel7 has too old a php.
> >
> > It's got 10 CVEs ope
roundcubemail in epel7 is very old at this point, and can never be
upgraded because epel7 has too old a php.
It's got 10 CVEs open against it.
I'm planning on retiring it later today.
I can mail epel-announce about it...
kevin
signature.asc
Description: PGP
@lists.fedoraproject.org/thread/QLYF7M7UU7FFSBQTOIK7MFCAYS6TXDVZ/
>
> People like programmatically ways: How reach the "downgrade" goal
> via such archives?
>
> Would a repo config for the archives in epel-release be a viable
> solution? (details have been intentionall
https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
>
> Would it not be beneficially? Especially for such cases like these ...
There's a number of reasons we haven't implemented this over the years:
tooling isn't setup for it easily, desire to not k
ble from EPEL.
I think this sounds fine, but you might want to send a note to
'epel-annou...@lists.fedoraproject.org' once its in updates-testing and
again when it goes to stable.
kevin
signature.asc
Description: PGP signature
___
epel-de
ent point. Perhaps we should try and identify those
packages and see if we can just add epel-packagers sig to all of them?
Do we have any record of those?
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproj
them rebuild a epel9-next package
> on epel9, or possibly maintaining a package when the Fedora packager
> does not want to do EPEL.
I think simple is better here.
> - More details will be coming, but we hope the SIG will help get alot
> of the most used EPEL packages
On Fri, Jan 29, 2021 at 01:46:56PM -0800, Troy Dawson wrote:
> On Fri, Jan 29, 2021 at 2:29 AM Petr Pisar wrote:
> >
> > On Thu, Jan 28, 2021 at 03:15:29PM -0800, Kevin Fenzi wrote:
> > > I think that could be workable, but I'll toss out another proposal:
> >
ery night and there's no bodhi overhead.
Of course to be confusing we could just treat epel9-stream that way
until GA too I suppose.
In any case as soon as centos 9 stream is ready, I think it would indeed
be a great idea to start allowing epel builds against it one way or
another. :)
el8 ( python38-radicale3 )
do we want to also standardize there also to python3-name? Since there's
multiple python stacks there we really might have need for being more
specific there, so that might be fine, but we should probibly note it.
kevin
signature.asc
Description: PG
osal for both groups).
>
> Is there any easy way to tell if a package is explicitly blocked vs just not
> being present.
You can ask koji:
koji list-pkgs --show-blocked --package whatever
and it will tell you what tags it's blocked in with [BLOCKED]
kevin
_
> https://wiki.centos.org/FAQ/CentOSStream#What_happens_when_CentOS_Stream_switches_from_RHEL_8_to_RHEL_9_based_content.3F
> ?
There will still be centos8 stream for a year...
kevin
signature.asc
Description: PGP signature
___
epe
in the end?
but yeah, not sure what the best way is.
We do have some time...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@list
On Sun, Dec 06, 2020 at 07:51:13PM +0100, Antonio T. sagitter wrote:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=56903884
>
> I opened a ticket about:
> https://pagure.io/releng/issue/9887
Should be fixed now.
Please reopen the ticket if you see any further issu
epel8 and is only made if requested.
fedpkg/fedscmadm just needs to finish adjusting and no longer make the
package.cfg file.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubsc
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.
kevin
signature.asc
Description: PGP signature
___
just put it in a copr (this would work for both epel7 and
epel8). It's not as discoverable there, but this might be a good
solution.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists
On Mon, Oct 05, 2020 at 11:08:27AM -0500, Carl George wrote:
> Thanks for looking over the plan Kevin.
>
> 1. I wasn't planning any changes for bugzilla. I think it's appropriate for
> the bug reports to be filed against the epel8 component. Typically there
> should b
s using 4.2.2 and you update epel7, how much will they
need to adjust?
I would lean toward doing the upgrade, but good to know what affect it
might have, and if it's going to require people to make changes,
announce in advance and leave in testing extra long.
kevin
signature.asc
Descripti
ier just to do it all at once after f33 freeze is over?
Thanks much for putting this together!
kevin
--
>
> On Wed, Sep 23, 2020 at 8:43 PM Carl George wrote:
> >
> > I agree, using .el8.next for the dist macro makes the most sense. This will
> > enable maintainers to use a s
t to epel-announce).
> >
> epel-announce is a moderated mailing list. Sometimes it is quick,
> sometimes it takes a day or two to get through.
I get to moderation requests as soon as I can, but not while I am
asleep. :)
kevin
signature.asc
Description: PGP signature
On Wed, Sep 16, 2020 at 11:28:10AM -0700, Troy Dawson wrote:
> On Wed, Sep 16, 2020 at 9:36 AM Kevin Fenzi wrote:
> >
> > On Tue, Sep 15, 2020 at 09:18:17AM -0700, Troy Dawson wrote:
> > ...snip...
> > >
> > > When a maintainer is done with their package i
> In EPEL Next we could define dist to a string that RPM evaluates higher than
> .el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be
> in sync and the same commit could be built for both targets. The higher
> dist would ensure the upgrade path works.
I thi
. We could also create a 'epel-sig' permission and grant everyone in
that group permissions to untag from playground?
Otherwise, looks good to me.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@list
e playground repo).
>
> Also another question is whether we can fix the chroot, or not (dropping the
> config file from mock-core-configs is an option, too).
We should be able to fix it. Once the above lands in the buildroot it
should be working again.
kevin
signature.asc
Description: PGP
to epel branches,
> > some
> > don't want that at all. I wonder if it wouldn't make sense to have
> > some
> > way to indicate to people what workflow is in effect for the package
> > (I
> > guess spec file comments?)
> >
> Maybe spec file
packages as 'always
branch' wouldn't it?
The other hazard if that different maintainers have different workflows
and epel-sig folks would need to adjust to those. ie, some people want
master to have epel conditionals and merge back to epel branches, some
don't want that
sal. It can be changed. If there is something
> in there you do not want or think should be re-worded, please say so.
Looks good to me. +1 and thanks for writing it up.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing
do a lower karma/time threashold than regular EPEL if
> desired.
>
ok. Thats a non trivial amount of work added on. (creating bodhi release
for it, updating sync scripts and punji config, etc). Can be done, but
will definitely be more work.
kevin
signature.asc
Description:
at's a problem for Future Us to solve.)
I'm a bit confused here... you seem to be conflating epel and this
epel-stream/epel-next. Do you mean both of them? or just the new one
would move over? We would need at least shared git (is that still
someth
p of epel8, rather than duplicating content
>
> I first suggested this idea at the last EPEL Steering Committee meeting, and
> we plan to discuss it again during the next one. Please share your thoughts
> on this proposal.
I assume this would work like playground/r
releng. We would be changing the inheritance,
> instead of deleting it. I don't know how much extra work that will
> be.
Should just be a few commands.
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-de
On Mon, Aug 31, 2020 at 08:05:14AM -0700, Troy Dawson wrote:
> On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen wrote:
> >
> >
> >
> > On Mon, 31 Aug 2020 at 09:43, Troy Dawson wrote:
> >>
> >> On Sun, Aug 30, 2020 at 11:44 AM kevin wrote:
>
think it satisfies all the use cases, but... we barely have
enough cycles to try and revamp playground. Do we think we have enough
to do that and also make a new -next version?
Also, if we do make it, perhaps we should think what critera we would
use to determine it's successfull? 10 packag
consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you
have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to
justify the trouble
would be
> quite different with the different plans. So until we decide which
> way to go, we don't know what to do.
>
> Thoughts on which plan to choose? Or if there is something different?
A for me, not sure when I would have time to work on it, but I think
thats best.
ke
On Tue, Jul 21, 2020 at 02:06:43PM +0200, Miro Hron=C4=8Dok wrote:
> On 07. 07. 20 14:08, Tomas Orsava wrote:
> > On 6/30/20 9:10 PM, Miro Hron=C4=8Dok wrote:
> > > On 30. 06. 20 21:03, Kevin Fenzi wrote:
> > > > I don't think a package-review is needed? It wou
On Thu, Jul 16, 2020 at 04:29:08PM -0400, warron.french wrote:
> Actually the file indicates DEFAULT already.
Odd. Thats the only time I have seen any errors like those.
YOu might try a sudo update-crypto-policies --set DEFAULT
and see if it helps anyhow.
ke
fix this. Can someone please explain what the
> problem is on a high level and then what to do about it so that I can learn
> from this?
What does:
cat /etc/crypto-policies/state/current
show?
If it's FUTURE, thats the problem. You can do back to default with:
sudo update-cr
ra and cause a lot of breakage.
Whats your goal here? To have them easily available to query from fedora
installs?
> (Side note: I'm using the hyperkitty web interface to send this email, as I
> cannot connect to my email from Thunderbird, sorry if the email is somewhat
> weird.)
tried a bunch of things to
get it working, and it seems that it is now? But the actual root cause
of the slowdown is still unknown. ;(
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To uns
ixes = True
in your dnf/yum/mock config.
From the dnf man page:
"Set this to True to disable module RPM filtering and make all RPMs from the
repository available. The default
is False. This allows user to create a repository with cherry-picked hotfixes
that are included in a package
set
rc --enablerepo
> epel-source,epel-testing-source --whatrequires oniguruma-devel
> jq
> ```
>
> Let me know your thoughts and concerns about moving forward with this.
+1 here and thanks for making epel a safer place.
kevin
signature.asc
Description: PGP signature
__
.6 to python 3.8?
But I guess python 3.6 is going to be maintained the entire life of
rhel7?
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le..
are identical -- not sure how it happens, maybe the
> committer has force-push permission? Or is there a way to request that a
> branch be cloned from another branch instead of created from scratch?
There's no force-push allowed. They likely just deleted it and are
merging master over it
On Thu, Apr 30, 2020 at 08:39:48PM -0600, Orion Poplawski wrote:
> Anyone willing to take over ngircd for EPEL?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1830182
Sure. I can do that. Will add it to my list.
kevin
___
epel-devel mai
clients and servers at
the same time so they can talk to each other. The existing backups you
have on disk will work with either version.
Does that help clarify any?
kevin
--
>
> Thanks-
>
> On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford
> wrote:
>
> > We have pushed
ription more for
testing?
Open to other ideas...
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.fedoraproject.org
Fedora Code of Conduct:
t testing for the
> usual time. If anyone has any problems, please let me know before the
> two weeks are up.
Seems fine to do to me...
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproj
On Tue, Mar 31, 2020 at 06:49:45AM -, Mattia Verga wrote:
> > On Sun, Mar 29, 2020 at 10:52 AM Kevin Fenzi >
> > Please file a bug in bugzilla, requesting both of these to be added to
> > EPEL8.
> > It's possible that we might need to use the older version f
;: {"channels": {"codeready-builder-for-rhel-8-aarch64-rpms":
[{"release": "17.el8", "epoch": "0", "versions": "2.32.1"},
kevin
signature.asc
Description: PGP signature
_
If someone else would like to work on it and make a PR, please feel free
to do 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.f
be best for you?
Perhaps we should make a https://whenisgood.net/ or whatever that fully
open source one is ( frame a date?), and let people vote for a week or
so?
kevin
signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.f
On Sat, Feb 15, 2020 at 05:17:01PM -0500, Matthew Miller wrote:
> On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote:
> > This is what I was trying to get to in the thread recently about
> > libssh2. However it's still not entirely clear to me.
> >
>
1 - 100 of 378 matches
Mail list logo
