An amd64 Debian sarge release in the works
| From: | Andreas Jochens <aj-AT-andaco.de> | |
| To: | debian-devel-AT-lists.debian.org | |
| Subject: | Sarge release for amd64 - Please help to fix the remaining bugs | |
| Date: | Mon, 25 Apr 2005 11:32:25 +0200 |
Debian sarge release for the amd64 architecture
-----------------------------------------------
At the amd porters irc meeting on 2005-04-23 07:00 UTC, the amd64 porting
team decided to release a version of sarge for amd64 which is based on the
unpatched Debian sarge source packages.
The amd64 porting team will provide security support for the sarge release
by autobuilding the security updates as soon as the fixed sources become
available.
Proposed updates and updated versions for Debian sarge point releases
will also be made available for amd64 by the amd64 porting team.
The package archive for the Debian amd64 sarge port will be hosted by
a Debian server which is located in Darmstadt, Germany.
The complete debian-amd64 project will move from the current alioth host
to that server.
Packages from sarge with build problems on amd64
------------------------------------------------
There are still a few packages in sarge which fail to build from source
on amd64. Those packages will not be part of the amd64 release of sarge.
The packages mentioned in the table below and all their dependencies
will not be part of the amd64 sarge release unless the listed problems
get fixed really soon and the fixed package versions make it into sarge.
The following architecture specific packages from Debian sarge/main
currently (as of 2005-04-24) fail to build from source for amd64:
Package BTS Bug Problem description
---------------- ------- ---------------------------------------------------
amynth #274703+ missing '#include <signal.h>' in main.cc
armagetron - dh_installchangelogs: command returned error code
11
cal3d - + libcal3d-doc/html/functions_rela.html missing
cbmlink #207003+ uses i386 specific code
cdrdao #249634+ x86_64-linux-{cc,gcc}.rul links missing
elk - + needs workaround for ICE with gcc-3.3
freewnn #142253 segfaults during build (same as on ia64)
ftape-tools - "ltconfig: you must specify a host type..."
ghdl #276399 ghdl internal compiler error: Segmentation fault
gnustep-base - + does not build with gcc-3.3 (needs gcc >= 3.4)
guile-core #255894+ amd64 missing in UNSUPPORTED_QTHREAD_ARCHS
heaplayers - "*** [allocators] Error 1"
hfsutils #280310+ missing '#include <errno.h>'
icom #277805+ missing '#include <errno.h>'
ircd-ircu #254165+ configure check for res_mkquery fails
k3d #278966 compilation of expression.cpp does not finish
kmatplot #286533+ missing -fPIC
krb4 #175491+ configure does not define HAVE_H_ERRNO
kuake - "Can't find X libraries"
kxstitch - "Can't find X libraries"
libglademm2.0 #279985+ "$LD" vs. $LD in configure
libgtk-java - java.lang.NullPointerException
libhdf4 #251275+ missing amd64 support in hdf/src/hdfi.h
libmysqlclient-lgpl - Linuxthreads test has to be switched off for amd64
libooc-vo #164726 "*** [liboo2c_vo@EXEEXT@] Error 1"
libpolyxmass - "*** [localealias.o] Error 1"
licq - undefined reference to
pthread_kill_other_threads_np
linux86 #260647+ elksemu's file format not recognized
lsb-release #249396+ mising 'amd64' in architecture list
lvm2 #298762+ "device/dev-io.c:342:3: #error miss O_NOATIME"
lxdoom #279190+ missing '#include <errno.h>'
masqmail #254720+ configure check for res_search in -lresolv fails
mn-fit #301509 segmentation fault on 64bit architectures
mondo - missing amd64 in architecture list
mozart - "undefined reference to `free'"
mtr #254089 configure check for res_mkquery broken
muddleftpd #253618 missing -fPIC
nntp #280278+ missing '#include <errno.h>'
ogre - "no matching function for call to ..."
oleo #287854+ missing '#include <errno.h>'
oo2c #251577+ missing 64bit-arch handling in debian/rules
perlipq #278944 links against non-fPIC libipq.a
pike7.4 - "*** [build/autodoc.xml] Segmentation fault"
plex86 - amd64 missing from architecture list
pocketpc-gcc - "/tmp/ccEpnAHc.s:1046: Error: bignum invalid"
portslave - "pppd.h: No such file or directory"
prc-tools - "machine `x86_64' not recognized"
redboot - "Unknown target amd64"
radiusd-livingst #273629+ missing '#include <errno.h>'
rplay #280274+ missing '#include <errno.h>'
rpvm #277834 missing -fPIC in pvm library
rsplib #305894 No sctplib installation found (/usr/lib/libsctp.a)
ruby-gnome2 #304951 "*** extconf.rb failed ***"
sam #280259+ missing '#include <errno.h>' in libframe/misc.c
snacc #277690 "*** [tbl.c] Segmentation fault"
socks4-server #280262+ missing '#include <errno.h>'
syslinux #306123+ amd64 missing from architecture list and FTBFS
tct #254165+ missing 'defined(x86_64)' and '#include <errno.h>'
tela - configure: error: "Blas not found!"
vnc4 #276238 "debian/scripts/vars.amd64: No such file"
wine - needs porting/depends on 32bit libs
xfs-xtt #253544+ "debian/scripts/vars.amd64: No such file"
xmms-kde #284977 "Can't find X libraries"
xppaut #306173+ missing '#include <errno.h>'
xview #294844+ amd64 missing from architecture list
A '+' after the bug number indicates that a patch is available which fixes
the problem.
Additionally, the following "Architecture: all" packages from Debian sarge
fail to build from source on amd64:
Package Bug No. Description
---------------- ------- ---------------------------------------------------
libtool1.4 #247299 demo-nopic.test has to be skipped on amd64
... [this table has to be completed]
Last update: 2005-04-24 Andreas Jochens <aj@andaco.de>
Posted Apr 25, 2005 20:05 UTC (Mon)
by Ross (guest, #4065)
[Link] (1 responses)
Not a very good experience overall. Hopefully some of these driver issues
Posted Apr 26, 2005 11:24 UTC (Tue)
by blaz (guest, #3591)
[Link]
Posted Apr 25, 2005 20:06 UTC (Mon)
by jebba (guest, #4439)
[Link]
http://jebba.blagblagblag.org/index.php?p=137
Posted Apr 25, 2005 20:29 UTC (Mon)
by jwb (guest, #15467)
[Link] (1 responses)
Posted Apr 25, 2005 20:53 UTC (Mon)
by avr (guest, #27673)
[Link]
This is how I interpret the above combined together with the amd64 discussion on debian-devel.
Incidentally, the port now gets to be a guinnee pig for the upcoming unloved architectures of Debian, where the porting teams will be supposed to do their own security support, amongst other things, that up to and including Sarge have been taken care of by Debian.
Posted Apr 26, 2005 2:59 UTC (Tue)
by kimunha (guest, #9298)
[Link] (7 responses)
Now I have a stable, free(in cost), supported server OS.
I use CentOS(Recompiled RHEL) for server but it's depend on RedHat generously publicize the source of security fix.
If RedHat decide to delay publicizing the source code of security fix by a month then I am in trouble.
Even Debian does not officially support it, CentOS is same that RedHat does not officially support it.
Important diffrence is that when using Debian, source code of security fix is guarantted to be publicized.
Posted Apr 26, 2005 10:13 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (6 responses)
Why do you think Red Hat would every do that.
"Important diffrence is that when using Debian, source code of security fix is guarantted to be publicized."
I believe that its equally guaranteed that Red Hat will make public all of its changes to any software. After all for GPL license software its required that you do so anyway
Rahul
Red Hat Inc
Posted Apr 26, 2005 18:14 UTC (Tue)
by ewan (guest, #5533)
[Link] (3 responses)
Posted Apr 27, 2005 4:34 UTC (Wed)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
If they were suddenly possessed by the devil and tried to do this, at least one of their customers would provide the source of the security fix to the public; Red Hat's EULA does not and cannot (by the GPL) prevent this.
And speaking of holding back security fixes: until recently, Debian had been holding back some security updates for weeks because of delays in getting them built for the Arm architecture. Despite all of the fuss, it will be good for Debian that they are shifting some of their architectures to second-class status post-Sarge, because the alternative is to let their x86 users run with security holes for an extended period.
Posted Apr 27, 2005 9:32 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
I've contemplated switch to Debian but ended with Gentoo instead. There are solution is trival: each package has status for each architecture. Thus package can be upgraded for x86 and sparc, but not for arm and mips. Why not go this way ? It's only logical, after all... P.S. And no x86 is not "the most current one": some changes are essential for x86-64, but not really important for x86 - in such a case package will be marked as "~x86" and "amd64"...
Posted Apr 28, 2005 3:16 UTC (Thu)
by dvdeug (guest, #10998)
[Link]
Posted Apr 27, 2005 8:10 UTC (Wed)
by kimunha (guest, #9298)
[Link] (1 responses)
I believe in RedHat's devotion to open source philosophy.
Even if RedHat delays the source code a little, I can not blame it.
Posted Apr 28, 2005 17:44 UTC (Thu)
by Guhvanoh (subscriber, #4449)
[Link]
I tried to install Sarge AMD64 last night. It wasn't able to detect eitherJust tried it out last night
the onboard SATA or SATA2 controllers though I know there are drivers for
both (NVidia and SIL). It also failed to detect either onboard Ethernet
card (NVidia and Marvel). Apparently the first is fixed in later kernels,
but all the install CDs are using 2.6.8. The latter is strange because the
Marvel driver is specifically listed, but if I try to load it it says there
is no hardware (yet /proc/pci lists it). Maybe it's just missing some PCI
IDs or something.
can be worked out.
You would probably have the same problems with ia386 sarge because of kernel problems. I couldn't get the 2.6 kernel to work properly with my recent hardware until at least 2.6.10 or so.Just tried it out last night
I wrote a mini-HOWTO in my blog last November about installing debian on AMD64. Perhaps someone will find it helpful...An amd64 Debian sarge release in the works
Great news. They can hardly have expected AMD64 to remain out of sarge, as even in it's unsanctioned experimental state, it is the second most popular architecture after i386 (according to Popularity Contest). It is three times more popular than PowerPC and 9 times more frequently seen than Alpha. It deserves a Sarge release.An amd64 Debian sarge release in the works
As I understand it, it is not released as sarge, or more precisely. The AMD64 release will not be part of Debian stable as a supported architecture.An amd64 Debian sarge release in the works
The porting team made a huge effort to have it officially included, but it didn't make it. So the porting team decided to make a release parallel to sarge, taking care of the support themselves.
It is greate news.An amd64 Debian sarge release in the works
"If RedHat decide to delay publicizing the source code of security fix by a month then I am in trouble."An amd64 Debian sarge release in the works
> I believe that its equally guaranteed that Red Hat will make public all An amd64 Debian sarge release in the works
> of its changes to any software. After all for GPL license software its
> required that you do so anyway
It's not, of course; you only need to distribute source to people you've
distributed the binaries to, so there'd be nothing keeping RH from only
releasing the source through RHN. Nothing in the GPL, anyway.
The GPL does not forbid the entire Red Hat staff from jumping out of an airplane without a parachute, but that doesn't mean it's remotely possible.
They aren't going to hoard their fixes, or give them only to their customers. You can't do this as a distro, because you have to work with the upstream, and your own engineers wouldn't put up with something so socially irresponsible.
An amd64 Debian sarge release in the works
An amd64 Debian sarge release in the works
Because then you have multiple versions of the package running around, making support much harder.An amd64 Debian sarge release in the works
It is guaranteed that RedHat will publicize its security fix source code (at least to their customer).An amd64 Debian sarge release in the works
But, it is not guaranteed the source code of security fix is available immediately after binary of security fix is available.
RedHat can DELAY a little, which means serious degrade in the quality of RHEL clones.
I also believe RedHat will keep major contribution to open source community.
But if RHEL clones mean serious threat to their sales, they are FORCED to do something.
It is a competition which is so common in free economy.
And who in the world support their competitors?
To the best of my knowledge, and I have only been using Redhat since RHL2.1, source rpms and binary rpms are published in the same notification. I have yet to see Redhat allow people to download the binary rpms while refusing access to source rpms.An amd64 Debian sarge release in the works