From: [email protected]

reassign 266837 pvm
thanks

On Thu, Aug 19, 2004 at 09:38:37PM +1000, Anibal Monsalve Salazar wrote:

Package: rpvm
Severity: serious
Version: 0.6.2-1

Please refer to the buildd log at the URL listed below.

http://buildd.debian.org/fetch.php?&pkg=rpvm&ver=0.6.2-1&arch=hppa&stamp=1090293622&file=log&as=raw

gcc -shared -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -lpvm3 -lgpvm3 -lreadline -L/usr/lib/R/bin -lR
/usr/bin/ld: /usr/lib/gcc-lib/hppa-linux/3.3.4/../../../libgpvm3.a(pvmgsu_core.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC

This is pvm's fault for not providing a shared library (which R needs to
create a shared library from this rpvm package to add pvm capabilities to R).

Dirk

Regards,

Anibal Monsalve Salazar
--
.''`. Debian GNU/Linux | Building 28C
: :' : Free Operating System | Monash University VIC 3800 Australia
`. `' http://debian.org/ | http://www-personal.monash.edu/~anibal
`-

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

On Thu, Aug 19, 2004 at 11:30:31PM +0200, Steinar H. Gunderson wrote:

severity 266837 wishlist
merge 266837 266762
thanks

On Thu, Aug 19, 2004 at 04:26:08PM -0500, Dirk Eddelbuettel wrote:

This is pvm's fault for not providing a shared library (which R needs to create a shared library from this rpvm package to add pvm capabilities to R).

Please see #266762 for any discussion on this.

Can you explain why a Policy violation (i.e. not providing shared libs for
a -dev package) is of "Severity: wishlist", esp. in the context of repeated FTBFS caused by it?

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

On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:

Please see #266762 for any discussion on this.

Can you explain why a Policy violation (i.e. not providing shared libs for
a -dev package) is of "Severity: wishlist"

Again, see #266762.

esp. in the context of repeated FTBFS caused by it?

To be honest, it is not pvm's problem that rpvm does not work with pure upstream pvm on non-i386.

Feel free to invoke the ctte if you feel this is wrong; note that this _will_ be fixed for etch, but not 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: [email protected]

On Thu, Aug 19, 2004 at 11:58:40PM +0200, Steinar H. Gunderson wrote:

On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:

Please see #266762 for any discussion on this.

Can you explain why a Policy violation (i.e. not providing shared libs for a -dev package) is of "Severity: wishlist"

Again, see #266762.

esp. in the context of repeated FTBFS caused by it?

To be honest, it is not pvm's problem that rpvm does not work with pure upstream pvm on non-i386.

That is a smokescreen.

There are surely more examples of upstream having expected only static libs, and working fine with shared libs. Years back everything was static, and
pvm presumably has an old-enough heritage.

It is your mixing of two incompatible approaches that creates the problem.

Feel free to invoke the ctte if you feel this is wrong; note that this _will_ be fixed for etch, but not for sarge.

Whatever.

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

--H23uHpCUqgUcHMpK
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

On Thu, Aug 19, 2004 at 11:58:40PM +0200, Steinar H. Gunderson wrote:

On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:

Please see #266762 for any discussion on this.

Can you explain why a Policy violation (i.e. not providing shared
libs for a -dev package) is of "Severity: wishlist"

Again, see #266762.

esp. in the context of repeated FTBFS caused by it?

To be honest, it is not pvm's problem that rpvm does not work with
pure upstream pvm on non-i386.

Feel free to invoke the ctte if you feel this is wrong; note that
this _will_ be fixed for etch, but not for sarge.

Invoking the ctte, as per sgunderson's suggestion. In another message
edd didn't oppose to bring this matter to the ctte. I think, the three
parties involved agree to request the ctte's opinion to this problem.

A serious bug, #266837, has been downgraded to whislist.

Could the ctte decide whether or not this is right?

Kind regards,

Anibal Monsalve Salazar
--
.''`. Debian GNU/Linux | Building 28C
: :' : Free Operating System | Monash University VIC 3800 Australia
`. `' http://debian.org/ | http://www-personal.monash.edu/~anibal
`-

--H23uHpCUqgUcHMpK
Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBJUiUipBneRiAKDwRAv6lAJ9da2JgmIHhlB9NPhkw+21PjhYUogCbByH5 2t4zdWpexRFFuqNQMKOuFvg=
=QMqu
-----END PGP SIGNATURE-----

--H23uHpCUqgUcHMpK--


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

On Thu, Aug 19, 2004 at 05:45:21PM -0500, Dirk Eddelbuettel wrote:

There are surely more examples of upstream having expected only static libs, and working fine with shared libs.

Then please do the following:

- Find an hppa system, and install pvm (with the -dev packages).
- Remove the shared libpvm3.so from the system; now you have a pvm
installation with none of the "mix" you seem to think is the problem.
- Build rpvm and demonstrate that it can indeed create a shared library.

Or allow me:

m206b:~# aptitude install pvm pvm-dev r-base-dev
[etc. -- this operation actually took about an hour; imagine the usefulness
of pvm on these platforms, eh? ;-)]
m206b:~# rm /usr/lib/libpvm3.so*
m206b:~# apt-get -b source rpvm
Reading Package Lists... Done
Building Dependency Tree... Done
Need to get 63.4kB of source archives.
Get:1 ftp://ftp.no.debian.org unstable/main rpvm 0.6.2-1 (dsc) [596B]
Get:2 ftp://ftp.no.debian.org unstable/main rpvm 0.6.2-1 (tar) [61.0kB]
Get:3 ftp://ftp.no.debian.org unstable/main rpvm 0.6.2-1 (diff) [1741B]
Fetched 63.4kB in 1s (35.8kB/s)
dpkg-source: extracting rpvm in rpvm-0.6.2
dpkg-buildpackage: source package is rpvm
dpkg-buildpackage: source version is 0.6.2-1
dpkg-buildpackage: source maintainer is Dirk Eddelbuettel <[email protected]> dpkg-buildpackage: host architecture is hppa
debian/rules clean
test -x debian/rules
test "`id -u`" = 0
if test -n "" && test "" != "."; then rmdir ""; fi
if test "." != "."; then rmdir .; fi
dh_clean
debian/rules build
test -x debian/rules
if [ -n "" ]; then \
mkdir -p ""; \
fi
if [ ! -d "." ]; then \
mkdir -p "."; \
fi
if [ -z "" ]; then \
if ! test -f debian/compat; then echo 4 > debian/compat; fi; \
fi
debian/rules binary
test -x debian/rules
test "`id -u`" = 0
dh_clean -k
dh_installdirs -A
if [ -n "" ]; then \
mkdir -p ""; \
fi
if [ ! -d "." ]; then \
mkdir -p "."; \
fi
if [ -z "" ]; then \
if ! test -f debian/compat; then echo 4 > debian/compat; fi; \
fi
dh_installdirs usr/lib/R/site-library
R CMD INSTALL -l /root/rpvm-0.6.2/debian/r-cran-rpvm/usr/lib/R/site-library --clean .
* Installing *source* package 'rpvm' ...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
Check if PVM_ROOT is defined... no
Warning: PVM_ROOT not defined.
I'll try to build rpvm but you need set PVM_ROOT
before use pvm. See pvm_intro(1PVM)

Try to guess if pvm is installed somewhere ...
Found pvm: /usr/lib/pvm3
PVM_ROOT is /usr/lib/pvm3
PVM_ARCH is LINUXHPPA
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking pvm3.h usability... yes
checking pvm3.h presence... yes
checking for pvm3.h... yes
checking for main in -lpvm3... yes
checking for main in -lgpvm3... yes
checking for pvmd... /usr/bin/pvmd
checking for pvmgs... /usr/bin/pvmgs
configure: creating ./config.status
config.status: creating src/Makevars
config.status: creating inst/pvmhosts
** libs
make[1]: Entering directory `/root/rpvm-0.6.2/src'
gcc -I/usr/lib/R/include -I/include -fPIC -g -O2 -c rpvm_core.c -o rpvm_core.o
gcc -I/usr/lib/R/include -I/include -fPIC -g -O2 -c rpvm_ser.c -o rpvm_ser.o
gcc -I/usr/lib/R/include -I/include -fPIC -g -O2 -c utils.c -o utils.o
gcc -shared -o rpvm.so rpvm_core.o rpvm_ser.o utils.o -lpvm3 -lgpvm3 -lreadline -L/usr/lib/R/bin -lR
/usr/bin/ld: /usr/lib/gcc-lib/hppa-linux/3.3.4/../../../libpvm3.a(lpvmgen.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc-lib/hppa-linux/3.3.4/../../../libpvm3.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[1]: *** [rpvm.so] Error 1
make[1]: Leaving directory `/root/rpvm-0.6.2/src'
ERROR: compilation failed for package 'rpvm'
** Removing '/root/rpvm-0.6.2/debian/r-cran-rpvm/usr/lib/R/site-library/rpvm' make: *** [R_any_arch] Error 1
Build command 'cd rpvm-0.6.2 && dpkg-buildpackage -b -uc' failed.
E: Child process failed
m206b:~#

Years back everything was static

So?

It is your mixing of two incompatible approaches that creates the problem.

Then explain how a pure static setup with no "mixing" fails in exactly the same way, like above. Please, I have wasted enough time on this; if you want this changed before sarge is released, bring the case up for the ctte.

/* 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: [email protected]

On Fri, Aug 20, 2004 at 02:44:33AM +0200, Steinar H. Gunderson wrote:

On Thu, Aug 19, 2004 at 05:45:21PM -0500, Dirk Eddelbuettel wrote:

There are surely more examples of upstream having expected only static libs,
and working fine with shared libs.

Then please do the following:

- Find an hppa system, and install pvm (with the -dev packages).
- Remove the shared libpvm3.so from the system; now you have a pvm
installation with none of the "mix" you seem to think is the problem.
- Build rpvm and demonstrate that it can indeed create a shared library.

Or allow me:

[...]

Useless exercise: a static-only library cannot be used for R -- or at least
not in the default settings as R's configure determines what goes into /etc/R/Makeconf:

edd@homebud:~> grep -c CFLAGS /etc/R/Makeconf
13

So had I seen only static libraries on my i386 when preparing the inital
rpvm packaging as part of snow, I would either not have packaged rpvm, or possibly altered debian/rules to override the CFLAGS in /etc/R/Makeconf. The second alternative is unlikely as it opens its own can of worms in terms of cross-platform builds.

In any event, claiming that a failure in an _altered_ situation (i.e. one shared removed, two static remaining) excuses the failure _in your present packaging_ (mix of shared and static) is pretty silly.

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

On Thu, Aug 19, 2004 at 08:29:17PM -0500, Dirk Eddelbuettel wrote:

Useless exercise: a static-only library cannot be used for R

That is indeed R's problem, not pvm's. I'm sorry to be so negative here, but
a month before release I _won't_ do major changes to what I consider a
working package. (It seems the tech-ctte will have to determine if the
package is "working" or not; I had really hoped we could avoid invoking them for this, but OK, that's the current situation.)

So had I seen only static libraries on my i386 when preparing the inital
rpvm packaging as part of snow, I would either not have packaged rpvm, or possibly altered debian/rules to override the CFLAGS in /etc/R/Makeconf.

I must admit I know very little about R's make system (so I can't say
anything about CFLAGS in Makeconf), but since rpvm obviously can't build without shared pvm libraries (except on i386 and arm, where it works by accident, violating policy requirement that all code in a shared library
must be built with -fPIC), perhaps it shouldn't be in sarge, but wait for
etch. Wouldn't that be a much better solution that arguing about it until
sarge releases? :-)

In any event, claiming that a failure in an _altered_ situation (i.e. one shared removed, two static remaining) excuses the failure _in your present packaging_ (mix of shared and static) is pretty silly.

You're claiming the mix of shared and static is creating a problem; I'm
showing that exactly the same problem exists when the mix goes away. Note
that the situation I created is identical to what upstream offers (two static libraries), so rpvm will not build on hppa with unmodified upstream. What causes rpvm to fail is the lack of two shared libraries, _not_ the mixing in itself; that is completely irrelevant.

/* 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: [email protected]

On Thu, Aug 19, 2004 at 04:37:49PM -0500, Dirk Eddelbuettel wrote:

Please see #266762 for any discussion on this.

Can you explain why a Policy violation (i.e. not providing shared
libs for a -dev package) is of "Severity: wishlist"

Again, see #266762.

esp. in the context of repeated FTBFS caused by it?

On Thu, Aug 19, 2004 at 11:58:40PM +0200, Steinar H. Gunderson wrote:

To be honest, it is not pvm's problem that rpvm does not work with
pure upstream pvm on non-i386.

I agree.

That said, if someone were to submit a patch for pvm which fit within
its design, and which made rpvm easier to get working, I think pvm should accept that patch.

On Fri, Aug 20, 2004 at 10:40:52AM +1000, Anibal Monsalve Salazar wrote:

A serious bug, #266837, has been downgraded to whislist.

That seems to me to be inappropriate. Dirk Eddelbuettel is the package maintainer for rpvm, and Steinar H. Gunderson (the maintainer of pvm) downgraded its priority.

We have here a case of a package [rpvm] which doesn't fullfill its design intent on non-i386 packages and someone who isn't even the package
maintainer trying to downgrade the severity to a wishlist bug. I see
no valid reasons -- technical or otherwise -- for this status change.

It's appropriate for 266762 to be wishlist, but that has no bearing
on 266837.

Could the ctte decide whether or not this is right?

It will take the ctte some time to hold a vote, but Dirk is the package maintainer -- he has every right to put the priority on 266837 back
to serious. Furthermore, since he didn't delegate his authority to the committee, we'd have to have an incredibly good technical reason to ask
him to do anything else.

That said, this is an rpvm problem, not a pvm problem.

That said, I've not looked closely at the designs of either rpvm or pvm.
It might very well be that the design of pvm could sensibly incorporate
a shared lib -dev.

But I agree with Steinar that this is a bit late to make architectural
changes on a package slated for inclusion in Sarge.

I know this leaves rpvm in an awkward state. I'd suggest [for sarge]
making it build statically against pvm (maybe with strict requirements on
the associated installed version of pvm), and incorporating all the bulk
that implies. Yes, this places a disproportionate storage requirement
on rpvm, but this close to release I think stupid simple changes are
better than more elegant but riskier changes.

Maybe someone else in the committee can come up with some better ideas
than mine.

Thanks,

--
Raul


--
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)