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
Running with vm.overcommit_memory=2
by Ralf Ertzinger
Hi.
After having firefox killed by the OOM-killer due to a totem running wild
(and watching the killer churn the disks for 5 minutes to do so, what the heck
is it doing?), I ventured to try a hard overcommit limit (which setting
vm.overcommit_memory=2 does, to the best of my knowledge). The system in
question has 640MB RAM, no swap.
The result is that almost nothing works, even with plenty of memory free.
It's even impossible to get a simple man page to display:
[sun@nausicaa ~/src/gmemusage-0.2 :) 23]$ free
total used free shared buffers cached
Mem: 645152 366636 278516 0 16900 106340
-/+ buffers/cache: 243396 401756
Swap: 0 0 0
[sun@nausicaa ~/src/gmemusage-0.2 :) 24]$ man sysctl
sh: fork: Cannot allocate memory
sh: fork: Cannot allocate memory
Error executing formatting or display command.
System command (cd /usr/share/man && (echo ".ll 11.8i"; echo ".pl 1100i"; /usr/bin/gunzip -c '/usr/share/man/man8/sysctl.8.gz'; echo ".\\\""; echo ".pl \n(nlu+10") | /usr/bin/gtbl | nroff --legacy ISO-8859-1 -man -rLL=129n -rLT=129n 2>/dev/null | /usr/bin/less -iRs) exited with status 32768.
No manual entry for sysctl
The system has nearly 400MB of free memory. What does it take to display
some lines of text these days?
--
"It's one of those irregular verbs: I explore the possibilities of
computing, you hack, he has been charged under section 2 of the computer
misuse act..." -- Richard Watts
18 years, 6 months
Package pruning for FC4 and beyond
by Eric Warnke
I said it and now I'm doing it.
I have started making a once over of the packages looking for
dead/obsolete/unecessary core packages in core-testing. I have gone
through .src.rpm's a*-e* and I have a breakdown of packages. These
packages appear to be things that can either move to extras or be dropped.
I am willing to pledge support for some of these packages if there is a
call for their continued existance in extras, but not all. I have a
feeling that some will drop completly out from lack of support.
Lines with a '+' mean that they are a dependancy that is a logical
remove as well. I have a small reason for each removal from core listed
next to each. 'D:0' = nothing depends on these packages.
Highly likley candidates
ElectricFence - Development only ( many similar ) D:0
SDL* - kdeaddons is the only thing that depends on this
+ kdeaddons - small add on packages for stock kde apps
*VFlib2 - only if we can break the ghostscript requireedby
+ MagicPoint - Duplicated functionality already in other packages
Xaw3d - required by emacs
+ emacs ( pick emacs or xemacs and move the other to extras )
a2ps - used by Xfprint ( XFce - already moved to extras )
awesfx - OLD Soundblaster awe 32 util ( 2000 ) D:0
bogl* - kernel 2.2 fb graphics lib D:0
cdecl - C/C++ to English conversion D:0
dasher - obscure alternate input method D:0 ! 10MB
dovecot - IMAP server ( duplication of effort )
epic - duplicate effort
lynx - duplicate effort ( elinks )
Possible candidates
Canna - Superceeded by IIMF - nothing depends ! 10MB
Guppi
apel - extras for emacs
+ ddskk - extra input methods for emacs
+ film - message encoding emacs
+ wl - imap/pop/nntp reader for emacs
arptables_jf - specialized filtering of arp D:0
ccs - cluster config?
cdlabelgen - does anyone use? D:0
cscope - c code browser - duplicate effort D:0
doxygen - Sorce code documentation generator D:0
autorun - functionality in most desktops already d:0
Cheers,
Eric
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken
18 years, 6 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
Intel Pro Wireless cards
by Eric Warnke
After reviewing the archives of the various lists I have found no
discussion on the topic of wireless driver inclusion in FC.
I have checked with LICENSE and FAQ for the intel driver and firmware
and was wondering if it could be included in core. Without those driver
it makes most centrino based laptops useless without special handling.
Specifically since I know people will ask, the problem must lie in the
firmware since the driver is GPL. The firmware is under a commercial
licence that allows redistribution as long as a small number of
conditions are met. Distributed by rpm and installed the only condition
that needs to be met is that the LICENCE file needs to be installed with
the firmware.
http://ipw2100.sourceforge.net/firmware.php?fid=1
"*Your rights to redistribute the Software shall be contingent upon your
installation of this Agreement in its entirety in the same directory as
the Software.*"
So, is this a non-starter, or can this be accomodated by FC? I know
this would be a bog help to the laptop users out there. At least if we
can get the driver support in core so that each kernel release does not
break laptop support I would be most grateful.
Cheers,
Eric
18 years, 6 months
reducing distribution CD count
by Gene C.
I have been following the various discussions of reducing the CD count and
have the following comments:
1. I agree with those who want to expand the FC4 set to 5 CD images and then
put the big reduction effort into the FC5 timeframe when anaconda can/should
be able to handle multiple "respositories" (and, homefully, pup also).
2. Lets say something major which a lot of users will want is move out of the
"core core" and into a secondary "repository" which will still be fully
maintained by Red Hat employees. No flaming intended, but lets say this is
kde and all kde associated applications. Now that would be a big chunk but
it would also be something a lot of users would want. What is the current
thinking about how this "secondary repository" will be available to the user?
Furthermore, this must be done in such a manner that it is obvious that Red
Hat is NOT slighting the packages involved.
3. Can someone point me to the mailing list where the discussions are being
held about this future multiple repository?
4. I am a little concerned about the discussion of multiple repositories and
getting the CD count does to below four. What I am reading into the
"multiple repository" discussions so far is that there would be a small
number of CD images but then the rest of the packages would be pulled in off
the Internet. While this should work in most cases, there does exist a need
to have stand-alone systems or small networks of systems which have no
connectivity to the Internet. Currently, with everything on CD or DVD
images, things work for these stand-alone systems. True, getting updates to
these systems is a bit more work requiring downloading, burning to DVD or CD
and then moving to the unconnected systems but it does work. If large pieces
of the "core" is only available via the Internet, then this can cause a great
deal of additional effort.
5. There was some mention of RHEL having "extra" packages which are not part
of the RHEL on CDs. How does RHEL handle the extra packages for stand-alone
systems?
6. Currently, I pick and choose a small number of extra packages from Fedora
Extras and other rpm repositories. If large number of packages which a lot
of individuals may want are moved into secondary repositories, how will
things be handled? Will there be CD and/or DVD images available of these
repositories?
7. Currently, I do everything installs of Fedora Core for many installations
simply because it is easier than adding a lot of stuff manually ... even if
this does include a lot of packages that I have no need to install ... it is
just simpler to include them. However, doing "everything everything"
installs which would include packages from a Core, Extended Core, Extras, and
other repositories, does not sound like it would work. There must be a
better way.
My view of how installation should work is that the basic installation should
be just that ... basic. Then, during firstboot (and available at later times
too), you run something like pup (I hope this is the intent) to add
additional packages and groupings of packages ... this does need to have the
ability to select package installation/removal on an individual package
basis. Large groupings of packages (e.g., KDE) should be available as CD or
DVD images.
Comments?
--
Gene
18 years, 7 months
Why is sendmail bad?
by Kenneth Porter
There seems to be a lot of dissatisfaction with sendmail in the call to
replace it with Exim or Postfix, but I didn't see any specifics about why
people object to it. Anyone care to give details?
I'm using sendmail together with MIMEDefang to run SpamAssassin and ClamAV
against messages during the SMTP transaction so that I can reject obvious
spam and viruses before they're committed to a queue. MIMEDefang uses a
user-edited Perl script to establish the exact rules for acceptance, making
the system very flexible. How hard is that to set up in Postfix or Exim?
18 years, 7 months
