Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2006-10-06 Thread Adam C Powell IV 
On Fri, 2006-05-26 at 11:56 +0200, Petr Salinger wrote:
> Hi,
> 
> please could you support mpich and dependents on kFreeBSD.
> Attached please find a modified and extended patch, 
> updating of config.{guess,sub} is done at build time,
> not via dpatch. This variant is easily reviewable.

Hello.  Thank you for this variant, I really like it much better than
the old one.  I will upload my next version with it included, and you
will be notified that the bug has been closed; please test it to make
sure it builds for you.

Apologies for the long delay in getting to this!

Regards,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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

Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2006-05-26 Thread Petr Salinger 
Hi,

please could you support mpich and dependents on kFreeBSD.
Attached please find a modified and extended patch, 
updating of config.{guess,sub} is done at build time,
not via dpatch. This variant is easily reviewable.

Thanks in advance.

Petr



diff -u mpich-1.2.7/debian/control mpich-1.2.7/debian/control
--- mpich-1.2.7/debian/control
+++ mpich-1.2.7/debian/control
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Adam C. Powell, IV <[EMAIL PROTECTED]>
 Standards-Version: 3.6.2.1
-Build-Depends: g77, rsh-client, libx11-dev, libxt-dev, file, debhelper (>> 
4.0.0), dpatch, tk8.4
+Build-Depends: g77, rsh-client, libx11-dev, libxt-dev, file, debhelper (>> 
4.0.0), dpatch, tk8.4, autotools-dev
 Build-Depends-Indep: bzip2
 
 Package: mpich-bin
diff -u mpich-1.2.7/debian/rules mpich-1.2.7/debian/rules
--- mpich-1.2.7/debian/rules
+++ mpich-1.2.7/debian/rules
@@ -17,6 +17,9 @@
 
 CONFIGURE_OPTIONS= -rsh=/usr/bin/rsh
 
+CONFIG_SG_DIRS= mpe mpe/slog2sdk mpe/slog2sdk/trace_rlog 
mpe/slog2sdk/trace_sample \
+   examples/perftest/config/confdb src/fortran/config MPI-2-C++ 
romio/confdb
+
 # checks the environmental variable DEB_BUILD_OPTIONS
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
 CONFIGURE_OPTIONS+= --enable-devdebug --enable-debug 
@@ -46,6 +49,9 @@
 build: build-stamp
 build-stamp: patch-stamp
dh_testdir
+   for CFGAUXDIR in $(CONFIG_SG_DIRS) ; do \
+   cp -f /usr/share/misc/config.{sub,guess} $$CFGAUXDIR ; \
+   done
# make mpich normal
(test -d image_mpich || mkdir image_mpich; cd image_mpich && 
../configure \
$(CONFIGURE_OPTIONS_P4) && \
@@ -79,6 +85,9 @@
 clean: unpatch
dh_testdir
dh_testroot
+   for CFGAUXDIR in $(CONFIG_SG_DIRS) ; do \
+   rm -f $$CFGAUXDIR/config.{sub,guess} ; \
+   done
rm -f build-stamp install-stamp
# clean up the build directory
(set -e; for INST in mpich mpich-mpd mpich-shmem ; do \
diff -u mpich-1.2.7/debian/patches/00list mpich-1.2.7/debian/patches/00list
--- mpich-1.2.7/debian/patches/00list
+++ mpich-1.2.7/debian/patches/00list
@@ -14,0 +15 @@
+19_kfreebsd
only in patch2:
unchanged:
--- mpich-1.2.7.orig/debian/patches/19_kfreebsd.dpatch
+++ mpich-1.2.7/debian/patches/19_kfreebsd.dpatch
@@ -0,0 +1,42 @@
+#! /bin/sh -e
+## 19_kfreebsd.dpatch by Aurelien Janro <[EMAIL PROTECTED]>
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Add support for GNU/kFreeBSD
+
+if [ $# -ne 1 ]; then
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+fi
+case "$1" in
+-patch) patch -f --no-backup-if-mismatch -p1 < $0;;
+-unpatch) patch -f --no-backup-if-mismatch -R -p1 < $0;;
+*)
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1;;
+esac
+
+exit 0
+
+--- mpich-1.2.7.orig/bin/tarch
 mpich-1.2.7/bin/tarch
+@@ -138,6 +138,7 @@
+ next)FARCH=NeXT ; break ;;
+   KSR1|KSR2)   FARCH=ksr ; break ;;   
+ FreeBSD) FARCH=freebsd ; break ;;
++GNU/kFreeBSD) FARCH=freebsd ; break ;;
+   NetBSD)  FARCH=netbsd ; break ;;
+   i386)GARCH=ipsc2 ;;
+   ULTRIX|RISC) GARCH=dec5000 ;;
+
+--- mpich-1.2.7.orig/mpid/ch_p4/p4/lib/p4_secure.c
 mpich-1.2.7/mpid/ch_p4/p4/lib/p4_secure.c
+@@ -367,6 +367,7 @@
+ #if defined(P4BSD) && !defined(NO_ECHO)
+ 
+ #ifdef FREEBSD
++#include 
+ #include 
+ #else
+ #include 
+

Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2006-01-16 Thread Santiago Vila 
On Sun, 15 Jan 2006, Adam C Powell IV wrote:

> On Sun, 2006-01-15 at 23:23 +0100, Santiago Vila wrote:
> > On Sun, 9 Oct 2005, Adam C Powell IV wrote:
> > 
> > > It looks like about 80-90% of the patch is unnecessary to support this
> > > architecture, e.g. there's no need for openrisc, os400, djgpp, crx etc.
> > > in a Debian system.  Can you please edit out the unnecessary parts so
> > > the patch is more compact, while supporting the new arch (and other new
> > > ones like armeb)?  If you don't, I will try, but I can't guarantee it
> > > will work...
> > 
> > Well, there might be no need for openrisc, os400, djgpp, crx, but if
> > you think about it, there is really no need to make the patch shorter
> > either.
> 
> Sure there is.  It's about conciseness and verifiability.  I want a set
> of small patches which someone can reasonably say, "Okay, I see what
> that does, it does that and nothing more," and not worry that it will do
> something bad to their machine.  Long patches which do much more than is
> needed for Debian are inherently bad.

I understand that you prefer a small patch over a big patch *in general*,
but a small patch is not always more verifiable.

In this case, for example, if you use the most recent config.guess and
config.guess, it will be easy to verify that the modified versions
match the ones in the autotools-dev package. The latest versions of
those files in the autotools-dev package are the ones we *fully* trust,
for *every* machine. Everybody can reasonably say "okay, I see that
the patch updates those files to the latest version, which I trust".

You even admit that if you try to make the patch smaller, you don't
guarantee that it will work. We know that the full config.guess and
config.sub files do work and we trust them. Why lose your time (or ask
anybody else to lose his time) trying to make the patch smaller when
doing so increases the risk of breaking something?

I for one would certainly not consider this package "safer" just
because you managed to save a few bytes in the size of the patch.
In such case I would start worrying about it, not the opposite.

So I agree that a small patch is better than a long patch in general,
but there are exceptions, and this is one of them. If you try to make
it smaller, the probability of breaking something increases, not decreases.


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

Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2006-01-15 Thread Adam C Powell IV 
On Sun, 2006-01-15 at 23:23 +0100, Santiago Vila wrote:
> On Sun, 9 Oct 2005, Adam C Powell IV wrote:
> 
> > It looks like about 80-90% of the patch is unnecessary to support this
> > architecture, e.g. there's no need for openrisc, os400, djgpp, crx etc.
> > in a Debian system.  Can you please edit out the unnecessary parts so
> > the patch is more compact, while supporting the new arch (and other new
> > ones like armeb)?  If you don't, I will try, but I can't guarantee it
> > will work...
> 
> Well, there might be no need for openrisc, os400, djgpp, crx, but if
> you think about it, there is really no need to make the patch shorter
> either.

Sure there is.  It's about conciseness and verifiability.  I want a set
of small patches which someone can reasonably say, "Okay, I see what
that does, it does that and nothing more," and not worry that it will do
something bad to their machine.  Long patches which do much more than is
needed for Debian are inherently bad.

> In fact, this is not really about applying a patch, it is about using
> the most recent config.guess and config.sub available. You can find
> those files in the autotools-dev package, in /usr/share/misc.

Right, but that's an issue for upstream, which has stopped developing
mpich-1.x.

> If you don't like adding a patch which is aesthetically ugly to you,
> you can copy the files at build time instead. The details are
> explained in /usr/share/doc/autotools-dev/README.Debian.gz.

Interesting idea.  At some point I might try this, but for now I think
I'll just cut a lot out of your patch.  Thanks for the suggestion.

> > Also, mpich is stuck with about twelve other packages trying to enter
> > testing, so until that transition is made I'll be unable to upload a new
> > mpich package.  I'll do this as soon as possible.
> 
> I hope such is not the case anymore.

Nope, so I'll try to get to this soon.

> For the record, several hurd-i386 packages fail to build from source
> because libmpich1.0-dev does not exist.

Yes, mpich is pretty central to much of the cluster computing
infrastructure.  I'll try to get to it soon.

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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

Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2006-01-15 Thread Santiago Vila 
On Sun, 9 Oct 2005, Adam C Powell IV wrote:

> It looks like about 80-90% of the patch is unnecessary to support this
> architecture, e.g. there's no need for openrisc, os400, djgpp, crx etc.
> in a Debian system.  Can you please edit out the unnecessary parts so
> the patch is more compact, while supporting the new arch (and other new
> ones like armeb)?  If you don't, I will try, but I can't guarantee it
> will work...

Well, there might be no need for openrisc, os400, djgpp, crx, but if
you think about it, there is really no need to make the patch shorter
either.

In fact, this is not really about applying a patch, it is about using
the most recent config.guess and config.sub available. You can find
those files in the autotools-dev package, in /usr/share/misc.

If you don't like adding a patch which is aesthetically ugly to you,
you can copy the files at build time instead. The details are
explained in /usr/share/doc/autotools-dev/README.Debian.gz.

> Also, mpich is stuck with about twelve other packages trying to enter
> testing, so until that transition is made I'll be unable to upload a new
> mpich package.  I'll do this as soon as possible.

I hope such is not the case anymore.

For the record, several hurd-i386 packages fail to build from source
because libmpich1.0-dev does not exist.


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

Bug#333001: mpich: FTBFS on GNU/kFreeBSD

2005-10-09 Thread Adam C Powell IV 
On Mon, 2005-10-10 at 00:37 +0200, Aurelien Jarno wrote:
> Package: mpich
> Severity: important
> Tags: patch
> 
> Hi,
> 
> mpich fails to build on GNU/kFreeBSD due to missing support and outdated
> config.{guess,sub}. Please find attached a patch to fix that. Could you 
> please add it in the next upload?
> 
> Don't hesitate to contact me if you need more information.
> 
> Thanks in advance,
> Aurelien

Thank you for the bug, and patch.  I appreciate the work you are doing
to support Debian on this new kernel/OS combination.

It looks like about 80-90% of the patch is unnecessary to support this
architecture, e.g. there's no need for openrisc, os400, djgpp, crx etc.
in a Debian system.  Can you please edit out the unnecessary parts so
the patch is more compact, while supporting the new arch (and other new
ones like armeb)?  If you don't, I will try, but I can't guarantee it
will work...

Also, mpich is stuck with about twelve other packages trying to enter
testing, so until that transition is made I'll be unable to upload a new
mpich package.  I'll do this as soon as possible.

Thanks again,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe!
http://www.take6.com/albums/greatesthits.html


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