RAWHIDE USERS: BEWARE RPM 4.11.0-0.beta1.2.fc19!
by Panu Matilainen
Apologies for shouting but we have a genuine, rare, rpmdb-eating bug
(shade of dark paperbag) at hand:
DO NOT UPGRADE TO rpm-4.11.0-0.beta1.2.fc19!
The buggy version is expected to appear in todays rawhide-push. I've
built a new version where the broken %ghost-related patch is reverted
but there's a day-long danger-zone before the new build will be pushed.
It's best just to avoid upgrading to the buggy rpm version at all, but
if you have already happened to update to it one way or the other, DONT
PANIC but BACK UP /var/lib/rpm/ before anything else. Merely upgrading
to that version wont kill your rpmdb, but on the next update of rpm
itself, it will COMPLETELY ERASE /var/lib/rpm/ contents. Recovering
isn't exactly hard if you have an up-to-date backup, but otherwise...
- Panu -
11 years, 3 months
Proposed F19 Feature: Shared System Certificates
by Jaroslav Reznik
= Features/SharedSystemCertificates =
https://fedoraproject.org/wiki/Features/SharedSystemCertificates
Feature owner(s): Kai Engert <kaie(a)redhat.com>, Stef Walter <stefw(a)redhat.com>
Make NSS, GnuTLS, OpenSSL and Java share a default source for retrieving
system certificate anchors and black list information. This is an initial
but useful step in the direction of a comprehensive solution.
== Detailed description ==
The goal is to have a systemwide trust store of static data, that is used by
crypto toolkits as input for certificate trust decisions.
By default, the trust store will continue to contain the trust list as
published by the Mozilla CA Certificate list (but use of others are possible),
including positive and negative trust (blacklists). The system will allow
updating of the core Mozilla CA list. The trust list can be adjusted, added
to and overridden by administrators.
There will be a global directory that is scanned for input files, which will
include the RPM-package-owned Mozilla trust bundle, and which may contain
any number of additional files.
In order to achieve this, the following implementation would be used.
Much of the upstream implementation of this is p11-kit and can be shared with
other distros.
This initial implementation is a step towards a later more comprehensive
representation of locally stored trust policy information. The upstream
p11-kit project has more information on the long term concept.
p11-kit will provide a PKCS#11 trust module which provides trust information
based on a directory of certificates, some of which may have trust information
attached.
The PEM trusted certificate file format is supported here, as are others.
p11-kit will provide a tool to extract information from the PKCS#11 trust
module in the following formats:
Extract to a CA PEM bundle with TRUSTED CERTIFICATE information for OpenSSL.
Extract to a dirhash style directory for OpenSSL.
Extract to a CA bundle with plain certificates, for serverAuth,
clientAuth, etc.
Extract to the Java cacerts file.
This tool uses the PKCS#11 module as its source of trust information,
allowing future work to build off of this effort.
This tool is an interim bridge between OpenSSL, GnuTLS and Java until
they are able to read PKCS#11 trust information directly.
NSS: Uses the above PKCS#11 trust module directly to pull in trust information.
The PKCS#11 trust module is a drop in replacement for libnssckbi.so.
We can use update-alternatives to manage this drop in replacement.
NSS using applications would not need to be changed to work with this
module.
OpenSSL: p11-kit tool will extract trusted certificate PEM blocks from the
PKCS#11 trust module.
These extracted certificates will be placed in a location so that they
can be consumed by OpenSSL by default.
The aim is that neither OpenSSL nor OpenSSL applications will have to
be changed for this to work.
In the long term future we hope that we can build a bridge so that
OpenSSL can consume trust information directly from the PKCS#11 trust module.
GnuTLS: The p11-kit tool tool will extract a CA bundle to be used by GnuTLS
from the PKCS#11 trust module.
This CA bundle would be placed in the location where most GnuTLS
applications today are configured to use it.
It would pull out all the certificates that are trusted for serverAuth
since GnuTLS does not yet provide a way to consume detailed usage directly.
Black listed certificates would obviously not be included in this bundle.
We are working with GnuTLS can consume trust information from the PKCS#11
trust module in the future.
Java: The p11-kit tool will extract a Java compatible cacerts file from the
PKCS#11 trust module.
Again it is our aim that this changes later, once we can provide a bridge
for java to load trust information from PKCS#11.
The recurring theme is that the PKCS#11 trust module is the source of trust policy
information. Over time, (but not in this Fedora release) there will be:
Work done to both make the trust module have a comprehensive model of stored
trust policy.
Steps taken to make it possible to use GnuTLS, OpenSSL and Java directly with
that stored trust policy.
Obviously applications can continue to use their own CA list as appropriate,
for example in servers such as httpd or postfix.
For more information:
http://p11-glue.freedesktop.org/sharing-trust-policy.html
http://p11-glue.freedesktop.org/trust-module.html
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 3 months
Proposed F19 Feature: Yum Groups as Objects
by Jaroslav Reznik
= Features/YumGroupsAsObjects =
https://fedoraproject.org/wiki/Features/YumGroupsAsObjects
Feature owner(s): James Antill <james(a)fedoraproject.org>
Change the default yum configuration from group_command=compat to
group_command=objects.
== Detailed description ==
Currently yum groups work as a simple substitution, so "yum group remove foo"
works as though you took every package from foo and passed it to "yum remove".
This tends to not be what users expect, for example "yum group install kde-
desktop" and then "yum group remove kde-desktop" will end up removing packages
(like abrt-desktop). This feature changes that so that groups are installed as
real objects, meaning that when a user does "yum group install foo" yum will
mark that the packages from foo are being installed (as before) but also that
a group called foo is being installed and that those packages are installed
because of it. Later if the group is removed, yum will remove the group and
only those packages that were installed because of the group install/upgrade
commands.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 3 months
F18: Anaconda installer: Are there going to be any updates to this
by Terry Barnaby
I am trying to build a spin of Fedora18 for local use as I normally do with
Fedora releases using pungi. All has been built fine but the installation
fails with an Anaconda popup stating "The following error occurred ..." with
no information on the error at all and nothing in the various virtual terminal
windows.
Obviously the Anaconda installer is pretty rough at the moment.
1. Is there a good way to debug it ?
2. Are there likely to be updated releases of Anaconda during F18's life time ?
Cheers
Terry
11 years, 3 months
icu 50 rebuilt without --disable-renaming again
by Eike Rathke
Hi,
As there seems no proper way to resolve the mess of rhbz#856594
I rebuilt icu-50.1.2-3.fc19 without --disable-renaming again.
Please, if you built between Friday and today against icu-50.1.2-1.fc19
or icu-50.1.2-2.fc19 do another round against icu-50.1.2-3.fc19
Please accept my apology, I'm very unhappy with how this went.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
11 years, 3 months
Native vagrant packages for Fedora
by Ingvar Hagelund
Vagrant offers scripted provisioning and deployment of virtual
instances, removing the infamous "but it works om my laptop"
obstacle. Vagrant is well-known and much used and praised in the
devops community. Its home page is http://vagrantup.com/
Though VirtualBox is the current supported target, future versions of
vagrant may support other hypervizors as well, including kvm. Being in
itself free software under the MIT license, I think vagrant could be
included in fedora.
While an upstream rpm exists (putting all dependent packages in /opt)
a native fedora package of vagrant was missing. So I wrapped one up.
Review request: https://bugzilla.redhat.com/show_bug.cgi?id=905396
It depends on the following packages missing from fedora 18:
rubygem-log4r >= 1.1.9 < 2.0.0
Fix: Build new package.
Package review request:
https://bugzilla.redhat.com/show_bug.cgi?id=905240
rubygem-childprocess >=0.3.1 < 0.4.0 (0.3.6 in rawhide)
Fix: Grab 0.3.6 package from rawhide
rubygem-json >= 1.5.1, < 1.6.0 (1.6.5 in f18, 1.9.1 in rawhide)
Fix: Build rubygem-json15, roughly based on current package.
Package review request:
https://bugzilla.redhat.com/show_bug.cgi?id=905389
rubygem-net-ssh >= 2.2.2 < 2.3.0 (2.2.1 in rawhide)
Fix: Build 2.2.2 package based on current package.
Update request: bz https://bugzilla.redhat.com/show_bug.cgi?id=905393
yum repo with prebuilt packages for f17 and f18 available here:
http://users.linpro.no/ingvar/vagrant/
Ingvar
11 years, 3 months
Strange subscriptions to Bugzilla bugs
by Tim Niemueller
Dear Fedorians and Bugzilla admins.
In the recent past I have seen several subscription to bugs in Bugzilla.
While this is normal, what makes me suspicious is that it is one
particular email address (rutadeevacuacion...) to rather old bugs, e.g.
124789 or 446335, bugs which are already closed. Similar things seem
to have been reported on Ubuntu (cf.
http://irclogs.ubuntu.com/2008/11/21/%23launchpad.txt, found googling
for the full mail address).
To me it looks like someone or some organization is registering to
random bugs to get a hold on email addresses or the like. Is someone
else seeing similar actions or find this also suspicious?
Maybe someone with admin privileges on Bugzilla can have a look through
the database to check for strange behavior of that user?
Regards,
Tim
11 years, 3 months
cogl soname bump
by Peter Robinson
Hi All,
Sorry, I missed the cogl soname bump when I pushed the build last
night, I'll work to rebuild associated deps now, any help appreciated.
Peter
11 years, 3 months
Heads-up: cyrus-sasl-2.1.26 with libsasl2 soname bump
by Petr Lautrbach
Hi all,
I'm going to push update cyrus-sasl-2.1.26 into Rawhide soon. Part of this update
is also SONAME bump to libsasl2.so.3.
The main issue with this update is that it would break buildroot since there is the openldap
package requiring libsasl2.so.2 which is part of buildroot. So I'll do needed steps in co-operation
with Jan Vcelak - the openldap maintainer - in order not to break it.
There are also several other packages dependent on libsasl2.so.2 [1], which will need rebuild.
It's my understanding that there will be mass rebuild soon so I wouldn't rebuild all of them manually,
but I would wait for this rebuild.
Comments? Suggestions?
Thanks,
Petr
[1] # repoquery -s --whatrequires --alldeps 'libsasl2.so*' | uniq
389-admin-1.1.31-1.fc19.1.src.rpm
389-ds-base-1.3.0.2-1.fc19.src.rpm
389-dsgw-1.1.9-3.fc18.src.rpm
argus-3.0.4-3.fc18.src.rpm
autofs-5.0.7-10.fc19.src.rpm
claws-mail-3.9.0-1.fc19.src.rpm
cyrus-imapd-2.4.17-1.fc19.src.rpm
cyrus-sasl-2.1.25-2.fc19.src.rpm
ekiga-4.0.0-2.fc19.src.rpm
evolution-data-server-3.7.4-1.fc19.src.rpm
exim-4.80.1-1.fc19.src.rpm
freeipa-3.1.0-1.fc19.src.rpm
gtk-vnc-0.5.1-5.fc19.src.rpm
kdebase3-3.5.10-21.fc18.src.rpm
kdepim-4.9.97-1.fc19.src.rpm
kdepimlibs-4.9.98-1.fc19.src.rpm
libetpan-1.1-3.fc18.src.rpm
libguestfs-1.21.2-2.fc19.src.rpm
libmemcached-1.0.15-1.fc19.src.rpm
nufw-2.4.3-6.fc18.src.rpm
pidgin-2.10.6-4.fc19.src.rpm
libvirt-1.0.1-4.fc19.src.rpm
mozldap-6.0.5-9.fc18.src.rpm
mutt-1.5.21-16.fc19.src.rpm
myproxy-5.9-2.fc19.src.rpm
nss_ldap-265-10.fc17.src.rpm
nufw-2.4.3-6.fc18.src.rpm
openldap-2.4.33-3.fc19.src.rpm
php-5.4.11-1.fc19.src.rpm
postfix-2.9.5-2.fc19.src.rpm
ptlib-2.10.9-1.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
qca-cyrus-sasl-2.0.0-0.4.beta3.fc18.src.rpm
qemu-1.3.0-3.fc19.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
rinputd-1.0.5-1.fc19.src.rpm
ruby-qpid-0.8-7.fc18.src.rpm
qpid-cpp-0.18-5.fc19.src.rpm
saslwrapper-0.16-2.fc18.src.rpm
samba-4.0.1-1.fc19.src.rpm
sendmail-8.14.6-2.fc19.src.rpm
spice-gtk-0.16-1.fc19.src.rpm
spice-0.12.2-2.fc19.src.rpm
squid-3.2.5-1.fc19.src.rpm
subversion-1.7.8-3.fc19.src.rpm
11 years, 3 months
icu 50 soname bump
by Orion Poplawski
FYI - Looks like icu 50 landed in rawhide today with the usual soname bump
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11 years, 3 months