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!"
Nowadays the jack project has two branches - old jack (1) branch with
version 0.116.2 and new one called jack2 version 1.9.3.
I'd like to gather opinions and suggestions about applying new version for F13.
Please, share your thoughts!
With Best Regards,
early in the F13 cycle, we enabled the bytecode interpreter in our
freetype package, since the patents on that have expired last fall.
Unfortunately, it turned out that many free fonts don't actually benefit
from this, and actually look worse with the bci. The reason for that is
that without the bci, freetype uses its autohinter on all fonts, but
with the bci turned on, it only applies hints to fonts which have them,
and leaves other fonts alone.
Behdad investigated the situation, and we have a plan to fix this, but
doing it properly requires enhancements in multiple places (freetype,
fontconfig, pango), and will not be ready in time for F13.
Therefore, we decided to turn the bci off again until the necessary
changes are in place to use it only on fonts which benefit from it. This
change went into freetype-2.3.11-3.fc13.
If your fonts look subtly different tomorrow, this is why...
I would like to add a feature for F-14: D programming
For this the needs are
- D compiler
- standard runtime library
Fedora will take some benefit to increase its community of developers
with the inclusion of this feature. And an easy way for people who want
to try this language.
Feature page: https://fedoraproject.org/wiki/Talk:Features/D_Programming
I just pushed a version 0.7.5 of bodhi into production. This release
contains the following notable changes:
proventesters & strict critical path update handling
Critical path package updates now require positive karma from two
proventesters, and a single +1 from one other community member.
You can get a list of critical path updates using the bodhi web interface:
You can optionally pass in a specific 'release' or an 'untested' flag,
which will return a list of critical path updates that have yet to be
approved. I have not added these links to the main interface yet,
because at the moment they are fairly expensive calls. This will be
addressed in an upcoming release.
The latest command-line client also supports these options as well:
$ bodhi --critpath --untested --release F13
I re-enabled the auto-obsoletion code in bodhi. This means that new
updates will automatically obsolete older testing updates containing the
same packages. The new update will also inherit all of the old updates
bugs and notes. This code had been disabled for a while now, due to
some nasty edge cases, but those have since been resolved.
If you experience any problems, please file tickets here:
devel-announce mailing list
You don't seem to be working all that good!
I'm sure I'm not the only one seeing this. In particular:
Install 1 Package(s)
Upgrade 85 Package(s)
Total download size: 207 M
Is this ok [y/N]: y
Setting up and reading Presto delta metadata
updates/prestodelta | 17 kB 00:00
Processing delta metadata
Download delta size: 2.1 M
(1/10): ModemManager-0.3-9.git20100409.fc12_0.3-13.git20 | 126 kB 00:00
(2/10): NetworkManager-0.8.0-6.git20100408.fc12_0.8.1-0. | 510 kB 00:00
(3/10): NetworkManager-glib-0.8.0-6.git20100408.fc12_0.8 | 106 kB 00:00
(4/10): NetworkManager-gnome-0.8.0-6.git20100408.fc12_0. | 301 kB 00:00
(5/10): NetworkManager-pptp-0.7.997-3.git20100120.fc12_0 | 47 kB 00:00
(6/10): NetworkManager-vpnc-0.7.996-4.git20090921.fc12_0 | 56 kB 00:00
(7/10): gstreamer-plugins-bad-free-0.10.18-1.fc12_0.10.1 | 339 kB 00:00
(8/10): gstreamer-plugins-good-0.10.22-1.fc12_0.10.23-1. | 427 kB 00:00
(9/10): libmtp-1.0.2-1.fc12_1.0.3-2.fc12.x86_64.drpm | 33 kB 00:00
(10/10): wpa_supplicant-0.6.8-8.fc12_0.6.8-9.fc12.x86_64 | 191 kB 00:00
Finishing rebuild of rpms, from deltarpms
<delta rebuild> | 4.5 MB 00:03
Presto reduced the update size by 54% (from 4.5 M to 2.1 M).
Package(s) data still to download: 202 M
...which includes the most recent openoffice.org update - a prime
candidate for drpm goodness.
Am I missing something obvious?
Probably thought of a million times, but was wondering whether it would
be possible, and useful to give diff capabilities within the koji web
eg: x86_64 build
Output build.log (tail)
Output build.log (tail) (diff)
root.log (tail) (diff)
state.log (tail) (diff)
hovering over diff would cause a (json) load of options:
- diff -u with other arch:
i686, ppc, ppc64
- diff -u with other version:
list other builds in this release (eg devel): 4.3-1, 4.3-4,
- diff -u with other release:
list other releases of same version that have been built: f12, f13
The diff could be generated to look like a viewvc side by side diff.
Bonus points if the diff ignores things like:
- tmp file names (/var/tmp/rpm-tmp.trZK8P)
- log address: 0x2b9c82662f90
- builder: x86-05.phx2.fedoraproject.org
Previously, I found the build logs rather boring; by saving each
locally, then running meld on them, I immediately see what has changed
between eg F12 and devel.
Any comments (other than 'show me the money/code') ?