Maintainers wanted for packages from 2013-02-27 FESCo Meeting
by Toshio Kuratomi
Greetings,
At today's FESCo meeting there were two tickets which had the end result
of needing to have new maintainers and comaintainers for some packages:
== https://fedorahosted.org/fesco/ticket/1028 ==
tor package was reassigned to a new maintainer. Former maintainer dropped
ownership of his other packages. Those are now orphaned and in need of a
new owner. Note to potential new maintainers: although not mandatory, you
may want to open an optional re-review request as the spec files for some
of these may be very out of sync with the current Fedora Packaging Guidelines
* clamav
* dhcp-forwarder
* fedora-usermgmt (epel branches still owned by ensc)
* gif2png
* hunt
* ip-sentinel
* kismet
* libextractor
* libtasn1
* milter-greylist
* mimetic
* util-vserver
* x11-ssh-askpass
* xmlrpc-c
* dietlibc (devel is still owned by ensc but maybe that was an oversight)
== https://fedorahosted.org/fesco/ticket/1091 ==
Non Responsive Maintainer ticket for mediawiki. The mediawiki package was
assigned a new maintainer due to nonresponse. The former owner owns other
packages as well. Fesco asks that comaintainers be solicited for these
packages. If package maintainer is nonresponsive for more packages,
consider performing the Mass Orphaning clause of the Nonresponsive
Maintainers Policy:
http://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainer...
* apt -- Debian's Advanced Packaging Tool with RPM support
* arpack -- Fortran77 subroutines for solving large scale eigenvalue problems
* chrpath -- Modify rpath of compiled programs
* fail2ban -- Ban IPs that make too many password failures
* fakechroot -- Gives a fake chroot environment
* fakeroot -- Gives a fake root environment
* fedora-package-config-apt -- Fedora configuration files for the apt-rpm package manager
* fedora-package-config-smart -- Fedora configuration files for the Smart package manager
* freenx-client -- Free client libraries and binaries for the NX protocol
* freenx-server -- Free Software (GPL) Implementation of the NX Server
* greylistd -- Greylisting daemon
* ivtv-firmware -- Firmware for the Hauppauge PVR 250/350/150/500/USB2 model series
* ivtv-utils -- Tools for the iTVC15/16 and CX23415/16 driver
* libcdaudio -- Control operation of a CD-ROM when playing audio CDs
* maildrop -- Mail delivery agent with filtering abilities
* mediawiki-openid -- The OpenID extension for MediaWiki
* nx -- Proxy system for X11
* perl-Text-CharWidth -- Get number of occupied columns of a string on terminal
* perl-Text-WrapI18N -- Line wrapping with support for several locale setups
* php-pear-Auth-OpenID -- PHP OpenID
* po4a -- A tool maintaining translations anywhere
* smart -- Next generation package handling tool
* synaptic -- Graphical frontend for APT package manager.
* vtk -- The Visualization Toolkit - A high level 3D visualization library
* vtkdata -- Example data file for VTK
Please let FESCo know via a ticket if you need any help becoming a comaintainer
because the owner is nonresponsive.
Thanks,
Toshio
10 years, 9 months
[Guidelines Change] Changes to the Packaging Guidelines
by Tom Callaway
Some more changes to the Fedora Packaging Guidelines have been made:
---
The Packaging Guidelines covering Desktop files have been amended to say
that for Fedora 19 and beyond, the vendor tag must not be used. If it
was being used in a previous release, it may continue to be used for
that previous release, but must be removed in Fedora 19. New packages
must not add the vendor tag for any release. Packagers are reminded that
they must not change the name of the desktop file in a stable Fedora
release.
https://fedoraproject.org/wiki/Packaging:Guidelines#desktop-file-install_...
---
The Ruby Guidelines have been updated to prepare for JRuby integration
in Fedora (and new macros to assist in this).
https://fedoraproject.org/wiki/Packaging:Ruby
---
The Java Guidelines have been changed to reflect BuildRequires:
maven-local (instead of maven).
https://fedoraproject.org/wiki/Packaging:Java#maven_3
---
These guideline changes were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Bohuslav Kabrda, Parag Nemade, Stanislav Ochotnicky, and
all of the members of the FPC, for assisting in drafting, refining, and
passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
10 years, 9 months
Call for Test Days for Fedora 18
by Adam Williamson
Hey, folks. It's that time again - time to start thinking about Test
Days for Fedora 18.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and developers
together to test a specific feature or area of the distribution. You can
run a Test Day on just about anything for which it would be useful to do
some fairly focused testing in 'real time' with a group of testers; it
doesn't have to be code, for instance we often run Test Days for
l10n/i18n topics. For more information on Test Days, see
https://fedoraproject.org/wiki/QA/Test_Days .
Anyone who wants to can host their own Test Day, or you can request that
the QA group helps you out with organization, or any combination of the
two. To propose a Test Day, just file a ticket in QA trac - full details
are at https://fedoraproject.org/wiki/QA/Test_Days/Create . For
instructions on hosting a Test Day, see
https://fedoraproject.org/wiki/QA/SOP_Test_Day_management .
You can see the schedule at
https://fedoraproject.org/wiki/QA/Fedora_18_test_days . There are many
slots open right now, with the earliest on 2012-08-09 and the latest
2012-11-01. Consider the development schedule, though, in deciding when
you want to run your Test Day - for some topics you may want to avoid
the time before the Alpha release or the time after the feature freeze
or the Final freeze.
We normally aim to schedule Test Days on Thursdays; however, if you want
to run a series of related Test Days, it's often a good idea to do
something like Tuesday / Wednesday / Thursday of the same week (this is
how we usually run the X Test Week, for instance). If all the Thursday
slots fill up but more people want to run Test Days, we will open up
Tuesday slots as overflows. And finally, if you really want to run a
Test Day in a specific timeframe due to the development schedule, but
the Thursday slot for that week is full, we can add a slot on another
day. We're flexible! Just put in your ticket the date or timeframe you'd
like, and we'll figure it out from there.
If you have any questions about the Test Day process, please don't
hesitate to contact me or any other member of the QA team on test@ or in
#fedora-qa on IRC. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10 years, 9 months
Mass Rebuild for Fedora 19
by Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
it was requested in https://fedorahosted.org/fesco/ticket/1004 that
we do a mass rebuild for Fedora 19 for
http://fedoraproject.org/wiki/Features/GCC48
Additionally we will be mass patching config.guess and config.sub to
support aarch64 in preperation for 64 bit arm support
we will start the mass rebuild on 2013-02-12
This is a heads up that it will be done in a side tag and moved over
when completed. We will be running scripts to output failure stats.
please be sure to let releng know if you see any bugs in the reporting.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlEUx/4ACgkQkSxm47BaWffzcQCggHykVzb0MlCY+sXoHsbjbQxm
aVgAnjTb32kw6gmXTwlrIxhnU+N2YHkD
=fj3Q
-----END PGP SIGNATURE-----
10 years, 9 months
Proposed F19 Feature: Resource Management Tools
by Jaroslav Reznik
This Feature has been submitted *before* Feature Submission Deadline and it
required input/changes from the owner or it was queued.
= Features/ResourceManagementTools =
https://fedoraproject.org/wiki/Features/ResourceManagementTools
Feature owner(s): Daniel Berrange <berrange(a)fedoraproject.org>
This feature will provide a library and command line tools for OS resource
management, utilizing on cgroups and integrating with systemd and libvirt.
== Detailed description ==
The kernel cgroups capability provides a general purpose framework for
resource management of processes. Both libvirt and systemd make use of cgroups
and resource tunables to be set and the libcgroup project provides some
command line tools for managing croups. Despite this, however, it is
difficult/impossible for an admin to use these to do effective system
partitioning. The guidelines on how applications should co-operate in use of
the cgroups hiearchy are flawed, leading applications to setup a hiearchy that
cannot be used to do system partitioning. Another part of the problem is that
there is no single high level view for the admin across all the "objects"
using cgroups - the cgroups tools themselves are too low level, focusing on
controllers & processes, rather than concepts like "resource groups", 'system
service', 'virtual machine', etc.
This feature will seek to address the manageability problems with cgroups to
facilitate system partitioning / workload isolation. The guidelines on using
the cgroup hiearchy will be updated to allow a more practical hiearchy to be
created by applications like systemd/libvirt out of the box. A library and
corresponding command line tool will be written to provide a high level view
of objects needing resource management. This will allow an administrator to
easily define resource groups with different performance characteristics and
control placement of system services and virtual machines into those groups.
Follow on work will also look at how to extend the controls to user sessions,
and ad-hoc commands which may be invoked by users, as well as other non-cgroup
based resource tunables under sysfs / procfs.
10 years, 9 months
Proposed F19 Feature: Scala 2.10
by Jaroslav Reznik
This Feature has been submitted *before* Feature Submission Deadline and it
required input/changes from the owner or was queued.
= Features/Scala210 =
https://fedoraproject.org/wiki/Features/Scala210
Feature owner(s): Jochen Schmitt <Jochen(a)herr-schmitt.de>
Providing the most current relase of Scala a functional programming language
based on the JVM.
== Detailed description ==
Scala 2.10 is an update of the scala programming language. This is a
functional programming langage based on the JVM. This release contains
language enhancements which may affected existing scala progjects of fedora
users. This release support jdk-1.7 and contains support of the swing module
in opposite of the official upstream release. This was done by a request of
fedora users for a previous release on based of a patch from the upstream
development repository. Additionally it's requires packages which doesn't
available in fedora until yes.
10 years, 9 months
Proposed F19 Feature (exception): Kolab 3
by Jaroslav Reznik
This Feature has been submitted *after* Feature Submission Deadline and
requires exception from FESCo to be accepted as Fedora 19 Feature.
Owner(s), please, provide motivation why do you think the exception should be
granted.
= Features/Kolab3 =
https://fedoraproject.org/wiki/Features/Kolab3
Feature owner(s): Christoph Wickert <cwickert(a)fedoraproject.org>, Jeroen van
Meeuwen <kanarip(a)fedoraproject.org>
Package the Kolab Groupware solution and include it in Fedora.
== Detailed description ==
Kolab is a secure, scalable and reliable groupware server. It is formed by a
number of well-known and proven components and adds intelligent interaction
between them. There's a web administration interface, management of free-busy
lists and resources, synchronization for several devices and more.
The latest version of Kolab is 3.0 released January 15, 2013. We want to
package it for Fedora so that the installation becomes as easy as a single yum
install kolab.
10 years, 9 months
Proposed F19 Feature: Usermode Migration
by Jaroslav Reznik
This Feature has been submitted *before* Feature Submission Deadline and it
required input/changes from the owner or was queued.
= Features/UsermodeMigration =
https://fedoraproject.org/wiki/Features/UsermodeMigration
Feature owner(s): Harald Hoyer <harald(a)redhat.com>, Kay Sievers
<kay(a)redhat.com>, Bill Nottingham <notting(a)redhat.com>
Access control of privileged operations for ordinary users should be handled
exclusively by a centrally managed authority.
Usermode/consolehelper should be phased out and be replaced entirely by
polkit.
== Detailed description ==
The usermode/consolehelper program is a setuid-root wrapper around a couple of
system tools, providing superuser privileges to ordinary users. Its policy is
controlled by text files in /etc.
These days, most privileged system operations are already controlled by
polkit, a well-established, fine-grained, (possibly) network-transparent
service for managing privileged operations by ordinary users. Enterprise
environments need to be able to centrally define access control policy for the
organization, and automatically apply it to all connected workstations.
* polkit can be used by privileged processes to decide if it should execute
privileged operations on behalf of the requesting user. For directly executed
tools, polkit provides a setuid-root helper program called ‘’pkexec’’.The
hooks to ask the user for authorizations are well-integrated into text
environments, and native in all major graphical environments.
* The concept of a console user (that usermode/consolehelper implements) is no
longer a sufficient concept to derive privileges from. OTOH polkit
authorizations can properly distinguish between multiple active sessions and
seats: e.g. an untrusted user’s reboot request is only granted if only a
single user session runs at that time.
This Feature has been accepted for F18 and as it's continuous effort, it was
moved for F19.
10 years, 9 months
Proposed F19 Feature: FreeIPA Two Factor Authentication
by Jaroslav Reznik
This Feature has been submitted *before* Feature Submission Deadline and it
required input/changes from the owner or was queued.
= Features/FreeIPA Two Factor Authentication =
https://fedoraproject.org/wiki/Features/FreeIPA_Two_Factor_Authentication
Feature owner(s): Nathaniel McCallum <npmccallum(a)redhat.com >
Provide Kerberos enabled, LDAP replicated, two-factor authentication for
FreeIPA.
== Detailed description ==
Until recently, no two-factor authentication was possible with Kerberos.
However, the standardization of RFC 6560 combined with recent work in the MIT
krb5 code makes it possible to now offer support for two-factor authentication
in Kerberos.
Fedora 18 already supports most of the client side of this proposal. FreeIPA
will be landing support for the server side in Fedora 19.
10 years, 9 months
