text: 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 know that this question might be more reasonable on a kernel list,
  but a while back I posted the question twice and got no answers.)
  The acct struct is defined in /usr/include/sys/acct.h includes both
  ac_io and ac_rw for bytes transferred and blocks read or written,
  respectively. Fair and good - works (on paper) similarly to unix,
  solaris, hp-ux, etc.
  However, in the kernel code [kernel/acct.c], ac_io (char) and ac_rw
  (blocks) are always set to 0 by these two lines:
  ac.ac_io = encode_comp_t(0 /* current->io_usage */);
  ac.ac_rw = encode_comp_t(ac.ac_io / 1024);
  For most purposes, this probably wouldn't be an issue, but I also do
  extensive performance analysis on several platforms and have written a
  fairly compresive accounting package (as a wraparound for psacct or as
  a standalone) including both an improved acctcom and a built-in
  reporter for it.
  Does anyone know wby the kernel zero's out the bytes transferred data?
  (Overhead comes to mind.) Not that it makes a huge differnce for my
  purposes (I had to write some wraparound code to make a
  "best-guestimate" about the data I'm missing), but curiosity is bugging
  me now. When I compile my program on other OS's I get useful data for
  char and block i/o and I'd like to find out whether there is something
  obvious that I'm just totally missing here...).
  william w. austin waustin(a)speakeasy.net
  "life is just another phase i'm going through. this time, anyway ..."
  I put firefox-trunk SRPM based on current fedora rawhide one at
  Notice: this package breaks the dependency against devhelp and yelp.
  Janina Sajka <janina(a)rednote.net> wrote:
  > Does anyone know of any rpm builds of Firefox 3? I'm aware it's nowhere
  > near ready for prime time, but I have a compelling reason to start using
  > ff3 fairly soon and would rather install from rpm, of course.
  > BTW: My compelling reason is that FF3 will contain a11y support that
  > should prove superior to any yet seen on any platform. Fingers crossed,
  > etc ...
  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 just checked my laptop which is a core2duo with 1 gig of ram. WinXP
  reports PAE but fc6 installed non-PAE kernel. Would the PAE kernel be
  better for me or should I stick with the non-PAE? Obviously I don't need
  highmem support, will that be to much of a performance hit?
  model name : Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz
  flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca
  cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm
  constant_tsc pni monitor ds_cpl est tm2 cx16 xtpr lahf_lm
  I've built a set of FC6 ia64 ISOs (CD set and DVD) which are available
  for download from
  (Click on Download on left-hand side, and then the FC6 directory)
  These are labelled as FC6GOLD to differentiate them from the broken sets
  that Yanmin attempted to release last week. md5sums are provided.
  We have verified CD, DVD, NFS, http, ftp installs on various HP & SGI boxes.
  Please remember that FC6 ia64 is _unsupported_ by Fedora. You can file
  bugs, but be sure to file them against the devel branch of Fedora Core.
  Also, add "fedora-ia64" to the "blocks" field of the BZ.
  I have updated 3 boxes from FC5->FC6 (x86_64) using anaconda (booted
  from a DVD).
  All three of them is nothing that can be called a slow machine:
  AMD64 3000+ @ 4100+ (2.61ghz)
  7200 RPM 2MB Cache IDE Seagate HDD 120GB
  Core 2 Duo T7400 2x2.17Ghz 4MB shared L3 Cache
  7200 RPM 8MB Cache SATA Hitatchi HDD 80GB
  AMD Opteron 170 @ 2x2.7Ghz
  2x120GB Hitatchi SATAII HDD 8MB Cache MD RAID0
  Update time was ~90-120min depending on the sys.
  Why does the update take that long? A reinstall is much faster..
  I think that improving this should be a goal for FC7
  Also why isn't it possible to install from a md raid partition? Should I
  fill a RFE?
  Are we still planning to completely replace termcap with
  ncurses in Fedora?
  While I welcome reducing the number of dupe packages, I'm
  worried by the impact of this change on the size and
  performance of many core programs.
  libncurses is much bigger than libtermcap, and also has
  oddly large .bss and .data sections:
  bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2
  text data bss dec hex filename
  319006 56608 3592 379206 5c946 /lib64/libncurses.so.5
  10483 788 112 11383 2c77 /lib64/libtermcap.so.2
  this is going to impact very negatively on the RSS of several
  critical programs such as bash and python.
  I'm also worried that the overall time required spent for a
  fork may increase considerably.
  But maybe ncurses can easily be fixed to avoid global data and
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
  Okay its come to my attention that the readahead configs have a
  difficult time being kept in sync as package updates roll out. For fc6
  right now for example readahead is out of sync with firefox libraries.
  Can we update readahead's implementation so we can get per package
  control of the default configs? Is a readahead.d/ structure
  I want to point out that we lose significant value with read-ahead if
  we can't ensure that the listings will be in-sync as package updates
  are issued. And re-spinning readahead updates periodically to attempt
  to sync a centralized config file is horrible inefficient and may
  never be perfectly in-sync considering the churn of updates during a
  We've recently started working on a project called Linux Hardware
  Project or in short LHCP. Goals are:
  * Provide a list of working hardware for people wanting to buy a new
  * Provide an idea on what hardware our/your distribution in run on
  * Provide a list of hardware we need to improve support for
  * Provide an interface to all above that allows simple and complicated
  * Get the user a list of thing that should work and a way to test that
  * Tell the user how good his hardware is supported
  There have been several Hardware Compatibility lists from vendors and
  other projects in the past, but most of them were limited in one
  aspect or another - so we start our own.
  To achive this we are building a modular framework to generate, collect,
  and analyze information about all components of systems running Linux
  and how well each component works.
  The project is currently in it's infancy, but following the typical
  approach of open source projects ("Release early, release often!") we've
  decided to already officially announce it.
  Current status is that the basic GUI application for testing is up and
  with some test modules. We're now in the process of writing the first real
  data collection and test modules and are currently starting to design the
  server end of the side.
  The home page of the project can be found here:
  If you want to take a look at the current source code you can checked it out
  using Mercurial in read only mode like this:
  hg clone http://hg.fedoraproject.org/hg/hosted/LHCP
  For development discussions a mailing list has been set up here:
  Although the project is hosted under Fedora we're aiming it to be very
  distribution independant, so supporting other distributions should be
  do. We have some basic requirements on what is needed on the system for
  simply work, but a lot of things will be optional.
  Read ya, Phil & Fabi
  Philipp Knirsch | Tel.: +49-711-96437-470
  Development | Fax.: +49-711-96437-111
  Red Hat GmbH | Email: Phil Knirsch <phil(a)redhat.de>
  Hauptstaetterstr. 58 | Web: http://www.redhat.de/
  Motd: You're only jealous cos the little penguins are talking to me.