Bug#265597: Bug#264403: rpvm: FTBFS m68k: /usr/lib/pvm3/conf/LINUXR68R.def: No such file or directory
Dirk Eddelbuettel <edd@debian.org> writes:
> 5. Now, R uses the _exact_ same debian/rules files for about 40 packages in
> the archive. I have used it on another 400 auto-generated packages I
> have included in Quantian 0.5.9.3.
>
> I don't see why rpvm would need anything special. I also don't
> understand how the shell script pvmgetarch can get so confused.
> That said, for Linux it does the following:
>
> os="/bin/uname -s"
> ht="/bin/uname -m"
> ov="/bin/uname -v"
> [...]
>
> case "$os,$ht" in
> [...]
> Linux,i[3456]86 ) ARCH=LINUX ;;
> Linux,sparc64 ) ARCH=LINUXSPARC ;;
> Linux,parisc* ) ARCH=LINUXHPPA ;;
> Linux,arm* ) ARCH=LINUXARM ;;
> Linux,x86_64* ) ARCH=LINUXAMD64 ;;
> Linux,* ) ARCH=LINUX`uname -m | tr [a-z] [A-Z]` ;;
> [...]
The tests for amd64 is wrong. You are testing for the presence of an
amd64 cpu which doesn't mean that a 64bit amd64 linux is running. You
MUST override $ht from the rules file with the DEB_BUILD_GNU_CPU or
you get FTBFS errors on i386 on amd64 cpus.
> 6. From this we note
>
> a) that arm -- which built successfully -- is covered
> whereas none of the failed arches is (ia64, hppa, s390, powerpc,
> mipsel, sparc), and
>
> b) that the little tr(1) call may not be the most robust thing on Earth.
zsh% uname -m | tr [a-z] [A-Z]
zsh: no matches found: [a-z]
bash$ uname -m | tr [a-z] [A-Z]
M68K
bash$ touch m R; uname -m | tr [a-z] [A-Z]
R68k
Please add ''
> 7. So the question is: how to we fix this? The best place, I'd say, is
> pvmgetarch.
>
> 8. I am not seeing anything obvious. Any takers?
>
>
> Thanks for reading this far, Dirk
>
>
>
> --
> Those are my principles, and if you don't like them... well, I have others.
> -- Groucho Marx
MfG
Goswin
Reply to: