No missing expected images.
Images in this compose but not Rawhide 20151028:
Cloud disk raw i386
Cloud_atomic disk raw x86_64
Cloud disk qcow x86_64
Cloud docker x86_64
Cloud vagrant libvirt x86_64
Cloud vagrant virtualbox x86_64
Cloud_atomic disk qcow x86_64
Cloud disk raw x86_64
Cloud_atomic vagrant virtualbox x86_64
Cloud disk qcow i386
Cloud_atomic vagrant libvirt x86_64
No images in Rawhide 20151028 but not this.
Mail generated by check-compose:
My name is Noel and I am a Spanish linux sysadmin. I work primarily with
CentOS servers and workstations.
I am a former Apple employee with experience packaging software for Mac.
I'd like to join the maintainers to help out and gain more experience.
What prompted me to start contributing was the version of tmux on my Fedora
We will be removing the kdbus driver from Rawhide kernels before the
4.3 final release upstream. Realistically, this means kdbus will be
gone from Fedora by Monday November 2nd at the latest. If you have a
setup using kdbus, please adjust it accordingly.
The upstream developers asked me to remove the module from Fedora
while they rethink some of the approach they are taking with kdbus.
I am hereby orphaning the flasm (Flash bytecode assembler disassembler)
package. (I am about to click the buttons in pkgdb.) I was asked to pick
this up back when I picked up gnash. I have since long given up
maintainership of gnash. I have never had any use for this package (not even
when I was still maintaining gnash), and I have not touched it for ages. I
also wonder whether anybody uses it at all. Either way, I am not the right
person to maintain this package.
The owner of the gnash package may want to take it up (as it is a tool that
can be used to debug gnash). Or they might not have any use for it either,
in which case it might be time to retire it (which will happen anyway if
nobody picks it up). In any case, it is free to take.
Got bug #1266181 filed about apitrace.i686 missing in the x86_64 repos.
The reporter probably meant apitrace-libs.i686, which in the past was
indeed installable on x86_64. Any ideas what the reasons can be that the
package disappeared? Suppose something about the "mash" step, but that's
as far as I get.
-----BEGIN PGP SIGNED MESSAGE-----
At the FESCo meeting on October 14th, it was decided that the time
has come to finally complete the migration away from System V init
scripts. What does this mean for you as a packager?
When we branch from Rawhide for Fedora 24 (currently scheduled for
February 2nd, 2016), we will be immediately retiring any package in
the Fedora collection that relies on a System V init script instead of
a systemd unit file to start. We will consider reasonable requests to
delay this action on a case-by-case basis for anyone who submits a
ticket to FESCo no later than 23:59 UTC on January 12, 2016.
There is no plan to remove System V compatibility from Fedora, due to
the necessity of supporting legacy third-party software. We are also
not making any changes at all to the EPEL project. EPEL packages may
continue to use System V init scripts (in the case of EPEL 5 and EPEL
6, there is no other option).
We will be going through the Wiki packaging documentation over the
next month and updating all related entries to reflect this change in
This will be the first such announcement. The Change Wrangler will be
sending additional reminders from now until February 2nd, so no one
will be surprised by this event.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
devel-announce mailing list
Hello fellow Fedora developers,
I have relatively recently completed a project to replace the ancient
and aging and unmaintained mod_auth_kerb Apache module with a new,
slimmer, more modern and maintained module called mod_auth_gssapi.
The plan is to retire mod_auth_kerb soon and get it out of the
distribution. So this is a heads up that if you have a project that
somehow relies on mod_auth_kerb it would be nice if you could migrate it
to mod_auth_gssapi instead, and if you have any issue doing so (missing
features, incompatibilities, anything) that you let us know so we can
address whatever problem you may find and accelerate the demise of
Simo Sorce * Red Hat, Inc * New York