we use mock for local package build, but it's very slow. now we install
a new host just for mock with 8core, ram disks etc. it seems it still
slow. first of all most of the time mock use only one 1 core of the cpu.
is there any way to speed up different part of the mock build process?
thanks in advance.
ps. anyway is there any better place to discuss it?
Levente "Si vis pacem para bellum!"
So we're getting close to having a working fsck tool so I wanted to
take the opportunity to talk about the future of BTRFS in Fedora.
Coming up in F15 we're going to have the first release of Fedora where
we don't need the special boot option to have the ability to format
you filesystem as BTRFS. This is in hopes that we can open it up for
wider testing before possibly making it the default filesystem. I
realize we're in the early stages of F15, but since filesystems are
big and important I'd like to get an idea of the amount of work that
needs to still be done to get BTRFS in shape for being Fedora's
default filesystem. So here are my goals
1) Fedora 16 ships with BTRFS as the default root filesystem.
2) Fedora 16 ships without LVM as the volume manager and instead use
BTRFS's built in volume management, again just for the default.
Fedora 16 is a very aggressive target, which is also why I'm bringing
it up now. I think we will be ready by then. We have had the ability
to install Fedora onto BTRFS since F11, and I have been testing it
since then without too many issues. Some things that I know are going
to be gotcha's at this point
1) GRUB support. Edward Shishkin did GRUB1 patches for BTRFS a while
ago, but they were obviously never merged upstream and were also not
included into fedora. These would either need to be cleaned up and
put into our grub package, or we'd need to put /boot on a different
filesystem. I personally hate the idea of having a non-btrfs /boot
partition but I'm not the one in charge of GRUB.
2) Anaconda support. I've already talked with Will Woods about this
some. Really anaconda will format a normal disk with BTRFS with no
problem today, the biggest issue here is adding the volume management
stuff and allowing users to create subvolumes via anaconda.
3) All the various little tools that we have for putting together
LiveCD's that are very ext* centered. I've not even looked at this
yet, but I assume it's going to be kind of a pain.
4) FSCK does actually need to be finished. I don't see this as a
problem as Chris is 90% done with it at this point so it should be
ready even before F15 ships, but it's worth mentioning.
I would really like to see a lot of testing on BTRFS in the F15 cycle
just so we know how well it works in the non-developer's use case.
It's easy for me to use it because I work on it and I understand the
limitations, so it would be nice to have much broader testing.
So what are your thoughts? Thanks,
It seems that Peter has been unavailable for Fedora packaging work for
a while now. I have been maintaining two of his packages, (midori and
webkitgtk) but there are a number of others which may need attention.
Shows him unresponsive on rb_torrent as well.
deluge -- A GTK+ BitTorrent client with support for DHT, UPnP, and PEX
epiphany-extensions -- Extensions for Epiphany, the GNOME web browser
glabels -- A program for creating labels and business cards for GNOME
gnome-applet-music -- A GNOME panel applet to control various music players
gnome-theme-curvylooks -- A modern Clearlooks theme using a Bluecurve-like color scheme
labyrinth -- A simple yet powerful mind-mapping tool for the GNOME desktop
lucidlife -- A Conway's Life simulator
man-pages-es -- Spanish man pages from the Linux Documentation Project
midori -- A lightweight GTK+ web browser
ndesk-dbus -- Managed C# implementation of DBus
ndesk-dbus-glib -- Provides glib mainloop integration for ndesk-dbus
nemiver -- A GNOME C/C++ Debugger
ots -- A text summarizer
rb_libtorrent -- A C++ BitTorrent library aiming to be the best alternative
scribes -- A sleek, simple, and powerful text editor for the GNOME desktop
scribes-templates -- Templates ("Snippets") for the Scribes text editor
tango-icon-theme -- Icons from Tango Project
tango-icon-theme-extras -- Extra Icons from the Tango Project
telepathy-haze -- A multi-protocol Libpurple connection manager for Telepathy
telepathy-mission-control -- Central control for Telepathy connection manager
viaideinfo -- Displays the information of installed VIA IDE controllers
webkitgtk -- GTK+ Web content engine library
Peter: If you are out there, please let us know.
I sent email several times over the last six months with no reply. :(
If we don't hear anything soon, we should reassign his packages or at
least get active co-maintainers on all of them so they are going on.
I'd be happy to take over midori and webkitgtk.
Le Lun 21 février 2011 22:27, Hedayat Vatankhah a écrit :
> On ۱۱/۰۲/۲۲ 12:30, Nicolas Mailhot wrote:
>> Le lundi 21 février 2011 à 21:42 +0330, Hedayat Vatankhah a écrit :
>>> Now, as is being discussed in , which fonts should be pulled by a
>>> desktop environment as its dependencies?
>> A DE should pull in the fonts group. That's the only font list proofed
>> by i18n for each release.
> Thanks for the answer. I also thought that it is reasonable, but wanted
> to make sure before calling others for it. I just wonder if it is
> possible to have group dependencies in comps.xml or by packages! What is
> the best way for enforcing such dependencies in Fedora?
Well that is a question for fedora-devel and the tools people :)
-----BEGIN PGP SIGNED MESSAGE-----
currently, I'm the maintainer of logcheck. It parses system logs and
sends mails defined by regular expressions.
It's a package mostly adopted for debian. The README says, it is
recommended to create an own user and put it into adm group. This leads
to some problems, because fedoras system logs are currently owned
root:root and currently just readable by user.
Three possible solutions appear:
- - make logcheck owned by root (against package maintainers hint)
- - make the log reading program use the sticky option
- - change systems logs owners from root:root mode 600 to root:adm mode
640 (or something similar)
I would prefer the latter. What package owns "/var/log/messages"?
(Who to contact...?)
yum provides "*/messages" did not list it. Is it really unowned?
What do you think? Did I miss something? Has anybody of you another hint?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Following is the list of topics that will be discussed in the FESCo
meeting tomorrow at 17:30UTC (12:30pm EDT) in #fedora-meeting on
Links to all tickets below can be found at:
= Followups =
#topic #516 Updates policy adjustments/changes
#topic #515 Investigate a "features" repo for stable releases
#topic #517 Updates Metrics
#544 List of services that may start by default
== New Business ==
#563 suggested policy: all daemons must set RELRO and PIE flags
#275 Propose a soft-path via co-maintainer status to becoming sponsored
#531 Orphaned package ownership claiming clarification
= Fedora Engineering Services tickets =
= Open Floor =
For more complete details, please visit each individual ticket. The
report of the agenda items can be found at
If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fesco,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting.
Am Montag, den 07.02.2011, 19:49 +0000 schrieb Bill Nottingham:
> commit f2cb3971ffb2a53b9f0fdc536cdcc4f9c3a87876
> Author: Bill Nottingham <notting(a)redhat.com>
> Date: Fri Jan 28 16:24:54 2011 -0500
> Move system-config-* tools from base-x to appropriate desktops.
> In Admin tools, make s-c-network optional, and swap gnome-disk-utility for s-c-lvm.
> diff --git a/comps-f15.xml.in b/comps-f15.xml.in
> index ff1fd16..f2c92a8 100644
> --- a/comps-f15.xml.in
> +++ b/comps-f15.xml.in
> @@ -9,14 +9,13 @@
> <packagereq type="default">authconfig-gtk</packagereq>
> + <packagereq type="default">gnome-disk-utility</packagereq>
> <packagereq type="default">gnome-packagekit</packagereq>
> <packagereq type="default">system-config-boot</packagereq>
Next time you a change like this one, please announce it to the lists
because it has a large impact on the spins. Even better: Ask *before*
making this change.
While we are at it: I'd like to suggest that non-desktop groups like
'admin-tools' should be desktop-agnostic.
there is a new way to contact the board now: Recently the board's trac
instance was opened for ticket submissions by all FAS account holders.
In order to bring something to the board's attention, just file a ticket
You'll need to login with your FAS credentials.
If you add the keyword "meeting", the ticket will automatically be added
to the board's agenda and discussed in the next board meeting.
For privacy reasons, you can only see your own tickets or tickets where
you are in CC.
Please forward this info to all relevant lists if you think I have
P.S.: I wonder why the board didn't announce this.