On Fri, 29.04.11 17:46, Greg KH (greg(a)kroah.com) wrote:
> > > I think /srv actually makes a lot of sense. Probably not so much on the
> > > desktop, but the boundaries are blurry, and I see no reason to set
> > > things up differently in this respect between servers and desktops. I
> > > see little benefit in removing this directory.
> > >
> > > Lennart
> > >
> > I think moving /selinux is a bit more complicated then just a simple
> > kernel change. We have libselinux changes, Lots of tools have learned
> > over the years the path of /selinux and lots of users know about it.
> > I am willing to work towards the goal of moving /selinux, but I might
> > end up with a symbolic link if we can not fix all of the problems.
> A symbolic link from /selinux to point at /sys/fs/selinux/ is a good
> idea to help people migrate. The startup tools should be able to create
> this if /sys/fs/selinux/ is not present, right?
This is not necessarily easy to do actually, since for upgraded systems
/selinux needs to be an actual directory in the rootfs to be useful as
mount points. At boot time the rootfs is read-only, hence removing the
dir then and turning it into a symlink is difficult.
However, we can use the same approach as we did for moving /var/run to
/run: on new installs create it as a symlink and on upgrades simply make
it a bind mount.
For the long run we could also add %post scripts to filesystem.rpm which
moves away the old /selinux, and recreates it as symlink. Unfortunately
that cannot be done completely atomic, but that property is not really
necessary here anyway I think.
So, yeah, it isn't super-pretty doing this move, but we can handle it
more or less exactly like the /var/run → /run move.
Lennart Poettering - Red Hat, Inc.
The clock is ticking. The days are counting down. The release of
Fedora 15, codenamed "Lovelock," is scheduled for release in late
May. Fedora is the leading edge, free and open source operating
system that continues to deliver innovative features to users
worldwide, with a new release every six months.
We are delighted to announce the availability of the Beta release
of Fedora 15.
"I beta one American dollar that you will love this release!"
Come see why we love Fedora so much. We are betting you will,
too. Download it now: http://fedoraproject.org/get-prerelease?wkanF15b
== What is the Beta Release? ==
The beta release is the last important milestone of Fedora 15. Only
critical bug fixes will be pushed as updates leading to the general
release of Fedora 15 in May. We invite you to join us in making
Fedora 15 a solid release by downloading, testing, and providing
your valuable feedback.
Of course, this is a beta release, meaning that some problems may still
be lurking. A list of the problems we already know about can be seen on
the Common F15 bugs page, at http://fedoraproject.org/wiki/Common_F15_bugs.
If you find a bug that's not found on that page, be sure it gets
fixed before release by reporting your discovery at
https://bugzilla.redhat.com/ Thank you!
== Features ==
Desktop enthusiasts and end users of all sorts can look forward to:
* Gnome Shell and the Gnome 3 desktop. Gnome 3 is the next major
version of the Gnome desktop. After many years of a largely
unchanged Gnome 2.x experience, GNOME 3 brings a fresh look
and feel with GNOME Shell.
* LibreOffice Productivity Suite. LibreOffice is a fork of
OpenOffice, with the support of the OpenOffice.org community.
All of the applications you know and love are still there,
including apps for spreadsheets, document creation, and presentations.
* Desktop environments a-plenty. The Xfce and LXDE spins have
been updated, and the Fedora Spins SIG has other offerings
tailored to a wide variety of user needs.
Sysadmins will love features such as:
* Appliance building. BoxGrinder creates appliances (virtual
machines) from simple plain text appliance definition files
for various virtual platforms, and is great for building
appliances for use in a Cloud environment.
* Dynamic Firewall. The dynamic firewall mode aims to make it
possible to change firewall settings without the need to restart
the firewall and to make persistent connections possible.
Coders have lots of new development tools to try out, including:
* Updates to popular languages. Python 3.2, Rails 3.0.3, and
OCaml 3.12 are all included in Fedora 15.
* Project tooling. Maven 3 is a Java project management, project
comprehension, and build system tool.
* Compiling and debugging. GDB gets an update to 7.3, and GCC
4.6 is included. (Fedora 15 has also been rebuilt using GCC 4.6!)
And that's only the beginning. A more complete list and details of
all the new features in Fedora 15 is available here:
We have nightly composes of alternate spins available here:
== Contributing ==
For more information on common and known bugs, tips on how to report
bugs, and the official release schedule, please refer to the release
notes at http://docs.fedoraproject.org.
There are many ways to contribute beyond bug reporting. You can help
translate software and content, test and give feedback on software
updates, write and edit documentation, help with all sorts of promotional
activities, and package free software for use by millions of Fedora
users worldwide. To get started, visit http://join.fedoraproject.org today!
devel-announce mailing list
On Fri, 29.04.11 16:34, Greg KH (greg(a)kroah.com) wrote:
> > > I think it's a very good decision - I never understood why selinux dir
> > > is directly under /.
> > Yes, I think this would be a good thing to have in F16.
> > Note however that this needs a tiny kernel patch to work, to create the
> > mount point under /sys/fs/selinux. This is a trivial patch and has been
> > done for /sys/fs/cgroup before, so I assume this would be easy to get
> > in and just needs a champion to push this forward.
> As I did this for /sys/fs/cgroup I can do it for /sys/fs/selinux as
> well, just let me know.
I'd say "yes, please" to this, right-away.
But I guess this is up to Dan Walsh to say.
Dan, could you say "yes" to this, please? If so, then the first step to
making this happen for F16 would already have been taken!
Lennart Poettering - Red Hat, Inc.
Biosdevname version is updated from 0.3.7 to latest upstream in Fedora 15. Please expect the following change -
The naming for PCI add-on devices is changed from pci<slot number>p<port number>_<virtual function instance> to p<slot number>p<port number>_<virtual function instance>. If you are upgrading to F15 from F15-alpha or F15-beta, you could encounter following issue -
"/etc/sysconfig/network-scripts/ifup-eth: Device pci5p1 does not
seem to be present, delaying initialization."
The config files under /etc/sysconfig/network-scripts/ are of the form "ifcfg-pciXpY" and the "DEVICE=" directive will have pciXpY names when F15-Beta is installed. As the interface name changes
when upgraded to F15, the ifcfg-* files and DEVICE= field remain same causing this issue.
Please rename the ifcfg-pciXpY files to ifcfg-pXpY and change the DEVICE= field from pciXpY to pXpY before reboot to avoid the issue.
> Date: Mon, 02 May 2011 08:48:26 +1000
> From: David Timms <dtimms(a)iinet.net.au>
> Subject: adding manual to existing package - soft review ?
> To: Development discussions related to Fedora
> Message-ID: <4DBDE33A.9030704(a)iinet.net.au>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Hi, I'm adding a subpackage -manual to audacity to include the
> additional manual archive. It links from the help menu items if it is
> installed, or else points you to the in development online version.
> I already made a mistake and included manual files in both the main and
> sub package. The spec change  I've committed fixes this.
> The -manual package can be used by either audacity or
> audacity-freeworld. At the moment the manual spec marks up the
> datadair/audacity folder and hence dually owns it with audacity if that
> is installed. Reading the packaging examples, seems that this can
> sometimes be OK, but does what I've done make sense ?
In your updated spec the manual (from the URL) does not contain a
version. When creating a sub-package, both audacity and
audacity-manual will have the same version. I do not think this is
always correct, you probably want to use the manual from the same
version, or create a separate package if versions can be mixed.
> Or should I Require the audacity (or audacity-freeworld) package, and
> not add the datadir/audacity folder to the -manual directory.
If the manual does not need to be the same version as audacity and/or
audacity-freeworld, I guess that using a Requires and creating an
independent sub-package is the best choice.
> Thirdly, vague recollection of one source/package. Should the -manual
> just be a separate package anyway (review?) ? It's likely to be updated
> more often, but not necessarily in sync with the program.
> 4. Being new to git/fedpkg, how can I tell which branch I'm on ?
$ fedpkg switch-branch -l
$ git branch
the active branch is marked with a *.
More git/fedpkg can be found on
http://fedoraproject.org/wiki/Using_Fedora_GIT or even
I've got a question whose answer I expected to find on one of these
pages, but no joy:
I'm packaging a library that does some heavy mathematical
computations. The build system tries to cleverly determine whether an
Intel CPU with vector instructions is being used. Until I can
convince upstream to do this at runtime, I'll need to build the
package (a library) for the lowest common denominator. The package
checks for MMX, SSE, SSE2, SSE3, and SSSE3. For i686, can I assume
MMX? SSE? I believe I can also build an SSE2 version of the library
and drop it into /usr/lib/sse2. How about for x86_64? Can I assume
SSE2 is available? (I thought I could, but I see that /usr/lib64/sse2
exists on my machine, so now I'm uncertain.) I don't see a
/usr/lib64/sse3 or /usr/lib64/ssse3, so I just have to forget those,
If there is a wiki page that answers these questions, I'd appreciate a
pointer. If not, perhaps someone with edit privileges could add the
answer to one of the pages listed above. Thanks,