On Fri, 13 Jan 2017 16:48:22 +0100 Hagen Fuchs wrote:
>
> > mshr needs a patched version of CGAL.
>
> Ouf. Anything I can do or is it simply a matter of just waiting for
the
> maintainers?
>
Johannes has prepared a de-CGALed version in his
johannr/optional-use-system-packages branch at
http
On Fri, 17 Mar 2017 10:47:26 +0800 Drew Parsons
wrote:
>
> Hi Stephen
My apologies, your name is Steve not Stephen!
D.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Looks like the PIE contradictions between dpkg and gcc have been
smoothed out across the board. petsc 3.7.5 now builds on all
architectures (except kfreebsd and a couple of build-deps on oth
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
For some reason the build on mips64el missed slepc and scotch. I
suspect the failure was related to the PIE settings on dpkg/gcc, now
fixed.
PETSc 3.7.5 is now built on powerpc and sparc64.
On Thu, 16 Mar 2017 10:28:09 +0100 Mattia Rizzolo
wrote:
> On Thu, Mar 16, 2017 at 11:01:10AM +0800, Drew Parsons wrote:
> > The hurd failure looks like the common problem arising from the
changes
> > in PIE handling, see bugs #848129, #854061, same as the FTBFS on
other
&
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
petsc 3.7.5 is now built on kfreebsd. slepc should be rebuilt to match.
nmu slepc_3.7.3+dfsg1-5 . kfreebsd-amd64 kfreebsd-i386 . unstable . -m "Build
against PETSc 3.7.5."
-- System Inform
Source: dolfin
Version: 2016.2.0-3
Severity: normal
petsc and slepc are available on kfreebsd. But dolfin configuration
is unable to activate their support due to a linking error during
configuration tests. SCOTCH support also fails. A snippet from the
log gives:
-- Checking for package 'PETS
On Wed, 08 Feb 2017 14:25:12 +0100 =?ISO-8859-1?Q?S=E9bastien?=
Villemot wrote:
>
> I don't know what's the proper solution to this issue. The
circularity
> can easily be dealt with (using patchelf for closing the loop in
> DT_NEEDED entries).
>
> The problem is rather that the Cblacs_pinfo symb
On Tue, 21 Mar 2017 10:50:29 +0800 Drew Parsons
wrote:
>
> That document is from 1997 though. The MPI standard has moved
through
> 2 major versions since then. But blacs remains unchanged.
Further, BLACS is now part of (packaged with) scalapack, see
http://netlib.org/scalapack/scalap
On Tue, 28 Feb 2017 10:46:53 + Santiago Vila
wrote:
> Package: src:mpi4py
> Version: 2.0.0-2
...
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> but it failed:
...
> MPI.Win.Create(None, 1, MPI.INFO_NULL, MPI.COMM_SELF).Free()
> File "MPI/Win.pyx", line 73, in
On Wed, 2017-03-08 at 11:30 +0100, Andreas Tille wrote:
> Hi Drew,
>
> ... your suggestion to
> turn an error about "invalid window" into a warning seems to be an
> apropriate action in this case.
Thanks Andreas.
> May be the bug could be reopened later with lower severity to make
> sure
> the i
On Wed, 2017-03-08 at 14:19 +0100, Andreas Tille wrote:
>
> Perfect. I was just wondering whether closing + reopening is
> somehow
> easier to handle technically since testing migration requires closing
> an RC bug - but yes, we both mean the same in the end.
That's a fair point. For the sake o
.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From dd69f5f6bafeb518cd236ca167aff5233ab0daeb Mon Sep 17 00:00:00 2001
From: Drew Parsons
Date: Fri, 10 Mar 2017 11:53:14 +0800
Subject: [PATCH 1/2] NMU: fix FTBFS by tre
On Wed, 15 Feb 2017 13:45:41 + James Cowgill
wrote:
> >
> > Please look for already reported bugs before reporting new ones
(there
> > is an "affect" so it is in libpetsc3.7.5-dev bugs list).
>
> Well I did check petsc (not release.debian.org), but affects on
binary
> packages don't actually
On Wed, 15 Feb 2017 23:40:57 +0800 Drew Parsons
wrote:
>
> the Affecting Bug shows up neither on the src:petsc
> overview on bugs.debian.org, nor in reportbug (for libpetsc3.7.5-
> dev).
> I'll file a bug (or 2 bugs).
>
In fact already reported.
#544812 against re
On Sun, 12 Feb 2017 20:16:06 +0100 Emilio Pozuelo Monfort wrote:
> >
> > A binNMU seems to be sufficient here.
> >
> > nmu petsc_3.7.5+dfsg1-4 . ANY . unstable . -m "Rebuild with openmpi 2.0.2"
>
> We should probably wait until petsc migrates, and then maybe not do
this unless
> we unblock open
On Thu, 16 Feb 2017 15:12:23 +0800 Drew Parsons
wrote:
>
> petsc 3.7.5+dfsg1-4 has now hit testing.
>
Hi again. There's some discussion on what to do about openmpi in
testing (#855217). Regardless of how we resolve that, can I
affirmatively request we trigger the binNMU for pet
I suspect (or at least wonder if) the FTBFS on petsc [1] might be
relevant to this discussion. I haven't had time to debug fully, but
petsc started failing to build on Tier 2 architectures after the pie
defaults changed. petsc builds libraries, so the build explicitly uses
-fPIC. Currently of the 2
Package: quantum-espresso-data
Version: 6.0-3
Severity: normal
The quantum espresso documentation refers to example files, located at
"PW/examples" (and also tests in PW/tests).
It would be helpful if these could be included in the Debian package
(whether -data or a new -examples package).
--
Package: quantum-espresso-data
Version: 6.0-3
Severity: normal
The general documentation e.g.
http://www.quantum-espresso.org/wp-content/uploads/Doc/pw_user_guide/node8.html
says details on input fields are found in PW/Doc/INPUT_PW.html. But
this documentation is not in the Debian package.
Actua
On Fri, 2017-05-05 at 09:12 +0200, Michael Banck wrote:
> Hi Drew,
>
> On Thu, May 04, 2017 at 06:56:43PM +0800, Drew Parsons wrote:
> > Package: quantum-espresso-data
>
> Quantum ESPRESSO also needs a bump to the next major version I think.
Yeah, v6.1 recently release
>
> 2m18.4s INFO: Warning: Package purging left files on system:
> /etc/alternatives/petsc3.7 -> /usr/lib/petscdir/3.7.4/x86_64-linux-
gnu-real not owned
> /etc/alternatives/petsc3.7-real -> /usr/lib/petscdir/3.7.4/x86_64-
linux-gnu-real not owned
> /usr/lib/petscdir/ owned by: l
dev packages, we don't
+simply Recommend them.
+ * Move petsc3.7 and petsc3.7-real alternatives handling from
+libpetsc3.7-dev to libpetsc3.7.5-dev. Similarly petsc3.7-complex.
+Otherwise alternatives for older patch versions are left unowned.
+Closes: #852514.
+
+ -- Drew P
libslepc3.7-dev to libslepc3.7.3-dev. Similarly slepc3.7-complex.
+Otherwise alternatives for older patch versions will be left
+unowned after upgrading. cf. bug#852514.
+
+ -- Drew Parsons Mon, 06 Feb 2017 16:04:17 +0800
+
slepc (3.7.3+dfsg1-4) unstable; urgency=medium
* patch-specifi
Package: ftp.debian.org
Severity: normal
The acecad X driver is abandoned upstream since 2011, see
https://cgit.freedesktop.org/xorg/driver/xf86-input-acecad/commit/?id=9131acd655869cd474188cc579a44b43554a317b
It does not build, see Bug#846696.
Not much point keeping it around.
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: mshr
Version : 1.6.0
Upstream Author : Benjamin Kehlet
* URL : http://fenicsproject.org/
* License : GPL3+, LGPL
Programming Lang: C++, Python
Description : generates simplicial
> make[4]: *** No rule to make target '/usr/lib/libgl2ps.so', needed by
> 'dolfin/libdolfin.so.1.6.0'. Stop.
I suspect this is transient and arises from a dependent package (vtk6 I
think). A new version of gl2ps is flushing through, upgrading to
multiarch.
Drew
Package: xpdf
Version: 3.04-1
Severity: normal
>From the man page, command line option -z should control the
initial zoom when xpdf loads up a file. But it does nothing, whether
is a number (percentage) or text (page,height).
Bug #737628 reports that the X resource: Xpdf.initialZoom is also
br
Package: cups
Version: 1.7.5-1
Severity: normal
A phantom printer appears in the printer list of my GUI applications
e.g. in evince and gimp and iceweasel, but curiously not in
LibreOffice or karbon or konquerer.
I call it "phantom" because it does not appear in the admin printer
list, not in Gno
On Wed, 13 Apr 2016 18:59:22 +0800 Drew Parsons
wrote:
>
> Any ideas what to do next? Â The openmpi bug (#818909) still has some
> unfinished business with chrpath for mips architectures to remove the
> workaround applied in 1.10.2-12. Could this generate a deadlock in
one
> pets
block 816101 by 818909
severity 816101 important
retitle 816101 FTBFS on mipsel - broken openmpi breaks petsc build
thanks
openmpi on mips seems to be in a sorry state at the moment.
Indeed, even though the petsc builds halts on the fortran test, there
is an mpicc segfault earlier in the log at "
You're quick :)
Thanks for the tips. I'm intending to remove the links in /usr/lib,
converting alternative petsc.so to petsc.so.multiarch (i.e. use only
pure multiarch links with no legacy links.) Hopefully your discussions
can help sort that out.
Drew
On Mon, 21 Mar 2016 16:53:46 +0100 Gilles Filippini
wrote:
>
> Trying the mpicc.openmpi command on mips* porterboxes, it appears
that
> it segfault on mips and mipsel:
>
> pini@etler:~/debian/hdf5$ schroot -r -c pini1
> (sid_mipsel-dchroot)pini@etler:~/debian/hdf5$ /usr/bin/mpicc.openmpi
--showm
reopen 346182
reassign 346182 libvtk6.2
thanks
This bug is still present for the same test file.
A gdb backtrace pins it on vtkVRMLImporter::exitField()
from /usr/lib/x86_64-linux-gnu/libvtkIOImport-6.2.so.6.2,
which is in package libvtk6.2.
It's essentially the same backtrace as before, only
Package: python-openbabel
Version: 2.3.2+dfsg-2.2+b1
Severity: normal
Whenever a doc-base update is triggered (by any package), the
following error is thrown:
Processing triggers for doc-base (0.10.7) ...
Processing 2 changed doc-base files, 2 added doc-base files...
Error while merging /usr/shar
Hi Giacomo, which version of stable are you currently using? Not wheezy
at the moment?
The current petsc in unstable/testing is 3.6.4 (soon to be updated to
3.7). slepc is closely bound to petsc of course (also v3.6 moving soon
to 3.7)
wheezy fails on these petsc build-depends:
mpi-default-dev
On Fri, 22 Apr 2016 18:25:41 +0200 Graham Inggs
wrote:
>
> Your luck ran out, the build failed on powerpc [1].
Well dang.
I've prepared a patch (test_mpi_conditional) to skip the 2 MPI test.
I'm making it conditional to skip only on mipsel and powerpc, on the
grounds that it's useful feedback
Package: ftp.debian.org
Severity: normal
ufc is now obsolete, superseded by ffc
Package: ftp.debian.org
Severity: normal
syfi is obsolete, no longer used in the FENiCS suite
Package: ftp.debian.org
Severity: normal
ferari is obsolete, no longer used in the FENiCS suite
Package: ftp.debian.org
Severity: normal
viper is no longer used in the FENiCS suite
forcemerge 821215 822255
thanks
822255 was mistitled, it refers to python-netcdf not python-numpy
Package: cups-server-common
Version: 1.7.3-6
Severity: normal
/usr/share/cups/doc-root/index.html (or
/usr/share/doc/cups/online-docs/index.html) contains links to documentation,
mostly to files in /usr/share/cups/doc-root/help/. But the link
"Adding Printers and Classes" points to
/usr/share/cups
On Thu, 2014-07-10 at 07:52 +0200, Didier 'OdyX' Raboud wrote:
>
> That's normal. These (symlinked) documentation hierarchies are the
> source of the cups webinterface, normally accessible locally under
> http://localhost:631/ , where http://localhost:631/admin works (or
> should at least).
Ah
On Fri, 2014-07-18 at 15:25 +0100, Pedro Beja wrote:
> version: 3.12.2-1
>
> this is an old bug.
>
> I'm closing this bug now since it seems to be fixed.
>
> If you can still reproduce it feel free to reopen and provide more
> info.
Agreed, it seems to be fixed now.
gnomevfs-info (libgnomevf
Package: python-dolfin
Version: 1.5.0-2
Severity: grave
Justification: renders package unusable
The dolfin python package fails to import:
$ python
Python 2.7.10rc1 (default, May 11 2015, 04:32:37)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f
Package: libmpich-dev
Version: 3.1-6
Severity: grave
Justification: renders package unusable
/usr/include/mpich/mpicxx.h has a hardwired dependency on the gcc used
to build mpich (gcc 5.2):
#ifdef __GNUC__
# if __GNUC__ >= 5
# if __GNUC_MINOR__ > 2 && 2 == 2
# error 'Please use the same vers
block 803477 807318
thanks
Testing the petsc build on s390x yields this error
# error 'Please use the same version of GCC and g++ for compiling MPICH and
user MPI programs'
The error comes from /usr/include/mpich/mpicxx.h:
#ifdef __GNUC__
# if __GNUC__ >= 5
# if __GNUC_MINOR__ > 2 && 2 ==
Package: valgrind
Version: 1:3.11.0-1
Severity: normal
I'm rebuilding PETSc (petsc-dev 3.6.1). During build configuration, it says
that building petsc with valgrind support is HIGHLY recommended, and
they provide simple configuration flags to do so.
petsc with valgrind support switched on compile
On Wed, 5 Aug 2015 16:17:54 +0200 Martin Pitt wrote:
> tag 791238 patch
> user release.debian@packages.debian.org
> usertag 791238 + transition
> block 791238 by 790756
>
> Hello,
>
> this is a debdiff which we uploaded to Ubuntu (aside from some formal
> debian/changelog differences). As de
The rtupdate scripts are not part of PETSc, they are automatically
installed by dh_python2.
Is this a bug in dh_python2 ?
This one's a mystery ... "works for me"
i.e. my upload was built successfully with sbuild.
Drew
On Fri, 23 Oct 2015 10:21:35 +0800 Drew Parsons
wrote:
> This one's a mystery ... "works for me" Â
> i.e. my upload was built successfully with sbuild.
>
We diagnosed the problem on irc (i.e. why it was "working for me"): the
default sbuild configuration
On Wed, 28 Mar 2012 23:59:54 +0200 Michael Banck
wrote:
>
> Thanks to Johannes Ring, I have been made aware of this work-around
(see
> http://lists.debian.org/debian-science/2012/03/msg5.html):
>
> export OMPI_MCA_plm_rsh_agent=/bin/false
This flag works but now generates a "deprecated" war
Package: sbuild
Version: 0.66.0-2
Severity: normal
sbuild by default assigns the user building the package as the
Maintainer listed in the changes files. That is, sbuild ignores the
Maintainer: field in debian/control.
This means a natural use of sbuild to build a team-maintained package
results
On Thu, 29 Oct 2015 01:52:50 +0100 gpe92 wrote:
>
> Since the update to gnome-shell 3.18 the login takes very long time
> (more than 1 minute) and after there is a processus 'gnome-shell
> --mode=gdm' which consumes 20% of CPU all the time.
Have you got extensions installed?
There's a suggestio
Package: numlockx
Version: 1.2-6
Severity: normal
numlockx provides /etc/X11/Xsession.d/55numlockx, which is intended to
automatically activate numlock when X starts.
It contains code to look for a USB keyboard when used on a laptop in
auto mode:
fkb=/lib/udev/findkeyboards
[ -x $fkb ] && /
On Fri, 2014-08-08 at 16:47 -0400, Ariel wrote:
/lib/udev/findkeyboards is part of udev.
>
> https://packages.debian.org/wheezy/amd64/udev/filelist
>
No, it's literally not there. That's the filelist for stable. Compare
udev on unstable, or testing:
https://packages.debian.org/jessie/amd64/udev
On Fri, 2014-10-24 at 22:56 +0200, Hendrik Tews wrote:
>
> What desktop are you using? Does this happen immediately after
> starting emacs or only after visiting a Coq file?
>
I'm using Gnome from unstable (currently gnome-shell 3.14.0-1)
The wrong icon shows up immediately when emacs is invoke
On Sun, 2014-10-26 at 21:58 +0100, Hendrik Tews wrote:
> the problem is the
> line
>
> StartupWMClass=Emacs
>
> in /usr/share/applications/proofgeneral.desktop .
Sounds like it might be tricky to sort out!
Incidentally, after removing that entry, the ProofGeneral icon does
still appear i
I agree with Graham, this is a plain and simple naming clash. The only
reasonable resolution is to rename one (or both) of the binaries.
You could workaround the clash with Conflicts:, but that's not
reasonable either since there's no reason both binaries shouldn't
coexists.
A possible alterna
On Mon, 21 Dec 2015 22:07:59 + Sandro Tosi
wrote:
> this is from top right now:
>
> PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+
COMMAND
> 3716 Debian-
Package: skype
Version: 4.3.0.37-1
Severity: important
skype fails to start up when required libraries are missing. Running
from the command line:
$ skype
skype: error while loading shared libraries: libGL.so.1: cannot open shared
object file: No such file or directory
libGL.so.1 is provided by
On Wed, 2016-02-10 at 17:59 +0200, Graham Inggs wrote:
> In the build logs of a recent rebuild of PETSc [1] for the OpenMPI
> 1.10 transition, I see the following warning (and the build was
> successful):
>
...
> Deprecated variable: orte_rsh_agent
> New variable:plm_rsh_agent
> --
On Thu, 12 Nov 2015 00:49:46 +0800 Drew Parsons
wrote:
> On Thu, 29 Oct 2015 01:52:50 +0100 gpe92 wrote:
> >
> > Since the update to gnome-shell 3.18 the login takes very long time
> > (more than 1 minute) and after there is a processus 'gnome-shell
> > --mode=gd
On Thu, 2015-12-24 at 01:09 +0100, Johannes Schauer wrote:
> Control: tag -1 + unreproducible moreinfo
>
> Hi,
>
> On Tue, 13 Oct 2015 10:58:50 +0800 Drew Parsons
> wrote:
> >
> > sbuild by default assigns the user building the package as the
> > Maintaine
As far as I can tell this build failure is just some ephemeral problem
on the build machine. The same code built before, and builds now on
mips and other architectures. Trigger a rebuild, maybe it will work
now.
The orte/plm warning is a red herring. All architectures have the same
problem. It's
Source: petsc
Followup-For: Bug #816101
The petsc build failure on mipsel appears to be a transient problem on
the build machine. Please try the mipsel build again.
gb petsc_3.6.2.dfsg1-3+b3 . mipsel
On Sun, 2016-03-13 at 17:35 +0100, Emilio Pozuelo Monfort wrote:
> On 13/03/16 16:34, Drew Parsons wrote:
> >
> > Source: petsc
> > Followup-For: Bug #816101
> >
> > The petsc build failure on mipsel appears to be a transient problem
> > on
> > t
On Sun, 2016-03-13 at 19:59 +0100, Emilio Pozuelo Monfort wrote:
> [Adding debian-wb-team back to Cc]
>
> On 13/03/16 17:56, Drew Parsons wrote:
> >
> > On Sun, 2016-03-13 at 17:35 +0100, Emilio Pozuelo Monfort wrote:
> > >
> > > On 13/03/16 16:34, Drew
On Mon, 14 Mar 2016 09:39:04 +0800 Drew Parsons
wrote:
> > Did you read the MOTD? See https://dsa.debian.org/doc/schroot/
>
> I missed that. I'll add it to my bookmarks.
>
>
> > Anyway given the build queue is currently empty on mipsel, I've
given
> > it
Package: openmpi-bin
Version: 1.10.2-8
Severity: normal
openmpi-bin Suggests: openmpi-checkpoint. But there is no such
package in openmpi 1.10.2-8. There was one built fro 1.6.5-11.
Either the Suggests: openmpi-checkpoint should be removed from openmpi-bin.
Or the openmpi-checkpoint package s
Package: python3-instant
Version: 2016.2.0-2
Severity: normal
Testing the new python3 dolfin. It works fine on my own scripts. But
seems to fail when instant is invoked by interpolate.
$ instant-clean-3
$ ipython3
Python 3.5.3 (default, Jan 19 2017, 14:11:04)
In [1]: from fenics import * # do
Package: python-dolfin
Version: 2016.2.0-3
Severity: grave
Justification: renders package unusable
Weird, the new python3 module seems to have broken the python2 dolfin
module. That's not good.
Importing dolfin gives the error:
AttributeError: 'module' object has no attribute 'cpp'
Importing in
reassign 863828 libdolfin-dev 2016.2.0-3
thanks
On Thu, 2017-06-01 at 10:01 +0200, Johannes Ring wrote:
>
> The problem here is that Python 2 header files are used. This comes
> from VTK, which is built against Python 2 only. The solution is to
> not
> call `find_package(VTK)` and `include(${VTK_
On Thu, 1 Jun 2017 10:39:37 +0200 Johannes Ring
wrote:
> On Thu, Jun 1, 2017 at 10:24 AM, Drew Parsons
wrote:
> > Should the vtk section in UseDOLFIN.cmake be controlled with some
> > python3 test, so VTK is still pulled in for python2?
>
> Yes, we can do that, altho
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
scalapack 2.0 has been stabilised in experimental, I think it is now
ready for release in unstable. I have tested various client packages.
The API has not changed, the transition should b
Package: mpi-default-dev
Version: 1.8
Severity: normal
OPENMPI_AVAILABLE_ARCHITECTURES in
/usr/share/mpi-default-dev/debian_defaults does not include m68k.
But openmpi is built on m68k (since 2.1.1-1), so it should now be added.
Similarly, powerpcspe is not listed in
MPICH_AVAILABLE_ARCHITECTURE
On Thu, 2017-08-24 at 03:22 +0200, Cyril Brulebois wrote:
>
> Drew, such conversion from xsfbs to dh should really be accompanied
> by
> a thorough debdiff check:
>
> $ debdiff --controlfiles=ALL ../libxcursor*changes
>
> which makes the breakage obvious:
> > Shlibs files of package libxcursor
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
With stretch released, we plan to upgrade our numerical computational
packages:
scalapack to 2.0.2
mumps to 5.1.1
scotch to 6.0
etc
This transition request concerns mumps. It has been be
Debichem has other molecular viewers and toolkits, I suggest going with
Debichem to fit alongside those packages.
Drew
On Tue, 2017-06-13 at 11:21 +0300, Andrius Merkys wrote:
> Dear Andreas,
>
> thank you for your message. I would gladly maintain my package in
> either
> Debian Science or DebiC
Package: dput-ng
Version: 1.15
Severity: normal
A recent build of libdolfin2017.1 (i.e. dolfin 2017.1.0-1 in main) accidentally
resulted in a
dependency on a non-free package, libparmetis4.0. Consequently the new
package was rejected by ftp-masters.
dput uses the suite-mismatch hook to check the
Package: lintian
Version: 2.5.52
Severity: normal
A recent build of libdolfin2017.1 (i.e. dolfin 2017.1.0-1 in main)
accidentally resulted in a dependency on a non-free package,
libparmetis4.0. Consequently the new package was rejected by
ftp-masters.
It would be a useful service if lintian could
On Sun, 2017-06-25 at 12:23 +0100, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> Hi,
>
> On Mon, Jun 12, 2017 at 08:32:19PM +0800, Drew Parsons wrote:
> > This transition request concerns mumps. It has been behaving itself
> > in
> > experimental and
On Mon, 2017-06-26 at 14:01 +0100, Jonathan Wiltshire wrote:
> On 2017-06-26 13:34, Drew Parsons wrote:
> >
> > Thanks Jon. I'll wait first for dolfin to get out of
> > NEW
> > and stabilise in testing (to make it simpler for any stable users
> > wanting to
On Fri, 2017-06-30 at 11:26 +0200, Emilio Pozuelo Monfort wrote:
> Hi Drew,
>
> On 30/06/17 10:32, Gianfranco Costamagna wrote:
> > Package: release.debian.org
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> > Severity: normal
> >
> > nmu petsc_3.7.5+dfsg1-4 . ANY . unstab
On Fri, 30 Jun 2017 05:56:30 +0300 Adrian Bunk wrote:
>
> This is a release critical bug that should stay open until it is
fixed
> in sid.
nmu has been filed in #866582 which will fix the bug in this instance.
The strict dependency of PETSc on the MPI version (that requires the
rebuild) is a
reopen 865526
retitle 865526 PETSc has strict dependency on MPI version
severity 865526 normal
forwarded 865526
https://bitbucket.org/petsc/petsc/commits/ca70f86ee9db8e69523e0e69f12289c6cab9b4cb?at=jed/mpi-semver
thanks
Reopening to help track upstream handling of PETSc's MPI dependency
logic.
U
On Mon, 2017-07-03 at 10:55 +0200, Emilio Pozuelo Monfort wrote:
>
> I have gone ahead and scheduled the binNMU as this is blocking the
> python3.6
> transition.
Thanks Emilio.
> But please, either get that patch upstreamed and in Debian, or just
> apply it downstream. IMHO it would be better t
Package: python-h5py
Version: 2.7.0-1+b1
Severity: serious
Justification: FTBFS
Your new version of h5py fails to build from source. All arches.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_
On Sat, 2017-09-09 at 13:20 +0200, Emilio Pozuelo Monfort wrote:
>
> > scalapack 2.0 has been stabilised in experimental, I think it is
> > now
> > ready for release in unstable. I have tested various client
> > packages.
> > The API has not changed, the transition should be no more
> > complicate
Package: nwchem
Version: 6.6+r27746-4
Severity: normal
nwchem cannot build on its own, since changes are made to some
upstream files outside of the debian/patches system.
This is caught during dh_clean in dh_auto_clean built on a pbuilder chroot
(pdebuild).
A build log reports:
dh_auto_clean
Package: nwchem
Version: 6.6+r27746-4
Severity: normal
scalapack 2 is now available in unstable. It includes BLACS, so
libblacs-mpi-dev is now deprecated and must be removed from
Build-Depends.
Please update nwchem:
debian/control:
Build-Depends: autotools-dev (>> 20100122.1~),
cs
severity 875267 serious
thanks
Actually the FTBFS occurs for the standard nwchem source (even without
updating to debian/compat 10 or replacing blacs with scalapack 2).
So raising severity to serious.
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
petsc on powerpc got rebuilt for libgfortran4 before it could catch
scalapack2. Please nmu. powerpcspe also needs a fresh build.
nmu petsc_3.7.6+dfsg1-3+b1 . powerpc powerpcspe . unstable .
On Mon, 11 Sep 2017 16:49:51 +0800 Drew Parsons
wrote:
> ... powerpcspe also needs a fresh build.
powerpcspe is already scheduled for a rebuild of +b1, which is good
enough. So we only need to binNMU on powerpc:
nmu petsc_3.7.6+dfsg1-3+b1 . powerpc . unstable . -m "Rebuild against s
On Mon, 11 Sep 2017 09:57:03 +0200 Andreas Beckmann
wrote:
>
> nmu dolfin_2017.1.0-3 . ANY . experimental . -m "Rebuild against
swig3.0 3.0.12."
>
I'm about to push dolfin 2017.1.0 to unstable, as soon as petsc (and
slepc) are up to date, see binNMU at #875407.
Drew
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
Once petsc is rebuilt against scalapack2 on powerpc (binNMU #875407),
slepc will also need to be rebuilt.
dw slepc_3.7.4+dfsg1-2 . powerpc . unstable . -m "libpetsc3.7-dev (>=
petsc_3.7.6+d
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
* Package name: superlu-dist
Version : 5.1.3
Upstream Author : Xiaoye S. Li
* URL : http://crd-legacy.lbl.gov/~xiaoye/SuperLU/#superlu_dist
* License : BSD
Programming Lang: C
Description : Highly
Thanks Takeshi.
Drew
On Sun, 2017-09-17 at 17:32 +0900, Takeshi Hamasaki wrote:
> Package: gworldclock
> Version: 1.4.4-10
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> current GTK application needs to use
> gtk_action_group_set_translation_domain ()
> for menu to be translated. Atta
401 - 500 of 2488 matches
Mail list logo
