kudzu error message
by LarryT
(using FC5-test3, architec is x64, installing with iso from harddisk).
After updating my fc5, using yum, still get an error at boot when
checking new harware :
checking for hardware changes/etc/rc5.d/S05kudzu : line 23: 1524
Segmentation fault /sbin/kudzu $KUDZU_ARGS
larry
PS : have the simplicity to tell me if my report is not as good as
expected ! thx :)
18 years, 3 months
Keyboard situation - Non-US users dead in water?
by Chris Tyler
There are a number of interacting issues surrounding XKB at this point,
but the bottom line is that many (most? all?) users using non-US
keyboards are pretty much dead in the water right now.
Putting aside issues with libxklavier and keyboard options, the console
(non-X) keyboard maps, and the keyboard switching applet, it's simply
not possible to select certain keyboards which are in widespread use.
Here's one example: in FC4 and before, the de-facto standard French
Canadian keyboard was identified as ca_enhanced, and it worked
reasonably well. (Note: This is the keyboard that is shipped by Dell,
IBM, HP, etc, and the keyboard that you you would buy at a Future
Shop/Best Buy in Quebec. English Canadian users (such as myself) use the
"us" keyboard layout. All other "Canadian keyboards" are corner cases).
With the current set of XKB data, this keyboard is identified as ca(fr),
and it can be selected manually:
setxkbmap "ca(fr)"
When selected in this way, they keyboard works perfectly (except for
RightAlt-E which is labelled as Euro on newer versions of the
keyboard).
However, this keyboard option cannot be selected at installation time,
nor can it be correctly selected after installation using the KDE or
Gnome applets, which expose the corner-case keyboards but don't provide
an option for this one. I'm assuming (from browsing Bugzilla) that
similar problems exist for some of the other international keyboards.
(It's unclear to me where the current (X11R7) set of xkb maps came from.
They're not the legacy maps that shipped with 6.8.2, but they're not the
current xkeyboard-config maps either - perhaps they're a snapshot of
older xkeyboard-config data, since they seem closer to xkeyboard-config
than they do to the 6.8.2 set).
What needs to be done to get this working for FC5?
--
Chris Tyler
18 years, 3 months
Re: [Fwd: Help Needed: FC5 Blocker List and Rawhide Install Testing]
by Fulko.Hew@sita.aero
Rahul Sundaram <sundaram(a)fedoraproject.org> on 03/08/2006 08:42 AM
repliued:
> Fulko.Hew(a)sita.aero wrote:
>
> >
> >I (and others) would like to see the problem with 'no longer being able
to
> >install'
> >resolved. Apparently something between FC5 Test 1 and Test2 _changed_
the
> >way
> >the CD and DVDs are made, preventing some people from installing off of
> >the media, whereas older version of Core work fine.
> >
> >This is reported in Bugzilla #s: 178143, 182147, 178632
> >
> >This bug will prevent (some) people from being able to install Fedora
> >Core altogether. And it will give any newcomer, a bad taste...
> >well actually _no_ taste, since they won't know how to get past
> >the boot prompt!
>
> There are all duplicates of the same bug which is marked as a FC5 target.
Yes, I know they are all duplicates of the same bug (I provided them for
reference).
I responded to your email, because this bug wasn't on the list you refered
to.
Pardon my ignorance... what does 'marked as a FC5 target' mean?
18 years, 3 months
Why can't I see my other processes?
by Orion Poplawski
[root@hammer ~]# ps -fu orion
UID PID PPID C STIME TTY TIME CMD
orion 5059 5052 0 Mar08 ? 00:00:02 sshd: orion@pts/1
orion 5060 5059 0 Mar08 pts/1 00:00:01 -tcsh
orion 5238 5237 0 09:05 ? 00:00:01 -csh
/opt/local/sge-6.0/default/spool/ham
orion 5435 5238 0 09:06 ? 00:00:00 /usr/bin/python -tt
/usr/bin/mock --no-cl
orion 6020 5435 0 09:07 ? 00:00:00 sh -c {
/usr/sbin/mock-helper chroot /var
orion 6038 6037 0 09:07 ? 00:00:00 rpmbuild --rebuild
--target x86_64 --node
orion 6086 6038 0 09:07 ? 00:00:00 /bin/sh -e
/var/tmp/rpm-tmp.69316
[...snip...]
[orion@hammer paraview-2.4.2]$ ps -fu orion
UID PID PPID C STIME TTY TIME CMD
orion 5060 5059 0 Mar08 pts/1 00:00:01 -tcsh
orion 11391 5060 0 10:02 pts/1 00:00:00 ps -fu orion
Same in top.
Super tight security?
18 years, 3 months
Faster network?
by Mike Chambers
I saw this in my file archives, and think the contents are something I
read to make your network/machine a little faster. If so, where would
this be set to? rc.local? a sys file somewhere?
Below is what the contents of the file are...
ifconfig eth0 mtu 1500
echo 256960 >> /proc/sys/net/core/rmem_default
echo 256960 >> /proc/sys/net/core/rmem_max
echo 256960 >> /proc/sys/net/core/wmem_default
echo 256960 >> /proc/sys/net/core/wmem_max
echo 0 >> /proc/sys/net/ipv4/tcp_timestamps
echo 1 >> /proc/sys/net/ipv4/tcp_sack
echo 1 >> /proc/sys/net/ipv4/tcp_window_scaling
--
Mike Chambers
Madisonville, KY
"It's only funny until someone gets hurt, then it's hilarious!"
18 years, 3 months
Re: FC5: How to run an old binary that wants non-NPTL glibc?
by Mikko Huhtala
John Reiser wrote:
> There is a feature of glibc that allows running an app under a completely
> different glibc. This feature is used when testing a new glibc. Invoke
> ld-linux directly and specify "--library-path list:of:directories" (which
> overrides LD_LIBRARY_PATH for this execve only) before the rest of the
> command line:
> /path/to/old/glibc/ld-linux.so.2 --library-path /path/to/old/glibc:$LD_LIBRARY_PATH app arg1 ...
> See also this web page which contains more explanation and some helper code
> to run an "indirect runtime loader":
> http://BitWagon.com/rtldi/rtldi.html
Thanks a lot. I did manage to cobble things together, although this is
by far the ugliest contraption I've ever done as an administrator.
The app is a big graphical one, so I had to put in the
/path/to/voodoo/glibc directory libstdc++, libgcc and half of the
various libs that come with X. The app lives in its own bubble of FC3
bits and pieces, but it does work.
Mikko
18 years, 3 months
Password feedback in Anaconda
by Arthur Pemberton
I just installed FC5Test3 and I've got to say, everything is prettier, even
at 800x600. However, Anaconda in FC1 and FC2 I believe, gave live feedback
on length and strenth of passwords being input, any idea why this is
nolonger so? It was a really nice feature IMHO.
Good work to all those who have worked, and are working on FC5 . . . now I
just need to figure out what to test.
Peace
Arthur
--
As a boy I jumped through Windows, as a man I play with Penguins.
18 years, 3 months
Network Manager with madwifi drivers
by Brian Anderson
As documented in bug 180369, NetworkManager stopped connecting my
madwifi wireless card after the change from NetworkManager-0.5.1-8 to
NetworkManager-0.5.1-10. I use the CVS versions of the madwifi drivers.
I use WEP for authorization.
Today I downloaded the SRPM for NetworkManager-0.6.0-2 and removed the
special-case-madwifi.patch and built the binary. This version of NM can
connect to my madwifi card. The patch is trying to work around a WPA
problem in the madwifi drivers. My question is has the fix for WPA
broken WEP?
--
. __o Brian "la lumaca"
_`\<,_
(*)/ (*)
18 years, 3 months
FC5: How to run an old binary that wants non-NPTL glibc?
by Mikko Huhtala
I'm planning to migrate a site of about two dozen desktops from FC3 to
FC5. One of the apps we use requires LD_ASSUME_KERNEL=2.4.9 on FC3. I
have been unable to run it on FC5. The LD_ASSUME_KERNEL setting, of
course, breaks everything on FC5 because the appropriate version of
glibc is not present.
The error I get is
relocation error: [ ... ] : symbol errno, version GLIBC_2.0 not
defined in file libc.so.6 with link time reference
apparently because 'errno' is defined differently in the NPTL-version
of glibc.
The obvious fix is to patch the source and recompile, but
unfortunately the app is Closed-Source Legacy Crap (TM) from Big
Unresponsive Company Ltd.
Any ideas? Is it possible to compile a non-NPTL binaries of glibc 2.4?
I'm willing to try any kind of ugly hacks, including but not limited
to, editing symbol tables in binaries.
Mikko
18 years, 3 months
Please "attach" files to bugzilla, instead of pasting into a massive comment
by Mike A. Harris
Warning: Frustration rant follows.
More and more over time, I am noticing a tendency of bug reporters
adding log files, config files and other large files to bug reports
by cutting and pasting these massive files into the comment box,
instead of attaching them as proper bugzilla file attachements.
As a developer, this is very irritating because it makes the bug
report incredibly long to view. You have to scroll forever to
get from one comment to the next, with this massive file pasted
in the middle, making it very hard to follow, and thus making
it more difficult to provide help for the problem being reported.
It also causes bugzilla's word-wrap to affect the text being pasted,
which generally breaks patches, making them no longer apply cleanly,
until they're reattached properly as file attachment by the person
who has the original, or causing the developer more work manually
recreating the patch from scratch by hand editing the source and
regenerating it with diff/gendiff. This also can cause config files
pasted into comments to be distorted and no longer machine parseable,
depending on the syntax of the file, and how the parser that reads
it handles things that have moved from one line to another due to
wordwrapping in bugzilla.
Bugzilla has a file attachment feature, labeled "Create a file
attachment". If you can not find it, please use your web browser's
search feature to find the link on the bugzilla page, and _always_
attach these files directly as individual uncompressed text files,
so that developers such as myself can bring the file attachments
up in another web browser tab/window with a simple single mouse
click, while still following the bug report.
Bugzilla used to also have a "Create a file attachment" hyperlink
directly under the "Add a comment" window in red font, which the
majority of users seemed to find right away. Back then, we got
very few 1Mb log files pasted into bug reports making them
unreadable, however nowadays bugzilla has reverted to the old
behaviour, and an ever mounting number of bugs are getting these
massive files pasted into them.
This is very very irritating. Please help us (developers) to help
you (bug reporters/testers), by using bugzilla properly, and
thinking about what it is like to be on the receiving end of 500
bug reports and get 30 like this.
</rant>
Feature request filed:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184481
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
18 years, 3 months