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
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, 9 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, 11 months
anaconda update time needs to be improved
by dragoran
Hello
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:
1)
AMD64 3000+ @ 4100+ (2.61ghz)
1024MB RAM
7200 RPM 2MB Cache IDE Seagate HDD 120GB
2) Laptop:
Core 2 Duo T7400 2x2.17Ghz 4MB shared L3 Cache
2048MB RAM
7200 RPM 8MB Cache SATA Hitatchi HDD 80GB
3)
AMD Opteron 170 @ 2x2.7Ghz
2048MB RAM
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?
16 years, 7 months
[offtopic] Ignacio Vazquez-Abrams
by Arthur Pemberton
Hi guys,
I apologize ahead of time for the offtopic nature of this thread, and
if desired, I will cease any continuation. Threads over on
fedora-extras-list have brought my attention to the e-dissappearance
of one "Ignacio Vazquez-Abrams".
This guy has helped me out many times over of #fedora, and was always
online, despite me changing time zone twice - to the point where I
asked if he was a bot. He seemed to have also had a large load in
package maintaince. Fedora being partly about the community, I have to
ask: does anyone know what happened to this guy? His online presence
seems to have simply ceased as of May-2006. I searched Gmail for
emails from him, the last was in May. His blog
(http://www.ivazquez.net) seems also to have gone quiet as of May.
Just felt that the guy has helped me enough to at least care if he
suddenly died or something.
Peace.
--
To be updated...
16 years, 8 months
Move Evolution to Extras?
by David Woodhouse
Evolution is fairly much broken in FC5, and there's little movement even
on the 'this mail crashes Evolution' bugs, let alone the "Evolution is
totally unusable with IMAP" bugs.
What are we going to do about it? One option might be to move it to
Extras in the hope that someone will actually start to look after it
there. Or perhaps just drop it entirely? Any better ideas? Volunteers?
--
dwmw2
16 years, 8 months
ifup-ipsec: Manual v. Automatic keying
by Bojan Smojver
Disclaimer: I know bugger-all about IPSec.
I looked through this script in devel and it appears that it does
something like this (among other things) when using setkey -c:
------------------------------
spdadd $SPD_SRC $SPD_DST any -P out ipsec
${SPD_ESP_OUT:+esp/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
${SPD_AH_OUT:+ah/$MODE/${TUNNEL_MODE:+$SRC-$DST}/require}
;
spdadd $SPD_DST $SPD_SRC any -P in ipsec
${SPD_ESP_IN:+esp/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
${SPD_AH_IN:+ah/$MODE/${TUNNEL_MODE:+$DST-$SRC}/require}
;
------------------------------
The HOWTOs (located here:
http://lartc.org/howto/lartc.ipsec.automatic.keying.html and here:
http://www.ipsec-howto.org/x299.html) mention only the ESP bit in
relation to automatic keying, but not the AH bit. From the HOWTOs:
------------------------------
#!/sbin/setkey -f
flush;
spdflush;
spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
esp/transport//require;
spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
esp/transport//require;
------------------------------
------------------------------
#!/usr/sbin/setkey -f
#
# Flush SAD and SPD
flush;
spdflush;
# Create policies for racoon
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
esp/tunnel/192.168.1.100-192.168.2.100/require;
spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
esp/tunnel/192.168.2.100-192.168.1.100/require;
------------------------------
FC5, that I'm using for my IPSec to PIX connection, is similar to devel
(i.e. it has the AH bits in spdadd). Anyone on the list knows why the
discrepancy?
The HOWTO method lets me establish a tunnel to PIX. The one from the
script does not...
--
Bojan
16 years, 10 months
Driver disks for FC6
by Gregory Maxwell
Is there a driver disk for FC6 example anywhere?
The driver disk layout changed a few revisions ago and I had a lot of
trouble building one for FC5. Now that FC6 has come around I'd like
to avoid pulling my hair out again.
I need to make a disk for the Arcea driver, arcmsr, which has finally
gone into the upstream kernel (as of 2.6.19-pre1). Hopefully FC6 will
upgrade to a kernel containing this driver soon, but to get it
installed, I'll need to make a disk. It looks like compiling the
driver outside of the tree against the kernel in FC6 shouldn't be
hard... but I'm worried about figuring out the driver disk layout all
over again. ... (well that and finding a working floppy disk drive..
ugh)
16 years, 10 months
State of multilib development update
by Hans de Goede
Hi all,
Some time ago I send the message below, I've now filed bugs left and
right and I'm posting this again with the BZ url's for those interested.
---
Yesterday I tried to build i386 rpms on my x86_64 using the new
multilib-devel packages instead of resorting to an i386 chroot.
Although we have come a long way to making this possible there are still
a few issues which makes doing this very hard:
1) gcc ignores setarch
======================
"gcc -o hello helloworld.c", creates an x86_64 elf file on my x86_64
system as expected however, "setarch i386 gcc -o hello helloworld.c"
also creates an x86_64 elf file instead of an i386 one, to get an i386
one I must do: "gcc -m32 -o hello helloworld.c".
This is unfortunate, because even though rpmbuild adds -m32 to the
*FLAGS environment variables things still don't for many packages,
because they for example often ignore LDFLAGS, thus not specifying -m32
when linking, causing things to fail.
A work around is to create shell script wrappers for gcc, g++ and ld
which always add -m32, put these somewhere outside the standard $PATH
and add the location to PATH when you want to build i386 binaries.
BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212520
(which got closed as not a bug, as I was already afraid).
2) rpmbuild ignores setarch
===========================
"setarch i386 rpmbuild -bb foo.spec" Still tries to build an x86_64 foo,
I know "rpmbuild --target i386" works better but still has issues, for
example libdir is still set to /usr/lib64, this is already in bugzilla.
BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=194123
3) pkgconfig ignores setarch
============================
I thought that pkgconfig was supposed to get this right and hence it was
used to implement verious replacement foo-config scripts, but pkgconfig
doesn't get this right. When testing I had only libpng-devel.i386
installed not the x86_64 version:
---
[hans@shalem ~]$ pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
---
Behaves as expected, since it searches /usr/lib64/pkgconfig where there
is no libpng.pc
---
[hans@shalem ~]$ setarch i386 pkg-config --cflags libpng
Package libpng was not found in the pkg-config search path.
Perhaps you should add the directory containing `libpng.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpng' found
[hans@shalem ~]$ ls -l /usr/lib/pkgconfig/libpng.pc
lrwxrwxrwx 1 root root 11 Oct 15 18:50 /usr/lib/pkgconfig/libpng.pc ->
libpng12.pc
---
Does not behave as expected, it should search /usr/lib/pkgconfig and
find libpng.pc
This can be worked around by doing a "export
PKG_CONFIG_PATH=/usr/lib/pkgconfig"
BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212522
4) rpmbuild lets x86_64 packages satisfy BR's when building for i386
====================================================================
The subject says most of it, when doing an rpmbuild --target=i386 I
don't want libXt-devel.x86_64 to satisfy a BR: libXt-devel .
I know things aren't that easy because with something like BR:
desktop-file-utils, the x86_64 version will do fine.
Suggestion: make rpmbuild check the arch of BR's who's name ends with
-devel.
BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212523
5) xxx-devel.arch should require xxx.arch not just xxx
======================================================
When I install libXt-devel.i386 I expect it to drag in libXt.i386 and
not to be happy with the already installed libXt.x86_64 .
This will also stop some polution with i386 packages of x86_64 system,
because currently we have the following scenario:
libXt-1.0.2-3.fc6.x86_64 is installed
Users does "yum install libXt-devel.x86_64"
Yum finds libXt-devel-1.0.2-3.1.fc6.x86_64,
which needs libXt-1.0.2-3.1.fc6.x86_64 yum does decides to update the
x86_64 version of libXt and as an added bonus also install the i386
version since both match the requirement of libXt-devel-1.0.2-3.1.fc6.x86_64
BZ: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212524
Let me know what you think & Regards,
Hans
16 years, 10 months
Propose Emacs 22 for Fedora Core 7
by Leo
Hi there,
I'm a big fan of Emacs and I like to build Emacs from source. So
whether FC7 is gonna have Emacs 22 does not concern me much. However I
think it is important to have this modernized powerful tool available
to our current and prospective Fedora users.
As we know RMS is extremely strict on fixing bugs, Emacs 22 has long
passed the production quality while still in development. A few days
ago, Emacs's developers have decided to enter pretest¹. As it is in
the early stage of FC7 cycle, I'd propose we upgrade to Emacs 22. The
News is just too big for this mailing list, but you can read it here:
http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/etc/NEWS?root=emacs
A few highlights:
- much improved Unicode support
- Gtk2 menu, toolbar and scrollbar
- Gnome style icons
- Tons of add-on packages (calc 2.05, Gnus 5.11, ido etc)
Footnotes:
¹ http://permalink.gmane.org/gmane.emacs.devel/61249
--
Leo
16 years, 10 months
