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, 4 months
kernel/accounting question ...
by William W. Austin
(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...).
Thanks
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 5 months
acctcom for linux
by William W. Austin
I recently made several updates to a Linux version of of acctcom
(actually another accounting add-on package) which I've been using for
several years, and one of the people testing it asked a question which
I cannot answer. I'm hoping that someone on this list can give me some
info.
I have previously (over a year ago) asked on both this and a couple of
kernel lists (several times there) about this issue, but nobody has
ever answered. So if you have any info about this, I'd really
appreciate it.
As in many (all?) previous Linux kernels, the struct acct (defined in
/usr/include/sys/acct.h) has members ac_io and ac_rw which are
presumably counts of characters transferred and blocks read/written
respectively.
However, in the kernel code, the ac_io is set to 0 and the ac_rw gets
set to (ac_io/512) or some such - it is set to 0 as well (and thus
these are always reported as 0 in process accounting records. not good
if you're trying to measure them...).
Does anybody know why this is done that way? A long time ago (IIRC
late 2.2 and an early 2.4 kernel) I looked into "fixing" this in the
kernel code but was not successful (I finally produced a bootable
kernel, but it was unstable. Then I changed jobs, got swamped at work,
and eventually gave up).
As I said above, I have previously asked about this issue without
success, and I have essentially given up changing or "fixing" it.
But if anyone knows __WHY__ it is this way (I'm hypothesizing that it's
just too much work for too little added value), I'd really appreciate
knowing the reason. Curiosity and the cat and all that ...
Thanks
- Bill
--
william w. austin waustin(a)speakeasy.net
"life is just another phase i'm going through. this time, anyway ..."
13 years, 5 months
Any way to search all .spec files?
by Orion Poplawski
Is there any was to do a grep/search on all of the Fedora .spec files
for a specific release (or devel)? I'd be fine with checking them all
out if there was a way to just the the spec files for a specific release.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 2 months
Re: Firefox 3
by Takanori MATSUURA
Hi all,
I put firefox-trunk SRPM based on current fedora rawhide one at
http://homepage2.nifty.com/t-matsuu/install-memo/fc/
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 ...
MATSUURA Takanori
15 years, 6 months
Self-Introduction: Denis Ovsienko and /etc/net project
by Denis Ovsienko
Denis Ovsienko
Russia, Moscow
Linux system administrator and developer
ValueCommerce/Russia
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
--
DO4-UANIC
15 years, 7 months
koji weirdness
by Hans de Goede
Hi all,
I'm working on updating libgda + libgnomedb to 3.0.x for F-8 / future rawhide
(more on that later) and yesterday evening before going to bed I queued a build
of libgda-3.0.1, which completed successfully. This morning I build
libgnomedb-3.0.0, which correctly got its buildroot populated with the fresh
libgda-3.0.0 . So next I tried to build gnumeric against the new libgda +
libgnomedb, but populating the root failed with:
Executing /usr/sbin/mock-helper yum --installroot
/var/lib/mock/dist-f8-build-5517-1020/root resolvedep 'intltool' 'pygtk2-devel
>= 2.6.0' 'libgnomeprintui22-devel >= 2.8.2' 'libgnomedb-devel >= 3.0.0'
'python-devel' 'scrollkeeper' 'gettext' 'automake' 'desktop-file-utils >= 0.9'
'libgnomeui-devel >= 2.4.0' 'libgsf-gnome-devel >= 1.13.2' 'goffice-devel >=
0.2.0' 'libtool' 'autoconf' 'guile-devel'
0:intltool-0.35.5-3.fc7.x86_64
0:pygtk2-devel-2.10.4-2.fc7.x86_64
0:libgnomeprintui22-devel-2.18.0-1.fc7.x86_64
1:libgnomedb-devel-1.9.100-15.fc7.x86_64
0:python-devel-2.5-12.fc7.x86_64
0:scrollkeeper-0.3.14-11.fc7.x86_64
0:gettext-0.16.1-8.fc7.x86_64
0:automake-1.10-5.noarch
0:desktop-file-utils-0.12-4.fc7.x86_64
0:libgnomeui-devel-2.18.1-2.fc7.x86_64
0:libgsf-gnome-devel-1.14.3-4.fc7.x86_64
0:goffice-devel-0.2.2-1.fc7.x86_64
0:libtool-1.5.22-11.fc7.x86_64
0:autoconf-2.61-8.fc7.noarch
5:guile-devel-1.8.1-3.fc7.x86_64
Notice how it says its going to include libgnomedb-devel-1.9.100, not 3.0.0
and then:
Error: Missing Dependency: libgda-3.so.3()(64bit) is needed by package libgnomedb
Which figures, as that is the old 1.9.100 libgda .so
For the full log see:
http://koji.fedoraproject.org/koji/getfile?taskID=18756&name=root.log
So why is koji finding the new libgda, but not the new libgnomedb, is some
kinda sync script running for this at regular intervals, or ... ?
Regards,
Hans
15 years, 11 months
Massive size increases in certain packages
by Orion Poplawski
I just got a bug report on python-numarray
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240289) indicating
that the size of the installed package has increased from around 6.7MB
in FC6 (1.5.2-1.fc6) to around 56MB currently (1.5.2-2.fc7). Now, the
only this that was done was to rebuild the package for python 2.5 back
in December.
If I rebuild the package now the size is back to "normal". The
differences are in the size of the shared libraries:
< 1272 /usr/lib/python2.5/site-packages/numarray/_bytes.so
< 1264 /usr/lib/python2.5/site-packages/numarray/_chararray.so
< 1308 /usr/lib/python2.5/site-packages/numarray/_conv.so
< 1268 /usr/lib/python2.5/site-packages/numarray/_converter.so
< 1280 /usr/lib/python2.5/site-packages/numarray/_ndarray.so
< 1280 /usr/lib/python2.5/site-packages/numarray/_numarray.so
< 1260 /usr/lib/python2.5/site-packages/numarray/_numerictype.so
< 1264 /usr/lib/python2.5/site-packages/numarray/_objectarray.so
< 1260 /usr/lib/python2.5/site-packages/numarray/_operator.so
< 1376 /usr/lib/python2.5/site-packages/numarray/_sort.so
< 1292 /usr/lib/python2.5/site-packages/numarray/_ufunc.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so
< 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so
< 1312 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so
< 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so
< 1308 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so
< 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so
< 1324 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so
< 1320 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so
---
> 28 /usr/lib/python2.5/site-packages/numarray/_bytes.so
> 20 /usr/lib/python2.5/site-packages/numarray/_chararray.so
> 72 /usr/lib/python2.5/site-packages/numarray/_conv.so
> 20 /usr/lib/python2.5/site-packages/numarray/_converter.so
> 36 /usr/lib/python2.5/site-packages/numarray/_ndarray.so
> 36 /usr/lib/python2.5/site-packages/numarray/_numarray.so
> 12 /usr/lib/python2.5/site-packages/numarray/_numerictype.so
> 16 /usr/lib/python2.5/site-packages/numarray/_objectarray.so
> 16 /usr/lib/python2.5/site-packages/numarray/_operator.so
> 136 /usr/lib/python2.5/site-packages/numarray/_sort.so
> 48 /usr/lib/python2.5/site-packages/numarray/_ufunc.so
> 80 /usr/lib/python2.5/site-packages/numarray/_ufuncBool.so
> 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex32.so
> 72 /usr/lib/python2.5/site-packages/numarray/_ufuncComplex64.so
> 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat32.so
> 72 /usr/lib/python2.5/site-packages/numarray/_ufuncFloat64.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt16.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt32.so
> 80 /usr/lib/python2.5/site-packages/numarray/_ufuncInt64.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncInt8.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt16.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt32.so
> 84 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt64.so
> 76 /usr/lib/python2.5/site-packages/numarray/_ufuncUInt8.so
and so on.
I did a quick compare of FE 6 to the last FE devel and found that the
following packages have increased in size by more than a factor of 2.
Some of these may be fine, I haven't looked into it in detail.
What's up?
banshee 2536364 -> 6770157
cppunit-doc 4504311 -> 10063237
duplicity 936214 -> 2255520
fwbackups 347859 -> 894038
graphviz-tcl 298038 -> 2020760
libburn-devel 47334 -> 944521
libcaca-devel 507545 -> 1482955
libhugetlbfs 97382 -> 206633
libhugetlbfs-test 1031501 -> 135632714
libpreludedb-python 91466 -> 1355682
linux-libertine-fonts 2589874 -> 10225720
mercurial 2063651 -> 6487353
nsd 446095 -> 1665847
ogre 6374746 -> 29476134
openbabel-perl 1206495 -> 3376667
openbabel-python 1501764 -> 3509293
ortp-devel 197141 -> 3761868
php-pear-PHPUnit 126756 -> 1106041
plplot-wxGTK 54287 -> 144831
pybluez 341942 -> 1617662
pyflowtools 35170 -> 1302402
pyfribidi 27095 -> 1299303
pygpgme 79943 -> 1349853
python-CDDB 55383 -> 1324169
python-GeoIP 30419 -> 1299395
python-adns 60844 -> 1327860
python-alsaaudio 28238 -> 1297182
python-chm 121632 -> 2670312
python-durus 419912 -> 1718919
python-numarray 6771218 -> 56416870
python-protocols 766774 -> 2075564
python-pycurl 212612 -> 1485863
python-quixote 1853963 -> 7008959
python-ruledispatch 933214 -> 2272446
python-smbpasswd 34293 -> 1302773
python-twisted-runner 74839 -> 1349825
python-zope-interface 1013800 -> 2358938
pyxmms 327987 -> 2871939
rdiff-backup 1286381 -> 3896666
supertux 15057058 -> 49666684
wallpapoz 110963 -> 363890
xpa 945338 -> 1979801
zvbi-fonts 43808 -> 132817
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
15 years, 11 months
