PkgDB and the ArbitraryBranching Change
by Ralph Bean
Hello,
As part of the Factory 2.0 and Modularity efforts[1], we’ve been
developing a plan to migrate to an “arbitrary” branching model from
our current model of one branch per release (as had been discussed at
Flock and DevConf[2]).
The main motivation behind this is to enable functionality required by
Modularity[3] and to ultimately reduce some package maintenance
burden. For some packages, it makes sense to have only a single branch
that feeds into multiple releases. For other packages, it makes sense
to have multiple branches which correlate with multiple upstream minor
releases. Today, our source branches are tied to the distro release,
via PkgDB. We want to decouple that and use modules to put it all
back together again.
To make this happen requires significant infrastructure changes. Our
proposed plan[4] is to decommission PkgDB entirely and to replace it
with a combination of PDC[5] and pagure over dist-git. (Tangentially,
getting pagure over dist-git to play nicely with PkgDB was a
challenge. This route gets us to a pull-request interface for spec
files quicker.)
We have brought this Change to FESCo[6][7][8] who expressed general
agreement on the project but also concern that the community may be
caught by off guard by the removal of PkgDB. As part of this change,
we have proposed a timeline[9] that outlines the steps we plan to take
to actually proceed with the migration. Please review that if you have
time and provide feedback. We are most concerned with missing
scripts/tools that may rely on PkgDB’s API. If you can think of any
that we may have overlooked, please let us know and we will add it to
the timeline!
We are meeting again with FESCo next Friday, June 2nd, where a
decision will be made on the Change. Any feedback before that would be
greatly appreciated.
Ralph and Matt,
From the so-called Factory 2.0 team
[1] https://fedoraproject.org/wiki/Infrastructure/Factory2
[2] https://youtu.be/5gqccjyjwFk?t=26m27s
[3] https://docs.pagure.org/modularity/
[4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBra...
[5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
[6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching
[7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html
[8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html
[9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
6 years, 8 months
F27 System Wide Change: perl Package to Install Core Modules
by Jan Kurik
= Proposed System Wide Change: perl Package to Install Core Modules =
https://fedoraproject.org/wiki/Changes/perl_Package_to_Install_Core_Modules
Change owner(s):
* Petr Písař <ppisar AT redhat DOT com>
dnf install perl will install all core Perl modules that come with
Perl upstream sources.
== Detailed Description ==
Upstream releases Perl interpreter together many Perl modules. This
set of modules is called core modules. Fedora splits the modules into
subpackages so that installing perl package results in stripped-down
set of modules. Fedora documents this as a feature and provides
perl-core to metapackage that allows installing all the core modules
as is intended by upstream.
Unfortunately this seems to be confusing to Perl users because Fedora
is the only distribution doing so.
To align Fedora's behaviour to upstream and other distributions this
change will rename perl package to perl-interpreter and perl-core
package to perl'. This will allow installing all core Perl modules
with dnf install perl while still retain the possibility to install
only a minimal perl interpreter (/usr/bin/perl) with dnf install
perl-interpreter.
This change will also update Fedora Packaging Guidelines for Perl to
all spec files that require perl to use perl-interpreter instead.
There is only 81 binary packages affected. They will rebuilt.
Otherwise no mass rebuild won't be necessary.
To ease sharing spec files with older Fedoras, perl-interpreter
provide will add to perl package there.
== Scope ==
* Proposal owners:
- Submit Fedora Packaging Guidelines for Perl update to Fedora
Packaging Committee.
- Update and rebuild perl source package.
- Add Provides: perl-interpreter to perl package in older Fedoras.
- Replace BuildRequires and Requires for perl with perl-interpreter in
all spec files.
- Rebuild packages with replaced Requires to propagate the change to
repositories.
- Replace perl-core with perl in compose groups definition.
* Other developers:
Get familiar with new Fedora Packaging Guidelines for Perl.
* Release engineering:
No action needed. Request to check of an impact with Release
Engineering: https://pagure.io/releng/issue/6842
* List of deliverables:
Anything what contains perl package
* Policies and guidelines:
Fedora Packaging Guidelines for Perl update request (
https://pagure.io/packaging-committee/issue/690 ) to use perl and
perl-interpreter instead of perl-core and perl.
Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 8 months
Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/Schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
even.
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
release.
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
press push).
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 8 months
F27 Self Contained Change: Samba AD
by Jan Kurik
= Proposed Self Contained Change: Samba AD =
https://fedoraproject.org/wiki/Changes/Samba_AD
Change owner(s):
* Alexander Bokovoy <abokovoy AT redhat DOT com>
* Andreas Schneider <asn AT redhat DOT com>
Samba AD is an open source implementation of an Active Directory set
of tools and protocols. It allows Windows clients to be enrolled and
managed using native Windows tools. In addition, Samba AD can serve as
a domain controller for Fedora workstations and servers utilizing
DCERPC, LDAP and Kerberos.
== Detailed Description ==
Samba AD is an implementation of an Active Directory set of tools and
protocols. It is developed and released as part of Samba suite.
Upcoming Samba 4.7 release will contain changes to allow Samba AD to
be built and used with MIT Kerberos. Prior to Samba 4.7 it was
impossible to compile Samba AD with MIT Kerberos. As result, Samba AD
was not packaged in Fedora.
== Scope ==
* Proposal owners:
Samba packages in Fedora already include a stub subpackage samba-dc
that is going to be replaced with a full Samba AD implementation.
Appropriate dependencies are already present in Fedora 27/Rawhide or
will be added together with Samba 4.7 update. This mostly concerns
upgrade of Samba-related libraries: libtevent, libldb, libtdb, and MIT
Kerberos update to support new APIs added to accommodate Samba AD
(already in Rawhide).
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
- https://pagure.io/releng/issue/6869
- We believe no impact to Release Engineering is needed for this change
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
6 years, 9 months
rpm debuginfo improvements for rawhide/f27
by Mark Wielaard
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/ParallelInstallableDebuginfo
https://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
6 years, 9 months
Self Intro: Tomofumi Hayashi
by Tomofumi Hayashi
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
6 years, 9 months
