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?
12 years, 11 months
APT repository problems with up2date
by Jos Vos
Hi,
Before I start digging in the up2date code myself, maybe someone
can comment on this:
I have a problem when using up2date up2date with my self-created
APT repositories. When updating, it complains about conflicting
files: it just thinks that a long list of directories that are
shared among packages conflict with each other.
Apt-get itself (and synaptic) seems to work fine with the same
repository, only with up2date there is a problem. Also, up2date
with a yum repository of then same package set works fine, as
does yum itself.
FWIW: I generate my APT repositories with --flat --bloat.
Cheers,
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
14 years, 8 months
emacs-nxml-mode new version out.
by Gavin Henry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
If I remember Tim Waugh did an rpm for this.
Tim, do you have an updated one or should I take your src.rpm and update it?
http://www.thaiopensource.com/download/nxml-mode-20040726.tar.gz
- --
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 587369
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E ghenry(a)suretecsystems.com
Open Source. Open Solutions.
http://www.suretecsystems.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBBSOieWseh9tzvqgRAqS7AJ9dw2htkWghGDkqaSSxnDuUj8m5pQCgkm2x
zjEl0ToUdqT4KOugxCowY24=
=hVlR
-----END PGP SIGNATURE-----
14 years, 9 months
gnupg newpg gpgme gpgme03 cryptplug isuses
by Dennis Gilmore
Recently the version of libgcrypt was increased to 1.1.94 as a result of
this newpg would not build against the newer libgcrypt i sent an email to
gcrypt-devel list and this is what i got back
<quote>
Don't build newpg at all. It has been superseded by gnupg-1.9.x .
You would need an old libgcrypt < 1.1.42 to build it. The configure
sscript was not able to detect newer versions with a changed API.
</quote>
we have a problem here seems we no longer need newpg but we need things it
provides for gpgme gpgme03 cryptplug gpa kgpg (which doesnt complain so
much just says its not there) to get these things it provides we need to
go to the newer gnupg or we need to revert back to the older libgcrypt.
being so late in the cycle i dont know which would be best. so i thought id
ask before filling a bug against something. it does need to be fixed before
final is out as people will complain if they cant decrypt email in kmail or
mutt gpa doesnt work etc. i think we should probably go back to the old
version of libgcrypt
Dennis
14 years, 9 months
gqview removed from rawhide
by Christopher Aillon
Just a note that gqview just got removed from rawhide. It has the same
mission statement as gthumb and uses raster code internally. Yes, I
know there are people who use it still. I suggest this can move over to
Fedora Extras if people really want it.
14 years, 11 months
Traffic shaping broken with kernel errata
by Chris Adams
There is a new kernel config option CLS_U32_PERF that, when set,
requires a new version of the iproute utils to be able to set traffic
filters. Either this options needs to be remove from the kernel or the
iproute utils need to be upgraded.
I commented on this in bugzilla #129185 (jar(a)pcuf.fi had already opened
a ticket against iproute).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
14 years, 11 months
Where to report a missing component in bugzilla?
by Matthias Saou
Hi,
Probably a stupid question, but where should I report a missing component
in bugzilla? Against what? I thought of doing it in the bugzilla product,
but got scared of being flamed by a bugzilla developer if that's not the
right place ;-)
My problem is that sysfsutils (which is from the sysfsutils source rpm,
I've checked) isn't listed in the current Fedora Core Development
components, and I need to report that it's missing /sbin/ldconfig scriplets
:-)
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 2 (Tettnang) - Linux kernel 2.6.8-1.521
Load : 0.16 0.58 0.55
14 years, 11 months
[FC2] OT - Desert Combat F-16 bug
by Shockwave
I have been operating a game server for the better part of a year that
runs a very popular mod of BattleField 1942 called Desert Combat. From
the start, I have been using Fedora Core 1 on a hyper-threaded P4 2.8GHz
system using the SMP kernel and have enjoyed fantastic stability and
performance. Just yesterday I upgraded the system to Fedora Core 2 and
have noticed something strange. All of a sudden, every F-16 fighter
that spawns on any map has its right rear wheel sunk into the ground.
The game files are the same exact ones from the system when it was
running FC1 so that can't be the cause.
The game itself has two versions of the executable. One is statically
linked and one is dynamically linked. I have tried both and the problem
still occurs. This seems to indicate to me that the problem lies with
operating system files that both versions require. I did a little
research and ran "ldd" against both the static and dynamic versions of
the executable. Here are the results:
Static build
======================
libdl.so.2 => /lib/libdl.so.2 (0x00c7e000)
libm.so.6 => /lib/tls/libm.so.6 (0x00c59000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000)
Dynamic build
======================
libdl.so.2 => /lib/libdl.so.2 (0x00c7e000)
libncurses.so.5 => /usr/lib/libncurses.so.5 (0x03798000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000)
libm.so.6 => /lib/tls/libm.so.6 (0x00c59000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d71000)
libc.so.6 => /lib/tls/libc.so.6 (0x00b3c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00b1f000)
The only lines that differ between the two are these:
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x0023a000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00191000)
While it is possible that only the lines in common are to blame, it is
also logical to assume that it may be related to an interface between
them and other system components. Not having a tremendous amount of
experience with C under Linux, I'm not quite sure where to go next but I
am certainly willing to roll up my sleeves and dive in head first.
If determining the specific cause of this problem by someone who isn't a
developer of the game itself is not feasible, then my question is this:
Is it possible to isolate the pieces specific to FC1 and use them in
some sort of artificial environment on FC2? If that is possible,
perhaps the game server could be tricked into believing that the system
was actually FC1. That assumes, of course, that this isn't some kernel
related issue which certainly cannot be circumvented.
The gaming community tends to be fairly picky about this sort of thing
and might not feel comfortable playing on our server for matches if this
bug persists. That would mean I would need to go back to FC1 and lose
the benefits of the advances in FC2. That's something I would obviously
like to avoid. I and others have posted about this problem for some
time now and the developers of the mod probably won't respond because
they have moved on to bigger and better things. If anyone could point me
in the right direction, I would greatly appreciate it.
--
|TF20|Shockwave
http://www.clan-tf20.com/
ICQ# 57671167
#taskforce20 irc.gamesurge.net
14 years, 11 months
