RFS: blockdiag/1.5.3+dfsg-1.1 [RC] Re: Sympy(+sagemath+nipy+~30 more) removal ahead

[Rebecca N. Palmer]

 Forwarded Message 
Subject: intent to NMU #848748: blockdiag FTBFS
Date: Sun, 22 Jan 2017 23:29:24 +
From: Rebecca N. Palmer 
To: 848...@bugs.debian.org

Attached is a proposed NMU fixing this bug (identical to my original
patch other than adding the changelog entry; the olefile issue noted
above was a bug in pillow, which has now been fixed).

As the execnet issue (#840823) now also appears to have a fix,
this will allow blockdiag's ~30 rdeps to stay in stretch.

diff -Nru blockdiag-1.5.3+dfsg/debian/changelog 
blockdiag-1.5.3+dfsg/debian/changelog
--- blockdiag-1.5.3+dfsg/debian/changelog   2016-10-11 02:21:04.0 
+0100
+++ blockdiag-1.5.3+dfsg/debian/changelog   2017-01-22 22:14:34.0 
+
@@ -1,3 +1,10 @@
+blockdiag (1.5.3+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't fail tests on a harmless wand warning. Closes: #848478
+
+ -- Rebecca N. Palmer   Sun, 22 Jan 2017 22:13:59 
+
+
 blockdiag (1.5.3+dfsg-1) unstable; urgency=medium
 
   * New upstream release. Closes: #801314
diff -Nru 
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch 
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch
--- 
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch 
1970-01-01 01:00:00.0 +0100
+++ 
blockdiag-1.5.3+dfsg/debian/patches/848748-exception-ignored-in-Image-del.patch 
2017-01-09 22:32:13.0 +
@@ -0,0 +1,38 @@
+Description: Fix test failure with wand 0.4.1+
+ 
+wand 0.4.1 added an Image.destroy()
+(https://sources.debian.net/src/wand/0.4.4-1/wand/image.py/#L2760) that
+iterates over self.sequence (the frames of an animation) to free their
+memory; this throws an exception on single images (where
+self.sequence=None), but as this is called from __del__, this
+exception is warned about then ignored
+(https://docs.python.org/3/reference/datamodel.html#object.__del__),
+and hence is not an error in normal use.
+
+However, blockdiag tests that use capture_stderr fail on any output
+containing "Traceback", including this warning message.
+
+This patch ignores this message to allow blockdiag to build.
+
+Author: Rebecca Palmer 
+Bug-Debian: https://bugs.debian.org/848748
+Forwarded: no
+
+--- blockdiag-1.5.3+dfsg.orig/src/blockdiag/tests/utils.py
 blockdiag-1.5.3+dfsg/src/blockdiag/tests/utils.py
+@@ -64,7 +64,14 @@ def capture_stderr(func):
+ 
+ func(*args, **kwargs)
+ 
+-if re.search('(ERROR|Traceback)', sys.stderr.getvalue()):
++filtered_stderr=re.sub(r"""Exception ignored in: >
++Traceback \(most recent call last\):
++  File "/usr/lib/python3/dist-packages/wand/resource\.py", line [0-9]+, in 
__del__
++self\.destroy\(\)
++  File "/usr/lib/python3/dist-packages/wand/image\.py", line [0-9]+, in 
destroy
++for i in range\(0, len\(self\.sequence\)\):
++TypeError: object of type 'NoneType' has no 
len\(\)""","",sys.stderr.getvalue())#this is the expected result of freeing a 
single image (as opposed to an animation) in wand 0.4, not a blockdiag bug - 
#848748
++if re.search('(ERROR|Traceback)', filtered_stderr):
+ raise AssertionError('Caught error')
+ finally:
+ if sys.stderr.getvalue():
diff -Nru blockdiag-1.5.3+dfsg/debian/patches/series 
blockdiag-1.5.3+dfsg/debian/patches/series
--- blockdiag-1.5.3+dfsg/debian/patches/series  2016-10-11 01:32:49.0 
+0100
+++ blockdiag-1.5.3+dfsg/debian/patches/series  2017-01-09 21:50:32.0 
+
@@ -1 +1,2 @@
 Fixed-remote-image-resouces.patch
+848748-exception-ignored-in-Image-del.patch

Re: Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr

[Andreas Beckmann]

On 2017-01-22 09:48, Adrian Bunk wrote:
> es.abr was a conffile in the jessie ucto, that needs additional treatment.
> 
> The solution might be using mv_conffile from dpkg-maintscript-helper(1) 
> in a .maintscript to move the conffile to the new name spa.abr and the 
> new package (es.abr is now a symlink), but Andreas should comment on 
> that since he knows this better.

TL;DR: You have an ambitious task before you.

Let me see if I understand what's going on.

Renaming conffiles and changing the owning package at the same time is a
PITA.
You add an extra point by making the old name a symlink to the new one,
owned by the new package

In jessie, everything in /etc/ucto was owned by ucto.
In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata
or libucto2, a m-a:same library package. These come from 2 different
source packages.

Yuck. While putting conffiles in m-a:same packages is allowed, I highly
discourage this. Even if I haven't seen this fail once, yet. I'm just
afraid, someone has to clean up a mess caused by this at some point in
the future. and I'm afraid, I won't keep my fingers out of then :-(

Before we start: Are these really conffiles? Supposed to be modified by
the local admin? Or are these rather data files that are not supposed to
be updated locally? And would better live in /usr/share in that case?

And nearly everything from jessie's /etc/ucto content is now renamed and
a symlink.

Can't you just fork the project? I'd suggest 'hpgb' and then use
/etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new
source packages ...

Oh yeah, it well be a mess. But we will do it right. Including making
dpkg forget about the old conffiles.

Right now, all upgrade attempts from jessie to stretch should always
have failed, so there is no further messed up state inbetween that
should be supported for clean upgrades.

can we move the conffiles from libucto2 to a new package, e.g.
ucto-common (which would be either m-a:foreign or m-a:allowed, but I
always mess up these two, I need to look up what's right?

* Which version introduced the new layout?
* can you give me a list of
  + removed conffiles
  + renamed conffiles (old name, new name, new owning package, whether
they have a compat symlink, did the content change between jessie and sid)

Do you *really* need the compat symlinks?

OK, packaging is in git. Need to check whether I have write permissions
there ...

rough plan:

ucto uses d-m-h move-conffile (but provides no new version, so the old
conffile should "disappear" and dpkg should forget about it.
Maybe it's better to rm_conffile it instead.

uctodata will probably need a Conflicts against ucto (<< current+fixed~)


Andreas

Re: Bug#851806: ITP: libmseed2 -- seed (Standard for the Exchange of Earthquake Data) data records manipulation library

[Andreas Tille]

On Sat, Jan 21, 2017 at 11:46:01PM +0100, Pierre Duperray wrote:
> >I think Ghislain's suggestion geography-dev makes a reasonable match.
> not sure if geophysics/seismology is related to geography in any way...

The general rule is that a task will be created if we have packages
that fit into this task and if somebody (you?) cares about maintaining
the task file (adding the package names and make sure every matching
package is menitoned there).

> Right now, I'm learning git-package and to be honest even if not completely
> noob in git I think I screwed my local git repo because instead of commiting
> in local master
> the change I did, I first imported with `gbp pq import' my already done
> debian/patches.
> after commiting a few change to master I realized my patch-queue/master is
> completely
> unrelated to my master commits. I though I could work around this with an
> interactive
> rebase but I'm not sure where I'm standing now :)
> I will clone back my initial alioth master branch and start from scratch.
> Sorry for the delay, but I really need to learn more indepth gbp.

No problem with the delay.  No idea how to help here but if you have
prcise questions they could be answered here on the list.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de

RE:spyder/3.1.0 in Stretch

[PICCA Frederic-Emmanuel]

Hello Ghislain

> A snapshot release of jedi 0.10 was recently uploaded.


yes :( I hope that it will not break rdepends...

> It has been released yesterday alongside qtpy-1.2.1. Could you sponsor
> its upload, please?

> https://anonscm.debian.org/git/python-modules/packages/python-qtpy.git

no problem, is it possible for you to upload into mentors.
then I will do the job.

> I will take care of qtawesome later today or tomorrow.


Great.

> Not much news on that front yet.


hopefully it will be before the 25th.


Fred

Re: spyder/3.1.0 in Stretch

[Ghislain Vaillant]

On Wed, 2017-01-18 at 18:46 +, Ghislain Vaillant wrote:
> On Wed, 2017-01-18 at 17:00 +, Ghislain Vaillant wrote:
> > On Wed, 2017-01-18 at 16:51 +, PICCA Frederic-Emmanuel wrote:
> > > Hello Ghislain
> > > 
> > > it is ok for the taurus upstream to work with 3.1.0
> > 
> > Great news. Meanwhile, I got the green light from Piotr to prepare a
> > new update for src:python-jedi.
> 
> Ok, this is blocked for now (although I have a working package) because
> the packaging repository is in a bad state currently.

A snapshot release of jedi 0.10 was recently uploaded.


> > > So can you prepare the qtawesome package.
> > 
> > I have yet to hear from Carlos on a specific issue arising with 0.4.x [1].
> > 
> > [1] https://github.com/spyder-ide/qtawesome/issues/64
> > 
> > He promised to look into it today.
> 
> It should be released today, and I'll be ready to package it straight-away.

It has been released yesterday alongside qtpy-1.2.1. Could you sponsor
its upload, please?

https://anonscm.debian.org/git/python-modules/packages/python-qtpy.git

I will take care of qtawesome later today or tomorrow.


> > 
> > > I will prepare the spyder package and I woud like to upload this as soon 
> > > as possible to let them enought time in order to fix taurus.
> > > before the 25th
> > 
> > Hopefully, we can make this work timewise.
> 
> Carlos mentioned that they are planning to release a first bugfix
> release (spyder/3.1.1) in a "couple of days".

Not much news on that front yet.


Cheers,
Ghis

Re: Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr

[Adrian Bunk]

Adding Andreas, the BTS does not Cc the submitter on messages.

On Mon, Jan 16, 2017 at 08:17:03PM +0100, Maarten van Gompel wrote:
> Quoting Andreas Beckmann (2017-01-16 17:24:19)
> > Followup-For: Bug #838112
> > Control: found -1 0.3.1-1
> > Control: affects -1 + ucto
> > 
> > that bug has just reappered:
> > 
> >   Preparing to unpack .../ucto_0.9.5-1_amd64.deb ...
> >   Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ...
> >   dpkg: warning: unable to delete old directory '/etc/ucto': Directory not 
> > empty
> >   Selecting previously unselected package uctodata.
> >   Preparing to unpack .../uctodata_0.3.1-1_all.deb ...
> >   Unpacking uctodata (0.3.1-1) ...
> >   dpkg: error processing archive 
> > /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack):
> >trying to overwrite '/etc/ucto/es.abr', which is also in package ucto 
> > 0.9.5-1
> > 
> > 
> > Andreas
> 
> Hi,
> 
> Thanks for the notification. It seems this bug is a persistent one and I 
> don't really get why it's
> resurfacing; I'm probably missing something so CC'ing the debian-science list
> for help. Ucto 0.9.5 no longer has the
> mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then
> moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 
> (package libucto2 actually),
> states:
> 
> Replaces: ucto (<< 0.5.5-1)
> Breaks: ucto (<< 0.5.5-1)
> 
> Uctodata also states:
> 
> Replaces: ucto (<< 0.9.2-1)
> Breaks: ucto (<< 0.9.2-1
> 
> But as this resurfaced, it's apparently not enough, What am I missing here?

es.abr was a conffile in the jessie ucto, that needs additional treatment.

The solution might be using mv_conffile from dpkg-maintscript-helper(1) 
in a .maintscript to move the conffile to the new name spa.abr and the 
new package (es.abr is now a symlink), but Andreas should comment on 
that since he knows this better.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed