devel January 2017

devel@lists.fedoraproject.org

204 participants
255 discussions

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

F26 System Wide Change: Kerberos KCM credential cache by default
by Jan Kurik 02 Feb '17

02 Feb '17

= 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

8 19

packaging work is becoming increasingly cumbersome
by Julian Sikorski 02 Feb '17

02 Feb '17

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

7 10

Boost 1.63 rebuilds underway for f26
by Jonathan Wakely 01 Feb '17

01 Feb '17

As part of the https://fedoraproject.org//wiki/Changes/F26Boost163 change to update Boost in F26 I've started rebuilding the packages that depend on Boost, using the f26-boost side tag. That means I've pushed a bumpspec change to their spec files, but the rebuilt package won't land in rawhide until they're all done and everything in the side tag is merged back to the main f26 target. If you maintain a package that depends on Boost and this will interfere with any package maintenance you're doing please let me know and I'll coordinate the rebuilds with you. I'm trying to get all these rebuilds done before the mass rebuild next week, but as usual there will be lots of FTBFS cases.

4 12

per-product packaging question
by Lokesh Mandvekar 01 Feb '17

01 Feb '17

Hi, I'm looking at the per-product packaging doc at https://fedoraproject.org/wiki/Packaging:Per-Product_Configuration and I see that variants for all products are installed at package install time, with the ghost file pointing to the appropriate product variant. Just wondering if there's a reason for installing all variants and/or if it's worth considering installation of just the particular variant appropriate for the system at install time? Thanks, -- Lokesh Freenode: lsm5 GPG: 0xC7C3A0DD https://keybase.io/lsm5

4 7

Rust SIG
by Igor Gnatenko 01 Feb '17

01 Feb '17

Hello everybody, we are establishing new SIG for Rust[0]. Feel free to join us on IRC (#fedora-rust) and/or Mailing List (rust(a)lists.fedoraproject.org) Help with improving our wiki page is very welcomed ;) [0] https://fedoraproject.org/wiki/SIGs/Rust -- -Igor Gnatenko

3 2

Offering to co maintain lv2 related packages (lv2, lilv, suil, serd, sord, sratom...)
by Guido Aulisi 01 Feb '17

01 Feb '17

Hello, I recently joined the packager group and I made 2 audio related packages (setBfree and lv2-ir-plugins). I noticed that lv2 related packages are behind upstream releases, and I know there are important bug fixes in these new releases, so I'm proposing myself as a co-maintainer of lv2 related packages (from drobilla.net) to try to package the latest versions (in rawhide). The packages are: lv2 sratom serd sord suil lilv Ciao Guido

2 3

failed to load external entity "http://www.oasis-open.org/docbook/xmlcharent/0.3/iso-pub.ent"
by Julian Sikorski 01 Feb '17

01 Feb '17

Hi list, the latest gnumeric seems to require internet access to build its documentation. I am getting the following error [1] [2]: failed to load external entity "http://www.oasis-open.org/docbook/xmlcharent/0.3/iso-pub.ent The build works fine in mock, but it is probably because mock has access to internet while koji does not. Has anybody experienced something like this, respectively knows how this can be fixed? Thank you for your feedback in advance. Best regards, Julian [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=837293 [2] https://koji.fedoraproject.org/koji/buildinfo?buildID=837294

4 5

Fedora 25 Koji buildroots broken…
by Björn 'besser82' Esser 01 Feb '17

01 Feb '17

Hi there! The Fedora 25 buildroot on Koji is b0rk3n… :( DEBUG util.py:435: Error: nothing provides libGL.so.1()(64bit) needed by muffin-devel-3.2.1-1.fc25.x86_64. DEBUG util.py:435: nothing provides libEGL.so.1()(64bit) needed by clutter-1.26.0-1.fc25.x86_64. DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-gobject-1.14.8-1.fc25.x86_64. DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64. DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-gobject-1.14.8-1.fc25.x86_64. DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64. DEBUG util.py:435: nothing provides libGL.so.1()(64bit) needed by cairo-1.14.8-1.fc25.x86_64. DEBUG util.py:435: nothing provides libglvnd-glx(x86-64) needed by mesa-libGL-13.0.3-4.fc25.x86_64 Can the one who broke fix it, please? Cheers Björn

7 12

F26 System Wide Change: GNOME 3.24
by Jan Kurik 31 Jan '17

31 Jan '17

= System Wide Change: GNOME 3.24 = https://fedoraproject.org/wiki/Changes/GNOME3.24 Change owner(s): * Kalev Lember <klember AT redhat DOT com> Update GNOME to the latest upstream release, 3.24 == Detailed Description == Tentative new features for 3.24 include: * Updated System Settings panels: User Accounts, Printer, Online Accounts * Tag Editing in GNOME Music * ownCloud integration in GNOME Music * Sharing Framework * Photo Import * Passwords and Keys Application * Revamped Header Bar and Bookmarks in Web * Browse as root in Files More details are available in https://wiki.gnome.org/ReleasePlanning/FeaturePlans == Scope == Proposal owners: * Keep existing GNOME packages updated * Follow upstream module changes * Package new applications and new dependencies of existing GNOME packages for GNOME 3.24 Other developers: N/A Release engineering: N/A List of deliverables: N/A Policies and guidelines: N/A 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 3

← Newer
1
2
3
4
5
6
7
...
26
Older →

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