Bug#999526: Taking over package into Debian Python Team maintenance and fixing bug (Was: mdp: FTBFS with numpy 1.21 (in experimental): dh_auto_test: error: pybuild --test --test-pytest -i python{versi

[Yaroslav Halchenko]

Hi Andreas,

Thank you very much for offering help.  I think Tiziano would not mind,
so please feel very welcome to a) for the sake of b) or any other
goodness you would like to bring ;)

Note though that MDP is pretty much inactive project since a few years
back.  It seems it is still used by some and somewhat maintained
upstream, so might indeed be worthwhile keeping afloat in Debian but I
would not cry if it got RMed.

After/if packaging moves to a new repo on salsa, we can submit a
PR to add an empty out debian/ and add stub debian/README to that
upstream repo to signal that packaging moved to salsa.

Cheers,

On Mon, 17 Apr 2023, Andreas Tille wrote:

> Hi Tiziano and Yaroslav,

> I'd volunteer to

>a) take over package into Debian Python Team (including
>   using Salsa Git and Maintainer address of DPT) and
>b) apply the patch and upload the package

> I'm not interested in just doing b) and hope you will find the time to
> care for the package if you are not happy with a).  Please note that
> there was an NMU which is not taken over in your repository at Github.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1015102: heudiconv: FTBFS: FAILED heudiconv/tests/test_heuristics.py::test_reproin_largely_smoke[--files /<>/.pybuild/cpython3_3.10_heudiconv/build/heudiconv/tests/data-reproin]

[Yaroslav Halchenko]

oh, sorry about that and thanks for the ping!

I fixed it upstream already (the bug is really in datalad), and will
look to release it asap (i.e. now) and then see if we can update package
(might need to also upload new version of dcmstack first)

On Thu, 29 Sep 2022, Nilesh Patra wrote:

> Hi Yaroslav,

> Since you are the upstream for heudiconv, could you please help fix this?

> On Sat, 16 Jul 2022 15:49:48 +0200 Lucas Nussbaum  wrote:
> > Source: heudiconv
> > Version: 0.11.3-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20220716 ftbfs-bookworm

> > Hi,

> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.


> > Relevant part (hopefully):

> >dh_auto_test -O--buildsystem=pybuild
> > pybuild --test --test-pytest -i python{version} -p "3.9 3.10"
> > I: pybuild pybuild:300: cp -a heudiconv/tests 
> > /<>/.pybuild/cpython3_3.9_heudiconv/build/heudiconv/
> > I: pybuild base:239: cd 
> > /<>/.pybuild/cpython3_3.9_heudiconv/build; python3.9 -m pytest 
> > = test session starts 
> > ==
> > platform linux -- Python 3.9.13, pytest-7.1.2, pluggy-1.0.0
> > rootdir: /<>
> > collected 99 items / 1 skipped

> > heudiconv/external/tests/test_dlad.py .  [  
> > 1%]
> > heudiconv/heuristics/test_reproin.py [  
> > 9%]
> > heudiconv/tests/test_bids.py ..s [ 
> > 44%]
> > heudiconv/tests/test_convert.py ..   [ 
> > 54%]
> > heudiconv/tests/test_dicoms.py ...   [ 
> > 57%]
> > heudiconv/tests/test_heuristics.py .F.   [ 
> > 68%]
> > heudiconv/tests/test_main.py ..  [ 
> > 82%]
> > heudiconv/tests/test_queue.py ...[ 
> > 85%]
> > heudiconv/tests/test_regression.py sss.  [ 
> > 89%]
> > heudiconv/tests/test_tarballs.py .   [ 
> > 90%]
> > heudiconv/tests/test_utils.py .  
> > [100%]

> > === FAILURES 
> > ===
> > _ test_reproin_largely_smoke[--files 
> > /<>/.pybuild/cpython3_3.9_heudiconv/build/heudiconv/tests/data-reproin]
> >  _

> > tmpdir = 
> > local('/tmp/pytest-of-user42/pytest-9/test_reproin_largely_smoke___f0')
> > heuristic = 'reproin'
> > invocation = '--files 
> > /<>/.pybuild/cpython3_3.9_heudiconv/build/heudiconv/tests/data'

> > @pytest.mark.parametrize('heuristic', ['reproin', 'convertall'])
> > @pytest.mark.parametrize(
> > 'invocation', [
> > "--files %s" % TESTS_DATA_PATH,# our new way with automated 
> > groupping
> > "-d %s/{subject}/* -s 01-fmap_acq-3mm" % TESTS_DATA_PATH # 
> > "old" way specifying subject
> > # should produce the same results
> > ])
> > @pytest.mark.skipif(Dataset is None, reason="no datalad")
> > def test_reproin_largely_smoke(tmpdir, heuristic, invocation):
> > is_bids = True if heuristic == 'reproin' else False
> > arg = "--random-seed 1 -f %s -c dcm2niix -o %s" \
> >   % (heuristic, tmpdir)
> > if is_bids:
> > arg += " -b"
> > arg += " --datalad "
> > args = (
> > arg + invocation
> > ).split(' ')

> > # Test some safeguards
> > if invocation == "--files %s" % TESTS_DATA_PATH:
> > # Multiple subjects must not be specified -- only a single one 
> > could
> > # be overridden from the command line
> > with pytest.raises(ValueError):
> > runner(args + ['--subjects', 'sub1', 'sub2'])

> > if heuristic != 'reproin':
> > # if subject is not overridden, raise error
> > with pytest.raises(NotImplementedError):
> > runner(args)
> > return

> > runner(args)
> > ds = Dataset(str(tmpdir))
> > assert ds.is_installed()
> > assert not ds.repo.dirty
> > head = ds.repo.get_hexsha()

> > # and if we rerun -- should fail
> > lgr.info(
> > "RERUNNING, expecting to FAIL since the same everything "
> > "and -c specified so we did conversion already"
> > )
> > with pytest.raises(RuntimeError):
> > runner(args)

> > # but there should be nothing new
> > assert not ds.repo.dirty
> > >   assert head == ds.repo.get_hexsha()
> > E   AssertionError: assert '2c32d90c7252...452338c3a611a' == 
> > '52121805b02b...b36be77769e34'
> > E - 52121805b02b454149686a4ae12b36be77769e34
> > E + 2c32d90c7252c966ebdba876f6f452338c3a611a

> > 

Bug#1009381: datalad-container: diff for NMU version 1.1.6-0.1

[Yaroslav Halchenko]

THANK YOU Adrian!

Apparently I have forgotten to upload updated debian package after all
those now automated bugfix releases in datalad-container...  I will do
that now, and if I fail -- your NMU would proudly solve the issue  -- no
need to cancel.

On Thu, 26 May 2022, Adrian Bunk wrote:

> Control: tags 1009381 + patch
> Control: tags 1009381 + pending

> Dear maintainer,

> I've prepared an NMU for datalad-container (versioned as 1.1.6-0.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I should 
> cancel it.

> cu
> Adrian
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#1010941: python-argcomplete salvaging and possible team (re)join

[Yaroslav Halchenko]

Hi Marco, Marc and the Team,

I have just uploaded to --delayed 5 a workaround fix for #1010941
(FTBFS). The diff is attached 

I have a clone at https://salsa.debian.org/yoh/python-argcomplete
with Marc's NMU imported, and my NMU changes on top.  So could be a good
starting point to update packaging to a new release ;)

would also be nice to add tags (may be original from Marco?) for prior
upstream/debian releases.

Cheers,

On Wed, 27 Apr 2022, Marc Dequènes (duck) wrote:

> Quack,

> python-argcomplete has not been actively maintained and I did a NMU last
> year that got unacknowledged. I intend to salvage it. I think it would make
> sense to maintain it under the team's umbrella, which leads me to…

> I was part of the "Python Modules Team" between 2006 and 2009 but since then
> did not maintain Python packages except for some sponsoring (mainly
> postfix-mta-sts-resolver and dico related packages but not team-maintained
> although wikitrans was in the Python Modules Team as the Maintainer field
> attest). I'd be glad to rejoin if you would allow me. I don't know if I
> would have time to work on other team packages but occasionally I should be
> able to give a hand.

> I have read and agree to the policy on:
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> I am not familiar with gbp-pq but I looked at the doc and it seems quite
> interesting. The rest of the workflow is is almost identical to what I'm
> used to and should not be a problem.

> Regards.
> \_o<
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

diff -Nru python-argcomplete-1.12.3/debian/changelog python-argcomplete-1.12.3/debian/changelog
--- python-argcomplete-1.12.3/debian/changelog	2021-09-28 10:29:56.0 -0400
+++ python-argcomplete-1.12.3/debian/changelog	2022-05-13 13:07:30.0 -0400
@@ -1,3 +1,12 @@
+python-argcomplete (1.12.3-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/rules
+- provide workaround for tests to not fail (Closes: #1010941).
+  Upstream issue: https://github.com/kislyuk/argcomplete/issues/337
+
+ -- Yaroslav Halchenko   Fri, 13 May 2022 13:07:30 -0400
+
 python-argcomplete (1.12.3-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-argcomplete-1.12.3/debian/rules python-argcomplete-1.12.3/debian/rules
--- python-argcomplete-1.12.3/debian/rules	2021-09-28 10:29:56.0 -0400
+++ python-argcomplete-1.12.3/debian/rules	2022-05-13 13:07:30.0 -0400
@@ -26,6 +26,17 @@
 		cp debian/$$i.1 debian/python3-argcomplete/usr/share/man/man1/$${i}3.1; \
 	done
 
+# Workaround
+# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010941
+# https://github.com/kislyuk/argcomplete/issues/337#issuecomment-771835184
+override_dh_auto_test:
+	echo "set enable-bracketed-paste off" > .inputrc
+	INPUTRC=$(CURDIR)/.inputrc dh_auto_test
+
+override_dh_auto_clean:
+	rm -f .inputrc
+	dh_auto_clean
+
 generate_manpages:
 	VERSION=$$(./setup.py -V) ; \
 	for file in \


signature.asc
Description: PGP signature

Bug#1010941: FTBFS due to tests 56 tests failing

[Yaroslav Halchenko]

Package: python3-argcomplete
Version: 1.12.3-0.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Wanted to build a backport but failed to have it built even in current sid.
A complete log is at 
http://www.onerussian.com/tmp/python-argcomplete_1.12.3-0.1_amd64.build

and here is a typical (they are all of the same kind - not matching
desired empty string) fail:

==
FAIL: test_wordbreak_chars (test.test.TestBashGlobal)
--
Traceback (most recent call last):
  File "/build/python-argcomplete-1.12.3/test/test.py", line 1215, in setUp
self.assertEqual(output, '')
AssertionError: '\x1b[?2004l\r\x1b[?2004h' != ''
- ^[[?2004l^M- ^[[?2004h



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable-updates'), (100, 'stable-security'), (100, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-argcomplete depends on:
ii  python3  3.9.8-1

python3-argcomplete recommends no packages.

python3-argcomplete suggests no packages.

-- debconf-show failed

Bug#937209: openopt: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

> openopt seems dead upstream and has been dropped from testing for almost
> two years, let's remove it?

sounds good to me

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#982503: marked as pending in neurodebian

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #982503 in neurodebian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/neurodebian/-/commit/6480c19a1e13b72ead571230019995fc55c1b4f9


Merge remote-tracking branch 'salsa/master'

* salsa/master:
  Replace xcf2png (xcftools) with convert (imagemagick). (Closes: #982503)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/982503

Bug#982503: marked as pending in neurodebian

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #982503 in neurodebian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/neurodebian/-/commit/d0e0f642ed2010677d98f23253afad5097de7ec1


Merge branch 'rm-xcftools' into 'master'

Replace xcf2png (xcftools) with convert (imagemagick). (Closes: #982503)

See merge request neurodebian-team/neurodebian!1


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/982503

Bug#982503: marked as pending in neurodebian

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #982503 in neurodebian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/neurodebian/-/commit/34808c4aa5c77d811234d379470772d2a8355049


Replace xcf2png (xcftools) with convert (imagemagick). (Closes: #982503)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/982503

Bug#980967: closed by Debian FTP Masters (reply to Yaroslav Halchenko ) (Bug#980967: fixed in bats 1.2.1-2)

[Yaroslav Halchenko]

On Mon, 15 Feb 2021, Paul Gevers wrote:

> Hi Yaroslav,

> On 15-02-2021 05:51, Debian Bug Tracking System wrote:
> >  bats (1.2.1-2) unstable; urgency=medium
> >  .
> >* debian/patches
> >  - adopted patch from https://github.com/bats-core/bats-core/pull/387 to
> >resolve "bats-exec-test: command not found" (Closes: #980967)

> This seems to be not enough. The test now fails with:

yeah, earlier this morning I was told that the failing test was not a
red herring... ;)  I have uploaded -3 few hours back which should
have address this :

> /usr/lib/bats-core/preprocessing.bash: line 16: bats-preprocess: command
> not found

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#978257: pynwb is marked for autoremoval from testing

[Yaroslav Halchenko]

failed to arrive with working minimal patch against that elderly 1.2.1

FWIW built current snapshot which seems to be ok.  but I am reluctant to
upload that one since it has breaking (we have no rev-depends though in
debian ATM) changes.

On Sun, 14 Feb 2021, Andreas Tille wrote:

> Hi Yaroslav,

> could you please have a look.  I'm occupied by many other things and will not
> care for this one.

> Kind regards
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#982120: heudiconv still depends on python

[Yaroslav Halchenko]

Thanks, on it. also needs a patch now for datalad 0.14 deprecation

On Sat, 06 Feb 2021, Adrian Bunk wrote:

> Package: heudiconv
> Version: 0.9.0-1
> Severity: serious

> This looks like a forgotten conversion:
> https://sources.debian.org/src/heudiconv/0.9.0-1/debian/control/#L28


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#982119: dcmstack: autopkgtest failure

[Yaroslav Halchenko]

Thanks!

Test building and will upload if all good with


$> git show
commit e9f88704d2fd8bf5f0053904222e66dcc69db621 (HEAD -> debian, tag: 
debian/0.8-2)
Author: Yaroslav Halchenko 
Date:   Sat Feb 6 12:29:39 2021 -0500

Replace nosetests-3 with python3 -m nose for autopkgtest invocation 
(Closes: #982119)

diff --git a/debian/changelog b/debian/changelog
index a5b654f..ff77288 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dcmstack (0.8-2) unstable; urgency=medium
+
+  * Replace nosetests-3 with python3 -m nose for autopkgtest invocation
+(Closes: #982119)
+
+ -- Yaroslav Halchenko   Sat, 06 Feb 2021 12:29:32 -0500
+
 dcmstack (0.8-1) unstable; urgency=medium
 
   * Fresh upstream release
diff --git a/debian/tests/control b/debian/tests/control
index 4a50d35..47277d7 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
-Test-Command: nosetests-3 .
+Test-Command: python3 -m nose .
 Depends: @, @builddeps@




On Sat, 06 Feb 2021, Adrian Bunk wrote:

> Source: dcmstack
> Version: 0.8-1
> Severity: serious

> https://ci.debian.net/data/autopkgtest/testing/amd64/d/dcmstack/10273343/log.gz

> ...
> autopkgtest [00:00:03]: test command1: nosetests-3 .
> autopkgtest [00:00:03]: test command1: [---
> bash: line 1: nosetests-3: command not found
> autopkgtest [00:00:04]: test command1: ---]
> autopkgtest [00:00:04]: test command1:  - - - - - - - - - - results - - - - - 
> - - - - -
> command1 FAIL non-zero exit status 127


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#975166: connectome-workbench: FTBFS: qwt_painter_command.h:85:22: error: field ‘clipPath’ has incomplete type ‘QPainterPath

[Yaroslav Halchenko]

Great, thanks for the info and the buzz -- missed this, will try now and
upload if all good.

Cheers,

On Wed, 13 Jan 2021, s3v wrote:

> Dear Maintainer,

> I tried to build your package in a sid chroot environment
> and I confirm that patch fixes this issue.

> Kind Regards


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> > Thanks for the hint.  While this could possibly speet up the upload of
> > nipype I for myself are fine with waiting for the new Build-Depends.
> > Anybody who wants to speed up things is kindly invited to add this patch
> > and upload.

> What's the status here? python-etelemetry is now in the archive and testing.

FWIW: I just uploaded rdflib 5.0.0 (recent nipype needs that
version if any) and pushed initial changes to nipype's packaging git for
1.6.0 . Will try to find more time over weekend to finalize packaging
update (if no other new depends etc) -- needed for heudiconv package
(currently present  nipype version incorrectly handles some DWIs, FYI
for those who care ;)).

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#959138: Error in build time tests (Was: numpy breaks nipy autopkgtest: No module named 'numpy.testing.decorators')

[Yaroslav Halchenko]

FWIW those were reported "upstream"
https://github.com/nipy/nipy/issues/466

unfortunately I had no time to look at them (again :-/)
On Tue, 08 Dec 2020, Andreas Tille wrote:

> Control: tags -1 pending
> Control: tags -1 help

> Hi,

> I've updated nipy Git[1] to version 0.4.3~rc1 which solves the
> originally reported issue.  However, there are some remaining failures
> in the build time test:

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#976325: [ans...@debian.org: Bug#976325: src:libgdf: invalid maintainer address]

[Yaroslav Halchenko]

On Thu, 03 Dec 2020, Rafael Laboissière wrote:

> Dear Yaroslav and Michael,

> Are you aware of the problem related in Bug#976325, regarding the email
> address t...@neuro.debian.net?

thanks Rafael.  I think that elderly mail server didn't re-emerge from
the dead upon recent power outage.  I will tend to it within few days or
we figure out some alternative solution to bring that email address back
in service

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#972163: Bug#972166: Rising severities

[Yaroslav Halchenko]

Feel welcome to NMU without delay.  Sorry for being slow etc.

Thank you!

On Sun, 25 Oct 2020, Lisandro Damián Nicanor Pérez Meyer wrote:

> severity 972163 serious
> severity 972166 serious
> block 972176 by 972163
> block 972176 by 972166
> thanks

> Hi! We are close to begin the Qt transition that will remove
> qt5-default, so I'm raising the severities.  If everything goes well
> I'll be NMUing your package today with an upload to delayed/5. Of
> course feel free to ping me if needed.

> Thanks, Lisandro.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik



signature.asc
Description: PGP signature

Bug#964650: pydicom: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13

[Yaroslav Halchenko]

On Fri, 17 Jul 2020, Andreas Tille wrote:

> Control: tags -1 help

> Hi,

> the new upstream version I've just pushed to git solves the issue

thanks!

> that is reported here, but I'm running into a different issue:

>TypeError: data type 'uint15' not understood

I do not understand it either, in the sense that I have never seen such a
beast in real life.

> Any help is welcome

google lead me to
https://bugzilla.redhat.com/show_bug.cgi?id=1838435_source=feedburner_medium=feed_campaign=Feed%3A+rawhide-new-7days+%28Bugzilla+Bugs%29
which points to
https://github.com/pydicom/pydicom/issues/1119
which says to be fixed by
https://github.com/pydicom/pydicom/pull/1114
which is not really related ...

will look into it later...
> Andreas.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#938605: svgtune: Python2 removal in sid/bullseye - reopen 938605

[Yaroslav Halchenko]

Old python ones are listed only as alternative dependencies to easy backports 
for ancient systems.
https://packages.debian.org/sid/svgtune 
I don't think this package holds any python removal

On June 20, 2020 12:49:59 AM EDT, Sandro Tosi  wrote:
>Control: reopen -1
>
>This bug was closed, but the package has still some dependencies
>towards
>Python2 packages, in details:
>
>(binary:svgtune)Depends->python
>(binary:svgtune)Depends->python-lxml
>
>Re-opening, so that they can be taken care of.

-- 
Yaroslav O. Halchenko (mobile version)
Center for Open Neuroscience   http://centerforopenneuroscience.org
Dartmouth College, NH, USA

Bug#937485: pymvpa2: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

As the upstream and Debian maintainer for it, I am ok with it. It could be 
easily made to build for python 3 but tests would show that it is not entirely 
kosher. I better reupload it when it i an sure it is functioning correctly again

On June 13, 2020 1:16:58 PM EDT, "Moritz Mühlenhoff"  wrote:
>On Mon, Feb 03, 2020 at 08:36:43AM +1100, Stuart Prescott wrote:
>> Dear maintainers,
>> 
>> In the last update on pymvpa2, it sounded like upstream would soon
>have sorted 
>> Python 3 compatibility and the FTBFS bugs for the package would soon
>be fixed. 
>> However, there has been no upstream activity in the referenced PR 
>> https://github.com/PyMVPA/PyMVPA/pull/525 for many months.
>> 
>> What are the prospects for a fixed package in the buster release
>cycle? Given 
>> that it will have to go through NEW to gain the Python 3 module
>package in any 
>> case, are we at the stage where it should just be removed from
>Debian, perhaps 
>> to be reintroduced later when upstream work is completed?
>> 
>> (There's a cost to keeping buggy packages in Debian in that they
>occupy 
>> people's time when dealing with transitions or bug squashing. Even
>finding the 
>> packaging Vcs to see if there has been yet-to-be uploaded progress on
>these 
>> bugs is excessively difficult right now)
>
>Indeed, let's remove it from unstable for now?
>
>Cheers,
>Moritz

Bug#945739: symeig - RM?

[Yaroslav Halchenko]

the last changelog msg I see is

symeig (1.5-2) unstable; urgency=low

  * Deprecating symeig as a separate package -- functionality was 
included in
scipy (>=0.7.0), please use scipy.linalg.eigh instead.
  * Transitional packages became architecture 'all' instead of 'any'
  * Boosted policy to 3.8.3:
- -dbg got correct "section: debug" and "priority: extra"

     -- Yaroslav Halchenko   Mon, 16 Nov 2009 
08:55:44 -0500


so indeed it is time for it to RiP ;)  please RM

On Wed, 13 May 2020, Scott Talbert wrote:

> Hi,

> It seems that symeig has no (longer?) reverse depends and it seems to be
> abandoned upstream.  Is the best solution just to remove it?

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#959940: hdmf FTBFS with h5py 2.10.0

[Yaroslav Halchenko]

Package: python3-h5py
Version: 2.10.0-7
Followup-For: Bug #959940

Please see https://github.com/hdmf-dev/hdmf/issues/343#issuecomment-625972582
for possibly more info:

@tillea @yarikoptic the debian port contains this code in 
h5py_2.10.0-7.debian/debian/wrapper_module/h5py/__init__.py

from sys import modules as sys_modules

# [snip]

# make generic h5py module behaviour the same as specific builds
# by importing public and weak internal symbols (single _underscore)
api = [ k for k in _h5py.__dict__.keys() if not k.startswith('__') and 
not k.endswith('__') ]
this_module=sys_modules[__name__]
for key in api:
# "imports" symbols (makes them accessible)
setattr(this_module,key,getattr(_h5py,key))
# rename symbols as properties of toplevel h5py module
sys_modules['h5py.{}'.format(key)] = getattr(_h5py,key)

Since remove_deprecated_highlevel_module_2f41c78.patch is not
applied, the api list includes 'highlevel' so then
sys.modules['h5py.highlevel'] is set to h5py.highlevel. This is 
problematic
because sys.modules is traversed in the context manager for
unittest.TestCase.assertWarns and getattr is called on it, but 
h5py.highlevel
is intentionally lazily imported by h5py, I think, because it is 
deprecated. So
one solution might be to apply the patch. Another might be to add and 
not k ==
'highlevel' to the line that sets api above.


In the above "patch" is the remove_deprecated_highlevel_module_2f41c78.patch 
patch
which was disabled in 

commit ed17e72dc2fa47f590b78632401512546d3d3e1e
Author: Drew Parsons 
Date:   Sun Apr 5 18:31:33 2020 +0800

disable upstream patches and update drop_deprecation_tests.patch

aid HDF5 transition by giving bitshuffle more time to update
(see Bug#955456)

changes to drop_deprecation_tests.patch needed to pass h5py 
tests

diff --git a/debian/patches/series b/debian/patches/series
index 6753f8e..9f3468d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -7,8 +7,8 @@ fix_2.10_docs.patch
 hdf5_pkgconfig.patch
 build_flavour.patch
 stop_circular_dep.patch
-drop_deprecated_dtype_6a77b91.patch
-remove_deprecated_highlevel_module_2f41c78.patch
-file_default_read_5e71c49.patch
+#drop_deprecated_dtype_6a77b91.patch
+#remove_deprecated_highlevel_module_2f41c78.patch
+#file_default_read_5e71c49.patch
 drop_deprecation_tests.patch
 tests_as_local_build.patch


Cheers,

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable-updates'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-h5py depends on:
ii  python3-h5py-serial  2.10.0-7

python3-h5py recommends no packages.

Versions of packages python3-h5py suggests:
pn  python-h5py-doc  

-- no debconf information

Bug#959575: marked as pending in neurodebian

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #959575 in neurodebian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/neurodebian/-/commit/793990fb04bc077882af1e9ee5bb998219b4b64e


Be compatible with inkscape >= 1.0~rc1 which changed -e into -o. (Closes: 
#959575)

Also robustify mkdir -- do not bother with checking for existence first, there 
is
no need with mkdir -p and also overall it would fail if exists due to lack of 
|| :
or - before


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/959575

Bug#959575: neurodebian: FTBFS: (process:15028): WARNING **: 05:07:11.653: Unable to create profile directory (Permission denied) (13)

[Yaroslav Halchenko]

On Sun, 03 May 2020, Lucas Nussbaum wrote:
> > [ ! -d build/icons ] && mkdir -p build/icons
> > inkscape artwork/icon.svg -w 32 -h 32 \
> > -e build/icons/neurodebian.png

> > ** (process:15028): WARNING **: 05:07:11.653: Unable to create profile 
> > directory (Permission denied) (13)
> > Unable to init server: Could not connect: Connection refused
> > Unknown option -e
> > make[1]: *** [debian/rules:28: override_dh_auto_build] Error 1

FTR, reason is that inkscape switched from -e to -o.  Upload fixing
that is being prepared

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

> > yes, AFAIK it is dead.  Let's RM.   you ? me ? ;)

> Please go ahead :-)

FTR #959213

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> On Wed, Feb 26, 2020 at 04:15:03PM +0100, Andreas Tille wrote:
> > On Wed, Feb 26, 2020 at 08:37:30AM -0500, Yaroslav Halchenko wrote:
> > > thank you Andreas!!!

> > > re etelemetry:  I made it optional for previous version of the
> > > package:

> > >   $> quilt series
> > >   deb-no-demand-on-etelemetry

> > >   $> git describe
> > >   debian/0.6.0-1

> > Thanks for the hint.  While this could possibly speet up the upload of
> > nipype I for myself are fine with waiting for the new Build-Depends.
> > Anybody who wants to speed up things is kindly invited to add this patch
> > and upload.

> What's the status here? python-etelemetry is now in the archive and testing.

my problem with any version of nipype ended up stalling tests with
python3.8. See e.g. https://github.com/nipy/nipype/pull/3154 for
interactions with upstream and now a dedicated issue 
https://github.com/nipy/nipype/issues/3209

I guess what we could do is to upload currently present in debian
version with python 3.8 testing disabled and hope for the best ;)  I
will exercise (update packaging and see if builds/test otherwise ok with
3.7 etc) that now

Then we wait for python3-rdflib 5.0 being uploaded (just submitted a
wishlist bug report to have it updated), and upload fresh snapshot (or
release if by then done) of nipype.

any suggestions to the plan? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#937431: pyepl: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

On Thu, 30 Apr 2020, Moritz Mühlenhoff wrote:

> On Fri, Aug 30, 2019 at 07:33:35AM +, Matthias Klose wrote:
> > Package: src:pyepl
> > Version: 1.1.0+git12-g365f8e3-3
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal

> > Python2 becomes end-of-live upstream, and Debian aims to remove
> > Python2 from the distribution, as discussed in
> > https://lists.debian.org/debian-python/2019/07/msg00080.html

> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.

> pyepl is dead upstream, let's remove it?

yes, AFAIK it is dead.  Let's RM.   you ? me ? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#936857: libfreenect: diff for version 1:0.5.3-2

[Yaroslav Halchenko]

Thanks for the alert, FWIW, done now:

(git)lena:~exppsy/libfreenect[debian]git
$> gbp push  salsa   
gbp:info: Pushing debian/1%0.5.3-1 to salsa
gbp:info: Pushing upstream/0.5.3 to salsa
gbp:info: Pushing refs/heads/debian to salsa:refs/heads/debian
gbp:info: Pushing refs/heads/dfsg to salsa:refs/heads/dfsg


On Thu, 09 Apr 2020, Sandro Tosi wrote:

> FTR, i sent my changes this way instead on git because HEAD doesnt
> contain the 1:0.5.3-1 upload
> 
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#936857: libfreenect: diff for version 1:0.5.3-2

[Yaroslav Halchenko]

On Thu, 09 Apr 2020, Sandro Tosi wrote:

> Control: tags 936857 + patch


> Dear maintainer,

> I've prepared an upload for libfreenect (versioned as 1:0.5.3-2). The diff
> is attached to this message.

Thank you Sandro!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#954579: datalad-container: FTBFS: build-dependency not installable: datalad (>= 0.11.5~)

[Yaroslav Halchenko]

On Sun, 22 Mar 2020, Lucas Nussbaum wrote:

> Source: datalad-container
> Version: 0.5.0-1

Thank you for the report.  1.0.0-1 was built but forgotten to be
uploaded at the end of Feb.  Now it would need to wait until datalad
0.12.4 is uploaded first which would resolve incompatibilities with
recent git annex and git releases.  Hopefully later today/tomorrow

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#942615: no-changes source-only NMU

[Yaroslav Halchenko]

On Fri, 06 Mar 2020, Paul Gevers wrote:

> Control: tags -1 pending

> Dear maintainer,

> I have uploaded a no-changes source only version to DELAYED/15. Please
> tell me if I should delay or cancel the upload.

oh, I have missed that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942615
and that it was awaiting  THANKS!! Please feel welcome to reupload
without delay

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#951982: fixed upstream

[Yaroslav Halchenko]

FWIW, this issue should be fully addressed in recent releases.

in Debian we have 4.30.0-1, upstream release is v4.43.0, and this issue
was fixed in 

https://github.com/tqdm/tqdm/commit/0fcf9ed4c191fa224afd5581ac1a47b2cf80bc54#diff-79a0b30dff238cd3aa6b9f8e665a57a0
pandas: support v1.0.0  (so even for the version of pandas in experimental)

which is

$> git describe --contains 0fcf9ed4c191fa224afd5581ac1a47b2cf80bc54
v4.42.1^2~3

so, updating to the most recent release should resolve this issue and
prevent avalanche of removes from testing.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#932197: Bug#937144: Request to join the Neurodebian group

[Yaroslav Halchenko]

thank you Andreas!!!

re etelemetry:  I made it optional for previous version of the
package:

$> quilt series
deb-no-demand-on-etelemetry

$> git describe
debian/0.6.0-1


On Tue, 25 Feb 2020, Andreas Tille wrote:

> Hi,

> here is some update I'm also forwarding to NeuroDebian Team list to have
> some public record of the current status.

> On Thu, Feb 20, 2020 at 01:36:35AM +1100, Stuart Prescott wrote:

> > I also looked at nipype (but its source is very odd and I can't build what 
> > is 
> > in the repo; I think that was .gitattributes related but end up fixing it)

> I have updated nipype in the Git repository I moved to Debian Med team[1]
> The latest upstream version needs a new dependency python3-etelemetry
> which I packaged and uploaded to new (see #952558)

> I've also tried to build heudiconv in Git[2].  It builds so far but tests
> accessing remote locations to download data need to be disabled.  That's
> where I'm stoping for now.

> Kind regards

>Andreas.

> [1] https://salsa.debian.org/med-team/nipype
> [2] https://salsa.debian.org/med-team/heudiconv 
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#937249: closed by Abhijith PA (Bug#937249: fixed in patool 1.12-4)

[Yaroslav Halchenko]

On Thu, 06 Feb 2020, Yaroslav Halchenko wrote:
> On Wed, 15 Jan 2020, Abhijith PA wrote:
> > Hi Adrian,
> > On 15/01/20 5:47 pm, Adrian Bunk wrote:
> > > On Tue, Dec 17, 2019 at 03:21:07PM +, Debian Bug Tracking System 
> > > wrote:
> > >> ...
> > >> Architecture: source all
> > >> Version: 1.12-4
> > >> ...

> > > Please make a source-only upload to allow testing migration.

> > Currently I don't have any change to make a new source only upload. But
> > I am working on one of its lintian warning[1]. Once it is solved, I will
> > make a source only upload.

> should it be uploaded with a new revision just for the sake of source
> only upload?  I have sinned the same way and probably do the same for
> datalad

the issue needs to be resolved, so I have made source only upload of
1.12-4.1 into 3 days delayed.  Let me know if I should delay longer or
reupload without delay.  The only change was changelog (attached)

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
From 91ef4904d036de9c81b41098adf5cc5894516496 Mon Sep 17 00:00:00 2001
From: Yaroslav Halchenko 
Date: Wed, 12 Feb 2020 23:56:19 -0500
Subject: [PATCH] changelog for 1.12-4.1 -- source only upload

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a519270..dc566f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+patool (1.12-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * source-only upload to allow migration to bullseye
+
+ -- Yaroslav Halchenko   Wed, 12 Feb 2020 23:55:28 -0500
+
 patool (1.12-4) unstable; urgency=medium
 
   [ Ondřej Nový ]
-- 
2.24.0



signature.asc
Description: PGP signature

Bug#936305: marked as pending in citeproc-py

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #936305 in citeproc-py reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/citeproc-py/commit/fcbeb9a94dbaffda1f8056663984f7d59a8d8bd4


NMU upload: - remove debian/tests/python-citeproc to fully deprecate python2 
support

(Closes: #936305)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/936305

Bug#937249: closed by Abhijith PA (Bug#937249: fixed in patool 1.12-4)

[Yaroslav Halchenko]

On Wed, 15 Jan 2020, Abhijith PA wrote:

> Hi Adrian,

> On 15/01/20 5:47 pm, Adrian Bunk wrote:
> > On Tue, Dec 17, 2019 at 03:21:07PM +, Debian Bug Tracking System wrote:
> >> ...
> >> Architecture: source all
> >> Version: 1.12-4
> >> ...

> > Please make a source-only upload to allow testing migration.

> Currently I don't have any change to make a new source only upload. But
> I am working on one of its lintian warning[1]. Once it is solved, I will
> make a source only upload.

should it be uploaded with a new revision just for the sake of source
only upload?  I have sinned the same way and probably do the same for
datalad

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#936857: libfreenect: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

On Mon, 27 Jan 2020, Sandro Tosi wrote:
> in the archive we have 0.5.3, released in 2015; the latest upstream
> release is 0.5.7 which was released in 2017; the first release to
> support python3 is 0.5.4 of 2016.

> I see 2 paths forward:

> 1. (longer) the package gets upgraded to 0.5.7 (with a relative mini
> transition i guess) and that includes adding python3-freenect and drop
> python-freenect
> 2. (shorter) we keep 0.5.3 and we simply drop python-freenect, which
> has 0 reverse dependencies in the archive.

> What do you think it's best here?

I would have tried going "longer" way, given the age of 0.5.3.  Would
you have time for it Sandro, or should I try?

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Mon, 20 Jan 2020, Andreas Tille wrote:

> On Mon, Jan 20, 2020 at 01:01:00PM -0500, Yaroslav Halchenko wrote:

> > > I'm fine with re-doing what I changed if you consider it really of
> > > practical relevance.  If you ask me we two would spent time we could
> > > use more productively but its OK if you want to do it.

> > You just rename and I will do the rest (push your pristine-tar, align
> > branches properly).  then debcheckout should work for old people (if
> > gitlab redirects correctly as github does in such cases), and you could
> > proceed with your work ;)

> Just ping me if you are done.  Next time I should try to move first. :-)

I guess we got some communication disconnect... anyways -- since I have
needed super-powers in debian-med I did the move myself:

- changed name and adjusted path for yours to become

https://salsa.debian.org/med-team/nibabel-andreas

- went to https://salsa.debian.org/neurodebian-team/nibabel
 and in Settings -> General -> Advanced -> Transfer

 to Debian Med to get

 https://salsa.debian.org/med-team/nibabel

- verified -- debcheckout nibabel does the right thing, all the way from
  original elderly
  https://salsa.debian.org/neurodebian-team/pynifti.git
  redirecting to
  https://salsa.debian.org/med-team/nibabel 

- did following dance (extracting from bash history):

git remote add --fetch andreas https://salsa.debian.org/med-team/nibabel-andreas
git co --track andreas/pristine-tar
git push salsa -u pristine-tar
git co upstream
git push salsa -u upstream
git co master
git reset --hard andreas/master
git push salsa -u master


I think that should do it.  Please let me know if nothing is forgotten, and
then we could remove nibabel-andreas, and I would remove andreas remote
;)

after above I did

debcheckout nibabel  to see that it checks out old  dist/debian/proper which is
unavoidable since it  is what was in Vcs fields.  But I guess whenever you
upload new version with new Vcs -- all should work standard ways

PS note that nibabel is the core library for many python neuroimaging toolkits.
Typically before uploading it I was running our
https://github.com/neurodebian/neurodebian/blob/master/tools/nd_build_testrdepends
to see what next nibabel possibly breaks for other toolkits. I see that I
haven't done that for 3.0.0 yet, which IIRC did break API, so I expect
surprises to come with 3.0.0 upload

Cheers and thanks!
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Mon, 20 Jan 2020, Andreas Tille wrote:

> > so I should be able to transfer over to debian-med.  May be rename yours
> > into nibabel-med-initial  so I could do it?

> I'm fine with re-doing what I changed if you consider it really of
> practical relevance.  If you ask me we two would spent time we could
> use more productively but its OK if you want to do it.

You just rename and I will do the rest (push your pristine-tar, align
branches properly).  then debcheckout should work for old people (if
gitlab redirects correctly as github does in such cases), and you could
proceed with your work ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Mon, 20 Jan 2020, Andreas Tille wrote:

> Hi Yaroslav,

> On Mon, Jan 20, 2020 at 10:50:07AM -0500, Yaroslav Halchenko wrote:

> > > I think it would be helpful if you would remove the old repository
> > > in neurodebian-team.

> > shouldn't I (you) just "move" it on salsa under debian-med and then push
> > updated branches?  so if anyone clones old url, it would get redirected
> > to the new one?

> > otherwise I would probably need not just to remove it (imagine ppl doing
> > debcheckout on stable debian with older urls) but add some README
> > describing the move

> I admit I have no idea how I can technically move a repository.  Since I

googled up
https://docs.gitlab.com/ee/user/project/settings/

Navigate to your project’s Settings > General > Advanced settings.
Under “Transfer project”, choose the namespace you want to transfer the
project to.
Confirm the transfer by typing the project’s path as instructed.

so I should be able to transfer over to debian-med.  May be rename yours
into nibabel-med-initial  so I could do it?


> do not have permission to remove from neurodebian-team I doubt that any
> move is possible.  Thus I simply forked.  I agree with you that it would
> be better to inform the user directly.  I was simply trusting that any
> user of the repository would read out the current Vcs-Git fields from
> unstable - but I agree with you that its not sure that every user will
> do this.

> In any case the old repository is now lagging behind the new one in
> med-team.  That's the worst situation while your suggestion to simply
> drop a README there would be the best.  Simply removing it and let users
> seek in case they do not find anything is somewhere inbetween those two
> situations. ;-)

let's try moving first? ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Mon, 20 Jan 2020, Andreas Tille wrote:

> Hi Yaroslav,

> On Sun, Jan 19, 2020 at 02:41:52PM -0500, Yaroslav Halchenko wrote:

> > actually as far as I see it Sando has pushed everything for
> > 2.5.1-2
> > https://salsa.debian.org/neurodebian-team/nibabel/blob/dist/debian/proper/debian/changelog
> > which is the latest AFAIK

> Ahhh.

> > PS I have changed the default branch on salsa to dist/debian/proper to
> > match the one we used as one of our utopian plans to stay organized for
> > different distributions/releases ;)

> OK, I moved the nibabel repository to Debian Med and while doing so I
> moved the "interesting" branches to the default layout that is described
> in team policy (master, upstream, pristine-tar).  I hope I did not
> spoiled your utopian plan to much in favour of easier access for all
> team members.


> I think it would be helpful if you would remove the old repository
> in neurodebian-team.

shouldn't I (you) just "move" it on salsa under debian-med and then push
updated branches?  so if anyone clones old url, it would get redirected
to the new one?

otherwise I would probably need not just to remove it (imagine ppl doing
debcheckout on stable debian with older urls) but add some README
describing the move

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#948372: Please push your changes to nibabel

[Yaroslav Halchenko]

On Sun, 19 Jan 2020, Andreas Tille wrote:

> Hi Yaroslav,

> can you please push your latest changes to nibabel?  I'd volunteer
> to fix #948372 and when doing so move the repository to Debian Med
> if you do not mind.

actually as far as I see it Sando has pushed everything for
2.5.1-2
https://salsa.debian.org/neurodebian-team/nibabel/blob/dist/debian/proper/debian/changelog
which is the latest AFAIK

PS I have changed the default branch on salsa to dist/debian/proper to
match the one we used as one of our utopian plans to stay organized for
different distributions/releases ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#929954: [Python-apps-team] Bug#929954: what about just uploading relevant patch for now?

[Yaroslav Halchenko]

On Fri, 09 Aug 2019, Elena ``of Valhalla'' wrote:

> Yaroslav Halchenko  wrote:
> > If new version building is problematic, why not to upload just a patched
> > version?

> That would only delay the removal a bit: I'm sure that the current
> version doesn't work with python3, so it's going to be removed sooner or
> later from the archive.

> Uploading the new upstream would also be python2 only, at least at the
> beginning, but at least there is hope that it can be made to work also
> with python3.

> I don't expect the new version to be problematic, but it will involve a
> bit of yak shaving, and and see #876681 (RFH: rst2pdf) on how this
> package is pretty low on my priorities.

Hi Elena et al

I wonder if anything could be done to have this package fixed, so
dependent packages (e.g. nuitka) aren't blocked awaiting for the
resolution.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#936450: duecredit: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

thanks! fixing now

On Thu, 19 Dec 2019, Andreas Beckmann wrote:

> Followup-For: Bug #936450
> Control: found -1 0.7.0-2

> There are some references to python2 left, causing the package to FTBFS:
> https://buildd.debian.org/status/fetch.php?pkg=duecredit=all=0.7.0-2=1576039796=0

>  fakeroot debian/rules clean
> dh clean --with python2,python3 --buildsystem=pybuild
> dh: unable to load addon python2: Can't locate 
> Debian/Debhelper/Sequence/python2.pm in @INC (you may need to install the 
> Debian::Debhelper::Sequence::python2 module) (@INC contains: /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.30.0 /usr/local/share/perl/5.30.0 
> /usr/lib/x86_64-linux-gnu/perl5/5.30 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
> /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 9) 
> line 1.
> BEGIN failed--compilation aborted at (eval 9) line 1.



-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#913015: Bug#936372: dcmstack: diff for version 0.7-2

[Yaroslav Halchenko]

On Tue, 17 Dec 2019, Sandro Tosi wrote:

> Control: tags 913015 + patch
> Control: tags 936372 + patch
> Control: tags 942992 + patch


> Dear maintainer,

> I've prepared an upload for dcmstack (versioned as 0.7-2). The diff
> is attached to this message.

> i dont have access to the GH repos, so i post the changes here

THANKS!  I couldn't git am -- wanted to preserve your ownership, but to
late to mess with env variables -- invited you as a collaborator to 
GH for that repo

Thanks again
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#945348: python3-joblib: Missing new dependency python3-pkg-resources

[Yaroslav Halchenko]

On Sat, 23 Nov 2019, Andreas Tille wrote:

> Package: python3-joblib
> Version: 0.14.0-0.2
> Severity: critical
> Tags: patch
> Justification: breaks unrelated software


> Hi,

> as per latest debci log of spades[1] joblib needs python3--pkg-resources.

> I will add this to the dependencies but I will also take over joblib
> packaging to Debian Science team to make the package watched by a
> greater audience.  I've got confirmation from Yaroslav for similar
> cases in the past so I assume its OK.

Yes, thank you Andreas!  If you could also keep it at debcompat 10, all
backport gods would favor you ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#934868: pynwb: Please drop python2 support

[Yaroslav Halchenko]

On Thu, 17 Oct 2019, peter green wrote:

> severity 934868 serious
> thanks

> python-pynwb depends on python-h5py, which is no longer built by the h5py 
> source package.

> unfortunately it seems hdmf is still stuck in new, can you go ahead with 
> uploading the python2 removal with the current version?

yeah. I had prepared 1.0.3-1 with python2 removed but it needs hdmf
and NEW queue seems to be pretty much without any attention, so
unlikely hdmf would be accepted any time soon. ok - I will prepare
0.5.1-2 which would also remove python2

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#903213: fixed in datalad 0.10.2-1

[Yaroslav Halchenko]

On Tue, 06 Aug 2019, Santiago Vila wrote:

> reopen 903213
> found 903213 0.4.1-1
> fixed 903213 0.10.2-1
> thanks

> Hi. Could we please fix this in stretch?
> (Packages in stretch must be buildable in stretch).

...
FAILED (SKIP=65, errors=63, failures=15)

I will unlikely embark on that endeavor until I retire and get really
bored! ;-)  (well -- the "fix" could be just disabling testing).

those failures cheeped in  with some new then release of git or
git-annex most likely.

stretch is now a very oldstable, and 0.4.1 of datalad is even more so --
we are aiming to release 0.12 soon.

if anything -- feel welcome to remove datalad from stretch


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#941242: pymc: intention to remove this package from Debian

[Yaroslav Halchenko]

I guess it could indeed be removed, even if only to raise later from ashes as 
pymc3

Cheers

On September 26, 2019 7:18:08 PM EDT, Sandro Tosi  wrote:
>Source: pymc
>Severity: serious
>
>Hello,
>pymc is abandoned upstream and replaced by pymc3 (python3 only module),
>https://github.com/pymc-devs/pymc3 .
>
>Currently pymc has a single (initial) maintainer upload, the only other
>one
>being a NMU, it's not in the last 2 stable releases, have 2 RCs bugs
>unaddressed, so it's my belief we should remove this package.
>
>if I dont get back a good reason to keep this package in Debian withing
>a week,
>i will file for its removal (it has no reverse dependencies).
>
>Regards,
>Sandro
>
>-- System Information:
>Debian Release: 10.0
>  APT prefers unstable-debug
>APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
>'experimental-debug'), (1, 'experimental')
>Architecture: amd64 (x86_64)
>Foreign Architectures: i386
>
>Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
>Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
>TAINT_UNSIGNED_MODULE
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>LANGUAGE= (charmap=UTF-8)
>Shell: /bin/sh linked to /bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled

-- 
Yaroslav O. Halchenko (mobile version)
Center for Open Neuroscience   http://centerforopenneuroscience.org
Dartmouth College, NH, USA

Bug#934687: Bug#938974: Removed package(s) from unstable

[Yaroslav Halchenko]

On Mon, 02 Sep 2019, Debian FTP Masters wrote:

> Version: 0.5.3-1+rm

oh well -- I have missed all the reports (misconfigured debian.net
MX for a few months, heh).  So only saw the effect of RM.  Just want to
clarify

heudiconv is maintained

python3 support was added upstream as of 0.3 I believe so current
removed version of the package just needed tune up to packaging

PS given that https://ftp-master.debian.org/new.html already quite
   "stuffed" and processing times seems to be months ATM, may be removals
   are given more consideration

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#935015: Thank you!

[Yaroslav Halchenko]

Dear Sandro, Steve, and Peter

Thank you for all the modernization of DataLad package.  Feel welcome to
upload to shorter NMU if desired/needed.  Some of those changes are now
addressed upstream and I will include/ack your NMUs with the next
release of datalad package.

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#929954: what about just uploading relevant patch for now?

[Yaroslav Halchenko]

Package: rst2pdf
Version: 0.93-7
Followup-For: Bug #929954

If new version building is problematic, why not to upload just a patched
version?  I have verified that adding import reportlab to
/usr/lib/python2.7/dist-packages/rst2pdf/flowables.py addresses the issue

I ran into this one while building new version of nuitka, so its new version
upload blocked by this one.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rst2pdf depends on:
ii  python2.7.16-1
ii  python-docutils   0.14+dfsg-4
ii  python-pdfrw  0.4-2
ii  python-pkg-resources  40.8.0-1
ii  python-pygments   2.3.1+dfsg-1
ii  python-reportlab  3.5.13-1
ii  python-setuptools 40.8.0-1
ii  python-simplejson 3.16.0-1
ii  python3-pygments  2.3.1+dfsg-1

rst2pdf recommends no packages.

Versions of packages rst2pdf suggests:
pn  python-aafigure  
ii  python-matplotlib2.2.3-6
ii  python-pil   5.4.1-2
ii  python-sphinx1.8.4-1
ii  python-uniconvertor  1.1.5-4

-- debconf-show failed

Bug#926930: joblib: FTBFS (test_nested_parallelism_limit does not always work)

[Yaroslav Halchenko]

TL;DR summary:
interesting... in my case reliably fails locally on python 3.6 and 3.7 but not 
2.7 even with fresh release of 0.13.0
reported upstream https://github.com/joblib/joblib/issues/870

Thanks for the patch -- I will xfail it in  0.13.0-1 with this, upload to
unstable, and then upload 0.13.2-1 with it to experimental

Some notes collected:

1. I think it is the same issue as
https://github.com/joblib/joblib/issues/758 which was addressed upstream in 

commit f58e833df6802bbc2120a9eb2c608a8c35dbc099
Author: Olivier Grisel 
Date:   Mon Aug 27 11:34:30 2018 +0200

Fix a bug in nesting level computation with 
FallbackToBackend(SequentialBackend()) (#759)

which is

$> git describe --contains f58e833df6802bbc2120a9eb2c608a8c35dbc099
0.12.3~5 

so might have been regression in

Version: 0.13.0-1

where (on upstream) 

taskset -c 0 python -m pytest -v -k test_nested_parallelism_limit

passes just ok, so probably not a straight regression.

2. Could trigger "reliably" for the second (python 3.7) test run while
passing for 2.7

with change

$> git diff
diff --git a/debian/rules b/debian/rules
index 0ede50a..dd4d8ef 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,7 @@ override_dh_auto_test: ${PYVERS:%=python-test%} 
${PY3VERS:%=python-test%}
 
 python-test%:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-   PYTHONPATH=$(CURDIR) python$* /usr/bin/py.test -s -v joblib;
+ PYTHONPATH=$(CURDIR) python$* /usr/bin/py.test -s -v -k 
test_nested_parallelism_limit joblib;
 else
: # Skip unittests due to nocheck
 endif

and running

taskset -c 0 fakeroot debian/rules binary



> Note: I've checked and this failure may be reproduced easily on any
> system by doing "taskset -c 0 dpkg-buildpackage", but if for whatever
> reason you need a single-CPU system to test, please contact me
> privately and I will gladly provide one.

> Thanks.

> --- a/joblib/test/test_parallel.py
> +++ b/joblib/test/test_parallel.py
> @@ -1429,6 +1429,7 @@ def _recursive_backend_info(limit=3, **kwargs):
>  return this_level + results[0]


> +@pytest.mark.xfail
>  @with_multiprocessing
>  @parametrize('backend', ['loky', 'threading'])
>  def test_nested_parallelism_limit(backend):



Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#918206: Pandas

[Yaroslav Halchenko]

On Wed, 27 Feb 2019, Andreas Tille wrote:

> Dear Rebecca,

> On Wed, Feb 27, 2019 at 07:25:26AM +, Rebecca N. Palmer wrote:
> > On 27/02/2019 07:00, Andreas Tille wrote:
> > > Dear Rebecca,
> > > I do not think that there is any
> > > need for a separate branch.  Just stick to the debian branch.

> > It's needed because the debian branch contains the attempt at packaging 0.24
> > described earlier in this thread, which it's now too late for.

> You are right.  Considering the branching jungle (Yaroslav, could you possibly

for someone jungle is a sweet sweet home! ;)

$> git br -a | grep salsa | grep -e bf- -e enh- -e cythoned | while 
read b; do git push salsa :${b//*salsa\//}; done
To salsa.debian.org:science-team/pandas.git
 - [deleted] __tent/debian-cythoned-quilt
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-cython
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-i386
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-native-endianness
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-skips
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-unser
To salsa.debian.org:science-team/pandas.git
 - [deleted] bf-versions-etc
To salsa.debian.org:science-team/pandas.git
 - [deleted] enh-tests-compat-pytables-2.1

and will try to not forget to not push them again ;)

$> git br -a | grep salsa # -- with my annotations
  remotes/salsa/master -- some upstream's point of master -- could 
also be removed if you like
  remotes/salsa/releases   -- linear progression of upstream releases
  remotes/salsa/debian -- sits on top of releases and carries 
packaging
  remotes/salsa/debian-experimental -- the one for uploads to 
experimental

better now?

> cleanup branches that are not used any more?) I'd prefer if you would move the
> 0.24 packaging to some separate branch (debian-experimental is covered but may
> be debian-0.24 or something like this?) and keep branch debian for what we are
> really releasing.

well "releasing" is a loaded term. I guess you are talking about uploading to
unstable so it manages to get into buster.  Since "debian" branch already got
its 0.24, what about starting debian-buster branch off debian/0.23.3-1 ?

otherwise -- I am ok to hard-reset and force push debian to the debian/0.23.3-1
state -- everyone should just beware of it, and then progress
debian-experimental to current state of debian (v0.24.1-972-g1cfbd07c7)

your call

> Thanks again for your work on this

yeap, Thank you Rebecca!

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#917740: not about CHANGES

[Yaroslav Halchenko]

tags 917740 +unreproducible +moreinfo
severity 917740 normal
thanks

Rebuilt package in current sid pbuilder env - no failing test.  So my
fear is that the issue is somehow specific to that environment where it
failed or something has changed since then.   Lowering severity.  I will
upload fresh upstream shortly - so we will see if reproduces then

On Sun, 03 Feb 2019, Yaroslav Halchenko wrote:

> CHANGES error is benign , will clarify upstream 
> https://github.com/nipy/nipype/issues/2873

> the actual issue is

> > raise TypeError("expected str, bytes or os.PathLike object, 
> > "
> > >   "not " + path_type.__name__)
> > E   TypeError: expected str, bytes or os.PathLike object, not 
> > unicode

> or in full:

> > === FAILURES 
> > ===
> > _ test_split_and_merge 
> > _

> > tmpdir = local('/tmp/pytest-of-user42/pytest-0/test_split_and_merge0')

> > def test_split_and_merge(tmpdir):
> > import numpy as np
> > import nibabel as nb
> > import os.path as op
> > import os

> > from nipype.algorithms.misc import split_rois, merge_rois

> > in_mask = example_data('tpms_msk.nii.gz')
> > dwfile = tmpdir.join('dwi.nii.gz').strpath
> > mskdata = nb.load(in_mask, mmap=NUMPY_MMAP).get_data()
> > aff = nb.load(in_mask, mmap=NUMPY_MMAP).affine

> > dwshape = (mskdata.shape[0], mskdata.shape[1], mskdata.shape[2], 6)
> > dwdata = np.random.normal(size=dwshape)
> > tmpdir.chdir()
> > nb.Nifti1Image(dwdata.astype(np.float32), aff, 
> > None).to_filename(dwfile)

> > >   resdw, resmsk, resid = split_rois(dwfile, in_mask, roishape=(20, 
> > > 20, 2))

> > /<>/nipype/algorithms/tests/test_splitmerge.py:26: 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 
> > /<>/nipype/algorithms/misc.py:1318: in split_rois
> > np.savez(iname, (nzels[0][first:last], ))
> > /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:619: in savez
> > _savez(file, args, kwds, False)
> > /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:700: in _savez
> > file = os_fspath(file)
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 

> > path = 
> > '/tmp/pytest-of-user42/pytest-0/test_split_and_merge0/roi00_idx'

> > def os_fspath(path):
> > """Return the path representation of a path-like object.
> > If str or bytes is passed in, it is returned unchanged. Otherwise 
> > the
> > os.PathLike interface is used to get the path representation. If the
> > path representation is not str or bytes, TypeError is raised. If the
> > provided path is not str, bytes, or os.PathLike, TypeError is 
> > raised.
> > """
> > if isinstance(path, (str, bytes)):
> > return path

> > # Work from the object's type to match method resolution of other 
> > magic
> > # methods.
> > path_type = type(path)
> > try:
> > path_repr = path_type.__fspath__(path)
> > except AttributeError:
> > if hasattr(path_type, '__fspath__'):
> > raise
> > elif PurePath is not None and issubclass(path_type, PurePath):
> > return _PurePath__fspath__(path)
> > else:
> > raise TypeError("expected str, bytes or os.PathLike object, 
> > "
> > >   "not " + path_type.__name__)
> > E   TypeError: expected str, bytes or os.PathLike object, not 
> > unicode

> > /usr/lib/python2.7/dist-packages/numpy/compat/py3k.py:237: TypeError
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#917740: not about CHANGES

[Yaroslav Halchenko]

CHANGES error is benign , will clarify upstream 
https://github.com/nipy/nipype/issues/2873

the actual issue is

> raise TypeError("expected str, bytes or os.PathLike object, "
> >   "not " + path_type.__name__)
> E   TypeError: expected str, bytes or os.PathLike object, not 
> unicode

or in full:

> === FAILURES 
> ===
> _ test_split_and_merge 
> _
> 
> tmpdir = local('/tmp/pytest-of-user42/pytest-0/test_split_and_merge0')
> 
> def test_split_and_merge(tmpdir):
> import numpy as np
> import nibabel as nb
> import os.path as op
> import os
> 
> from nipype.algorithms.misc import split_rois, merge_rois
> 
> in_mask = example_data('tpms_msk.nii.gz')
> dwfile = tmpdir.join('dwi.nii.gz').strpath
> mskdata = nb.load(in_mask, mmap=NUMPY_MMAP).get_data()
> aff = nb.load(in_mask, mmap=NUMPY_MMAP).affine
> 
> dwshape = (mskdata.shape[0], mskdata.shape[1], mskdata.shape[2], 6)
> dwdata = np.random.normal(size=dwshape)
> tmpdir.chdir()
> nb.Nifti1Image(dwdata.astype(np.float32), aff, 
> None).to_filename(dwfile)
> 
> >   resdw, resmsk, resid = split_rois(dwfile, in_mask, roishape=(20, 20, 
> > 2))
> 
> /<>/nipype/algorithms/tests/test_splitmerge.py:26: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /<>/nipype/algorithms/misc.py:1318: in split_rois
> np.savez(iname, (nzels[0][first:last], ))
> /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:619: in savez
> _savez(file, args, kwds, False)
> /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:700: in _savez
> file = os_fspath(file)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> path = 
> '/tmp/pytest-of-user42/pytest-0/test_split_and_merge0/roi00_idx'
> 
> def os_fspath(path):
> """Return the path representation of a path-like object.
> If str or bytes is passed in, it is returned unchanged. Otherwise the
> os.PathLike interface is used to get the path representation. If the
> path representation is not str or bytes, TypeError is raised. If the
> provided path is not str, bytes, or os.PathLike, TypeError is raised.
> """
> if isinstance(path, (str, bytes)):
> return path
> 
> # Work from the object's type to match method resolution of other 
> magic
> # methods.
> path_type = type(path)
> try:
> path_repr = path_type.__fspath__(path)
> except AttributeError:
> if hasattr(path_type, '__fspath__'):
> raise
> elif PurePath is not None and issubclass(path_type, PurePath):
> return _PurePath__fspath__(path)
> else:
> raise TypeError("expected str, bytes or os.PathLike object, "
> >   "not " + path_type.__name__)
> E   TypeError: expected str, bytes or os.PathLike object, not 
> unicode
> 
> /usr/lib/python2.7/dist-packages/numpy/compat/py3k.py:237: TypeError


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#919727: cmtk /dcmtk

[Yaroslav Halchenko]

On Mon, 21 Jan 2019, Torsten Rohlfing wrote:

>Hi there -
>Upstream owner of CMTK here. It looks like DCMTK in release 3.6.4 changed
>their API for locking/unlocking the global data dictionary.
>I am going to look into fixing this, but it'll take a while since I'll
>have to set up a suitable Debian VM for testing first.

docker run -it --rm debian:sid

adjust /etc/apt/sources.list to include deb-src entries

apt-get update
apt-get build-dep cmtk

and you should be all set ;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#896025: Segfault in test suite of new upstream version (Was: python-mne FTBFS with python-matplotlib 2.2.2-1)

[Yaroslav Halchenko]

Dear Andreas

Thank you for taking a stab at this!  I will try to not forget to look
at it tomorrow (need to meet some other deadlines today).  If you had a
chance to try figuring out in what part segfault happens (I would just
strace -f -o /tmp/strace.log python -m pytest ...) it might give a clue.
Might as well be an xvfb issue

On Wed, 19 Dec 2018, Andreas Tille wrote:

> Control: tags -1 help
> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/mne-tools/mne-python/issues/5806

> Hi,

> it seems the matplotlib issue reported here is solved in the last
> upstream version which I commited to packaging Git[1].  Unfortunately
> there is another issue which I reported upstream[2]:

> ...
> make[1]: Entering directory '/build/python-mne-0.17+dfsg'
> mkdir -p build
> HOME=/build/python-mne-0.17+dfsg/build \
> MNE_DONTWRITE_HOME=true MNE_SKIP_SAMPLE_DATASET_TESTS=true 
> MNE_FORCE_SERIAL=true MNE_SKIP_NETWORK_TESTS=1 \
>   xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 -ac 
> +extension GLX +render -noreset" \
>   py.test -s -v mne
> = test session starts 
> ==
> platform linux2 -- Python 2.7.15+, pytest-3.10.1, py-1.7.0, pluggy-0.8.0 
> -- /usr/bin/python2
> cachedir: .pytest_cache
> rootdir: /build/python-mne-0.17+dfsg, inifile: setup.cfg
> plugins: cov-2.6.0
> collecting ... Using default location ~/mne_data for testing...
> Creating ~/mne_data
> Using default location ~/mne_data for testing...
> Using default location ~/mne_data for testing...
> ...
> Using default location ~/mne_data for testing...
> Using default location ~/mne_data for testing...
> Segmentation fault
> make[1]: *** [debian/rules:26: override_dh_auto_test] Error 139
> make[1]: Leaving directory '/build/python-mne-0.17+dfsg'


> I wonder whether one of the Uploaders (in CC) will be able to
> fix this since I feel absolutely incompetent to solve this.

> Kind regards

>Andreas.


> [1] https://salsa.debian.org/med-team/python-mne
> [2] https://github.com/mne-tools/mne-python/issues/5806
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

Dear Yangfl and other Debian-science folks

could you please have a look at the scikit-learn packaging, which was
heavily tuned up recently and I have little to no clue how to
augment it reliably back or to avoid parallel build and its gotchas.
See http://bugs.debian.org/911830 for more details

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

Great, thanks
For starters I would just disable parallel invocation of debian/rules since 
indeed there is no guarantee of absent races. Will do and reupload when get 
back from dentist ;-)
-- 
Yaroslav O. Halchenko (mobile version)
Center for Open Neuroscience   http://centerforopenneuroscience.org
Dartmouth College, NH, USA

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

On Sun, 02 Dec 2018, Yaroslav Halchenko wrote:

> > There's no visible progress on this problem in git -- is there progress 
> > elsewhere?

> you could find some traces of the progress which lead to i386 fixes on
> https://github.com/scikit-learn/scikit-learn/issues?utf8=%E2%9C%93=is%3Aissue+author%3Ayarikoptic+

> I welcome you to review/analyze failures on other platforms and/or just
> report them upstream.  or I would do it whenever I get a chance 

s390x (and also arm64) issue is here upstream
https://github.com/scikit-learn/scikit-learn/issues/10561

if you care to help, please try to figure out WTF with ppc64el:
https://buildd.debian.org/status/fetch.php?pkg=scikit-learn=ppc64el=0.20.1%2Bdfsg-1=1543512601=0
where it even doesn't build... might be a cython issue

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#911830: FTBFS on multiple architectures

[Yaroslav Halchenko]

On Sun, 02 Dec 2018, Stuart Prescott wrote:

> Dear Yaroslav & Michael,

> scikit-learn currently FTBFS everywhere. 

please define your version of "everywhere".  From
https://buildd.debian.org/status/package.php?p=scikit-learn=unstable
I see that 0.20.1+dfsg-1 builds fine on all intel and mips architectures

I would not upload a version which FTBFS on amd64, and unlikely to
upload the one which FTBFS on i386

> I've had a bit of a poke at it and 
> not got very far:

> - if run as a parallel build, I can't figure out what actually fails

> - if run with only one job (sbuild -j1), the build does not actually attempt 
> to build with either python 3.6 or 3.7 at all. (which sounds like a separate 
> bug in d/rules)

I guess any relevant "parallelism" effects (although there was a recent
fix also for joblib and non-parallel runs) stem from

2b495fe013 (yangfl 2018-10-19 23:22:43 +0800  72) # silly distutils does not 
support parallelism! waste hours of time
2b495fe013 (yangfl 2018-10-19 23:22:43 +0800  73) .PHONY: build
32438ee441 (yangfl 2018-10-20 16:06:58 +0800  74) build build-arch build-indep:
32438ee441 (yangfl 2018-10-20 16:06:58 +0800  75)   $(MAKE) -j $(JOBS) -f 
debian/rules _$@

so CCing Yangfl who worked on improving packaging at some point.  Unfortunately
neither from those commits messages, nor from debian/changelog I could not
figure out what was the purpose of this act really and either it is kosher at
all  (e.g. wouldn't confuse dh)

> There's no visible progress on this problem in git -- is there progress 
> elsewhere?

you could find some traces of the progress which lead to i386 fixes on
https://github.com/scikit-learn/scikit-learn/issues?utf8=%E2%9C%93=is%3Aissue+author%3Ayarikoptic+

I welcome you to review/analyze failures on other platforms and/or just
report them upstream.  or I would do it whenever I get a chance 

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#908555: Bug #908555 in pydicom marked as pending

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #908555 in pydicom reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/pydicom/commit/60a9b257b3b39ca3a9156398ed6bebe4ce418ac9


- Removed gdcm from B-Depends and moved under Suggests since it is an optional 
dependency (Closes: #908555)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908555

Bug#907335: similar issue

[Yaroslav Halchenko]

thanks!  upstream says the issue was fixed in
https://github.com/pydata/patsy/pull/131
so I will just build a fresh snapshot

Cheers!

On Sat, 27 Oct 2018, Julian Taylor wrote:

> this problem probably has the same python change as cause as this issue:

> https://github.com/PyCQA/pycodestyle/issues/786
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908700


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#909990: Stange import error for nibabel when trying to import from .pybuild

[Yaroslav Halchenko]

Thank you Andreas for looking into it

2.3.1 bugfix is around the corner
https://github.com/nipy/nibabel/pull/667
so I will aim to make sure the #909990 is fixed within it (for starters
- I do not think I observed this exception when building from current RC
  branch)


On Mon, 08 Oct 2018, Andreas Tille wrote:

> Hi,

> to see what I can do about bug #909990 I've imported the latest version
> into the packaging Git[1].  When beeing inside the main dir of the Git
> repository I can easily do

> neurodebian-team/pynifti(debian) $ python3
> Python 3.6.6 (default, Jun 27 2018, 14:44:17) 
> [GCC 8.1.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import nibabel


> However, if I try inside the .pybuild dir I get:

> /build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build# python3.6
> Python 3.6.7rc1 (default, Sep 27 2018, 09:51:25) 
> [GCC 8.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import nibabel
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/__init__.py",
>  line 45, in 
> from .loadsave import load, save
>   File 
> "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/loadsave.py",
>  line 18, in 
> from .imageclasses import all_image_classes
>   File 
> "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/imageclasses.py",
>  line 16, in 
> from .minc1 import Minc1Image
>   File 
> "/build/nibabel-2.3.0/.pybuild/cpython3_3.6_nibabel/build/nibabel/minc1.py", 
> line 20, in 
> from .deprecated import FutureWarningMixin
> ImportError: cannot import name 'FutureWarningMixin'

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#906388: nipy: FTBFS in buster/sid (failing tests)

[Yaroslav Halchenko]

update:
- uploaded sympy 1.3 which resolves sympy bug
- running by upstream the resolution for the other failed test:
  https://github.com/nipy/nipy/pull/445

and will upload fixed up package tomorrow


On Tue, 02 Oct 2018, Yaroslav Halchenko wrote:

> FWIW, two of the errors are caused by a bug in sympy which was fixed in
> 1.3 .  I am preparing sympy 1.3 although didn't check yet if it would
> fix it in nipy tests (not clear why it wasn't triggered before)

> On Fri, 17 Aug 2018, Santiago Vila wrote:

> > Package: src:nipy
> > Version: 0.4.2-1
> > Severity: serious
> > Tags: ftbfs

> > Dear maintainer:

> > I tried to build this package in buster but it failed:
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#906388: nipy: FTBFS in buster/sid (failing tests)

[Yaroslav Halchenko]

FWIW, two of the errors are caused by a bug in sympy which was fixed in
1.3 .  I am preparing sympy 1.3 although didn't check yet if it would
fix it in nipy tests (not clear why it wasn't triggered before)

On Fri, 17 Aug 2018, Santiago Vila wrote:

> Package: src:nipy
> Version: 0.4.2-1
> Severity: serious
> Tags: ftbfs

> Dear maintainer:

> I tried to build this package in buster but it failed:
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 01 Oct 2018, Andreas Tille wrote:

> Hi Yaroslav,

> was this helpful for you?

sorry -- didn't look into scikit-learn yet. BTW - 0.20 release was
posted, so we should update and try again.  Will you have time or should
I ?

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#866455: Bug #866455 in psychopy marked as pending

[Yaroslav Halchenko]

Control: tag -1 pending

Hello,

Bug #866455 in psychopy reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/neurodebian-team/psychopy/commit/7417072cba9b76c1e1e742623d66bf6050395d49


replace python-imaging with python-pil (Closes: #866455)



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/866455

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> Probably due to racing condition since I migrated the repository before
> your pushes.

> > > either needed to be imported as quilt patches or alternatively you can
> > > use git mode in d/watch which creates a new tarball for you
> > > incorporating the latest state of upstream Git (I doubt that would be a
> > > sensible solution in the current case).

> > if we are to stay with my non conventional setup of sitting straight on
> > top of the upstream git repo, then we would just need to merge
> > debian-0.20 branch into debian branch (might be a fast-forward) whenever
> > we are ready to upload that beast. 

> I confirm that there are cases where this workflow makes sense.  We need
> to outweight pros and cons.

To say the truth, I am no longer sure since it is possible to still have
regular upstream repo as a remote and dedicated branches for them in the
same git repo (locally), so I could still cherry pick etc.  Pretty much
what I do eg for cython etc.

That is why I am agreeing to go "standard" so to make life easier for
others as well.

My only concern with the "standard" workflow ATM is that pristine-tar is
not as reliable as needed to be. # of open issues manifests to that
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pristine-tar;dist=unstable
and Joey himself moved from using it to dgit AFAIK.  But anyways it is
unrelated to this discussion, sorry for bringing it up ;(

> > ...
> > If we are to convert to the more conventional gbp workflow (I am ok with
> > that now ;)) , I guess the best would be to just reimport from the
> > snapshots entire history of the package and proceed from there.  Then
> > commits in debian-0.20 would need to be rebased (or cherry picked or
> > your suggested format-patch+am) to stay on top of the "master"
> > branch 

> I hope I will find the time tomorrow or the day after tomorrow.

thanks

> > and picking any needed changes, would be appreciated.  I will adjust ;)

> I'll check what might be the easier solution and will come back once I
> did so.  Hopefully you will have solved the ssh issue meanwhile. 

I will try again later today, and when home (different network/provider)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> > > When you talked about new upstream version:  Do you want to give 0.20rc1

> > I did give it a try...

> > From the now empty list of
> > https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it
> > might be that all of the ones I've filed are addressed by now, BUT I do not 
> > see
> > them in

> > $> git lg 0.20rc1..origin/0.20.X   
> > * c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) 
> > [Joel Nothman]
> > * 17f8016c5 - Bugfix release of joblib that also restores PyPy support 
> > (#12012) (3 weeks ago) [Olivier Grisel]
> > * c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel 
> > Nothman]
> > * 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman]
> > * 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) 
> > [Joel Nothman]
> > * 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel 
> > Nothman]

> > so might have been fixed in master, and not backported yet, which indeed
> > might be the case:
> > https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493

> You asked me to clone http://github.com/yarikoptic/scikit-learn to
> https://salsa.debian.org/science-team/scikit-learn which I did.  In

cool

> *your* packaging repository is no branch 0.20rc1 those commits would be

indeed salsa clone is missing the
https://github.com/yarikoptic/scikit-learn/tree/debian-0.20 branch which
sits on top of debian branch and the 0.20rc1 upstream tag (pushed
now to my fork on github)

> either needed to be imported as quilt patches or alternatively you can
> use git mode in d/watch which creates a new tarball for you
> incorporating the latest state of upstream Git (I doubt that would be a
> sensible solution in the current case).

if we are to stay with my non conventional setup of sitting straight on
top of the upstream git repo, then we would just need to merge
debian-0.20 branch into debian branch (might be a fast-forward) whenever
we are ready to upload that beast. 

> I have no trouble with accessing the repository on Salsa.

> > Meanwhile, debian-0.20 branch is on
> > http://github.com/yarikoptic/scikit-learn

> I admit I'm not sure what you want me to do next.  It somehow smells


> like using git mode in debian/watch and try to extract your commits to
> debian/ dir via `git format-patch` and import these into Debian Science
> repository via `git am`.  However, I do not see this as very promising

If we are to convert to the more conventional gbp workflow (I am ok with
that now ;)) , I guess the best would be to just reimport from the
snapshots entire history of the package and proceed from there.  Then
commits in debian-0.20 would need to be rebased (or cherry picked or
your suggested format-patch+am) to stay on top of the "master"
branch 

> since I'm not sure whether you are really in favour to migrate to Debian
> Science or rather stick to your workflow.  

I am ok with either way now, as long as the package stays easy to
backport (so cythonize in debian/rules etc stays)

> So before I start spending
> time into this it would be helpful if you confirm that you can

>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git

as I said, smth is finicky with ssh for me for salsa:

$>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git 
gbp:info: Cloning from 'g...@salsa.debian.org:science-team/scikit-learn.git'
gbp:error: Git command failed: Error running git clone: ssh: connect to host 
salsa.debian.org port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

$> sudo tcptraceroute salsa.debian.org 22
Running:
traceroute -T -O info -p 22 salsa.debian.org 
traceroute to salsa.debian.org (209.87.16.44), 30 hops max, 60 byte packets
 1  _gateway (10.31.176.1)  1.733 ms  2.085 ms  2.620 ms
 2  berry1-crt.border1-rt.dartmouth.edu (129.170.1.42)  2.598 ms  2.074 ms  
2.060 ms
 3  i2-cleveland.border1-rt.dartmouth.edu (129.170.9.241)  6.170 ms  6.151 ms  
6.155 ms
 4  et-3-1-0.4079.rtsw.clev.net.internet2.edu (162.252.70.93)  15.175 ms  
15.531 ms  15.542 ms
 5  ae-1.4079.rtsw.eqch.net.internet2.edu (162.252.70.131)  25.121 ms  25.082 
ms  24.325 ms
 6  et-7-0-0.4079.rtsw.minn.net.internet2.edu (162.252.70.107)  31.915 ms  
32.184 ms  31.981 ms
 7  et-7-0-0.4079.rtsw.miss2.net.internet2.edu (162.252.70.59)  55.142 ms  
57.452 ms  55.346 ms
 8  et-4-1-0.4079.rtsw.seat.net.internet2.edu (162.252.70.1)  65.376 ms  65.717 
ms  65.842 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *


I can clone though via https:// (just can't push changes via ssh)

> and we both agree about the method how we want to inject the upstream
> source there.  Debian Science policy says this is done via

>gbp import-orig --pristine-tar 

> while the upstream tarball is obtained via 

Bug#902817: fail2ban: diff for NMU version 0.10.2-2.1

[Yaroslav Halchenko]

On Sun, 23 Sep 2018, Mattia Rizzolo wrote:

> Control: tags 902817 + patch
> Control: tags 902817 + pending

> Dear maintainer,

> I've prepared an NMU for fail2ban (versioned as 0.10.2-2.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

I guess if tests pass, should be ok and no need to delay

Thank you!
> Regards.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 24 Sep 2018, Andreas Tille wrote:

> When you talked about new upstream version:  Do you want to give 0.20rc1

I did give it a try...

From the now empty list of
https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it
might be that all of the ones I've filed are addressed by now, BUT I do not see
them in

$> git lg 0.20rc1..origin/0.20.X   
* c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) 
[Joel Nothman]
* 17f8016c5 - Bugfix release of joblib that also restores PyPy support (#12012) 
(3 weeks ago) [Olivier Grisel]
* c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel 
Nothman]
* 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman]
* 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) [Joel 
Nothman]
* 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel 
Nothman]

so might have been fixed in master, and not backported yet, which indeed
might be the case:
https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493

> a try or do you want to wait for 0.20?

regarding push to salsa:

something is funky with salsa or with my network?

(git)hopa:~deb/scikit-learn[debian-0.20]
$> git remote add salsa g...@salsa.debian.org:science-team/scikit-learn.git

$> git fetch salsa
ssh: connect to host salsa.debian.org port 22: Network is unreachable
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Meanwhile, debian-0.20 branch is on
http://github.com/yarikoptic/scikit-learn




-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 10 Sep 2018, Andreas Tille wrote:

> On Mon, Sep 10, 2018 at 10:54:02AM -0400, Yaroslav Halchenko wrote:
> > Outstanding few issues so far are reported/dealt with upstream:
> > https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker
> > updating packaging is in debian-0.20 branch at 
> > http://github.com/yarikoptic/scikit-learn

> ... sorry to repeat myself but having team maintained packages on
> github is not inviting to others.  Is there any reason not to
> use Salsa?

yeap, let's make a repo on salsa.  Would you be ok to retain my weird
"based on upstream git" setup?

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#907806: How to disable tests for Python2 only?

[Yaroslav Halchenko]

On Mon, 10 Sep 2018, Andrey Rahmatullin wrote:

> On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote:
> > Hi,

> > looking at the bug log of scikit-learn[1] it seems to be a simple means to 
> > do

> > --- a/debian/control
> > +++ b/debian/control
> > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf,
> > python3-pytest,
> > python3-matplotlib,
> > python3-joblib (>= 0.9.2),
> > +   python3-distributed ,
> > libsvm-dev (>= 2.84.0),
> > libatlas3-base,
> >  Build-Depends-Indep:
> I don't think that's how build profiles work.


> > However, it seems that due to the fact that this package uses
> > --buildsystem=python_distutils 
> Which is already a problem, as it doesn't support py3.
> There is a lot of strange hacks in this rules file. I'm especially
> interested in "dh_autoreconf debian/rules -- clean_generated" but that's a
> question for another discussion.

many hacks might be left overs for historical (age of the package)
+ backports (hence cythonize rule, allows to provide backports for older
debian/ubuntu via neurodebian) reason.  Would be nice to review/remove
those no longer needed, but attention should be taken care not to break
backportability. So far built/tested fine even for jessie (8) and ubuntu
xenial (16.04).

> > Are there any other ways to exclude some tests for Python2 to make this
> > package build again?
> rules call nosetests directly so I guess find out how to do that with
> nosetests.

overall, as I've just noted in the bugreport, I think it is better to
concentrate on making upcoming 0.20 (will use pytest not nose among
other things) into debian.  

Outstanding few issues so far are reported/dealt with upstream:
https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker
updating packaging is in debian-0.20 branch at 
http://github.com/yarikoptic/scikit-learn

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#907806: scikit-learn: FTBFS in buster/sid (could not import 'distributed')

[Yaroslav Halchenko]

FWIW - waiting on upstream to fixup issues I've reported leading to
FTBFS of 0.20rc:
https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker
when done, will upload the 0.20 to address this one 

On Sun, 02 Sep 2018, Santiago Vila wrote:

> Package: src:scikit-learn
> Version: 0.19.2-1
> Severity: serious
> Tags: ftbfs

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#904359: pending

[Yaroslav Halchenko]

Tags +pending

Sorry I caused us duplicate work.  for a minor slip it wasn't uploaded
to debian proper, I will build (now) and upload tomorrow morning

cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#903213: datalad: FTBFS in stretch/buster/sid

[Yaroslav Halchenko]

Should be fixable, concerns only testing

On July 8, 2018 9:02:07 AM EDT, Sean Whitton  wrote:
>Hello Santiago,
>
>On Sat, Jul 07 2018, Santiago Vila wrote:
>
>> This is just how the build ends in my autobuilder with
>dpkg-buildpackage -A,
>> but there are full build logs available here:
>>
>>
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/datalad.html
>>
>> A diff between the previous successful build log and this (failed)
>one
>> yields this result:
>>
>> -Get:63 http://deb.debian.org/debian-security stretch/updates/main
>amd64 git-annex amd64 6.20170101-1+deb9u1 [10.9 MB]
>> +Get:63 http://deb.debian.org/debian stretch-proposed-updates/main
>amd64 git-annex amd64 6.20170101-1+deb9u2 [10.9 MB]
>>
>> so it seems git-annex now behaves in a way which breaks the tests.
>>
>> (X-Debian-CC to Sean Whitton, who did the proposed-updates upload, in
>case he has any hint
>> about the reason for this FTBFS in datalad).
>
>I suspect that datalad uses some of the git-annex functionality that
>was
>disabled by the security update I uploaded to proposed-updates.  I
>don't
>know whether this is fixable or effectively means that datalad must be
>removed from stretch.

-- 
Sent from a phone which beats iPhone.

Bug#903213: datalad: FTBFS in stretch/buster/sid

[Yaroslav Halchenko]

I bet it is the security fix which was recently introduced... Would need a 
patch to datalad from https://github.com/datalad/datalad/pull/2670 
Hopefully still easy to apply since datalad moved way far ahead since 0.4 .  
For buster/sid we will just release fresh version soon which would be 
compatible, so no need to patch there

On July 7, 2018 2:42:12 PM EDT, Santiago Vila  wrote:
>Package: src:datalad
>Version: 0.4.1-1
>Severity: serious
>Tags: ftbfs
>
>Dear maintainer:
>
>I tried to build this package in stretch + security +
>stretch-proposed-updates
>but it failed:
>
>
>[...]
> debian/rules build-indep
>dh build-indep --with python2 --buildsystem=pybuild
>   dh_testdir -i -O--buildsystem=pybuild
>   dh_update_autotools_config -i -O--buildsystem=pybuild
>   dh_auto_configure -i -O--buildsystem=pybuild
>   pybuild --configure --test-nose -i python{version} -p 2.7
>I: pybuild base:184: python2.7 setup.py config 
>running config
>   dh_auto_build -i -O--buildsystem=pybuild
>   pybuild --build --test-nose -i python{version} -p 2.7
>I: pybuild base:184: /usr/bin/python setup.py build 
>running build
>running build_py
>creating /<>/.pybuild/pythonX.Y_2.7/build/datalad
>
>[... snipped ...]
>
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/support/tests/test_annexrepo.py",
>line 247, in test_AnnexRepo_is_under_annex
>  assert_equal(ar.is_under_annex(testfiles, batch=batch), target_value)
>AssertionError: Lists differ: [False, False, False] != [True, False,
>False]
>
>First differing element 0:
>False
>True
>
>- [False, False, False]
>+ [True, False, False]
>
>==
>FAIL: datalad.support.tests.test_gitrepo.test_GitRepo_get_toppath
>--
>Traceback (most recent call last):
>File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
>runTest
>self.test(*self.arg)
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/tests/utils.py",
>line 706, in newfunc
>t(*(arg + (uri,)), **kw)
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/tests/utils.py",
>line 536, in newfunc
>return t(*(arg + (filename,)), **kw)
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/support/tests/test_gitrepo.py",
>line 637, in test_GitRepo_get_toppath
>eq_(GitRepo.get_toppath(repo, follow_up=False), reporeal)
>AssertionError: '/tmp/datalad_temp_testrepo_bh4Q3X' !=
>'/tmp/datalad_temp_testrepo_bh4Q3X/sub dataset1/subm 1'
>
>==
>FAIL: datalad.support.tests.test_gitrepo.test_submodule_deinit
>--
>Traceback (most recent call last):
>File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
>runTest
>self.test(*self.arg)
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/tests/utils.py",
>line 706, in newfunc
>t(*(arg + (uri,)), **kw)
>File
>"/<>/.pybuild/pythonX.Y_2.7/build/datalad/support/tests/test_gitrepo.py",
>line 840, in test_submodule_deinit
> eq_(['subm 1', 'subm 2'], [s.name for s in top_repo.get_submodules()])
>AssertionError: ['subm 1', 'subm 2'] != []
>
>--
>Ran 616 tests in 167.088s
>
>FAILED (SKIP=65, errors=63, failures=15)
>E: pybuild pybuild:283: test: plugin distutils failed with: exit
>code=1: cd /<>/.pybuild/pythonX.Y_2.7/build; python2.7 -m
>nose -s -v datalad
>dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7
>--test-nose returned exit code 13
>debian/rules:27: recipe for target 'override_dh_auto_test' failed
>make[1]: *** [override_dh_auto_test] Error 25
>make[1]: Leaving directory '/<>'
>debian/rules:19: recipe for target 'build-indep' failed
>make: *** [build-indep] Error 2
>dpkg-buildpackage: error: debian/rules build-indep gave error exit
>status 2
>
>
>This is just how the build ends in my autobuilder with
>dpkg-buildpackage -A,
>but there are full build logs available here:
>
>https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/datalad.html
>
>A diff between the previous successful build log and this (failed) one
>yields this result:
>
>-Get:63 http://deb.debian.org/debian-security stretch/updates/main
>amd64 git-annex amd64 6.20170101-1+deb9u1 [10.9 MB]
>+Get:63 http://deb.debian.org/debian stretch-proposed-updates/main
>amd64 git-annex amd64 6.20170101-1+deb9u2 [10.9 MB]
>
>so it seems git-annex now behaves in a way which breaks the tests.
>
>(X-Debian-CC to Sean Whitton, who did the proposed-updates upload, in
>case he has any hint
>about the reason for this FTBFS in datalad).
>
>Thanks.

-- 
Sent from a phone which beats iPhone.

Bug#901377: ping (was: Re: skimage: FTBFS and Debci failure with NumPy 1.14)

[Yaroslav Halchenko]

FWIW -- about to upload, cosmetics now

On Mon, 25 Jun 2018, Graham Inggs wrote:

> On 25 June 2018 at 18:21, Yaroslav Halchenko  wrote:
> > I am loosely involved and highly interested ;-)  If someone could help
> > maintaining it, I would appreciate.

> > meanwhile since there were no other activity regarding this issue, I
> > will look into updating it for 0.14.0

> In case you didn't receive Lumin's earlier reply:

> On 25 June 2018 at 13:45, Lumin  wrote:
> > I'm working on this. It would take days for me to finish it
> > due to my final terms... But I think it doesn't matter because
> > we still have a month until AUTORM.

> > https://salsa.debian.org/lumin-guest/skimage/commits/master


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#901377: ping (was: Re: skimage: FTBFS and Debci failure with NumPy 1.14)

[Yaroslav Halchenko]

On Mon, 25 Jun 2018, Graham Inggs wrote:

> On 25 June 2018 at 18:21, Yaroslav Halchenko  wrote:
> > I am loosely involved and highly interested ;-)  If someone could help
> > maintaining it, I would appreciate.

> > meanwhile since there were no other activity regarding this issue, I
> > will look into updating it for 0.14.0

> In case you didn't receive Lumin's earlier reply:

> On 25 June 2018 at 13:45, Lumin  wrote:
> > I'm working on this. It would take days for me to finish it
> > due to my final terms... But I think it doesn't matter because
> > we still have a month until AUTORM.

> > https://salsa.debian.org/lumin-guest/skimage/commits/master

oops -- missed it somehow... (travel... still digging through emails),
hopefully we didn't duplicate much of effort.  I'm building a sample
package ATM, here is the changelog summary of what I've done:

skimage (0.14.0-1) unstable; urgency=medium

  * Fresh upstream release
- should resolve FTBFS due to incompatibility with NumPy 1.14
  (Closes #901377)
  * d/patches
- refreshed patches skipping on some archs.  Use testing.skipif instead
  of explicit import of skipif into the namespace
- remove_deprecated_box-forced.patch - removed since was CPed from
  upstream

 -- Yaroslav Halchenko   Mon, 25 Jun 2018 12:26:51 -0400


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#901377: ping (was: Re: skimage: FTBFS and Debci failure with NumPy 1.14)

[Yaroslav Halchenko]

On Sat, 23 Jun 2018, Graham Inggs wrote:

> Hi Stefan, Yaroslav

> On 22 June 2018 at 21:15, Stefan van der Walt  wrote:
> > That sounds like a good solution to me.  That said, scikit-image in
> > Debian is now maintained by the science team, so it would be good to
> > hear from a member of that team.

> Lumin is a member of Debian Science Team.  :)

> According to Science Team's policy [1],

> "The Maintainer field should be "Debian Science Maintainers
> ".
> You should also add yourself to the Uploaders field. Doing so shows
> your involvement and interest in the package. Developers listed in
> Uploaders will take care of maintenance, bug reports and other QA
> work, helped by the Debian Science team."

> You are listed as one of Uploaders for skimage.  If you, for whatever
> reason, are no longer involved or interested in the skimage package,
> then we need to update the Uploaders field to reflect reality.  Should
> your name be removed from Uploaders with the next upload?

> Yaroslav, are you still involved or interested in skimage?

Sorry for the delay.

I am loosely involved and highly interested ;-)  If someone could help
maintaining it, I would appreciate.

meanwhile since there were no other activity regarding this issue, I
will look into updating it for 0.14.0

Cheers
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#902302: connectome-workbench FTBFS on armel/armhf: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'

[Yaroslav Halchenko]

Thank you Adrian

Yes, we will proceed the RM way, will deal with it tomorrow

Cheers

On June 24, 2018 2:30:35 PM EDT, Adrian Bunk  wrote:
>Source: connectome-workbench
>Version: 1.3.1-1
>Severity: serious
>
>https://buildd.debian.org/status/package.php?p=connectome-workbench=sid
>
>...
>In file included from
>/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105:0,
>   from /usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/qgl.h:45,
>from /usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/QGLWidget:1,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/../../src/GuiQt/BrainOpenGLWidget.h:38,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/moc_BrainOpenGLWidget.cpp:9:
>/usr/include/GLES3/gl32.h:77:25: error: conflicting declaration
>'typedef khronos_ssize_t GLsizeiptr'
> typedef khronos_ssize_t GLsizeiptr;
> ^~
>In file included from /usr/include/GL/gl.h:2055:0,
>from /<>/src/Graphics/CaretOpenGLInclude.h:63,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/../../src/GuiQt/BrainOpenGLWidget.h:33,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/moc_BrainOpenGLWidget.cpp:9:
>/usr/include/GL/glext.h:468:19: note: previous declaration as 'typedef
>ptrdiff_t GLsizeiptr'
> typedef ptrdiff_t GLsizeiptr;
>   ^~
>In file included from
>/usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105:0,
>   from /usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/qgl.h:45,
>from /usr/include/arm-linux-gnueabihf/qt5/QtOpenGL/QGLWidget:1,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/../../src/GuiQt/BrainOpenGLWidget.h:38,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/moc_BrainOpenGLWidget.cpp:9:
>/usr/include/GLES3/gl32.h:78:26: error: conflicting declaration
>'typedef khronos_intptr_t GLintptr'
> typedef khronos_intptr_t GLintptr;
>  ^~~~
>In file included from /usr/include/GL/gl.h:2055:0,
>from /<>/src/Graphics/CaretOpenGLInclude.h:63,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/../../src/GuiQt/BrainOpenGLWidget.h:33,
>from
>/<>/obj-arm-linux-gnueabihf/GuiQt/moc_BrainOpenGLWidget.cpp:9:
>/usr/include/GL/glext.h:469:19: note: previous declaration as 'typedef
>ptrdiff_t GLintptr'
> typedef ptrdiff_t GLintptr;
>   ^~~~
>GuiQt/CMakeFiles/GuiQt.dir/build.make:1423: recipe for target
>'GuiQt/CMakeFiles/GuiQt.dir/moc_BrainOpenGLWidget.cpp.o' failed
>make[3]: *** [GuiQt/CMakeFiles/GuiQt.dir/moc_BrainOpenGLWidget.cpp.o]
>Error 1
>
>
>The problem is that on armel and armhf Qt in Debian uses
>OpenGL ES instead of full OpenGL.
>
>Ideally, connectome-workbench should be fixed to also work with OpenGL
>ES.
>
>If this is not easily possible, then:
>- change the build dependency from libqt5opengl5-dev
>  to libqt5opengl5-desktop-dev, and
>- submit an RM bug against ftp.debian.org asking for
>  the removal of the old armel+armhf binaries

-- 
Sent from a phone which beats iPhone.

Bug#902258: any docker command triggers an attempt to unlock my GPG key

[Yaroslav Halchenko]

Package: docker.io
Version: 18.03.1+dfsg1-3
Severity: grave

Filing an official report so it doesn't get forgotten (we had some private
correspondence about it).  New behavior was detected while testing new version
in experimental (17.12.1+dfsg-2) and maintains with current one:  running any
docker command (even just docker --help) triggers a dialog to enter my GPG key
password.  I am really not sure why this should be necessary but it is
worrisome that it might result in leakage or unauthorized use of GPG keys,
happen user has it unlocked in the session (gpg-agent etc).

IMHO doker must not ask for unlocking GPG key at all AFAIK, unless may be
some functionality requires signing et.

I've not yet tried to figure out what exactly leads to it.

Cheers,
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docker.io depends on:
ii  adduser 3.117
ii  iptables1.6.2-1
ii  libc6   2.27-2
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  libltdl72.4.6-2
ii  libnspr42:4.18-1
ii  libnss3 2:3.35-2
ii  libseccomp2 2.3.1-2.1
ii  libsystemd0 238-3
ii  lsb-base9.20170808
ii  runc1.0.0~rc4+dfsg1-2
ii  tini0.18.0-1

Versions of packages docker.io recommends:
ii  ca-certificates  20170717
ii  cgroupfs-mount   1.4
ii  git  1:2.17.0-1
ii  xz-utils 5.2.2-1.3

Versions of packages docker.io suggests:
ii  aufs-tools   1:4.9+20170918-1
ii  btrfs-progs  4.15.1-1
ii  debootstrap  1.0.93+nmu2
pn  docker-doc   
pn  rinse
pn  zfs-fuse | zfsutils  

-- debconf-show failed

Bug#895226: FTBFS on amd64 in testing/unstable - a number of tests failures

[Yaroslav Halchenko]

Package: python-cffi
Version: 1.11.5-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

testing/cffi0/test_verify.py ..s [ 35%]
 [ 39%]
.s...s..F.   [ 41%]
testing/cffi0/test_verify2.py ..s... [ 43%]
 [ 47%]
..s...s..F.  [ 50%]
...
and so on
here you could find the full build log:
http://neuro.debian.net/_files/_buildlogs/python-cffi/1.9.1/python-cffi_1.9.1-2~nd+1_amd64.build


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-cffi depends on:
ii  python   2.7.14-4
ii  python-cffi-backend  1.11.5-1
ii  python-pycparser 2.18-2

python-cffi recommends no packages.

Versions of packages python-cffi suggests:
ii  python-dev  2.7.14-4

-- no debconf information

Bug#894526: Taking over scikit-learn into Debian Science team maintenance

[Yaroslav Halchenko]

meanwhile may be let me just take care about this tiny issue myself

On Sun, 08 Apr 2018, Yaroslav Halchenko wrote:

> Ok. Go ahead. Thanks.
>  But indeed please keep it in a shape so it could be easily backported.

> On April 8, 2018 1:59:53 AM EDT, Andreas Tille <andr...@fam-tille.de> wrote:
> >Hi Yaroslav and Michael,

> >as I did in the past with other scientific packages I would like to
> >take
> >over scikit-learn into Debian Science team maintenance to fix bug
> >#894526.  As I understood you in those cases you are OK with this as
> >long as backportability is given.

> >Please let me know until tomorrow if you do not like it.

> >Kind regards

> >   Andreas.



-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#894526: Taking over scikit-learn into Debian Science team maintenance

[Yaroslav Halchenko]

Ok. Go ahead. Thanks.
 But indeed please keep it in a shape so it could be easily backported.

On April 8, 2018 1:59:53 AM EDT, Andreas Tille  wrote:
>Hi Yaroslav and Michael,
>
>as I did in the past with other scientific packages I would like to
>take
>over scikit-learn into Debian Science team maintenance to fix bug
>#894526.  As I understood you in those cases you are OK with this as
>long as backportability is given.
>
>Please let me know until tomorrow if you do not like it.
>
>Kind regards
>
>   Andreas.

Bug#866433: impressive: diff for NMU version 0.11.2-1.1

[Yaroslav Halchenko]

Feel welcome to upload without delays

On February 3, 2018 7:47:15 AM EST, Adrian Bunk  wrote:
>Control: tags 866433 + patch
>Control: tags 866433 + pending
>
>Dear maintainer,
>
>I've prepared an NMU for impressive (versioned as 0.11.2-1.1) and 
>uploaded it to DELAYED/15. Please feel free to tell me if I should 
>cancel it.
>
>cu
>Adrian

-- 
Sent from a phone which beats iPhone.

Bug#880793: closed by Yaroslav Halchenko <deb...@onerussian.com> (Bug#880793: fixed in pymvpa2 2.6.4-1)

[Yaroslav Halchenko]

On Tue, 30 Jan 2018, Yaroslav Halchenko wrote:


> On Tue, 30 Jan 2018, Adrian Bunk wrote:

> > Control: reopen -1

> > On Tue, Jan 30, 2018 at 03:39:04AM +, Debian Bug Tracking System wrote:
> > >...
> > >  pymvpa2 (2.6.4-1) unstable; urgency=medium
> > >...
> > >* debian/rules
> > >  - run tests under fixed MVPA_SEED=1 to avoid surprises, so should
> > >resolve spurious FTBFS (Closes: #880793)
> > >...

> > Unfortunately this didn't fix the problem:
> >   https://buildd.debian.org/status/package.php?p=pymvpa2=sid

> Thanks for spotting it!
> yeah -- I will look "inside"

> Note that for mips64el, previous version included, failures happen on
> aql builder but not on manda:
> https://buildd.debian.org/status/logs.php?pkg=pymvpa2=mips64el
> so it is something relating to available resources on the box.  might be
> that we need to skip the test if resources are tight

FTR, I think it is an issue to be fixed in numpy itself -- that error is caused
by specifying step in np.float dtype, which leads to ValueError instead
of ZeroDivisionError as in the case of regular float:

(sid_mips64el-dchroot)yoh@eller:~/pymvpa2-2.6.4$ python -c 'import numpy as np; 
print(np.arange(-1, -1+0, 0.))'
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: float division by zero

(sid_mips64el-dchroot)yoh@eller:~/pymvpa2-2.6.4$ python -c 'import numpy as np; 
print(np.arange(-1, -1+0, np.float16(0.)))'
-c:1: RuntimeWarning: invalid value encountered in true_divide
Traceback (most recent call last):
  File "", line 1, in 
ValueError: array is too big; `arr.size * arr.dtype.itemsize` is larger than 
the maximum possible size.


on my x64 laptop it is yet another kind of fun with the same version of numpy
1:1.13.3-2 :

$> python -c 'import numpy as np; print(np.arange(-1, -1+0, np.float(0.)))'
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: float division by zero

$> python -c 'import numpy as np; print(np.arange(-1, -1+0, np.float64(0.)))'
-c:1: RuntimeWarning: invalid value encountered in double_scalars
[]

$> python -c 'import numpy as np; print(np.arange(-1, -1+0, np.float32(0.)))'
-c:1: RuntimeWarning: invalid value encountered in true_divide


in current numpy git, unfortunately they release from releaase branches
so hard to say 'version':

pre-removal-numpybook-5689-gbb7b12672

it is a bit more consistent but still varying:

$> PYTHONPATH=. python -c 'import numpy as np; print(np.arange(-1, -1+0, 0.))'
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: float division by zero

$> PYTHONPATH=. python -c 'import numpy as np; print(np.arange(-1, -1+0, 
np.float(0.)))'
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: float division by zero

$> PYTHONPATH=. python -c 'import numpy as np; print(np.arange(-1, -1+0, 
np.float64(0.)))'
-c:1: RuntimeWarning: invalid value encountered in double_scalars
Traceback (most recent call last):
  File "", line 1, in 
ValueError: arange: cannot compute length

$> PYTHONPATH=. python -c 'import numpy as np; print(np.arange(-1, -1+0, 
np.float32(0.)))'
-c:1: RuntimeWarning: invalid value encountered in true_divide
Traceback (most recent call last):
  File "", line 1, in 
ValueError: arange: cannot compute length

asked upstream: https://github.com/numpy/numpy/issues/10496

will fix up pymvpa with my patches tomorrow or so
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#880793: closed by Yaroslav Halchenko <deb...@onerussian.com> (Bug#880793: fixed in pymvpa2 2.6.4-1)

[Yaroslav Halchenko]

On Tue, 30 Jan 2018, Yaroslav Halchenko wrote:


> On Tue, 30 Jan 2018, Adrian Bunk wrote:

> > Control: reopen -1

> > On Tue, Jan 30, 2018 at 03:39:04AM +, Debian Bug Tracking System wrote:
> > >...
> > >  pymvpa2 (2.6.4-1) unstable; urgency=medium
> > >...
> > >* debian/rules
> > >  - run tests under fixed MVPA_SEED=1 to avoid surprises, so should
> > >resolve spurious FTBFS (Closes: #880793)
> > >...

> > Unfortunately this didn't fix the problem:
> >   https://buildd.debian.org/status/package.php?p=pymvpa2=sid

> Thanks for spotting it!
> yeah -- I will look "inside"

> Note that for mips64el, previous version included, failures happen on
> aql builder but not on manda:
> https://buildd.debian.org/status/logs.php?pkg=pymvpa2=mips64el
> so it is something relating to available resources on the box.  might be
> that we need to skip the test if resources are tight

ah -- and I was chasing the same issue today on conda builds with newer
numpy, it was giving me a different exception though.  I might just
adopt the same patches I did for conda.  Should resolve without me
digging in (unless I could reproduce since I am still intrigued what is
the actual reason)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


signature.asc
Description: PGP signature

Bug#880793: closed by Yaroslav Halchenko <deb...@onerussian.com> (Bug#880793: fixed in pymvpa2 2.6.4-1)

[Yaroslav Halchenko]

On Tue, 30 Jan 2018, Adrian Bunk wrote:

> Control: reopen -1

> On Tue, Jan 30, 2018 at 03:39:04AM +, Debian Bug Tracking System wrote:
> >...
> >  pymvpa2 (2.6.4-1) unstable; urgency=medium
> >...
> >* debian/rules
> >  - run tests under fixed MVPA_SEED=1 to avoid surprises, so should
> >resolve spurious FTBFS (Closes: #880793)
> >...

> Unfortunately this didn't fix the problem:
>   https://buildd.debian.org/status/package.php?p=pymvpa2=sid

Thanks for spotting it!
yeah -- I will look "inside"

Note that for mips64el, previous version included, failures happen on
aql builder but not on manda:
https://buildd.debian.org/status/logs.php?pkg=pymvpa2=mips64el
so it is something relating to available resources on the box.  might be
that we need to skip the test if resources are tight

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#867550: libgiftiio-dev: This package should have a strong dependance on libnifti-dev

[Yaroslav Halchenko]

severity 867550 normal
thanks

On Fri, 07 Jul 2017, Manonam wrote:

> Package: libgiftiio-dev
> Version: 1.0.9-1+b2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)

Sorry for a delayed reply.  As far as I see

- it builds fine for me in a clean pbuilder env
- and it indeed built fine in the past across all platforms

So I am lowering severity to Normal to get it migrate again into
testing, since there is no other proof that it actually fails to build
(even in your original report there was no indication of that)

> This package should have a strong dependance on libnifti-dev, as the
> gifti_io.h:6:23: includes  nifti1_io.h. 

Thanks -- I will address in -2 (upload after migrates to testing)
and close this issue with that

> Furthermore there are missing
> library symbolic links in /usr/lib/libniftiio.so and /usr/lib/libznz.so

I think, that it is due to the fact that it is still .0.0.0 kind state
-- no heavy promises could be made on compatibility, so I will leave it
as is for now

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#866458: Please update Git repository mentioned in VCS fields

[Yaroslav Halchenko]

On Sat, 20 Jan 2018, Andreas Tille wrote:



> Could you please bring the Git repository in sync to enable me to make
> a proper team upload instead of putting the work to inject a NMU into
> the repository for something that is so simple that if it would be less
> work if you do it yourself.

our bad

moszumanska:~
*$> cat /srv/git.debian.org/git/pkg-exppsy/pydicom.git/HEAD 
ref: refs/heads/debian-release

$> echo 'ref: refs/heads/debian' >| 
/srv/git.debian.org/git/pkg-exppsy/pydicom.git/HEAD


try now ;)
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#866446: Where is an up to date Git for openpyxl (Was: What branch of the git repository is featuring the latest packaging)

[Yaroslav Halchenko]

Regarding the original report:

$> grep python-pil debian/control 
   python-pytest, python-pil | python-imaging,
Recommends: python-pytest, python-pil, python-imaging

so the only "harm" here is a possible recommends of python-imaging.
IMHO severity is exaggerated.

Anyways, I will remove now python-imaging "linkage" altogether since it
seems from http://neuro.debian.net/pkgs/python-openpyxl.html that we build
recent openpyxl only on the systems which already have python-pil, so backports
shouldn't be harmed at this point.

On Thu, 11 Jan 2018, Andreas Tille wrote:

> I assume your aggrement if I do not hear from you in the next 24h hours
> for the following action:

> If you do not uncover the real Vcs where openpyxl is actively maintained
> I'll create a fresh Git repository using

> gbp import-dscs --debsnap --pristine-tar openpyxl

> move the package to Debian Science team on salsa while fixing the bug.
> I'd prefer to move the active Git repository over one via import-dscs,
> thought.

I am quite confused here

1.  
(git)hopa:~exppsy/openpyxl[debian]
$> grep Maintainer debian/control
Maintainer: NeuroDebian Team 

so it is not under Debian Science team maintenance... you are officially
stating that you will hijack the package if we do not reply in 24h?

not nice IMHO... BUT I would appreciate if you do ;)  the package is of general
interest etc,  with only one IF:  do not drop Python 2 support until it is a
very strong mandate that we MUST not support python 2.

Let me know if you would like to do that, then I will leave the removal
of python-imaging for you

2. 
hopa:/tmp
$> debcheckout python-openpyxl
declared git repository at git://git.debian.org/git/pkg-exppsy/openpyxl.git
git clone git://git.debian.org/git/pkg-exppsy/openpyxl.git python-openpyxl ...
Cloning into 'python-openpyxl'...
remote: Counting objects: 42053, done.
remote: Compressing objects: 100% (10826/10826), done.
remote: Total 42053 (delta 32119), reused 40869 (delta 30949)
Receiving objects: 100% (42053/42053), 29.34 MiB | 133.00 KiB/s, done.
Resolving deltas: 100% (32119/32119), done.
repository only contains the debian directory, using apt-get source
Reading package lists... Done
NOTICE: 'openpyxl' packaging is maintained in the 'Git' version control system 
at:
git://git.debian.org/git/pkg-exppsy/openpyxl.git
Please use:
git clone git://git.debian.org/git/pkg-exppsy/openpyxl.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 6,585 kB of source archives.
Get:1 http://cdn-fastly.deb.debian.org/debian stretch/main openpyxl 2.3.0-3 
(dsc) [2,323 B]
Get:2 http://cdn-fastly.deb.debian.org/debian stretch/main openpyxl 2.3.0-3 
(tar) [6,577 kB]
Get:3 http://cdn-fastly.deb.debian.org/debian stretch/main openpyxl 2.3.0-3 
(diff) [5,872 B]
Fetched 6,585 kB in 3s (2,290 kB/s)  
dpkg-source: info: extracting openpyxl in openpyxl-2.3.0
dpkg-source: info: unpacking openpyxl_2.3.0.orig.tar.bz2
dpkg-source: info: unpacking openpyxl_2.3.0-3.debian.tar.xz
dpkg-source: info: applying up_no_lxml
dpkg-source: info: applying deb_no_et_xml_file
dpkg-source: info: applying up_python3_print
debcheckout python-openpyxl  4.80s user 0.95s system 2% cpu 3:56.76 total

$> cd python-openpyxl/
AUTHORS.rst  LICENCE.rst  MANIFEST.in  README.rst  debian/  doc/  openpyxl/  
pytest.ini  requirements.txt  setup.cfg  setup.py*  shippable.yml  tox.ini

(git)hopa:/tmp/python-openpyxl[debian]
$> git describe
debian/2.3.0-3

$> apt-cache policy python-openpyxl
python-openpyxl:
  Installed: 2.3.0-3
  Candidate: 2.3.0-3
  Version table:
 *** 2.3.0-3 600
100 http://http.debian.net/debian stretch/main amd64 Packages
100 http://http.debian.net/debian stretch/main i386 Packages
600 http://http.debian.net/debian sid/main amd64 Packages
600 http://http.debian.net/debian sid/main i386 Packages

So we are all up to date and have full packaging available.
So, are you confused by the debian branch?
Or an overlay mechanism of gbp?

$> grep overlay debian/gbp.conf
overlay = True

?

we indeed missed the prestine-tar though.


-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#853492: libgdf: ftbfs with GCC-7

[Yaroslav Halchenko]

Thanks!

On Mon, 18 Dec 2017, Juhani Numminen wrote:

> Control: tags -1 + patch

> This patch removes -Werror to resolve this FTBFS. Removing the deprecated
> exception specifications is another option but I didn't feel like editing
> the public headers of the library.
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#883466: singularity-container: FTBFS on mips*

[Yaroslav Halchenko]

Thanks -- I have submitted them for upstream review/feedback
https://github.com/singularityware/singularity/pull/1195

On Mon, 04 Dec 2017, James Cowgill wrote:

> Source: singularity-container
> Version: 2.4-1
> Severity: serious
> Tags: sid buster patch

> Hi,

> singularity-container FTBFS on mips* with the error:
> > In file included from mnt.c:41:0:
> > ../../../../../src/util/setns.h:46:4: error: #error Please determine the 
> > syscall number for setns on your architecture
> >  #  error Please determine the syscall number for setns on your architecture
> > ^

> This error happens because the setns.h header requires a __NR_setns
> define for each architecture. However, this define is never used in the
> case where glibc provides a setns function (as is the case for all
> architectures in buster).

> The attached "setns-syscall-nr.patch" patch fixes this by moving the
> __NR_setns ifdefs into setns.c so it is only used in the case where
> setns is not provided by libc.

> After doing this, the package FTBFS again in a different way:
> > util/signal.c:39:5: error: 'SIGSTKFLT' undeclared here (not in a function); 
> > did you mean 'SIGSTKSZ'?
> >  SIGSTKFLT,
> >  ^
> >  SIGSTKSZ

> The SIGSTKFLT signal is not defined on mips (and a few other
> architectures). This is fixed by the "maybe-sigstkflt.patch" patch which
> only adds this signal to the all_signals list if it is defined.

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#877344: [Debian-med-packaging] Bug#877344: Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

[Yaroslav Halchenko]

On Mon, 04 Dec 2017, Alexandre Gramfort wrote:

>oh mayavi
>I would really be in favor of removing mayavi as a hard dependency.
>is it an option?

well, it is not a hard dependency already... I just hate when
users keep reporting all those and then I need to react.  Prefer not to
upload if an issue is known thus having as many dependencies installed
during tests as I could "afford"

anyways -- only one left segfaulting (situation improved after I
realized that you switched to use py.test instead of nosetests),
for now will just disable that test... fighting other minor things ATM
;)

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#877344: [Debian-med-packaging] Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

[Yaroslav Halchenko]

On Mon, 04 Dec 2017, Alexandre Gramfort wrote:

>Hi Andreas,
>I don't have the bandwidth to address this sorry.
>Also mne 0.13 is now 2 versions behind where we are now.
>Nobody found the time to do the debian packaging for 0.14
>and 0.15 so far.
>Really sorry about this.

if only life was easy and fair ;)

...
/usr/lib/python2.7/dist-packages/mayavi/core/source.py:209: DeprecationWarning: 
use "HasTraits.trait_set" instead
  obj.set(scene=self.scene, parent=self)
/usr/lib/python2.7/dist-packages/mayavi/core/module_manager.py:260: 
DeprecationWarning: use "HasTraits.trait_set" instead
  obj.set(module_manager=self, scene=self.scene, parent=self)
/usr/lib/python2.7/dist-packages/mayavi/tools/pipe_base.py:157: 
DeprecationWarning: use "HasTraits.trait_get" instead
  traits = self.get(self.class_trait_names())
/usr/lib/python2.7/dist-packages/mayavi/tools/pipe_base.py:171: 
DeprecationWarning: use "HasTraits.trait_set" instead
  **traits)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:809: 
DeprecationWarning: use "HasTraits.trait_set" instead
  editor_factory = trait.get_editor().set(**item.editor_args)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
/usr/lib/python2.7/dist-packages/traitsui/group.py:793: DeprecationWarning: use 
"HasTraits.trait_set" instead
  orientation = self.orientation ) )
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:809: 
DeprecationWarning: use "HasTraits.trait_set" instead
  editor_factory = trait.get_editor().set(**item.editor_args)
/usr/lib/python2.7/dist-packages/traitsui/qt4/ui_panel.py:833: 
DeprecationWarning: use "HasTraits.trait_set" instead
  ).set(item = item, object_name = item.object )
Segmentation fault (core dumped)
debian/rules:25: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 139

;)
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#877344: [Debian-med-packaging] Bug#877344: python-mne FTBFS: ERROR: Test ICA on raw and epochs

[Yaroslav Halchenko]

I will look into updating it in upcoming days

On December 4, 2017 8:54:28 AM EST, Alexandre Gramfort 
 wrote:
>Hi Andreas,
>
>I don't have the bandwidth to address this sorry.
>
>Also mne 0.13 is now 2 versions behind where we are now.
>Nobody found the time to do the debian packaging for 0.14
>and 0.15 so far.
>
>Really sorry about this.
>
>Best,
>Alex
>
>
>On Sun, Dec 3, 2017 at 6:45 PM, Andreas Tille  wrote:
>
>> Hi,
>>
>> could please somebody care for this bug.  I admit I do not like the
>> pattern that RC bugs in python-mne remain unanswered by any of the
>> uploaders until you get a ping.  I would really love if you make sure
>> to subscribe the package and answer this kind of bugs in a timely
>> manner.
>>
>> Thank you
>>
>>   Andreas.
>>
>> --
>> http://fam-tille.de
>>
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
>> debian-med-packaging
>>