devel January 2017

devel@lists.stg.fedoraproject.org

204 participants
254 discussions

F26 Self Contained Change: Container Minimal Image
by Jan Kurik 13 Feb '17

13 Feb '17

= Proposed Self Contained Change: Container Minimal Image = https://fedoraproject.org/wiki/Changes/ContainerMinimalImage Change owner(s): * Dusty Mabe <dusty AT dustymabe DOT com> Produce a new container image that contains as little as possible, but also still provides the ability to install packages from dnf repositories. == Detailed Description == As a user of Fedora I'd like to build containers based on an image that is a little more lightweight than the current base container image that is produced in Fedora. We have a proof of concept kickstart [1] that will create such an image. It is a work in progress. [1] https://pagure.io/fedora-kickstarts/pull-request/120 == Scope == * Proposal owners: Implementation of this Change * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * 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

7 8

Attempt at building YafaRay
by Luya Tshimbalanga 13 Feb '17

13 Feb '17

Here is an attempt at building YafaRay using scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=17274673 An issue is somehow OpenCV will not meet a requirement due to this error below: -- Found opencv, version 3.1.0 CMake Error at CMakeModules/FindOpenCV.cmake:120 (string): string sub-command REGEX, mode REPLACE needs at least 6 arguments total to command. Using "" to work around the error inside "CMakeModules/FindOpenCV.cmake" still produce a failure. Any pointer? -- Luya Tshimbalanga Graphic & Web Designer E: luya(a)fedoraproject.org W: http://www.coolest-storm.net

3 5

HEADS UP: shapelib soname bump
by Sandro Mani 12 Feb '17

12 Feb '17

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

5 8

F26 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik 10 Feb '17

10 Feb '17

= 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

9 12

Changing default "docker" storage to to Overlay2 in Fedora 26
by Daniel J Walsh 08 Feb '17

08 Feb '17

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.

8 13

F26 System Wide Change: Enable TRIM pass down to encrypted disks
by Jan Kurik 06 Feb '17

06 Feb '17

= 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

11 16

Are partial upgrades expected to work in rawhide?
by Florian Weimer 06 Feb '17

06 Feb '17

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

6 20

overriding CXX_FLAGS
by Mattia Verga 05 Feb '17

05 Feb '17

In the latest version of RawTherapee, developers suggest the use of -DCMAKE_CXX_FLAGS="-std=c++11". I've tried to modify the .spec file with -DCMAKE_CXX_FLAGS="$RPM_OPT_FLAGS -std=c++11" [1], but koji still use "-std=c++11 -std=gnu++11" [2] and the latter wins (I think). How can I override that setting? Thanks Mattia [1] https://mattia.fedorapeople.org/rawtherapee.spec [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=17398942

4 4

[Verification] FOSDEM speakers
by Dhanesh B. Sabane 03 Feb '17

03 Feb '17

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/aab71c065fc29bec3b40f5d751… -- Dhanesh B. Sabane [dhanesh95] dhanesh95.gitlab.io

3 2

F26 System Wide Change: Python Classroom Lab
by Jan Kurik 03 Feb '17

03 Feb '17

= 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

9 14

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 January 2017