Am 24.03.22 um 19:52 schrieb Carl George:
I found python-certbot-dns-google and python-certbot-dns-route53 that require
some of these packages. I did local mock builds using a custom one off
config comprised of RHEL8, RHEL8 HA, and EPEL8 with the above packages
excluded. The %check sections
Am 24.03.22 um 03:18 schrieb Carl George:
python-boto3-1.6.1-2.el8
python-boto3-1.15.15-1.el8
python-botocore-1.9.1-2.el8
python-botocore-1.18.15-1.el8
python-fasteners-0.14.1-14.el8
python-fasteners-0.14.1-20.el8
python-oauth2client-4.1.2-6.el8
python-oauth2client-4.1.3-9.el8
Hi,
I have submitted a review request [1] which passed ("fedora-review +") but
somehow the package git repo was not created. For Fedora packages this happens
pretty quickly after approval.
Any idea who I should ping about this?
Felix
[1]
Am 17.02.22 um 13:52 schrieb Stephen John Smoogen:
The working assumption has been that the Fedora package is already cleaned up
and dependencies are there because the main packager thought they were needed. I
and other EPEL packagers have spent enough time 'cleaning up' a package and then
+1
I'd like to highlight python3-nose and python3-mock. If your package depends on
one of these you should really fix your package and/or code upstream.
Felix
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an
Am 23.01.22 um 10:57 schrieb Nick Howitt via epel-devel:
A bit o/t, but will you be updating the python2-certbot-dns-* packages as well?
All certbot plugins currently in EPEL 7 will transition to Python 3 as well
(all packages will be in a single upgrade). So technically the Python 2
Hi,
the packaging guidelines have a few excemptions for the package review process
[1]. I'm working on updating certbot to Python 3 in EPEL 7 (rhbz 1797129,
[2]). I need some additional Python 3 packages in EPEL 7 to achieve that and
my question is which of these packages should get a proper
Am 11.05.21 um 06:45 schrieb kefu chai:
i pushed the updated libfmt v6 to EPEL7 as a fix of [1]. it upgraded
libfmt v3.01 to libfmt 6.2.1, and introduced a soname bump for
libfmt.so. so packages depending on libfmt should be rebuilt to pick
up the new library.
It would be helpful if you could
Hi,
I created a review request for python3-configobj which is needed to update
certbot in EPEL 7. (certbot now only supports Python 3).
The python3-configobj repo was used in Fedora (in ancient history) but I think
it can be "reused" to provide an EPEL7-only package.
Now my review request
Am 08.12.20 um 19:56 schrieb Japheth Cleaver:
With point releases, at least there was the possibility of flag days around EPEL
ABI changes, however with a rolling release format there seems to need to be an
active synchronization around such changes, as "expected" breakages aren't
really
Hi Troy,
thank you for the pointer and sorry if my tone was a bit harsh.
I filed also https://bugzilla.redhat.com/show_bug.cgi?id=1851642 - is that
the right place?
Felix
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
This morning I got an email notification:
Package Arch Version Repository Size
Am 04.06.20 um 07:07 schrieb Sérgio Basto:
> Please what ticket ?
I think Troy was referring to
"bodhi times out on update with many (almost 300) packages"
https://pagure.io/fedora-infrastructure/issue/8949
Felix
___
epel-devel mailing list --
Am 04.06.20 um 05:49 schrieb Kevin Fenzi:
> To clarify we knew it was having problems and tried a bunch of things to
> get it working, and it seems that it is now?
At least it worked for me. I was able to promote a few updates (single builds
but also an update with ~a dozen packages) to stable.
Am 01.06.20 um 17:25 schrieb Troy Dawson:
> I was having a similar problem last week, I opened a
> fed-infrastructure ticket and they extended the time out time. But it
> looks like things have gotten so bad that even that extended time
> isn't good enough.
> I have re-opened the ticket.
Thank
Hi,
I'm unable to submit updates to EPEL 7 stable:
$ bodhi updates request FEDORA-EPEL-2020-d8b45f1e30 stable
fedora.client.ServerError:
ServerError(https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d8b45f1e30/request,
504, Error returned from json module while processing
Am 24.05.20 um 11:49 schrieb Antonio Trande:
> Can i include all dependent packages without related permissions? (i'm
> not the maintainer of `R-argon2` `borgbackup` `gtkhash`)
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812
Yes. Submitting an update does not
Am 22.05.20 um 23:16 schrieb Felix Schwarz:
> We should push broken updates to EPEL 7/F31.
obviously this should read "We should NOT push broken updates" ;-)
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
Hey,
seems like you already built libb2?
I hoped we could coordinate the update a bit more so there won't be any
breakage. I just added buildroot override (still waiting for it to become
active) and I can rebuild borgbackup.
I hoped you could do the koji build and then dependent packages would
Am 16.05.20 um 19:39 schrieb Antonio Trande:
> `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a
> soname bump, so all dependent packages need to be rebuilt:
>
> $ repoquery --whatrequires libb2-devel --disablerepo=*
> --enablerepo=*-source
> R-argon2-0:0.2.0-8.fc32.src
>
Am 20.04.20 um 22:19 schrieb Dominik 'Rathann' Mierzejewski:
> Unfortunately, we don't have that many sponsors, and many of the
> existing ones are not very active. Please be patient.
Though my impression was that there are several Fedora sponsors who are
willing to sponsor new packagers. So
Hi Justin,
Am 12.04.20 um 03:40 schrieb Justin Coffman:
> There’s a bug currently open requesting that “tinyfugue” be packaged for EPEL
> 8.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1762158
>
> There hasn’t been any response to the original requestor since it was opened
> in October.
Am 10.04.20 um 13:40 schrieb Miro Hrončok:
> On 10. 04. 20 12:05, Felix Schwarz wrote:
>> What is the best way to get a Python 3 version for EPEL 7?
>
> Do a new package review request for an epel7 only package called
> python3-configobj that looks like:
Thank you for your ad
Hi,
I want to move certbot from Python 2 -> Python 3 in EPEL 7. As you might
imagine this means getting Python3 packages of all required libraries. Most of
them are pretty straight forward (I hope) - just build the Python 3 version
also on EPEL 7.
However there is python-configobj which is
Am 18.03.20 um 12:51 schrieb Antonio Trande:
> I'm going to update `msgpack` to the release 3.1.0 on EPEL7.
> It shouldn't provide a newer library version than the current 1.4.1 release.
Thank for the heads up.
Just to be sure - this does not affect python36-msgpack, right?
(otherwise I'd have
Am 09.01.20 um 00:03 schrieb Breno Brand Fernandes:
> It seems that the package was retired on 2019-02-11[1].
I think you need to follow the general un-retirement procedure:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
Felix
Am 26.11.19 um 02:07 schrieb Sérgio Basto:
> Seems we need to wait an amount of time to koji get synced with
> request, but how long we have to wait ?
Someone on IRC told me https://pagure.io/releng/issue/9041 is related to these
symptoms.
Felix
___
Am 03.11.2017 um 16:09 schrieb Stephen John Smoogen:
> OK how can we better explain this in the future?
I don't think there is an easy solution with "just another mail to -announce"
or so. Personally I don't find it really practical scanning a mailing list for
relevant packages (and filtering
Am 19.02.2016 um 16:53 schrieb Dave Johansen:
> But as was also mentioned, a lot of packages have jumped on the Chrome
> bandwagon with crazy release cycles and maintaining security fixes in those
> cases is basically impossible for a volunteer effort. From my perspective,
> having a policy that
Hey,
Am 25.01.2015 um 21:10 schrieb Till Maas:
Now it seems as if I have to do something to save a part of EPEL5's Python
stack from removal.
You can also just maintain the python packages. AFAIK nobody is really
forcing that python26 is removed from EPEL5, it is just a lack of
interest in
Am 22.12.2014 um 00:34 schrieb Sérgio Basto:
I don't maintain flumotion , I'm Awaiting Review (to have commit
rights), because I'd like update it to flumotion-0.10.1 or git master
version (pre 0.11.0), on rawhide we have flumotion-0.10.0 (released on
2011-10-10 )
The same thing applies for
31 matches
Mail list logo
