I would like to draw some attention to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1622259. Description: startx unsets DBUS_SESSION_BUS_ADDRESS, which result in launching another D-Bus session which breaks communicating with user systemd services (and any D-Bus services started before launching X) from X session via D-Bus, since they use two different D-Bus daemons. I would really like this bug to be fixed.
Can somebody please enlighten me, how to update Rawhide after branching
and not using --nogpgcheck?
It seems that Rawhide keys were added in fedora-repos-30-0.4. So this is
the package which is still "rawhide" package and has "f31" keys. But
this package was not probably signed, because this directory is empty:
Installing anything from Rawhide fails, because of missing GPG keys.
So is there a way to get the GPG keys via DNF? Would it be possible to
sign fedora-repos and fedora-release packages by older key to allow
On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
> This makes the assumption, which was also made earlier in the thread,
> that it's somehow impossible to check what bootloader is installed.
> Why? My bootloader is happy to tell me its version:
> $ bootctl
> Current Boot Loader:
> Product: systemd-boot 241-565-g43d51bb
> Features: ✓ Boot counting
> ✓ Menu timeout control
> ✓ One-shot menu timeout control
> ✓ Default entry control
> ✓ One-shot entry control
> File: /EFI/systemd/systemd-bootx64.efi
> Nowadays it's gives the exact git commit it's built from, in the past
> it was just the release version, but either is enough. Therefore
> 'bootctl update' can fairly reliably *update*, i.e. do the installation
> if the thing we have is newer than the version already installed.
That's news to me, and unfortunately it doesn't look as nifty on my system:
Current Boot Loader:
Features: ✗ Boot counting
✗ Menu timeout control
✗ One-shot menu timeout control
✗ Default entry control
✗ One-shot entry control
Available Boot Loaders on ESP:
ESP: /boot/efi (/dev/disk/by-partuuid/$UUID)
Boot Loaders Listed in EFI Variables:
Status: active, boot-order
Title: Linux Firmware Updater
Status: active, boot-order
Where $UUID is the same for all three occurrences.
I am looking for arch container archive files like
" for Fedora 30.
I found the x86_64, aarch64 and s390x's archive files in below directory.
But where is the archive file of armv7hl, i686 and ppc64le?
I assume the multi archs except x86_64, aarch64 and s390x existed in
the age of Fedora 24, 25 in below releases directory.
And why below s390x does not have Fedora-Container-Base-*.tar.xz?
=> No Fedora-Container-Base-*.tar.xz
Jun Aruga / He - His - Him
jaruga(a)redhat.com / IRC: jaruga
Now I'm working on signal SIGTERM handling and I would like to kill all processes related to the main mock process.
What do you think is it a good idea to kill all processes, or do we want to kill the main process only?
And what about SIGINT so-called KeyInterrupt in python? Same reaction?
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
> > I'd like to get this package reviewed please:
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> > Would anyone like to swap reviews?
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
Time zone: Europe/London
Back when [Django 2.0] was released in Fedora 28, I took over Django
1.11 LTS as some important (to me) packages depended on it. I'm no
longer interested in maintaining it, so I've orphaned it.
Let me know if you want to take it. If no one does, it may be removed
from Rawhide in 6 weeks.
Depending packages and their maintainers are:
- fts-monitoring (andreamanzi, simonm)
- python-oauth2client (mbaldessari, ralph)
- cobbler-web (jimi, kwizart, orion, shenson)
Let me know if you need help with these packages.
[Django 2.0]: https://fedoraproject.org/wiki/Changes/Django20
== Summary ==
Stop building i686 kernels, reduce the i686 package to a
kernel-headers package that can be used to build 32bit versions of
== Owner ==
* Name: [[User:jforbes| Justin Forbes]]
* Email: jforbes(a)fedoraproject.org
== Detailed Description ==
The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for
several Fedora releases now. As such, it gets very little testing,
and issues frequently appear upstream. These tend to go unnoticed for
long periods of time. When issues are found, it is often a long time
before they are fixed because they are considered low priority by most
developers upstream. This can leave other architectures waiting for
important updates, and provides a less than desirable experience for
people choosing to run a 32bit kernel.
With this proposal, the i686 kernel will no longer be built. A kernel
headers package will still exist, and all 32bit packages should
continue to build as normal. The main difference is there would no
longer be bootable 32bit images.
This was last proposed with Fedora 27, but it was deferred as an i686
SIG was to be created to handle issues going forward. That SIG has
been largely unresponsive. The only thread so far this year has been
a thread starting with "Hello, I noticed that the x86 group hasn't had
any reports in a while. As the absentee sponsor of the group, I would
like to remind people on the list and interested in keeping x86_32 in
Fedora releases that there is general work which needs to be done by
people interested. " And the only response was one person saying they
would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora ==
More testable kernel updates, faster fixes for security bugs, and
== Scope ==
* Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep
the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461]
of deliverables]]: Drop i686 based images
* Policies and guidelines: N/A (not needed for this change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test ==
N/A Nothing to test, we simply stop producing a flavor of the kernel
package. As there is no direct upgrade path from i686 -> x86_64, users
with capable hardware will have to reinstall.
== User Experience ==
The few 32bit users will have the full lifecycle of Fedora 30 to
choose a time to upgrade to a 64bit installation. Some old hardware
will no longer be supported by fedora.
== Dependencies ==
32 bit x86 images can no longer be built.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
* Contingency deadline: As QA requires for image candidates
* Blocks release? Yes
* Blocks product? product Fedora 31
== Documentation ==
The lack of an i686 image will need to be documented.
He / Him / His
Fedora Program Manager