Non-responsive maintainer - Mosaab Alzoubi
by Vitaly Zaitsev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello!
According Non-responsive Maintainer Policy I'm asking the maintainer
to respond second time and resolve issues with package goldendict.
RHBZ tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1667084 and
https://bugzilla.redhat.com/show_bug.cgi?id=1594569
Proposed PR with fix:
https://src.fedoraproject.org/rpms/goldendict/pull-request/1
- --
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEGFSlHDlYR1Xq8pxov5n8bdRauQoFAlxEPjsACgkQv5n8bdRa
uQpOLhAAlqcuEaRpsKkdO27Qi3XIq6BH2cmUzshQKqW98uYoP3QxepI2X1jaZ5sJ
IbbROzvu2ZyOQYlWAecV1LSNgO9zDuHSC2SKhOThGa5HguGZJRtrCyILLU0w3IeD
cCOpRaTy1Zg1MfaqsEqb9bZe/Fz7dzOpuVTE2HQ/YDDlwe6iA1iqAIpD1CBK2yNT
qcghrpQQtZweFb72fbPbSgnE8k4GBvzYaTtbxxP1ZaXoiZqKTgwUFrFVecT9+CuR
/5ffcFh38o4mb1pP8c0VjJCioSv9qf7achY0IlaZhQsC7XB+VkUH11hdoKlUC1az
9Ws8g+DFHB0Z8roUBrSQWM2hX8m+jPQqTAjE5QtGgdveggdUvII7dMIIbSLjr3hw
/SrfKin6ALNvanumma02eZw93tv+YXR+uvT1HzMC/iaFwoclbFMsbUYn5gbr4viR
ukJLJgN/L1w/NNI63BU3JYsuH9LC9GOY/bmyeK4w1L7zkIdL3atCyUv2QrJ+JI4e
IXvmO6eIwJOENLcT9D8YUA6GSftE4nUeiWU7QT02/51vm6BLJSu53KiW8BMtD0Ij
W5+oltdb6X0PRm+mzDfkgweh1kn26bHCMTM/SZUVtKxPHVHW6VYKombXDtJgwbDt
BLTdGcGKBhCpcdr41EWt8BzzzcnQMnJIXNQwCThccYtXyAJn9zA=
=fkRA
-----END PGP SIGNATURE-----
5 years, 2 months
Re: Unannounced soname bumps: proj and geos
by Elliott Sales de Andrade
Hi,
On Tue, 5 Feb 2019 at 17:12, Devrim Gündüz <devrim(a)gunduz.org> wrote:
> Hi,
>
> On Mon, 2019-02-04 at 21:09 -0500, Elliott Sales de Andrade wrote:
> >
> > The recent bump of proj in Rawhide from 4.9.3 to 5.2.0 also bumped the
> > soname from libproj.so.12 to libproj.so.13.
> > The bump of geos in Rawhide from 3.6.1 to 3.7.1 also bumped the soname
> > from libgeos-3.6.1.so to libgeos-3.7.1.so.
> >
> > These bumps should be announced *before* the build has been made.
>
> Apologies, that was me. I forgot the process.
>
> > Fortunately, as I was already investigating the possibility of
> > updating proj,
>
> Yay!
>
> > I have the list of proj-dependent packages already. I
> > was not looking at geos, but hopefully the list below includes
> > everyone. I have CC'd maintainers on the list to notify them that they
> > will need to rebuild their packages (or I can do it myself at some
> > point if they're busy.)
>
> I am working on it. Fixed libgeotiff, libspatialite ,ogdi. gdal, GRASS and
> PostGIS so far.
>
Thanks for taking care of these. I was able to rebuild my packages as
well without issue, and I see a few others were done by other
maintainers.
There are still six left that have not been rebuilt: perl-PDL,
shapelib-tools, spatialite-gui, merkaartor, qlandkartegt, saga. I may
build these if the maintainers do not get to it before the branch
point or beta freeze.
And two that were rebuilt but seem to be FTBFS anyway: mapserver, xastir.
PS, can you also take a look at my PRs that enable the test suite and
add the optional datum grids:
https://src.fedoraproject.org/rpms/proj/pull-request/4
https://src.fedoraproject.org/rpms/proj/pull-request/5
> Regards,
> --
> Devrim Gündüz
> Open Source Solution Architect, Red Hat Certified Engineer
> Twitter: @DevrimGunduz , @DevrimGunduzTR
--
Elliott
5 years, 2 months
MBI (Playground 2.0)
by Igor Gnatenko
MayBe I …(can do something useful)?
Hello,
We've been discussing some (hopefully) nice idea with Mikolaj, Neal and
Jakub how we could improve packager (and user) experience and we have some
proposal which will be described below.
We would like to ask you to read it, understand it and ask us any questions
you have. From the Fedora Infrastructure we would like to ask for some
machines to implement this idea (you can find some more information in
"Implementation details" part).
I would like to apologize for HTML email, but it is much easier to have it
that way to have better visibility and reading easiness.
Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners
-
Mikolaj Izdebski (mizdebsk) <mizdebsk(a)redhat.com> - Java SIG, Fedora
infrastructure
-
Igor Gnatenko (ignatenkobrain) <ignatenkobrain(a)fedoraproject.org> - Rust
SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor
-
Neal Gompa (ngompa) <ngompa13(a)gmail.com> - Rust SIG, Golang SIG, RPM
contributor
-
Jakub Čajka (jcajka) <jcajka(a)fedoraproject.org> - Golang SIG, Container
SIG
This proposal aligns with the objective of improving the packager experience
<https://fedoraproject.org/wiki/Objectives/Packager_Experience> by
developing a platform whereby the proposal owners and others can experiment
with improvements that can be funneled back into the official production
infrastructure.
ProblemsProblem №1: Build-only packages
Some ecosystems have many build-only packages (packages which are used to
build other packages, without having them installed on end-user systems).
Those ecosystems include Java, Rust and Go.
It is extremely hard to keep up maintaining them due to lack of
time/people. Upstreams are usually changing quickly (sometimes when you
update just one such package, you’d need to update tens of the
dependencies). Few facts about such packages:
-
They are almost always outdated in released versions of distribution;
-
They are often FTBFS (e.g. because there was compiler update but not
package update, broken deps, broken APIs due to deps rebases, …).
In Rust ecosystem, we abuse Rawhide to build and store such packages there
and then generate end-user application (e.g. ripgrep) which uses some of
those packages and produces binary for all supported releases. Those
applications have high quality and are supported.
Rawhide gating makes this much more complicated because builds appear in
buildroot slower, updating group of packages would need side tags and it’s
just painful to work with.
https://pagure.io/fesco/issue/2068
And, after all, those packages shouldn’t be shipped to users.
Problem №2: Testing of new rpm/koji/mock features/configuration
When developing new features in RPM (e.g. rich dependencies) or testing
different Koji configuration (e.g. removing gcc/gcc-c++ from the
buildroot), it is required to make custom configuration and try building
things.
Problem №3: Developing modules
Modules are built in MBS as a single unit. It is hard to develop big
modules by progressively improving individual packages or small package
groups. Scratch builds for modules are not implemented. Local builds work
differently from official module builds, they don’t scale and don’t allow
groups of people to work collaboratively. All these problems can be solved
by first developing a flat repository of packages in a shared environment
and then generating modulemd from such package set.
Problem №4: Testing things before push
Primary Fedora Koji and dist-git are not suited for packaging
experimentation. Packagers are expected to experiment on their own systems
and push changes of successful experiments only. But this approach doesn’t
scale with number of maintained packages. Often you can find commits like
“d’oh, forgot to upload sources” or “let’s try with this settings”. People
need to build things somewhere quickly, do development and testing. And
only after that, they should push commit(s) to Fedora.
Solution
-
Separate Koji + Koschei deployed in Fedora infrastructure cloud;
-
Builders are optimized for the best performance (see below
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
);
-
People can have their own targets where they can break things as they
wish without affecting others;
-
Package changes are eventually contributed to Fedora proper by merging
changes to Fedora dist-git and rebuilding packages in official Fedora Koji;
-
All improvements can eventually be contributed back to official Fedora
infra.
Ideas
All ideas which you’ll find below are just an ideas and do not have to be
implemented.
Idea №1: Automated legal review
openSUSE released their review app called Cavil
<https://github.com/openSUSE/cavil> which we could try running in automated
way.
Idea №2: Automated package review
Currently review process is burden and we could run automated legal review,
create a repo, run set of checks and notify person. Somewhat similar to
fresque <https://github.com/fedora-infra/fresque>. In future might be
integrated with approval process and auto-imported into Fedora.
Idea №3: Building packages for multiple distributions
In Rust ecosystem, we managed to get have same packaging guidelines in
openSUSE, Mageia and Fedora. We could automatically build some packages on
multiple distributions and be kinda upstream.
Idea №4: Building custom images with user content
Deploy (or build) a tool(s) to enable user-built install, appliance and
container images with their content (modulo restrictions similar to COPR)
on top of Fedora.
Implementation details
-
Koji and Koschei deployed in fedorainfracloud.org
-
A few builders constantly running, with a possibility to add more
builders as needed and as available cloud resources allow
-
Deployed and maintained by proposal owners - not supported by Fedora
infrastructure
-
Other contributors can have access granted by proposal owners (for the
time being only users in “packagers” group will be eligible to get access)
-
Possibility to have some builders running outsides of Fedora
infrastructure - contributed by proposal owners
-
Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or
from SRPM upload
FAQWhy not COPR?
-
COPR has been starved of resources for years, which has impaired its
ability to provide reliable service at scale. Fedora Infrastructure refuses
to consider supporting it officially and Fedora Release Engineering seems
to have some undefined issues with COPR.
-
It is not official build system of Fedora which is not helping with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
-
COPR is not extensible enough, more specifically:
-
No query API (e.g. it is not possible to find out from which SCM
commit the package has been built)
-
Builds always have access to all previous builds in a repository
(i.e. not possible to control when/how repo is created)
-
GC doesn’t exist
-
No scratch builds
Why not staging Koji?
-
Staging Koji is meant for testing Koji itself and not for package
development.
-
Staging Koji is often in broken state where it is not possible to build
anything.
-
No one can touch staging Koji, so it’s pointless for offering a useful
service.
How can you make Koji builds faster?
-
By tuning Koji for performance, not correctness and reliability.
-
By building only on a single, fast architecture.
-
By extensive caching. Files like RPM packages, repodata and files in
lookaside cache don’t change after they are initially stored, so builders
can cache them aggressively.
-
By keeping build repositories small. Some package sets don’t need to be
built against full Fedora, but can use a minimal subset of Fedora. Such
repositories can be generated by Koji in seconds, not minutes.
Why not the Open Build Service (OBS)?
-
OBS is not yet packaged for Fedora officially. The upstream code lacks
adaptations necessary to deploy and run on Fedora and in Fedora
Infrastructure.
-
OBS is not official build system of Fedora, which does not help with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
What does MBI stand for?
-
M for middlestream, module, mizdebsk, …
-
B for build, bootstrap, …
-
I for infrastructure, initiative, ignatenkobrain, …
-
MBI might be pronounced as “maybe I …(can make something cool)?”
-
MBI is also initials of mizdebsk (Mikolaj Bozydar Izdebski)
-
MBI is also IBM spelled backwards :)
Is it somehow related to Fedora Playground
<https://fedoraproject.org/wiki/Playground>?
Yes, it is. Although it is more developer-focused. Users could enrol for
some specific things like experimental Java/Rust packages.
MBI (Playground 2.0)
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
5 years, 2 months
F31 System-Wide Change proposal: Update Sphinx to version 2 and drop
Python 2 support from Sphinx
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Sphinx2
== Summary ==
The version 2.0.x of [https://www.sphinx-doc.org/ Sphinx], popular
Python documentation generator and framework, is expected to be
[https://github.com/sphinx-doc/sphinx/issues/5950 released in early
2019]. It [https://www.sphinx-doc.org/en/master/changes.html#incompatible-changes
drops support for Python 2]. As part of
[[FinalizingFedoraSwitchtoPython3|Finalizing Fedora's Switch to Python
3]], we update {{package|python-sphinx}} to 2.0.x and we drop
{{package|python2-sphinx}} and related packages from
[[Releases/31|Fedora 31]] and further.
Package maintainers using Sphinx on Python 2 have three options:
* they stop using Python 2 entirely (preferred), dropping their
python2 subpackages if not dependent upon by other packages,
* they switch to Sphinx on Python 3 for building their documentation,
* they stop building documentation.
Packages that use Sphinx on Python 2 at runtime are Sphinx extensions,
themes etc. and will be removed together with
{{package|python2-sphinx}}.
== Owner ==
* Name: [[User:Churchyard|Miro Hrončok]] as the lead Python 2 deletionist
* Name: [[User:Cstratak|Charalampos Stratakis]] as the
{{package|python-sphinx}} maintainer
* Email: python-maint(a)redhat.com
== Detailed Description ==
See live (or several days old) information of Python dependents of
{{package|python2-sphinx}} at the
[https://fedora.portingdb.xyz/pkg/python-sphinx/ Python 2 Dropping
Database].
We will remove the following (sub)packages:
* {{package|python2-sphinx}}
* {{package|python2-catkin-sphinx}}
* {{package|python2-numpydoc}}
* {{package|python2-openstack-doc-tools}}
* {{package|python2-openstackdocstheme}}
* {{package|python2-snowballstemmer}}
* {{package|python2-sphinx-intl}}
* {{package|python2-sphinx-theme-alabaster}}
* {{package|python2-sphinx_rtd_theme}}
* {{package|python2-sphinxcontrib-httpdomain}}
* {{package|python2-sphinxcontrib-websupport}}
* {{package|sphinx-webtools}}
* {{package|trac-sphinx-plugin}}
The following (source) packages currently (2019-02-06) BuildRequire
any of the above and will need to be modified to stop BuildRequiring
them:
(See wiki page for a full listing)
As said in the summary, packages will either switch to Python 3 Sphinx
or stop building the docs.
Change owners can provide guidance and help, yet they cannot be
expected to fix all the packages.
The following tools will be switched to Python 3:
* <code>/usr/bin/sphinx-apidoc</code>
* <code>/usr/bin/sphinx-autogen</code>
* <code>/usr/bin/sphinx-build</code>
* <code>/usr/bin/sphinx-quickstart</code>
Their <code>-3</code> and <code>-3.X</code> suffixed counterparts will
be kept as symbolic links for backwards compatibility.
Explicit conflicts with old {{package|python2-sphinx}} will be added
and {{package|python2-sphinx}} will be obsoleted via
{{package|fedora-obsolete-packages}}.
== Benefit to Fedora ==
Fedora is the leading environment for Python development and will
include the newest and greatest Sphinx for users and packagers.
The removal of Python 2 Sphinx will help in getting rid of a
significant amount of Python 2 usage, as Fedora's long term plan is to
get rid of this legacy interpreter. Python 2 is deprecated in Fedora
and its upstream support ends on 2020-01-01, very early in the Fedora
31 life time.
== Scope ==
* Proposal owners: remove above-mentioned packages as soon as
possible, update {{package|python-sphinx}} to 2.0.0 or newer, provide
guidance and help.
* Other developers: stop using {{package|python2-sphinx}} (list of
affected packages in the description)
* Release engineering: [https://pagure.io/releng/issue/8100 #8100] (no
Release Engineering impact is anticipated)
** List of deliverables: empty
* Policies and guidelines: none
* Trademark approval: not needed for this Change
== Upgrade/compatibility impact ==
The new {{package|python3-sphinx}} package will have to conflict with
the old {{package|python2-sphinx}} package because the unversioned
executables will be moved from {{package|python2-sphinx}} to
{{package|python3-sphinx}}. Proper obsoletes will be added to ensure a
clean upgrade path.
Fedora users using RPM-packaged Sphinx will use Sphinx on Python 3 by
default, as many would expect.
Fedora users still needing to use Sphinx running on Python 2 will use
Python virtual environment and pip.
== How To Test ==
TBD
== User Experience ==
Already covered by sections above.
== Dependencies ==
Described by the sections above.
== Contingency Plan ==
* Contingency mechanism: If absolutely needed, the change owners will
add compatibility {{package|python2-sphinx}} package with Sphinx 1.8.x
but they are not willing to maintain it, so they plan to orphan it
soon after Fedora 31 is released.
* Contingency deadline: any time before release
* Blocks release? No
* Blocks product? No
== Documentation ==
This page is the documentation.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 2 months
FC30 Mass Rebuild still not finished
by Tomasz Kłoczko
Hi,
Looks like MR which started two weeks ago still is not fully finished.
Below command has been executed in mirrored rawhide source packages tree.
[tkloczko@domek fedora]$ for i in fc{21..30}; do echo "$i $(ls -1
*/*$i.src.rpm | wc -l)"; done; echo; ls -1 ?/*|wc -l
fc21 16
fc22 15
fc23 21
fc24 80
fc25 12
fc26 61
fc27 79
fc28 223
fc29 14133
fc30 25760
[tkloczko@domek fedora]$ find . -mtime +14 | wc -l; ls -1 ?/* | wc -l
20746
40616
Looks like only about half packages actually have been rebuild.
Possible cause: failing Fedora build infra like in rebuild of the mc
package:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32784400
Is it any plan to resend all those pending build requests?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
5 years, 2 months
Orphaning some packages
by David Cantrell
Hello all,
I was going through the list of packages I own in Fedora and see a few
that I do not use anymore and do not actively maintain. Traffic on
these is relatively low. If anyone is interested in taking over the
packages, feel free. I have transferred them to orphaned status:
wicd
ez-pine-gpg
python-urwid
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
5 years, 2 months
