Hi packagers,
rawhide rpmbuild contains various debuginfo improvements that hopefully
will make various hacks in spec files redundant.
If you have your own way of handling debuginfo packages, calling
find-debuginfo.sh directly, need hacks for working around debugedit
limitations or split your debuginfo package by hand then please try out
rpmbuild in rawhide and read below for some macros you can set to tweak
debuginfo package generation.
If you still need hacks in your spec file because setting macros isn't
enough to get the debuginfo packages you want then please let us know.
Also please let us know about packages that need to set debuginfo rpm
macros to non-default values because they would crash and burn with the
default settings (best to file a bug against rpmbuild).
The improvements have been mainly driven by the following two change
proposals for f27 (some inspired by what other distros do):
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfohttps://fedoraproject.org/wiki/Changes/SubpackageAndSourceDebuginfo
The first is completely done and has been enabled by default for some
months now in rawhide. The second introduces two new macros to enable
separate debugsource and sub-debuginfo packages, but has not been
enabled by default yet. If people like the change and no bugs are found
(and fesco and releng agree) we can enable them for the f27 mass
rebuild.
If your package already splits debuginfo packages in a (common) source
package and/or sub-debuginfo packages, please try out the new macros
introduced by the second change. You can enable the standard splitting
by adding the following to your spec file:
%global _debugsource_packages 1
%global _debuginfo_subpackages 1
Besides the above two changes debuginfo packages can now (and are by
default in rawhide) build by running debug extraction in parallel. This
should speed up building with lots of binaries/libraries. If you do
invoke find-debuginfo.sh by hand you most likely will want to add
%{?_smp_mflags} as argument to get the parallel processing speedup.
If your package is invoking find-debuginfo.sh by hand also please take a
look at all the new options that have been added. Also note that almost
all options can be changed by setting (or undefining) rpm macros now.
Using the rpm macros is preferred over invoking find-debuginfo.sh
directly since it means you get any defaults and improvements that might
need new find-debuginfo.sh arguments automatically.
Here is an overview of various debuginfo rpm macros that you can define
undefine in your spec file with the latest rpmbuild:
#
# Should an ELF file processed by find-debuginfo.sh having no build ID
# terminate a build? This is left undefined to disable it and defined to
# enable.
#
%_missing_build_ids_terminate_build 1
#
# Include minimal debug information in build binaries.
# Requires _enable_debug_packages.
#
%_include_minidebuginfo 1
#
# Include a .gdb_index section in the .debug files.
# Requires _enable_debug_packages and gdb-add-index installed.
#
%_include_gdb_index 1
#
# Defines how and if build_id links are generated for ELF files.
# The following settings are supported:
#
# - none
# No build_id links are generated.
#
# - alldebug
# build_id links are generated only when the __debug_package global is
# defined. This will generate build_id links in the -debuginfo package
# for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
# the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
# This is the old style build_id links as generated by the original
# find-debuginfo.sh script.
#
# - separate
# build_id links are generate for all binary packages. If this is a
# main package (the __debug_package global isn't set) then the
# build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
# a -debuginfo package (the __debug_package global is set) then the
# build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
#
# - compat
# Same as for "separate" but if the __debug_package global is set then
# the -debuginfo package will have a compatibility link for the main
# ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
%_build_id_links compat
# Whether build-ids should be made unique between package version/releases
# when generating debuginfo packages. If set to 1 this will pass
# --build-id-seed "%{VERSION}-%{RELEASE}" to find-debuginfo.sh which will
# pass it onto debugedit --build-id-seed to be used to prime the build-id
# note hash.
%_unique_build_ids 1
# Do not recompute build-ids but keep whatever is in the ELF file already.
# Cannot be used together with _unique_build_ids (which forces recomputation).
# Defaults to undefined (unset).
#%_no_recompute_build_ids 1
# Whether .debug files should be made unique between package version,
# release and architecture. If set to 1 this will pass
# --unique-debug-suffix "-%{VERSION}-%{RELEASE}.%{_arch} find-debuginfo.sh
# to create debuginfo files which end in -<ver>-<rel>.<arch>.debug
# Requires _unique_build_ids.
%_unique_debug_names 1
# Whether the /usr/debug/src/<package> directories should be unique between
# package version, release and architecture. If set to 1 this will pass
# --unique-debug-src-base "%{name}-%{VERSION}-%{RELEASE}.%{_arch}" to
# find-debuginfo.sh to name the directory under /usr/debug/src as
# <name>-<ver>-<rel>.<arch>.
%_unique_debug_srcs 1
# Whether rpm should put debug source files into its own subpackage
#%_debugsource_packages 1
# Whether rpm should create extra debuginfo packages for each subpackage
#%_debuginfo_subpackages 1
# Number of debugging information entries (DIEs) above which
# dwz will stop considering file for multifile optimizations
# and enter a low memory mode, in which it will optimize
# in about half the memory needed otherwise.
%_dwz_low_mem_die_limit 10000000
# Number of DIEs above which dwz will stop processing
# a file altogether.
%_dwz_max_die_limit 50000000
%_find_debuginfo_dwz_opts --run-dwz\\\
--dwz-low-mem-die-limit %{_dwz_low_mem_die_limit}\\\
--dwz-max-die-limit %{_dwz_max_die_limit}
If there are settings missing that would be useful, bugs with the
default settings or defaults that should be changed please do file a bug
report.
Thanks,
Mark
Hi,
This is intro email as a new packager to Fedora.
I am Tomofumi Hayashi and live in Tokyo, Japan. I have contributed
OpenStack and OPNFV.
I am developing koko (container connector), which makes connection
between containers with veth or with vxlan interface.
https://github.com/redhat-nfvpe/koko
Now I create RPM package for it and want to bring it to Fedora. Hence
I am seeking a sponsor for this package.
https://bugzilla.redhat.com/show_bug.cgi?id=1463492
I am looking forward to contribute Fedora more!
Regards,
Tomofumi Hayashi
I ran into this today:
https://gist.github.com/Brainiarc7/aa43570f512906e882ad6cdd835efe57
DRM firmware is loaded by default. HuC and GuC are not. Things work
without them, and things work with them loaded. So what's the pro/con
and if there's a pro, why isn't it the kernel default? Seems like if
it should be default, either upstream should set them as the default,
or the CPU/GPU should ask for it?
Recently (either 4.10/4.11 kernel, or same time frame Firefox on
F25/F26) I notice a blocky flickering when Firefox is launched. This
doesn't happen with the firmware loaded. So that's nice I guess, but
doesn't seem critical.
Anyway, just curious.
--
Chris Murphy
Hi all,
python-greenlet was marked as dead.package for the epel7 branch because
it's in rhel-extras:
https://bugzilla.redhat.com/show_bug.cgi?id=1108884
however, it seems that it's only built for python 2. Is it fine if we bring
it back in EPEL but make it python3 only?
Thanks,
--
​ ​
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
GPG key ID: 4AF554ABA36A937A
Okay, so, I decided to get my hands dirty with this to make sure my
conceptual understanding stays in sync with the reality. And, it turns
out we really do need a system-tools module. So, I'm going to make
that. And in doing so, I ran into something I think is unresolved.
An early decision needed when making a module is the label for the
stream — that is, the dist-git branch it builds from. The convention is
that within a stream, interfaces remain the same (just as now we expect
big changes from release to release, not within f25 or f26). For
modules which correspond primarily to a single piece of software (and
associated stuff), it makes sense for the stream to match the major
version of the software: module nodejs might have streams for 8 and 10,
and httpd might have streams for 2.4 and 2.6.
In fact, let's make that a guideline. I believe the existing
https://fedoraproject.org/wiki/Module:Guidelines#Module_name.2C_update_stre…
doesn't have any rules, so let's make one. Specifically:
* Modules which correspond primarily to a single application or
versioned software stack (e.g. Apache HTTP 2.4 or Node.js v8) MUST
use a stream label corresponding to the major version of that software
(e.g. 2.4 or 8)
* Such modules MAY additionally have a "latest" stream, which would be
"rolling release" of the latest stable version (as opposed to master,
which corresponds to rawhide and may be unstable).
So far, easy, I think. But what about modules like mine which are
collections of stuff? We could give them an arbitrary version and
increment that. Or, since this module will to follow the same 13-month
lifecycle of a base Fedora release, and make big changes in new streams
on the same cadence, it is tempting to use "f26", "f27" and so on. I
think, though, we want to avoid this, because it introduces a
conceptual overload that will become confusing and limiting.
On the other hand, I want a label that tells people what to expect.
Langdon suggested that expected EOL might be a good way to do this. So,
I propose a convention that modules which do not correspond to single
specific versioned software all follow this convention:
Each such "collection" module MUST have one or both of the following:
* A "latest" rolling stream (As above, this would be separate from
"rawhide", as "latest stable", but could update frequently and
arbitrarily.)
* One or more streams corresponding to "end of life no earlier than",
in the format "YYMM". (Or "eolYYMM"? Or "eYYMM"? Or "uYYMM" for
'until'? Or "fYYMM" for 'fedora' — which might make sense if we get
to my dream of mixing and matching with CentOS modules....)
Additionally and for all of our sanity, I suggest:
* Valid module end-of-life dates are always either June or December,
corresponding to the Fedora schedule of early May / late October
base releases. So, f1806 or f1812, but not f1810 or f1901.
I know there is some work on stream-to-stream upgrades in modularity;
that work could take advantage of this convention.
So, we'd have:
httpd 2.4
httpd 2.6
nodejs 8
nodejs 10
sysadmin-tools latest
sysadmin-tools f1812
sysadmin-tools f1906
Does this make sense? Do you have improvements or entirely better
ideas?
I have an alternate idea too: "collection" type modules would
use arbitrary integer versions starting with 1 and increase only if the
content undergoes a major switch. ALL module streams would contain EOL
information after the version number separated by a ":". This EOL info
would be a date as above, or the string "latest", _or_ the string
"stable", indicating that no abi-breaking changes are expected ever and
that we basically have no known EOL.
With this alternate proposal, we'd have:
httpd 2.4:stable
httpd 2.6:latest (rolling as httpd 2.5 development leads to 2.6...)
nodejs 8:f1912 (because that's upstream eol)
nodejs 9:f1806 (if someone wants to do the work for a non-lts release)
nodejs 10:f2106 (or maybe e2012)
sysadmin-tools 1:latest
sysadmin-tools 1:f1812
sysadmin-tools 1:f1906
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
Hi,
I've been looking into how to suggest packages for inclusion in Fedora
for some time. See
https://ask.fedoraproject.org/en/question/106042/where-do-i-request-new-pac….
Finally I'm giving a list of some very useful pieces of software I am
partially missing after switching from Debian.
* one/some tox clients (see https://tox.chat)
* zcash
* MAT (metadata anonymisation toolkit, e.g. famous for inclusion in
Tails)
* qtqr (small good QR code generation toolkit)
Games:
* tworld
* and a 2d game included in the Debian repos, where you would walk
through a technical landscape avoiding being shot by seemingly robots
and you could get on elements that turn the world. (I think that's how
the game was named too, something like "Where is top?" or so…)
In any case already thanks @aeperezt and @davidva for your help, BTW.
Best regards,
rugk
Hi all,
Currently, in Fedora package names, "python" without a version number generally means Python 2. We would like to make it mean Python 3, but to make that switch, we first need to make sure nothing uses unqualified "python". All packages should use the "python2-" or "python3-" prefix. This has already been discussed in the packaging mailing list [0], which includes the technical details.
Recently, there were two important changes to Python packaging guidelines. The first one bans using the ambiguous `python` prefix in binary RPM package names [1]. Thus you must explicitly define the Python version by using either `python2-` or `python3-`. The second change bans depending on anything using the ambiguous `python-` prefixed names in (Build)Requires [2].
The packages that violate the above-mentioned policies are being tracked in portingdb [3] and we plan to start filling bugs soon . Since th at's a lot of bugs to file (more than 1000) , we encourage all maintainers to fix the packages they maintain. The changes needed to rename the package s are documented here [4]. For your convenience, we have also implemented taskotron automated checks, which run whenever a package is built in Koji . Y ou can see the results in bodhi once you submit an update.
The templates we are going to use for bugs' desctiptions can be found here [5]. Any feedback or suggestions are welcome !
[0] https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject…
[1] https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelin…
[2] https://fedoraproject.org/wiki/Packaging:Python #Dependencies
[3] http://fedora.portingdb.xyz/namingpolicy/
[4] https://python-rpm-porting.readthedocs.io/en/latest/naming-scheme.html
[5] https://fedoraproject.org/wiki/User:Ishcherb/Package_Naming_Bug_Filing
Kind regards,
Iryna Shcherbina
Associate Software Engineer
Red Hat
Whoever set up that service, seriously?
Why would I receive 610 emails for activity in "epel7"? For packages with
a longer git history, it will likely be thousands of emails.