an interesting discussion came up in the Python Maint team recently,
about not shipping python3-debug and python2-debug.
On the Chesterton's fence principle , I'd would like to know why are
we building and shipping them before we have a discussion about their
removal to save build time and remove packaging cruft.
Anyone has an idea? Those packages are meant to debug Python, yet all
people I know who do that, build they own Python for that purpose (often
from the master branch).
I tracked down the introduction of the python-debug package in this
commit  by David Malcolm (CCed) @ 8 years ago, added in Fedora 14
shortly before upgrade to 2.7. Yet the commit message lacks rationale.
Since I've just got sponzored - thank you jskarvad :) - it's time for me to
introduce myself. So here's my attempt :) .
I've discovered Linux, programming and the whole open source world about
7-8 years ago when I was at high school and immediately fell in love with
it. Even though I've studied electrical engineering I was much more
interested in software from the beginning. Driven mainly by my curiosity
and fascination by the concept of open source I've learned enough of coding
and Linux administration to get a job as a sysadmin at a smaller company in
Brno (Czech Republic). After roughly two and a half years I was given an
opportunity to challenge myself and to gain experience more towards
development at Red Hat.
So here I am taking this opportunity and starting as a packager. I'm about
to be focused mainly on containers and databases and my very first package
is timescaledb but more should come soon.
I'm very excited to be a part of this community and looking forward for the
Have a great day everyone!
Associate Software Engineer
Red Hat <https://www.redhat.com>
The Fedora today, there was a presentation about a vision for how
applications should have a different life cycle than the operating system:
For Flatpaks, the future is now - as soon as we start building them, I'd
like to start immediately in a model where the application lifecycle is not
tied to the traditional release cadence.
My basic idea is that applications consumed as Flatpaks should have a
"rolling stable" model - there is a *single* default version of the
application for all Fedora users, and that version is the latest upstream
stable release (once the Fedora Flatpak has passed automatic and manual
In more detail:
* The rolling stable version is maintained as the master branch of
modules/MyApp (this git repository contains both the module definition and
the container definition) - this also ends up as the stream of the built
* It should use the Flatpak runtime corresponding to the latest stable
release of Fedora - e.g., flatpak-runtime:f28 at the moment.
* The Flatpak branch name should be "stable", to correspond to Flatpak
Questions, possible answers
Isn't 'master' == 'rawhide' == unstable?
This is certainly the Fedora tradition, but since the stable branch is
the *default* branch, and since it will often be the *only maintained
branch*, I think it works better on master.
What about packaging *unstable* upstream releases?
If the packager desires, they can create a 'devel' branch, but they need
to rename the application in the desktop file and rename the application
ID, so that the devel releases can be parallel installed with the standard
releases. [There's some work that needs to be done to enable this either in
Bodhi since currently both branches of MyApp will end up tagged by Bodhi as
MyApp:latest with the latest updated one winning.]
What about packaging old stable upstream releases?
This should be done only in exceptional circumstances, such as a
complete rewrite upstream that produces a new stable version that (at least
originally) doesn't have all the features of the old stable version. In
this case you would use a upstream-versioned branch in dist-git, and also
be expected to change the desktop file name and application ID to enable
How does this affect rpms/MyApp
The branch structure of rpms/MyApp does *not* have to match that of
modules/MyApp. If a new major release of MyApp comes out in the middle of
F29, the package maintainer would have various choices a) ask for a stream
branch of rpms/MyApp to put the new version on and change their module to
reference the stream branch b) update the f29 branch to the new major
version and upgrade rpm consumers as well c) update the master branch to
the new major version and change the module to reference the master branch
- the spec file would need to work against both the f29 and f30 platforms,
but that usually isn't hard.
How does this relate to server containers?
I registry.fedoraproject.org/MyContainer:latest should be "rolling stable"
in the same sense. It should be the latest upstream revision, and should be
based on the latest Fedora release. But server admin's often don't want to
wake up one morning with their apps upgraded to a different major version
(or wake up one middle of the night to a phone call), so perhaps we need to
have stream branches and tags *up front* - so that you can use
MyContainer:10 [needs the same Bodhi work referenced above to avoid
fighting over 'latest' and 'testing']. We'd also need to figure out when
it's permissible for a stream branch to rebase to a different Fedora base
Do you have documentation for how Flatpaks will work?
Nothing very up-to-date. I hope to have comprehensive Flatpak packager
docs posted within the next few days, hopefully they will clarify this a bit
libipt v2.0 has been released yesterday and there was an SONAME bump
(from 1.6 to 2.0). According to 'dnf repoquery --whatrequires libipt',
only two packages depend on it:
I am the Fedora GDB maintainer and will rebuild it now. I am also
Cc'ing the insight maintainer in this message.
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
= Proposed System Wide Change: uEFI for ARMv7 =
* Peter Robinson <pbrobinson at fedoraproject dot org>
Move to uEFI as the default boot mechanism for ARMv7 devices.
== Detailed description ==
Currently ARMv7 uses extlinux to boot the kernel on ARMv7. This has
served us very well and has allowed us to standardise the ARMv7 boot
process with the vast majority of devices booting this way OOTB due to
the support being in a wide variety of u-boot releases. Over recent
years there have been a number of improvement to uEFI including robust
support in u-boot. We've supported uEFI on aarch64 as the only way of
booting Fedora supporting both Tianocore, proprietary uEFI
implementations and since Fedora 27 we've supported uEFI via u-boot
too. The uEFI provided by u-boot is now stable enough that we can now
move ARMv7 to this method too allowing us to move ARMv7 to grub2-efi
and have a single standard booth path/stack for both ARMv7 and
== Scope ==
* Proposal owners:
Patches, updates to the process, testing
* Other developers:
System component owners will need to review and merge patches for
* Release engineering:
** List of deliverables:
* Policies and guidelines:
N/A I don't believe this changes any policies or guidelines
* Trademark approval:
N/A (not needed for this Change)
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic