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, 10 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
16 years, 1 month
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, 11 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, 2 months
Zeroconf in FC5?
by Daryll Strauss
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
directory server)
*) Allows for the publishing and discovery of services such as DNS,
NFS, ftp, http, printers, whatever (without requiring any setup or
directory server)
*) 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
appropriate places.
- |Daryll
17 years, 4 months
libm
by Rudi Chiarito
Hello,
I have a couple of questions that maybe someone can help with. Exhibit A
is an x86_64 FC3 system:
# objdump -p /usr/lib64/libfftw.so | grep -A20 Version
Version References:
required from libm.so.6:
0x09691a75 0x00 03 GLIBC_2.2.5
required from libc.so.6:
0x0d696913 0x00 04 GLIBC_2.3
0x09691a75 0x00 02 GLIBC_2.2.5
# rpm -qi fftw | grep ^[VRI]
Version : 2.1.5 Vendor: (none)
Release : 5 Build Date: Tue 14 Dec 2004
06:56:25 PM CST
Install Date: Wed 23 Mar 2005 04:14:50 PM CST Build Host:
extras64.linux.duke.edu
Exhibit B is an x86_64 FC5 system:
# objdump -p /usr/lib64/libfftw.so | grep -A20 Version
Version References:
required from libc.so.6:
0x0d696913 0x00 05 GLIBC_2.3
0x0d696914 0x00 04 GLIBC_2.4
0x09691a75 0x00 03 GLIBC_2.2.5
0x09691974 0x00 02 GLIBC_2.3.4
# rpm -qi fftw2 | grep ^[VRI]
Version : 2.1.5 Vendor: (none)
Release : 12.fc5 Build Date: Sat 18 Feb 2006
04:08:15 AM CST
Install Date: Wed 26 Apr 2006 05:00:30 PM CDT Build Host:
hammer2.fedora.redhat.com
The FC3 fftw references libm, the FC5 one doesn't. Is one of the two
behaviours considered more proper? Scons' autoconf-like test fails with
the FC5 libfftw because it can't resolve sin() and cos(). The FC3
libfftw seems to reference those, too, but the reference to libm takes
care of that.
More in general, though, isn't a call to sin() and cos() expensive and
shouldn't the compiler just use inline native FP code? In the case of
FFTW those two are only used in the setup stages, with the actual FFTs
implemented with multiplications and additions (gcc uses SSE as
expected on x86_64), but not all code is going to be like that. Are
there reasons for them not to be inlined?
Thanks.
--
Rudi
17 years, 5 months
Reporting bugs upstream
by Bart Vanbrabant
Hello,
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
about this.
thanks,
Bart
--
Bart Vanbrabant <bart.vanbrabant(a)zoeloelip.be>
PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1
17 years, 6 months
OLPC + Fedora = ?
by Andy Green
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.
Hardware
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)
http://www.opencores.org/projects.cgi/web/or1k/openrisc_1200
- ??? expensive patented video --> Opencores VGA/LCD controller
http://www.opencores.org/projects.cgi/web/vga_lcd/overview
- Sound -> Cheap SPI codec, eg,
http://focus.ti.com/docs/prod/folders/print/tlv320aic23b.html or AC97
interface to external mixer
http://www.opencores.org/projects.cgi/web/ac97/overview
Software
- Linux 2.6 with hardware-optimized .config
- glibc -> uclibc http://www.uclibc.org/ or newlib
http://sources.redhat.com/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
(http://maemo.org ,
http://maemo.org/platform/docs/maemo_exec_whitepaper.html )
- 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...
-Andy
17 years, 6 months
AIGLX packages for FC5 (and rawhide)
by Kristian Kristensen
Hi,
I've set up a yum repository with AIGLX packages for FC5. It's on
download.fedora.redhat.com:
http://download.fedora.redhat.com/pub/fedora/projects/aiglx
and there's a aiglx.repo file there that can be dropped into
/etc/yum.repos.d. With that,
$ yum --enablerepo=aiglx update
should pull down the AIGLX package set. The packages are just the
rawhide RPMs rebuilt for FC5, so they're a little rough around the
edges. That said, if the metacity compositor isn't enabled (see below),
things should be pretty stable.
Here's an overview of the features and tweakable settings in the current
versions of the repository packages. Since rawhide has the same
packages the instructions below can also be used with a recent rawhide
system:
- metacity with compositing manager functionality. Turn it on using
gconf-editor by enabling /apps/metacity/general/compositing_manager or
alternatively, use
$ gconftool-2 -s /apps/metacity/general/compositing_manager --type bool
true
- the metacity build in the repo has wobbly windows as an optional
feature. Set the environment variable USE_WOBBLY to 1 and restart
metacity. For example:
$ USE_WOBBLY=1 metacity --replace &
- metacity also has an experimental screen magnifier built in. Like
the wobbly windows this is enabled by setting an environment variable -
USE_MAGNIFIER:
$ USE_MAGNIFIER=1 metacity --replace &
- real translucency in gnome-terminal. Enable this by clicking the
"Transparent background" radio box in the "Effects" tab of the termnal
profile editor dialog. gnome-terminal may have to be restarted for this
to take effect - pkill gnome-terminal should do the trick.
There are a number of known bugs with these packages, so go easy on
bugzilla :). Specifically,
- The damage events doesn't always kick in, so sometimes window
contents doesn't update properly. A workaround for this is to switch
desktop back and forth.
- The drop shadows look weird on shaped/argb windows, for example
xeyes, the notify bubbles and well, even the rounded metacity corners.
The shadow code is due for an overhaul later, so we're not going to
patch over this issue in the short term.
- Perfomance for in-window updates isn't always great. We're
currently doing too much work when updating textures from pixmaps. It's
still possible to optimize this further with the current setup, and
longer term the memory architecture in the X server and DRI stack will
see some changes that will allow us to optimize this further.
Have fun,
Kristian
17 years, 7 months