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
7 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
7 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
7 years, 2 months
Boost 1.63 rebuilds underway for f26
by Jonathan Wakely
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.
7 years, 2 months
Rust SIG
by Igor Gnatenko
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
7 years, 2 months
Offering to co maintain lv2 related packages (lv2, lilv, suil,
serd, sord, sratom...)
by Guido Aulisi
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
7 years, 2 months
Fedora 25 Koji buildroots broken…
by Björn 'besser82' Esser
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 years, 2 months
F26 System Wide Change: GNOME 3.24
by Jan Kurik
= 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
7 years, 2 months
