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?
14 years, 5 months
DMRaid in Fedora devel
by Mark Wormgoor
Hi,
Attached are three patches that I made to get Fedora-devel to install on
a bios sata raid-0 system (Sil 3112 on Abit AN7). It uses Heinz
Mauelshagen's dmraid for detecting the disks.
The first patch is against Anaconda. It removes the raid disks from the
isys disklist and replaces them with the mapper device. The patch
requires the full (not enable-mini) dmraid binary in the stage 2 image.
I tested the patched Anaconda in install, upgrade and rescue mode (text
and gui) and had no problems on my system.
The second patch is against mkinitrd. It adds /sbin/dmraid.static to
the initrd if necessary and updates the initscript. The
/sbin/dmraid.static binary is not yet a part of the current dmraid rpm,
so you need to provide your own.
The third patch is against rc.sysinit so that dmraid.static is run at
boot. Again, you need the full dmraid binary under /sbin/dmraid.static
(not enable-mini) because the rc.sysinit script uses the testmode first
before enabling the mapper devices.
I now have a Fedora-devel system booting from my two raid-0 disks.
Unfortunately, there is no bootloader for /dev/mapper devices. There is
a patch against lilo to make it work on devmapper devices here
(http://www.saout.de/misc/) and Eric Agsjö has a patch to make it work
with raid-1 devices here
(https://www.redhat.com/archives/ataraid-list/2004-October/msg00007.html). I am still using lilo under FC1 (using the medley.o module) and that works for me.
I hope someone finds these patches useful; it would be very nice if FC4
would install on and boot from these bios ide raid devices without too
much hacking.
Kind regards,
Mark Wormgoor
--
***************************************************************
* |\ /| | /| / Mark Wormgoor *
* | \ / | | / | / mailto:mark@wormgoor.com *
* | \/ |ark |/ |/ormgoor http://www.wormgoor.com/mark/ *
***************************************************************
15 years, 10 months
Emacs cvs snapshot packages available
by Jens-Ulrik Petersen
I finally got round to packaging a snapshot of current
development Emacs from CVS. Noone knows when the next
actual release of Emacs will be, but there are many
new features and changes: improved utf-8
and gtk2 support in particular.
See
http://people.redhat.com/petersen/emacs/
for more details.
Enjoy and please report any problems directly to me
(ie not to bugzilla or the emacs-devel list:),
Jens
15 years, 11 months
Proposal: swap epic for irssi
by Colin Charles
Hi,
For FC-4, what would folk think about removing epic and replacing it
with irssi in Core?
irssi currently sits in Extras, and we could very likely just move epic
to Extras after the swap.
Thoughts?
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
16 years
binary rpm package checking
by Florian La Roche
This is a start to check binary rpm packages for consistency.
Right now mostly the rpm header is checked to get a feeling
how much "strange" binary rpm packages might be out there.
It has two modes of checking, one for the current Fedora Development
tree with more strict checks and a more relaxed one that should
work for all existing rpm packages, also other distributions.
I'd be interested to get feedback on what output is generated
for rpm addon expositories and non - Red Hat distributions
if the script generates warning messages.
At least for Fedora Core only very few rpm tags are actually
used in the rpm header.
Examples usage:
./pyrpm.py --strict /mirror/fedora/development/i386/Fedora/RPMS/*.rpm
Checking all rpms:
locate .rpm | xargs ./pyrpm.py
find /mirror/linux -name "*.rpm" -type f -print0 2>/dev/null |
xargs -0 ./pyrpm.py
greetings,
Florian La Roche
16 years
fedora stable branch updates Q&A policy
by Kyrre Ness Sjobak
What is this policy today? Who does the testing before an update is
released for large numbers of users to install via yum?
I am wondering, not because there are very many bad updates (99% of them
are OK), but i simply wonder - who does this? And who does this for
extras?
Personally, i would believe a q&a mailinglist and a "testing" repo for
yum could be a good idea, in order to get packages as good tested as
possible - as fast as possible.
Kyrre
16 years
redhat abe
by Christof Damian
I just read about RedHat ABE (Application Build Environment) which
seems to be something similar to mach.
Will this be available or work on fedora? Has anyone tried it ?
I found some info here: http://people.redhat.com/mwaite/
Christof
--
Christof Damian
christof(a)damian.net
16 years, 1 month
radical suggestion for fc4 release
by seth vidal
Hi folks,
this is a touch silly but possibly useful and it would definitely cut
down on the old crap blocking up cdroms.
how about if we kill all rpm spec file changelog entries OLDER than 2
years.
they'll still live on in older srpms and rpms but it'd be a useful
reduction and it would make the specfiles that much smaller, along with
the rpm headers.
thoughts?
-sv
16 years, 1 month
Fedora PPC things...
by Colin Charles
CC'ing fedora-devel-list because there are some things that need to be
sorted for a possible FC-4/ppc _release_
Now, a list of known issues:
0. this boot.iso + nfs installation system has to go away - so we need
to give anaconda love
1. out of the box video detection - system-config-display needs to be
hacked on to recognise all the common Mac hardware bits out there. We
can't be pushing Xautoconfig or something similar... but we can lean on
it for inspiration if need be
2. anaconda and partitioning - auto partitioning possibly still fails (I
don't think the Apple Bootstrap partition gets created); running
yabootconfig automatically after installation, with an appropriate
initrd and so on needs to happen (we can't depend on users breaking out
into a shell)
3. sound is still relatively broken - dmasound_pmac tends to work, but
is not the default config. system-config-soundcard definitely needs some
work to make it play well with the Macs
4. power management - we need either pmud or pbbuttonsd. The latter has
received no love from most fedora/ppc users, so pmud seems to be the
winner, I'd guess. We need this included in Core (building only for ppc,
and possibly later ppc64). We know yellow dog add some nice patches for
disabling the touchpad in pmud - I guess the package maintainer can be
free to include such patches at will if need be
5. updates - we can't have david woodhouse (dwmw2) grabbing packages
from the RH build system and having to host them at ftp.linux.org.uk -
we need a better mechanism. i.e. the normal way package updates go out,
can the ppc and ppc64 packages go out with them too? This might involve
some policy change at Red Hat, so can someone in the know, speak up?
6. back to the topic of power management; there are some patches out
there that help G4 iBooks and newer powerbooks sleep (and wake up).
They're not in the upstream kernel.org kernel, but with good benh
approval (!), we might consider patching the kernel to make it more
useful. dwmw2 currently builds kernels with these patches enabled
7. we'll be upfront about modems and Airport Extreme probably never
working for free. Modems have drivers at linuxant (though they still
might be flaky with our stack size in the kernel), but the Airport
Extreme stuff is probably a no go (not yet at least)
8. 64-bit support. I personally don't have a G5 or anything ppc64, but I
know that dwmw2 has one sitting at work, as probably does nasrat. We
need more 64-bit testing, and making sure that anaconda boots on them
too (if not we need more anaconda hacking). There have been reports that
things were (or are still) broken on a 64-bit arch
9. PegasosPPC (Genesi) makers of PPC boards have thought of getting
FC4/ppc to work on their machines. I'll be taking a look at this, though
does anyone else have such machines around?
10. spanking MiniMac support?
I guess this is a list of outstanding issues that we need to fix before
Fedora Core 4 gets a PPC release. If I missed anything glaring, do add
on the the thread
Otherwise, lets get some C and Python hackers hacking on the packages
above, and making things "just work" for FC/ppc. PPC specific discussion
can take place at fedora-ppc(a)lists.infradead.org
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
16 years, 1 month
