Re: Please push your changes to python-xarray

[Graham Inggs]

Hi Alastair, Antonio

On Fri, 29 Dec 2023 at 11:40, Alastair McKinstry  wrote:
> xarray was/is being held back by #1055848 which I think is fixed by
> recent changes to ecmwflibs but the debci tests appear to be hung for
> some reason I don't understand.

Also #1055847, #1056504 and now #1059630, all in python-sparse.

Regards
Graham

Re: Why was Caffe removed from Debian ?

[Graham Inggs]

Hi Matt

On Sun, 12 Feb 2023 at 09:48, lemonsqueeze  wrote:
> Until bullseye caffe deep learning framework was packaged (cpu-only version),
> however looks like it was removed from testing (likewise it's absent in 
> ubuntu jammy).
>
> I'm wondering why it was removed (was pretty stable and useful), however i 
> couldn't find
> the rationale for it. Could someone point to the removal discussion ?

Here you go:

https://bugs.debian.org/1003068

Regards
Graham

Re: scikit-learn Re: Are we still trying to do scipy 1.10, given transition freeze?

[Graham Inggs]

Hi Drew

I think python3-scipy should declare a Breaks on python3-skbio less
than the version in unstable (0.5.8-3).
This should sort out the autopkgtest regressions of emperor,
python-skbio itself, q2-metadata and q2-quality-control, which are all
passing in unstable, and allow scipy and python-skbio to migrate
together.

Python-cooler seems to have a different failure, and I don't see a bug
filed for it.

Regards
Graham

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Graham Inggs]

Hi Andreas

On Fri, 3 Feb 2023 at 12:19, Andreas Tille  wrote:
> Thanks a lot for your always helpful support

You are welcome!

~$ rmadison -u debian -s testing python3-numba
python3-numba | 0.56.4+dfsg-1+b1 | testing| amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x

numba is now in testing and I filed bug #1030379.

Regards
Graham

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Graham Inggs]

Hi

On Thu, 2 Feb 2023 at 21:15, Andreas Tille  wrote:
> I do not see any real chance to fix all issues in numba right in time
> for the freeze.

I do not want to create work for you by suggesting you temporarily
skip the autopkgtests to get numba to migrate.  I also do not want to
hide problems.

I will hint numba 0.56.4+dfsg-1 to migrate to testing now, despite the
autopkgtest regressions, and file an RC bug so we don't lose track of
this. Please don't upload until this has happened.

Regards
Graham

Re: Numba not in testing due to lots of autopkgtest errors - how to proceed

[Graham Inggs]

Hi

On Thu, 2 Feb 2023 at 17:18, Andreas Tille  wrote:
> It seems to me that build time tests are working and the failure is
> just in autopkgtest.  I'm drawing this conclusion from your latest
> push to Salsa where amd64 and i386 were building successfully
...
> I know that's cheating but there is no time for fiddling around here
> any more. We are running the same test as at build-time where it is
> passing so we can assume that numba works.

The build time tests are probably only passing because of a similar
"cheat" [1] committed in 2017.

Regards
Graham


[1] 
https://salsa.debian.org/science-team/numba/-/commit/3d08b6e6fe43400e7640de51d8e5afb5942d79ed

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Graham Inggs]

Hi Drew

On Thu, 26 Jan 2023 at 14:46, Drew Parsons  wrote:
> Ok, if you're happy with those regressions then I'm happy.  In any case,
> I've filed bug reports against them.

Great, thank you!

> I'll try to wait for scipy's own tests (armel, riscv64) before uploading
> to unstable.

riscv64 is not a release architecture (yet) and the hardware is still
a little slow, so it is not enabled for experimental pseudo excuses.

Regards
Graham

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Graham Inggs]

Hi Drew, Andreas

On Wed, 25 Jan 2023 at 17:34, Andreas Tille  wrote:
>
> Am Wed, Jan 25, 2023 at 04:29:59PM +0100 schrieb Drew Parsons:
> > heh yeah, I was just replying about that :)
>
> So at least I was beating you in writing an e-mail! :-P
>
> > Are we confident on bringing scipy 1.10 to the new stable?
>
> In any case we should probably follow Graham's advise to let things
> migrate to testing first.

scipy/1.8.1-22 and numpy/1:1.24.1-2 have just migrated to testing, so
please go ahead with uploading scipy 1.10 to unstable when you're
ready.

> Meanwhile someone with a proper setup might run ratt on it.  I
> personally failed setting up sbuild to get this done but having some
> verification that at least this tool does not uncover serious issues
> would make sense.

Since we don't have to rebuild all the packages involved, I don't
think a test rebuild before uploading is necessary.  I suspect the
packages with failing autopkgtests might also FTBFS, and maybe a few
more that don't have autopkgtests.  We will have test rebuilds of the
archive before release which will catch these.

The experimental pseudo excuses for scipy 1.10.0-1exp6 [1] look good
to me, only 12 regressions.  By the way, we have just enabled these
for the release architectures with autopkgtests, so expect results for
more architectures to appear over the next few hours.

Regards
Graham


[1] https://qa.debian.org/excuses.php?experimental=1=scipy

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Graham Inggs]

Hi Drew

Please do fix #1029550 in 1.8.1 in testing before uploading 1.10.0 to
unstable.  It is one of the last blockers for NumPy.

Regards
Graham

Re: Bug#1022571: transition: pandas 1.3 -> 1.5

[Graham Inggs]

Hi Rebecca, Andreas

On Wed, 25 Jan 2023 at 11:43, Andreas Tille  wrote:
> I was motivated for this patch by Diane's statement on the Debian Med
> matrix channel that dask and dask.distributed are interconnected.  If
> the autopkgtest on Salsa CI[4] would have passed I would have uploaded.

We will temporarily remove dask.distributed from testing, which should
unblock dask and pandas.
No uploads please, until dask and pandas have migrated.

Regards
Graham

Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Graham Inggs]

Hi Markus

On Sat, 21 Jan 2023 at 19:59, Graham Inggs  wrote:
> I noticed there was an upload of opm-common 2022.10+ds-3, but it also
> FTBFS on armhf.  I trust this is on your radar.

It turns opm-common was blocked by python3-defaults and
python3-defaults was blocked by opm-common's FTBFS on armhf.

To break out of the Catch-22, I temporarily removed opm-* from testing
and dune-* migrated together.
opm-* will be able to migrate once the armhf build is fixed, or
opm-common stops building for that architecture.

Regards
Graham

Re: Bug#1022571: transition: pandas 1.3 -> 1.5

[Graham Inggs]

Hi Rebecca

On Tue, 24 Jan 2023 at 00:16, Rebecca N. Palmer  wrote:
> The remaining autopkgtest failures blocking pandas are:
> - dipy/amd64 and snakemake/i386 look like random flakiness: please retry
> them.  (I think DMs can't use the self-service interface.)  Or for dipy,
> see #1029533 for a possible fix.

These have cleared up.

> - python-xarray/i386 looks like xarray not pandas: see #1004869.

Sometimes britney is too greedy and pins too many packages from
unstable.  I managed to find the right combination [1] and got the
test to pass without python-xarray.

> - dask and dask.distributed have to go together, with or before pandas.

There's nothing in the currently uploaded packages that specifies
this, although I do see a commit on salsa [2].
I tried running dask.distributed's autopkgtest with dask and itself
from unstable [3], but no luck.

Regards
Graham


[1] https://ci.debian.net/packages/p/python-xarray/testing/i386/
[2] 
https://salsa.debian.org/python-team/packages/dask.distributed/-/commit/9df3fe1a0ea7538f742ebb162379e3cd50b388e6
[3] https://ci.debian.net/packages/d/dask.distributed/testing/amd64/

Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Graham Inggs]

Hi Markus

On Wed, 18 Jan 2023 at 20:48, Graham Inggs  wrote:
> Almost there, the excuses [1] for dune-common shows:
>
> Migration status: Blocked. Can't migrate due to a non-migratable
> dependency. Check status below.
> Blocked by: opm-simulators/ppc64el
>
>I don't think any action is required, just some waiting.

My apologies, I knew the ppc64el buildd infrastructure was a bit
behind, so didn't look at this closely.  Upon further investigation, I
found that the dune-common transition is entangled with the Python
3.11 transition through opm-simulators.  We will either wait for
Python 3.11, or find a way to disentangle them.

> By the way, excuses [2] for opm-common shows:
>
> Issues preventing migration:
> missing build on armhf

I noticed there was an upload of opm-common 2022.10+ds-3, but it also
FTBFS on armhf.  I trust this is on your radar.

Regards
Graham

Re: Are we still trying to do scipy 1.10, given transition freeze?

[Graham Inggs]

Hi Rebecca

On Wed, 18 Jan 2023 at 23:48, Rebecca N. Palmer  wrote:
> Given that the transition freeze was on 2023-01-12, it's too late to
> move to scipy 1.10 if that's likely to cause significant breakage.  (Do
> we have a guess of whether it will, or do we need a package that builds
> in experimental to test that?)

>From the release team's perspective, this isn't a transition; no new
library package, no binNMUs needed.

It would be good to have scipy 1.10 in testing before the start of the
soft freeze on 2023-02-12, because from that point, only small,
targeted fixes are appropriate [1].

Regards
Graham


[1] https://release.debian.org/bookworm/freeze_policy.html

Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Graham Inggs]

Hi Markus

On Wed, 18 Jan 2023 at 09:59, Markus Blatt  wrote:
> Thanks a lot Graham. That really worked like a charm and seem to finished. 
> Cool.These processes
> and the tools in Debian are really great.

Almost there, the excuses [1] for dune-common shows:

Migration status: Blocked. Can't migrate due to a non-migratable
dependency. Check status below.
Blocked by: opm-simulators/ppc64el

I don't think any action is required, just some waiting.

> Next time I will try to do that myself to avoid confusion.
> Is the upload to NEW for dune-common optional as the package name stays the 
> same?

That's correct.

By the way, excuses [2] for opm-common shows:

Issues preventing migration:
missing build on armhf

Regards
Graham


[1] https://tracker.debian.org/pkg/dune-common
[2] https://tracker.debian.org/pkg/opm-common

Re: Changes for new upstream version (2.9.0) of DUNE (Mini-transition because of OPM)

[Graham Inggs]

Hi Markus

On Tue, 3 Jan 2023 at 02:46, Markus Blatt  wrote:
> Nevertheless opm-grid, opm-material, opm-models, opm-simulators, and 
> opm-upscaling will
> need to be rebuild for the mini-transition. Otherwise they won't work 
> correctly
>
> If it is possible to give me upload rights for the DUNE packages, then I 
> could do the
> upload/transition work myself, too. But I would still require some guidance 
> (next steps, etc.)
> and don't want to step on other people's toes.

I found out about this transition after an Ubuntu developer asked me
to schedule binNMUs for some opm-* packages.  In future, you can
follow steps described [1] and file a transition bug against
release.debian.org. For now, I have scheduled binNMUs for opm-grid,
opm-material, opm-models, opm-simulators, and opm-upscaling.

I've also set up a transition tracker [2], with the following ben file:

title = "dune-common-2.9.0";
is_affected = .depends ~ /libdune-common-2/;
is_good = .depends ~ /libdune-common-2\.9/;
is_bad = .depends ~ /libdune-common-2\.8/;
notes = "https://lists.debian.org/debian-science/2023/01/msg1.html;;
export = false;

Please let us know if anything else is needed.

Regards
Graham


[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
[2] https://release.debian.org/transitions/html/dune-common-2.9.0.html

Re: transition: pandas 1.3 -> 1.5

[Graham Inggs]

Hi Rebecca

On Fri, 6 Jan 2023 at 10:30, Rebecca N. Palmer  wrote:
> Should this go ahead before the freeze?  I think yes if the new dask
> works, but am open to disagreement.

Please go ahead.  With numpy 1:1.24.1-2 built on all release
architectures, now is a good time.

Regards
Graham

Re: scikit-learn testing migration

[Graham Inggs]

Hi

On Wed, 27 Jul 2022 at 17:57, M. Zhou  wrote:
> The previous segfault on armel becomes Bus Error on armel and armhf.
> I can build it on Power9, but it seems that the test fails on power8 (our 
> buildd).

In #1003165, one of the arm porters wrote they are happy to look at
the bus errors, but the baseline issue should be fixed first.

> I have skimmed over the build logs and one of the main issues is the use of
> -march flags to enforce a certain baseline [1]:
>
> powerpc64le-linux-gnu-gcc: error: unrecognized command-line option 
> ‘-march=native’; did you mean ‘-mcpu=native’?

This may be the cause of the test failures on power8.

Regards
Graham

Re: transition: pandas 1.1 -> 1.3

[Graham Inggs]

It might be easier to upgrade to 1.2.4 first, then 1,3,x later.

Re: ownership transfer of some pckages from science team to deep learning team

[Graham Inggs]

On Mon, 19 Oct 2020 at 07:57, Michael R. Crusoe  wrote:
> Feel free to move tensorflow to a good home, yes!

Done!

Re: ownership transfer of some pckages from science team to deep learning team

[Graham Inggs]

Hi

On Sun, 18 Oct 2020 at 22:03, Mo Zhou  wrote:
>  1. caffe (educational deep learning framework)
>  2. onednn (intel's CPU/SYCL-based deep learning acceleration library)
...
> Ok, could any science team owner help me transfer those mentioned repos?

Done!

Michael, please let me know whether I should move tensorflow as well.

Regards
Graham

Re: Should the pandas 1.x transition be forced (breaking python-biom-format and q2-demux/q2-types) or keep waiting?

[Graham Inggs]

Hi Rebecca

On Mon, 24 Aug 2020 at 01:03, Rebecca N. Palmer  wrote:
> pandas 1.0 has been in experimental for 6+ months, because it breaks
> some of its reverse dependencies:
...
> Ubuntu freezes this Thursday, but I suspect I may have left this too
> late for that.

We can sync 1.0.4+dfsg-1 from experimental to Ubuntu right now if you want.

Regards
Graham

Re: PyZoltan (Was: RE: [RFS] zarr, numcodecs and asctree)

[Graham Inggs]

Hi Antonio

On Thu, 23 Apr 2020 at 08:07, Antonio Valentino
 wrote:
> Thank you for proposing me to become a DM.
> Unfortunately it is a problem to me to get my key signed by a DD.

Please add yourself here:
https://wiki.debian.org/Keysigning/Need

Regards
Graham

Re: Missing dependancies for streamlit

[Graham Inggs]

On Tue, 7 Apr 2020 at 12:46, Andreas Tille  wrote:
>
> On Tue, Apr 07, 2020 at 11:15:17AM +0100, Rebecca N. Palmer wrote:
> > A potential workaround for testing: while package builds (including
> > build-time tests) are not allowed to use the network, autopkgtests *are*
> > allowed to => skip the tensorflow-needing tests in build, but run them (with
> > tensorflow from PyPI) in autopkgtest?
>
> Are you sure that autopkgtests *are* allowed to?  That's new to me.

See: https://bugs.debian.org/954150
src:ffc: Requires a package outside of Main

Re: Broken package in testing repository

[Graham Inggs]

Control: severity -1 serious

Hi Alexander

On Wed, 25 Mar 2020 at 18:15, Alexander van der Meij
 wrote:
> As described in bug 951634, Debian is currently distributing a broken 
> development build of the software of which I am the developer; gummi.
>
> Hereby my request to either bump the package to the stable (0.8.1) release or 
> remove it from your repositories altogether.

I've raised the severity of this bug.  It should be auto-removed if
there is no action from the maintainer.

Regards
Graham

Re: RFR: src:lapack's 64bit-indexing variant

[Graham Inggs]

Hi Mo

On Sat, 21 Sep 2019 at 07:07, Mo Zhou  wrote:
> mips64el, s390x, ppc64, sparc64, they are not
> typical architectures used for intensive
> scientific computing.

Besides the slow mips64el, the other architectures are all big-endian, 64-bit.
I note the build was successful on powerpc (big-endian, 32-bit) so my
guess is somewhere a 64-bit variable is accessed as a 32-bit variable,
which happens to work on little-endian, but not on big-endian.

e.g. a loop counter that is initialized as 64-bit, but decremented as 32-bit.

Regards
Graham

Re: scientific python stack transitions

[Graham Inggs]

On Sat, 10 Aug 2019 at 09:03, Rebecca N. Palmer  wrote:
> Autopkgtest failure:
> https://autopkgtest.ubuntu.com/packages/python-scipy/eoan/amd64
>
> (Though I'm not sure why they're calling something that's been failing
> since before their last release a "regression"...)

That requires some manual hinting.  I'll try to prod ubuntu-release
during this coming week.

Re: MPI debugging workflows

[Graham Inggs]

Hi

On 30 August 2018 at 10:39, Drew Parsons  wrote:
> It's a comedy of errors with openmpi3, I see 3.1.2 has triggered new RC bugs

To be clear, 3.1.2 didn't introduce any new RC bugs.  The bugs you see
here [1] affect the version in testing and should not block migration.

What is delaying openmpi's migration is dolfin's autopkgtest failure [2].

Regards
Graham


[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=openmpi=no=pending-fixed=fixed=done=critical=grave=serious=no
[2] https://qa.debian.org/excuses.php?package=openmpi

can we disable the bounce kicker? Re: confirm

[Graham Inggs]

Hi List Maintainers

As per:
https://lists.debian.org/debian-python/2018/06/msg00045.html

Would you consider disabling the bounce kicker for debian-science and
debian-med please?

Although, I am more affected by the debian-med-packaging and
debian-science-maintainers lists.

Regards
Graham

Re: Getfem++ is looking for new maintainers

[Graham Inggs]

Hi Kostas

Thanks for the quick response!

On 30/05/2018 19:27, Konstantinos Poulios wrote:

If there aren't any other volunteers I can take over again but I will need
to freshen up my debian maintenance skills. Are there any pending tasks to
work on regarding getfem? The next upstream version is planned for July.


There is nothing to be done right now with getfem, the package is still 
in good shape.


I suggest filing a RFA (Request for Adoption) bug [1] against getfem, 
and hopefully someone steps up in time for the release of the new 
upstream version.  Shall I file this bug on your behalf?


Regards
Graham


[1] https://www.debian.org/devel/wnpp/#l2

Getfem++ is looking for new maintainers

[Graham Inggs]

Hi Konstantinos Poulios

Are you still interested in maintaining getfem++ in Debian?

If not, we need to find new maintainers or orphan the package.

Regards
Graham

Re: Freecad is looking for new maintainers

[Graham Inggs]

On 26 May 2018 at 22:43, Sebastian Kuzminsky  wrote:
> Thank you for the offer, but I think I can't be an uploader, because I'm
> not a DM/DD.  I'll be content contributing via commits on salsa for now.

Sure you can. :)
Uploaders are just the co-maintainers of the package [1].
The Maintainer field in this case is:
Debian Science Maintainers 


[1] https://www.debian.org/doc/debian-policy/#s-maintainer

Re: Freecad is looking for new maintainers

[Graham Inggs]

I recently pushed some changes to Freecad on Salsa [1].
I'd like to update the Uploaders field and upload soon, unless one of
the prospective uploaders wishes to make any other changes, in which
case I am happy to sponsor.

Sebastian Kuzminsky, I take it I can add you as an uploader?
Filippo Rusconi, are you in too?


[1] https://salsa.debian.org/science-team/freecad/commits/master

Re: Freecad is looking for new maintainers

[Graham Inggs]

Hi Adam

Please let us know if you intend maintaining the freecad package going 
forward.


Teemu and Anton will no longer be maintaining it (see below), so if you 
won't be maintaining it, I agree with Sébastien that orphaning the 
package would better match reality.


Regards
Graham


On 23/05/2018 23:41, Sébastien Villemot wrote:

Hi Anton,

On Wed, May 23, 2018 at 11:17:35PM +0200, Anton Gladky wrote:


freecad_0.16.6712+dfsg1-2 has just been uploaded and
two of its maintainers (me and Teemu) decided not to maintain
this package any more. Adam, which is currently the only
one in "Uploaders"-field seems to be not active for a long time.

I am not orphaning the package because it is team-maintained.
But it would be good if somebody could take over the package.


IMO, it's better to orphan the package, to make it clear that it has no active
maintainer. Otherwise that critical piece of information may go unnoticed for a
long time by third parties, including potentially interested maintainers. And
this doesn't prevent the future maintainer from keeping it in Debian Science.

Best,

Re: sponsor for trilinos 12.12.1 bump

[Graham Inggs]

On 17 November 2017 at 21:52, Nico Schlömer  wrote:
> I've fixed the typo in in the lintian-override and a few other small things.
> If you want to upload 12.12.1-2, I'd say it's good to go.

Sponsored, thanks!

Re: sponsor for trilinos 12.12.1 bump

[Graham Inggs]

Hi Nico

I've just uploaded trilinos 12.12.1-1.  I had to upload source + 
binaries because of the NEW libtrilinos-kokkos-kernels* and 
libtrilinos-trilinosss* binary packages.


After building, I noticed that:

https://anonscm.debian.org/cgit/debian-science/packages/trilinos.git/commit/?id=88ccfbeb02d72b1a1dc3acc49ceaf3950c1150ac

should have had libtrilinos-tpetra%V instead of libtrilinos_tpetra%V
Please wait until -1 has passed through binNEW before fixing in git.

Regards
Graham

Re: sponsor for trilinos 12.12.1 bump

[Graham Inggs]

On 1 November 2017 at 12:30, Nico Schlömer  wrote:
> The corresponding folder in the Trilinos tree is `packages/kokkos-kernels`,
> and renaming to kokkoskernels will make the build logic fail (see d/rules).
> The easiest thing probably is to to add another lintian exception; let me go
> ahead and do that.

Works for me. :)

> I'll submit the build to launchpad today and will let you know if it
> completes successfully.

I was able to run Lintian locally in Ubuntu against the binaries I
built with sbuild for Debian unstable, so I'm sure you'll be able to
do the same with binaries built in a PPA.  Always try to install the
latest Lintian from unstable, or build it locally if you need to.

Re: Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)

[Graham Inggs]

On 12 October 2017 at 19:01, Dirk Eddelbuettel  wrote:
> So we did this 71 times, but stopped 4+ years ago.  Not sure what got the
> toolchain coughing, but I guess we could try again.

That would be great, thanks!

Re: Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)

[Graham Inggs]

Hi Dirk

On 12/10/2017 16:37, Dirk Eddelbuettel wrote:

And yes, the hint re 3.5 being shaky leads itself to uploading to experimental.


Would you please consider versioning such uploads as 3.5~something 
instead of 3.4.something?


e.g. your second-to-last upload of r-base was 3.4.1.20170921-1
I think it would have been clearer if it were versioned 3.4.2~20170921-1 
or even 3.4.2~rc1-1


This also allows for things like Depends: r-base-core (>= 3.4.2~) should 
they ever be needed.


Regards
Graham

Re: Bug#875859: nmu: julia_0.4.7-7

[Graham Inggs]

On 15/09/2017 12:38, Matthias Klose wrote:

On 15.09.2017 12:04, Graham Inggs wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pkg-julia-de...@lists.alioth.debian.org

Dear Release Team

Openblas recently switched to multiarch and Julia needs to be rebuilt in order
to pick up the new location of libopenblas.  Please schedule the following 
binNMU:

nmu julia_0.4.7-7 . ANY . -m 'Rebuild against multiarch openblas'


same for vips.



You probably mean visp, which FTBFS on i386 (#871414), is RC buggy due 
to a license violation (#856703), and is not in testing.


If it is not being maintained, it should be removed rather.

Re: Unable to browse r-cran-sp VCS

[Graham Inggs]

On 24/07/2017 16:16, Graham Inggs wrote:
I'll ask alioth admins to remove /cvs/debian-science and hopefully it 
doesn't get created again!


Fixed now.

Re: Unable to browse r-cran-sp VCS

[Graham Inggs]

On 24/07/2017 14:13, Andreas Tille wrote:

I tried to change to Git but may be there is some delay until this gets
propagated.  At least the change is not visible on the web page yet.


Thanks, I see the change on
https://alioth.debian.org/projects/debian-science/

I'll ask alioth admins to remove /cvs/debian-science and hopefully it 
doesn't get created again!

Re: scalapack 2.0 now in experimental

[Graham Inggs]

Hi Drew

On 19/07/2017 17:06, Drew Parsons wrote:

scalapack 2.0 is now available in experimental.  It's quite a big
transition (absorbing blacs, most notably) so we'll want to test
dependent packages before dropping it into unstable.  We need to check
the transition from blacs to scalapack is smooth.

Can you tell us (or commit to the scalapack git directly) if we need
any tweaks to keep elpa, c2pk and espresso happy?

scalapack now builds with cmake and we may want to change the way we
install its cmake scripts. pkg-config also.  We've built both openmpi
and mpich versions.


Thanks for your work on this!

I plan to enable scalapack support in gpaw soon (it requires >= 2.0.1) 
and will let you know if any tweaks are required.


Regards
Graham

Re: Unable to browse r-cran-sp VCS

[Graham Inggs]

No debian-science admins around?


On 17 July 2017 at 11:01, Graham Inggs <gin...@debian.org> wrote:
> Hi
>
> Again the debian-science SVN webview is being obscured by the empty
> CVS, making the VCS browser return 404 for packages still maintained
> in SVN, e.g. r-cran-sp [1], also the debian science top level appears
> empty [2].
>
> A month ago, Alexander Wirt renamed /cvs/debian-science to
> /cvs/debian-science.delete on Alioth and the problem went away.
>
> The problem is back now, and I can see that /cvs/debian-science was
> recreated.  The debian-science project on Alioth page [3] shows 'SCM
> Repository (CVS: 0 commits, 0 adds)',  Would one of the project admins
> please change this to Git from the project page by clicking on the SCM
> tab, then Administration, then selecting the Git radio button and
> clicking Update?
>
> Regards
> Graham
>
>
> [1] 
> https://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-sp/trunk/
> [2] https://anonscm.debian.org/viewvc/debian-science/
> [3] https://alioth.debian.org/projects/debian-science/

Re: Unable to browse r-cran-sp VCS

[Graham Inggs]

Hi

Again the debian-science SVN webview is being obscured by the empty
CVS, making the VCS browser return 404 for packages still maintained
in SVN, e.g. r-cran-sp [1], also the debian science top level appears
empty [2].

A month ago, Alexander Wirt renamed /cvs/debian-science to
/cvs/debian-science.delete on Alioth and the problem went away.

The problem is back now, and I can see that /cvs/debian-science was
recreated.  The debian-science project on Alioth page [3] shows 'SCM
Repository (CVS: 0 commits, 0 adds)',  Would one of the project admins
please change this to Git from the project page by clicking on the SCM
tab, then Administration, then selecting the Git radio button and
clicking Update?

Regards
Graham


[1] https://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-sp/trunk/
[2] https://anonscm.debian.org/viewvc/debian-science/
[3] https://alioth.debian.org/projects/debian-science/

Re: tbb git?

[Graham Inggs]

Hi Steve

On 9 July 2017 at 15:27, Steven Capper  wrote:
> I have pulled down the tbb git repo and applied changes locally for
> 2017~U7-1~exp1, but I am unable to push the changes back.
> I'm a Debian Maintainer not a DD, so don't have a full Debian account.
> I have a temporary account "capper" for porting that has my SSH keys
> set up, and I have tried the remote:
> upstream ssh://cap...@git.debian.org/git/debian-science/packages/tbb.git 
> (push)
>
> But that has not accepted my key, do I need to send off a request to
> do something with my porting account (maybe it's expired) or should I
> send my ssh keys somewhere to be able to upload?

I think you need to request to join debian-science, there is a link at
the bottom of the project page on Alioth:
https://alioth.debian.org/projects/debian-science/

Regards
Graham

Re: tbb git?

[Graham Inggs]

On 03/07/2017 13:07, Nico Schlömer wrote:

Luckily, the maintainer Steven (cc'd) is super responsive, so transitioning
to a debian-science repo should be no problem.


That's great!


@Graham, can you set one up for us and populate it with the latest tbb from
Debian [1]? We could then go ahead and polish it up.


Here you go:

git clone ssh://git.debian.org/git/debian-science/packages/tbb.git

It is also visible at:

https://anonscm.debian.org/cgit/debian-science/packages/tbb.git/

BTW, I deviated slightly from Sébastien's suggestion and ran:

gbp import-dscs --debsnap --pristine-tar tbb

Re: tbb git?

[Graham Inggs]

Hi Nico

On 03/07/2017 11:12, Sébastien Villemot wrote:

Since this process is likely to take time, you can also work on an NMU
in the meantime.


Below is a list of tbb's reverse dependencies and the team (if any) that 
maintains them.


bowtie  debian-med
bowtie2 debian-med
flexbar debian-med
salmon  debian-med
blender debian-multimedia
deal.ii debian-science
gazebo  debian-science
mathicgbdebian-science
opencv  debian-science
openturns   debian-science
trilinosdebian-science
madness debichem
mpqc3   debichem
tiledarray  debichem
hhvmhhvm-team
openvdb none

Mostly debian-science, then debian-med and debichem.  I think 
debian-science would be a good home for this package and you should have 
no trouble finding sponsors, and I agree with everything else Sébastien 
wrote.


You probably are aware, but for reference, Ubuntu has a new upstream 
version [1] which builds on s390x.


Regards
Graham


[1] https://launchpad.net/ubuntu/+source/tbb/+changelog

Re: Unable to browse r-cran-sp VCS

[Graham Inggs]

Hi Andreas

On 15/06/2017 10:10, Andreas Tille wrote:

I can confirm that

 https://anonscm.debian.org/viewvc/debian-science/

looks completely empty (not only for r-cran-sp).  Since Debian Med SVN looks
OK this seems to be a special issue of Debian Science SVN.  I have no idea
how this happened and what to do.


Thanks for confirming!

I asked on #alioth and jcristau suggested it might be because 
/cvs/debian-science exists, and that is probably what we are seeing.


I think we need an Alioth admin to rename /cvs/debian-science to 
/cvs/debian-science.delete and then remove it if that makes the SVN visible.


Regards
Graham

Unable to browse r-cran-sp VCS

[Graham Inggs]

Hi

I was trying to browse the VCS for r-cran-sp [1], but all I got was a 
404 error.


I was able to checkout with SVN, so the repository is there, it's just 
the web view that seems to be missing.


Have things been moved, or do I need to report this somewhere?

Regards
Graham

[1] 
https://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-sp/trunk/

Re: Scotch upgrade [Was: Re: MUMPS and other imminent upgrades]

[Graham Inggs]

On 12/06/2017 11:49, Drew Parsons wrote:

I wonder whether this should be listed in Debian Science policy as a
general policy?: new major updates (especially transitions with a
soname change) should always be pushed first to experimental.

Otherwise you risk the danger where one component of the library gets
into unstable and then testing, while another component is held back by
some failure. That might result in the library not working at all, for
a while.

Experimental also gives the opportunity to test the builds (and
runtime) of client programs before releasing to unstable.


It is also what Release Team would like you to do, before filing a bug 
requesting a transition slot:


https://wiki.debian.org/Teams/ReleaseTeam/Transitions

Re: Moving some of my packages to Debian Science team

[Graham Inggs]

On 08/06/2017 17:05, Muammar El Khatib wrote:

That is great!, to be honest, I don't understand why I didn't upload
these packages before to Debian Science!. I will upload ScaLAPACK this
weekend. Do you know if it is possible to automagically create tags
for each debian revision in the changelog?. Or just tagging the latest
one as I did for blacs-mpi suffices?.


The following should download all previous versions from 
snapshot.debian.org and tag everything for you:


gbp import-dscs --debsnap --pristine-tar scalapack

Removal of Aster?

[Graham Inggs]

Hi All

Would there be any objections to me filing a removal request for package 
aster [1]?  It has been removed from testing four times since its last 
upload by a listed uploader in 2014.


The last time was during the transition to openmpi 2 in September 2016 
(RC bug #837915).  The bug was forwarded upstream [2], but marked "wontfix".


Regards
Graham


[1] https://packages.qa.debian.org/a/aster.html
[2] https://bitbucket.org/code_aster/codeaster-src/issues/84

Re: Sundials is way outdated

[Graham Inggs]

On 14 February 2017 at 13:28, James Tocknell  wrote:
> Also, is anyone else running into a problem with conflicting openmpi
> requirements? Is there a way to request petsc gets rebuild against openmpi?

Already requested in bug #854905

Re: Vc: SIMD Vector Classes for C++

[Graham Inggs]

Hi Kay

On 03/02/2017 13:01, Kay F. Jahnke wrote:

I'm currently trying to get the ubuntu package sources for vc-dev up to
date, so I thought I might find the package in debian, hoping that an
update there would eventually trickle down. But it's not there - at
least I can't find it.


You are correct, the package exists in Ubuntu [1], but not in Debian.
A RFS (Request for Packaging) bug for vc has already been filed [2].
Rather than spend your time trying to get the Ubuntu package up to date, 
I suggest preparing the updated package for Debian.
You should have no trouble finding sponsorship for your package at 
Debian Mentors [3].



Regards
Graham


[1] https://launchpad.net/ubuntu/+source/vc
[2] https://bugs.debian.org/846491
[3] https://mentors.debian.net/

Bug#842491: ITP: dfcgen-gtk -- Digital Filter Coefficients Generator (DFCGen) GTK+

[Graham Inggs]

Package: wnpp
Severity: wishlist
Owner: Graham Inggs <gin...@debian.org>
X-Debbugs-CC: debian-de...@lists.debian.org, debian-science@lists.debian.org

* Package name: dfcgen-gtk
  Version : 0.4
  Upstream Author : Ralf Hoppe <ralf.ho...@ieee.org>
* URL : http://www.dfcgen.de
* License : GPL-2.0
  Programming Lang: C
  Description: Digital Filter Coefficients Generator (DFCGen) GTK+
 DFCGen, the Digital Filter Coefficients Generator, assists the engineer
 in the design of digital filters. It supports  the engineer in analysis
 and synthesis of linear time-invariant  time-discrete (LTI) systems
 from the theoretical point of view. It performs  generation of
 system transfer function coefficients in the Z-domain,
 based on the type and specific parameters of a chosen system.

I intend maintaining this package within debian-science.

Re: Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Graham Inggs]

On 24 October 2016 at 05:36, Muammar El Khatib <muam...@debian.org> wrote:
> On 10/20/2016 03:28 AM, Graham Inggs wrote:
>> No, but I do have a local packaging of neural (before the name changed
>> to amp) which was working, but since the project changed to amp and
>> was re-organized, it longer works and I don't know if any of it is
>> still relevant.  I can mail it to you privately, if you wish.
>>
>
> That would be great!.

I have sent it, let me know if you didn't receive it.

> I forgot to answer that. I would love to team-maintain scalapack in
> debian-science!. I do not have too much time for maintaining it  as it
> deserves. I will read the wiki of Debian science and request to be added to
> the group.

Thanks!  Would you consider doing the same for blacs-mpi?

Re: Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Graham Inggs]

On 20 October 2016 at 02:50, Muammar El Khatib  wrote:
> I discussed with Peterson and Alireza, and there is a new version on the go
> (v0.5.0, maybe in a month or something). What we could do is to work on
> snapshots from master (that is the development branch). What do you think?.

Sounds good!

> Are you working on a git repo available in the debian platform?, if so, could 
> you
> point me out to it?. I will be playing around with amp in the following days 
> and
> I could help with the packaging.

No, but I do have a local packaging of neural (before the name changed
to amp) which was working, but since the project changed to amp and
was re-organized, it longer works and I don't know if any of it is
still relevant.  I can mail it to you privately, if you wish.

While preparing to package amp, with the help of Marcin Dulak and Ask
Hjorth Larson, I did manage to get the prerequisites python-ase, gpaw
and gpaw-setups updated and into the archive.

BTW, I though I recognized your name from somewhere, would you mind
taking a look at #671380 ?

Re: Bug#790803: ITP: amp -- atomistic machine-learning potentials

[Graham Inggs]

Hi Muammar

Sadly, this fell off my radar. :(

On 18 October 2016 at 17:00, Muammar El Khatib  wrote:
> I am interested in participating in the packaging of amp. I recently
> joined Prof. Peterson's group as postdoctoral research associate at
> Brown, and thus I will be involved in amp (use/development). I would
> be glad if you let me know how I can help you with.

I did have a problem with relative imports when running the tests.  I
ended up repacking the tarball and moving some of the files and
directories into a directory named amp which seemed to improve things.

Is v0.4.1 the version we should be working on, or can you tag
something more recent?

Regards
Graham

Re: Packages FTBFS with new eigen3

[Graham Inggs]

Hi Anton

On 24 August 2016 at 18:09, Anton Gladky  wrote:
> it looks like the eigen-upstream has a patch already,
> but AFAIK it does not solve all problems.
>
> I discussed it with Philipp already and I will apply the
> patch as far as it will be ready.

Great, thanks for the update!

> Yes, bug can be reassigned.

I'll clone the bug, assign it to eigen3, and mark the others as being
blocked by it.

Regards
Graham

Packages FTBFS with new eigen3

[Graham Inggs]

Hi

At least ceres-solver and opensurgsim FTBFS with eigen3 3.3~beta2-1.
They both build fine with 3.3~beta1-2.

Should these bugs be moved to eigen3?

Regards
Graham

Re: Include Request: Box0 softwares in Debian Science

[Graham Inggs]

Hi!

Box0 does look interesting.  Do you have a link to where a prospective
package maintainer could obtain a sample of the hardware?

On 27 July 2016 at 09:26, Kuldeep Singh Dhaka  wrote:
> Yes, Box0 do *not* have a Debian package currently maintained.
> so, Yeah - im looking for someone to actually mantain the package!

I suggest filing an RFP (Request for Package) [1] bug.  You can do
this using 'reportbug' [2] or by email [3].

Regards
Graham


[1] https://wiki.debian.org/RFP
[2] https://www.debian.org/devel/wnpp/#l1
[3] https://www.debian.org/devel/wnpp/#l2

Re: FEniCS still on SVN?

[Graham Inggs]

On 22/04/2016 11:39, Nico Schlömer wrote:

I was looking for the Dolfin/FEniCS packages this morning and couldn't find
them on /git/debian-science on alioth. Is it possible that they are still
provided under svn?


Here they are:

https://anonscm.debian.org/viewvc/debian-science/packages/fenics/

Re: Bug#814149: add alternative for /usr/bin/dx

[Graham Inggs]

Hi Hans-Christoph

On 8 February 2016 at 21:25, Hans-Christoph Steiner  wrote:
> We have just packaged the "Dalvik Explorer" aka android-platform-dalvik
> which is always used as the command util 'dx'.

Always?  IBM's DX has been around since 1991. :)

> This conflicts with
> OpenDX's /usr/bin/dx, so I propose that OpenDX support /usr/bin/dx using
> the 'alternatives' system.

I don't believe the 'alternatives' system is the way to solve this.

From:
"The Debian alternatives system creates a way for several programs
that fulfill the same or similar functions to be listed as alternative
implementations that are installed simultaneously but with one
particular implementation designated as the default."

Clearly Dalvik Explorer's /usr/bin/dx and OpenDX's /usr/bin/dx do not
fulfil the same or similar functions.

I'm CC-ing the Debian Science list as I am sure similar situations
have been resolved in the past, and hopefully someone will suggest
possible solutions.

Regards
Graham


[1] http://www.opendx.org/about.html
[2] https://wiki.debian.org/DebianAlternatives

Re: Rearranging some of my packages

[Graham Inggs]

On 28 December 2015 at 13:42, Graham Inggs <gin...@debian.org> wrote:
> OpenDX Data Explorer [1][2] - move from collab-maint to debian-science
> GPAW [3] - move from debian-science to debichem
> LinSmith [4] - move from collab-maint to debian-science
>
>
> [1] https://tracker.debian.org/pkg/dx
> [2] https://tracker.debian.org/pkg/dxsamples
> [3] https://tracker.debian.org/pkg/gpaw
> [4] https://tracker.debian.org/pkg/linsmith

I forgot there is also;
gpaw-setups [5] - move from debian-science to debichem


[5] https://tracker.debian.org/pkg/gpaw-setups

Re: Bug#704782: trilinos: new package for Trilinos 11.x

[Graham Inggs]

On 22/09/2015 14:50, Nico Schlömer wrote:

I'm just comparing how the old (10.0.4.dsfg-1.1) package was built in
Debian.  The old packaging produced 5 binary packages, your new
packaging produces 94!
Is this really necessary?


The structure of Trilinos is much better reflected by this many packages
than it was with 5. In many ways, Trilinos works like Boost, particularly
in that it is essentially a collection of "packages". I didn't see a
disadvantage in having many packages either. Perhaps that presents a
problem somewhere?


The disadvantage is that adding packages adds to amount of data that 
everyone has to download on every update (not only those who have your 
packages installed).
It also increases the size of the dependency graph that package managers 
like apt need to handle.  There was a thread on debian-mentors [1] about 
this some time ago.


Basically, for packages with high install counts like libboost and 
libreoffice, it makes sense to split the packages (e.g. a user of 
English help is unlikely to install help in any other language).  For 
packages with low install counts, and whose users are likely to install 
most of the packages anyway, it does not make sense to split the packages.


Ultimately, the decision lies with ftpmaster whether this package will 
be accepted, and they will ask 'Is there a valid reason to provide a new 
binary package?', see 'Checks for new binary packages' [2].



[1] https://lists.debian.org/debian-mentors/2014/04/msg00256.html
[2] https://ftp-master.debian.org/NEW-checklist.html

Re: Bug#704782: trilinos: new package for Trilinos 11.x

[Graham Inggs]

On 23/09/2015 09:52, Felix Salfelder wrote:

building binary packages from master-{11,12} now works for me, can
anybody reproduce?


I have just successfully built trilinos from master-12. :)
Thanks Nico and Felix for your efforts!


A couple of Lintian warnings:

outdated-autotools-helper-file - this should be easily fixed with 
autoreconf [1], i.e. simply changing to:


dh $@ --with autoreconf

dep5-copyright-license-name-not-unique and 
space-in-std-shortname-in-dep5-copyright - should be easy to fix, e.g. 
'gpl-2 w/bison exception' can be changed to 'GPL-2.0-with-bison-exception'.



Some comments of my own:

In debian/rules you seem to have a mix of short form dh and debhelper. 
The install-stamp and configure-stamp stuff can probably go.


In debian/control you are restricting the architecture to amd64.
I'd prefer 'Architecture: any', at least for the initial upload, and 
take it from there.  Trilinos might be useful on ppc64el, for example.



[1] https://wiki.debian.org/Autoreconf

Re: Bug#704782: trilinos: new package for Trilinos 11.x

[Graham Inggs]

Hi Nico / Felix

On 19/09/2015 20:13, Felix Salfelder wrote:

On Sat, Sep 19, 2015 at 06:00:33PM +, Nico Schlömer wrote:

As I said, however, the git-archive of that commit dow _not_ coincide with
what Sandia distributes as their 12.2.1 tarball.


this is business as usual, and the reason why we import tarballs into
pristine-tar. in addition, gbp even requires a dedicated tarball import
commit for some reason.


For example, the
git-archive [1] is 212 MB large, the official tarball [2] only 110 MB. This
is because some testing files are removed from the tarball. Possibly there
are other changes as well.


master is now up2date with the 12.2.1 release (tarball). it seems to
build, but not on all machines. (i only have random systems, no proper
buildbot yet).


I don't see pristine-tar data for trilinos_12.2.1.orig.tar.bz2.

I downloaded trilinos-12.2.1-Source.tar.bz2 (md5sum 
760f14cbce482b4b9a41d1c18297b531) and tried to build against it.

I received many errors about unrepresentable changes.

I then tried unpacking the source tarball and copying over the debian 
directory from git.  The build ran for about an hour then failed while 
installing with a message about being unable to find packages/panzer.


Any suggestions?

BTW, I found a site linked to from trilinos.org that doesn't require 
login and contains old and current source tarballs:

https://trilinos.org/oldsite/download/files/

Regards
Graham

Re: DFSG status of petsc

[Graham Inggs]

Hi Drew

On 19 September 2015 at 10:46, Drew Parsons  wrote:
> As far as the win32 exe goes, maintenance would be simpler if we didn't
> have to generate a separate dfsg-free upstream tarball just to remove a
> file that we don't use.

Are you aware of UscanEnhancements[1]?

You can now use the 'Files-Excluded' field in debian/copright to
exclude files from repacking.
Repacking can be done in one line in debian/rules.
See source package p4vasp for examples of debian/copyright [2] and
debian/rules [3].

Regards
Graham


[1] https://wiki.debian.org/UscanEnhancements
[2] 
http://anonscm.debian.org/cgit/debichem/packages/p4vasp.git/tree/debian/copyright#n5
[3] 
http://anonscm.debian.org/cgit/debichem/packages/p4vasp.git/tree/debian/rules#n37

Re: Bug#704782: trilinos: new package for Trilinos 11.x

[Graham Inggs]

Hi Nico, Debian Science List

Nico, I've just come across your message while looking into repackaging 
Trilinos.


On Fri, 05 Apr 2013 22:14:49 +0200 Nico Schlömer 
 wrote:
> I'm working on a package for Trilinos 11.x, and things are shaping up 
nicely:

> I and a bunch of other people have been using the package at
> https://launchpad.net/~nschloe/+archive/trilinos-nightly
> https://github.com/nschloe/trilinos-ubuntu/tree/master/debian
> for a while now. Some things could maybe still be improved, but I 
think the

> thing is ready for a wider audience.
> Since Debian doesn't have an up-to-date package anymore for several 
years now,
> the suggestion would be to improve the package a bit more with some 
hints of
> Debian devs, and -- if the package proves worthy -- work towards 
including it

> in the package directory.
> What would be the steps that need to be taken?

I know you wrote this a long time ago, but I was pleased to see you are 
still updating your PPA!


I'd be happy to co-maintain this package with you in Debian and review 
and sponsor your uploads.


Debian Science List, what needs to be done before uploading a new version?
I don't see that the package was ever orphaned and the pkg-scicomp svn 
is gone.

I could set up a new git under debian-science.
Do you think it would be worth pulling in the old releases from 
snapshot.d.o, or given the amount of time has passed, rather start afresh?


Regards
Graham

Re: Bug#704782: trilinos: new package for Trilinos 11.x

[Graham Inggs]

On 17 September 2015 at 23:02, Nico Schlömer  wrote:
> Perhaps we can discuss the details of what still needs to be done in a
> separate thread for everyone who's interested. Graham, Felix? Hands up!

Let's drop the CC to the bug and continue the thread in the debian-science list.
I am subscribed there, so you can drop the CC to me as well.

Re: [Caffe] uploaded to mentors but NOT RFS

[Graham Inggs]

On 9 September 2015 at 04:42, Paul Tagliamonte  wrote:
> On Tue, Sep 08, 2015 at 10:36:00PM -0400, Yaroslav Halchenko wrote:
>> 2. or  provide two source packages, of which main would build only
>> CPU implementation while in non-free would build both/only GPU
>> (depending how organized).
>
> Yeah, that's not super great. I might consider a -src
> package and build-depend on that. That's a monumental hack, though, and
> I don't like seeing that in the archive.

What is wrong with doing it that way?
Working with nvidia-cuda-toolkit, I've come across the following packages:

https://packages.qa.debian.org/s/starpu.html
https://packages.qa.debian.org/s/starpu-contrib.html
https://packages.qa.debian.org/h/hwloc.html
https://packages.qa.debian.org/h/hwloc-contrib.html
https://packages.qa.debian.org/e/eztrace.html
https://packages.qa.debian.org/e/eztrace-contrib.html

Re: [Debichem-devel] updated python-ase / gpaw

[Graham Inggs]

Hi Andreas

Thanks for the upload!

On 24/07/2015 18:14, Andreas Tille wrote:

So if you build in an unstable chroot you do not get this error?


I have just tried with sbuild now, and I did not get this error.
This was with the revision before you commented out the Python 3 changes.

Regards
Graham


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b60de9.50...@nerve.org.za

Re: [Debichem-devel] updated python-ase / gpaw

[Graham Inggs]

On 24/07/2015 16:53, Andreas Tille wrote:

I noticed that ase also should work with Python 3 and thus added a
Python 3 package.


OK.  I had read that Python3 wasn't supported yet [1]:

The following packages are required for basic ASE functionality:

1. Python2 version 2.6 or newer. Python3 is not supported yet.
2. NumPy.


   Unfortunately 1 of 142 fails.  Would you mind having a look into this?


Weird, I tried building and it passed all the tests (although that was 
with Python 3.4, not 3.5 as is in unstable).

I did get hundreds of Lintian warnings though, e.g.
W: python-ase source: binaries-have-file-conflict python-ase python3-ase 
usr/bin/ase-build


Is this normal for packages that produce Python2 and Python3 binaries?

What about the recommended packages; python-gtk2, python-matplotlib and 
python-scipy?
Should those become python3-matplotlib and python3-scipy?  It seems that 
there is no python3-gtk2.


I must admit I am not comfortable with this change you have made.

[1] https://wiki.fysik.dtu.dk/ase/download.html#requirements


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b25f70.7080...@nerve.org.za

Re: [Debichem-devel] updated python-ase / gpaw

[Graham Inggs]

Hi Andreas

On 24 July 2015 at 18:14, Andreas Tille andr...@an3as.eu wrote:
 I was building in an unstable chroot which obviously used Python 3.4
 (not 3.5).  The log said:

Sorry, I was confused.  I think I saw that Ubuntu have already switched to 3.5.

 So if you build in an unstable chroot you do not get this error?

I have limited connectivity until next week.
I tried building with your changes on the first machine available
which happened to be running Ubuntu 14.04.
(What I pushed to git was tested against unstable using sbuild though)

 If you want to push on a quick update I'm fine with reverting this
 change.  However, at some point in time you will need to do it anyway.
 Its youe choice when you want to do this.

At this stage, I'd prefer if we uploaded a Python2-only version.

I can then look at the test case failure you saw, and Python3 in more
detail, over the coming weeks.

Regards
Graham


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAM8zJQufD_3nCY0owRu+6ir-3XJY7Kf=gw0=3f4o5shbepz...@mail.gmail.com

Re: updated python-ase / gpaw

[Graham Inggs]

On 15/07/2015 20:09, Graham Inggs wrote:

I've been working on the python-ase packaging in git [1].

...

[1] http://anonscm.debian.org/cgit/debichem/packages/python-ase.git



Update: new upstream version 3.9.1.4567 was released.
I have updated my packaging and I would like someone to review and 
hopefully sponsor the upload.


Andreas did already offer [2].

[2] https://lists.debian.org/debian-science/2015/07/msg00098.html


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55b24712.6090...@nerve.org.za

Re: Bug#787329: RFS: gpaw/0.10.0.11364 ITP -- DFT and beyond within the projector-augmented wave method

[Graham Inggs]

On Wed, Jul 22, 2015 at 05:18:04PM +0200, Marcin Dulak wrote:
 There is a new GPAW release (just today),
 but this requires python-ase-3.9.0 which is not in Debian yet.

I did post about this a week ago to debian-science and debichem lists:

 I've been working on the python-ase packaging in git [1].
...
[1] http://anonscm.debian.org/cgit/debichem/packages/python-ase.git 


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAM8zJQucd9PcgRvbAKhe1HLMFZjAXUPw3Yr7+A+Ss+=met2...@mail.gmail.com

Re: viewmol: /usr/bin/viewmol missing for most archs

[Graham Inggs]

On 03/07/2015 09:57, Drew Parsons wrote:

On Mon, 2015-06-29 at 21:59 +0200, Graham Inggs wrote:

Hi Drew

On 13 November 2014 at 02:23, Drew Parsons dpars...@debian.org
wrote:

In those terms it makes sense for Debian Science to handle the
lonely
science-related packages that don't have a more focussed home.  I'm
happy then for viewmol to be handled under DebiChem.

Just letting you know I'll be moving the viewmol package over to
debichem and doing some QA work on it.


Thanks for that Graham, I appreciate the extra help.



No worries!

Work-in-progress here:
https://anonscm.debian.org/cgit/debichem/packages/viewmol.git/

I used 'git-import-dscs --debsnap --pristine-tar viewmol' to pull in all 
the previous versions and then merged in the debian-unstable branch from 
debian-science to preserve your commit history.



--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a67345.2000...@nerve.org.za

Re: [Debichem-devel] Please help porting rasmol to latest vte (Was: Bug#790196: rasmol: depends on vte which is deprecated)

[Graham Inggs]

Hi Andreas

I'll have a look when I get a chance, possibly at debcamp next month.

On 3 July 2015 at 21:24, Andreas Tille andr...@an3as.eu wrote:
 I had a look into the said issue but failed with

 ...
 No package 'vte' found
 Package vte was not found in the pkg-config search path.
 Perhaps you should add the directory containing `vte.pc'
 to the PKG_CONFIG_PATH environment variable
 No package 'vte' found

I had a look at the file listings of the -dev packages [1][2], and
vte.pc is now named vte-2.91.pc.

Regards
Graham

[1] https://packages.debian.org/sid/amd64/libvte-dev/filelist
[2] https://packages.debian.org/sid/amd64/libvte-2.91-dev/filelist


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cam8zjqtsjcv6lbhfcnibo9nxt1ux+7h+y5ib4yuy0g3jv62...@mail.gmail.com

Re: viewmol: /usr/bin/viewmol missing for most archs

[Graham Inggs]

Hi Drew

On 13 November 2014 at 02:23, Drew Parsons dpars...@debian.org wrote:
 In those terms it makes sense for Debian Science to handle the lonely
 science-related packages that don't have a more focussed home.  I'm
 happy then for viewmol to be handled under DebiChem.

Just letting you know I'll be moving the viewmol package over to
debichem and doing some QA work on it.

Regards
Graham


-- 
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAM8zJQtcsBmDZo4aNznZnndMTOnBiaOBUg5vUyi1ctN=p8b...@mail.gmail.com

Re: [inventor] please transition from lesstif2 to motif

[Graham Inggs]

Hi Steve

On 08/08/2013 09:12, Steve M. Robbins wrote:

If you and other debian-science readers want to review the changes, perhaps
do a test-build and send feedback, I'd really appreciate that.


I've done test builds on Debian Sid in a VM and Ubuntu Precise with 
backported motif and glw packages.  I was able to run the binaries in 
inventor-clients and inventor-demo and open their 'about' PDF pages.


The 'about' page for revo did not open, but that can be easily fixed by 
removing the ampersand in line 227 of d/patches/configurability.patch as 
follows:


+sprintf(command, which  PDFVIEWER   /dev/null);

becomes:

+sprintf(command, which  PDFVIEWER   /dev/null);

I did run into a problem building the package for i386 on Ubuntu's PPA 
builders for Saucy, although x86_64 built fine.


 /usr/lib/i386-linux-gnu/libc_nonshared.a(stack_chk_fail_local.oS):
 In function `__stack_chk_fail_local':
 (.text+0x10): undefined reference to `__stack_chk_fail'

If you run into the same problem on the Debian builders you can add the 
following line to apps/nodes/Decal/GNUmakefile:


CXXFLAGS += -fno-stack-protector

If not, I will investigate further and fix it on the Ubuntu side.

Regards
Graham


--
To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52037bf4.4060...@nerve.org.za