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
2 years, 3 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, 7 months
dbus-qt
by Frederick Alexander Thomssen
hi,
once dbus-qt was removed from fedora because there was no use for it. but now
kde 3.4 supports dbus-qt for the media:/ protocol which indicated if a new
device was connected. so there now is a use for dbus-qt so i think it ought
to be included.
freddy
--
Frederick Alexander Thomssen
18 years, 8 months
Printing system proposal
by Remco Poelstra
Hi,
It's very quiet on this list about printing, so I thought it would be a
nice idea to put forward a proposal. I don't know if there are internal
redhat discussions about this subject, but I think I'll find out soon :).
It's a rahter lengthy explanation with a diagram so I put it up here:
www.beryllium.net/~remco/printingproposal.html
Kind regards,
Remco Poelstra
18 years, 8 months
Fedora 4 XEN and Kernel 2.4xenU
by Roland Käser
Hello
I'm currently testing xen for internal failover usage.
I would like to ask if there is a package with the kernel-2.4.2xenU
available on fedora 4 and if its possible to run kernel-2.4xenU kernels
on a kernel 2.6 dom0 system?
Roland Kaeser
19 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/ *
***************************************************************
19 years
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
19 years
FC4 perl module upgrades/cleanups
by Warren Togami
Right now I'm looking at cleaning up and upgrading all perl modules in
FC4. The specs of many of the perl modules have ancient crap that
should be cleaned up and modernized. Among the stuff I want to do:
https://www.redhat.com/archives/fedora-packaging/2005-March/msg00095.html
https://www.redhat.com/archives/fedora-packaging/2005-March/msg00096.html
https://www.redhat.com/archives/fedora-packaging/2005-March/msg00097.html
* Remove brp-compress calls from all packages, as it isn't doing
anything useful. (Right?)
* Update URL and Source0 to actual modern CPAN addresses.
* Clear out most of the trival to minor perl-* FC bugs, which are mainly
"upgrade this" and "fix the spec".
* Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
Do we want this in all perl packages, both regular arch and noarch?
* %define _use_internal_dependency_generator 0
Many of the ancient specs have this. Might be nice to get rid of it,
but it will require some careful verification comparing the before and
after in order to be sure the rpm-auto-dep isn't demanding bad
dependencies like Win32 crap. Is this worth doing? Need your opinions.
* Identify all modules that have a newer version available in CPAN.
Would be nice if we had a script to compare a devel CVS checkout to CPAN
and output a list with URLs or something.
Contributors like Ville, Robert and Jose have been very helpful in
submitting good spec rewrites for perl packages in the past. So I hope
the community can help with cleaned up spec unidiffs (along with version
upgrades) to be submitted to Bugzilla, one report per package. Perhaps
discuss here who will do which package. I'll do some myself.
Thoughts?
Warren Togami
wtogami(a)redhat.com
19 years
Stateless linux
by gaurav
Hi list,
I am interested in stateless Linux project and would like to
volunteer for its beta tester ... I will try roll this out in my brother's
school and after that co workers on my office plus also would like to
contribute to its development ....help it to take to next level :-)
I would like to know what state this project is in ? is anybody involved
in active testing/ testing development ? Do you need beta tester ...
all like minded (stateless people ;-) ) pl let me know if interested
Regards,
gaurav
19 years
kernel source code
by not disclosed
Dear All,
RE: In order to eliminate the redundancy inherent in providing a separate
package for the kernel source code when that source code already exists in
the kernel's .src.rpm file, Fedora Core 3 no longer includes the
kernel-source package. -
http://fedora.redhat.com/docs/release-notes/fc3/x86/
I think this is a big mistake - kernel-source didn't harm anyone and
removing it hugely increases the amount of hassle involved in any kernel
upgrade. You have to accept that fedora users will be using stuff that lies
outside the fedora world of nicely packaged programs and this means that
users need the source code. The hassle involved with this elimination of
the kernel source code package is irritating enough for us to consider using
another distro when we come to change from FC2.
Please put the kernel sourcecode back.
Cheers,
SA
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
19 years
