1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#264403: rpvm: FTBFS m68k: /usr/lib/pvm3/conf/LINUXR68R.def: No such

    From Dirk Eddelbuettel@1:229/2 to Goswin Brederlow on Mon Aug 16 04:30:10 2004
    From: [email protected]

    Just back from a short and quick vacation, sorry for the late response...

    On Sun, Aug 08, 2004 at 08:02:05PM +0200, Goswin Brederlow wrote:
    Package: rpvm
    Severity: serious
    Justification: no longer builds from source

    Hi,

    rpvm FTBFS with "/usr/lib/pvm3/conf/LINUXR68R.def: No such file or directory", see attache dlogs.

    Ack -- but from a casual look it seems like the pvm package may be at fault. Any idea or comment, Steinar?

    Dirk


    MfG
    Goswin

    -- System Information:
    Debian Release: testing/unstable
    APT prefers unstable
    APT policy: (500, 'unstable')
    Architecture: m68k
    Kernel: Linux 2.2.10
    Locale: LANG=C, LC_CTYPE=de_DE

    Reading Package Lists...
    Building Dependency Tree...
    Need to get 63.4kB of source archives.
    Get:1 ftp://dual sid/main rpvm 0.6.2-1 (dsc) [596B]
    Get:2 ftp://dual sid/main rpvm 0.6.2-1 (tar) [61.0kB]
    Get:3 ftp://dual sid/main rpvm 0.6.2-1 (diff) [1741B]
    dpkg-source: extracting rpvm in rpvm-0.6.2
    Fetched 63.4kB in 3s (18.5kB/s)
    Reading Package Lists...
    Building Dependency Tree...
    The following NEW packages will be installed:
    cdbs f2c g77 g77-3.3 lapack3 lapack3-dev libbz2-1.0 libbz2-dev libg2c0
    libg2c0-dev libice6 libjpeg62 libjpeg62-dev libncurses5-dev libpcre3-dev
    libpng12-0 libpng12-dev libpvm3 libreadline4 libreadline4-dev libsm6 libx11-6
    pvm pvm-dev r-base-core r-base-dev refblas3 refblas3-dev tcl8.4 tk8.4
    type-handling xfree86-common xlibs-data zlib-bin zlib1g-dev
    0 upgraded, 35 newly installed, 0 to remove and 11 not upgraded.
    Need to get 577kB/19.4MB of archives.
    After unpacking 67.4MB of additional disk space will be used.
    Get:1 http://ftp.de.debian.org sid/main libpvm3 3.4.2-11 [67.7kB]
    Get:2 http://ftp.de.debian.org sid/main pvm 3.4.2-11 [182kB]
    Get:3 http://ftp.de.debian.org sid/main pvm-dev 3.4.2-11 [327kB] Preconfiguring packages ...
    Fetched 577kB in 1m8s (8392B/s)
    Selecting previously deselected package libbz2-1.0.
    (Reading database ... 9786 files and directories currently installed.) Unpacking libbz2-1.0 (from .../libbz2-1.0_1.0.2-1_m68k.deb) ...
    Selecting previously deselected package libreadline4.
    Unpacking libreadline4 (from .../libreadline4_4.3-11_m68k.deb) ...
    Selecting previously deselected package cdbs.
    Unpacking cdbs (from .../archives/cdbs_0.4.22-1_all.deb) ...
    Selecting previously deselected package f2c.
    Unpacking f2c (from .../f2c_20020621-2_m68k.deb) ...
    Selecting previously deselected package libg2c0.
    Unpacking libg2c0 (from .../libg2c0_1%3a3.3.4-7_m68k.deb) ...
    Selecting previously deselected package libg2c0-dev.
    Unpacking libg2c0-dev (from .../libg2c0-dev_1%3a3.3.4-7_m68k.deb) ... Selecting previously deselected package g77-3.3.
    Unpacking g77-3.3 (from .../g77-3.3_1%3a3.3.4-7_m68k.deb) ...
    Selecting previously deselected package g77.
    Unpacking g77 (from .../g77_4%3a3.3.4-2_m68k.deb) ...
    Selecting previously deselected package refblas3.
    Unpacking refblas3 (from .../refblas3_1.2-6_m68k.deb) ...
    Selecting previously deselected package lapack3.
    Unpacking lapack3 (from .../lapack3_3.0.20000531a-3_m68k.deb) ...
    Selecting previously deselected package refblas3-dev.
    Unpacking refblas3-dev (from .../refblas3-dev_1.2-6_m68k.deb) ...
    Selecting previously deselected package lapack3-dev.
    Unpacking lapack3-dev (from .../lapack3-dev_3.0.20000531a-3_m68k.deb) ... Selecting previously deselected package libbz2-dev.
    Unpacking libbz2-dev (from .../libbz2-dev_1.0.2-1_m68k.deb) ...
    Selecting previously deselected package libice6.
    Unpacking libice6 (from .../libice6_4.3.0.dfsg.1-6_m68k.deb) ...
    Selecting previously deselected package libjpeg62.
    Unpacking libjpeg62 (from .../libjpeg62_6b-9_m68k.deb) ...
    Selecting previously deselected package libjpeg62-dev.
    Unpacking libjpeg62-dev (from .../libjpeg62-dev_6b-9_m68k.deb) ...
    Selecting previously deselected package libncurses5-dev.
    Unpacking libncurses5-dev (from .../libncurses5-dev_5.4-4_m68k.deb) ... Selecting previously deselected package libpcre3-dev.
    Unpacking libpcre3-dev (from .../libpcre3-dev_4.5-1.1_m68k.deb) ...
    Selecting previously deselected package libpng12-0.
    Unpacking libpng12-0 (from .../libpng12-0_1.2.5.0-7_m68k.deb) ...
    Selecting previously deselected package zlib1g-dev.
    Unpacking zlib1g-dev (from .../zlib1g-dev_1%3a1.2.1.1-5_m68k.deb) ... Selecting previously deselected package libpng12-dev.
    Unpacking libpng12-dev (from .../libpng12-dev_1.2.5.0-7_m68k.deb) ... Selecting previously deselected package libreadline4-dev.
    Unpacking libreadline4-dev (from .../libreadline4-dev_4.3-11_m68k.deb) ... Selecting previously deselected package libsm6.
    Unpacking libsm6 (from .../libsm6_4.3.0.dfsg.1-6_m68k.deb) ...
    Selecting previously deselected package xfree86-common.
    Unpacking xfree86-common (from .../xfree86-common_4.3.0.dfsg.1-6_all.deb) ... Selecting previously deselected package xlibs-data.
    Unpacking xlibs-data (from .../xlibs-data_4.3.0.dfsg.1-6_all.deb) ... Selecting previously deselected package libx11-6.
    Unpacking libx11-6 (from .../libx11-6_4.3.0.dfsg.1-6_m68k.deb) ...
    Selecting previously deselected package zlib-bin.
    Unpacking zlib-bin (from .../zlib-bin_1%3a1.2.1.1-5_m68k.deb) ...
    Selecting previously deselected package tcl8.4.
    Unpacking tcl8.4 (from .../tcl8.4_8.4.6-1_m68k.deb) ...
    Selecting previously deselected package tk8.4.
    Unpacking tk8.4 (from .../tk8.4_8.4.6-1_m68k.deb) ...
    Selecting previously deselected package r-base-core.
    Unpacking r-base-core (from .../r-base-core_1.9.1-2_m68k.deb) ...
    Selecting previously deselected package type-handling.
    Unpacking type-handling (from .../type-handling_0.2.1_m68k.deb) ...
    Selecting previously deselected package r-base-dev.
    Unpacking r-base-dev (from .../r-base-dev_1.9.1-2_all.deb) ...
    Selecting previously deselected package libpvm3.
    Unpacking libpvm3 (from .../libpvm3_3.4.2-11_m68k.deb) ...
    Selecting previously deselected package pvm.
    Unpacking pvm (from .../archives/pvm_3.4.2-11_m68k.deb) ...
    Selecting previously deselected package pvm-dev.

    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Tue Aug 17 00:10:08 2004
    From: [email protected]

    On Sun, Aug 15, 2004 at 09:08:19PM -0500, Dirk Eddelbuettel wrote:
    Just back from a short and quick vacation, sorry for the late response...

    Ditto.

    rpvm FTBFS with "/usr/lib/pvm3/conf/LINUXR68R.def: No such file or
    directory", see attache dlogs.
    Ack -- but from a casual look it seems like the pvm package may be at fault. Any idea or comment, Steinar?

    There is no such file in upstream, AFAICS -- what would R68R be anyhow?
    (There is a LINUXM68K.def, which I'd guess would be the right file to look for.)

    BTW, for both this and the other rpvm-related bug: I'm quite new as PVM maintainer; I hijacked the package some time ago and fixed the worst bugs,
    but it rarely gives me problems so I'm not really into all the packaging details yet :-)

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXR68R

    This seems rather odd... What does "/usr/lib/pvm3/lib/pvmgetarch" return?
    How about "uname -m"?

    BTW, how did rpvm 0.6.1-2 get into testing with two FTBFS bugs, at least
    one of them serious? :-)

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Tue Aug 17 00:30:14 2004
    From: [email protected]

    On Mon, Aug 16, 2004 at 11:38:21PM +0200, Steinar H. Gunderson wrote:
    On Sun, Aug 15, 2004 at 09:08:19PM -0500, Dirk Eddelbuettel wrote:
    Just back from a short and quick vacation, sorry for the late response...

    Ditto.

    rpvm FTBFS with "/usr/lib/pvm3/conf/LINUXR68R.def: No such file or
    directory", see attache dlogs.
    Ack -- but from a casual look it seems like the pvm package may be at fault.
    Any idea or comment, Steinar?

    There is no such file in upstream, AFAICS -- what would R68R be anyhow? (There is a LINUXM68K.def, which I'd guess would be the right file to look for.)

    I'm mystified too. Builds fine on i386, not sure anybody ever tried it
    anywhere else ...

    BTW, for both this and the other rpvm-related bug: I'm quite new as PVM maintainer; I hijacked the package some time ago and fixed the worst bugs, but it rarely gives me problems so I'm not really into all the packaging details yet :-)

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXR68R

    This seems rather odd... What does "/usr/lib/pvm3/lib/pvmgetarch" return?
    How about "uname -m"?

    We need a m68k person to help us here. I'm enlisting Chris Steigies who has often helped me in the past :)

    BTW, how did rpvm 0.6.1-2 get into testing with two FTBFS bugs, at least
    one of them serious? :-)

    Well it does build on i386; building on many other arches is not a
    requirement.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Tue Aug 17 01:00:17 2004
    From: [email protected]

    On Mon, Aug 16, 2004 at 05:14:25PM -0500, Dirk Eddelbuettel wrote:
    BTW, how did rpvm 0.6.1-2 get into testing with two FTBFS bugs, at least
    one of them serious? :-)
    Well it does build on i386; building on many other arches is not a requirement.

    If the package hasn't been built in that package before, FTBFS bugs should be important, not serious.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Tue Aug 17 04:00:10 2004
    From: [email protected]

    On Tue, Aug 17, 2004 at 12:40:42AM +0200, Steinar H. Gunderson wrote:
    On Mon, Aug 16, 2004 at 05:14:25PM -0500, Dirk Eddelbuettel wrote:
    BTW, how did rpvm 0.6.1-2 get into testing with two FTBFS bugs, at least >> one of them serious? :-)
    Well it does build on i386; building on many other arches is not a requirement.

    If the package hasn't been built in that package before, FTBFS bugs should be important, not serious.

    Ah, I see -- didn't know that. That would apply here.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Christian T. Steigies@1:229/2 to Dirk Eddelbuettel on Tue Aug 17 10:20:12 2004
    From: [email protected]

    On Mon, Aug 16, 2004 at 05:14:25PM -0500, Dirk Eddelbuettel wrote:
    On Mon, Aug 16, 2004 at 11:38:21PM +0200, Steinar H. Gunderson wrote:
    On Sun, Aug 15, 2004 at 09:08:19PM -0500, Dirk Eddelbuettel wrote:
    Just back from a short and quick vacation, sorry for the late response...

    Ditto.

    rpvm FTBFS with "/usr/lib/pvm3/conf/LINUXR68R.def: No such file or
    directory", see attache dlogs.
    Ack -- but from a casual look it seems like the pvm package may be at fault.
    Any idea or comment, Steinar?

    There is no such file in upstream, AFAICS -- what would R68R be anyhow? (There is a LINUXM68K.def, which I'd guess would be the right file to look for.)

    I'm mystified too. Builds fine on i386, not sure anybody ever tried it anywhere else ...

    It seems to fail on most arches wit a similar problem:

    ** libs
    make[1]: Entering directory /build/buildd/rpvm-0.6.2/src'
    Makevars:3: /usr/lib/pvm3/conf/LINUXRRR.def: No such file or directory
    make[1]: *** No rule to make target /usr/lib/pvm3/conf/LINUXRRR.def'. Stop.

    http://buildd.debian.org/build.php?arch=&pkg=rpvm

    BTW, for both this and the other rpvm-related bug: I'm quite new as PVM maintainer; I hijacked the package some time ago and fixed the worst bugs, but it rarely gives me problems so I'm not really into all the packaging details yet :-)

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXR68R

    This seems rather odd...

    I would say you have an overflow of "R"'s in your code... they kill
    everything but the numbers.

    What does "/usr/lib/pvm3/lib/pvmgetarch" return?
    How about "uname -m"?

    On woody:
    Setting up libpvm3 (3.4.2-8) ...

    Setting up pvm (3.4.2-8) ...

    Setting up pvm-dev (3.4.2-8) ...

    buildd@aahz:~>uname -m
    m68k
    buildd@aahz:~>/usr/lib/pvm3/lib/pvmgetarch
    LINUXM68K

    On unstable:
    Setting up libpvm3 (3.4.2-11) ...

    Setting up pvm (3.4.2-11) ...

    Setting up pvm-dev (3.4.2-11) ...
    root@aahz:/# uname -m
    m68k
    root@aahz:/# /usr/lib/pvm3/lib/pvmgetarch
    LINUXM68K

    Where R the RRRs???

    Christian


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Christian T. Steigies on Wed Aug 18 04:40:08 2004
    XPost: linux.debian.maint.boot
    From: [email protected]

    On Tue, Aug 17, 2004 at 01:54:34AM -0600, Christian T. Steigies wrote:
    I'm mystified too. Builds fine on i386, not sure anybody ever tried it anywhere else ...

    It seems to fail on most arches wit a similar problem:

    Yes (see below).

    ** libs
    make[1]: Entering directory /build/buildd/rpvm-0.6.2/src'
    Makevars:3: /usr/lib/pvm3/conf/LINUXRRR.def: No such file or directory make[1]: *** No rule to make target /usr/lib/pvm3/conf/LINUXRRR.def'. Stop.

    http://buildd.debian.org/build.php?arch=&pkg=rpvm

    BTW, for both this and the other rpvm-related bug: I'm quite new as PVM maintainer; I hijacked the package some time ago and fixed the worst bugs,
    but it rarely gives me problems so I'm not really into all the packaging details yet :-)

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXR68R

    This seems rather odd...

    I would say you have an overflow of "R"'s in your code... they kill everything but the numbers.

    Yes (see below).

    What does "/usr/lib/pvm3/lib/pvmgetarch" return?
    How about "uname -m"?

    On woody:
    Setting up libpvm3 (3.4.2-8) ...

    Setting up pvm (3.4.2-8) ...

    Setting up pvm-dev (3.4.2-8) ...

    buildd@aahz:~>uname -m
    m68k
    buildd@aahz:~>/usr/lib/pvm3/lib/pvmgetarch
    LINUXM68K

    On unstable:
    Setting up libpvm3 (3.4.2-11) ...

    Setting up pvm (3.4.2-11) ...

    Setting up pvm-dev (3.4.2-11) ...
    root@aahz:/# uname -m
    m68k
    root@aahz:/# /usr/lib/pvm3/lib/pvmgetarch
    LINUXM68K

    Where R the RRRs???

    That really is the problem. And I still think the two FTBFS, which I merged
    and which Steinar unmerged, are the same and should be merged again.

    Witness the following:

    1. rpvm has a very simple and standard structure confirming to the layout
    of the over 400 R packages. In particular, in rpvm-0.6.2/src/, the
    following -- and really simple -- Makevars.in is included:

    edd@chibud:~/src/debian/CRAN/rpvm-0.6.2/src> cat Makevars.in
    # -*- Makefile -*- vim : ft = make

    include @PVM_ROOT@/conf/@[email protected]

    # PVM library and header files
    PKG_CPPFLAGS = @PKG_CPPFLAGS@ -I$(PVM_ROOT)/include
    PKK_CFLAGS = $(ARCHCFLAGS)
    PKG_LIBS = @PKG_LIBS@ $(ARCHLIB)
    edd@chibud:~/src/debian/CRAN/rpvm-0.6.2/src>

    2. Notice how it wants @[email protected]. The pvm-dev package in testing
    ships these:

    edd@chibud:~/src/debian/CRAN/rpvm-0.6.2/src> ls /usr/lib/pvm3/conf/*def
    /usr/lib/pvm3/conf/LINUX.def /usr/lib/pvm3/conf/LINUXM68K.def
    /usr/lib/pvm3/conf/LINUXALPHA.def /usr/lib/pvm3/conf/LINUXMIPS.def
    /usr/lib/pvm3/conf/LINUXAMD64.def /usr/lib/pvm3/conf/LINUXPPC.def
    /usr/lib/pvm3/conf/LINUXARM.def /usr/lib/pvm3/conf/LINUXS390.def
    /usr/lib/pvm3/conf/LINUXHPPA.def /usr/lib/pvm3/conf/LINUXSPARC.def
    /usr/lib/pvm3/conf/LINUXIA64.def
    edd@chibud:~/src/debian/CRAN/rpvm-0.6.2/src>

    Should be fine for all of us, you'd think.

    3. Now, configure.in and configure determine @PVM_ARCH@ in a very simple
    way:

    if test -z "${PVM_ARCH}"; then
    PVM_ARCH=${PVM_ROOT}/lib/pvmgetarchfi
    fi

    I.e., if unset, the output of pvmgetarch is used [ and PVM_ROOT is set
    to /usr/lib/pvm3 if that directory exists -- explicit Debian test ]

    4. This brings us back to Christian's comment above. It looks like (cf.
    http://buildd.debian.org/build.php?pkg=rpvm ) that 6 out of 7 autobuild
    attempt failed, and they all seem to have this problem (here using sparc):

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXRRRRR
    [...]
    make[1]: Entering directory /build/buildd/rpvm-0.6.2/src'
    Makevars:3: /usr/lib/pvm3/conf/LINUXRRRRR.def: No such file or directory
    make[1]: *** No rule to make target /usr/lib/pvm3/conf/LINUXRRRRR.def'. Stop.

    Similarly on ia64

    Try to guess if pvm is installed somewhere ...
    Found pvm: /usr/lib/pvm3
    PVM_ROOT is /usr/lib/pvm3
    PVM_ARCH is LINUXRR64
    [...]
    make[1]: Entering directory /build/buildd/rpvm-0.6.2/src'
    Makevars:3: /usr/lib/pvm3/conf/LINUXRR64.def: No such file or directory
    make[1]: *** No rule to make target /usr/lib/pvm3/conf/LINUXRR64.def'. Stop.

    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]` ;;
    [...]

    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.

    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



    --

    [continued in next message]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Goswin von Brederlow@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 07:40:07 2004
    From: [email protected]

    Dirk Eddelbuettel <[email protected]> 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


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Goswin von Brederlow on Wed Aug 18 12:50:07 2004
    From: [email protected]

    [I'm only Cc-ing 265597 to tell people to stop Cc-ing the wrong bug now :-P]

    On Wed, Aug 18, 2004 at 07:25:19AM +0200, Goswin von Brederlow wrote:
    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.

    What do you mean by "$ht"? I might be stupid now, but I really can't find any such variable in debian/rules.

    Anyhow, this is Not A Bug(TM) for sarge.

    bash$ touch m R; uname -m | tr [a-z] [A-Z]
    R68k

    Please add ''

    :-)

    I'll fix that right away for sarge.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 12:50:07 2004
    From: [email protected]

    On Tue, Aug 17, 2004 at 09:26:03PM -0500, Dirk Eddelbuettel wrote:
    Where R the RRRs???
    That really is the problem. And I still think the two FTBFS, which I merged and which Steinar unmerged, are the same and should be merged again.

    As Goswin pointed out by showing where the other bug is, we're talking two entirely different bugs here.

    Witness the following:

    [...]

    4. This brings us back to Christian's comment above. It looks like (cf.
    http://buildd.debian.org/build.php?pkg=rpvm ) that 6 out of 7 autobuild
    attempt failed, and they all seem to have this problem (here using sparc):>
    [...]

    I still fail to see how this is related to the problem with -fPIC and shared libraries at all. 265697 is a bug in pvm like Goswin pointed out; that still does not give us an answer as of how to fix 264493.

    On some platforms, _all_ code in a shared library _must_ be compiled with
    -fPIC. Static libraries aren't compiled with -fPIC. Clear enough? :-)
    Sure -- And that is exactly what is done as the -fPIC argument is stored in CFLAGS in /etc/R/Makeconf.

    No, that does _not_ change what the PVM static library code is built with.
    rpvm is trying to link to a static library (which you can't guarantee was compiled with -fPIC) in code for use in a shared library (where all code must be compiled with -fPIC); I cannot possibly see why this shouldn't be an rpvm bug.

    No, it is not; it will break with two .a files as well.
    I doubt that as rpvm works for non Debian systems where, from what you say, two .a are standard.

    Does it also work in arches like amd64 or m68k? Again, this sounds very much like the "works by accident" behavior we're seeing on i386 in Debian.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Goswin von Brederlow@1:229/2 to Steinar H. Gunderson on Wed Aug 18 13:30:11 2004
    From: [email protected]

    "Steinar H. Gunderson" <[email protected]> writes:

    [I'm only Cc-ing 265597 to tell people to stop Cc-ing the wrong bug now :-P]

    On Wed, Aug 18, 2004 at 07:25:19AM +0200, Goswin von Brederlow wrote:
    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.

    What do you mean by "$ht"? I might be stupid now, but I really can't find any such variable in debian/rules.

    The $ht used in the case statement. I have no clue how to do that but
    its neccessay.

    On i386 I get:
    % uname -m
    x86_64

    Anyhow, this is Not A Bug(TM) for sarge.

    Yes it is. A kernel-image-2.6.8-amd64 is in the works for i386. Since
    you need to upload a new version anyway check how to force the ARCH to
    the right thing.

    bash$ touch m R; uname -m | tr [a-z] [A-Z]
    R68k

    Please add ''

    :-)

    I'll fix that right away for sarge.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/

    MfG
    Goswin


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Wed Aug 18 14:00:16 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 12:15:29PM +0200, Steinar H. Gunderson wrote:
    [I'm only Cc-ing 265597 to tell people to stop Cc-ing the wrong bug now :-P]

    On Wed, Aug 18, 2004 at 07:25:19AM +0200, Goswin von Brederlow wrote:
    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.

    What do you mean by "$ht"? I might be stupid now, but I really can't find any such variable in debian/rules.

    Not debian/rules, but pvmgetarch.

    I.e. in your package.

    Anyhow, this is Not A Bug(TM) for sarge.

    bash$ touch m R; uname -m | tr [a-z] [A-Z]
    R68k

    Please add ''

    :-)

    I'll fix that right away for sarge.

    Thank you.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Wed Aug 18 14:20:08 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 01:12:09PM +0200, Steinar H. Gunderson wrote:
    On Wed, Aug 18, 2004 at 01:09:25PM +0200, Goswin von Brederlow wrote:
    Policy dictates that all shared libaries MUST be compiled WITH -fPIC
    and all static libraries MUST be compiled WITHOUT -fPIC. You can never
    link a static lib into a share one, NEVER.

    Yes, and thus rpvm _must_ check for .so, not .a.

    I think you are still focussing on the wrong issue.

    All configure ends up with is a request -lfoo -Lpath/to/foo. When there is
    a shared one, it is used. That is a feature, and doesn't need changing.

    What probably needs changing is your package; Goswin kindly pointed to
    Policy.

    And it is still the same bug: both problems are due to pvmgetarch returning the wrong info in the 'catch all' case. Protecting the args to tr(1) may
    fix that.

    Packages that build a static libarary to be linked into a shared one
    have to build a libfoo-pic package, e.g. libc6-pic.

    rpvm must use a libpvm-pic and pvm should provide such a thing.

    Or pvm could provide a shared libgpvm for etch, which is what I plan to do.

    Please do.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Goswin von Brederlow on Wed Aug 18 16:00:13 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 01:04:57PM +0200, Goswin von Brederlow wrote:
    The $ht used in the case statement. I have no clue how to do that but
    its neccessay.

    On i386 I get:
    % uname -m
    x86_64

    OK, so the simplest fix for sarge would probably be doing

    Linux,x86_64* ) ARCH=LINUX ;;

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 16:00:14 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 06:46:57AM -0500, Dirk Eddelbuettel wrote:
    Yes, and thus rpvm _must_ check for .so, not .a.

    I think you are still focussing on the wrong issue.

    All configure ends up with is a request -lfoo -Lpath/to/foo. When there is
    a shared one, it is used. That is a feature, and doesn't need changing.

    But when there is no shared one, the static one is used, which simply does
    not work; this is not pvm's fault. The rpvm configure script assumes that if there is a libfoo.a file, it can do "-lfoo" while making a shared library and it will work; that is _wrong_. It is a bug in rpvm. (Note: I'm not saying
    that rpvm is the only buggy package here :-) )

    What probably needs changing is your package; Goswin kindly pointed to Policy.

    Well, yes, a shared libgpvm should be put into place -- however, like I
    pointed out, I'm highly reluctant to adding this just before sarge, as it involves tweaking parts of the build system I'm not really familiar with. Perhaps we should ask an RM on this issue, if you want to have rpvm working
    for sarge?

    And it is still the same bug: both problems are due to pvmgetarch returning the wrong info in the 'catch all' case. Protecting the args to tr(1) may
    fix that.

    How on Earth would wrong pvmgetarch return value have _anything_ to do with rpvm checking for the wrong file?

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Wed Aug 18 16:40:17 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 03:40:27PM +0200, Steinar H. Gunderson wrote:
    On Wed, Aug 18, 2004 at 01:04:57PM +0200, Goswin von Brederlow wrote:
    The $ht used in the case statement. I have no clue how to do that but
    its neccessay.

    On i386 I get:
    % uname -m
    x86_64

    OK, so the simplest fix for sarge would probably be doing

    Linux,x86_64* ) ARCH=LINUX ;;

    Err, don't you then end up with the base case 'LINUX' when you'd want the
    amd case:

    edd@chibud:~/src/debian/R/R-1.9.1/debian> ls -1 /usr/lib/pvm3/conf/L*def /usr/lib/pvm3/conf/LINUX.def
    /usr/lib/pvm3/conf/LINUXALPHA.def
    /usr/lib/pvm3/conf/LINUXAMD64.def
    /usr/lib/pvm3/conf/LINUXARM.def
    /usr/lib/pvm3/conf/LINUXHPPA.def
    /usr/lib/pvm3/conf/LINUXIA64.def
    /usr/lib/pvm3/conf/LINUXM68K.def
    /usr/lib/pvm3/conf/LINUXMIPS.def
    /usr/lib/pvm3/conf/LINUXPPC.def
    /usr/lib/pvm3/conf/LINUXS390.def
    /usr/lib/pvm3/conf/LINUXSPARC.def
    edd@chibud:~/src/debian/R/R-1.9.1/debian>

    So if I were you I'd make that ARCH=LINUXAMD64

    And while you're add it, would make sense to nail the others ones down.

    Dirk


    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Wed Aug 18 16:50:07 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 03:36:46PM +0200, Steinar H. Gunderson wrote:
    On Wed, Aug 18, 2004 at 06:46:57AM -0500, Dirk Eddelbuettel wrote:
    Yes, and thus rpvm _must_ check for .so, not .a.

    I think you are still focussing on the wrong issue.

    All configure ends up with is a request -lfoo -Lpath/to/foo. When there is a shared one, it is used. That is a feature, and doesn't need changing.

    But when there is no shared one, the static one is used, which simply does not work; this is not pvm's fault. The rpvm configure script assumes that if

    Sure is pvm's fault: You are violating Policy by not providing a shared lib.

    Please provide a shared library.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 17:00:18 2004
    XPost: linux.debian.devel.release
    From: [email protected]

    [Cc-ing debian-release to reach an RM; please keep the discussion on the bug
    as I'm not subscribed to -release.]

    On Wed, Aug 18, 2004 at 09:21:34AM -0500, Dirk Eddelbuettel wrote:
    But when there is no shared one, the static one is used, which simply does >> not work; this is not pvm's fault. The rpvm configure script assumes that if
    Sure is pvm's fault: You are violating Policy by not providing a shared lib.

    *sigh* This is obviously hard. Let me summarize:

    - rpvm should NOT check for a static library if it cannot use a static
    library. This is a bug in rpvm upstream.
    - pvm should build a shared library for libgpvm3 as of Debian policy (but see
    below).

    Please provide a shared library.

    Would an RM please step in here and assist? To summarize: rpvm refuses to
    work with static PVM libraries on some (non-i386) platforms. (Due to an rpvm bug, it does not detect this at configure time; this works by accident on
    i386 and some other platforms but fails on others.) PVM upstream only
    provides static libraries; Debian PVM has provided a shared libpvm3 for ages but no shared libgpvm3. I am rather reluctant to hacking a shared libgpvm3
    into a build system I am not intimately familiar with before sarge (I have
    not maintained pvm all that long), even though lack of shared libraries is a policy violation (or at least so it seems), as this has obviously been OK
    with the world for ~3-4 years, and I don't want to possibly break pvm for sarge.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 16:50:08 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 09:19:24AM -0500, Dirk Eddelbuettel wrote:
    OK, so the simplest fix for sarge would probably be doing

    Linux,x86_64* ) ARCH=LINUX ;;
    Err, don't you then end up with the base case 'LINUX' when you'd want the
    amd case:

    I don't want the AMD case. AMD64 here is for 64-bit x86. LINUX is Linux/i386, which is what I want for sarge. (Current pvm in sarge/sid picks AMD64 when
    run on AMD64 in i386 mode, which is a bug, as Goswin points out.)

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Dirk Eddelbuettel@1:229/2 to Steinar H. Gunderson on Wed Aug 18 17:10:15 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 04:30:07PM +0200, Steinar H. Gunderson wrote:
    On Wed, Aug 18, 2004 at 09:19:24AM -0500, Dirk Eddelbuettel wrote:
    OK, so the simplest fix for sarge would probably be doing

    Linux,x86_64* ) ARCH=LINUX ;;
    Err, don't you then end up with the base case 'LINUX' when you'd want the amd case:

    I don't want the AMD case. AMD64 here is for 64-bit x86. LINUX is Linux/i386, which is what I want for sarge. (Current pvm in sarge/sid picks AMD64 when run on AMD64 in i386 mode, which is a bug, as Goswin points out.)

    Sorry, I missed that aspect and had concentrated on amd64 mode on amd64.
    They can of course be used with i386 binaries, in which case ARCH=LINUX is correct.

    But can you base that test on uname -m? If you make the suggested change,
    you will get the i386 case for 'amd64 binary on amd64 cpu' case too. So
    you'd trade one bug for another, wouldn't you?

    One solution would be to modify pvmgetarch at the top, test for /etc/debian_version, and then use the recommended tricks for host, arch, ... that dpkg-architecture gives you (see Policy). Doesn't that make more sense
    as you'd then get it right for every package linking against pvm, instead of reying on all of them doing the right thing?

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 17:30:12 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 09:52:24AM -0500, Dirk Eddelbuettel wrote:
    But can you base that test on uname -m? If you make the suggested change, you will get the i386 case for 'amd64 binary on amd64 cpu' case too. So
    you'd trade one bug for another, wouldn't you?

    Yes, except that "amd64 binary on amd64 cpu" is not a supported architecture for sarge, so that bug doesn't really matter. etch will require plenty of changes for multiarch anyhow, and we'll work out a better solution for then.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 19:20:10 2004
    XPost: linux.debian.devel.release
    From: [email protected]

    On Wed, Aug 18, 2004 at 10:02:21AM -0500, Dirk Eddelbuettel wrote:
    - rpvm should NOT check for a static library if it cannot use a static
    library. This is a bug in rpvm upstream.
    Nope: rpvm can only assume static libs, as the rest of the world uses only static libs. We are different, and can be different as __the combination of -Lpath/to/libfoo -lfoo inferred from static libs works for shared libs too__ provided there are working shared libs.

    But you cannot assume static libs imply working shared libs, which you obviously seem to do. You say "we can be different from upstream because
    X, but X is false, so your package is what breaks my package since X is
    false". Sorry, but that does not make sense. :-)

    Pvm is broken for sarge AFAICT. I'd expect your mix of shared and static to break with way more packages that just rpvm (which happens to rely on dyn.lib. loading to extend the functionality of GNU R at run-time).

    (Note that this is not _my_ mix of shared and static libs; this is for historical reasons from the previous maintainer. :-) )

    Shared and static library mix should not pose a problem for _any_
    well-behaved package (the availability of the libraries should be checked separately for different libraries _and_ for shared/static libraries as long
    as it actually matters which one to use), and as you can see, the pvm package has been working for ages without any problems caused by this. Moreover, the problem in question is not from the mix at all; it is simply because rpvm's configure script is broken, assuming that it can create a shared library linking against libpvm3 and libgpvm3 just because libpvm3.a and libgpvm3.a exist. (The fact that pvm probably breaks policy by not providing a shared library is really a different issue, and that is why I'm pulling in the debian-release; see below.)

    I don't see what wasting precious RM time gains us here, other than getting PVM completely blown out of sarge unless fixed.

    I want to

    a) verify that "libgpvm3 does not have a shared library" is indeed an RC bug. b) get that bug tagged sarge-ignore, as I see a stable pvm package in sarge
    as a lot more important than getting rpvm working on m68k/amd64.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Goswin von Brederlow@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 20:10:14 2004
    XPost: linux.debian.maint.boot
    From: [email protected]

    Dirk Eddelbuettel <[email protected]> writes:

    On Wed, Aug 18, 2004 at 12:15:29PM +0200, Steinar H. Gunderson wrote:
    [I'm only Cc-ing 265597 to tell people to stop Cc-ing the wrong bug now :-P] >>
    On Wed, Aug 18, 2004 at 07:25:19AM +0200, Goswin von Brederlow wrote:
    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.

    What do you mean by "$ht"? I might be stupid now, but I really can't find any
    such variable in debian/rules.

    Not debian/rules, but pvmgetarch.

    I.e. in your package.

    I mentioned debian/rules. The usual way for this kind of thing is to
    read in the right information from dpkg-architecture in debian/rules
    and then to pass that information along via "configure --host=....".

    Since I don't know pvm I can't say how that applies there but I feel
    its best to keep the debian specifics in debian/rules and not patch
    the pvmgetarch to use dpkg-architecture instead of uname.

    But its your choice how you do it.

    Anyhow, this is Not A Bug(TM) for sarge.

    bash$ touch m R; uname -m | tr [a-z] [A-Z]
    R68k

    Please add ''

    :-)

    I'll fix that right away for sarge.

    Thank you.

    Dirk

    --
    Those are my principles, and if you don't like them... well, I have others.
    -- Groucho Marx

    MfG
    Goswin


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Goswin von Brederlow on Wed Aug 18 22:40:07 2004
    From: [email protected]

    [Please stop Cc-ing 265597, it is unrelated]

    On Wed, Aug 18, 2004 at 07:54:13PM +0200, Goswin von Brederlow wrote:
    Since I don't know pvm I can't say how that applies there but I feel
    its best to keep the debian specifics in debian/rules and not patch
    the pvmgetarch to use dpkg-architecture instead of uname.

    What about "dpkg-architecture > lib/pvmgetarch"? :-) (OK, add some sed and parameters and stuff, but you get the idea.)

    Anyhow, that is unrelated to the bug for now; I'll work out something for
    etch.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Steinar H. Gunderson@1:229/2 to Dirk Eddelbuettel on Wed Aug 18 22:50:09 2004
    From: [email protected]

    On Wed, Aug 18, 2004 at 09:19:24AM -0500, Dirk Eddelbuettel wrote:
    OK, so the simplest fix for sarge would probably be doing

    Linux,x86_64* ) ARCH=LINUX ;;
    Err, don't you then end up with the base case 'LINUX' when you'd want the
    amd case:

    I _do_ _not_ _want_ the AMD case for AMD64 in i386 mode, and there is no
    "base case": LINUX is Linux/i386 just as much as LINUXM68K is Linux/m68k. Please check your facts before commenting: LINUXAMD64 compiles with -m64,
    which would make the package not run on an i386.

    /* Steinar */
    --
    Homepage: http://www.sesse.net/


    --
    To UNSUBSCRIBE, email to [email protected]
    with a subject of "unsubscribe". Trouble? Contact [email protected]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)