devel February 2013

devel@lists.fedoraproject.org

286 participants
252 discussions

F18, efi-bootable live images
by Andreas Tunek 11 Mar '13

11 Mar '13

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?

6 14

review swap
by Martin Gansser 11 Mar '13

11 Mar '13

Hi, I would be willing to swap a review of vdr-markad [1] in rpmfusion for another review, be it RPM Fusion or Fedora, preferably not something overly complex. Feel free to contact me if you are interested. Cheers, Martin [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=2319

2 1

Re: Maintainers wanted for packages from 2013-02-27 FESCo Meeting
by Rave it 08 Mar '13

08 Mar '13

> 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

3 4

Mediawiki 1.20.2 has landed
by Michael Cronenworth 07 Mar '13

07 Mar '13

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

5 12

Proposed F19 Feature: systemd/udev Predictable Network Interface Names
by Jaroslav Reznik 07 Mar '13

07 Mar '13

= Features/SystemdPredictableNetworkInterfaceNames = https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceN… 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

30 91

What would it take to make Software Collections work in Fedora?
by Matthew Miller 06 Mar '13

06 Mar '13

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/html… 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>

34 86

Django-1.5 build
by Matthias Runge 04 Mar '13

04 Mar '13

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-1.… -- Matthias Runge <mrunge(a)matthias-runge.de> <mrunge(a)fedoraproject.org>

7 16

dietlibc
by Kevin Kofler 04 Mar '13

04 Mar '13

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

8 11

Package_update_HOWTO
by Brad Bell 01 Mar '13

01 Mar '13

I often use the web page https://fedoraproject.org/wiki/Package_update_HOWTO and have a few edits to suggest. Who would be the proper person to contact ?

5 6

Orphaning the-board
by Cosimo Cecchi 01 Mar '13

01 Mar '13

Hi all, The "the-board" project hasn't seen almost any development upstream and it currently doesn't build in rawhide due to previous gjs API changes. I just don't have the time to try and reviving it these days, so I'll orphan the package. Cheers, Cosimo

3 4

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 February 2013