some man pages have bugs, can't be grep'd
by Chris Murphy
I've been seeing this since clean installing Fedora 30. I don't recall
ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded
system (is now the clean installed system).
[chris@flap ~]$ man rpm | grep -C 10 rpmverbosity
<standard input>:176: warning [p 3, 0.8i]: cannot adjust line
[chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr
[chris@flap mantest]$ ll
-rw-rw-r--. 1 chris chris 62 Jul 16 14:24 rpm.stderr
-rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout
Is this a bug that should be reported against rpm or something else?
I'm certain I've seen it in other man pages, but offhand I can't find
another example.
--
Chris Murphy
2 weeks, 5 days
Unretire ulogd (or another NFLOG logger?)
by Chris Adams
I'd like to use NFLOG to log firewall drops (so that the kernel message
log isn't spammed by them), but it doesn't appear there's anything
currently in Fedora that can read that other than "tcpdump -i nflog".
It looks like ulogd was retired a while back because it only had a SysV
init script and nobody stepped up to convert it to systemd (which should
be really simple, since the old init script is pretty much a textbook
template of a SysV init script).
Am I missing anything? Is that all it needs? Is there another NFLOG
logger daemon?
--
Chris Adams <linux(a)cmadams.net>
1 month, 3 weeks
fedrq - new repoquerying tool
by Maxwell G
Hi Fedorians,
I've been working on a repoquerying tool called fedrq [1] that I'd like
to share with you. Here's the elevator pitch: fedrq provides a friendly
interface to query the Fedora repositories. It makes it really easy to
query across Fedora and EPEL branches. It uses the dnf Python bindings
(libdnf5 backend is almost done) and doesn't shell out to dnf repoquery.
Amongst other things, fedrq allows querying for reverse dependencies,
packages that contain a certain Provide or file, subpackages of an SRPM,
and general package metadata. My favorite features are the easy branch
switching, `fedrq subpkgs` (there's no real equivalent in dnf
repoquery), and the ability to dump package metadata as JSON. The many
threads about how to properly query for dependencies when doing SO name
bump rebuilds and my own frustrations with dnf repoquery inspired this
tool.
You can install fedrq from PyPI or from gotmax23/fedrq [2] on Copr. The
EXAMPLES section of fedrq(1) [3] provides a good intro and demonstration
of fedrq's functionality. The tool is very much a WIP and any feedback
is appreciated.
For reverse dependency rebuilds, you probably want the following
command:
```
$ fedrq whatrequires -X -F source $(fedrq subpkgs SRCNAME) # equivalent
$ fedrq subpkgs SRCNAME | fedrq whatrequires -X -i -F source # equivalent
```
This accounts for any package that depends on any subpackage/binary RPM
produced by SRCNAME at buildtime and/or runtime, and spits out the names
of the source packages that need to be rebuilt. For simple packages that
output only one RPM, `fedrq whatrequires -F source PKGNAME` is
sufficient.
[1] https://sr.ht/~gotmax23/fedrq/
[2] https://copr.fedorainfracloud.org/coprs/gotmax23/fedrq/
[3] https://gotmax23.srht.site/fedrq/fedrq.1.html#EXAMPLES
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/They
2 months, 1 week
Co-maintainers for my ham packages
by Matt Domsch
Due to an impending move to NYC and related downsizing of my house into a
2-bedroom apartment, I'm selling all my ham radio gear. Therefore I won't
be able to test any of the Fedora packages I maintain with actual
hardware. Would anyone be interested in maintaining or co-maintaining
these?
- direwolf - Sound Card-based AX.25 TNC
- CubicSDR - Cross-Platform Software-Defined Radio Panadapter
- liquid-dsp - Digital Signal Processing Library for Software-Defined Radios
- sdrpp - SDRPlusPlus bloat-free SDR receiver software
- SoapySDR - A Vendor Neutral and Platform Independent SDR Support Library
- soapy-rtlsdr - SoapySDR module for RTL-SDR hardware
Thanks,
Matt N5MLD
4 months, 3 weeks
F38 proposal: Rpmautospec by Default (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Rpmautospec (`%autorelease` and `%autochangelog`) is recommended as
the default approach.
Packaging Guidelines and other documentation are adjusted to describe
this approach first.
Various tools that provide spec file templates are adjusted.
== Owner ==
* Name: [[User:Nphilipp| Nils Philippsen]], [[User:Zbyszek| Zbigniew
Jędrzejewski-Szmek]]
* Email: nphilipp - at - redhat.com, zbyszek - at - in.waw.pl
== Detailed Description ==
{{admon/note|Brief reminder about rpmautospec|
The spec file contains:
<pre>
Version: 1.2.3
Release: %autorelease
...
%changelog
%autochangelog
</pre>
Rpmautospec uses git history. Whenever the package is built
(`.src.rpm` is generated), rpmautospec tooling will replace the
`%autorelease` macro with the number of commits since the last commit
that changed the `Version` field, and the `%autochangelog` macro with
a text generated from `git log`.
For details see the
[https://docs.pagure.org/fedora-infra.rpmautospec/principle.html
docs].
}}
Rpmautospec has been deployed in Fedora since F35
([[Changes/rpmautospec]]), and 3423/23045 packages use it (15%).
But it is still a "second-class citizen": most documentation doesn't
mention it, and many packagers know that it exists but don't use it in
their packages. We think that it's reasonable to switch to
`%autorelease`+`%autochangelog` for almost all packages and that
Packaging Guidelines and various packaging howtos should recommend
that approach to packagers. The "traditional" approach of
manually-managed `Release` and `%changelog` will remain valid and will
be documented as a fallback.
This change is targeted at Fedora 38, but it will actually apply to
all releases. The goal is to update the Packaging Guidelines and other
prominent documentation and tools now, and other docs and tools
possibly at a later time. Changing packages is out of scope.
It is worth mentioning that `rust2rpm` uses
`%autorelease`+`%autochangelog` since a few releases, so most rust
packages have switched. (Generally, rust spec files are recreated
using the generator for each new version, so the switch would happen
whenever a new version is packaged unless the packager opts out.)
== Feedback ==
* Thread on fedora-devel in August 2022:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
rpmautospec by default]
** open issues: a bunch have been fixed.
** maintenance: Nils will add some co-maintainers.
** compatibility with rpmdevtools, fedpkg/rpkg, fedora-review: see
Scope section.
== Benefit to Fedora ==
Various packaging workflows become smoother for packagers and contributors:
* packagers don't need to touch the `Release` field on updates
* packagers describe changes just once in the git commit message, the
`%changelog` entry is autogenerated
* patches to the spec file can be cherry-picked between branches
without trivial conflicts
* pull requests on src.fedoraproject.org can be merged without trivial conflicts
* in workflows that regenerate the spec file (rust2rpm, pip2rpm, …)
`%changelog` section doesn't need to be copied over
== Scope ==
* Proposal owners:
** provide pull requests to Packaging Guidelines and other docs to
make `%autorelease`+`%autochangelog` the default
** implement fixes for issues reported by packagers
** make semi-regular releases of rpmautospec
([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
0.3.1 was released on November 17th, and should be deployed to
production in about two weeks])
* Other developers:
** provide pull requests to other docs as appropriate
** accept the changes to documentation
** update other spec file generators (pip2rpm, others?)
* Somebody (TBD):
** `fedora-review` — https://pagure.io/rpkg/issue/641
** `fedpkg import` — with https://pagure.io/rpkg/c/3087dd7, the
command will fail. A replacement workflow that instead restores
`%autorelease`+`%autochangelog` in the file committed to dist-git
needs to be implemented.
* Related work
** https://pagure.io/rpkg/c/3087dd7
** https://src.fedoraproject.org/rpms/fedora-packager/pull-request/4
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: a list of places to be updated
** https://docs.fedoraproject.org/en-US/packaging-guidelines/#changelogs
** https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning
** https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutori...
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Rpmautospec is already used by a decent number of packages, so any
issues are already being seen and need to be fixed anyway.
== How To Test ==
* Convert an existing package: `rpmautospec convert`. Ideally this
step is done right before a version bump so that the release numbers
restart at `-1`.
* Do local builds (`fedpkg local`, `fedpkg mockbuild`). Verify
correctness of version-release (`rpm -qpi`) and the changelog (`rpm
-qp --changelog`).
* Do builds in koji. Verify correctness of version-release and the changelog.
* For new packages, use `%autorelease`+`%autochangelog`. Repeat all
the tests listed above.
* Assume you are a newbie packager. Read the packaging docs and check
that the workflow is clear and the intructions are sufficient to use
rpmautospec tooling correctly.
== User Experience ==
No changes visible to end users.
== Dependencies ==
None.
== Contingency Plan ==
If it turns out that the rpmautospec workflows have unknown problems,
we can revert changes to documentation.
* Contingency mechanism: Revert changes to documentation by reverting
the appropriate commits. This can be done easily by FPC.
* Contingency deadline: Any time.
* Blocks release? No.
== Documentation ==
This page and any changes to Packaging Guidelines and other documents.
== Release Notes ==
Not needed.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
5 months, 3 weeks
F39 Change Proposal: Allow Removal of tzdata (System-Wide)
by Aoife Moloney
https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Allow the removal of tzdata especially on containers in order to minimize size.
== Owner ==
* Name: Patsy Griffin (Franklin)
* Email: patsy(a)redhat.com
== Detailed Description ==
This change will allow the removal of tzdata. When tzdata is removed,
the system will default to UTC. In order to reduce overhead, many
container installations now remove the data associated with tzdata but
cannot fully remove the package due to dependencies by other packages.
This results in confusion regarding the expected timezone info.
In order for this to work, we need packages that use tzdata at run
time to switch from Require'ing tzdata to Recommend'ing tzdata. These
packages should also gracefully handle instances where tzdata has been
removed. For example, this would require recognizing that tzdata is
not present and providing an appropriate error, such as recommending
that the user install tzdata.
== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone. As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
== Benefit to Fedora ==
This change will allow tzdata to be removed from containers without
leaving inconsistent package remnants.
== Scope ==
* Proposal owners: No changes are needed to tzdata.
* Other developers: Some packages need to change their spec files from
`Requires: tzdata` to `Recommends: tzdata`. It would be beneficial if
all packages switched in this way, but it is not required. Supporting
optional tzdata installation for as many workloads as possible allows
those workloads to minimize their container image size.
List of packages which need to be changed:
* glibc (glibc-common)
* gcc (libstdc++)
* python3.XX (3.9, 3.10, 3.11, 3.12)
List of packages which would be beneficial to be changed:
* python3-dateutil
* python3-pytz
* libical
Upon acceptance of the change request we will file bugs to fix each of
these packages for Fedora 39.
* Release engineering: No changes needed.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
If tzdata is already installed, then it continues to be installed on the system.
Following the Fedora Weak Dependencies Policy dnf will treat the
Recommends on tzdata as if it were a Requires and tzdata will always
be installed in a default system
(https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/)
However, the recommends will allow tzdata to be correctly uninstalled
in a container build file rather than having to use ‘rm -rf’ to delete
the zone files to recover space.
== How To Test ==
Language runtimes were installed and A/B tests carried out with tzdata
present and tzdata removed. The intent of these tests was to ensure
that the system can use the language frameworks without tzdata present
and that when the data was required that meaningful errors were
presented to the user.
Packages tested were C (glibc), C++ (libstdc++), Python (Python 3.11),
using their time and date APIs. This testing led to the correction of
the libstdc++ implementation as noted here:
https://gcc.gnu.org/cgit/gcc/commit/?id=4abd5bc600193e821fbc41995a0b8d9ea...
Developers can test this by installing Rawhide and uninstalling tzdata
and verifying their package operates as expected.
If tzdata cannot be uninstalled then we recommend filling a bug
against the package that Requires: tzdata and having a discussion with
the maintainer to make tzdata optional e.g. Recommends: tzdata.
== User Experience ==
The user can remove tzdata to minimize the container size.
With tzdata removed the system is UTC only.
== Dependencies ==
Fixing glibc, gcc, and python3.xx at a minimum to make tzdata
Recommends instead of Requires.
== Contingency Plan ==
* Contingency mechanism: Back out the change. Don’t do it.
* Contingency deadline: Can be backed out at the last minute since we
are only dealing with conversions from Requires to Recommends.
* Blocks release? No
== Documentation ==
Document that the tzdata package may be removed if needed to reduce
space on containers. With tzdata removed, the system will default to
UTC.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
6 months, 3 weeks
Re: TSS maintainer volunteer
by Petr Pisar
V Thu, Feb 16, 2023 at 07:29:07PM +0000, Kenneth Goldman napsal(a):
> I think I followed all those steps - identifying the package, announcing that
> I want to be the packager, making an account, etc.
>
> What's next?
Submit an updated tss2 package for a package review. As far as I can see,
there is no review opened for tss2 now
<https://bugzilla.redhat.com/buglist.cgi?component=Package%20Review&produc...>.
How to do it is described at
<https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_P...>.
Especially pay attention to:
If you are not member of the packager group, you need a sponsor. Add
FE-NEEDSPONSOR to the bugs being blocked by your review request.
> Does someone approve me?
Based on the FE-NEEDSPONSOR blocker someone from sponsors should notice your
review request and start to communicate with you in the review request in
Bugzilla. (If that does not happen, approach you a sponsor of your choice as
recommended at
<https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Spons...>)
Once the sponsor finds your package looks good and you understand how to
maintain a package, he/she will sponsor you, i.e. adds you into a packagers
group. Then you will be able to continue from this item on the
Package_Review_Process document:
When your package passes the review you should use fedpkg to request a Git
repository for it.
> Move a git repo somewhere?
For the purpose of the package review, you need to publish the spec file and
the SRPM file somewhere on the Internet. (Once you become a packager, you can
also use <https://fedorapeople.org/> server for that purpose.)
Once the package review passes, the offical git repository (called dist-git in
Fedora) for the tss2 package will be reopened with completing this item:
Request a Git repository for the package
Then you will commit the new spec file into the reopen dist-git repository.
-- Petr
7 months, 1 week
Bootstrapping package with circular dependencies in koji
by Jaroslav Skarvada
Hi,
I need to bootstrap package which has bootstrap support written
according to the [1]. I am able to bootstrap it locally (rpmbuild,
mock, ...) with the "--with bootstrap" or "-D '_with_bootstrap 1'". Is
there support for it in koji? E.g. something like:
koji build SIDE-TAG PACKAGE --bootstrap? Or do I have to manually do:
1. patch:
- %bcond_with bootstrap
+ %bcond_without bootstrap
2. koji build SIDE-TAG SCM
3. update&build the circular dep
4. unpatch:
- %bcond_without bootstrap
+ %bcond_with bootstrap
5. release bump
6. koji build SIDE-TAG SCM
Or is there some better way?
thanks & regards
Jaroslav
[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping
7 months, 1 week
