upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse
I have the yarrow's iso files on my HD in a RH9 system. Let's say I want
to upgrade selected packages using an "apt-get install" pointing to my
iso-mounted files, how do I do it?
i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc..
Then what is the complete procedure to make my apt look into my own HD to
upgrade packages. Can anybody redirect me to the correct
resource or some literature hanging on the web? Thanks.
Assume also that I do not wish to burn CDs! I do not want to use
apt-cdrom. Thanks.
With kind regards,
Didier.
---
PhD student
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Singapore 117603
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
Website: http://ssls.nus.edu.sg
1 year, 4 months
orphan most of my packages
by Andy Shevchenko
Hello,
I have no more time to support the following packages in the Fedora.
jack-audio-connection-kit -- The Jack Audio Connection Kit
klamav -- Clam Anti-Virus on the KDE Desktop
man-pages-uk -- Ukrainian man pages from the Linux Documentation Project
python-alsa -- Python binding for the ALSA library
qstat -- Real-time Game Server Status for FPS game servers
uniconvertor -- Universal vector graphics translator
--
With Best Regards,
Andy Shevchenko
10 years, 8 months
[ANNOUNCE] bfq disk I/O scheduler
by Paolo Valente
Hi,
I have been working for a few years (with Fabio Checconi) on a disk
scheduler providing definitely lower latencies than cfq, as well as a
higher throughput with most of the test workloads we used (or the same
throughput as cfq with the other workloads). We named this scheduler
bfq (budget fair queueing). I hope this is the right list for announcing
this work.
One of the things we measured in our tests is the cold-cache execution
time of a command as, e.g., "bash -c exit", "xterm /bin/true" or
"konsole -e /bin/true", while the disk was also accessed by different
combinations of sequential, or random, readers and/or
writers. Depending on which of these background workloads was used,
these execution times were five to nine times lower with bfq under
2.6.32. Under 2.6.35 they were instead from six to fourteen times
lower. The highest price paid for these lower latencies was a 20% loss
of aggregated disk throughput for konsole in case of background
workloads made only of sequential requests (due to the fact that bfq
of course privileges, more than cfq, the seeky IO needed to load
konsole and its dependencies). In contrast, with shorter commands, as
bash or xterm, bfq also provided up to 30% higher aggregated
throughput.
We saw from 15% to 30% higher aggregated throughput also in our
only-aggregated-throughput tests. You can find in [1] all the details
on our tests and on other nice features of bfq, such as the fact that
it perfectly distributes the disk throughput as desired, independently
of disk physical parameters like, e.g., ZBR. in [1] you can also find
a detailed description of bfq and a short report on the maturity level
of the code (TODO list), plus all the scripts used for the tests.
The results I mentioned so far have been achieved with the last
version of bfq, released about two months ago as patchsets for 2.6.33
or 2.6.34. From a few days a patchset for 2.6.35 is available too, as
well as a backport to 2.6.32. The latter has been prepared by Mauro
Andreolini, who also helped me a lot with debugging. All these patches
can be found here [2]. Mauro also built a binary kernel package for
current lucid, and hosted it into a PPA, which can be found here [3].
A few days after being released, this version of bfq has been
introduced as the default disk scheduler in the Zen Kernel. It has
been adopted as the default disk scheduler in Gentoo Linux too. I
also recorded downloads from users with other distributions, as, e.g.,
Ubuntu and ArchLinux. As of now we received only positive feedbacks
from the users.
Paolo
[1] http://algo.ing.unimo.it/people/paolo/disk_sched/
[2] http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
[3] Ubuntu PPA: ppa:mauro-andreolini/ubuntu-kernel-bfq
12 years, 1 month
Re: Testing zsh completion for fedpkg
by Ben Boeckel
Christopher Aillon <caillon(a)redhat.com> wrote:
> I missed the first notice of this go by, but I use zsh so can play with
> it in the next few days. Can you post the updates so I don't hit the
> same bugs you did?
Sure. Attached. The bugs were mainly with zsh conventions and getting
the sed command for the branch selection corrected.
--Ben
12 years, 1 month
how to speed up mock?
by Farkas Levente
hi,
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!"
12 years, 2 months
HEADS UP! Ohloh Fedora repositories
by Peter Lemenkov
Hello All!
I'm currently in process of automatic enlisting of all ~10K Fedora Git
repos at Ohloh. Right now roughly 7% of repositories were added and
overall process will be finished in a 20-30 hours (it takes me about
5-10 seconds to properly add repository, and I don't want to speedup
this process - to prevent Ohloh from accidental DoS).
Just FYI.
--
With best regards, Peter Lemenkov.
12 years, 4 months
Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
by Jesse Keating
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As you might be aware, there was a period of roughly two weeks where a
gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and
Fedora 15. Items built with this could have undefined behavior, which
could lead to data corruption.
Unfortunately I'm told that it is impossible to look at a generated
binary and detect whether or not the binary would be effected by this
bug. The only reliable way to tell would be to re-create the build
environment exactly, except replace GCC with one that will detect the
error scenario and print something. As this is a significant amount of
work, I decided instead to just rebuild the potential problem builds.
I detected all the "latest" builds of packages that had gcc-4.5.1-3.fc14
in the buildroot, and then further narrowed it down to things which
require rtld(GNU_HASH) to find the things that actually used gcc (since
gcc gets thrown in every buildroot anyway).
For Fedora 15 this was a simple task. Just find the packages where the
latest build is "bad", bump it and rebuild it. End of story. This work
is already done (except that a few have failed, and I need to follow up
on those).
For Fedora 14 the matter is much more complicated. Builds are spread
out across 3 main tags, dist-f14, dist-f14-updates-testing, and
dist-f14-updates-candidate.
dist-f14 is things that have made it through bodhi as stable.
dist-f14-updates-testing is for things which are currently in
updates-testing
dist-f14-updates-candidate is for things which could potentially become
an update should the maintainer decide.
To handle the F14 scene I've come up with this strategy:
* For things tagged in dist-f14 and no newer build elsewhere, do a bump,
build and tag directly into dist-f14. While there is some risk of
breakage, it is quite minimal and with discussion from QA we are willing
to take that chance. This work is ongoing.
* For things tagged in dist-f14-updates-testing, do a bump, build and
then edit the bodhi ticket to add the new build, and re-push to
updates-testing. This work will begin soon.
* for things tagged in dist-f14-updates-candidate, do a bump and build.
Then look for an open bodhi ticket for that package, adjusting as
needed. If no bodhi ticket is found, do not create a new one, just
leave the build as is. This work will begin soon.
Using this strategy we should be able to replace potentially bad builds
with corrected ones wherever they might have been published (barring the
failed builds). This message is mostly a heads up as to what's happening.
PS I had a small misfire in some of the F14 builds, I used the wrong
input set of packages. There is a chance that some f14 builds were done
unnecessarily. The unnecessary builds will just be ignored and left to
expire.
PPS I did not modify my bump script yet to attempt a commit to master
and merge to the f14 branch. In the interest of time, I took the easy
route and just did commits to the f14 branch. Maintainers can do a
merge and fixup after the builds have been done if they wish to have
their branches in sync with master once more.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyrpk4ACgkQ4v2HLvE71NW6IwCbBex8eV/0M2eOmfqTqakx14zC
pDMAnA6iBmjaMC+E87fgp6CvLoxEhAiF
=GFLf
-----END PGP SIGNATURE-----
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
12 years, 6 months
