Proposal: Stewardship Group / SIG for taking care of otherwise
"module-only" packages
by Fabio Valentini
Hi everybody,
In the past few weeks, it has come up regularly that future
"module-only" packages are orphaned (and hence will soon be retired),
and nobody stepped up to fix this issue - especially for non-leaf
packages. I don't think fedora as a project has a solution for this
yet.
I propose to create a "Stewardship" Group / SIG that will take care of
such packages - either until a new main maintainer steps up, or until
modularity matures enough so it won't be necessary anymore. (Or, until
it dies a quiet death, which is always a possibility.) However, I
think this is necessary until the situation stabilizes.
Comments and future contributors are very welcome.
Fabio
3 years, 1 month
Can we please stop enforcing Signed-off-by commits?
by Miro Hrončok
It happened to me almost dozen times now, so here's my rage :D
I want to send a pull request to a Fedora project*, I clone it, fork it, push to
the fork, open a PR and there it goes:
! This repo requires all commits to have the Signed-off-by whatnot in them !
So I have to go again, amend with -s, push force. That is tedious and at least I
know how to do that. I assume there are people who don't.
Can we stop this nonsense? I usually smuggle something like:
Signed-off-by: Stop This <pretty(a)plea.se>
And nobody ever cares! The thing is enforced only because it can be enforced.
The line in that commit message is totally useless and doesn't provide any
benefit, just pain. I've signed the Fedora Project Contributor Agreement. That
should be enough.
Now a bit more serious:
What information am I missing? Why do Fedora upstreams enforce this?
Thanks
(* last time it was simple-koji-ci, but it's also fedpkg and other projects on
pagure.io)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 2 months
Tracking translation status of a package built in koji
by Sundeep Anand
Hi Everyone,
At times this could be a requirement to track or know translation status of a package which has (just) built in koji.
Transtats could be used for this purpose. We just need to run a job.
Steps:
1. Navigate to https://transtats-web-transtats.app.os.stg.fedoraproject.org/jobs/yml-based
2. Select 'Sync Package Build System' job template and proceed.
3. You may read and continue with the tasks defined in YML.
4. Select or enter package name. For example: anaconda.
Select Build System and Tag. For example: koji and rawhide
Click 'Next'
5. And run the job. Upon successful completion an unique URL will be created.
This could really be helpful. We are working on creating alerts or warnings.
Feel free to share comments on this here: http://feedback.transtats.xyz
thanks,
sundeep
3 years, 2 months
HEADS UP: dhcp will ship bunded bind libraries
by Pavel Zhukov
All,
tl;dr dhcp 4.4.1 will not require bind-export-libs and will bring
dhcp-libs-static with bundled version of libisc/libdns/etc
As ISC dropped support of single thread build of BIND libraries [1] and
dhcp requires one we decided to not patch dhcp/bind build scripts anymore
and ship bundled bind libraries just like upstream (ISC) does it. It will
allow to update BIND in Fedora to newest version. So dhcp 4.4.1 can be
expected in rawhide/F31 soon!
I'm aware of FPG recommendation to avoid shipping of bundled libraries due
to its maintenance cost but maintaining of heavy patched build sctipts and
inability to ship newer versions are even worse.
I have not find any application in Fedora repository which link with
libdhcp/libomapi. Please let me know if you aware of any.
[1] https://ftp.isc.org/isc/bind9/9.13.3/RELEASE-NOTES-bind-9.13.3.html
--
Pavel
3 years, 2 months
F31 System-Wide Change proposal: BuildRequires Generators
by Ben Cotton
https://fedoraproject.org/wiki/Changes/BuildRequires_Generators
= BuildRequires Generators =
== Summary ==
Add possibility to generate build-time dependencies within RPM spec
file and teach RPM and mock how to handle this.
== Owner ==
* Name: [[User:ignatenkobrain|Igor Gnatenko]], [[User:ffesti|Florian
Festi]], [[User:msuchy|Miroslav Suchý]]
* Email: ignatenkobrain(a)fedoraproject.org, ffesti(a)redhat.com, miroslav(a)suchy.cz
== Detailed Description ==
For many languages (Rust, Golang, Node.Js, Ruby, Python),
BuildRequires can be automatically generated. All it takes, run some
special tool which will output dependencies in RPM format.
Q: How will it work under the hood?
A: When you build RPM, something like this will happen under the hood…
# rpm would perform %prep (which is supposed to abort if some
dependencies missing and print them)
# mock would install those dependencies and resume build
Q: Will src.rpm contain all generated dependencies?
A: This is not known yet, we'll update page once it is known.
Q: Does this mean that package builds won't be reproducible anymore?
A: No, as long as you have same buildroot and tool which is generating
BuildRequires is doing so in reproducible manner, it should not affect
reproducibility.
== Benefit to Fedora ==
Packagers won't have to pre-generate BuildRequires in the spec file
which means it will be always updated (and correct) :
* Packagers can focus of making their packages better instead of
spending all their packaging time copying BuildRequires from
documentation and third party tools.
* BuildRequires are dropped as soon as they're no longer necessary
* Packages can be easily bumped without requiring a manual BuildRequires refresh
* BuildRequires and Requires generation can use similar utilities,
making sure that the deps packages declare can also be used for
second-level building. Packages no longer need to declare the deps of
their second and n-th dependencies because someone forgot to declare
them in the correct package.
== Scope ==
* Proposal owners: Implement support for a feature in RPM and mock (if
implemented properly, Koji should just work). Make use of it in Rust
ecosystem.
* Other developers: Maintainers of language stacks are advised to use
this feature.
* Release engineering: [https://pagure.io/releng/issue/8129 #8129]
* Policies and guidelines: Packaging Guidelines need to be updated
with instructions how to use this feature.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Packagers and users who use repoquery might be affected (src.rpm might
not contain generated dependencies).
== How To Test ==
TBD.
== User Experience ==
Users won't notice differences.
== Dependencies ==
Required feature needs to be implemented in RPM and mock.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Proposal
Owners might still ship feature disabled for Fedora buildsystem but
have it available for end-users, and move full completion to the next
release.
* Contingency deadline: Beta Freeze
* Blocks release? No.
* Blocks product? No.
== Documentation ==
TBD.
== Release Notes ==
TBD.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
3 years, 2 months
modular repositories in mock configs: please don't
by Fabio Valentini
Hi everybody,
Recently, modular repositories were enabled in the mock configs for fedora 29+.
Now, I can't build at least one of my packages (elementary-music) in
fedora 29 chroots, due to dependency issues within modules. dnf just
gives up with this rather unhelpful message:
Problem: cannot install the best candidate for the job
- package libpeas-devel-1.22.0-9.module_2123+73a9ef6f.x86_64 is excluded
I don't want or need modules installed for this package to build.
See: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cca3e242eb#comment-90...
IMO it was a mistake to enable modular repositories in mock configs by
default. Now dnf only downloads even more metadata for no benefit (or,
it even breaks dependency resolution, as in this case).
Do I really have to manually edit mock's config files to disable
modular repos, to get builds equivalent to koji (where modules aren't
available / usable either)? I want to test builds locally, before I
push them to koji builders ...
Any insights why this was done?
Can it be fixed please?
Or am I the only one having problems?
Fabio
3 years, 2 months
Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
3 years, 2 months
F30 Self-Contained Change proposal: Retire YUM 3
by Ben Cotton
(Note this change was previously submitted for Fedora 29:
https://pagure.io/fesco/issue/2064)
https://fedoraproject.org/wiki/Changes/Retire_YUM_3
== Summary ==
Remove yum (v3) and all related packages from Fedora.
== Owner ==
* Name: [[User:mdomonko|Michal Domonkos]]
* Email: mdomonko(a)redhat.com
== Detailed Description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils
* yum-metadata-parser
* yum-updatesd
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.
Compatibility:
* Important packages such as yum, createrepo or yum-utils will be
provided/obsoleted by relevant packages from the dnf stack
* Important executables such yum, repoquery, createrepo, etc. will be
provided either as new executables or via symlinks
== Benefit to Fedora ==
Drop an old package manager that has no active upstream development.
Move existing users to DNF which that has active development.
Secondary benefit is reducing number of packages in Fedora that still
depend on Python 2.
== Scope ==
* Proposal owners: Remove packages from the distribution: createrepo,
yum, yum-langpacks, yum-utils, yum-metadata-parser, yum-updatesd,
python-urlgrabber
* Other developers: Either remove packages from the distribution or
switch them to DNF
* Release engineering: [https://pagure.io/releng/issue/7588 #7588]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tool based on YUM 3 Python API will stop working. This applies on
any 3rd party software which won't be changed in Fedora as part of
this change.
CLI compatibility will be provided by DNF.
== How To Test ==
Repoclosure passes after dropping the packages.
== User Experience ==
There shouldn't be any impact on YUM users because the functionality
is provided by DNF already.
Users of tools listed in the Dependencies section shouldn't see any
difference if the migration to DNF is done properly.
== Dependencies ==
The list of source packages (SRPMs) that still depend on some of the
yum-related packages to be removed:
(see wiki page)
== Contingency Plan ==
* Contingency mechanism: Do not remove the packages in the current release.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A
== Release Notes ==
Inform end-users about removing the YUM 3 stack and definitive migration to DNF.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
3 years, 2 months
libravatar is in fedorainfracloud!
by Michal Novotny
Hello!
maybe you know that around April 2018, there was an announcement that
libravatar service (a service for serving user avatars) is shutting
down: https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018...
This raised a big wave of interest in the service and in keeping it
alive because libravatar was here for quite a long time and used by
many parties including Pagure, Mozilla Firefox, or Linux kernel. A
group of people formed with the goal to port libravatar to a new
platform and new servers and
https://blog.libravatar.org/posts/Libravatar.org_is_not_going_away/
was published. Then the work on saving libravatar had begun...
And now, it is finally done! Yesterday at 17pm UTC, Francois Marier
flipped the DNS switch to point www.libravatar.org to the new server
and completely new, modern implementation placed in our Fedora cloud!
\o/ Check it out here: www.libravatar.org
I think it's quite a nice message of how well people in Open Source
and Free Software can cooperate and how they can make something
significant happen. I would like to say thank you to them and in
particular to:
Oliver Falk who rewrote libravatar from scratch
(https://git.linux-kernel.at/oliver/ivatar)
Francois Marier who wrote and maintained the original libravatar and
who was helping us all the time with the migration
Tristan Le Guern who was testing the new implementation and provided
great insights
Niklas Poslovski who themed new libravatar
Lars Kruse who lead our IRC meetings and setup our @libravatar.org
email addresses
Me who setup the new servers in Fedora Infra Cloud and did some
testing of the new implementation too
I would also like to thank the Fedora community and the Infra team for
providing us with the space in the cloud for the new service.
So yeah, if your avatars are not served properly, you know whom to
blame :). You can get in touch with us on #libravatar Freenode
channel. Through https://git.linux-kernel.at/oliver/ivatar bugtracker
or by writing to libravatar-fans(a)lists.launchpad.net mailing list.
Enjoy
clime
3 years, 2 months
