Self introduction
by Ben Harper
Hello Fedora faithful,
My name is Ben Harper and work for Rackspace as a RPM developer in
Austin, TX. My duties include creating RPMs for internal use, but also
for iuscommunity.org (IUS). IUS provides new versions of packages found
in RHEL. I am looking to become a package maintainer for EPEL. There
are some cases where IUS packages have dependences that are not
available from packages provided by RHEL and should be provided by EPEL.
Currently I do not have package I am looking to get approved, but just
looking for a sponsor. I would like to prove that I can follow the
documation and create quality packages. I have been reading over the
docs and created the needed accounts with this email account.
-Ben
11 years, 1 month
F18, efi-bootable live images
by Andreas Tunek
The latest couple of F18 live images I have tried have not been efi
bootable. Is this something known or something I should report in bugzilla?
If so, under what component?
11 years, 1 month
Re: Maintainers wanted for packages from 2013-02-27 FESCo Meeting
by Rave it
> 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
I've added me as comaintainer to clamav and i'm willing to take
ownership if it is orphoned.
Shure, i will do a new review request because i want to reorganized the
package like it is for epel.
Fedora's version is total user unfriendly, ie. needed to copy
configuration files by hand and no default daemon configuration.
I used the epel version for a long time for myself, because you need
only installation and enable the the daemon, that's all.
Wolfgang
11 years, 1 month
Mediawiki 1.20.2 has landed
by Michael Cronenworth
Hi,
The mediawiki package has been updated to 1.20.2 for Rawhide and 1.19.3
for F17/F18.
The mediawiki-math/nopath packages have been merged into just
"mediawiki" (with Obsoletes). There is one package that depended on the
old packages.
mediawiki-semantic
owner: jlaska
If you have your own wiki please look over the release notes and test
the packages in updates-testing. We're coming from a 2 year old version
so there are a few changes.
Thanks,
Michael
11 years, 1 month
Proposed F19 Feature: systemd/udev Predictable Network Interface Names
by Jaroslav Reznik
= Features/SystemdPredictableNetworkInterfaceNames =
https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfac...
Feature owner(s): Kay Sievers <kay at redhat dot com>
The udevd service has a long history of providing predicatable names for block
devices and others. For Fedora 19 we'd like to provide the same for network
interfaces, following a similar naming scheme, but only as fallback if not
other solution such as biosdevname is installed or the administrator manually
defined network interface names via udev rules or the old network scripts.
== Detailed description ==
The classic naming scheme for network interfaces applied by the kernel is to
simply assign names beginning with "eth0", "eth1", ... to all interfaces as
they are probed by the drivers. As the driver probing is generally not
predictable for modern technology this means that as soon as multiple network
interfaces are available the assignment of the names "eth0", "eth1" and so on
is generally not fixed anymore and it might very well happen that "eth0" on one
boot ends up being "eth1" on the next. This can have serious security
implications, for example in firewall rules which are coded for certain naming
schemes, and which are hence very sensitive to unpredictable changing names.
Starting with v197 systemd/udev can automatically assign predictable, stable
network interface names for all local Ethernet, WLAN and WWAN interfaces. This
is a departure from the traditional interface naming scheme ("eth0", "eth1",
"wlan0", ...), but should fix real problems.
This feature is about enabling this as default in Fedora, but only as a
fallback if the user/administrator did not manually assign names to interfaces
via udev rules, or via the old networking scripts, or if biosdevname is
installed.
For a longer discussion about this feature see the upstream documentation.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 1 month
What would it take to make Software Collections work in Fedora?
by Matthew Miller
There is a perpetual problem facing all Linux distributions around how fast
to move with software updates. In Fedora, of course, our default speed is
petal-to-the-metal. This is part of who we are and why we are awesome.
However, it also sometimes makes life difficult for us -- for example, our
Puppet packages are broken because Ruby is too new. It also makes life
difficult for people trying to use Fedora seriously. It's especially hard
with Ruby and Java -- not that there's anything _wrong_ with these
languages, but the packaging expectations are different and often in
conflict with the system operator's traditional packaging worldview.
So, some Red Hat folks have developed an idea called Software Collections
http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/ht...
which is aimed at this problem -- it lets you install and choose between
different versions of RPM-packaged software in parallel at run-time.
The base tool for enabling this (scl-utils) is included in Fedora, but we
don't allow Software Collections actually as Fedora packages (see
https://fedoraproject.org/wiki/SoftwareCollections). This is for very good
reasons -- there are a number of huge unanswered questions around structure,
infrastructure, maintenance, and security updates.
I think, though, that this tool, integrated well and supported, could really
help us in Fedora (and in EPEL). So, I'd like to
a) enumerate the problems with Software Collections in Fedora,
b) develop a medium-term plan for solving those problems, and
c) develop a longer-term plan for taking full advantage of the functionality
where appropriate.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11 years, 1 month
Django-1.5 build
by Matthias Runge
Dear list,
Django 1.5 was released about two days ago. I'd like to push a build to
rawhide, but I assume, that will break many dependent packages.
The plan is, to delay the push, until other packages are fixed, or to
push in about 14 days.
I have a scratch-build build ready, one might to try, it should install
cleanly e.g. on Fedora 18.
http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-...
--
Matthias Runge <mrunge(a)matthias-runge.de>
<mrunge(a)fedoraproject.org>
11 years, 1 month
dietlibc
by Kevin Kofler
Hi,
due to the Enrico Scholz saga, I realized that we have 4 packages in Rawhide
which BuildRequire dietlibc:
dhcp-forwarder-0:0.10-1902.fc19.src
ip-sentinel-0:0.12-1901.fc19.src
kismet-0:0.0.2011.03.R2-1603.fc18.src
util-vserver-0:0.30.215+svn2929-1603.fc18.src
There are 2 things that strike me as broken there:
1. As far as I can tell, those packages are STATICALLY linked against
dietlibc. Yet there is no dietlibc-static subpackage, and apparently the
static library is in the main package (not even -devel!). There are also
dietlibc-devel and dietlibc-header subpackages, but nothing BuildRequires or
Requires those. The dietlibc package needs to be fixed to comply to the
packaging guidelines (which also means that either Enrico lets go the devel
branch or it should be forcibly removed from him!) or retired entirely (Do
we really need a second libc in Fedora?).
2. I think those packages should not build against dietlibc at all, but just
use the system glibc. Now that Enrico let them go, can we PLEASE get those
packages fixed?
Kevin Kofler
11 years, 1 month
