DevHeads.net

Postings by =?UTF-8?B?TWlybyBIcm9uxI1vaw==?=

Orphaned packages need new maintainers (will be retired in 3 weeks)

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for
sure that the package should be retired, please do so now with a proper
reason:
<a href="https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life" title="https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life">https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life</a>

Note: If you received this mail directly you (co)maintain one of the
affected packages or a package that depends on one.

How do I "release" a spin/lab?

When Fedora 29 was released, the Python Classroom Lab wasn't built.

The problem is now fixed:

<a href="https://koji.fedoraproject.org/koji/packageinfo?packageID=23847" title="https://koji.fedoraproject.org/koji/packageinfo?packageID=23847">https://koji.fedoraproject.org/koji/packageinfo?packageID=23847</a>

However how do i build and release it, so it is listed on:

<a href="https://labs.fedoraproject.org/" title="https://labs.fedoraproject.org/">https://labs.fedoraproject.org/</a>

And so that

<a href="https://labs.fedoraproject.org/python-classroom/download/index.html" title="https://labs.fedoraproject.org/python-classroom/download/index.html">https://labs.fedoraproject.org/python-classroom/download/index.html</a>

Doesn't list 404 links?

Thanks,

Upstream tip wanted: CI service for Big Endian acrhes

Recently I've reported some Big Endian related test failures to an
upstream project [0].

I was asked by an upstream project maintainer, whether I know some free
Continuous Integration services where they can easily run their
testsuite on Big Endian.

Any tips?

* Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
* Upstream uses AppVeyor to test on Microsoft Windows
* It's a pure Python project, noarch, but some changes need to be done
when loading/saving binary data (LE) with NumPy on BE system.

What I've considered:

* COPR (but there is no big endian arch)
* (Ab)using

Retired long orphaned Python 2 only packages

We have a policy for long orphaned packages that says if they are
orphaned for 6+ weeks, they are retired.

<a href="https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers" title="https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers">https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers</a>

Since the policy was not happening and is blocking our removal of Python
2 packages, I've just retired the following packages:

ambari
arm-none-eabi-gdb
enemies-of-carlotta
fedmsg-notify
gnome-hearts
metamorphose2
mMass
ntop
phatch
pyrasite
python-decoratortools
python-kid
python-myghty
python-pycallgraph
python-turbocheetah
python-turbokid
python-4Suite-XML
qmforge
recoverjpeg
rpm-ostree-toolbox
spacewalk-koan

GNOME/Icon themes expert help needed: Trash icon stopped showing up with "my" icon theme

Hi.

I got a bugzilla that says gnome-color-icon-theme fails to show empty
Trash icon.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1645368" title="https://bugzilla.redhat.com/show_bug.cgi?id=1645368">https://bugzilla.redhat.com/show_bug.cgi?id=1645368</a>

However apparently nothing changed in the package, hence I guess
something must have changed in GNOME. Is there anyone who can help me
understand and debug this?

Thanks,

Orphaned python2-astroid and python2-pylint

Hi,

I've just orphaned python2-astroid and python2-pylint.

I don't need them and I don't want to maintain legacy python2 packages.

Those are needed for python2-spyder, python2-asttokens,
python2-flake8-import-order. Please consider removing those, so we can
retire python2-astroid and python2-pylint. If you need to keep them,
please consider maintaining python2-astroid and/or python2-pylint.

Thanks,

Intent to drop python2-SecretStorage and python2-keyring in a week

Hi.

We are planning to update python-SecretStorage to a version that does
not support python2 [0][1].

Whoever needs python2-SecretStorage can add it as a separate package,
the spec is ready at [2].

Nobody from the current maintainers of dependent packages responded to a
request of maintainership (some said they don't need it).

python2-SecretStorage is needed by python-keyring and transitively for:

* supernova
* python-keystoneclient
* python-msrestazure
* python-oauth2client

I decided I won't package python2-SecretStorage just to orphan it
immediately.

Could not execute new_sources: Fail to upload files. Server returns status 403

Got this when I run `fedpkg new-sources`.

$ fedpkg --release master new-sources wheel-0.32.0.tar.gz
Could not execute new_sources: Fail to upload files. Server returns
status 403

What do i need to do?

I've rekinited, I've rerun `fedora-packager-setup`, `fedora-cert` tells
me it's not needed any more.

Is there something more I should do?

<a href="https://status.fedoraproject.org/" title="https://status.fedoraproject.org/">https://status.fedoraproject.org/</a> is all green.

Thanks,

Orphaned python2-matplotlib

I've orphaned python2-matplotlib.
Nobody replied to my previous heads up e-mails.

Heads Up: matplotlib 3 (no Python 2 support) in rawhide

We updated python-matplotlib to 3.0.0. It only supports Python 3. This
was done in Rawhide only.

The python2-matplotlib* subpackages were moved to a new SRPM,
python2-matplotlib (remains at 2.2.x), as plenty of cruft still needs
them :(

If you experience some relevant trouble (conflicts between packages,
blocked updates, unresolved deps, matplotlib not working, your plots
exploding...) please file bugs or let me know.

python2-matplotlib needs a maintainer. Volunteer at your local animal
shelter (e-mail me).

Heads Up: python2 is marked as deprecated

In line with the "Mass Python 2 Package Removal" Fedora 30 Change [0],
we've just marked python2 and all it's subpackages as deprecated in
rawhide [1].

No new packages can depend on python2 except renames and FESCo/FPC
exceptions. See more info in the Guidelines for Deprecating Fedora
Packages [2].

[0] <a href="https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal" title="https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal">https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal</a>
[1]
<a href="https://src.fedoraproject.org/rpms/python2/c/0052c9fa9d76e1706d96a17460ad26f331a4e0fe?branch=master" title="https://src.fedoraproject.org/rpms/python2/c/0052c9fa9d76e1706d96a17460ad26f331a4e0fe?branch=master">https://src.fedoraproject.org/rpms/python2/c/0052c9fa9d76e1706d96a17460a...</a>
[2] <a href="https://fedoraproject.org/wiki/Packaging:Deprecating_Packages" title="https://fedoraproject.org/wiki/Packaging:Deprecating_Packages">https://fedoraproject.org/wiki/Packaging:Deprecating_Packages</a>

Packages that need new maintainers

I've recently completed two nonresponsive maintainers policies.

<a href="https://pagure.io/fesco/issue/1971" title="https://pagure.io/fesco/issue/1971">https://pagure.io/fesco/issue/1971</a>
<a href="https://pagure.io/fesco/issue/1977" title="https://pagure.io/fesco/issue/1977">https://pagure.io/fesco/issue/1977</a>

Here are some packages that still need maintainers:

From <a href="https://pagure.io/fesco/issue/1971:" title="https://pagure.io/fesco/issue/1971:">https://pagure.io/fesco/issue/1971:</a>

2048-cli
ColPack
GarminPlugin
NLopt
RxCpp
appmenu-qt5
arprec
checksec
dreamweb
dynaplugz
f23-backgrounds
fedorainfinity-backgrounds
freetiger
fstransform
garmintools
git-extras
gnome-shell-extension-dash-to-dock
gnome-shell-extension-disconnect-wifi
gnome-shell-extension-refresh-wifi
gnome-shell-extension-suspend-button
gnome-shell-extension-unite
hardening-wrapper

pythonX no longer requires setuptools and pip

Hi, python3 no longer requires python3-setuptools and python3-pip;
python2 no longer requires python2-setuptools and python2-pip.

Those are just recommended. If you need them at build time, BR them.

+ /usr/bin/python2 setup.py build '--executable=/usr/bin/python2 -s'
Traceback (most recent call last):
File "setup.py", line 5, in <module>
from setuptools import setup
ImportError: No module named setuptools

There will be no virtualenv-2 and virtualenv-3, just virtualenv

We used to have /usr/bin/virtualenv-2 and /usr/bin/virtualenv in
python2-virtualenv. /usr/bin/virtualenv-3 in python3-virtualenv.

As of <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1599422" title="https://bugzilla.redhat.com/show_bug.cgi?id=1599422">https://bugzilla.redhat.com/show_bug.cgi?id=1599422</a> this will
change on F29+.

Intent to retire python modules

I'm going to retire (in a ~week):

<a href="https://src.fedoraproject.org/modules/python" title="https://src.fedoraproject.org/modules/python">https://src.fedoraproject.org/modules/python</a>
<a href="https://src.fedoraproject.org/modules/python2" title="https://src.fedoraproject.org/modules/python2">https://src.fedoraproject.org/modules/python2</a>
<a href="https://src.fedoraproject.org/modules/python2-bootstrap" title="https://src.fedoraproject.org/modules/python2-bootstrap">https://src.fedoraproject.org/modules/python2-bootstrap</a>
<a href="https://src.fedoraproject.org/modules/python2-ecosystem" title="https://src.fedoraproject.org/modules/python2-ecosystem">https://src.fedoraproject.org/modules/python2-ecosystem</a>
<a href="https://src.fedoraproject.org/modules/python3" title="https://src.fedoraproject.org/modules/python3">https://src.fedoraproject.org/modules/python3</a>
<a href="https://src.fedoraproject.org/modules/python3-bootstrap" title="https://src.fedoraproject.org/modules/python3-bootstrap">https://src.fedoraproject.org/modules/python3-bootstrap</a>
<a href="https://src.fedoraproject.org/modules/python3-ecosystem" title="https://src.fedoraproject.org/modules/python3-ecosystem">https://src.fedoraproject.org/modules/python3-ecosystem</a>

This is f28 cruft from the "older modularity". Not used, not needed.
Correct me if I'm wrong.

Intent to drop python2-behave

There is a cluster of PRs:

<a href="https://src.fedoraproject.org/rpms/python-behave/pull-request/2" title="https://src.fedoraproject.org/rpms/python-behave/pull-request/2">https://src.fedoraproject.org/rpms/python-behave/pull-request/2</a>
<a href="https://src.fedoraproject.org/rpms/python-docx/pull-request/2" title="https://src.fedoraproject.org/rpms/python-docx/pull-request/2">https://src.fedoraproject.org/rpms/python-docx/pull-request/2</a>
<a href="https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2" title="https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2">https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2</a>

That allows us to drop python2-behave as nothing will depend on it.

I'm giving one week notice here.

I intent to orphan barman

I recently got <a href="https://src.fedoraproject.org/rpms/barman" title="https://src.fedoraproject.org/rpms/barman">https://src.fedoraproject.org/rpms/barman</a>

I will orphan it in a week if nobody wants it.

Nonresponsive maintainer: Luke Macken (lmacken)

Luke Macken (lmacken) is not responsive.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1610474" title="https://bugzilla.redhat.com/show_bug.cgi?id=1610474">https://bugzilla.redhat.com/show_bug.cgi?id=1610474</a>

Anyone knows how to contact the maintainer?

Nonresponsive maintainer: Björn Esser (besser82)

Björn Esser (besser82) is not responsive.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1610811" title="https://bugzilla.redhat.com/show_bug.cgi?id=1610811">https://bugzilla.redhat.com/show_bug.cgi?id=1610811</a>

Anyone knows how to contact the maintainer?

Nonresponsive maintainer: Dale Macartney (dbmacartney)

Dale Macartney (dbmacartney) is not responsive.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1608306" title="https://bugzilla.redhat.com/show_bug.cgi?id=1608306">https://bugzilla.redhat.com/show_bug.cgi?id=1608306</a>

Anyone knows how to contact the maintainer?

HEADS UP: /usr/bin/cython(ize) is now in python3-Cython

Cython-0.28.4-3.fc29 has landed in rawhide.

It moves all stuff in /usr/bin to pytyon3 package only, because the
functionality is the same on whatever Python version.

This might break your package if you BR Cython.

Here are some tips that should be Fedora/EPEL version agnostic:

If you need to use /usr/bin/cython (or /usr/bin/cythonize) during build,
BR /usr/bin/cython (or /usr/bin/cythonize).

If you need to use Cython from Python (from cython import...), BR
pytnonX-Cython or pythonXdist(cython) (for X={2,3} as needed).

If you would like to use Cython from the command line and explicitl

Why are we shipping debug builds of pythons?

Hi,

an interesting discussion came up in the Python Maint team recently,
about not shipping python3-debug and python2-debug.

On the Chesterton's fence principle [0], I'd would like to know why are
we building and shipping them before we have a discussion about their
removal to save build time and remove packaging cruft.

Anyone has an idea?

Changes in packages workflow vs. modular Fedora

Hi,

I was thinking about this for a while and I got the impression that this
is something I don't know the answer for. The question is a bit harder
to formulate simply, so let put it in examples:

a) A need packaging guideline is about to be discussed.

python-pip license changed (and clarified)

python-pip 9.0.x had MIT as License (bundled deps were not mentioned)

python-pip 18.0 now has more enjoyable:

MIT and Python and ASL 2.0 and BSD and ISC and LGPLv2 and MPLv2.0 and
(ASL 2.0 or BSD)

License breakdown is in the specfile.

HEADS UP: pip upgraded from 9 to 18 (rawhide only)

I've just built python-pip-18.0-1.fc29.

It has a lot of breaking changes, so please file bugs if you have
problems. We do not plan to upgrade pip in stable Fedora releases.

Release notes: <a href="https://pip.pypa.io/en/stable/news/" title="https://pip.pypa.io/en/stable/news/">https://pip.pypa.io/en/stable/news/</a>

See notes for 18 and 10, as we skipped 10.

Note that upstream changed version scheme, nothing existed between 10
and 18.

Thanks,

koschei build gone?

Hi,

I've filled this bugzilla: [0] and I clearly remember seeing a failed
build in koschei - I've even linked it in the BZ [1].

Yet the URL now returns 404.

Last build in koschei for python3 is 3 days older than the bugreport.

What happens? Are certain builds deleted for various reasons? Or are we
loosing some data by accident?

[0] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1609291" title="https://bugzilla.redhat.com/show_bug.cgi?id=1609291">https://bugzilla.redhat.com/show_bug.cgi?id=1609291</a>
[1] <a href="https://apps.fedoraproject.org/koschei/build/5052601" title="https://apps.fedoraproject.org/koschei/build/5052601">https://apps.fedoraproject.org/koschei/build/5052601</a>

"Orphan packages will be retired if they remain orphaned for six weeks"

Is $subj [1] an automated or manual process? Shall I retire packages
I've orphaned before more weeks or just wait?

[1]
<a href="https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers" title="https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers">https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers</a>

Packages needlessly use __provides_exclude_from on python sitearch

There are 56 packages that use something like this:

%global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$
%global __provides_exclude_from ^(%{python2_sitearch}/.*\\.so)$
%global __provides_exclude_from ^(%{python3_sitearch}/.*\\.so)$
%global __provides_exclude_from
^(%{python2_sitearch}|%{python3_sitearch})/.*\\.so$
...

and 68 like this:

%filter_provides_in %{python_sitearch}/whatnot/.*\.so$
%filter_provides_in %{python2_sitearch}/.*\.so$
%filter_provides_in %{python2_sitearch}/.*\.so$ %{python3_sitearch}/.*\.so$
...

The full list can be obtained by:

$ rg '(filter_provides_in|__

Intent to orphan: perl-Mail-DKIM and python-beaker

Anybody who wants perl-Mail-DKIM (needed by amavisd-new, spamassassin)
before I orphan it?

Anybody who wants python-beaker (needed by TurboGears2, python-pylons,
previously also python-mako) before I orphan it? This one FTBFS on
Python 3.7.

Let me know. I'll orphan the packages in a week.

Schedule for Thursday's FPC Meeting (2018-07-05 16:00 UTC)

Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-07-05 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

Local time information (via.