[Bug 1415190] Review Request: python-onionbalance - Load-balancing for Tor onion services

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1415190

Simone Caronni <negativo17@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|fedora-review?              |fedora-review+



--- Comment #5 from Simone Caronni <negativo17@xxxxxxxxx> ---
(In reply to Marcel Haerry from comment #3)
> Well if I read
> https://fedoraproject.org/wiki/Packaging:Python#Python_Version_Support
> 
> then I understand it that the default target is Python 3 and Python 2 is
> nice-to-have.

Ok, I missed that, sorry. Then I would say your approach is perfectly fine.

> I also thought about only building a python3 version for Fedora and a python
> 2 version for EPEL.
> 
> So I would suggest to then build only the python3 version.

Then yeah, I would say so.

> The problem is, that the version of sphinx in EPEL 7 is not new enough to
> build the man pages. That's why I excluded them.

Fine, you can still add them later if the code comes in to build with an older
sphinx.

> How would you go forward in such a case? From the update guidelines, I think
> it's not feasible to get the new version sphinx in EPEL, as it has breaking
> changes, afair.

It was decided (don't know exactly when) that it was ok also to rebase stuff in
EPEL (for example Nagios jumped from 2 to 4). After all, RHEL itself contains
huge rebases of everything (DRM, X and libraries, the whole GNOME, libvirt and
friends).

If you can push the changes and update all the various components, then fine.
Maybe I can help you there.

If your rebases require touch in RHEL packages, then you need a customer
account (hint!) to get stuff changed, normal bugzilla tickets are rarely taken
into consideration.

> I need to look into that one more in detail before being able to do a new
> test build. Nevertheless, we can already discuss the situation above.

I think all your points are valid. Just make the python 3 only version in
Fedora and the python 2 version only in EPEL 7 without the man pages.

(In reply to Marcel Haerry from comment #4)
> Ok, so the latest python-sphinxcontrib-autoprogram version (updated today in
> rawhide) has a bug that makes it not working on python 2:
> https://bitbucket.org/birkenfeld/sphinx-contrib/issues/168/autoprogram-013-
> fails-on-python-27-due-to
> 
> I can backport the fix to the autoprogram package first, but this is only
> urgent if we want to keep the build of the python2 package.

Well, in this case, just build the package for Fedora with python 3, but
request all branches including epel 7 even if at the moment you can't build the
package. You can always work on it later or in subsequent upstream releases.

Package approved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]