I'm updating Rawhide to ntl 9.6.2, which involves an soname bump. I
will rebuild all affected packages in Rawhide. I have already rebuilt
all of them in my local mock, so I'm confident there will be no
problems on x86_64. 
Note that multiple packages in the dependency chain take several hours
to build on ARM, so the next Rawhide compose will almost certainly
happen partway through the rebuild. Expect broken dependencies in
tomorrow's Rawhide report, but they should all be gone again by the
time of Sunday's report.
 Actually, a couple of packages are showing a large number of
complaints from python-sphinx, probably related to the new version of
python-sphinx built in Rawhide a few days ago. So documentation may
be in a partially broken state, but that is unrelated to the ntl
The devel mailing list archives has an awesome interface, but
unfortunately, it only seems to work with the devel@ list, not any of the
others (like java-devel@).
Any plans to extend that functionality to improve all the mailing list
cppformat 2.0.0 was released  and it has several breaking changes. In
addition to API/ABI changes, the soname changed and the header file was
relocated. Since this package was recently added to Fedora, I don't know if
any packages depend on it, so my question is "Is this a "self contained" or
"system wide" change ?".
On a side note, I'm planning on adding symlinks to the existing cppformat
package so that these new soname and header locations can be used to keep
code the same.
I see a couple of the Let's Encrypt dependencies (like python-acme) are
working their way in to rawhide, but not yet in F23. I also don't yet see a
Since it's now in "Public Beta", having it available soon might be very
useful for F23 users.
Does anybody have any plans to work on making the tools (and their
dependencies) available as an update to F23?
If so, I'd be willing to help test and/or review.
= Proposed System Wide Change: Layered Docker Image Build Service =
* Colin Walters <walters AT redhat DOT com>
* Adam Miller <maxamillion AT gmail DOT com >
* Tomas Tomecek <ttomecek AT redhat DOT com>
* Tim Waugh <twaugh AT redhat DOT com>
* Amanda Carter <acarter AT redhat DOT com>
Fedora currently ships a Docker base image, but Docker supports a
layering concept. There are some applications like Cockpit which we
would like to ship as layered applications.
This change will deploy the build service to support building and
delivering a set of layered Docker images, and will enable Fedora
contributors to create and maintain Dockerfiles from which those
images will be generated.
== Detailed Description ==
This change opens up an new type of official binary artifact produced
by Fedora. Currently, we produce two main types of artifacts: RPMs,
and images. The RPMs are created in Koji from specfiles in dist-git.
The images come in different formats, but have in common creation in
Koji from kickstart files — this includes the official Fedora Docker
Base Image. This change introduces a new type of image, a Docker
Layered Image, which is created from a Dockerfile and builds on top of
that base image.
The system has five major parts:
A command-line client — already integrated into rpkg; needs only minor
work to enable in fedpkg (there is discussion about either extending
fedpkg or adding a new fedcontainer utility)
* dist-git for Dockerfiles
* A koji plugin, containerbuild
* An OpenShift 3 backend
* A distribution mechanism; a Docker Registry
* Currently evaluating options for this
* * Pulp Crane
* * Docker Registry
== Scope ==
For the Scope of this Change please check
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
devel-announce mailing list
(repost to Fedora development)
I've posted few screenshots of the current status of Samba AD with MIT
Kerberos running on Fedora 23 and establishing cross-forest trust to
FreeIPA on my Google+ page:
The patches to Samba are in Andreas' git tree, plus few changes Simo did
for proper generation of the salt for interdomain trust object keys.
Currently Samba generates the salt principal wrongly for TDO keys and it
works in Heimdal only because Heimdal users RC4 keys for cross-realm
trust which does not use the salt.
Once Simo fixed the salt in password_hash ldb module, we were able to
complete trust to FreeIPA in such way that MIT KDC was able to respond
on AS request for the interdomain TDO principal and SSSD on FreeIPA side
was able to use the resulting Kerberos session to authenticate with SASL
GSSAPI to Samba AD's LDAP to look up users and groups. The POSIX
attributes are managed by FreeIPA (UID/GIDs are autogenerated in this
deployment) but they can also be picked up from Samba AD.
We plan to work on remaining fixes to eventually get the full Samba AD
support in Fedora 24, but this represents a huge milestone in our four
year quest to make it a reality.
Thanks to everyone!
/ Alexander Bokovoy
In response to a bug about a missing dependency in the python-pyudev
packages, I thought I would look for and add the rest of the missing
dependencies as well, and hey, wow, what's all this GUI stuff doing in here.
pyudev includes modules for integrating with the main loops of glib,
pyqt4, pyside and wxPython. The requirements for those modules should
also be reflected in the spec file, but I'm not about to add Qt to, say,
boot.iso. If you use pyudev, I am going to make the following changes:
pyudev/glib.py moves to python2-pyudev-glib. There is no python3
equivalent since this module uses the old pygtk bindings.
pyudev/pyqt4.py moves to python-pyudev-qt4.
pyudev/pyside.py moves to python2-pyudev-pyside. There is no python3
version of PySide in Fedora.
pyudev/wx.py moves to python2-pyudev-wx. There is no python3 version of
wxPython in Fedora.
This does not affect any packages currently in Fedora which use pyudev,
which are blivet, solaar, tuned, and openstack-ironic-python-agent.