Hi,
I need some help to fix a bug ¹ with python3 and site-packages.
> cd /usr/lib/python3.4/site-packages/krop/
> python2 -c 'import krop ; krop.main()'
→ dialog
> python3 -c 'import krop ; krop.main()'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python3.4/site-packages/krop/krop.py", line 25, in main
formatter_class=RawTextHelpFormatter)
TypeError: __init__() got an unexpected keyword argument 'version'
Besides that error, the start script in %{_bindir}/krop is b0rken and should just work for users clicking on the desktop icon.
¹ https://bugzilla.redhat.com/show_bug.cgi?id=1321376
I've applied to the python-sig FAS group and mailing list. According to
[SIG page] I also need to introduce myself, so here goes:
Hello!
I'm the keeper of [PortingDB], team lead in Red Hat's Python Maintenance
team, and I'm generally interested Python in Fedora. Please let me in? :)
[PortingDB] http://fedora.portingdb.xyz/
--
Petr Viktorin
Hello all,
Before going further, please note this is a cross-posted thread! There
is a low-traffic mailing list, logistics(a)lists.fedoraproject.org, which
was created for multi-list collaboration on things like this topic. To
centralize discussion, please consider using that list for replies (even
if you unsubscribe after the discussion finishes).
Anyways, assuming all goes according to plan, the F24 Beta is due to
land on May 3rd, or in seven days from today. Therefore, it's time to
review and look over the release notes for the F24 Beta. The current
draft can be found on the wiki.
https://fedoraproject.org/wiki/F24_Beta_release_announcement
As of now, it is a forked version of the Alpha release announcement with
a few changes based on information I gathered from #fedora-qa. If you
could take some time to review the release notes and ensure everything
is *current* and correct since the Alpha release for areas you are
familiar and knowledgeable with, that would be appreciated so we can aim
to ship this next week.
Thanks all!
--
Cheers,
Justin W. Flory
jflory7(a)gmail.com
Jonathan Underwood <jonathan.underwood(a)gmail.com> schrieb am Mo., 18. Apr.
2016 um 12:04 Uhr:
> On 18 April 2016 at 08:06, Thomas Spura <tomspur(a)fedoraproject.org> wrote:
> > Any help on reviewing new packages for ipython/jupyter and
> (co-)maintaining
> > the ipython stack is welcome. Are there any volunteers? :)
>
>
> Am happy to help review packages, and will have a window of time in
> the coming two weeks where I'll have more time than usual :). Is there
> any kind of tracking bug set up for this?
>
I just added a few review requests and the one for the notebook could serve
as the tracking bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1327979
It seems jupyter-core has no further dependencies and could be reviewed
first:
https://bugzilla.redhat.com/show_bug.cgi?id=1327994
Thanks for joining the jupyter party! :)
Thomas
Philippe Makowski <makowski.fedora(a)gmail.com> schrieb am So., 17. Apr. 2016
um 19:29 Uhr:
> Hi,
>
> just in case, I started to package ipython 4 and Jupyter in Mageia..
> my progress is there https://wiki.mageia.org/en/User:Philippem
>
> may be it could help for Fedora.
>
Thank you for your effort. It is of help to see which packages in Fedora
need new reviews.
> For help, I saw also that Debian started the work too.
>
Any help on reviewing new packages for ipython/jupyter and (co-)maintaining
the ipython stack is welcome. Are there any volunteers? :)
Best,
Thomas
Hello all,
It's been a while since I messaged this list about the new dependency
generator being upstreamed into RPM[0]. Since then, I've taken your
valuable feedback and incorporated it into the version that now sits
in RPM git master[1].
A little bit ago, I pushed a package to Copr[2] that includes this
updated dependency generator, and I would love for people to take a
look at it, try it out, and see how well it works. Instructions on
setting up and configuring are on the Copr page.
I'd also love this become enabled in Fedora's Python stack for Fedora
25, giving us nice Provides/Requires chains that are independent of
the package name, but map more closely to PyPi names that people would
recognize from using pip or other tools.
We already have similar things in place for Ruby, Mono, Perl, and even
MinGW in Fedora, so it'd be nice to have it on the Python side, too.
Best regards,
Neal
[0]: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj…
[1]: https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondi…
[2]: https://copr.fedorainfracloud.org/coprs/ngompa/rpm-depgen-pythondistdeps/
--
真実はいつも一つ!/ Always, there's only one truth!
On 02/04/16 13:58 +0200, Jan Pokorný wrote:
> On 02/04/16 12:26 +0200, Jan Pokorný wrote:
>> On 31/03/16 21:28 -0600, Orion Poplawski wrote:
>>> I've just submitted
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
>>>
>>> This update does two things:
>>>
>>> - Updates python to version 2.7.11
>>> - Splits out the python macros into separate packages
>>>
>>> It would be helpful if packagers would try building python packages with
>>> these packages installed.
>>
>> This might be the cause of a recent failure to build Pacemaker while
>> other Fedoras (24 + 25) were OK:
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=13522053
>>
>> See
>> https://kojipkgs.fedoraproject.org//work/tasks/2053/13522053/mock_output.log
>>
>>> Package python-macros is obsoleted by python-rpm-macros, but
>>> obsoleting package does not provide for requirements
>
> Subsequent build succeeded, though:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=750257
>
> So it must have been an intermittent issue.
> Can this be prevented next time a basic build dependency
> is restructured? Or would it require additional support
> in the build infra?
I tried to investigate this a little bit.
6 days ago, at around the point the build failed, several overrides
for the build root have been requested:
python-rpm-macros-3-7.fc23:
https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-7.fc23
redhat-rpm-config-36-1.fc23.1:
https://bodhi.fedoraproject.org/overrides/redhat-rpm-config-36-1.fc23.1
python-2.7.11-2.fc23:
https://bodhi.fedoraproject.org/overrides/python-2.7.11-2.fc23
All but the last, expired on 2016-04-01, appear active at the moment.
The last one was superseded with python-2.7.11-3.fc23:
https://bodhi.fedoraproject.org/overrides/python-2.7.11-3.fc23,
which is also active right now.
But clearly, at the moment of the linked build that failed,
python-rpm-macros and redhat-rpm-config were overridden whereas
python-macros-2.7.10-8.fc23+ wasn't. It looks to me I hit a racy
window in which python-2.7.11-2.fc23 override hasn't yet been
applied.
And later, at the moment of the linked build that succeeded,
no such override was active.
I would conclude, please be more careful about management of
overrides to prevent this kind of mess-ups.
Does bodhi allow to specify several builds as a means of an atomic
(non-racy) override? Should I file a RFE for that if not?
--
Jan (Poki)
I've just submitted
https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
This update does two things:
- Updates python to version 2.7.11
- Splits out the python macros into separate packages
It would be helpful if packagers would try building python packages with
these packages installed.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com