Intent to retire or orphan keybinder - python2 version
by Johannes Lips
Hi all,
since keybinder won't build on any fedora version >=29 and all functionality should be provided by the newer python3 keybinder3 package.
I would like to ask if it's ok to retire it, but since there are some packages depending on it, I would rather orphan it and let someone else take care of it.
Packages depending on it:
dnf repoquery --whatrequires python2-keybinder
Last metadata expiration check: 0:29:57 ago on Mi 29 Aug 2018 19:31:04 CEST.
guake-0:0.8.8-4.fc28.noarch
kupfer-0:208-15.fc28.noarch
streamtuner-0:2.1.9-9.fc28.noarch
dnf repoquery --whatrequires keybinder
Last metadata expiration check: 0:30:10 ago on Mi 29 Aug 2018 19:31:04 CEST.
keybinder-devel-0:0.3.1-9.fc28.i686
keybinder-devel-0:0.3.1-9.fc28.x86_64
lxpanel-0:0.9.3-7.D20180305gitb85c71a6.fc28.i686
lxpanel-0:0.9.3-7.D20180305gitb85c71a6.fc28.x86_64
python2-keybinder-0:0.3.1-9.fc28.x86_64
FTBFS Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1604486
Upstream opinion:
https://github.com/kupferlauncher/keybinder/issues/14
5 years, 7 months
zram-generator
by Zbigniew Jędrzejewski-Szmek
Hi!
https://fedoraproject.org/wiki/Changes/ZRAMforARMimages is a change to
automatically create a zram device on memory-constrained systems. It is
implemented using 'zram' package, which uses a service unit and two
bash scripts to implement the starting and stopping of the zram device.
I wanted to explore an alternative approach, using a systemd generator [1],
to create (or not) the unit to create the zram device. The advantages are:
- lower footprint (a custom binary instead of a shell script using
grep, awk, and whatnot)
- completely invisible if the memory limits are not met, no "skipped" units
- minimalistic: the unit just creates the device, but tells
systemd-modules-load.service to actually load the module,
and creates a .swap unit for the device, so it will be managed by systemd
in the usual fashion.
Systemd generators are often written in C, to keep them mean and lean, but
C is not an attractive option for many people. We have wanted to explore
the approach of writing generators in Rust. zram-generator doubles as a
proof-of-concept and example of a simple-yet-not-trivial systemd generator
in Rust.
Without further ado: upstream project [2], fedora package review [3].
Many thanks to Igor Gnatenko and Martin Sehnoutka for reviews of the code.
It works like this:
1. /usr/lib/systemd/zram-generator runs, checks if we have less memory than the limit
2. /run/modules-load.d/zram.conf is created to have "zram" module loaded
3. /run/systemd/generator/swap-create(a)zram0.service is created, it'll
initialize /dev/zram0
4. /run/systemd/generator/dev-zram0.swap is created, and added to swap.target
5. swap.target is pulled in by systemd, the config from items 2, 3, 4 is
executed.
[1] https://www.freedesktop.org/software/systemd/man/systemd.generator.html
[2] https://github.com/systemd/zram-generator
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1622127
Comments, ideas, reviews of the package, etc, are very much welcome.
I think this might be used to replace the 'zram' package, but it's too early
to say.
Zbyszek
5 years, 7 months
Fedora 30 Self-Contained Change proposal: Make ambiguous python
shebangs error
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Make_ambiguous_python_shebangs_error
== Summary ==
The <code>/usr/lib/rpm/redhat/brp-mangle-shebangs</code> buildroot
policy script will be changed to make the build fail when it sees an
ambiguous python shebang, such as <code>#!/usr/bin/python</code> or
<code>#!/usr/bin/env python</code>. (The script has been warning in
these cases for 2 Fedora releases already, saying ''This will become
an ERROR''.)
== Owner ==
* Name: Miro Hrončok (churchyard)
* Email: <mhroncok(a)redhat.com>
== Detailed Description ==
The buildroot policy script in
<code>/usr/lib/rpm/redhat/brp-mangle-shebangs</code> currently changes
all python shebangs to python2 with a message like:
*** WARNING: mangling shebang in /usr/bin/taskotron_result from
#!/usr/bin/python to #!/usr/bin/python2. This will become an ERROR,
fix it manually!
We will change it to:
*** ERROR: ambiguous python shebang in
/usr/bin/taskotron_result: #!/usr/bin/python. Change it to python3 (or
python2) explicitly.
The script will exit with nonzero exit code, rendering the build failed.
The warning and a promise of the error was there for 2 releases (28
and 29). Taskotron check was also present.
There are standard mechanics to avoid this buildroot policy script or
to block certain files form it. Those remain intact by this change.
For details see
https://fedoraproject.org/wiki/Packaging:Guidelines#Shebang_lines and
https://fedoraproject.org/wiki/Packaging:Guidelines#BRP_.28BuildRoot_Poli...
sections of the packaging guidelines.
== Benefit to Fedora ==
Packagers will be notified by build error if they accidentally have
python2 shebangs (and python2 dependency) they didn't anticipate. It's
up to them to decide what to do with such files, no automation can
know.
== Scope ==
* Proposal owners: change the script, change Python Packaging
Guidelines (https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)
* Other developers: fix their packages if they fail because of this
* Policies and guidelines: Adjust Python Packaging Guidelines
(https://fedoraproject.org/wiki/Packaging:Python#Multiple_Python_Runtimes)
slightly.
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
Have an RPM package that tries to ship files with ambiguous python
shebang. Observe the warning on Fedora 29 and the error on Fedora 30.
== User Experience ==
Users should not notice this, expect there might be less unneeded
python2 dependencies created by accident.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 7 months
iniparser SONAME bump in rawhide
by Robin Lee
iniparser SONAME version bump from 0 to 1 since 4.1.
All packages depends on iniparser should be rebuilt:
- cava
- spindown
- ubridge
robin
5 years, 7 months
odd issues with building resp. linking mame
by Julian Sikorski
Hi list,
mame-0.201-1.fc30 has failed to build on x86_64, i686 and arm. On each
of those a different, but unusual build issue has occurred:
- on i686 the linker failed with can not read symbols: memory exhausted
- on arm with a ton of issues like errors encountered processing file
obj/Release/generated/mame/mame/drivlist.o
- on x86_64 with a bunch of
../../../../linux_gcc/bin/x64/Release/libemu.a(emuopts.o):(.debug_info+0xa9b4c):
relocation truncated to fit: R_X86_64_32 against `.debug_info'
Strangely enough, s390x build completed successfully and the aarch64 one
is still ongoing. Is this a known buildsystem issue? If it is not, do
you have any ideas what is going on here? Thank you for the pointers in
advance!
Best regards,
Julian
5 years, 7 months
Intent to split 'postgresql.spec' into 'libpq.spec' and 'libecpg.spec'
by Pavel Raiskup
Hi all,
ad [1] tracker - it's a good time to warn about this (rather
non-intrusive, I believe) change in PostgreSQL packaging in Fedora,
expected to happen in F30.
We'd like to provide alternative versions of PostgreSQL servers in
Fedora's modular repo, but still - it is very much desirable to have only
one version of libpq.so in Fedora (and build all the PostgreSQL server
versions against that one client library).
So we plan to cut libpq.so.5 soname into separate specfile, dedicated package
(and ditto for libecpg.so*, and friends).
From packaging POV (of ~120 packages that depend on either postgresql-libs or
postgresql-devel) nothing huge is happening:
- postgresql-libs is going to disappear, but nothing should depend
on that package _directly_ (packages who do that by mistake will be
fixed)
- 'libpq' will provide/obsolete 'postgresql-libs', and provide
libpq.so.5()
- 'libpq-devel' will provide/obsolete 'postgresql-devel'
(those two ^^ will be done because the majority of affected packages
only depend on libpq.so.5 anyways)
- packages with PostgreSQL server modules (third-party *.so plugins) will
have to switch from BR 'postgresql-devel' to 'postgresql-server-devel',
and some manual tweaks regarding pg_config will be needed (only few
packages, prepared in [2])
- nothing in Fedora so far depends on other sonames from postgresql-libs,
but such packages should newly depend on libecpg-devel
I've tried to rebuild all "affected" packages with either
s/BuildRequires: postgresql-devel/libpq-devel/ or
s/BuildRequires: postgresql-devel/postgresql-server-devel/
into [2, 3] repos, and everything seemed to be pretty fluent.
So the next step would be to
(a) go through PackageReview of libpq.spec and libecpg.spec,
(b) rebuild ^^ them, and rebuild postgresql.spec (with related
changes) into Rawhide and
(c) rebuild packages that depend on postgresql-libs or postgresql-devel and
where the rebuild is actually needed (I don't think that I should rebuild
packages where s/postgresql-devel/libpq-devel/ is enough, since such
packages depend on libpq.so.5() provide - but let me know if you think
otherwise). Step
(d) will be to start working on modular servers, and
(e) try to build the respective server-side third-party modules against
that.
For more info please follow the tracker [1], and review changes in [5]
(compared to postgresql.spec in the actual rawhide) and libpq/libecpg packages
in 4.
I've also submitted updates for stable Fedoras [6, 7] to provide
{postgresql-server,libpq,libecpg}-devel Provides, so that any Fedora fix
that will be done because of this change can be safely merged into the
stable Fedora branches.
Thoughts?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1618698
[2] https://copr.fedorainfracloud.org/coprs/praiskup/libpq-postgresql-10/moni...
[3] https://copr.fedorainfracloud.org/coprs/praiskup/libpq-lib-deps/monitor/
[4] https://copr.fedorainfracloud.org/coprs/praiskup/libpq/builds/
[5] https://copr-dist-git.fedorainfracloud.org/cgit/praiskup/libpq-postgresql...
[6] https://bodhi.fedoraproject.org/updates/FEDORA-2018-36b0b4efc9
[7] https://bodhi.fedoraproject.org/updates/FEDORA-2018-8870ed56fa
Pavel
5 years, 7 months
Idea: let's use Pagure to track Changes
by Ben Cotton
Hi community,
We've traditionally used the wiki for Change proposals because it's
the tool we had. But, it's not necessarily well-suited to the purpose.
But now we have Pagure, which can help address some of the
shortcomings of using the wiki: poor scriptability, no reporting, and
a lot of copy/paste.
So I've come up with a plan that would use Pagure instead:
https://fedoraproject.org/wiki/User:Bcotton/UsePagureForChanges
You can read the full details on the wiki page above, but the general
idea is that we won't change the policy for Changes, just how we store
and manipulate them. My intent is to make it nearly seamless for the
community while giving us a platform for building on the process in
the future. Note that this would run parallel to Bugzilla for a
release or two and then replace Bugzilla for Changes tracking.
Because we're already moving with changes for Fedora 30 and because a
few Pagure features would make it smoother (primarily allowing issue
submitters to edit metadata), I'd like to implement this for Fedora
31. Before that, I'd like the community's feedback.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 years, 7 months
pgadmin4 prerequisites and status report for fedora 29
by Joseph D. Wagner
The following custom rpms will be obsolete in Fedora 29:
pgadmin4-python3-blinker-1.4-3.f28.noarch =>
python3-blinker.noarch 1.4-3.fc29
pgadmin4-python3-fixtures-3.0.0-5.f28.noarch =>
python3-fixtures.noarch 3.0.0-11.fc29
pgadmin4-python3-flask-0.12.2-1.f28.noarch =>
python3-flask.noarch 1:1.0.2-3.fc29
pgadmin4-python3-flask-babel-0.11.1-4.f28.noarch =>
python3-flask-babel.noarch 0.11.2-3.fc29
pgadmin4-python3-flask-babelex-0.9.3-1.f28.noarch =>
python3-flask-babelex.noarch 0.9.3-3.fc29
pgadmin4-python3-flask-gravatar-0.5.0-1.f28.noarch =>
python3-flask-gravatar.noarch 0.5.0-3.fc29
pgadmin4-python3-flask-login-0.3.2-3.f28.noarch =>
python3-flask-login.noarch 0.4.1-3.fc29
pgadmin4-python3-Flask-Mail-0.9.1-4.f28.noarch =>
python3-flask-mail.noarch 0.9.1-4.fc29
pgadmin4-python3-flask-migrate-2.1.1-1.f28.noarch =>
python3-flask-migrate.noarch 2.1.1-3.fc29
pgadmin4-python3-flask-paranoid-0.2-1.f28.noarch =>
python3-flask-paranoid.noarch 0.2.0-4.fc29
pgadmin4-python3-flask-principal-0.4.0-14.f28.noarch =>
python3-flask-principal.noarch 0.4.0-17.fc29
pgadmin4-python3-flask-security-3.0.0-1.f28.noarch =>
python3-flask-security.noarch 3.0.0-3.fc29
pgadmin4-python3-flask-wtf-0.14.2-1.f28.noarch =>
python3-flask-wtf.noarch 0.14.2-3.fc29
pgadmin4-python3-html5lib-1.0.1-1.f28.noarch =>
python3-html5lib.noarch 1.0.1-1.fc29
pgadmin4-python3-pyrsistent-0.14.2-1.f28.x86_64 =>
python3-pyrsistent.x86_64 0.14.2-5.fc29
pgadmin4-python3-sqlalchemy-1.2.5-1.f28.x86_64 =>
python3-sqlalchemy.x86_64 1.2.11-1.fc29
pgadmin4-python3-sqlparse-0.2.4-1.f28.noarch =>
python3-sqlparse.noarch 0.2.4-3.fc29
pgadmin4-python3-wtforms-2.1-3.f28.noarch =>
python3-wtforms.noarch 2.2.1-3.fc29
The following custom rpms need to be retained unless the fedora version
is updated:
pgadmin4-python3-dateutil-2.7.2-1.f28.noarch <=
python3-dateutil.noarch 1:2.7.0-3.fc29
Updated version requested:
https://bugzilla.redhat.com/show_bug.cgi?id=1560212
pgadmin4-python3-flask-htmlmin-1.3.2-1.f28.noarch <=
python3-flask-htmlmin.noarch 1.3.1-3.fc29
Updated version requested:
https://bugzilla.redhat.com/show_bug.cgi?id=1622327
pgadmin4-python3-passlib-1.7.1-1.f28.noarch <=
python3-passlib.noarch 1.7.0-10.fc29
Updated version requested:
https://bugzilla.redhat.com/show_bug.cgi?id=1620382
pgadmin4-python3-simplejson-3.13.2-1.f28.x86_64 <=
python3-simplejson.x86_64 3.10.0-10.fc29
Updated version requested:
https://bugzilla.redhat.com/show_bug.cgi?id=1462583
The following custom rpms have no fedora equivalent:
pgadmin4-python3-dateutil-doc-2.7.2-1.f28.noarch
Is this one really needed?
pgadmin4-python3-sshtunnel-0.1.3-1.f28.noarch
What can we do to create a python3-sshtunnel package in fedora?
Once the custom rpms are no longer needed, it will be an easy matter to
create a fedora package for pgadmin4.
Joseph D. Wagner
5 years, 7 months
