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
Linux system administrator and developer
I develop /etc/net project (http://etcnet.org) and my goal is to integrate it
into Fedora Core.
I am a member of ALTLinux Team. /etc/net is already integrated into ALTLinux
development tree and should soon be seen in 3.0 version.
I know that ArchLinux has /etc/net in its repository. IDMS Linux did so too,
but i haven't heard from them for last months.
My skills include 6 years Linux experience, several programming
languages, 5 years of mixed software development and system/network
administration and so on, but I guess it's not related much to my goal now.
I have reviewed current initscripts buglist.
Some bugs are not bugs in /etc/net:
#65114 RFE: ifup-aliases iproute support, ifup/ifup-aliases scop...
#75390 it would be nice to tie bandwidth shaping into the networ...
#129820 initscripts maclist patch
#132252 Request for addition of routing rule config file
#132912 No additional IP addresses at ethX without aliased devices
#132925 initscripts use old ifconfig instead of iproute2
#154348 Adds support for WPA (Wi-Fi Protected Access) to the ifup...
#168990 No ifup-gre/ifdown-gre scripts.
#170884 MTU of ethernet card can't be set before interface is up
#171763 Enhancement to initscripts
Some bugs gave me ideas how to improve /etc/net:
#59114 .d-style scripts for ifup/ifdown
#119952 RFE: Add hook for "local" network initialization
#124045 Support setting a metric on interface routes
The whole process, if we don't face some unexpected problems, should take
3 to 6 months. What I need:
1. Ability to advocate patches (sometimes heavy) to about 10-20 FC packages.
2. Probably some help with documentation.
How can we start?
pub 1024D/6D1844F2 2002-11-11
Key fingerprint = AF2F DDAE 7EB3 4699 09FF F0FC 00B1 6D41 6D18 44F2
uid Denis Ovsienko <linux(a)pilot.org.ua>
uid Denis Ovsienko (http://pilot.org.ua) <pilot(a)altlinux.ru>
sub 2048g/57B7ACBE 2002-11-11
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 saw zeroconf in action at a Mac based facility a while back and I have
to say I was impressed. It makes their networking setup very easy. The
biggest downside was that they knew very little about how their network
actually worked. That made my life integrating a Linux system in to
their environment much more difficult. So, I'd like to see zeroconf
really integrated in to FC5. I think it'll make network setup for a lot
of users much easier.
For those who don't know, zeroconf provides several functions:
*) Dynamically allocating an IP address to a system when it boots
(without requiring a DHCP server)
*) Translate between names and IP addresses (without any setup or
*) Allows for the publishing and discovery of services such as DNS,
NFS, ftp, http, printers, whatever (without requiring any setup or
*) Allocates multicast addresses (without a MADCAP server). (This part
isn't yet supported and I'm not sure I know what it means :))
Fedora ships with Howl which looks to be the framework for doing
zeroconf. It seems that what's needed is integrating howl in to all the
When I find a bug in fedora and it's obviously a bug upstream I report
it there. But do we have to report them in fedora bugzilla too and
reference the upstream bugreport? So if an other users files a bugreport
for the same bug and doesn't check upstream maintainer of the module
know it's already filed upstream. Or do we have to notify the maintainer
in other way?
I've searched the fedora wiki for this but I can't find any information
Bart Vanbrabant <bart.vanbrabant(a)zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
Hi folks -
There doesn't seem to be a place to talk about the RH OLPC project yet.
I mailed the olpc(a)redhat.com address last week but didn't hear anything
yet. It seems that Fedora and the OLPC development effort would have a
lot in common. I wanted to make some suggestions which are a little
radical but hopefully can make some interesting discussion before things
are set in stone.
My core starting assumption is that the box cannot be made for the price
suggested and that triage will be needed. Therefore the software must
get ahead of the game by assuming a weaker processor and half the flash.
Please understand though that these are just suggestions for thinking
about, not demands, complaints, etc.
Seems hard to believe that with such a low price point, AMD will deliver
optimal pricing and that the target CPU throughput is not excessive with
x86. Isn't it better for the longer term to only weakly couple the
concept of the cheap laptop to a processor arch? Isn't it better if
it's more of a virtual specification that, say, random Chinese companies
can compete with each other to provide at the lowest possible price,
without encumbered CPU designs even like Arm? It's great to tout it
around Large American Corporations, but it would be a big win if the
final specification was buildable by anyone.
- AMD x86 -> OpenRISC 1200 (Has working GNU toolchain)
- ??? expensive patented video --> Opencores VGA/LCD controller
- Sound -> Cheap SPI codec, eg,
http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html or AC97
interface to external mixer
- Linux 2.6 with hardware-optimized .config
- glibc -> uclibc http://www.uclibc.org/ or newlib
- coreutils + bash + a ton of other stuff -> busybox http://www.busybox.net
- ssh -> dropbear (http://matt.ucc.asn.au/dropbear/dropbear.html )
- apache -> lighttpd (http://lighttpd.net )
- firefox -> Opera? Used in Nokia 770... thought it was OSS now but
couldn't find link on site.
- various media players / codecs -> Ogg Vorbis + Theora only
What will the new modular X do faced with linking to something other
than glibc? What about Gnome?
- Although I am a KDE man, Gnome really impressed me for the first time
on the Nokia 770. The KISS vibe actually worked in that context. The
770 would be a good model for what's needed generally in fact
- Ext3 root filesystem -> JFFS2 NAND root filesystem
- Grub -> u-boot (http://sourceforge.net/cvs/?group_id=65938 ) .. can
pull a bzImage out of JFFS2 directly in <100K
Well I'm sure these ideas and more are already floating around, it would
be cool if these can be dual-purposed into a uber lightweight "Fedora
Beanie" version. Ultimately a lot of package specfiles will have to
have the configure options revisited anyway...
First of all, thanks for helping me find the kernel sources. I did find
Now, I have another interesting problem.
I am trying to compile the alsa driver from alsa 1.0.11rc4 and I am
having lots of compiler errors.
I have done some tracing and I have seemed to come to a conclusion that
there are some kernel 2.6.16 features (such as structures) in FC5's
yet that kernel is 2.6.15**. This is breaking some conditionals in the
source code where it is looking for kernel version 2.6.15 or earlier.
Are any of you aware of changes that have been put into the 2.6.15
that FC5 has that are actually from the 2.6.16 stock kernel?
For that matter, have any of you been able to successfully compile the
version 1.0.11rc4 driver under the FC5 kernel?
On Tue, Mar 28, 2006 at 12:30:43PM -0500, sean wrote:
> gconf isn't limited because of its file format. It's limited because
> it's tied so closely to the Gnome WM. Really, once you have a standard
Gconf doesn't need gnome. The reverse is true however. The XML format also lets
you work with prefences using styles and XML XSLT and the like which is very
powerful when working with a large number of systems. Really nobody has
scratched the surface of what it can do.
You don't have to care about the XML either, one of the crazier gconf demos
from a long time ago was an email interface to gconf settings