With the new upstream release python-ntplib-0.3.3 the license was
changed from LGPLv2+ to the MIT license. The only package that requires
python-ntplib seems to be anaconda which is not affected by the change,
but I'm rather letting you guys know.
Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic
I can see that RCs of development version of kernel are being built in rawhide.
Which is really great to test new stuff. But I would be pretty scared to run RC
Would it make sense then to also build latest stable releases?
E.g. now it would be 4.1.3. All I can see in koji is this 4.1.3 build  for f22.
During the review of cppformat, it was pointed out that it contained a font
that should be removed because it's packaged with Fedora (
https://bugzilla.redhat.com/show_bug.cgi?id=1216279#c3 ). While working on
resolving this, I was looking into what package provided this font so I
could add the appropriate Requires to get the font and noticed that quite a
few packages also include this font:
yum provides "*/glyphicons-halflings-regular.ttf"
Is this ok? And if not, then is there some way that a set of fedora-review
style audits could be run on existing packages to verify that these sorts
of things didn't accidentally slip through the original review or were
introduced in an update without being noticed?
- define the minimal install (continued)
- define the docker base image (continued)
- minimal disk image for importing into libvirt (continued)
- generic installer? (continued)
- Open Floor
Please add items by replying to this mail.
I originally sent this to the packaging list, but there was no
response there so I'm posting to devel now.
I've also opened a review request for the non-controversial packaging
of the "msed" utilities. Would anyone care to do a review swap?
Review Request: msed - Tools to manage the activation and use of self encrypting drives
Date: Tue, 21 Jul 2015 18:48:27 -0400
From: Chuck Anderson <cra(a)WPI.EDU>
Subject: [Fedora-packaging] building an embedded Linux distro into a RPM package
Reply-To: Discussion of RPM packaging standards and practices for Fedora <packaging(a)lists.fedoraproject.org>
I would like to submit a new package that provides a Pre-Boot
Authorization (PBA) image. The PBA is a "bootloader" of sorts that
prompts the user for the passphrase to unlock a Self-Encrypting Drive
(SED) using the TCG OPAL command set, and then either chainloads to
the real OS or reboots to allow the BIOS to boot the real OS. The
image gets installed to the OPAL SED as a sort of "shadow MBR/shadow
disk image" using a special command "msed" (Manage Self-Encrypting
Drive) that I also plan to submit a package for.
In my case, I've developed a tiny embedded Linux-based PBA image 
using Buildroot  and the MSED software . The final image is a
MBR-partitioned disk image with VFAT filesystem containing the
specially built Linux kernel (vmlinuz), initramfs (rootfs.gz), and the
installed syslinux bootloader.
Before you ask, I can't use even a stripped-down Fedora image for this
purpose, because it must be TINY and it only exists to run a single
command (linuxpba), then reboot. My image is 4MB and could be made
even smaller. See the reasoning in  for why it must be so small.
Now I know there are several challenges to using the Buildroot
approach to building software for Fedora. Buildroot downloads
software from the Internet, unpacks, patches, configures, and builds
it. The build environment is built first, so gcc, uClibc, busybox,
etc. and then the packages you want to include are built in that
What is the best approach I should use that is acceptable to Fedora?
Would it be acceptable to bundle source packages, Buildroot itself,
and my Buildroot configuration into one SRPM so everything is
self-contained and can be built without requiring network
connectivity? This means I would have to bundle the source code for
gcc, the linux kernel, uClibc, busybox, etc.
Or is there some way to pull in SRPM packages that already exist in
Fedora, and use those as part of my build process so that I don't have
to bundle all the source code? Additionally, I could made separate
SRPM packages for Buildroot itself, any components needed (uClibc is
already in the distro), the Buildroot build scripts for
buildroot-linuxpba, and the actual package I need (msed).