devel August 2018

devel@lists.fedoraproject.org

200 participants
269 discussions

zram-generator
by Zbigniew Jędrzejewski-Szmek 31 Aug '18

31 Aug '18

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

9 13

Fedora 30 Self-Contained Change proposal: Make ambiguous python shebangs error
by Ben Cotton 31 Aug '18

31 Aug '18

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_Policy… 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

7 13

iniparser SONAME bump in rawhide
by Robin Lee 30 Aug '18

30 Aug '18

iniparser SONAME version bump from 0 to 1 since 4.1. All packages depends on iniparser should be rebuilt: - cava - spindown - ubridge robin

1 0

odd issues with building resp. linking mame
by Julian Sikorski 30 Aug '18

30 Aug '18

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

1 1

Intent to split 'postgresql.spec' into 'libpq.spec' and 'libecpg.spec'
by Pavel Raiskup 30 Aug '18

30 Aug '18

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/monito… [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-1… [6] https://bodhi.fedoraproject.org/updates/FEDORA-2018-36b0b4efc9 [7] https://bodhi.fedoraproject.org/updates/FEDORA-2018-8870ed56fa Pavel

3 3

Idea: let's use Pagure to track Changes
by Ben Cotton 30 Aug '18

30 Aug '18

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

10 11

Intent to drop python2-behave
by Miro Hrončok 30 Aug '18

30 Aug '18

There is a cluster of PRs: https://src.fedoraproject.org/rpms/python-behave/pull-request/2 https://src.fedoraproject.org/rpms/python-docx/pull-request/2 https://src.fedoraproject.org/rpms/python-parse_type/pull-request/2 That allows us to drop python2-behave as nothing will depend on it. I'm giving one week notice here. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

pgadmin4 prerequisites and status report for fedora 29
by Joseph D. Wagner 30 Aug '18

30 Aug '18

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

3 3

Schedule for Thursday's FPC Meeting (2018-08-30 16:00 UTC)
by James Antill 30 Aug '18

30 Aug '18

Following is the list of topics that will be discussed in the FPC meeting Thursday at 2018-08-30 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. uitime): ================= Day: Thursday ================== 2018-08-30 09:00 PDT US/Pacific 2018-08-30 12:00 EDT --> US/Eastern <-- 2018-08-30 16:00 UTC UTC 2018-08-30 17:00 BST Europe/London 2018-08-30 18:00 CEST Europe/Berlin 2018-08-30 18:00 CEST Europe/Paris 2018-08-30 21:30 IST Asia/Calcutta ---------------- New Day: Friday ----------------- 2018-08-31 00:00 HKT Asia/Hong_Kong 2018-08-31 00:00 +08 Asia/Singapore 2018-08-31 01:00 JST Asia/Tokyo 2018-08-31 02:00 AEST Australia/Brisbane Links to all tickets below can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting = Followups = #topic #665 SSLCertificateHandling policy update .fpc 665 https://pagure.io/packaging-committee/issue/665 #topic #667 Recommend use of systemd sandboxing directives .fpc 667 https://pagure.io/packaging-committee/issue/667 #topic #693 Wiki:Packaging:RPMMacros .fpc 693 https://pagure.io/packaging-committee/issue/693 #topic #703 Inconsistency between "General Naming" and "Case Sensitivity" .fpc 703 https://pagure.io/packaging-committee/issue/703 #topic #714 let's kill file deps! .fpc 714 https://pagure.io/packaging-committee/issue/714 #topic #719 Simplify packaging of forge-hosted projects .fpc 719 https://pagure.io/packaging-committee/issue/719 #topic #726 Review for SELinux Independent Policy packaging Draft .fpc 726 https://pagure.io/packaging-committee/issue/726 #topic #740 Add "%python_enable_dependency_generator" onto Python .fpc 740 https://pagure.io/packaging-committee/issue/740 #topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config .fpc 743 https://pagure.io/packaging-committee/issue/743 #topic #775 Allow to have %{?suse_version} condition in spec file .fpc 775 https://pagure.io/packaging-committee/issue/775 #topic #782 Forbid %{pythonX_site(lib|arch)}/* in %files .fpc 782 https://pagure.io/packaging-committee/issue/782 #topic #784 forbid globs for shared libraries as it conceals sonames .fpc 784 https://pagure.io/packaging-committee/issue/784 #topic #785 Crypto policies packaging guideline update .fpc 785 https://pagure.io/packaging-committee/issue/785 #topic #788 Bootstrap Exception for rebar3 .fpc 788 https://pagure.io/packaging-committee/issue/788 = New business = #topic #792 Proposal for "What Can Be Packaged" document .fpc 792 https://pagure.io/packaging-committee/issue/792 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://pagure.io/packaging-committee/issues?status=Open&tags=meeting If you would like to add something to this agenda, you can: * Reply to this e-mail * File a new ticket at: https://pagure.io/packaging-committee * E-mail me directly * Bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.

1 0

Will there be one more nightly compose for Fedora 29 Beta?
by Zamir SUN 29 Aug '18

29 Aug '18

Hi, I just wanna know if there will be one more compose for Fedora 29 for Beta? To be clear, I've retired some packages in Fedora 29 before the freeze which affect the LxQT appearance. But it did not take effect so I filed a ticket for Release Engineering but it was handled yesterday. And I did not see a new LxQT image till now. If there won't be a new compose, do I need to fill a FBR to resolve this? Thanks. -- Ziqian SUN (Zamir) GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E Want to know more about Fedora? Visit https://fedoraproject.org/wiki/ Ready to contribute? See https://whatcanidoforfedora.org/ 想了解更多中文资讯，访问 https://zh.fedoracommunity.org/

4 3

← Newer
1
2
3
4
5
6
7
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2018