Updating hdf5 to 1.8.16 in rawhide soon
by Orion Poplawski
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
6 years, 3 months
Testing chrony seccomp support
by Miroslav Lichvar
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
6 years, 3 months
Supporting Python 3 in EPEL 7
by Randy Barlow
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...
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
6 years, 4 months
F24 System Wide Change: Default Local DNS Resolver
by Jan Kurik
= 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.fedorapro...
6 years, 5 months
Can Koji handle a soname change and a self-dependency?
by Björn Persson
Is there a way to deal with the following situation in Koji?
· Build tool B has a build-time dependency on itself.
· B is linked to library L version 1.
· L gets upgraded to version 2, which changes its soname.
B needs to be rebuilt to link to libL.so.2, but building B requires a
working B, which requires libL.so.1 because it hasn't been rebuilt yet.
As I understand it, when the L-2 package goes into the buildroot it
immediately replaces L-1. Is there a way to keep L-1 available until B
has been rebuilt?
Is the answer to link B statically?
Björn Persson
6 years, 5 months
Fedora 23 cloud image (and, for that matter, minimal anything) bloat
by Matthew Miller
Fedora-Cloud-Base-20141203-21.x86_64.qcow2: 151M
Fedora-Cloud-Base-23_Beta-20150915.x86_64.qcow2: 275M
In just one year — 82% more awesome?
I'd really like this to stay below 200MB as a competitive threshold.
Or, if we're going to be bigger than that, be bigger for REASONS, not
just accretion.
tl;dr: grub2 is a lot to blame, but there seem to be some new
questionable dep chains from systemd, and general dep growth across the
board.
Disk use at first boot:
[f21]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 359M 19G 2% /
[f23b]$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 20G 578M 19G 4% /
RPMs installed:
[f21]$ rpm -qa | wc -l
226
[f23b]$ rpm -qa | wc -l
264
Top 20 rpms by reported size:
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
120417342 glibc-common
42307839 kernel-core
25000497 python-libs
22438155 systemd
14623272 coreutils
14000291 glibc
11282056 ruby-libs # hey, at least we lost this
10845519 glib2
10593004 selinux-policy-targeted
9389116 cracklib-dicts # https://bugzilla.redhat.com/show_bug.cgi?id=865521
9078043 python-boto
8792531 util-linux
7084188 bash
6669884 gnupg2
5844544 yum
4893790 policycoreutils
3786564 file-libs
3540004 shadow-utils
3458312 groff-base # who doesn't love groff?
2997717 tar
$ rpm -qa --qf '%{size} %{name}\n'|sort -nr|head -20
125195206 glibc-common
86298752 linux-firmware # sadface, but hard
53291365 kernel-core
36004297 grub2-tools # this is ridiculous
28453336 python3-libs # 13% growth
27233273 systemd # 21% growth
16648994 grub2 # *sigh*
14486819 glibc
14287847 coreutils # this package got _smaller!_
11143743 glib2
11129880 selinux-policy-targeted
9389116 cracklib-dicts
9261499 python3-boto
9237998 util-linux
9224255 fedora-logos # this is also grub's fault.
7517574 gnupg2
7143418 bash
6574678 python3-pip # :(
5888883 hwdata # this is ALSO grub's fault
5423400 xkeyboard-config # really???? looks like a systemd dep chain
involving plymouth
Okay, let's look on disk:
[f21]$ sudo du -sh * 2>/dev/null|sort -h
[...]
36K home
40K root
228K run
21M boot
22M etc
34M var
276M usr
[f23b]$ sudo du -sh * 2>/dev/null|sort -h
[...]
40K root
264K run
16M etc
45M boot # ugh
171M var # oww
463M usr # oww oww oww
Breakdown:
- boot is mostly grub, but initramfs is also doubled
- var: DNF cache is full of stuff! 123M... oh, hey, that wasn't
there when we booted. `df -h /` is now up to 702M. Maybe multiple
repos would help here, or some other more clever design. Does
every cloud image in the world _really_ need to replicate
dependency data so I can `dnf install
/usr/share/minetest/builtin/mainmenu/init_simple.lua`?
- usr:
* linux-firmware is the biggest thing here
* python3 is another good chunk
* also kernel modules, but, eh, whatchagonnado
* oh, and of course, grub2.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
6 years, 5 months
