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
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 uploa
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
> l
Am Dienstag, den 02.03.2010, 10:25 + schrieb Alan Woodland:
> 2010/3/1 Fernando Tarlá Cardoso Lemos :
> > 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 to? They were
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
> contro
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 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 chang
Fixed security issue in copy of libtool, see CVE-2009-3736.
+Closes: #559836.
+
+ -- Manuel Prinz 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 openmpi-1.
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 fili
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
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 rec
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?
Tha
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
mast
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.
>
>
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
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
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
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
NMUi
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
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 whil
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.
Unfortunate
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 th
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, line 1.
>
> Changing /usr/local/l
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 s
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
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
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 (am
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 MPI
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 :).
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 f
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 w
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 build
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
> betw
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 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 se
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, t
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 i
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 bo
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
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
> meant
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 TIM
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
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 as
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 reintr
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 po
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 i
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
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 sti
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-
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 Na
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 th
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
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 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 /usr/in
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 da
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
sta
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
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
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
> |
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
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 inste
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
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
http://packages.qa.debi
including the .la files was OK. The question I asked myself 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
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
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
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
> di
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 fi
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 man
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 be
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 s
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 v
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 thi
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
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 thought
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
> be
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 investigat
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 libmes
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.
Thank
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
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
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 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 o
[ 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
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 th
94 matches
Mail list logo
