3:29 p.m.
Yes, it's that time again...
Although the FC4 schedule hasn't been finalized yet, we do need to try to
stick to the preliminary one until it's decided otherwise. Fedora Core 4
test 1 is currently slated to come out on February 21st, which means that
I would fall in love with you all over again if you did your part to make
sure the tree was installable and free of broken dependencies & conflicts
by Valentine's Day (Monday, February 14th).
The goal for FC4test1 is to "get something out there" - it may not be
fully baked, but it does need to pass basic sanity tests, be able to
install and avoid killing people's systems. One of the ways non-developers
can help is by trying to install from rawhide and yelling loudly about any
showstopper (i.e. hard disk-destroying) problems.
I'm not yet sure whether we'll have PowerPC included - it would help to
have someone from that team give a summary of the status of rawhide on
that arch.
Cheers,
-- Elliot
3:44 p.m.
On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote:
Yes, it's that time again...
I'm not yet sure whether we'll have PowerPC included - it
would help to
have someone from that team give a summary of the status of rawhide on
that arch.
I'll do some installs over the weekend and report back on Monday.
Paul
4:13 p.m.
Hi,
The goal for FC4test1 is to "get something out there" - it
may not be
fully baked, but it does need to pass basic sanity tests, be able to
install and avoid killing people's systems. One of the ways non-developers
can help is by trying to install from rawhide and yelling loudly about any
showstopper (i.e. hard disk-destroying) problems.
Does dependency fails count? I have one blocking openoffice, one
blocking evolution and the well reported nautilus-media one. And for
those using a laptop, the classic...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145923
where the laptop keypad-mouse goes insane with all kernels post 1105_FC4
TTFN
Paul
P.S. kgpg is still broken.
--
"I don't know how World War III will be fought, but I do know World War
IV will be fought with sticks and stones" - Einstein
4:42 p.m.
New subject: x86_64 in FC4?
Elliot Lee <sopwith(a)redhat.com>:
I'm not yet sure whether we'll have PowerPC included - it
would help to
have someone from that team give a summary of the status of rawhide on
that arch.
I just got an Opteron box. It would be real nice if the FC4 test 1 disks
included 64-bit kernel RPMS and a handful of 64-bit builds for the most
speed-critical stuff (Perl & Python interpreters, Open Office, etc.).
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
4:55 p.m.
New subject: x86_64 in FC4?
"Eric S. Raymond" <esr(a)thyrsus.com> writes:
Elliot Lee <sopwith(a)redhat.com>:
> I'm not yet sure whether we'll have PowerPC included - it would help to
> have someone from that team give a summary of the status of rawhide on
> that arch.
I just got an Opteron box. It would be real nice if the FC4 test 1 disks
included 64-bit kernel RPMS and a handful of 64-bit builds for the most
speed-critical stuff (Perl & Python interpreters, Open Office, etc.).
That's assuming 64bit is faster than 32bit... which it isn't
necessarily.
But even if it were, you don't want a 64bit version of perl and python
on a mostly 32bit box. Trust me; you don't want to mix 32 and 64 with
those languages. Either you end up with a rats nest of other 64 bit
apps (vim, xchat, gaim, mod_perl, apache -- after all, those link
against perl and/or python, and that means they have to be 64bit also)
or you end up trying somehow to get both a 64bit and a 32bit perl on
the same box (which means maintaining each CPAN module in two places,
etc). Madness in both directions.
Install the full 64bit distro if you want 64bit, otherwise stick with
32bit.
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
4:57 p.m.
New subject: x86_64 in FC4?
On Fri, 2005-02-04 at 17:42 -0500, Eric S. Raymond wrote:
Elliot Lee <sopwith(a)redhat.com>:
> I'm not yet sure whether we'll have PowerPC included - it would help to
> have someone from that team give a summary of the status of rawhide on
> that arch.
I just got an Opteron box. It would be real nice if the FC4 test 1 disks
included 64-bit kernel RPMS and a handful of 64-bit builds for the most
speed-critical stuff (Perl & Python interpreters, Open Office, etc.).
It looks to me like Python and Perl are already both 64-bit executables
in FC3. Open Office is a huge amount of work; I think Dan Williams was
doing some on it, but my impression was it was still fairly far away.
5:11 a.m.
New subject: x86_64 in FC4?
On Fri, 2005-02-04 at 17:57 -0500, Colin Walters wrote:
> speed-critical stuff (Perl & Python interpreters, Open
Office,
etc.).
It looks to me like Python and Perl are already both 64-bit
executables
in FC3. Open Office is a huge amount of work; I think Dan Williams
was
doing some on it, but my impression was it was still fairly far away.
There are OOo child workspaces for 64-bit integration, but yes, its
still fairly far away. Thats going to remain 32-bit for quite a while,
iirc (even upstream, that is)
--
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
5:05 p.m.
New subject: x86_64 in FC4?
On Friday 04 February 2005 17:42, Eric S. Raymond wrote:
Elliot Lee <sopwith(a)redhat.com>:
> I'm not yet sure whether we'll have PowerPC included - it would help to
> have someone from that team give a summary of the status of rawhide on
> that arch.
I just got an Opteron box. It would be real nice if the FC4 test 1 disks
included 64-bit kernel RPMS and a handful of 64-bit builds for the most
speed-critical stuff (Perl & Python interpreters, Open Office, etc.).
Yes, I have an Opteron system also and have been impressed with its relative
performance (even with my Opteron 140).
For FC2 and FC3, the x86_64 has been a fully "tier 1" "supported"
architecture
and I would expect this to continue with FC4 [FC1 was also supported but just
a bit later]. The folks behind Fedora Core are trying to pick architectures
for which there are a large number of potential users. Thus, you have i386
(i586 and i686), x86_64, and (maybe) the ppc. For x86_64, almost all of the
packages are built as x86_64 (not just the kernel and a few other packages).
Included are some i386 packages since the system supports dual mode running
of 32 bit or 64 bit applications and there are a few applications (notably
openoffice.org) that are still 32 bit only.
--
Gene
5:34 p.m.
New subject: x86_64 in FC4?
Gene C. <czar(a)czarc.net>:
Yes, I have an Opteron system also and have been impressed with its
relative
performance (even with my Opteron 140).
Indeed. I have a single Opteron 3400 that is cranking a measured 1.65
times better performance than my previous machine on doclifter, my
monster Python app -- which doesn't sound impressive until you
consider that the previous machine was a 2-processor SMP with 1.8GHz
Athlons. So my real-world throughput is as good or (allowing for
Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz
Athlon, if such a thing existed.
The folks behind Fedora Core are trying to pick architectures
for which there are a large number of potential users. Thus, you have i386
(i586 and i686), x86_64, and (maybe) the ppc.
That should do it. I expect the PPC to rise in importance rapidly over the
next two years, but I don't see anything other than x86_32, x86_64 and PPC
achieving significant market share.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
5:38 p.m.
New subject: x86_64 in FC4?
Unlike other architectures with 32-bit and 64-bit flavors, where the
biggest change in 64-bit binaries is using twice as much space for a lot of
things, the x86-64 architecture also has twice as many registers as the
32-bit x86 and so 64-bit compiled code tends to perform noticeably better.
5:45 p.m.
New subject: x86_64 in FC4?
Roland McGrath <roland(a)redhat.com> writes:
Unlike other architectures with 32-bit and 64-bit flavors, where the
biggest change in 64-bit binaries is using twice as much space for a lot of
things, the x86-64 architecture also has twice as many registers as the
32-bit x86 and so 64-bit compiled code tends to perform noticeably better.
Aren't those registers available to 32bit apps, though, should the
compiler choose to make use of them?
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
8:02 p.m.
New subject: x86_64 in FC4?
No, to remain compatible with x86 32, you cannot add more registers
without all sorts of fun problems. Also, since AMD wanted to remain
perfectly 32bit compatible, no, no more registers for 32bit apps.
Trever
On Fri, 2005-02-04 at 18:45 -0500, Chip Turner wrote:
Roland McGrath <roland(a)redhat.com> writes:
> Unlike other architectures with 32-bit and 64-bit flavors, where the
> biggest change in 64-bit binaries is using twice as much space for a lot of
> things, the x86-64 architecture also has twice as many registers as the
> 32-bit x86 and so 64-bit compiled code tends to perform noticeably better.
Aren't those registers available to 32bit apps, though, should the
compiler choose to make use of them?
Chip
--
Chip Turner cturner(a)redhat.com
Red Hat, Inc.
--
"Magazines all too frequently lead to books and should be regarded by
the prudent as the heavy petting of literature." -- Fran Lebowitz
2:44 p.m.
New subject: x86_64 in FC4?
lør, 05.02.2005 kl. 00.34 skrev Eric S. Raymond:
Gene C. <czar(a)czarc.net>:
> Yes, I have an Opteron system also and have been impressed with its relative
> performance (even with my Opteron 140).
Indeed. I have a single Opteron 3400 that is cranking a measured 1.65
times better performance than my previous machine on doclifter, my
monster Python app -- which doesn't sound impressive until you
consider that the previous machine was a 2-processor SMP with 1.8GHz
Athlons. So my real-world throughput is as good or (allowing for
Amdahl's Law inefficiencies) better than what I'd get from a 6 GHz
Athlon, if such a thing existed.
Depends on how well threaded the app is... A single-threaded app can't
use more than one CPU :)
4:42 a.m.
On Fri, Feb 04, 2005 at 04:29:41PM -0500, Elliot Lee wrote:
Yes, it's that time again...
Although the FC4 schedule hasn't been finalized yet, we do need to try to
stick to the preliminary one until it's decided otherwise. Fedora Core 4
test 1 is currently slated to come out on February 21st, which means that
I would fall in love with you all over again if you did your part to make
sure the tree was installable and free of broken dependencies & conflicts
by Valentine's Day (Monday, February 14th).
The goal for FC4test1 is to "get something out there" - it may not be
fully baked, but it does need to pass basic sanity tests, be able to
install and avoid killing people's systems. One of the ways non-developers
can help is by trying to install from rawhide and yelling loudly about any
showstopper (i.e. hard disk-destroying) problems.
oh another thing we need to resolve is the over-abundance of
execshield-disabling libaries and binaries in the distro.
the following list (made by Marc Cox) is what we shipped as such in rhel4;
if you're the owner of any of these packages/files please seriously consider
fixing these. If you don't know how or what or otherwise have questions, do
not hesitate to ask via email (on this list or off list) or on IRC; for security
reasons we really need to reduce this list to almost nothing.
anaconda-runtime-10.1.1.13-1.i386 ./usr/lib/anaconda-runtime/loader/init: stack=RWE
anaconda-runtime-10.1.1.13-1.i386 ./usr/lib/anaconda-runtime/loader/loader: stack=RWE
libgcj-3.4.3-9.EL4.i386 ./usr/lib/libgcj.so.5.0.0: stack=RWE
gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatbind: stack=RWE
gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatls: stack=RWE
gcc-gnat-3.4.3-9.EL4.i386 ./usr/bin/gnatmake: stack=RWE
gcc-gnat-3.4.3-9.EL4.i386 ./usr/libexec/gcc/i386-redhat-linux/3.4.3/gnat1: stack=RWE
libgnat-3.4.3-9.EL4.i386 ./usr/lib/libgnat-3.4.so.1: stack=RWE
compat-libstdc++-296-2.96-132.7.2.i386 ./usr/lib/libstdc++-3-libc6.2-2-2.10.0.so:
stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/gamma_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/i810_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/i915_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/mga_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/r128_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/r200_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/radeon_dri.so: stack=RWE
xorg-x11-6.8.1-23.EL.i386 ./usr/X11R6/lib/modules/dri/tdfx_dri.so: stack=RWE
xorg-x11-libs-6.8.1-23.EL.i386 ./usr/X11R6/lib/libOSMesa.so.4.0: stack=RWE
gstreamer-0.8.7-4.EL.0.i386 ./usr/lib/gstreamer-0.8/libgstgetbits.so: stack=RWE
alsa-lib-1.0.6-4.i386 ./lib/libasound.so.2.0.0: stack=RWE
grub-0.95-3.1.i386 ./sbin/grub: stack=RWE
kernel-utils-2.4-13.1.48.i386 ./usr/sbin/x86info: stack=RWE
valgrind-2.2.0-5.EL4.i386 ./usr/lib/valgrind/libpthread.so: stack=RWE
gstreamer-plugins-0.8.5-1.EL.0.i386 ./usr/lib/gstreamer-0.8/libgsthermescolorspace.so:
stack=RWE
gstreamer-plugins-0.8.5-1.EL.0.i386 ./usr/lib/gstreamer-0.8/libgstvideoscale.so:
stack=RWE
HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/codecs/colorcvt.so: stack=RWE
HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/codecs/cvt1.so: stack=RWE
HelixPlayer-1.0.1.gold-8EL.i386 ./usr/lib/helix/plugins/vidsite.so: stack=RWE
mkinitrd-4.1.18-2.i386 ./sbin/nash: stack=RWE
bogl-0.1.18-4.i386 ./usr/lib/libbogl.so.0.1: stack=RWE
dietlibc-0.27-4.i386 ./usr/bin/diet: stack=RWE
SDL-1.2.7-8.i386 ./usr/lib/libSDL-1.2.so.0.7.0: stack=RWE
xmms-1.2.10-9.i386 ./usr/lib/xmms/Visualization/libbscope.so: stack=RWE
guile-1.6.4-14.i386 ./usr/lib/libqthreads.so.12.3.0: stack=RWE
net-tools-1.60-37.i386 ./sbin/netplugd: stack=RWE
module-init-tools-3.1-0.pre5.3.i386 ./sbin/insmod.static: stack=RWE
libdv-0.103-1.i386 ./usr/lib/libdv.so.4.0.1: stack=RWE
gdk-pixbuf-0.22.0-15.1.i386 ./usr/lib/libgdk_pixbuf.so.2.0.0: stack=RWE
gdk-pixbuf-0.22.0-15.1.i386 ./usr/lib/libgdk_pixbuf_xlib.so.2.0.0: stack=RWE
libsilc-0.9.12-7.i386 ./usr/lib/libsilc-1.0.so.2.1.0: stack=RWE
gnupg-1.2.6-1.i386 ./usr/bin/gpg: stack=RWE
gnupg-1.2.6-1.i386 ./usr/bin/gpgv: stack=RWE
flac-1.1.0-7.i386 ./usr/lib/libFLAC.so.4.1.2: stack=RWE
beecrypt-3.1.0-6.i386 ./usr/lib/libbeecrypt.so.6.2.0: stack=RWE
5:51 a.m.
On Fri, Feb 04, 2005 at 04:29:41PM -0500, Elliot Lee wrote:
> Yes, it's that time again...
>
> Although the FC4 schedule hasn't been finalized yet, we do need to try
> to
> stick to the preliminary one until it's decided otherwise. Fedora Core
> 4
> test 1 is currently slated to come out on February 21st, which means
> that
> I would fall in love with you all over again if you did your part to
> make
> sure the tree was installable and free of broken dependencies &
> conflicts
> by Valentine's Day (Monday, February 14th).
>
> The goal for FC4test1 is to "get something out there" - it may not be
> fully baked, but it does need to pass basic sanity tests, be able to
> install and avoid killing people's systems. One of the ways
> non-developers
> can help is by trying to install from rawhide and yelling loudly about
> any
> showstopper (i.e. hard disk-destroying) problems.
I have a x86_64 FC3 - Completely up to date, Would yum it up to Rawhide be
a test for you?
If not let me know what to do and I will try it.
Regards,
4:16 p.m.
On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote:
I'm not yet sure whether we'll have PowerPC included - it
would help
to
have someone from that team give a summary of the status of rawhide on
that arch.
I know Paul did an install on his iMac and was successful
So, I did one today on the iBook G3. X detection from anaconda wasn't
appropriate (first time this has happened, incidentally); relevant
bugzilla filed (radeon 7500 not being configured well).
Autopartitioning is still something that needs to be fixed. Manual disk
druid partitioning works
There is an /etc/yaboot.conf with the appropriate initrd line available.
However, the drive isn't blessed (so running /sbin/mkofboot, and then
saying Y will allow you to get fedora booting - in the instructions,
this is stated to be /sbin/yabootconfig ...)
X, for the Radeon 7500 actually comes up, using fbdev, at 640x480. Its
ugly :P
rhgb works.
SELinux brought up a system that was rather weird - ping, scp,
traceroute wouldn't work (error while loading shared libraries: cannot
restore segment prot after reloc: Permission denied). Bringing it up
with selinux=0 solved that for me quickly.
APM is still installed by default. Why is apmd.spec showing:
ExclusiveArch: %{ix86} ppc
Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd
(i'm vouching for the former) would be a better bet. Incidentally, David
Woodhouse should be posting (or has already posted) for pmud's inclusion
into Extras
--
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
4:51 p.m.
On Mon, 2005-02-14 at 06:16 +0800, Colin Charles wrote:
On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote:
> I'm not yet sure whether we'll have PowerPC included - it would help
> to have someone from that team give a summary of the status of
> rawhide on that arch.
I know Paul did an install on his iMac and was successful
I updated my powerbook to rawhide a few days ago, just after the rpm-4.4
update. Nothing broken on it that isn't broken on i386, afaict. It's
just the installer autopartitioning and yaboot stuff which needs
attention for PPC, I think.
I'm using a lot of FC3/ppc machines for real work, and there's basically
not a lot wrong with FC3 other than the installer, either.
APM is still installed by default. Why is apmd.spec showing:
ExclusiveArch: %{ix86} ppc
Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd
(i'm vouching for the former) would be a better bet.
We don't get battstat_applet support in gnome-applets unless we
provide /usr/lib/libapm.a. Yes, that sucks.
Incidentally, David Woodhouse should be posting (or has already
posted) for pmud's inclusion into Extras
Waiting for someone to second it.
--
dwmw2
7:04 p.m.
On Sun, 2005-02-13 at 22:51 +0000, David Woodhouse wrote:
I'm using a lot of FC3/ppc machines for real work, and
there's basically
not a lot wrong with FC3 other than the installer, either.
Agreed. We need to fix:
a) autopartitioning
b) since we provide a correct yaboot.conf, just run mkofboot and bless
it
>APM is still installed by default. Why is apmd.spec showing:
> ExclusiveArch: %{ix86} ppc
>
>Do we really want apmd running on PPC? I'd have figured pmud/pbbuttonsd
>(i'm vouching for the former) would be a better bet.
We don't get battstat_applet support in gnome-applets unless we
provide /usr/lib/libapm.a. Yes, that sucks.
Urgh.
> Incidentally, David Woodhouse should be posting (or has already
>posted) for pmud's inclusion into Extras
Waiting for someone to second it.
Aye from me, though I haven't taken a look at the spec file/built it
yet. Will do so soon (after I fix selinux issues)
--
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
7:08 p.m.
On Mon, 2005-02-14 at 09:04 +0800, Colin Charles wrote:
Aye from me, though I haven't taken a look at the spec file/built
it
yet. Will do so soon (after I fix selinux issues)
I took the YDL patches I liked, I updated to apmud-1.0.0 from upstream,
I fixed the fcntl thing properly, I updated the init script. There's
possibly more that could be done, but it's working for now. I'll import
it in the morning.
--
dwmw2
9:11 a.m.
On Mon, 2005-02-14 at 06:16 +0800, Colin Charles wrote:
SELinux brought up a system that was rather weird - ping, scp,
traceroute wouldn't work (error while loading shared libraries: cannot
restore segment prot after reloc: Permission denied). Bringing it up
with selinux=0 solved that for me quickly.
Were there any avc denials in /var/log/messages?
Please post problems to fedora-selinux-list and give us a chance rather
than disable it entirely.
9:57 p.m.
New subject: Fedora Core 4 on PPC (was Re: Fedora Core 4 test 1 freeze ahead)
On Fri, 2005-02-04 at 16:29 -0500, Elliot Lee wrote:
I'm not yet sure whether we'll have PowerPC included - it
would help to
have someone from that team give a summary of the status of rawhide on
that arch.
I've just done some playing with rawhide installs, and I think it's well
worth including it for FC4T1 -- we can always drop it later if we really
have to, not that I think that'll be necessary.
It's only really the installer which was in question -- the distro
itself has been fairly solid on PPC since at least FC2, if you could get
it to install.
Anaconda in rawhide is now capable of installing the bootloader
correctly and rendering the system bootable -- unlike in FC3. That was
the biggest problem in the past.
Remaining issues (see tracker BZ #121179):
- Rawhide lacks a 64-bit boot.iso for the Mac G5. That's fixed with the
patch in BZ #149081.
- Autopartitioning doesn't work well. That's partially fixed with the
patch in BZ #121266, but there's a few more relatively minor issues
which could do with being fixed by someone who understands anaconda, or
at least speaks python. The problem is definitely tractable though.
- A few X configuration problems. These should also be relatively easy.
There's an Xautoconfig package from Yellow Dog which gets it right, and
it's just a case of getting system-config-display and/or anaconda to
learn the same tricks.
--
dwmw2
7057
days inactive
7072
days old
22 comments
14 participants
participants (14)
-
Arjan van de Ven -
Chip Turner -
Colin Charles -
Colin Walters -
David Woodhouse -
Elliot Lee -
Eric S. Raymond -
Gene C. -
Kyrre Ness Sjobak -
Paul F. Johnson -
Paul Nasrat -
Roland McGrath -
Si Jones -
Trever L. Adams