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
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
[Test-Announce] 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
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
11 years, 2 months
Proposed F19 Feature: Cinnamon as Default Desktop
by Jaroslav Reznik
= Features/Cinnamon as Default Desktop =
https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop
Feature owner(s): Eric Smith <eric(a)brouhaha.com>
This feature proposes that Fedora switch the default desktop interface from
Gnome 3 to Cinnamon. Cinnamon provides a desktop interface that is more
familiar to Windows and Gnome 2 users than the standard Gnome Shell interface,
while being built from Gnome 3 components.
== Detailed description ==
The Gnome 3 interface is substantially different that the traditional desktop
interfaces on both Linux and Windows. While it is good that there is research
into new user interface concepts, many users prefer to have a traditional
interface that they are accustomed to. Unfortunately it is difficult or
impossible to assess what fraction of the user base prefers Gnome Shell vs. a
more traditional interface. I'm not trying to start (or continue) a flame war
here, so I won't state any of my own criticisms of Gnome Shell here, but I
will observe that a number of very high profile people in the Linux community,
such as Linus Torvalds and Alan Cox, have publicly announce that due to
problems with Gnome Shell they are switching to a different desktop and/or
Linux distribution.
I submit the proposition that it is easier for a user doing a new Fedora
install to start with a traditional desktop, and switch to the Gnome Shell if
they prefer that, than to start with Gnome Shell and switch to a traditional
desktop.
The Cinnamon desktop provides a traditional desktop while being based on the
latest Gnome and GTK components, so it seems like a better candidate for a
default desktop than MATE, which is based on older components.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
Proposed F19 Feature: NetworkManager Bonding Support
by Jaroslav Reznik
= Features/NetworkManagerBonding =
https://fedoraproject.org/wiki/Features/NetworkManagerBonding
Feature owner(s): Pavel Šimerda <psimerda at redhat.com>, Dan Williams <dcbw
at redhat dot com>
NetworkManager should be able to configure bond master interfaces with commonly
used options and recognize their existing configuration on startup without
disrupting their operation.
== Detailed description ==
NetworkManager's existing support for bond interfaces covers a limited number
of use-cases and can conflict with existing bonding configurations created by
tools like libvirt. The purpose of this Fedora feature is to implement more
flexible bonding infrastructure in NetworkManager to support an expanded number
of use-cases and to be more cooperative with other users of bonding.
Support will be added to NetworkManager to detect the existing configuration of
a bond interface and its slaves and to seamless "take over" that connection
without disrupting it. Even if the existing configuration is not backed by
ifcfg files on-disk, NetworkManager will leave that configuration on the
interface unless told to change it by the user via GUI or CLI tools.
Additional bond interface configuration will be added to expand the use-cases
and hardware that NetworkManager can configure (eg primary, use_carrier,
xmit_hash_policy, etc).
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
11 years, 2 months
how reload udev rules and systemd on F18
by Sérgio Basto
Hi,
how I should do the old command udevadm: control --reload-rules ?
is correct : systemctl restart udev.service ?
I don't find any in documentation that guarantee this .
BTW in F18: udev.service change the name to systemd-udevd.service.
So put in package spec, is this correct way ?
%if 0%{?fedora} < 18
systemctl restart udev.service
systemctl restart udev-trigger.service
systemctl restart udev-settle.service
%else
systemctl restart systemd-udevd.service
systemctl restart systemd-udev-trigger.service
systemctl restart systemd-udev-settle.service
%endif
Thanks,
--
Sérgio M. B.
11 years, 2 months
