Re: amd64 and sarge
On Mon, 26 Jul 2004, Andreas Barth wrote: > 5. our users will profit if we can give them at least some support for > amd64 (means: more than only i386). 6. migrate to a 32/64 port immediately after r0 and schedule r1 few month later or 6a. fix all pending bugs on amd64/r0, set it as "official port" and release r1 few months later 6b. migrate to 32/64 dist, and release r2 few months later because letting a potentially broken, uncomplete (64-bit only) dist for a year or two is not very suitable for many users this would bring the need of a more aggressive (sub)release cycle (ie shorter, "a la gentoo" (no flame here please), that should maybe be discussed here (my 0.15 euro)
Re: problem running X11
Hi, > i've experienced such problems too. however, i have a ati radeon 9200 gfx > card but the same motherboard. > i fixed this problem by not loading the dri module in > /etc/X11/XF86Config-4 Thanks for the response. Unfortunately your tip was not the one that solved my problem :( I've also checked if it was the vesafb module that got in the way, but after compiling a 2.6.7-kernel without framebuffer support I still get a locked up machine. Even an ssh into the machine does not work. Anyone else out there that may have a hunch about this? regards, Thomas
Re: amd64 and sarge
* Xavier Roche ([EMAIL PROTECTED]) [040726 22:10]: > On Mon, 26 Jul 2004, Andreas Barth wrote: > > 5. our users will profit if we can give them at least some support for > > amd64 (means: more than only i386). > > 6. migrate to a 32/64 port immediately after r0 and schedule r1 few month > later > or > 6a. fix all pending bugs on amd64/r0, set it as "official port" and > release r1 few months later > 6b. migrate to 32/64 dist, and release r2 few months later 6a is what I said (except that my idea was to create the directories now, to preserve the right version of the packages), and 6, 6b is not doable. Either we take amd64 as is in sarge, or we don't take it at all. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: amd64 and sarge
Hi, On Mon, Jul 26, 2004 at 09:50:54PM +0200, Xavier Roche wrote: > because letting a potentially broken, uncomplete (64-bit only) dist for > a year or two is not very suitable for many users Not adding pure64 at all is not very suitable for much more of our users than those two or three who want to run non-DFSG-free software, wich might not be availeable for linux-amd64, on their systems. Feel free to work on multiarch, or stop bitching. thanks. Greetings Frederik Schueler -- ENOSIG
Re: sources.list used to build monolithic?
Kurt Roeckx wrote: On Mon, Jul 26, 2004 at 10:38:12AM +0200, Harald Dunkel wrote: Hi folks, I'm trying to rebuild the monolithic installer image for amd64. This is my sources.list.udeb.local: deb http://debian-amd64.alioth.debian.org/pure64 unstable main/debian-installer I don't use the "local" file, sources.list.udeb is automaticly generated from the /etc/apt/sources.list file and that same line I have in sources.list.udeb. The problem I had went away somehow. But I would prefer not to mix the machine configuration (/etc/apt/sources.list) and the sources.list to download the udebs to build d-i. Regards Harri
Which kernel to use
I have been using the vanilla 2.6.7 kernel for sometime on my amd64 box. I would like to know how good is the debian-amd64 kernel source as I like to use a modular kernel. I dont have any hardware as of now that require precompiled binaries to be used by the drivers other than nvidia which I can compile from the nvidia provided drivers. Would you suggest migrating to the debian kernel source instead of the vanilla source. Thanks, Bharath --- Bharath Ramesh <[EMAIL PROTECTED]> http://csgrad.cs.vt.edu/~bramesh
amd64 and sarge
Dear Porters, dear Developers, the latest update from the release masters indicate that the release of sarge is happening quite soon (perhaps by mid-September).[1] I'm happy with this development. This mail should write up some of the issues I see for amd64 and sarge, and I welcome feedback. In my opinion, the decision how to proceed needs to be based on the following issues: 1. amd64 is currently not part of sid 2. to allow amd64 to enter the archive, at least the mirror scripts have to be adopted, and the technical questions by the ftp-masters have to be answered (however, these questions are not asked till now[2]). 3. the release of sarge is overdue; we should not risk a further delay. 4. base+standard packages will be frozen starting on August 1st.[1] 5. our users will profit if we can give them at least some support for amd64 (means: more than only i386). So, because of 1. and 4., there is already now no possiblity any more to add amd64 to sarge as a normal architecture. I also see no way to official release sarge r0 with amd64 as supported architecture. What may be possible in my opinion is to add amd64 as a "maybe broken"-architecture even to sarge (means: bugs only for that arch are non-RC per definition, and this arch doesn't count for package transits to sarge); on the other hand, porters uploads of amd64-binary packages even to t-p-u are relaxed till sarge r1 (or so). Via this way, amd64 packages are in the archive, even in the dist called sarge. Users don't need to use a development version of debian for amd64. We just don't claim that it's as hard tested as everything else. Going this way would prevent to delay the release of sarge. And: We keep the door wide open to add amd64 with sarge r1. If we want to follow this way, the remaining steps would be IMHO: 1. Get the remaining issues with the ftp- and mirror scripts fixed. 2. Ask the technical questions from the ftp-masters, and answer them. 3. Add amd64 to sid, and as "maybe broken"-arch to sarge. 4. Release sarge. Cheers, Andi [1] http://lists.debian.org/debian-devel-announce/2004/07/msg00016.html [2] http://lists.debian.org/debian-devel/2004/07/msg01344.html -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: gcc-3.4 builds
Thanks for your reply. I hope you will give a status of when the port is ready for public test :-). Regards Anders Fugmann P.s. Your ip address is listed in SORBS (http://www.nl.sorbs.net/), as beeing a dynamically assigned ip address. You should consider using you ISP as mail relay for sending mails, or send SORBS a note. Andreas Jochens wrote: On 04-Jul-26 19:05, Anders Peter Fugmann wrote: Hi, I see a new directory on alioth named gcc-3.4, which seems to contain alot of packages. I guess that this is all the packages compiled with gcc-3.4, which generates better code for x86-64 than gcc-3.3. Is this a complete port (compared to pure64 on alioth) or should I sill have pure64 in my sources.list for packages that are not yet compiled using gcc-3.4? Currently all packages are being recompiled with gcc-3.4 as the default compiler. The resulting packages are being uploaded to the new repository in the gcc-3.4 directory. Every package is being compiled in clean chroot environment with only the specified Build-Depends installed. Building about 8500 packages takes some time even on an amd64 machine. At the moment the gcc-3.4 repository has about 1200 packages and it includes all packages with priorities 'Required', "Important' and 'Standard' as well as all packages from the base system which are necessary to debootstrap a chroot environment. However, the upload of the missing ~7000 packages will take a few more days. Also, is there any issues to be aware of when mixing gcc 3.4 compiled packages with gcc 3.3 compiled packages? I read that gcc 3.4 has changed ABI from gcc 3.3, but I'm not sure which architectures this affectes. I would recommend _not_ to use the packages from the gcc-3.4 repository until the conversion of the archive has been completed. C++ programs compiled with g++-3.3 use the library from the libstdc++5 package while programs compiled with g++-3.4 use the one from libstdc++6. There are (minor) incompatibilities between those two libraries. Regards Andreas Jochens
Re: gcc-3.4 builds
On 04-Jul-26 19:05, Anders Peter Fugmann wrote: > Hi, > > I see a new directory on alioth named gcc-3.4, which seems to contain > alot of packages. I guess that this is all the packages compiled with > gcc-3.4, which generates better code for x86-64 than gcc-3.3. > > Is this a complete port (compared to pure64 on alioth) or should I sill > have pure64 in my sources.list for packages that are not yet compiled > using gcc-3.4? Currently all packages are being recompiled with gcc-3.4 as the default compiler. The resulting packages are being uploaded to the new repository in the gcc-3.4 directory. Every package is being compiled in clean chroot environment with only the specified Build-Depends installed. Building about 8500 packages takes some time even on an amd64 machine. At the moment the gcc-3.4 repository has about 1200 packages and it includes all packages with priorities 'Required', "Important' and 'Standard' as well as all packages from the base system which are necessary to debootstrap a chroot environment. However, the upload of the missing ~7000 packages will take a few more days. > Also, is there any issues to be aware of when mixing gcc 3.4 compiled > packages with gcc 3.3 compiled packages? I read that gcc 3.4 has changed > ABI from gcc 3.3, but I'm not sure which architectures this affectes. I would recommend _not_ to use the packages from the gcc-3.4 repository until the conversion of the archive has been completed. C++ programs compiled with g++-3.3 use the library from the libstdc++5 package while programs compiled with g++-3.4 use the one from libstdc++6. There are (minor) incompatibilities between those two libraries. Regards Andreas Jochens
Keyboard errors
Offlate I am seeing this error very often on my machine. I shifted to the 2.6.7 kernel to get nVidia drivers working and I am seeing these errors. I never saw them when I was using 2.6.6 kernel. I am using the vanilla kernel and not the debian kernel. The error I get is: atkbd.c: Unkown key released (translated set 2, code 0x81 on isa0060/serio0). atkbd.c: Use 'setkeycodes e001 ' to make it known. Thanks, Bharath --- Bharath Ramesh <[EMAIL PROTECTED]> http://csgrad.cs.vt.edu/~bramesh
gcc-3.4 builds
Hi, I see a new directory on alioth named gcc-3.4, which seems to contain alot of packages. I guess that this is all the packages compiled with gcc-3.4, which generates better code for x86-64 than gcc-3.3. Is this a complete port (compared to pure64 on alioth) or should I sill have pure64 in my sources.list for packages that are not yet compiled using gcc-3.4? Also, is there any issues to be aware of when mixing gcc 3.4 compiled packages with gcc 3.3 compiled packages? I read that gcc 3.4 has changed ABI from gcc 3.3, but I'm not sure which architectures this affectes. Regards Anders Fugmann
Re: lesstiff bug triggered by grace and ddd programs
I've applied Nicks patch to the LessTif sources. Thanks for reporting it. Danny -- Danny Backx - danny.backx-at-planetinternet.behttp://up.to/danny.backx
Re: lesstiff bug triggered by grace and ddd programs
I've applied Nicks patch to the LessTif sources. Thanks for reporting it. Danny -- Danny Backx - danny.backx-at-planetinternet.behttp://up.to/danny.backx
Re: sources.list used to build monolithic?
On Mon, Jul 26, 2004 at 10:38:12AM +0200, Harald Dunkel wrote: > Hi folks, > > I'm trying to rebuild the monolithic installer image for amd64. > This is my sources.list.udeb.local: > > deb http://debian-amd64.alioth.debian.org/pure64 unstable > main/debian-installer I don't use the "local" file, sources.list.udeb is automaticly generated from the /etc/apt/sources.list file and that same line I have in sources.list.udeb. > Reading Package Lists... Done > Building Dependency Tree... Done > libacl1 is already the newest version. > adduser is already the newest version. > apt is already the newest version. > at is already the newest version. > libattr1 is already the newest version. > base-files is already the newest version. > base-passwd is already the newest version. > bash is already the newest version. > bc is already the newest version. > Package dc is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > E: Package dc has no installation candidate > make[2]: *** [stamps/get_udebs-monolithic_2.6-stamp] Error 100 > make[1]: *** [_build] Error 2 > make: *** [build_monolithic_2.6] Error 2 All the packages you're listing are not in the monolithic iso at all. They don't have any udebs either so I don't think it's a problem with your sources.list.udeb.local file. I have no idea what's wrong. Do you have all the dependencies for debian-installer installed? apt-get build-dep debian-installer Kurt
Re: Migration from unstable to testing.
On 23/07/2004 Chris Wakefield wrote: > Ron Johnson wrote: > >You're already running pure-amd64? > > Well, I may have embarassed myself, but I assumed that installing from: > http://debian.inode.at/pure64/ > with the > http://debian-amd64.alioth.debian.org/install-images/sid-amd64-monolithic.iso > image, and that: > deb http://debian-amd64.alioth.debian.org/pure64 sid main contrib non-free > is listed in my sources.list, that it would be a pure64? your absolutely correct, and you're running a pure-amd64 install. i don't think, that migrating from unstable to testing once amd64 entered debian, and once it has a testing tree, will be a big deal. you just change your sources.list, and wait until all packages currently installed are superseded by never versions in testing, as downgrading isn't recommented in those general cases. > I have noticed that in the .config file of: vmlinuz-2.6.7-5-amd64-xeon > has this: > CONFIG_IA32_EMULATION=y > > Maybe I'm mistaken? Please inform me if I am. no, it just allows you to still run 32bit binarys on your 64bit install. is enables you to use software compiled for the (currently more widespread) i386 port of linux kernels. bye jonas
Re: problem running X11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i've experienced such problems too. however, i have a ati radeon 9200 gfx card but the same motherboard. i fixed this problem by not loading the dri module in /etc/X11/XF86Config-4 there is another thread in this list, that says 64bit X on 64bit kernel would work fine with dri. for me it doesn't. hth, knue On Sunday 25 July 2004 17:17, Thomas J. Zeeman wrote: > Hi, > > I'm trying to get x11 to run on my machine but whatever I try to do it > completely locks up and I have to reset it. > My machine has an Asus K8V SE deluxe, A64 3200+ and a Matrox P650. Since > the latter has no working amd64-compatible driver I'm trying to get it to > work with the vesa-driver. > > The system is installed with a d-i daily image from > debian-amd64.alioth.debian.org/install-image dated 20040724 (I've also > tried almost all others of the past week but all have the same result on > x11) and that seems to work out fine. > > At one point I thought it could be the known problem of a PS/2 mouse and > kernel 2.6.7 but moving my mouse to USB and using kernel 2.6.6 also > resulted in a complete lockup. > > I've also tried to get it to run with a known working XF86config-4 from an > i386 install (the only other difference being that it uses a 2.6.5 kernel) > but that one results in a lock-up too. > > Does anyone have any idea what I may have done wrong? Or has anyone got an > idea of what else I could try to do to get X working? > > I've attached my config and log from the last try. I was on a cleanly > installed system running the default kernel (2.6.7) and my mouse stuck in > a usb-port. > > regards > Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBBMXV4TR4gVE/spsRAlExAJ4gxsXlutaVrfWqc9zcxPIyusgwWgCg60T8 PbHW/55bnrn4CRBgylJkCVY= =mYSe -END PGP SIGNATURE-
sources.list used to build monolithic?
Hi folks, I'm trying to rebuild the monolithic installer image for amd64. This is my sources.list.udeb.local: deb http://debian-amd64.alioth.debian.org/pure64 unstable main/debian-installer But if I run "make build_monolithic_2.6", then I get # make build_monolithic_2.6 make[2]: `pkg-lists/standard-udebs' is up to date. ./get-packages udeb Hit http://debian-amd64.alioth.debian.org unstable/main/debian-installer Packages Ign http://debian-amd64.alioth.debian.org unstable/main/debian-installer Release Reading Package Lists... Done Reading Package Lists... Done Building Dependency Tree... Done Need to download : Reading Package Lists... Done Building Dependency Tree... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. grep-dctrl -P -e '.*-modules-2.6.7-5-amd64-generic-di' \ -sPackage apt.udeb/state/lists/*_Packages* | \ cut -d " " -f 2 > pkg-lists/kernel-module-udebs # Add any local kernel modules to the list. find localudebs/*-modules-2.6.7-5-amd64-generic-di_*.udeb -printf '%f\n' | sed 's/_.*//' >> pkg-lists/kernel-module-udebs find: localudebs/*-modules-2.6.7-5-amd64-generic-di_*.udeb: No such file or directory dh_testroot : : Reading Package Lists... Done Building Dependency Tree... Done libacl1 is already the newest version. adduser is already the newest version. apt is already the newest version. at is already the newest version. libattr1 is already the newest version. base-files is already the newest version. base-passwd is already the newest version. bash is already the newest version. bc is already the newest version. Package dc is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package dc has no installation candidate make[2]: *** [stamps/get_udebs-monolithic_2.6-stamp] Error 100 make[1]: *** [_build] Error 2 make: *** [build_monolithic_2.6] Error 2 Could somebody please document the sources.list used to build the images on http://debian-amd64.alioth.debian.org/debian-installer/ ? Many thanx in advance Harri
