Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
2 years, 8 months
Reproducible builds/bootstrap
by Pablo Greco
I'm starting to work on a project to make Fedora fully reproducible and bootstrappable from scratch.
I know it is a long term plan and still working on the steps, but it would be good to know the current status, if there is an internal interest in this, if someone is already working (or planning to).
Thanks for the info.
Pablo
2 years, 11 months
Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file,
breaking almost everything
by Hans de Goede
Hi All,
Just a quick headsup for users following Fedora 29, the
dbus 1.12.10-1.fc29 build is missing the systemd dbus.service
file, breaking almost everything.
Instead it contains a dbus-daemon.service file, but the
dbus.socket file expects a matching dbus.service, not
dbus-daemon.service.
So either hold of on applying updates until this is fixed
or exclude dbus.
Regards,
Hans
3 years, 1 month
Ditch RPM in favor of DPKG
by Dridi Boukelmoune
Greetings packagers,
I know how important RPM is to the Fedora Project, but it breaks
everything downstream and we'd be better off using DPKG as we should
have from day one.
I'm calling this initiative fedpkg: Fedora Embraces DPKG.
A bit of background here: I build both RPMs and DEBs for $DAYJOB and
until recently my workflow was quite painful because I needed extra steps
between git checkout and git push that involves a VM, because what we
ship as apt is in reality apt-rpm.
It finally got enough on my nerves to locally build the things I needed and
after a month I have already amortized my efforts with the time I save not
having to deal with needless extra hoops.
In order to successfully build debs on Fedora I needed 4 packages that
I'm now submitting for review:
https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config
https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism
https://bugzilla.redhat.com/show_bug.cgi?id=sbuild
https://bugzilla.redhat.com/show_bug.cgi?id=apt
I need more than reviews here.
Three of those packages are heavy on Perl code, and I'm not a Perl
Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with
the mailing list address) but bugzilla replied kindly:
CC: perl-sig did not match anything
Apt is a mix of C, Perl and C++ code, so I would be reassured if I
could have a C++ co-maintainer too. I'm only a C developer so if
something goes wrong outside of the C realm that would be helpful.
Two of those packages should be runtime dependencies of debhelper.
The current apt package should be renamed to apt-rpm, I will look up
the procedure for that to happen. I understand that when someone sees
they should run "apt-get install foo" somewhere on the web it's
helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is
dead upstream and it shouldn't be advertised as apt.
I hope I CC'd everyone that should get this heads up, and hope to find
help for the reviews and co-maintainership. The packaging does nothing
fancy, there are quirks here and there but overall it was rather easy
to put together. And of course I would be happy to help with reviews
too in exchange.
And thanks again to the mock developers, its design is so much better
than either sbuild or pdebuild that I barely have pain points left when it
comes to RPM packaging.
Thanks,
Dridi
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig
[2] I'm not against apt-rpm in the base install for example
3 years, 2 months
Default editor for LXQt spin
by Raphael Groner
Hi,
writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun.
Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream.
@lupinix Could you remove lxqt-sig from the members in pagure?
Regards, Raphael
3 years, 2 months
New set of questions for FESCo candidates?
by Zbigniew Jędrzejewski-Szmek
Dear all,
the semiannual exercise is upon us. FESCo candidates must submit an
"interview" in which they answer a set of questions (but can also add whatever they want).
The question whether we should have a new set of questions needs to be answered.
Currently we have the following:
Mandatory Question #1: Describe some of the important technical issues
you foresee affecting the Fedora community. What insight do you bring
to these issues?
Mandatory Question #2: What objectives or goals should FESCo focus on
to help keep Fedora on the cutting edge of open source development?
Mandatory Question #3: What are the areas of the distribution and our
processes that, in your opinion, need improvement the most? Do you
have any ideas how FESCo would be able to help in those "trouble
spots"?
Please answer with any proposals. If there is sufficient support for
change, I'll gather a list and submit this for some kind of poll
(details to be figured out...).
Zbyszek
3 years, 4 months
python-pep8 is orphaned
by iliana weller
Hello,
I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it
received its last release in 2017. It should be removed from Fedora in a
future release.
I unfortunately don't have time to proceed with the full retirement
process myself. If somebody would like to pick it up:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers...
$ dnf repoquery --whatrequires python2-pep8
python2-autopep8-0:1.2.4-9.fc29.noarch
python2-pytest-pep8-0:1.0.6-15.fc29.noarch
python2-spyder-0:3.3.1-3.fc29.noarch
$ dnf repoquery --whatrequires python3-pep8
python3-autopep8-0:1.2.4-9.fc29.noarch
python3-hacking-0:1.1.0-3.fc29.noarch
python3-pytest-pep8-0:1.0.6-15.fc29.noarch
python3-spyder-0:3.3.1-3.fc29.noarch
See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent
bugs.
(Please CC me on replies that need my attention.)
--
iliana weller <ilianaw(a)buttslol.net>
3 years, 4 months
Fedora 32 Self-Contained Change proposal: Build Python with
-fno-semantic-interposition for better performance
by Ben Cotton
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
Simplified version of another change proposal|This change was
originally proposed for [[Releases/32|Fedora 32]] as
[[Changes/PythonStaticSpeedup]], however based on
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
community feedback], it has been significantly reduced.
== Summary ==
We add the <code>-fno-semantic-interposition</code> compiler/linker
flag when building Python interpreters, as it provides significant
performance improvement, up to 27% depending on the workload. Users
will no longer be able to use LD_PRELOAD to override a symbol from
libpython, which we consider a good trade off for the speedup.
== Owner ==
* Name: [[User:Cstratak| Charalampos Stratakis]], [[User:Vstinner|
Victor Stinner]], [[User:Churchyard| Miro Hrončok]]
* Email: python-maint(a)redhat.com
* Shout-out: [[User:Jankratochvil|Jan Kratochvíl]] for first
suggesting this instead of the original proposal, followed by
[[User:Kkofler|Kevin Kofler]]. [[User:Fweimer|Florian Weimer]] for
providing answers to our questions. David Gray for originally
suggesting to link Python statically to gain performance.
== Detailed Description ==
When we build the Python interpreter with the
<code>-fno-semantic-interposition</code> compiler/linker flag, we can
achieve a performance gain of 5% to 27% depending on the workload.
Link time optimizations and profile guided optimizations also have a
greater impact when python3 is built this way.
As a negative side effect, it disables the LD_PRELOAD feature: it's no
longer possible to override symbols in libpython with LD_PRELOAD.
Interposition is enabled by default in compilers like GCC: function
calls to a library goes through a "Procedure Linkage Table" (PLT).
This indirection is required to allow a library loaded by LD_PRELOAD
environment variable to override a function. The indirection puts more
pressure on the CPU level 1 cache (instruction cache). In term of
performance, the main drawback is that function calls from a library
to the same library cannot be inlined, to respect the interposition
semantics. Inlining is usually a big win in term of performance.
Disabling interposition for libpython removes the overhead on function
calls by avoiding the PLT indirection, and allows to inline more
function calls. We're describing function calls from libpython to
libpython, something which is very common in Python: almost all
function calls are calls from libpython to libpython.
If Fedora users need to use LD_PRELOAD to override symbols in
libpython, the recommend way is to build a custom Python without
<code>-fno-semantic-interposition</code>.
It is still possible to use LD_PRELOAD to override symbols in other
libraries (for example in glibc).
=== Affected Pythons ===
Primarily, we will change the interpreter in the {{package|python3}}
package, that is Python 3.8 in Fedora 32 and any later version of
Python in future Fedora releases.
Impact on other Python packages (and generally software using Python)
is not anticipated (other than the possible speedup).
We will also change the
[https://developer.fedoraproject.org/tech/languages/python/multiple-python...
alternate Python interpreters] where possible and useful, primarily
the upstream supported versions of CPython, such as
{{package|python39}} (if already packaged), {{package|python37}} and
{{package|python36}}.
=== Affected Fedora releases ===
This is a Fedora 32 change and it will be implemented in Rawhide
(Fedora 32) only. Any future versions of Fedora will inherit the
change until it is reverted for some reason.
If it turns out that there are absolutely no issues, we might consider
backporting the speedup to already released Fedora versions (for
example Fedora 31). Such action would be separately coordinated with
[https://docs.fedoraproject.org/en-US/fesco/ FESCo].
== Benefit to Fedora ==
Python's performance will increase significantly depending on the
workload. Since many core components of the OS also depend on Python
this could lead to an increase in their performance as well, however
individual benchmarks will need to be conducted to verify the
performance gain for those components.
[https://pyperformance.readthedocs.io/ pyperformance] results,
ignoring differences smaller than 5%:
(See change proposal)
== Scope ==
* Proposal owners:
** Review and merge the
[https://src.fedoraproject.org/rpms/python3/pull-request/151 pull
request with the implementation].
** Monitor Koschei for significant problems.
** Backport the change to alternate Python versions.
* Other developers are encouraged to check if their package works as expected
* Release engineering: N/A (not needed for this Change) -- this change
does not require a mass rebuild nor any other special releng work
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Python package maintainers should verify that their packages work as
expected and the only impact the end users should see is a performance
increase for workloads relying on Python.
== How To Test ==
Test that everything Python related in Fedora works as usual.
=== Was the flag applied test ===
You can test whether the <code>-fno-semantic-interposition</code> flag
was applied for your Python build:
<pre>
>>> import sysconfig
>>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_CFLAGS') + sysconfig.get_config_var('PY_CFLAGS_NODIST'))
True
>>> '-fno-semantic-interposition' in (sysconfig.get_config_var('PY_LDFLAGS') + sysconfig.get_config_var('PY_LDFLAGS_NODIST'))
True
</pre>
Before the change, you would see <code>False</code>, <code>False</code>.
=== Performance test ===
The performance speedup can be measured using the official Python
benchmark suite [https://pyperformance.readthedocs.io/ pyperformance]:
see [https://pyperformance.readthedocs.io/usage.html#run-benchmarks
Run benchmarks].
== User Experience ==
Python based workloads should see a performance gain of up to 27%.
== Dependencies ==
This change is not dependent on anything else.
== Contingency Plan ==
* Contingency mechanism: If issues appear that cannot be fixed in a
timely manner the change can be easily reverted and will be considered
again for the next fedora release.
* Contingency deadline: Before the beta freeze of Fedora 32 (2020-02-25)
* Blocks release? Yes
* Blocks product? None
== Documentation ==
This change proposal has all the documentation.
See the [[Changes/PythonStaticSpeedup|previous change proposal]] and
the [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
thread about it on the devel mailing list] for more relevant
information about what we are not doing
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
3 years, 5 months
