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, 8 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
11 years
orphaning gdk-pixbuf
by Kevin Fenzi
Greetings.
I just orphaned gdk-pixbuf in pkgdb.
It failed the mass rebuild, not much left that depends on it, and
nothing I need. ;)
% repoquery --source --whatrequires gdk-pixbuf
gdk-pixbuf-0.22.0-38.fc12.src.rpm
gdk-pixbuf-0.22.0-38.fc12.src.rpm
gdk-pixbuf-0.22.0-38.fc12.src.rpm
gdk-pixbuf-0.22.0-38.fc12.src.rpm
soundtracker-0.6.8-8.fc12.src.rpm
xosd-2.2.14-13.fc12.src.rpm
So, if anyone really really really wants to keep it alive, feel free to
take it and fix it so it builds and works. ;)
kevin
11 years, 9 months
bugzilla bugzappers?
by Bert Desmet
hi!
This is something I got in my mail box today.
As I don't have a valid answer for this, maybe someone else can answer for me?
cheers, Bert
the url of the blog of the guy: http://www.krisbuytaert.be/blog/
== the mail ==
Dear Fedoracommunity,
Over the course of the day I recieved 22^3 mails from your friendly Bug Zapper.
Most of those bugs where bugs I had reported upon crashes using
bug-buddy. Bugs on different desktop tools such as .. synergy,
evolution, gwibber , gnome-settings and probably some others
I do understand that I development goes on and on .. and your fancy
devs don't care anymore about
bugs I reported on Fedora 12 as they are all hacking on Fedora 15.
But what I don't get is that non of these bugs was ever touched,
they've been automatically created , and automatically closed
<a href="http://tieguy.org/blog/2004/09/">Luis</a> already told us
ages ago .. that every project needs a bugmaster apparently Fedora
replaced that bugmaster with a Bug Zapper.
So can someone please explain my why I should continue to try to
improve Fedora by reporting bugs ?
12 years
OpenBUGS program has a pre-compiled )S library from MS Windows. Any possibility to package it?
by Paul Johnson
I decided to try to help the cause of Bayesian statistics and the open
source effort of the OpenBUGS group (http://www.openbugs.info/w/) by
making some packages. In case you are not a statistically-inclined
person, it is worth knowing that Bayesian Updating with Gibbs Sampling
(BUGS) has caused something of a methodological landslide since the
early 1990s, helping scholars to model processes that were thought to
be too difficult.
In Linux, we do not have access to the OpenBUGS GUI, which
I've built deb and rpm packages for RedHat, Fedora and Ubuntu. They
are available in my webspace and in the project.
I wish these could be in the official linux repositories, but I've not
tried to put these into an official repository because there are 2
problems that seem prohibitive.
First, the (now open) code for OpenBugs is written in Object Pascal
and it requires a compiler framework called "Black Box" which is, as
far as I can understand, available only for MS Windows. The OpenBUGS
team compiles that library, and then for linux we use some accessor
scripts to send jobs to it.
This, of course, goes against the packaging policy that pre-compiled
libraries are prohibited.
I was wondering if there could be an exception here, since the code is
actually available and open. This is more reasonable than
re-packaging the closed Nvidia drivers, for example.
Second, there is a little packaging problem for 64 bit systems. The
library that is provided is only 32 bit, and to build it for a 64 bit
system, there is a somewhat confusing situation. The library itself
gets put into /usr/lib, which is supposed to be for 64 bit libraries.
And to make the whole thing package up in a workable way, the arch
ends up saying the packge is x86_64, even though it is only 32 bit.
To run OpenBUGS on a 64 bit system, one h as to install the 32bit libc
packages.
I've built the RPM on a 32bit system, it comes out with the proper x86
target in the file name,but that package will not instlal on the 64
bit systems. Should it? (As I said, I can build the package on the 64
bit system, and it comes out with a 64 bit file name, but it is really
32 bits.). Oh, bother, this is confusing to me, I can't imagine your
situation.
http://pj.freefaculty.org/Fedora/14/i386/kups/packages/
On the other hand, the ones I build on a 64 bit system:
Show up with 64bit names even though they are 32 bit programs:
http://pj.freefaculty.org/Fedora/14/x86_64/openbugs-3.2.1-1.x86_64.rpm
In the current Fedora framework, I can't understand if that is
supposed to happen.
--
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas
12 years
Intent to package GNOME Shell frippery
by Hans de Goede
Hi all,
Just a quick heads-up that I plan to look unto packaging the
gnome shell frippery extensions this weekend, if you've the
same plans or are already working on this, please let me know.
So we can avoid doing double work.
I plan to use 1 subpackage per extension of the frippery
extension collection, so that people can install only those
which they want without automatically getting all of
them.
Regards,
Hans
12 years, 1 month
Proposal: retire bittorrent
by Paul Howarth
I propose to retire bittorrent (the original python client) for the
reasons outlined below. If anyone's interested in taking it over
instead, please apply on the package database and I'll transfer
ownership. Think carefully before you act though!
Dead Upstream:
==============
Well, not actually dead but upstream has gone closed-source as of
version 6 so it's effectively dead.
Old Version:
============
Upstream's last open-source release (code dump really) was 5.3
(http://download.bittorrent.com/dl/), which was little more than a GPL
re-licensing of 5.2.2 and a dump of upstream VCS content. Fedora has
been stuck with 4.4.0 though with its PyGTK GUI because the "new" GUI in
version 5 was a rewrite with wxGTK but it didn't work with wxGTK > 2.6
(http://bugzilla.redhat.com/223623) and so was unusable in Fedora.
I believe Mandriva "solved" this problem by having transmission obsolete
bittorrent-gui and just shipping the console version.
Open Bugs:
==========
http://bugzilla.redhat.com/189072 (bittorrent doesn't die gracefully)
http://bugzilla.redhat.com/189295 (bittorrent is not utf-8 aware)
http://bugzilla.redhat.com/237254 (translations not working since python
2.4)
http://bugzilla.redhat.com/246879 (LSB-ize initscripts)
http://bugzilla.redhat.com/489810 (bittorrent stops seeding files, even
when "seed indefinitely" is checked)
http://bugzilla.redhat.com/630569 (traceback due to argument parsing error)
http://bugzilla.redhat.com/678710 (crash due to not running via provided
initscript)
http://bugzilla.redhat.com/707637 (RFE upgrade to 5.x)
Some of these are probably quite easily fixed by someone that knows
their python and is willing to dive into the code but they would have to
be prepared to the de-facto new upstream maintainer if they wanted to
take it on.
Doesn't Obey Protocol:
======================
The bittorrent client is actually blocked on at least one major site due
to violating the protocol and hammering the tracker with announcements:
http://wiki.dimeadozen.org/index.php/Mainline
12 years, 2 months
F15: ugly behavior of "df"
by Reindl Harald
what triggers that since F15 every bind-mount is displayed in
"df" with "ext4" and the full volume-szize and additionally
if BIND is running in a chroot FOUR volumes with the size
of the root-fs are shown and a normal user gets "access denied"?
this is way too much for 3 physical volumes!
[root@rh:~]$ /bin/df -hT
Dateisystem Typ Größe Benut Verf Ben%% Eingehängt auf
rootfs rootfs 29G 8,5G 21G 30% /
udev devtmpfs 7,8G 4,0K 7,8G 1% /dev
tmpfs tmpfs 1,0G 0 1,0G 0% /dev/shm
tmpfs tmpfs 7,9G 552K 7,9G 1% /run
/dev/md1 ext4 29G 8,5G 21G 30% /
tmpfs tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/run
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/lock
tmpfs tmpfs 150M 0 150M 0% /var/www/sessiondata
tmpfs tmpfs 7,9G 0 7,9G 0% /media
/dev/md0 ext4 485M 48M 437M 10% /boot
/dev/md2 ext4 3,6T 474G 3,1T 14% /mnt/data
/dev/md2 ext4 3,6T 474G 3,1T 14% /home
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers/phpincludes
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/usr/lib64/bind
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named.iscdlv.key
/dev/md1 ext4 29G 8,5G 21G 30% /var/named/chroot/etc/named.root.key
[root@rh:~]$ su - harry
[harry@rh:~]$ /bin/df -hT
Dateisystem Typ Größe Benut Verf Ben%% Eingehängt auf
rootfs rootfs 29G 8,5G 21G 30% /
udev devtmpfs 7,8G 4,0K 7,8G 1% /dev
tmpfs tmpfs 1,0G 0 1,0G 0% /dev/shm
tmpfs tmpfs 7,9G 552K 7,9G 1% /run
/dev/md1 ext4 29G 8,5G 21G 30% /
tmpfs tmpfs 7,9G 0 7,9G 0% /sys/fs/cgroup
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/run
tmpfs tmpfs 7,9G 552K 7,9G 1% /var/lock
tmpfs tmpfs 150M 0 150M 0% /var/www/sessiondata
tmpfs tmpfs 7,9G 0 7,9G 0% /media
/dev/md0 ext4 485M 48M 437M 10% /boot
/dev/md2 ext4 3,6T 474G 3,1T 14% /mnt/data
/dev/md2 ext4 3,6T 474G 3,1T 14% /home
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers
/dev/md2 ext4 3,6T 474G 3,1T 14% /Volumes/dune/www-servers/phpincludes
/bin/df: „/var/named/chroot/etc/named“: Keine Berechtigung
/bin/df: „/var/named/chroot/usr/lib64/bind“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.iscdlv.key“: Keine Berechtigung
/bin/df: „/var/named/chroot/etc/named.root.key“: Keine Berechtigung
12 years, 2 months
