tags 628826 + moreinfo unreproducable
thanks
Hi Jakub,
I can build pdb2pqr without problems in i386 unstable chroots on
two different amd64 host. Can you please give details on your
build setup?
Best regards,
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
tags 592892 + confirmed pending
thanks
Am Freitag, den 27.08.2010, 13:57 -0400 schrieb Jeff Squyres:
This was the badness, as pointed out by Ralf here:
http://www.open-mpi.org/community/lists/devel/2010/08/8292.php
Fix will committed to upstream SVN this evening; a patch for the v1.4
Hi Julien!
Am Freitag, den 16.07.2010, 17:26 +0100 schrieb Julien Cristau:
jcris...@merkel:~$ dpkg-deb -c
/org/ftp.root/debian/pool/main/o/openmpi/libopenmpi1.3_1.4.2-1_amd64.deb |
grep libmpi.so
-rw-r--r-- root/root679992 2010-07-16 08:19
./usr/lib/openmpi/lib/libmpi.so.0.0.2
Am Freitag, den 16.07.2010, 19:29 +0100 schrieb Julien Cristau:
In case you've missed it, the new version also FTBFS on kfreebsd-i386:
https://buildd.debian.org/fetch.cgi?pkg=openmpi;ver=1.4.2-1;arch=kfreebsd-i386;stamp=1279291631
I saw it but I have not looked into it yet. I'll probably upload
Am Dienstag, den 02.03.2010, 10:25 + schrieb Alan Woodland:
2010/3/1 Fernando Tarlá Cardoso Lemos fernando...@gmail.com:
My suggested fix is to add /usr/bin/orte-checkpoint and
/usr/bin/orte-restart
to the list of files that are installed by this package.
Any ideas where these got
Hi Moritz!
Am Dienstag, den 08.12.2009, 20:35 +0100 schrieb Moritz Muehlenhoff:
You should rather use the copy of libltdl currently in the
archive or is there a technical reason, which prevents this?
I'm aware of that and discussed it with upstream. They said it would
require quite some
Hi Moritz!
Am Dienstag, den 08.12.2009, 22:28 +0100 schrieb Moritz Muehlenhoff:
You can leave etch and lenny untouched, the impact doesn't warrant an
update.
Thanks for clarifying!
Best regards
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of
Hi Riccardo!
Am Dienstag, den 04.08.2009, 17:11 +0200 schrieb Riccardo Stagni:
A lot of development happened to gcx during last months!
In addition to a gtk2 interface, there is support for raw images produced
by DSLRs and a minimal support for INDI (for telescope, camera and guider
control).
Am Montag, den 07.12.2009, 09:30 +0100 schrieb Sylvestre Ledru:
Manuel, are you going to handle this issue or do you want me to do it ?
I can take care of that. I've forwarded this upstream already. The best
option would be having a fixed libtool available, or trying to use the
backported patch
Hi Michael!
Am Montag, den 07.12.2009, 00:06 -0500 schrieb Michael Gilbert:
The following CVE (Common Vulnerabilities Exposures) id was
published for libtool. I have determined that this package embeds a
vulnerable copy of the libtool source code. However, since this is a
mass bug filing
security issue in copy of libtool, see CVE-2009-3736.
+Closes: #559836.
+
+ -- Manuel Prinz man...@debian.org Tue, 08 Dec 2009 00:58:02 +0100
+
openmpi (1.3.3-3.1) unstable; urgency=low
* Non-maintainer upload with the maintainer's permission.
diff -u openmpi-1.3.3/debian/patches/series
Hi Lucas!
Am Dienstag, den 17.11.2009, 23:38 -0600 schrieb Lucas Nussbaum:
I'm still not convinced. For example, in preinst, you probably shouldn't
--remove-all mpirun.
Attached is a patch that works (apparently). I plan to do something very
similar in mpich2. Can you review/comment?
Thanks
Am Mittwoch, den 18.11.2009, 07:35 -0600 schrieb Lucas Nussbaum:
Yeah, but the unconditional --removal-all looks a bit scary :-)
I know. There was discussion about that on the dpkg mailing list, IIRC.
Other packages had similar problems. The recommended solution was to
remove all and let u-a
On Tue, 2009-11-10 at 15:29 -0600, Pavan Balaji wrote:
MPICH2 and Open MPI should have the same priority, isn't it? They are
just alternative implementations of MPI.
Thought about that too but I am unsure how update-alternatives handles
that case. The man page talks about only taking action if
On Wed, 2009-11-11 at 13:43 +0100, Lucas Nussbaum wrote:
I would vote for keeping it as is, so we don't need to change LAM and
mpich. It's not really exposed to users anyway.
I'm fine with that.
Best regards
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a
As for the mpi.so thing: Forget about it, confusion on my part. Not a
problem at all.
On Wed, 2009-11-11 at 13:54 +0100, Lucas Nussbaum wrote:
OK. That's really the first problem I'd like to solve, since it only
affects OpenMPI and MPICH2. The other problems can be addressed after
that.
Am Mittwoch, den 11.11.2009, 14:13 +0100 schrieb Lucas Nussbaum:
Let's fix the only really broken thing: the mpiexec/mpirun problem in
openmpi and mpich2. After that, we can downgrade this bug and discuss
the rest of it.
I uploaded a fixed package a few minutes ago that uses mpirun as
master
Hi Lucas!
Am Montag, den 26.10.2009, 09:04 +0100 schrieb Lucas Nussbaum:
Alternatives:
- for compilation environment:
all implementations have a single mpi alternative. The master
controls the link from /usr/include/mpi, and has all the compilers
wrappers as slaves.
= That's great,
Hi Niko!
Sorry for the late reply! I was offline for a few days and did forget to
mention that before.
Am Sonntag, den 18.10.2009, 21:05 +0300 schrieb Niko Tyni:
It seems the standard way to go is with Inline::MakeMaker. Here's
a lightly tested patch that seems to work for me, hope you find
Hi Niko,
thanks for your message and the included hints!
Am Donnerstag, den 15.10.2009, 09:05 +0300 schrieb Niko Tyni:
I suppose a workaround could be to somehow generate dependencies like
Depends: perl (= 5.10.1), perl ( 5.10.2~)
and require binNMUs every time the perl version changes.
Hi,
I have no idea where exactly the issue comes from, but after rebuilding
an unmodified version and installing the new package on my sid box
findimagedupes works like a charm. If someone could confirm that it
fixes the issue, I'll ask the release team to schedule a rebuild.
Best regards
Manuel
Am Sonntag, den 13.09.2009, 22:35 +0200 schrieb Michael Koch:
I'm in contact with Manuel (the only uploader) and he is working on a
new version.
The new version will be uploaded RSN. I hope suring the week, but might
take until the weekend. I guess we can afford to wait this; I don't mind
Am Mittwoch, den 24.06.2009, 16:16 +0100 schrieb David Ham:
libopenmpi1 has been replaced by libopenmpi1.3 rendering
libparmetis3.1 uninstalable. Rebuilding libparmetis3.1 from source is
sufficient to update the dependency and fix this bug.
Rebuilds are scheduled by the release team as part of
Hi Jeff! Hi Steve!
Thanks for implementing a solution and pushing it upstream!
The last NMU by Steve did not make it into Debian. I'm preparing an
upload at the moment, acknowleding the NMUs and fixing all RC bugs. I'll
upload later tonight or tomorrow.
Thanks again for working on the issue
Hi everyone!
On Fri, June 12, 2009 11:10 pm, Jeff Squyres wrote:
Agreed. We thought that stat() was safe to call in the malloc init
hook -- it seems to be in most other places, at least.
If there's some other safe way to check that stat() is *not* safe,
that would be great.
Unfortunately,
Checked again, the bug is somewhere in Open MPI. While testing on Lenny,
I had some cruft left over. A fresh 1.3.2 installation shows the same
behaviour.
Best regards
Manuel
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi Jeff!
Am Montag, den 08.06.2009, 21:08 -0700 schrieb Jeff Squyres:
Agreed; fixing the root problem is a better bet.
Manuel -- can you ping the fakeroot people? It would be preferable to
the method described in that URL.
The fakeroot maintainers are in CC, they should have gotten the
Hi Michael!
Am Montag, den 08.06.2009, 15:26 +0200 schrieb Michael Meskes:
mich...@feivel:~$ findimagedupes .
Invalid value '/usr/local/lib/findimagedupes' for config option DIRECTORY
at /usr/bin/findimagedupes line 0
INIT failed--call queue aborted, DATA line 1.
Changing
Hi Jeff and Steve,
thanks a lot for diving into it! It's very appreciated! (I was not able
to access a computer during the last two days, so sorry for being
unresponsive!)
Am Sonntag, den 07.06.2009, 11:04 -0500 schrieb Steve M. Robbins:
I was able to avoid the segfault simply by ifdef'ing out
[ Please keep me or the bug in CC, as I'm not subscribed. Thanks! ]
Hi everyone,
I'm trying to find the reason for bug #531522. The Open MPI compiler
wrapper of Open MPI 1.3.2 segfaults when called with fakeroot. I have
the feeling that eglibc's dlopen()/dlsym() might be the problem but I'm
not
Am Dienstag, den 02.06.2009, 15:29 -0700 schrieb Nicholas Breen:
Doesn't seem like it was necessarily the eglibc switch, though. Downgrading
to
openmpi 1.3-2 on an otherwise up-to-date sid box doesn't show the bug.
fakeroot 1.12.2, libc6 2.9-13.
Interestingly, it works with OpenMPI 1.3.2 on
Hi Daniel!
Am Mittwoch, den 03.06.2009, 00:21 +0200 schrieb Daniel Leidert:
Hi guys. A short note: After the change to eglibc I discovered
segmentation faults in the gnome-chemistry-utils (with similar
backtraces), which were solved by rebuilding the package. It *might*
help to do the same
tags 531419 + confirmed
thanks
Hi Jeff,
I'm putting you in the loop since I'm quite lost here... It would be
great if you could throw in your thoughts!
mpicc segfaults when it's called via fakeroot. Since this tool is needed
in the build process of Debian packages, packages depending on Open
Am Montag, den 01.06.2009, 19:15 -0700 schrieb Nicholas Breen:
I confess that the peculiar interactions of compilers, fakeroot, and (e)glibc
put me well out of my depth.
ACK. But from what I see and experienced, I get the feeling that it's
related to eglibc. Anyway, here is my backtrace
Hi Stefan!
Am Donnerstag, den 19.03.2009, 20:59 +0100 schrieb Stefan Potyra:
wow, that was fast!
Thanks! Compared to Alpha, fixing Sparc was quite easy. Should have
started with that one...
I just did a test-build on a sparc box with the packaging from svn, and it
worked like a charm :).
Am Dienstag, den 17.03.2009, 18:32 +0100 schrieb Adeodato Simó:
Okay; I think it’s reasonable to wait, as long as we make sure it gets
addressed at some point. Maybe we should open a separate bug report for
it?
Feel free to do so if you like; usually, they're very responsive and I
expect an
Am Dienstag, den 17.03.2009, 18:32 +0100 schrieb Adeodato Simó:
3.) Patch and build all dependant software.
4.) File bugs for all packages, including patches.
5.) NMU if no response in a reasonable time frame.
Uhm, what kind of patches are needed? Has the API changed as well
between 1.2
Hi Adeodato!
Am Dienstag, den 17.03.2009, 18:28 +0100 schrieb Adeodato Simó:
Hello, let’s file this as a bug so that we have a place to track it.
Thanks!
Sorry if you already had an upload ready!
I fixed it in the Git repository already but did not upload, as Open MPI
currently is not
Am Dienstag, den 17.03.2009, 23:21 +0100 schrieb Adeodato Simó:
If, as you say, the sparc failure is expected to be fixed soon, I don’t
understand if there would be any problem with uploading with the
alpha/LAM change now, keeping sparc with openmpi. If you are concerned
that mpi-defaults will
package openmpi
tags 519725 + patch
thanks
Hi Stefan!
Thanks for your bug report!
Am Samstag, den 14.03.2009, 18:41 +0100 schrieb Stefan Potyra:
I have no clue though, how to obtain a semantic equivalent info like the
time stamp counter on sparc though :/.
I did some research and guess I
Am Montag, den 16.03.2009, 16:41 +0100 schrieb Arthur Loiret:
No problem, I'll have a look and test it in a very few days, thanks a
lot for it!
Thanks! In case you try building the full Debian packages, please use a
SVN checkout, as I fixed a bug in debian/rules that may make the build
fail,
Am Sonntag, den 15.03.2009, 16:14 +0100 schrieb Adeodato Simó:
Indeed, bumping the SONAME in 1.3.1 would be great if indeed ABI
compatibility has been broken. Thanks for pursuing this.
Upstream discusses the plans for future releases and dealing with
SONAMEs on their development list. We'll see
Am Sonntag, den 15.03.2009, 12:23 +0100 schrieb Adeodato Simó:
There is an unfortunate problem with it, though: you can’t use an
architecture restriction like [arch1 !arch2] in Build-Depends. That
is, you can’t mix ! and non-!; if you stop to think about it, it
doesn’t make sense.
Just
package openmpi
tag 510845 + patch
tag 517543 + patch
thanks
Hi everyone,
I (hopefully) fixed the build issue on Alpha. You can find the patch
attached. It implements the timing routine that is missing. I applied it
to our SVN repository.
Though I was able to successfully build it on a porter
Hi Arthur!
Thanks for the patch! It turned it's not neccessary (and sufficient) to
fix VampirTrace (only). You should have recieved an email with the patch
I developed and I'd be really glad if you could review it, since my
alpha assemly skills are rather low! (Though improving, I hope!)
Thanks
Hi Adeodato!
Am Freitag, den 13.03.2009, 21:41 +0100 schrieb Adeodato Simó:
Open MPI used to build fine on alpha, so this is probably a problem with
the new upstream release. Reassigning to Open MPI maintainers.
It’s been 2 months, and this issue has not been addressed. In the
meantime,
Hi Arthur!
Thanks for the patch!
Am Samstag, den 28.02.2009, 14:56 +0100 schrieb Arthur Loiret:
There is an issue with using TIMER_CYCLE_COUNTER as TIMER on alpha
(it uses TSC), so alpha should use TIMER_GETTIMEOFDAY. Here is a quick
patch:
I've been working on implementing support for
reassign 510845 openmpi 1.2.8-3
thanks
Am Montag, den 05.01.2009, 12:05 +0100 schrieb Adeodato Simó:
Package: mpi-defaults
Version: 0.2
Severity: serious
The latest version of openmpi failed to build from source on alpha,
hence mpi-defaults can't be built there, because libopenmpi-dev is
Hi Andreas!
Am Dienstag, den 01.07.2008, 08:25 +0200 schrieb Andreas Tille:
Well, the versioned dependency was required to fix #479731 so a
simple ${perl:Depends} is not sufficient in this case. But thanks
for the dh_perl - cdbs issue.
You're welcome! The versioned dependancy can be
tags 488148 + pending
thanks
Hi Andreas,
I fixed the bug SVN, as you might have noticed. The path given to
dh_perl was wrong, that's why perlapi-$Confiv{Version} was not set. The
-V is not necessary. It even disables the dependancy to perlapi, so I
dropped it. ${perl:Depends} is now substitued
Hi Niko and Andreas!
Am Donnerstag, den 26.06.2008, 21:04 +0300 schrieb Niko Tyni:
This package contains a binary Perl module,
/usr/lib/findimagedupes/lib/auto/findimagedupes/findimagedupes.so
but doesn't depend on perlapi-$Config{version} as required by section
4.4.2 of the Perl policy.
tags + confirmed patch
thanks
Hi Gennaro and Lucas,
it's just an outdated Build-Depends on the older version of the SLURM
libraries. The attached patch fixes it. Sorry for missing it during the
testing! I did not have the newer SLURM version installed when compiling
libpam-slurm.
I do not know
Am Dienstag, den 05.02.2008, 11:19 +0100 schrieb Clemens Krammer:
$ dpkg -l | grep evolution
ii evolution 2.12.3-1 groupware suite with mail
client and organizer
ii evolution-common 2.12.3-1 architecture independent
files for Evolution
ii
Am Freitag, den 01.02.2008, 08:21 +0100 schrieb Yves-Alexis Perez:
Without version I can't really say. But I guess you didn't try with
evolution-data-server 1.12.3-1:
Pawel wrote to me that it works for him now, didn't notice that it was a
private mail. Updating everything to 1.12.3-1 works.
Hi Pawel!
Am Donnerstag, den 31.01.2008, 01:47 +0100 schrieb Paweł:
I have evolution in version: 2.12.3-1 also have the fallowing packages:
libedataserver1.2-9
libcamel1.2-10
libebook1.2-9
libecal1.2-7
libedata-book1.2-2
libedata-cal1.2-6
libegroupwise1.2-13
but I still have
Am Dienstag, den 29.01.2008, 17:15 +0100 schrieb Lapse of Reason:
I guess something else you did must have solved the problem. What else
did you do? Thanks...
The proposed solution worked for me. The following packages were
installed as well:
libedataserver1.2-9
libcamel1.2-10
libebook1.2-9
Hi Daniel!
First of all, thanks a lot for your patch to #220044!
Am Freitag, den 04.01.2008, 15:18 +0100 schrieb Daniel Leidert:
FYI: The bug in u-a has been fixed recently.
http://bugs.debian.org/220044
I did not get the message about the bug being closed though subscribed,
so thanks for the
Am Freitag, den 04.01.2008, 16:49 +0100 schrieb Ondrej Certik:
Actually, the mpi.h is in /usr/include/mpi, not /usr/include/openmpi,
as I mistakenly thought.
That happens. Are you fine with me closing the bug?
Best regards
Manuel
signature.asc
Description: Dies ist ein digital signierter
Hi Ondrej!
Am Donnerstag, den 20.12.2007, 20:13 +0100 schrieb Ondrej Certik:
[ Some confusing about /usr/include/mpi/mpi.h not being a symlink ]
No, I think this particular bug is solved.
What do you think about the symlink problem?
/usr/include/mpi/mpi.h is not a symlink because
Am Donnerstag, den 20.12.2007, 19:57 +0100 schrieb Ondrej Certik:
Thanks again for the work you and Dirk are doing on the openmpi
package and especially the quick responses. And sorry if I made some
confusion.
No worries.
Best regards
Manuel
signature.asc
Description: Dies ist ein digital
Hi Ondrej!
Am Freitag, den 21.12.2007, 09:34 +0100 schrieb Ondrej Certik:
On Dec 21, 2007 9:10 AM, Manuel Prinz [EMAIL PROTECTED] wrote:
/usr/include/mpi/mpi.h is not a symlink because /usr/include/mpi is a
symlink. The MPI packages place all their header files in a directory
Opps
Hi Ondrej!
Am Donnerstag, den 20.12.2007, 08:00 +0100 schrieb Ondrej Certik:
thanks very much for your reply. As you explained in your previous email,
I think the misunderstanding is, that you and Dirk think, that
/usr/include/mpi.h
is symlinked to /usr/lib/openmpi/whatever, right?
No. We
tags 456869 + patch
thanks
Hello Ondrej,
attached you'll find a patch that solved the FTBFS of your package for
me. It patches the source directly, so you have to convert it so it can
be used with your favorite patch system.
The problem is that you can't find the MPI includes, as you already
Am Mittwoch, den 19.12.2007, 00:47 +0100 schrieb Manuel Prinz:
I just finished to develop a patch for our broken OpenMPI package. It
looks quite good in first tests. I'll do more tomorrow and will include
GROMACS. So I hope we'll have a fixed openmpi package in a few days.
I'll keep you
Am Dienstag, den 18.12.2007, 16:39 -0800 schrieb Nicholas Breen:
Is it somewhere publically available? I'd be happy to test it as well,
it'll be interesting to see if it also works with GROMACS 3.3.3-beta
packages.
Yes, you can find it in the SVN repository linked at
Am Dienstag, den 18.12.2007, 21:23 -0600 schrieb Dirk Eddelbuettel:
On 19 December 2007 at 01:29, Manuel Prinz wrote:
| I'm not sure about that. I didn't see that on a quick read of chapters 8
| and 10, though policy states in 10.2:
| Packages that use libtool to create shared
Hi Ondrej!
Am Mittwoch, den 19.12.2007, 22:15 +0100 schrieb Ondrej Certik:
Unfortunately I still don't understand how it works. I admit
it can be my fault.
No problem. I'll try to explain the situation and reasoning below.
Let me repeat my question:
Why does openmpi use /usr/lib instead
Dear Sune!
Am Mittwoch, den 19.12.2007, 23:43 +0100 schrieb Sune Vuorela:
I have read the discussion in the bug report. If it is anywhere else, please
point to it instead of playing smart-ass.
That applies to everyone: I don't like the tone of the recent emails and
would be glad if we could
Am Mittwoch, den 19.12.2007, 06:58 -0600 schrieb Dirk Eddelbuettel:
On 19 December 2007 at 13:08, Manuel Prinz wrote:
| if we want to handle it via alternatives (which LAM doesn't) we have
| check the situation in pgapack, so we don't get a problem there. What is
| the advantage to have mpi.h
Hi Adam!
Thanks for your explanations. I have one question still:
Am Mittwoch, den 19.12.2007, 08:40 -0500 schrieb Adam C Powell IV:
I think the confusion is: the .la files are not the static libs, they
are libtool metadata files. The -dev package needs to include the .a
static libs. The
Hello Adam!
Am Dienstag, den 18.12.2007, 08:50 -0500 schrieb Adam C Powell IV:
A couple of notes:
* The lib*.so.0.0.0 and lib*.so.0 files *must* be in libopenmpi1,
that's the shared lib package which other packages will link to
at runtime. So please move those files and
Hi everyone!
Am Dienstag, den 18.12.2007, 15:31 +0100 schrieb Manuel Prinz:
I already noticed my mistake and am working with a modified version.
Here's my new and modified patch for openmpi. It looks right to me and
first checks show that it's working. I'll have a larger test tomorrow
is
whether we should compile the static libraries and/or (also) include
the .la files. I have to do more reading on that one.
On 19 December 2007 at 00:43, Manuel Prinz wrote:
| If noone has complaints, I will apply it to trunk.
Always apply, we can always fix later. No point in sending patches
Am Montag, den 17.12.2007, 13:36 -0600 schrieb Dirk Eddelbuettel:
Indeed, what were we thinking here Manuel? [...] In light of this, can
you remind me why you put the libs into /usr/lib/openmpi ? I
understand why we put the _internal_ library files like [files
snipped] there, but for the
Am Montag, den 17.12.2007, 14:47 -0600 schrieb Dirk Eddelbuettel:
On 17 December 2007 at 21:13, Manuel Prinz wrote:
| Am Montag, den 17.12.2007, 13:36 -0600 schrieb Dirk Eddelbuettel:
| The reasoning behind that was to fix the breaking of other MPI
| implementations by moving stuff to /usr/lib
Am Montag, den 17.12.2007, 16:16 -0500 schrieb Adam C Powell IV:
As the maintainer of mpich, I do not see any conflicts here.
libmpich1.0ldbl has: libmpich.so.1.0, libfmpich.so.1.0,
libpmpich.so.1.0, libpmpich++.so.1.0, libtvmpich.so.1.0, and
libmpe.so.1.0 . There's no ABI compatibility
Hi Dirk!
Am Montag, den 17.12.2007, 16:24 -0600 schrieb Dirk Eddelbuettel:
Are you sure we need alternatives for something like libmpi_cxx.so.0 which
the 'other' (ie LAM) doesn't have?
No. What I currently try to figure out is where the intersection is and
create links all unique libs and
Am Montag, den 17.12.2007, 17:53 -0500 schrieb Adam C Powell IV:
That already happens via alternatives slaves. As discussed earlier,
it's inappropriate with ABI-incompatible soname-named files e.g. *.so.0
I think we're going in the right direction: alternatives for *.so and
different
Hi guys!
Am Montag, den 17.12.2007, 17:53 -0500 schrieb Adam C Powell IV:
That already happens via alternatives slaves. As discussed earlier,
it's inappropriate with ABI-incompatible soname-named files e.g. *.so.0
I think we're going in the right direction: alternatives for *.so and
tags 452047 + pending
thanks
Hi Nicholas,
I added a fix in trunk a while ago which seems to work and uses
alternatives. Nevertheless, when installing other MPI -dev packages, the
problem is still the same due to a bug in update-alternatives. I thought
of patching but it's not as easy as I
Am Dienstag, den 11.12.2007, 10:00 -0600 schrieb Dirk Eddelbuettel:
Maybe we should release a new openmpi to fix the few trivial bugs, and maybe
add a NEWS or README item indicating this open issue with the alternatives --
and how our hands are tied by update-alternatives -- to give this some
Am Dienstag, den 11.12.2007, 10:57 -0600 schrieb Dirk Eddelbuettel:
foo:~ dict -P- TTBOMK
No definitions found for TTBOMK
What's TTBOMK ?
To The Best Of My Knowledge. I'm kinda surprised dict doesn't know
that!?
Can you give it a spin against SVN? If all is well, I can
upload this eve.
block 452047 by 388313 220044
thanks
Hi,
this bug (as well as #220044) blocks us (Debian OpenMPI Maintainers) in
fixing RC bug #452047. We have a solution in our trunk but it's not
functional because the alternative links are not removed/deleted
correctly by u-a.
I'd like to help in providing a
Hi Nicholas!
Am Montag, den 19.11.2007, 19:36 -0800 schrieb Nicholas Breen:
[ Problem description ]
I'm confident that the issue you describe causes the problem. So our gut
feeling was right. I'll have a look at it.
I've set the bug severity at serious because this is a filename overlap
Package: gromacs-openmpi
Version: 3.3.2-2
Severity: grave
Justification: renders package unusable
Hi Nicholas,
we already talked about that bug. It affects the current version in unstable
on amd64 and is reprocudible in a lenny and sid chroot.
I think it's caused by LAM but I have not
Hello Ondrej!
Am Mittwoch, den 07.11.2007, 21:31 +0100 schrieb Ondrej Certik:
$ mpicc
-bash: mpicc: command not found
This temporary fix overcomes the problem:
$ sudo ln -s /usr/bin/opal_wrapper /usr/bin/mpicc
The same has to be done for all the others: mpif77, mpi90 etc.
Thanks for
Am Mittwoch, den 07.11.2007, 23:58 +0100 schrieb Ondrej Certik:
Sure, close it. Open MPI seems to be fine.
Thanks! We put a lot of effort in it and are very happy it's
appreciated! :)
I'll close the bug then.
I also managed to build petsc thanks to this. Now I am going to try to
fix libmesh
Hi Bernd!
Am Montag, den 15.10.2007, 13:23 +0200 schrieb Bernd Zeimetz:
I can also rename genbox to radgenbox.
I guess your package attracts more people, so it should probably keep
the binaries name. On the other side - if genbox is only rarely used in
gromacs, the better thing would be to
Am Freitag, den 05.10.2007, 01:03 +0200 schrieb Manuel Prinz:
I've checked in a modified debian/control. Building and testing has to
be done tomorrow morning.
Done. It built, installed and worked fine. The bug can be closed with
the next upload.
Best regards
Manuel
--
To UNSUBSCRIBE
tags 445230 confirmed
thanks
Hi Andreas!
Am Donnerstag, den 04.10.2007, 00:58 -0700 schrieb Andreas Kabel:
Compiler wrappers don't work. Required data files
are not part of the package, nor are they in any
package libopenmpi-dev depends on.
[EMAIL PROTECTED]:~$ mpicc.openmpi
Cannot open
Am Donnerstag, den 04.10.2007, 17:10 -0500 schrieb Dirk Eddelbuettel:
Manuel, you said that you replicated Andreas' finding.
I did.
What version was that?
1.2.4-2
(My home system is still 1.2.3-2 as on testing, so whatever we may
have broken in the 1.2.3-{3,4} versions doesn't bite me).
tags 445230 + pending
thanks
Am Donnerstag, den 04.10.2007, 17:43 -0500 schrieb Dirk Eddelbuettel:
Ah, yes, have the -dev depend on openmpi-common. I read your mail 'the other
way around'. We don't want every user of -common to also have to have -dev.
Full ACK! It wouldn't solve the problem
Hi Keith!
Am Sonntag, den 30.09.2007, 01:58 -0600 schrieb Keith Hellman:
Package: openmpi-bin
Version: 1.1-2.5
The 1.1 series of OpenMPI is known to be buggy and no longer supported
upstream.
Is it possible for you to use the package in unstable (1.2.4-1) and
check if the bug still exists
[ CC'ing the BTS for documentation purposes ]
Am Sonntag, den 30.09.2007, 09:29 -0600 schrieb Keith Hellman:
On Sun, Sep 30, 2007 at 01:17:08PM +0200, Manuel Prinz wrote:
Am Sonntag, den 30.09.2007, 01:58 -0600 schrieb Keith Hellman:
Package: openmpi-bin
Version: 1.1-2.5
The 1.1
94 matches
Mail list logo
