HEADS UP: shapelib soname bump
by Sandro Mani
Hi
I'm preparing the shapelib-1.4.0 update, which bumped the soname. There
are no API changes, it was just to synchronize with the debian soname.
Dependent packages are:
gpsbabel-0:1.5.3-4.fc24
grads-0:2.0.2-18.fc26
librecad-0:2.1.0-1.fc25
marble-widget-qt5-1:16.08.3-1.fc26
plplot-libs-0:5.11.1-5.fc25
I'll need help rebuilding the above packages.
Thanks
Sandro
4 years, 2 months
F26 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik
= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Change owner(s):
* Michal Cyprian <mcyprian AT redhat DOT com>
* Petr Viktorin <pviktori AT redhat DOT com>
* Tomas Orsava <torsava AT redhat DOT com>
* Miro Hroncok <mhroncok AT redhat DOT com>
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the sys.prefix setting in the /usr/bin/python3 executable from /usr/
to /usr/local. pip3 will thereafter use this prefix when determining
where to install modules. In addition, the original path
/usr/lib/pythonX.Y/site-packages will be added to the sys.path
variable (so that modules at that location are still processed when
importing), because this path will not be automatically scanned
anymore as it no longer lies inside the sys.prefix path. These
settings, however, will not be modified for the system-python binary,
and the %{__python3} macro will be changed from /usr/bin/python3 to
/usr/libexec/system-python. Therefore, Python dnf packages will
continue to be built with the correct installation path for system
modules.
Note that using sudo pip3 is not strictly necessary, as using pip3
install --user would satisfy the vast majority of use cases.
Nevertheless, sudo pip is far too prevalent an instruction in various
guides and installation notes throughout the Internet that there is
little hope of changing users' behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the Python 3 executable as described above.
Modify the %{__python3} macro so that it points to /usr/libexec/system-python
* Other developers:
Spec files that use pip3 install without the use of a macro will need
to be modified accordingly. Only 3 like packages were identified
(python-flit, python-entrypoints, python-setuptools).
* Release engineering:
A rebuild of all Python packages will be necessary.
* List of deliverables:
All Fedora deliverables will be affected in a minor way that does not
jeopardize their delivery.
* Policies and guidelines:
The definition of the %{__python3} macro will be updated as mentioned above.
* Trademark approval:
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, 2 months
Changing default "docker" storage to to Overlay2 in Fedora 26
by Daniel J Walsh
Upstream docker is moving to overlay2 by default for its storage. We
plan on following suit. Their are some performance advantages of
overlay2 over devicemapper in memory sharing, which we would like to
take advantage of. We now have SELinux support for Overlay file
systems, so the security should be just as good.
Note: Overlay is not a Posix Compliant file system, so their could be
problems with your containers running on overlay, so
we want to make sure it is fairly easy to switch back to devicemapper.
Devicemapper out of the box, on Fedora Workstation, currently defaults
to loopback devices for storage, which has a performance penalty, but
this was the only way we were able to get docker to work right away.
Switching to overlay2 will cause the storage to be shared with / and
will eliminate this performance overhead. This is the way we will ship
Fedora Workstation.
On Fedora atomic host and Fedora server we have been storing
devicemapper storage on a separate partition. We plan on doing the same
thing with overlay2. This means separate device will be mounted on
/var/lib/docker. This will make it easier for someone to switch back to
devicemapper, if overlay2 has problems.
Upgraded systems will not be effected.
If you want to switch from one storage to another take a look at the
`atomic storage` commands.
We will write up release notes to cover this change. Along with a blog
explaining the commands to switch back and forth.
4 years, 2 months
F26 System Wide Change: Enable TRIM pass down to encrypted disks
by Jan Kurik
= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
Change owner(s):
* Vratislav Podzimek <vpodzime AT redhat DOT com>
* Ondrej Kozina <okozina AT redhat DOT com>
Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.
== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.
We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.
For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.
Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.
For rotational devices the cost of enabled discard is negligible
== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.
* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.
* Release engineering:
N/A
* List of deliverables:
N/A
* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.
* Trademark approval:
N/A
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
4 years, 2 months
Are partial upgrades expected to work in rawhide?
by Florian Weimer
We received a bug report that generated RPM dependencies are too coarse
in rawhide (#1409557).
The bug report is correct at a technical level. But I assumed that it
was not a problem because partial upgrades are in rawhide are not
supported—it's always all-or-nothing.
Comments?
Thanks,
Florian
4 years, 2 months
[Verification] FOSDEM speakers
by Dhanesh B. Sabane
Aloha Fedora people!
FOSDEM 2017 is just around the corner and CommOps is trying to compile a list of all Fedora related talks.[1] Here's our version of the list, put together by Alberto [bt0dotninja]:
1. jflory7:
* What open source and J.K. Rowling have in common, Importance of storytelling in open source projects
2. spot:
* A discussion of Fedora's Legal state, This is why I drink.
3. bee2502:
* Making Wiki Gardening Tasks Easier Using Big Data and NLP
* I contributed ! But what now ?, This talk will be about methods to improve contributor retention rates in your FOSS community.
4. pbrobinson
*Using a generic distro to redefine IoT
5. asamalik/psabata
* Modularity & Generational Core, The future of Fedora?
6. misc
* Desktop security, keeping the key to the castle safe
* Replacing Dockerfiles with Ansible-containe
* When configuration management meet SDN
* Privacy in practice for self hosting
7. pocock
* SDR, Ham Radio and the Debian Hams project
* Fundraising and Crowdfunding for FreeRTC
8. lalatendu
* The Easiest Way to Start Developing with Openshift
9. elioqoshi
* Mozilla Open Design, What we learned in 2016
10. cwickert
*Writing Open Source Documentation for Open Source Projects
11. byte
* The Proxy Wars - MySQL Router, ProxySQL, MariaDB MaxScale
* Distributions from the view of a package
12. gdha
* Relax-and-Recover Automated Testing
* Future ideas for ReaR, DRLM, and Bareos
13. rfenkhuber
* Pet-VMs and Containers united?
14. bmbouter
* Debugging Hung Python Processes with GDB
15. kshlm
* The next generation of GlusterFS management
16. mjw
* fortification vs memcheck
* Valgrind BoF and Hackaton
17. ueno
* Smart card forwarding
18. czanik
* Scaling your logging infrastructureusing syslog-ng
* Get the most out of your security logsusing syslog-ng
19. msivak
* VM: Hey VM, can I share a host with you?
20. eseyman
* Schema, Database Documentation Through Introspection
21. rtnpro
* Taking containers from development to production
All Fedora speakers at FOSDEM are requested to double-check this list and report discrepancies, if any, by commenting on the ticket or replying to this mail. You can also have a look at the fosdemSpeakersFinal.csv file[2].
[1] https://pagure.io/fedora-commops/issue/98
[2] https://pagure.io/fedora-commops/issue/raw/files/aab71c065fc29bec3b40f5d7...
--
Dhanesh B. Sabane [dhanesh95]
dhanesh95.gitlab.io
4 years, 2 months
F26 System Wide Change: Python Classroom Lab
by Jan Kurik
= System Wide Change: Python Classroom Lab =
https://fedoraproject.org/wiki/Changes/PythonClassroomLab
Change owner(s):
* Miro Hrončok <mhroncok AT redhat DOT com>
* SIGs/Python <python-devel(a)lists.fedoraproject.org>
A new Python Classroom Lab will be created in 3 variants: Workstation
based, Docker based and Vagrant based. It's an important step for our
Fedora Loves Python initiative. The main audience are Python teachers
and workshop instructors.
== Detailed Description ==
A new comps packages group with Python development tools will be
created and a new Lab (or Spin) for teaching Python or Python related
topics will be available from labs.fedoraproject.org as well as from
the Docker Hub and Vagrant Atlas.
A work in progress for the lab is available on GitHub.
The Lab will contain:
* Python 3.6 including the python3-devel package
* Python 2.7 including the python2-devel package
* PyPy 3
* tox
* virtualenv
* IPython console for both Python 2 and 3
* Jupyter Notebook with Python 2 and 3 kernels (if this gets into
Fedora in time)
* offline documentation for Python 2 and 3
* basic toolchain for building C and C++ extensions and valgrind
* git
* nano, vim, ssh client, curl, wget
* devel packages for commonly used dependencies of packages on the
Python Package Index
* * libxml2-devel
* * libyaml-devel
...
The Workstation based lab will also contain:
* Basic GNOME
* Terminal emulator
* Text editor
* PDF reader
* Web browser
* Image viewer
* ...and possibly other utilities
But it will not include multimedia and virtualization support, office
suite, e-mail client.
== Scope ==
Proposal owners:
* create the comps group
* create kickstarts for live and vagrant variants
* create a layer for docker
Other developers:
* Design team: Create an image for labs.fedoraproject.org
* Websites team: Add the new Lab to labs.fedoraproject.org
Release engineering:
List of deliverables:
* Labs/i386/iso/Fedora-Python-Classroom-Live-i386-_RELEASE_MILESTONE_.iso
* Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-_RELEASE_MILESTONE_.iso
* Labs/armhfp/images/Fedora-Python-Classroom-armhfp-_RELEASE_MILESTONE_-sda.raw.xz
* Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-libvirt.box
* Labs/i386/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.i386.vagrant-virtualbox.box
* Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-libvirt.box
* Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-_RELEASE_MILESTONE_.x86_64.vagrant-virtualbox.box
* docker images via Fedora Docker Layered image build service
Policies and guidelines: nothing
Trademark approval: waiting
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
4 years, 2 months
F26 System Wide Change: Kerberos KCM credential cache by default
by Jan Kurik
= System Wide Change: Kerberos KCM credential cache by default =
https://fedoraproject.org/wiki/Changes/KerberosKCMCache
Change owner(s):
* Jakub Hrozek <jhrozek AT redhat DOT com>
Default to a new Kerberos credential cache type called KCM which is
better suited for containerized environments and provides a better
user experience in the general case as well.
== Detailed Description ==
Over time, Fedora used different credential cache types to store
Kerberos credentials - going from a simple file-based storage (FILE:)
to a directory (DIR:) and most recently a kernel-keyring based cache
(KEYRING:).
Each of these caches has its own set of advantages and disadvantages.
The FILE ccache is very widely supported, but does not allow multiple
primary caches in a collection. The DIR cache does, but creating and
managing the directories including proper access control can be
tricky. The KEYRING cache is not well suited for cases where multiple
semi-isolated environments might share the same kernel. Managing
credential caches' life cycle is not well solved in neither of these
cache types automatically, only with the help of a daemon like SSSD.
The scope of this change is to introduce a new Kerberos credential
cache type called KCM and switch to using it by default.
With KCM, the Kerberos caches are not stored in a "passive" store, but
managed by a daemon. In this setup, the Kerberos library (typically
used through an application, like for example, kinit) is a "KCM
client" and the daemon is being referred to as a "KCM server". The KCM
server will be provided as a socket-activated service of the SSSD
deamon.
== Scope ==
* Proposal owners:
SSSD developers will implement a KCM server. The krb5-libs package
will then switch its default from KEYRING to KCM. The libkrb5 package
will require the sssd-kcm subpackage and enable its socket so that the
KCM server is socket activated when needed. Please note that the KCM
server only listens on a local UNIX socket, not over the network.
* Other developers: None required
* Release engineering: None required
* List of deliverables: None affected
* Policies and guidelines: None required
* 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, 2 months
packaging work is becoming increasingly cumbersome
by Julian Sikorski
Hi list,
I have been co-maintaining goffice and gnumeric for a while now. It has
been unfortunately becoming increasingly difficult over time, given the
fact that the two often need to be chain-built and tools needed to do
this have been slowly becoming more time-consuming to use, in addition
to some other issues. For example:
- requesting buildroot overrides via commandline has been broken for
over than a year now and will not be fixed until f26 [1]. Web interface
is much slower.
- chain-building has been broken for a month [2] so now requesting each
build in the chain separately is required
- fedpkg now needs authentication via kerberos instead of ssh key [3],
which means that I now have to run kinit before starting a packaging
session, in addition to firing up keepass and entering the password
- koji login via certificate is no longer possible which makes it harder
to track failed builds
While I am sure these changes are done with an aim of improving things
in the long run, the churn caused by them is really starting to take a
toll on my motivation. Could something be done to mitigate the
inconveniences caused by the infrastructure upgrades?
Best regards,
Julian
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1278742
[2] https://pagure.io/fedpkg/issue/98
[3] https://fedoraproject.org/wiki/Infrastructure/Kerberos
4 years, 2 months