Hello Fedora developers,
I'm Giovanni Campagna and I'm a first year student of informatics
engineering at Politecnico di Milano.
Some of you may already know me because I'm also an upstream contributor
and part-time developer for GNOME (in particular in the Shell area), but
this time I decided to dive deep in the land of distributions.
I've been a Fedora user since Fedora 11, coming from a Kubuntu (and of
course Windows) background. I liked it from the very beginning, as it
seemed a very professional and solid system.
From that, I've seen it grow and change, adding and improving on the
best technology available every 6 months, and so far I'm very happy with
This is to say, great job everyone!
As for me coming here, it's because I want to improve it even more,
finding where it lacks compared to the competition and fixing it. I
believe that the ultimate goal of Fedora, and free software in general,
is market domination, so we want to provide the best product ever.
(The rest is just business, which is easy, right? [cit.])
In any case, I don't want to pollute this introductory mail with
technical details, so I'll illustrate the area I'd like to work on in
the next mail.
See you soon,
Given that I'm migrating bunch of legacy init script to native systemd
ones and I have come many packages that seem that maintainer(s) have
deserted them but for some bizarre reason we still continue to package
and keep rolling them between release and now I came across bug 738442
which seriously begs the question that the whole cleanup process needs
to be revisited.
Instead of everybody that are doing needed work in the distribution
having to run around after maintainers trying to find out if they are
still active or not and initiate the unresponsive maintainer policy,
cant we revert the process and have maintainer(s) having to reassure
their ownership on their package(s) at the begin of each development
cycle and if they dont do that before x time, the package(s) they
maintain will be automatically orphaned and given up for someone else to
grab and take ownership before x time runs out and if nobody does they
get remove from the distribution?
I cant image how much resources across the project have been spent on
packages that no longer are being actively maintained but have not been
removed from the distribution.
What do people see as pros and cons continuing to use the current
package ownership model?
Would it be practical to dropping it altogether which in essence would
make every contributor an "proven packager"?
Would it be viable to move to something like language SIG based
ownership of packages?
As in lower the barrier of entry of contributor without the need and or
introduction of an package or any sponsorship and have them assigned to
relevant SIG based on language they either know or want to learn. ( not
necessarly having to tie packaging with code contribution ).
The governing body of the SIG would in essence be the once that would be
responsible for the components.
So as an example a indvidual skilled in Java who would want to join the
project would automatically be assigned to the java SIG which in turn
would be assigned and managing all Java related components then the Java
SIG based on what ever process/workflow they have decided would assign
to that individual what ever task is needed at current times prioritized
by the knowledge and resource they posses.
So basically the barrier of entry is no higher than what the individual
wants to learn or knows already as in..
Do you know or want to learn python. Join the python SIG etc...
Do you want to learn distribution packaging join the Packaging SIG
Or the individual would learn how to package components relevant to the
SIG he just joined
Far off and totally crazy, you are mad!
What meds are you on can I have some?
The SIG approach is something that actually might work...
I picked up gdk-pixbuf because freetennis supposedly depended on it but
actually doesn't. (Though freetennis if also FTBFS for another reason so
clearing the dependency isn't simple.) Though only thing that really
depends on it is xosd-xmms and I have checked with Kevin about that and
he will remove that subpackage or retire xosd.
gdk-pixbuf is FTBFS because it won't build without rerunning some of
the autotools programs and does not build with the currently available
autotools versions available. There are a number of errors reported
that would need to get this building again and the effort doesn't seem
So I have now retired the package in rawhide (f17).
Hello, I'm Willington Vega, a systems and informatics engineer from
Colombia currently studying for masters degree in systems engineering
at Universidad Nacional. I'm a fedora user since Fedora Core 6 and now
I'm trying to get more involved.
I started with a small package earlier this year, but at that time I
couldn't continue with the review process.
The package was for textext, an extension for Inkscape that
allows one to add LaTeX text objects to the drawings and edit them
later if necessary. For me this is a necessary feature and it would be
good if others are able to use it without having to do a manual
installation, which is easy, but not as easy as 'yum install
I created a review request  and I'm still looking for a sponsor,
but I know I'll have to work harder this time :).
Last weekend I took the SRPM for Hotot 0.9.6 and made changes to
package version 0.9.7. I sent the spec file to the package maintainer
(Rahul Sundaram), he made additional modifications and pushed an
update. He also asked me if I wanted to be a co-maintainer for the
package and I'm preparing to accept that offer.
Introducing myself to the list is the first step of my training. Now
I'll start looking for some packages that I can review and help me
improve my packaging skills.
My main interest right now is to learn more about being a package
maintainer or co-maintainer, become familiar with the packaging
guidelines and practice with small packages like the one I submitted
or Hotot. Then I can start packaging other interesting packages or
help to maintain existing ones.
Thanks to all.
Willington Vega C.
Enviado desde mi BlackBerry® de Claro Argentina
From: Jiri Skala <jskala(a)fedoraproject.org>
Date: Wed, 23 Nov 2011 07:49:59
To: <lsvpd-owner(a)fedoraproject.org>; <scm-commits(a)lists.fedoraproject.org>
Subject: [lsvpd/f16] added ExclusiveArch for ppc
Author: Jiri Skala <jskala(a)redhat.com>
Date: Wed Nov 23 08:49:55 2011 +0100
added ExclusiveArch for ppc
lsvpd.spec | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lsvpd.spec b/lsvpd.spec
index 40bf92b..ccfb44a 100644
@@ -3,7 +3,7 @@
Summary: VPD/hardware inventory utilities for Linux
@@ -22,9 +22,9 @@ Requires(post): /usr/sbin/vpdupdate
# librtas is now part of Fedora, lsvpd provides much more information with
# librtas on POWER
-%ifarch ppc ppc64
+ExclusiveArch: ppc ppc64
The lsvpd package contains all of the lsvpd, lscfg and lsmcode
@@ -75,6 +75,9 @@ on POWER PC based systems.
+* Wed Nov 23 2011 Jiri Skala <jskala(a)redhat.com> - 1.6.11-3
+- added ExclusiveArch for ppc
* Wed Nov 09 2011 Jiri Skala <jskala(a)redhat.com> - 1.6.11-2
- fixes #752244 - similar output for different options in lsmcode
scm-commits mailing list