devel November 2015

devel@lists.fedoraproject.org

228 participants
281 discussions

DNF 1.0.1 Released
by Honza Silhan 04 Feb '16

04 Feb '16

The new release brings fixes of the most occurred errors in Fedora 22. Moreover adds SSL support in repository configuration and random sleep dnf-automatic feature. Read more in 1.0.1 release notes [1] on DNF documentation page, try it from testing and give it a karma. [1] http://dnf.readthedocs.org/en/latest/release_notes.html#id44 [*] http://dnf.baseurl.org/2015/06/12/dnf-1-0-1-released/ Honza by DNF team

9 20

Build root prepared by DNF is way larger
by Vít Ondruch 27 Jan '16

27 Jan '16

Hi all, Today, I noticed that mock build root prepared by DNF is significantly larger then prepared by YUM (see attached logs). Owners of packages installed into minimal buildroot probably wants to review their dependency chain. I also reported the issue against DNF [1] in case DNF guys wants to improve this situation. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=1254634

10 17

Updating hdf5 to 1.8.16 in rawhide soon
by Orion Poplawski 22 Jan '16

22 Jan '16

I'll be updating hdf5 to 1.8.16 in rawhide in the next few days. This includes a soname bump for the C++ wrapper libs, but as usual I'll be rebuilding all deps due to run-time version checking by the library. bes-3.14.0-7.fc24.src.rpm CBFlib-0.9.5.4-1.fc23.src.rpm cgnslib-3.2.1-5.fc23.src.rpm engrid-2.0.0-0.8.gitbaef0ce.fc24.src.rpm Field3D-1.6.1-8.fc24.src.rpm gdal-2.0.1-2.fc24.src.rpm gdl-0.9.5-10.fc24.src.rpm gpaw-0.11.0.13004-16.fc24.src.rpm grads-2.0.2-13.fc23.src.rpm gtatool-2.1.0-9.fc24.src.rpm h5py-2.5.0-5.fc24.src.rpm InsightToolkit-4.8.2-1.fc24.src.rpm jhdf5-2.11.0-3.fc23.src.rpm kst-2.0.8-4.fc23.src.rpm libASL-0.1.6-1.fc24.src.rpm mathgl-2.3-11.fc24.src.rpm matio-1.5.2-7.fc23.src.rpm med-3.0.8-4.fc23.src.rpm mrpt-1.3.0-2.fc24.src.rpm ncl-6.3.0-6.fc24.src.rpm netcdf-4.3.3.1-7.fc24.src.rpm octave-4.0.0-7.fc24.src.rpm octave-communications-1.2.1-1.fc23.src.rpm OpenImageIO-1.5.20-2.fc24.src.rpm paraview-4.4.0-2.fc24.src.rpm python-tables-3.2.2-2.fc24.src.rpm R-Rsolid-0.9.31-16.fc23.src.rpm scilab-6.0.0-0.2.alpha1.fc24.src.rpm shogun-4.0.1-0.1.git20150808.779c3ad.fc24.src.rpm vigra-1.10.0-15.fc24.src.rpm vips-8.1.1-2.fc24.src.rpm ViTables-2.1-12.fc23.src.rpm vtk-6.3.0-2.fc24.src.rpm -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

3 13

Testing chrony seccomp support
by Miroslav Lichvar 22 Jan '16

22 Jan '16

In chrony 2.2-pre1 was added support for system call filtering with the kernel seccomp facility. In chrony it's mainly useful to reduce the damage from attackers who can execute arbitrary code, e.g. prevent gaining the root privileges through a kernel vulnerability. The rawhide chrony package is now compiled with the seccomp support, but the filtering is not enabled by default. The trouble is it has to cover all system calls needed in all possible configurations of chrony and all libraries it depends on, which is difficult and it may even change over time as the libraries are updated. I'm interested to know if this works in other configurations than what I tried, especially non-default NSS configurations, and get an idea if this could be enabled by default at some point. If you would like to help with the testing: 1. echo 'OPTIONS="-F -1"' > /etc/sysconfig/chronyd 2. systemctl restart chronyd 3. occasionally check if chronyd is still running If you see in the log that the process was killed with status=31/SYS, it's a problem in the seccomp support. Please let me know it has crashed for you. Unfortunately, abrt doesn't seem to catch these crashes, even when /proc/sys/fs/suid_dumpable is set to 2. For F22 and F23 there is a COPR repo with packages built from the current development code: https://copr.fedoraproject.org/coprs/mlichvar/chrony/ Thanks, -- Miroslav Lichvar

8 30

/etc/os-release VARIANT_ID in Bugzilla bugs opened by ABRT
by Jakub Filak 11 Jan '16

11 Jan '16

Hello, some time ago, Stephen Gallagher approached ABRT team with a request to include /etc/os-release and especially VARIANT_ID in the Bugzilla bugs opened by ABRT. We have decided to put this information into Whiteboard in this form: "VARIANT_ID=$id;" Here is the list of Fedora 23 bugs for Workstation: https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&list_id=39537… , Server: https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&list_id=39536… and Cloud: https://bugzilla.redhat.com/buglist.cgi?classification=Fedora&list_id=39536… Regards, Jakub ABRT team

2 4

New package distribution-gpg-keys
by Miroslav Suchý 06 Jan '16

06 Jan '16

Hi, I created new project distribution-gpg-keys: https://github.com/xsuchy/distribution-gpg-keys There are various GPG keys used to sign RPM packages. Right now: * centos * epel * fedora * redhat * rpmfusion In future I will try to add all Copr gpg keys. If you find it useful too, you can do package review: https://bugzilla.redhat.com/show_bug.cgi?id=1272235 Mirek Suchy

9 12

Supporting Python 3 in EPEL 7
by Randy Barlow 30 Dec '15

30 Dec '15

Hello! I recently added the package python-rpdb to F22/23/rawhide. The build failed in Koji due to having a BuildRequires on python3-devel. It seems that it is called python34-devel in EL 7. This leads me to wonder on a few things: 0) Should I call my package python34-rpdb in EL 7 for consistency? There don't seem to be very many Python 3 packages for EL 7 at all (yum search only found a handful) but it seemed that there are a few doing this. Alternatively, I could just build the python2 package. 1) What is the recommended strategy for handling my spec file if I attempt to do different things in EL 7 than I do in F22+? I had considered just making this change to the spec file in that branch, but since this would require raising the release it could make upgrade from EL 7 to EL 8 tricky if the package version doesn't change upstream. Is it better to use if statements in the spec file? I like the idea of very clean spec files that work on one specific release, but on the other hand I do see the potential for upgrading to be disrupted. I found this snippet: https://fedoraproject.org/wiki/Package_maintenance_guide?rd=Using_git_FAQ_f… Is that saying that it is OK for me to avoid the if statements and just make the epel7 branch's spec file provide and require the 34 packages and the .1 will make the upgrade path OK? I'm new to Fedora packaging, so apologies if I've missed the answer to this question in an obvious place. -- Randy Barlow xmpp: bowlofeggs(a)electronsweatshop.com irc: bowlofeggs on Freenode

5 4

Retire a package from Fedora i686 (not x86_64)
by Germano Massullo 21 Dec '15

21 Dec '15

I just removed 32bit CPU support from Darktable's spec file due technical reasons. Are there any other things I need to clean up in Fedora infrastructure?

20 73

orphaning radiusclient-ng
by Nikos Mavrogiannopoulos 18 Dec '15

18 Dec '15

Hello, I'll orphan radiusclient-ng with the purpose of dropping it from the next releases of Fedora. This is an old unmaintained library replaced by any of the following packages (the latter has an API compatible subpackage). * https://admin.fedoraproject.org/pkgdb/package/freeradius-client/ * https://admin.fedoraproject.org/pkgdb/package/radcli regards, Nikos

1 1

F24 System Wide Change: Default Local DNS Resolver
by Jan Kurik 17 Dec '15

17 Dec '15

= Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): * P J P <pjp AT fedoraproject DOT org> * Pavel Šimerda <pavlix AT pavlix DOT net> * Tomas Hozza <thozza AT redhat DOT com> * Petr Špaček <pspacek AT redhat DOT com> Plain DNS protocol is insecure and therefore vulnerable from various attacks (e.g. cache poisoning). A client can never be sure that there is no man-in-the-middle, if it does not do the DNSSEC validation locally. We want to have Unbound server installed and running on localhost by default on Fedora systems. Where necessary, have also dnssec-trigger installed and running by default. Unbound and dnssec-trigger will be properly integrated with the default network configuration manager (e.g. NetworkManager for Fedora Server and Workstation) and with the graphical user interface (especially GNOME). The localhost address will be the only record in /etc/resolv.conf and no other software except dnssec-trigger will be allowed to change its content. == Detailed Description == Plain DNS protocol is insecure and therefore vulnerable from various attacks (e.g. cache poisoning). DNSSEC is a DNS extension which enabled the client to verify the DNS query response and make sure there is no attacker to spoof some records. A user connected to network usually receives a set of resolvers from DHCP, which should be used for name resolution. These resolvers may also do the DNSSEC validation. However a client can never be sure that there is no man-in-the-middle, if it does not do the DNSSEC validation locally. Purpose of this Fedora change is to have a validating DNS resolver installed on Fedora systems by default. This includes necessary discussions, coordination and integration with other components installed on Fedora by default. There are growing instances of discussions and debates about the need for a trusted local validating DNS resolver. There are multiple reasons for having such a resolver, most importantly security and usability. Security and protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide. People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation, as currently there is no way to establish such trust. Apart from trust, these name servers are often known to be flaky and unreliable which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local validating DNS resolver not only makes sense but is, in fact, badly needed. It has become a need of the hour. (See: [1], [2], [3]) All DNS literature strongly recommends it and amongst all discussions and debates about the issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It will simplify and facilitate a lot of other design decisions and application development in the future. (See: [1], [2], [3]) [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html == Scope == Proposal owners: Proposal owners shall have to * define the syntax and semantics for new configuration parameters/files. * properly document how to test and configure the new default setup * persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications. * discuss with WGs in which products the change makes sense and what are the expectations of WGs for different Fedora products * resolve interoperability issues for Docker and other containers use-cases Other developers: (especially NetworkManager and the likes) * NetworkManager has to implement notifications on connectivity state changes * Gnome Shell has to use the connection provided resolvers (fetched directly from NM) for Hot-Spot login purposes * Ideally other developers and user should test their software and application in this setup and verify that it is working as expected Release engineering: * Make sure that the necessary packages (dnssec-trigger, unbound) are part of the composes for the appropriate Fedora Products. * Add services needed for the setup into the default presets (dnssec-triggerd.service) Policies and guidelines: * Any software, including NetworkManager, will have to be configured to not tamper with the content of '/etc/resolv.conf' by default. The connection-provided resolver entries should be stored in a separate configuration file or in memory and accessible via some API. -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel-announce@lists.fedoraproje…

36 92

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel November 2015