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
autoconf breakage on x86_64.
by Sam Varshavchik
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:
LIBS="-lresolv $LIBS"
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
`res_query'
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 ();
| int
| 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?
17 years
DMRaid in Fedora devel
by Mark Wormgoor
Hi,
Attached are three patches that I made to get Fedora-devel to install on
a bios sata raid-0 system (Sil 3112 on Abit AN7). It uses Heinz
Mauelshagen's dmraid for detecting the disks.
The first patch is against Anaconda. It removes the raid disks from the
isys disklist and replaces them with the mapper device. The patch
requires the full (not enable-mini) dmraid binary in the stage 2 image.
I tested the patched Anaconda in install, upgrade and rescue mode (text
and gui) and had no problems on my system.
The second patch is against mkinitrd. It adds /sbin/dmraid.static to
the initrd if necessary and updates the initscript. The
/sbin/dmraid.static binary is not yet a part of the current dmraid rpm,
so you need to provide your own.
The third patch is against rc.sysinit so that dmraid.static is run at
boot. Again, you need the full dmraid binary under /sbin/dmraid.static
(not enable-mini) because the rc.sysinit script uses the testmode first
before enabling the mapper devices.
I now have a Fedora-devel system booting from my two raid-0 disks.
Unfortunately, there is no bootloader for /dev/mapper devices. There is
a patch against lilo to make it work on devmapper devices here
(http://www.saout.de/misc/) and Eric Agsjö has a patch to make it work
with raid-1 devices here
(https://www.redhat.com/archives/ataraid-list/2004-October/msg00007.html). I am still using lilo under FC1 (using the medley.o module) and that works for me.
I hope someone finds these patches useful; it would be very nice if FC4
would install on and boot from these bios ide raid devices without too
much hacking.
Kind regards,
Mark Wormgoor
--
***************************************************************
* |\ /| | /| / Mark Wormgoor *
* | \ / | | / | / mailto:mark@wormgoor.com *
* | \/ |ark |/ |/ormgoor http://www.wormgoor.com/mark/ *
***************************************************************
18 years, 5 months
Emacs cvs snapshot packages available
by Jens-Ulrik Petersen
I finally got round to packaging a snapshot of current
development Emacs from CVS. Noone knows when the next
actual release of Emacs will be, but there are many
new features and changes: improved utf-8
and gtk2 support in particular.
See
http://people.redhat.com/petersen/emacs/
for more details.
Enjoy and please report any problems directly to me
(ie not to bugzilla or the emacs-devel list:),
Jens
18 years, 5 months
Proposal: swap epic for irssi
by Colin Charles
Hi,
For FC-4, what would folk think about removing epic and replacing it
with irssi in Core?
irssi currently sits in Extras, and we could very likely just move epic
to Extras after the swap.
Thoughts?
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
18 years, 6 months
binary rpm package checking
by Florian La Roche
This is a start to check binary rpm packages for consistency.
Right now mostly the rpm header is checked to get a feeling
how much "strange" binary rpm packages might be out there.
It has two modes of checking, one for the current Fedora Development
tree with more strict checks and a more relaxed one that should
work for all existing rpm packages, also other distributions.
I'd be interested to get feedback on what output is generated
for rpm addon expositories and non - Red Hat distributions
if the script generates warning messages.
At least for Fedora Core only very few rpm tags are actually
used in the rpm header.
Examples usage:
./pyrpm.py --strict /mirror/fedora/development/i386/Fedora/RPMS/*.rpm
Checking all rpms:
locate .rpm | xargs ./pyrpm.py
find /mirror/linux -name "*.rpm" -type f -print0 2>/dev/null |
xargs -0 ./pyrpm.py
greetings,
Florian La Roche
18 years, 7 months
fedora stable branch updates Q&A policy
by Kyrre Ness Sjobak
What is this policy today? Who does the testing before an update is
released for large numbers of users to install via yum?
I am wondering, not because there are very many bad updates (99% of them
are OK), but i simply wonder - who does this? And who does this for
extras?
Personally, i would believe a q&a mailinglist and a "testing" repo for
yum could be a good idea, in order to get packages as good tested as
possible - as fast as possible.
Kyrre
18 years, 7 months
redhat abe
by Christof Damian
I just read about RedHat ABE (Application Build Environment) which
seems to be something similar to mach.
Will this be available or work on fedora? Has anyone tried it ?
I found some info here: http://people.redhat.com/mwaite/
Christof
--
Christof Damian
christof(a)damian.net
18 years, 7 months
radical suggestion for fc4 release
by seth vidal
Hi folks,
this is a touch silly but possibly useful and it would definitely cut
down on the old crap blocking up cdroms.
how about if we kill all rpm spec file changelog entries OLDER than 2
years.
they'll still live on in older srpms and rpms but it'd be a useful
reduction and it would make the specfiles that much smaller, along with
the rpm headers.
thoughts?
-sv
18 years, 7 months
