DevHeads.net

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

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.

Heads up: /usr/bin/python moved to a separate package

<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

It has been done.

If you hit problems with automatic bytecompilation, see
<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

If you hit problems with python macros, see
<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

Heads up: /usr/bin/python moved to a separate package

<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

It has been done.

If you hit problems with automatic bytecompilation, see
<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_automatic_bytecompilation">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

If you hit problems with python macros, see
<a href="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros" title="https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate_package#Effect_on_.25_python_and_other_ambiguous_RPM_macros">https://fedoraproject.org/wiki/Changes/Move_usr_bin_python_into_separate...</a>

Python 3.7 on its way to rawhide

The merge of the f29-python side tag into rawhide has started.

Expect Python 3.7 in rawhide soon.

If your package will have broken dependencies (on Python 3.6), rebuild it.

If you cannot rebuild it due to dependencies not being rebuilt, (search
and) open bugs.

Make sure to block PYTHON37 [1] so we are aware of all the issues.

[1] <a href="http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37" title="http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37">http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37</a>

What is the criterion for Python 3.7 side tag merge?

The Python 3.7 rebuild in the f29-python side tag is currently:

- 2168 built
- ~170 FTBFS
- ~120 blocked by dependencies that FTBFS

Ideally, this would all get fixed before the merge, but that's
unrealistic, there are packages that are FTBFS for unrelated reasons, etc.

What is the criterion to merge the side tag?

The critpath installs fine (except stuff that cannot be installed due to
yum-deprecated vs yum collisions and gnome-software that has some broken
dependency on PackageKit).

Stuff that doesn't build and sounds important:

- ceph (also FTBFS in regular rawhide)
- libre

Nonresponsive maintainer: salimma

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

Does anyone know how to contact the maintainer?

Nonresponsive maintainer: kylev

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

Does anyone know how to contact the maintainer?

Nonresponsive maintainer: thomasvs

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

Does anyone know how to contact the maintainer?

Heads up: Python 3.7 rebuild in progress

I've just started to build the bootstrap sequence in a side tag
(f29-python).

This should not affect you mostly but if you have a Python 3 package and
you are going to update it with new buildtime dependencies, please let
me know or wait until this is done.

The initial order is in
<a href="https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml" title="https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml">https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml</a>

How to make DNS resolving fail early in mock?

Hi, since our Koji builds have disabled internet access, I want to do
the same, so I have more Koji consistent builds.

I have the following in /etc/mock/site-defaults.cfg:

config_opts['use_host_resolv'] = True # or False, no difference
config_opts['rpmbuild_networking'] = False

The internet doesn't work (desired), but has large timeouts (undesired).

This is especially tedious when building Python packages that use
intershpinx and they try to fetch stuff from the internet during build
(it fails, but that's OK). For each such request, the build is prolonged
for ~1 minute.

Seeking new OpenTK (co)maintainer (mono)

Hi, I maintain OpenTK as a direct dependency of RepetierHost (a 3D
printing tool using mono).

RepetierHost went closed source, but we maintain an older version which
was free software.

OpenTK FTBFS since F28. I have no resources to solve that, so I'm
looking for someone who has maybe better understanding of mono to take over.

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

If nobody volunteers, I will orphan both packages.

Thanks.

Intent to drop python2-notebook

python2-notebook is a leaf package (nothing in Fedora (build)requires
it). I'd like to drop it from rawhide. Any objections?

This **does not** affect the ability to run Jupyter Notebook (via the
jupyter-notebook command) with Python 2 kernel (from the
python2-ipykernel package).

Removing python2-tox (second attempt)

Hi all,

quite recently I've managed to remove the last thing that required
python2-tox: python-detox was switched to Python 3 [1].
So I went ahead and removed python2-tox [2].

However, I forgot to check buildrequires. I do apologize for that
overlook, apparently a couple of packages buildrequire python2-tox and
people were (rightfully) surprised by python2-tox being removed without
any notice [3].

So I added it back in [4]. Now I try to communicate this better.

"tox" the command is in python3-tox since Fedora 25.

Should boost package install boost-python2 / boost-python3 / both or none?

I was recently surprised that `dnf install boost` brings in python2.

It is like that because boost brings in bost-python and that is python2
ATM. I've reported it as a bug, because it bugs me :)

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

However Jonathan Wakely (the boost maintainer) says this needs broader
audience.

So I'm asking here on devel:

Should the 'boost' metapackage install boost-python at all? If so, what
versions?

Python 2 will be replaced with Python 3 in the next RHEL major release

Hi, see the deprecation notes for RHEL 7.5 [1]:

Python 2 has been deprecated
============================

Python 2 will be replaced with Python 3 in the next Red Hat Enterprise
Linux (RHEL) major release.

See the Conservative Python 3 Porting Guide [2] for information on how
to migrate large code bases to Python 3.

While this might have been obvious from the conditionals we have been
adding in some specfiles [3][4], this is AFAIK the first time this has
been publicly announced.

This is important for those who like to maintain a single spec for
everything.

License change: cura changed from AGPLv3+ to LGPLv3+

<a href="https://src.fedoraproject.org/rpms/cura/c/bb8dee5bb6c4e9d92918d96eac353d565c926441?branch=master" title="https://src.fedoraproject.org/rpms/cura/c/bb8dee5bb6c4e9d92918d96eac353d565c926441?branch=master">https://src.fedoraproject.org/rpms/cura/c/bb8dee5bb6c4e9d92918d96eac353d...</a>

Finalizing Fedora's Switch to Python 3

Hello fellow Fedora contributors,

We've created a page on Fedora wiki [1] that's something like a Change
proposal*.

The document is called "Finalizing Fedora's Switch to Python 3" and it
describes steps needed in order to:

* Switch /usr/bin/python to Python 3 in cooperation with Python upstream.
* Switch `dnf install python-foo` to install python3-foo.
* Hopefully eventually get rid of Python 2.

This is all planned to line with the fact that Python 2 will be dead
upstream by 2020.

The first phase of the changes is planned for Fedora 30, which is pretty
far away today, but the pr

s390x build failures

I'm hitting weird s390x build failures.

Koji says (almost immediately):

URLError: <urlopen error [Errno 111] Connection refused>

See a build here:
<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=20602824" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=20602824">https://koji.fedoraproject.org/koji/taskinfo?taskID=20602824</a>

s390x: <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=20602827" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=20602827">https://koji.fedoraproject.org/koji/taskinfo?taskID=20602827</a>

I got similar failures for several hours now. It took a while before an
error, but now the error is almost immediate.

Am I doing anything wrong?

Heads up: Retiring DevAssistant

Hello,

last bugfix release of DevAssisatnt [1] happened in September 2016, last
"major" release happened in April 2015. The project has not active
contributors, only me as a (very) low prio maintainer.

Users are experiencing problems with the assistants, as they are not
compatible with current Fedoras [2][3]. The test suite is broken [4] and
noone's going to fix that.

Given that, we are going to retire it from Fedora 26 and forward, as
this is clearly the "end of life" of DevAssistant.

Troubles with Python 3.6.1 in Fedora 26

There is and update of Python to 3.6.1 coming to Fedora 26 [1].
Due to a bug [2][3] tho following scenario might happen:

0. user has python3 3.6.0 and python3-foo-0.1-1
1. python3 3.6.1 is pushed to Fedora 26 stable
2. maintainer of python3-foo rebuilds the package to python3-foo-0.1-2
(this happens against python3 3.6.1) and pushes it to updates
3. user updates to python3-foo-0.1-2, but does not update python3
4. if the Python foo module meets certain conditions, it is broken
5.