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
4 years
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...
4 years, 1 month
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
4 years, 1 month
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
4 years, 1 month
Dealing with rolling release versioning
by Richard Shaw
I have a project that stopped providing versioned releases and went to a
rolling release model using the date.
In this case these are not "pre" or "post" releases or snapshot releases.
Is there any reason not to use the date as the version? It's in YYYYMMDD
format so there shouldn't be a upgrade path issue but this isn't explicitly
covered in the packaging guidelines that I can find.
Thanks,
Richard
4 years, 1 month
F24 System Wide Change: Fedora 24 Boost 1.60 uplift
by Jan Kurik
= System Wide Change: Fedora 24 Boost 1.60 uplift =
https://fedoraproject.org/wiki/Changes/F24Boost160
Change owner(s):
* Jonathan Wakely < jwakely AT redhat DOT com >
This change brings Boost 1.60.0 to Fedora 24. This will mean F24 ships
with the latest upstream Boost release.
== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boostese seen in output from g++. Such care is to be expected
this time around as well.
Boost 1.60 is scheduled for release on 2 Dec 2015 and a beta release
is already available for testing
The equivalent changes for previous releases were Fedora 22 Change and
Fedora 23 Change.
== Scope ==
Proposal owners:
* Build will be done with Boost.Build v2 (which is upstream-sanctioned
way of building Boost)
* Request a "f24-boost" build system tag (discussion):
https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
* Build boost into that tag (take a look at the build #606493 for inspiration)
* Post a request for rebuilds to fedora-devel (XXX link to
fedora-devel message here)
* Work on rebuilding dependent packages in the tag.
* When most is done, re-tag all the packages to rawhide
* Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).
In order to discover any problems ASAP the proposal owner has created
a COPR and built the Boost 1.60.0 beta, and started rebuilding the
300+ dependent packages. The results of this COPR will be thrown away,
but it means any bugs in the upstream release can be reported and
fixed before the final release (rather than patched in the Fedora
package) and any changes needed in dependent packages will be known
sooner.
Other developers:
Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.
The proposal owner has already started test rebuilds of affected
packages and identifying the needed changes, and will propose patches
to Boost upstream or to the client packages' upstreams as appropriate.
Release engineering:
* Side tag creation.
List of deliverables:
* All deliverables will include updated Boost packages
Policies and guidelines:
* Apart from scope, this is business as usual, so no policies, no guidelines.
Trademark approval:
* N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
4 years, 1 month
Freerdp update with bundle in guacamole-server
by Pavel Alexeev
Hello.
More than half year in the past freerdp was updated and then reverted
version to current present [1], mostly to allow built guacamole-server [2].
As I see it still stick with that version.
Meantime freerdp move forward. Remmina, which require fresh versions of
freerdp also can't be updated.
Recently our bundling policy changed [3].
From freerdp depends:
$ dnf repoquery --source --alldeps --whatrequires freerdp-libs
...
freerdp-1.2.0-0.9.git.24a752a.fc23.src.rpm
guacamole-server-0.9.7-1.fc23.src.rpm
medusa-2.2-0.rc1.2.fc23.1.src.rpm
remmina-1.2.0-0.8.git.b3237e8.fc23.src.rpm
vinagre-3.18.1-1.fc23.src.rpm
vlc-2.2.2-0.1.fc23.src.rpm (rpmfusion.org)
weston-1.9.0-1.fc23.src.rpm
$ dnf repoquery --source --alldeps --whatrequires freerdp
...
krdc-15.04.2-2.fc23.src.rpm
Today I have try build freerdp [4] from master and all dependencies
against it.
And again, *only* guacamole-server fails to build with:
In file included from rdp_stream.h:29:0,
from rdp_fs.c:27:
rdp_svc.h:28:38: fatal error: freerdp/utils/svc_plugin.h: No such file
or directory
compilation terminated.
It relied on old svc_plugin which has been rid in 2013 year [5].
Main question. Is it a good reason to bundle copy of current version
freerdp into guacamole-server (at least until someone do not willing
port it) and update it for rest of Fedora?
I have not tried to do such bundle yet, but if no one argue I could try
do that with update freerdp and rebuild all other deps too.
[1] https://lists.fedoraproject.org/pipermail/devel/2015-March/209140.html
[2] https://lists.fedoraproject.org/pipermail/devel/2015-March/209181.html
[3] https://fedorahosted.org/fpc/ticket/575
[4] https://github.com/FreeRDP/FreeRDP
[5] https://github.com/FreeRDP/FreeRDP/pull/1574
--
With best wishes, Pavel Alexeev.
Yes, I'm a fool - I believe in people, honesty, goodness and justice.
And also in the fact that I can make this world just a little better
unless stop fighting.
http://hubbitus.info
4 years, 1 month
