Re: Mirorring Debian AMD 64 bit version

2004-11-25 Thread A. P. Kennedy
> "Goswin" == Goswin von Brederlow <[EMAIL PROTECTED]> writes:

 >> http://debian-amd64.alioth.debian.org/gcc-3.4/

 Goswin> Sid but with gcc-3.4 compiled. We wanted to see how well
 Goswin> gcc-3.4 would work since gcc-3.3 did have serious issues but
 Goswin> they have been resolved by now. Personaly I don't see a point
 Goswin> for it anymore but it is still used and maintained by some.

So we should switch back to the gcc-3.3 repository?

Thanks for the info.

Alan




Re: Cool N' Quiet

2004-11-25 Thread Nick
root @ Gatsu # modprobe powernow-k8
FATAL: Error inserting powernow_k8 
(/lib/modules/2.6.7-6-amd64-k8/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko):
 No such device

This might be what I've been seeing on my 32 bit install on my Athlon64 system. 
Below are extracts from some emails I've exchanged with [EMAIL PROTECTED]

So it seems that, for at least our cases, the fix is in 2.6.10 (2.6.9 too?). 
But Sarge won't be seeing this unless someone makes a backport to Sarge's 
kernel.

Nick

//

I was just reading your post at
http://lists.debian.org/debian-amd64/2004/09/msg00336.html

I'm currently using an MSI K8T Neo-FIS2R motherboard with an Athlon 64 3200+ 
processor and am using the Debian kernel image 2.6.8-1-k7. When I modprobe 
powernow_k8, I get

"""
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09b)
powernow-k8: BIOS error: numpst must be 1
"""

which seems to match what you were getting (powernow_k7 says it's not suitable 
for my cpu).

//
(A bit from his reply)

> I had to hack the kernel source for that.
> in arch/i386/kernel/cpu/cpufreq/powernow-k8.c comment line 639 out:
> 
>   return -ENODEV;
> 
> That will make the detection not stop, but continue anyway.

//

http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.10-rc1


<[EMAIL PROTECTED]>
[CPUFREQ] Work around AMD64 2nd identical PST errata

AMD recently errata'd the definition of the PSB/PST for recent Athlon 
64 and Opteron parts.  The errata
allows for a second, identical PST for those parts.
The current powernow-k8 driver will not work in PST/PSB mode on those 
parts because it requires 
there be 1 and only 1 PST.

From: Mark Langsdorf
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>




Re: Undocumented changes to Debian source packages

2004-11-25 Thread Goswin von Brederlow
Bill Allombert <[EMAIL PROTECTED]> writes:

> Hello debian-amd64,
>
> I wanted to check whether my packages worked on amd64 and after much
> puzzling because I could not rebuild packages available on alioth.
> I finally get across the following discrepancy between Debian source
> package and source packages available on debian-amd64.alioth.debian.org:

Here is our scapegoat (from the wanna-build db):
unstable main amd64 pari 2.1.5-5 broken 2004-06-15.10:45:18 Andreas Jochens 
<[EMAIL PROTECTED]> 

The package has been flaged as being broken in wanna-build for month
now.

A good overview of the buildd status for your package is available
from:

http://people.debian.org/~igloo/status.php?packages=pari&arches=

That there actualy is a deb in the pure64 repository without an
incremented version and without patch in the BTS is regrettable but an
oversight from one of the earlier build cycles. We did rebuild all of
sid when we changed the archive software and when alioth destroyed our
database but this deb must have remained across the rebuilds.


Regrettably alioth is always overloaded and running a consistency
check over the full archive is very time consuming and would probably
create a lot of screaming svn users. Luckily it seems that alioth will
move to a new system soon and amd64 stay on the old one on its
own. Once that happens we would be free to run such tests regularly.


> Here a diff /in extenso/ of pari_2.1.5-5.diff.gz from the Debian mirrors
> and the one available at
> 
>
> %zdiff -u pari_2.1.5-5.diff.gz  pari_2.1.5-5.diff.gz.pure64
> --- -   Thu Nov 25 17:58:43 2004
> +++ /tmp/pari_21.5-5.diff.gz.pure64.12076   Thu Nov 25 17:58:43 2004
> @@ -587,7 +587,7 @@
>  +  test   -f pic-lib || $(MAKE) -f debian/rules build-nonpic-lib
>  +  $(MAKE) gp
>  +ifeq (,$(findstring notest,$(DEB_BUILD_OPTIONS)))
> -+  $(MAKE) dobench
> ++# $(MAKE) dobench
>  +endif
>  +  touch build-arch-stamp
>  +
>
> I am not terribly happy about that. Whoever made that change should at
> least add a comment or a changelog entry, etc. explaining what is the
> problem and how the patch fix it. Bumping the version and contacting me
> would be a plus.

We usualy do this, using 2.1.5-5.0.0.1.pure64 or 2.1.5-5.0.0.amd64.1
or similar as well as sending the patch to the BTS. Might have been
one of the earlier packages Andreas did build.

> Since I cannot know who made that change, I post here my comment on that
> patch:

You could have looked at the changes file (in the same subdir) to see:

Maintainer: Andreas Jochens <[EMAIL PROTECTED]>

as well as the gpg signature on it. Blame him. :)

> This patch is ineffective: it only hides the fact that pari-gp is broken
> on that platform by disabling the test-suite 
>
> I am not terribly happy about that either. I don't think disabling
> test-suites to build more packages is the way to go.
>
> I plan to write a proper patch to really solve this issue.
> (some int* is incorrectly used as a long*).  However, have I been
> notified sooner the fix would probably already in the archive.

Strange that this doesn't show up on the other 64bit
architectures.

We are looking forward to a fix.

> Anyway, good luck to the Debian amd64 port effort.
>
> Cheers,
> -- 
> Bill. <[EMAIL PROTECTED]>
>
> Imagine a large red swirl here. 

MfG
Goswin




Re: openoffice in chroot

2004-11-25 Thread Phil Warrick
Hi Alex,
Could you send all the details of what you did to get running?  I agree 
that there are holes in the HOWTO (see my related thread).

Thanks,
Phil



Undocumented changes to Debian source packages

2004-11-25 Thread Bill Allombert
Hello debian-amd64,

I wanted to check whether my packages worked on amd64 and after much
puzzling because I could not rebuild packages available on alioth.
I finally get across the following discrepancy between Debian source
package and source packages available on debian-amd64.alioth.debian.org:

Here a diff /in extenso/ of pari_2.1.5-5.diff.gz from the Debian mirrors
and the one available at


%zdiff -u pari_2.1.5-5.diff.gz  pari_2.1.5-5.diff.gz.pure64
--- -   Thu Nov 25 17:58:43 2004
+++ /tmp/pari_21.5-5.diff.gz.pure64.12076   Thu Nov 25 17:58:43 2004
@@ -587,7 +587,7 @@
 +  test   -f pic-lib || $(MAKE) -f debian/rules build-nonpic-lib
 +  $(MAKE) gp
 +ifeq (,$(findstring notest,$(DEB_BUILD_OPTIONS)))
-+  $(MAKE) dobench
++# $(MAKE) dobench
 +endif
 +  touch build-arch-stamp
 +

I am not terribly happy about that. Whoever made that change should at
least add a comment or a changelog entry, etc. explaining what is the
problem and how the patch fix it. Bumping the version and contacting me
would be a plus.

Since I cannot know who made that change, I post here my comment on that
patch:

This patch is ineffective: it only hides the fact that pari-gp is broken
on that platform by disabling the test-suite 

I am not terribly happy about that either. I don't think disabling
test-suites to build more packages is the way to go.

I plan to write a proper patch to really solve this issue.
(some int* is incorrectly used as a long*).  However, have I been
notified sooner the fix would probably already in the archive.

Anyway, good luck to the Debian amd64 port effort.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp41XJly3MMF.pgp
Description: PGP signature


K8 Mainboards Linux compatibility list

2004-11-25 Thread Abdullah Ramazanoglu
Hello,

Thank you for keeping such a list. Here is data for a motherboard 
missing in the list.

Mainboard : EP-8KDA3+ (Socket-754)
ATA   : amd74xx (2 channel ATA-IDE controller on nForce3 chipset)
ATA Raid  : None
Serial ATA: sata_nv  (2 channel SATA-IDE controller on nForce3 chipset)
sata_sil (onboard 4 channel SiI-3114 SATA controller)
SCSI  : None
Network   : forcedeth (onboard nForce 1000MBps thru Cicada 8201 Gb-Eth)
Sound : snd_intel8x0 (onboard 8 channel ALC-850 sound controller)


Notes:

1. Debian installer did not detect onboard Gb-Ethernet controller 
automatically, so I have used an add-on ethernet card to install it 
(over the Net). Nevertheless, once installed and updated to current 
Sid, it has started detecting onboard Ethernet. Now I removed the add 
on ethernet and I'm using onboard Gbit ethernet now.

2. I didn't hook up a speaker and test the sound, as I won't be using 
sound on this server machine. Nevertheless it seems to be working. 
(Detects, loads modules properly, no errors so far)

3. I also didn't test onboard SATA controllers ("sata_nv" of nForce and 
"sata_sil" of SiI-3114, but I gather that they work properly from 
others' experiences.


Other data about EP-8KDA3+ :

URL   : http://www.epox.com.tw/eng/products_content.php?ps=224
BIOS  : Award/Phoenix BIOS v6.0
Max FSB   : 800MHz
RAM Slots : 3 x DDR 400
Format: ATX
AGP Slot  : 8X
PCI Slots : 6 x 32-bits
I/O Ports : 1x PS/2 Mouse + 1x PS/2 Keyboard + 2x Serial + 1x Parallel
USB   : 4x USB 2.0 on back panel + 4x USB 2.0 ports on motherboard

Best regards,
-- 
Abdullah| aramazan@ |
Ramazanoglu | myrealbox |
| D.0.T cöm |__




mounting xfs on x86_64

2004-11-25 Thread Dennis Grevenstein
Hi,

Because of a hardware failure I upgraded my PC to an
Athlon64. I did a fresh install of Debian pure64
on a new SATA disk. It works pretty well so far.
The problem is that I have a lot of data on another
IDE disk formatted with xfs with i386 Linux.
I tried to mount the partition under x86_64 Linux, but it
only gives me an error about a bad superblock or so
(I don't remember exactly). The strange thing is that
I can boot my old i386 Linux installation and there
I can mount the partition without any problems.
Are there any known incompatibilities between
i386 and x86_64 xfs? I tried the current AMD64
kernel from the DFS CD and also compiled my own
with xfs support. It just doesn't work.
I am using 2.6.9 now.

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
T.S. Eliot




Re: Bug#282763: Installation report amd64 (gcc-3.4)

2004-11-25 Thread Goswin von Brederlow
Joey Hess <[EMAIL PROTECTED]> writes:

> Harald Dunkel wrote:
>> Joey Hess wrote:
>> >
>> >I thought EFI was only an ia64 thing. Strange. Could you send a tarball
>> >of /var/log/debian-installer/ from the installed system so I can try to
>> >see why it was doing EFI stuff?

I just see this now so maybe Harald already mentioned that there are
plans for amd64 systems with efi.

>> See attachment.
>
> From the d-i status file:
>
> Package: partman-efi
> Status: install ok unpacked
> Version: 7.0.0.1.amd64
> Depends: parted-udeb, partman
> Description: Add to partman support for EFI boot partitions
>
> I conclude that the unofficial amd64 archive is broken or someone is doing

It is only in the gcc-3.4 repository. The pure64 archive has
partman-efi in arch-excludes in accordance to the Sources file.

~/archive/gcc-3.4$ wb-cmd grep partman-efi
unstable main amd64 partman-efi 7.0.0.1.amd64 installed 2004-11-11.13:51:07 
Andreas Jochens <[EMAIL PROTECTED]> 

The .0.0.1.amd64 would denote a amd64 specific patch being applied,
most likely just adding amd64 to the Architecture. Questions as to why
he did this should go to Andreas.

> something strange putting this udeb in it. And what's up with the .amd64
> version numbering? Note that the current released version of this package is
> 6.

$ grep-dctrl -P partman-efi /mirror/debian/dists/sid/main/souce/Sources
Package: partman-efi
Binary: partman-efi
Version: 7
Maintainer: Debian Install System Team 
Build-Depends: debhelper (>= 4.2.0), po-debconf (>= 0.5.0)
Architecture: ia64
Standards-Version: 3.5.6
Format: 1.0
Directory: pool/main/p/partman-efi
Files:
 41bfe286fbedd95542673c3f086733b3 581 partman-efi_7.dsc
 9e3ed2a5c70025dcf11d6e399b604d81 24794 partman-efi_7.tar.gz
Uploaders: dann frazier <[EMAIL PROTECTED]>

You are mistaken it seems. 7 is the current sid version.

> -- 
> see shy jo

MfG
Goswin




Re: openoffice in chroot

2004-11-25 Thread Goswin von Brederlow
Alexandru Cabuz <[EMAIL PROTECTED]> writes:

> I set up a chroot last night following the instructions in the howto.
> By the way, that AMD64 howto needs some updating. There are some details
> that are not mentioned. Like when and how to run base-config to set up
> the chroot environment, and whatnot, and when and how one should run
> aptitude to install all the packages. The debootstrap just installs a
> base system. Also it's not clear if the proc and /tmp filesystems
> should be put in the fstab in the 64 system or in the chroot and it's
> not clear at what point int the boostrapping procedure exactly this
> mounting should be done. There
> are a couple of things where the howto does not specify where you're
> supposed to do it, inside or outside the chroot.
>
> I managed to install it though, though I ran aptitude and installed a
> bunch of stuff BEFORE I ran base-config, and while apt was installing
> packages I was constantly getting messages complaining about locale
> not being defined. My locale is supposed to be french.
>
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>LANGUAGE = "fr_FR:fr:en_GB:en",
>LC_ALL = "fr_FR",
>LANG = "[EMAIL PROTECTED]"
>are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
>
> Hundreds of times.
>
> Now when I try to run openoffice, the window appears, with french
> menus for just a fraction of a second, then it switches to english.
> And when I try to go to File New, to create a new document openoffice
> displays this to the console and then hangs.
>
> I18N: Operating system doesn't support locale ""
>
> Maybe it's because it was installed before the locale was set up for
> the chroot so it didn't know how to configure itself... or something.
>
> So what is supposed to be the correct sequence in order to set up a
> 386 chroot correctly, and is there a way to get openoffice running
> now, without reinstalling the whole chroot?

dpkg-reconfigure locales inside the chroot and make sure french
locales are generated. If OO then still  misbehaves this is a bug in
OO and should be reported.

After reporting it try "apt-get install --reinstall ".

>
> Oh, btw, mozilla works, but not the flash plugin (inside the chroot).
>
> Thanks
>
> Alex.

MfG
Goswin




Re: I need explanation on the design of debian-amd64.

2004-11-25 Thread Goswin von Brederlow
[EMAIL PROTECTED] writes:

> Hi!
>
> I would like to ask this:
>...
> Is there any way in wich I can have both kind of libraries in my system?,
> I mean, something like this:
>
> lib  : 32bits libraries.
> lib64: 64bits libraries.
>
> and have almost all of my system running 64bits binaries (except by:
> openoffice, doom3, mplayer with w32 codecs, you name it).

Pure64 is primarily made only for 64 bit. Any 32bit support comes as
an afterthought. Because of various reasons lib64 is a link to lib so
your idea won't work.

But there is no problem with your idea, just with the directory
names. You can use /emul/ia32-linux/lib (as the ia32-libs,
ia32-libs-dev and ia32-libs-openoffice.org packages already do). The
drawback of this method is that you can't just "apt-get install
foobar" to install a 32bit package.

> This way, I could have a true hybrid system, with some 32bits binaries and
> some 64bits binaries sharing the same filesystem and hardware devices,
> without the need of "duplicated" binaries.
>
> Please, somebody correct me if I'm geting things wrong.
>
> Thanks in advance for your help, and keep up the good work!
>
> Ildefonso.

MfG
Goswin




Re: /pure64 vs. /gcc-3.4

2004-11-25 Thread Goswin von Brederlow
Stefan Lüthje <[EMAIL PROTECTED]> writes:

> Hello,
>
> I read this list since last week. But my question is, which tree I should
> use.
> At the moment I have the /pure64. Make it sense to use the /gcc-3.4?
> If yes, what is the easiest way, to change the distribution.
>
> Best Regards
>
> Stefan Luethje
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Pure64 is what will enter sid after sarge and gcc-3.4 might be
discontinued at that point.

To change from pure64 to gcc-3.4 (or vice versa) you just have to
change your /etc/apt-sources.list. "apt-get -d --reinstall" apt
and all libraries it uses and then dpkg -i them. After that reinstall
every package you have installed.

Reason for the manual step is that C++ programs using the libstdc++
from 3.3 _and_ 3.4 at the same time will not work right. If you update
only apt without its libs (or vice versa) you will create this
situation and apt will probably segfault (it did for me).


Alternatively you can install gcc-3.4 directly (untested?) from D-I.

MfG
Goswin

PS: I recommend using pure64.




Re: Mirorring Debian AMD 64 bit version

2004-11-25 Thread Goswin von Brederlow
Leopold Palomo-Avellaneda <[EMAIL PROTECTED]> writes:

> Hi, yes please, could someone give a bit more information about that.
>
> I have looked the 
> http://debian-amd64.alioth.debian.org/archive-structure.txt

This file details plans for the near future and comments and
improvements to it are welcome. It will be implemented as spare time
permits.

> file, I also I have realized that there's also some directories as:
>
> http://debian-amd64.alioth.debian.org/openoffice.org/

Contains some 32 bit OO packages repackaged for amd64 as a
test. Probably outdated and useless by now but at one time they
worked.

> http://debian-amd64.alioth.debian.org/sarge/
> http://debian-amd64.alioth.debian.org/pure64/

The sarge and sid repository to be megred into what
archive-structure.txt describes.

> http://debian-amd64.alioth.debian.org/gcc-3.4/

Sid but with gcc-3.4 compiled. We wanted to see how well gcc-3.4 would
work since gcc-3.3 did have serious issues but they have been resolved
by now. Personaly I don't see a point for it anymore but it is still
used and maintained by some.

> http://debian-amd64.alioth.debian.org/debian/

Part of archive-structure.txt.

> and there's several mirrors and some has partial, so, I think that all is bit 
> complicated and not clear.
>
> Please, it's posible to make some information about that? 
> We are a LUG that has a server in Barcelona/Catalonia and we want to make a 
> public mirror of debian-amd64, and it would be useful for all.

Most mirrors only have the pure64/dists/sid repository (i.e. unstable
amd64). This is currently the most complete and functional one. The
intention of the plans i archive-structure.txt is to reduce the
duplicate files currently existing in sarge and pure64 and the
official debian archive. People that already have a debian mirror
would only mirror the add ons for amd64.

> Thank's in advance,
>
> Best regards,
> Leo

MfG
Goswin

> A Dimecres 24 Novembre 2004 15:19, Nils Valentin va escriure:
>> Hi Debian fans,
>>
>> If anybody from the Alioth team is reading this by chance (or anybody
>> else),
>>
>> I would like to mirror the debian packages for the AMD 64 bit distribution.
>> Which server of the 8 known should I use ?
>>
>> My mirror will be based in Tokyo / Japan, so I hope thats a valuable
>> contribution saving you guys some network bandwith ;-).
>>
>> Please be so kind and get back to me.
>>
>> --
>> kind regards
>>
>> Nils Valentin
>> Tokyo/Japan
>> valentin_nils(at)be-known-online.com
>> http://www.be-known-online.com/mysql/
>
>
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

On bach the following mirror script is running to create its mirror
(replace goswin-guest with your alioth login or another mirror or
method) [bach porvides annonymous rsync access]:

---] mirror.sh [--
#!/bin/sh

cd /org/ftp.root/

exec > mirror.log

[ -e UPDATE-IN-PROGRESS ] && exit 0
touch UPDATE-IN-PROGRESS

# pure64 repository
debmirror -v -p --postcleanup --source -h [EMAIL PROTECTED] -e rsync -r 
archive/pure64/ -d sid -s main,main/debian-installer,contrib,non-free -a amd64 
--ignore="^dists/sid/main/debian-installer" --ignore 
"^dists/sid/main/installer-amd64" --ignore "^dists/sarge" --ignore 
"^dists/testing" --ignore "^dists/unstable" --ignore "^patches" --ignore 
"^buildd-logs" /org/ftp.root/pure64

# gcc-3.4 repository
debmirror -v -p --postcleanup --source -h [EMAIL PROTECTED] -e rsync -r 
archive/gcc-3.4/ -d sid -s main,main/debian-installer,contrib,non-free -a amd64 
/org/ftp.root/gcc-3.4

# some extras debmirror won't pick up
for DIR in biarch icons install-images multiarch debian-installer kernels tools 
pure64/dists/sid/main/installer-amd64; do
  rsync -avHP --delete [EMAIL PROTECTED]:archive/$DIR/. /org/ftp.root/$DIR/.
done

touch MIRROR.STAMP
rm UPDATE-IN-PROGRESS