For one package for which I am part of upstream, we are talking about
adding TLS support. The upstream project is GPLv3+. We're looking at
the preferred list of crypto implementations on
http://fedoraproject.org/wiki/FedoraCryptoConsolidation and have a
couple of questions.
The most preferred option is NSS, which is MPLv2.0. The license list
says that MPLv2.0 is "sometimes" compatible with GPLv3. If I'm
reading the MPLv2.0 page correctly, then compatibility is strictly a
function of the MPL-licensed package. In that case, wouldn't it make
sense for us to have two license tags for our RPMs:
MPLv2.0-GPL-compatible and MPLv2.0-GPL-incompatible? (Not necessarily
with those names, of course.) As it is, anyone in our situation has
to independently evaluate the MPLv2.0 package to figure out whether it
is GPL compatible or not. (The NSS source code fortunately contains a
note on GPL compatibility.)
The second option is gnutls, which is various flavors of GPL and LGPL,
and so is fine for us. We did have one developer wonder why gnutls is
preferred over openssl, though. Can anyone answer that question?
The third option is OpenSSL, whose license is GPL-incompatible, and so
not an option for us.
The fourth option is libgcrypt, which is LGPLv2+, and so is fine for
us in terms of license (haven't looked at available functionality
Our plan, then, is to add an abstraction layer to hide the
implementing library, and prepare implementations for nss, gnutls, and
libgcrypt if it isn't too much work. Does this seem reasonable?
my name is Petr and I'm part of FreeIPA development team for over 2
years. My main focus is on its Web UI and web apps in general.
As my first Fedora package I submitted Open Sans fonts:
That said, I'm seeking a sponsor for this.
-----BEGIN PGP SIGNED MESSAGE-----
Final TC3 images have been uploaded to EC2 and are available at
ami-c17858a8 : us-east-1 image for i386
ami-6578580c : us-east-1 image for x86_64
additionally if your looking to the AMI's they have been added to files
in the release tree
when we get to final and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
Being on the test kernel - or, more likely, using a more stable one from
the list that is compiled - is probably the answer to the issue: how am I
to watch a VOB file?
Linux 3.11.9-300.fc20.x86_64 #1 SMP Wed Nov 20 22:23:25 UTC 2013 x86_64
My employer, ONELAN, have been using Fedora as a baseline Linux system for our
products for a while now, and I've just hit a situation where no-one's
packaging gstreamer1-python, but we're going to start depending on it.
Rather than just keep my packaging work to myself, I'm volunteering to
maintain this package within Fedora, so that everyone can benefit from it,
including ONELAN (who will hopefully see the quality of the package improve as
I learn from you guys).
IIRC fedora-review suggested to test packages on all sup-
ported Fedora releases. So, with a larger hard disk, I want
to install Fedora 19, 20 (soon) and Rawhide and throw in
(recent) Debian and Ubuntu as well. As my notebook doesn't
support VMs, I'm interested in best practices for partition-
ing and multi-boot setups.
Currently I use a partition for /boot and another for an en-
crypted LVM, so I only need to worry not to put private data
in /boot, and I would like to keep such flexibility.
I suppose I need to create a /boot partition for each ver-
sion/OS. I have had different Fedora versions share the
same encrypted LVM without problems; I assume Debian and
Ubuntu will do so as well, but I will keep some free space
and partitions just in case.
More contested seems to be the multi-boot setup.
https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a
myriad of opinions on how it should be set up;
suggests "chainloader", and
recommends "configfile". Of course there is also GRUB's OS
So what are Fedora developers /actually/ using? Creating a
separate GRUB partition and "chainloader"/"configfile"?
Running OS prober in the "main" OS after each installation/
kernel update? Something else? How often do the setups al-
low one to shoot oneself in the foot, or are they (more or
Thanks in advance,
while cleaning up retired packages (which I did not yet finish), I came
up with an idea to simplify the retirement procedure to avoid
inconsistencies. With the help of fedmsg I would like to make it enough
wrt to koji and pkgdb to add a dead.package file to dist git to
retire a package. When this happens, an automated process will retire
the package in pkgdb and block the package in koji. This will make
it impossible to only dead.package or only retire a package in pkgdb.
To avoid problems with lost messages from fedmsg, a regular cleanup job
can download a git checkout and check for any missed dead.package files.
What are your opinions about this? I already checked with Dennis
Gilmore, he is ok with this.
My plan is to first setup a service that triggers the retirement in
pkgdb and when this seems to work ask Infrastructure do disable retiring
packages for regular users in pkgdb.