DevHeads.net

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

Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

Today I've attempted to run "dnf upgrade".

It has the following in it:

Upgrading:
protobuf x86_64 3.6.1-6.module_f31+6793+1c93c38e updates-modular

Enabling module streams:
ant
eclipse
maven

I don't consider this behavior adequate for a released Fedora version.

As a maintainer of dependent packages (Cura stack) I have tested and built it
against the nonmodular protobuf. What just happened here and how do I track it down?

dnf doesn't even tell me what module is this in. I suppose eclipse.

However, protobuf was not mentioned in <a href="https://pagure.io/fesco/issue/2285" title="https://pagure.io/fesco/issue/2285">https://pagure.io/fesco/issue/2285</a>

Should we discontinue the Python Classroom Lab?

Hello,

I'd like to know whether it makes sense to continue maintaining and producing
the Fedora Python Classroom Lab.

It has problems:

- no issue tracker, I don't even know if there are users with issues
- there has simple been close to zero feedback, maybe nobody uses this?

- the website is horribly outdated: <a href="https://pagure.io/fedora-websites/issue/962" title="https://pagure.io/fedora-websites/issue/962">https://pagure.io/fedora-websites/issue/962</a>

- some Fedora versions weren't built:
- I wasn't notified when F29 wasn't built
- there was no way to get it fixed ex-post
- <a href="https://pagure.io/releng/issue/7922" title="https://pagure.io/releng/issue/7922">https://pagure.io/releng/issue/7922</a>

- Docker is broken
- one of the main ideas was t

Orphaned packages looking for new maintainers

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.

List of long term FTBFS packages to be retired in February (beta)

Dear maintainers.

Based on the latest fail to build from source package, the following packages
will be retired from Fedora 32 approximately one week before branching (February
2020).

Policy:
<a href="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/" title="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/">https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fa...</a>

The packages in rawhide were not successfully built at least since Fedora 30.

This report is based on dist tags and represents a preliminary list of packages.

Packages collected via:
<a href="https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb" title="https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb">https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/f...</a>

The main purpose is to gather feed

Orphaned packages looking for new maintainers

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.

Orphaned hamcrest

I have just orphaned hamcrest, based on the wishes of the maintainer.

If you want it, open a releng ticket:

<a href="https://pagure.io/releng/new_issue?template=package_unorphan&amp;title=Unorphan%20hamcrest" title="https://pagure.io/releng/new_issue?template=package_unorphan&amp;title=Unorphan%20hamcrest">https://pagure.io/releng/new_issue?template=package_unorphan&amp;title=Unorp...</a>

What are the benefits of default modular streams over non-modular packages?

Hello, in this thread (Fedora 32 System-Wide Change proposal: Modules in
Non-Modular Buildroot)

<a href="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/JNTMUOBZHHCEOV7KS7MRNOBO6VGGT7RX/" title="https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject.org/message/JNTMUOBZHHCEOV7KS7MRNOBO6VGGT7RX/">https://lists.fedoraproject.org/archives/list/ ... at lists dot fedoraproject....</a>

I've asked whether it wouldn't be in fact much easier to keep the default
versions of our packages non-modular.

Others have said they are interested in this as well.

Orphaned packages looking for new maintainers

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.

Will orphan packages with NEW F31FTBFS bugs tomorrow

According to the policy for packages that fail to build from source:

<a href="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/" title="https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/">https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fa...</a>

I plan to orphan packages with NEW Fedora 31 Fail To Build From Source bugzillas
tomorrow.

By doing so, we notify the dependent package owners that something is wrong with
their dependency before it is removed.

Orphaned packages can be unorphaned without any damage.
When the packages stay orphaned for 6+ weeks, they will be retired.
Retired packages can be unretired.

Python Annual Release Cycle adjusted to match odd-numbered Fedora releases

Hello,

I'd like to inform you that [PEP 602] "Annual Release Cycle for Python" has been
approved and [PEP 596] "Python 3.9 Release Schedule" is pending approval:

tl;dr New Python 3.X versions will be released annually, with RC period adjusted
to make it possible to update Python in odd-numbered Fedora releases. We plan to
submit the Python 3.9 change proposal for Fedora 33 after the first Python 3.9
alpha (expected in ~2 weeks).

The Python 3.8 update was postponed from Fedora 31 to Fedora 32 because the
schedule was too tight.

Getting notified on broken deps from updates-testing

Hello,

it repeatedly happened to me that I'm notified by Koschei that dozens of my
packages suddenly fail to resolve build dependencies on a released Fedora.

I usually find out that the broken update was sitting in testing for 7 days
without any feedback, only to be pushed and receive ex-post feedback from me.

Is there any good way to get notified about this sort of problems in timely
manner prior to the update being pushed? This is currently not optimal.

Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

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.

Summary/Minutes from today's FESCo Meeting (2019-11-04)

=====================================
#fedora-meeting-1: FESCO (2019-11-04)
=====================================

Meeting started by mhroncok at 15:01:36 UTC. The full logs are available
at
<a href="https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-04/fesco.2019-11-04-15.01.log.html" title="https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-04/fesco.2019-11-04-15.01.log.html">https://meetbot.fedoraproject.org/fedora-meeting-1/2019-11-04/fesco.2019...</a>
.

Meeting summary
* Next week's chair (mhroncok, 15:14:05)
* ACTION: jforbes will chair next meeting (mhroncok, 15:16:20)

* Open Floor (mhroncok, 15:16:26)
* ACTION: everybody, please try to vote on tickets in pagure if you
haven't already.

List of Python 2 packages to be removed mid-November

Dear maintainers,
here is a list of packages that (transitively, at build or run time) require
Python 2 and have not yet got a FESCo exception to do so.
If you were bcced on this e-mail, it affects one or more of your packages.

The default action will be to remove such packages mid-November.

If this took you by surprise, don't panic. It's possible to change the default.
Let us know and we'll work things out.
The mid-November deadline is not for removing *all* of Python 2, but for getting
exceptions.

If you are already working to port to Python 3, sorry for the spam!

How to figure out why is Python 2 in critpath

I've recently updated Python 2 to the penultimate release for Python 2.7:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d3fcae639" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d3fcae639">https://bodhi.fedoraproject.org/updates/FEDORA-2019-0d3fcae639</a>

Bodhi tells me that Python 2 is in criptpath in Fedora 31. That almost gave me a
heart attack. I've checked in PDC and indeed it is

Orphaned python-ripozo

Hey,

Some time ago, I've packaged python-ripozo because I thought it's useful.

However it's just a Python library nothing in Fedora uses and I don't have any
interest and time to maintain such packages any more.

I've orphaned it.

Orphaned packages looking for new maintainers

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.

Updates to the FTBFS policy

Hello,

after the recent discussions, the Fedora's "Fails to Build From Source" policy
[0] has been updated [1][2].

The changes include:

## The policy no longer requires e-mails to devel to orphan a package

This requirement made automation hard and resulted in most of the packages never
being orphaned because almost nobody did this.

Do F31 updates not obsolete each other during freeze?

Hey, I've just noticed something that I find a bit odd:

This python38 update is on it's way to f31 stable:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c">https://bodhi.fedoraproject.org/updates/FEDORA-2019-c26f535d3c</a>

This newer python38 update was submitted yesterday:

<a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-adde83b6b7" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-adde83b6b7">https://bodhi.fedoraproject.org/updates/FEDORA-2019-adde83b6b7</a>

...but it has not obsoleted the previous one.

Is this correct during freeze? What happens if both updates are set to "pushing
to stable" and we unfreeze? Is it possible that the older update will be tagged
later than the first one?

Orphaned packages looking for new maintainers

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.

Intent to replace bzr (bazaar) with brz (breezy)

Hello,
bzr (bazaar) FTBFS and is orphaned.

I have a Python 3 replacement called breezy (brz) ready, but it has some
problems with remote repositories on Python 3.8, so I was not ready to build it,
obsolete bzr and have a broken alternative.

However, bzr now also fails to install, so it cannot be any more broken than it
already is.

This update's test gating status has been changed to, 'greenwave_failed'.

Couple of my updates have e-mailed me $subj. Is it something to worry about?

Example: <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-f2ffe568a1" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-f2ffe568a1">https://bodhi.fedoraproject.org/updates/FEDORA-2019-f2ffe568a1</a>

Intent to orphan python-unittest2

Hello mostly Bcced maintainers of packages impacted by this.

I maintain python-unittest2, a backport of the standard library unittest module
from Python 3 to Python 2 (mostly) [1].

We are removing python2-unittest2 soon, as nothing depends on it any more [2].

I'd retire the package, as it makes no sense on Python 3, however there are
packages that use python3-unittest2 for various invalid reasons.

The proper action is to fix the packages to use unittest from the standard
library, but I lack the energy to coordinate that, so i just decided to just
orphan it.

That said, if you want my h

HEADS UP: Rawhide rebuild of Python packages with old bytecode version

Hello,
Python packages built with Python < 3.8.0b4 have invalid bytecode version,
because the version was updated in 3.8.0b4.

To see why this is a problem, follow the bugreport:

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

We were waiting for 3.8.0rc1 to see if the version is not updated once more.
It was not.

After rc1 hits the f32 buildroot we will mass bump and rebuild all Python
packages that still have the old bytecode.

The list of packages based on data from Monday (to be updated):

2ping
5minute
APLpy
ATpy
Cython
GitPython
Mayavi
NLopt
OpenIPMI
OpenLP
ProDy
PyDrive
PyGreSQ

Orphaned packages looking for new maintainers

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.

Schedule for Thursday's FPC Meeting (2019-09-26 16:00 UTC)

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

Local time information (via.

Join the package collection maintainers: Visit src.fp.o to request rights?

I was recently contacted by a fellow Fedora contributor about this.

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

I think this is not true, but what to say instead?

Orphaned tagsoup

tagsoup was maintained byt he Stewardship SIG and is no longer required by any
of our packages. I have orphaned it.

I don't know much about the package, but several other Java stuff requires it:

icedtea-web-0:1.8.2-3.fc31.src
icedtea-web-0:1.8.2-3.fc31.x86_64
javadocofflinesearch-0:2.2-9.fc31.noarch
javadocofflinesearch-0:2.2-9.fc31.src
xom-0:1.2.10-13.fc31.src

It was updated to the current 1.2.1 version in 2012 and upstream has either
moved or died.

Orphaned packages looking for new maintainers

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.