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
With kind regards,
Singapore Synchrotron Light Source (SSLS)
5 Research Link,
Email: slsbdfc at nus dot edu dot sg \or\
didierbe at sps dot nus dot edu dot sg
I don't know the right way to fix this, but something is definitely broken;
and something needs to be fixed, one way or the other. The question is what
exactly needs to be fixed.
Consider something like this:
AC_TRY_LINK_FUNC(res_query, AC_MSG_RESULT(yes), AC_MSG_RESULT(no))
Here's what happens on x86_64:
gcc -o conftest -g -O2 -Wall -I.. -I./.. conftest.c -lresolv >&5
/tmp/ccW7EeDX.o(.text+0x7): In function `main':
/home/mrsam/src/courier/authlib/configure:5160: undefined reference to
collect2: ld returned 1 exit status
configure:5147: $? = 1
configure: failed program was:
[ blah blah blah ]
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char res_query ();
| main ()
| res_query ();
| return 0;
The same exact test on FC1 x86 will work.
The reason appears to be that you have to #include <resolv.conf> on x86_64
in order to succesfully pull res_query() out of libresolv.so. You don't
need to do this on x86, and the test program generated by AC_TRY_LINK_FUNC
does not include any headers, but uses a manual prototype.
So, what now?
I've been doing a fair amount of work (ie. a fair slice of my free time
over the last couple of months) on getting Fedora Core booting on Apple
PowerPC. Because the ppc tree already existed (from my understanding,
just not tested on Apple hardware), I was given a huge head start. I now
have a install of FC/devel on my PowerBook and an old PowerMac G3, and
have been reporting bugs against packages (usually with patches) to
correct issues I've found. These can be split into two parts:
1. Existing packages, like the kernel needing a .config file that
produces a kernel that boots, and does something useful.
2. Adding packages that make the system more useful, and are essentially
equivalents for powerpc of packages that FC ships on x86. One example is
hfsutils (needed to write a NewWorld boot partition, bugs #117512, #120811).
Bugs reported against #1 types are accepted and fixed. Bugs against #2
types, it appears that Red Hat engineering people are unsure as to what
they are expected to do. Quoting bug #117512, Bill Nottingham:
"Hm, I suppose there should be some sort of policy on packages not
required for any officially supported arch."
This is not the only example I've come across of this, just the latest
one that has led me to post this message. Can somebody senior from Red
Hat give us some idea as to what the story is here?
FWIW, I believe that we're just "completing" the support for PowerPC,
not adding a new platform, because it pre-existed in devel. A community
driven release of a platform previously unsupported in any way by Red
Hat would certainly be send a really good signal to the doubters out
there that Fedora Core isn't just Red Hat, just like Mozilla wasn't just
Netscape (and they had their doubters too).
Once upon a time, Arjan van de Ven <arjanv(a)redhat.com> said:
> On Sat, 2004-04-10 at 21:57, Jurgen Botz wrote:
> > In the last few kernel RPMS there doesn't seem to be an sg
> > module. It was there in ./2.6.4-1.300, it's missing in 305.
> > What happened to it?
> it's deprecated
How do I control my tape library robot? AFAIK that is only controlled
via sg (the other SCSI modules ignore tape robots).
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
What if I wanted to build a kernel RPM for FC1 that was like the existing 2.4.22
ones except for being 2.4.26? Where would I start? I see that the spec is
fairly long, and includes a bunch of patches, etc. Can anyone give me a hint on
a starting point? Or am I barking up the wrong tree entirely?
The reason I'm trying to do this is that with FC1 stock kernels I am getting
random kernel *freezes* - not panics or even oopses - on multiple machines even
when trying the usual frequently recommended "apm=off acpi=off nohlt"
recommended incantations. It's my hope that some kind of bugfix has been
applied somewhere along the line that would address this problem, as I can't
seem to debug it.
Any ideas of any kind in this vein would be greatly appreciated at this point...
I was reading the Gnome release schedule and saw that
Gnome 2.6.1 is going to be released very soon with a
lot of bug fixes, some new translations and a few
performance improvements and was curious if it is
going to make it into FC2 or if a patched version of
Gnome 2.6.0 will be used.
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for 25�
I've noticed that, with Fedora Core 2 test 2, I get an error at each
Initializing firewire controler (ohci1394): FATAL: Module ohci1394 not
Does it mean the kernel doesn't support FireWire ? I have nothing to
test FireWire currently but I plan to buy an external FireWire hard
driver. Does it have any chance to work ? If not, why isn't the ohci1394
module included in the Fedora's kernel ?
Thanks for your help.
Julien Olivier <julo(a)altern.org>
I decided to test a FC1 "Everything" apt-get dist-upgrade to FC2 using
rawhide from April 21st. It found two cases where removed subpackages
were not Obsoleted by FC2 packages, causing a file conflict.
tcl & tk
These packages have been fixed and will be in tomorrow's rawhide push,
but I have copied them manually to fedora.us RPMS.updates. It is good
that the files conflicted because they can be fixed quickly, but what
scares me is possible cases where files did NOT conflict. Please be on
the look out for any missing Obsoletes that resulted in package or
We would really appreciate your help with "Everything" upgrade tests
from RH9 to FC2, and perhaps RH8 or RH7.x should be done too. I highly
suspect more conflicts or missing package removals are present in FC2.
Please do "Everything" installs, then attempt an upgrade with apt-get or
yum, then report any problems you encounter here.
Below is a list of packages that remained unchanged from FC1
"Everything" to FC2 apt-get dist-upgrade. Please read the instructions
at the top and comment here.
-----BEGIN PGP SIGNED MESSAGE-----
I don't know if it is happening with someone else but rhn-antool
informs about "phantom" upgrades (like perl-NET-dns)...
Up2date also crashes when network load is high or DNS fails (I guess
that it should present proper messages instead of a dump of python,
not everybody works in SW development). Other problem is that
sometimes (or, to be true, quite frequently) up2date gives an error
message when we try to run it after a crash (the best way of avoiding
it is clearing /var/spool/up2date or either /var/spool/up2date and
Besides screwing about USB CD-recorders (and other devices), kernel
2.6.5-1.327 also have problems with my modem. As soon as I debug it
better I'll tell you about what's going on.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Errr... long time listener, first time caller? I hate it when people
say that, but I'm not sure what else to say. ;-)
As per the self-introduction page at
http://www.fedora.us/wiki/SelfIntroduction, my info follows:
Full legal name: Chris McDonough
Country, City: US, Fredericksburg VA
- I'd like to be able to help with the Python bits (config
tools) as necessary.
- It would be nice to see Zope (http://www.zope.org) get into
- RH user since 5.1
- Core Zope developer (~ 5 years)
- Coauthor of Zope Book (http://www.zope.org)
- Languages: Python, dribs and drabs of C/C++ and Perl
- Why should we trust you: You shouldn't, but I suspect that won't
GPG KEYID and fingerprint:
pub 1024D/6F63C60E 2004-04-28 Chris McDonough <chrism(a)plope.com>
Key fingerprint = F5C0 6177 EB08 B9D3 0E0E 4176 2671 4C4F 6F63
sub 1024g/73525B01 2004-04-28
Anyhow, I'll just sit back and watch for a while to see how this list
works for now.