Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Sun, May 5, 2024 at 11:43 PM Jeremy Bícha  wrote:
>
> Control: block -1 by 1061627
>
> I was able to build all the reverse dependencies in Ubuntu 24.04 LTS
> against jpeg-xl from experimental. But jpeg-xl won't be able to
> migrate to Testing until its autopkgtests are fixed.
>
> https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

Finally fixed today. Sorry for the delay.

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Jeremy,

On Wed, Jan 31, 2024 at 10:04 AM Mathieu Malaterre  wrote:
>
> Sebastian,
>
> On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher  
> wrote:
> >
> > Control: tags -1 moreinfo
> >
> > Hi Mathieu
> >
> > On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > >
> > > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.
> >
> > Are the reverse dependencies known to build with the new dcmtk version?
>
> I still do not have access to debomatic-amd64. So I have not tested them yet.

I still do not have access to debomatic-amd64. Would you like to check
the reverse dependencies of dcmtk 3.6.8-3 for the transition to start
?

Thank you

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Sebastian,

On Sun, Jan 21, 2024 at 4:55 PM Sebastian Ramacher  wrote:
>
> Control: tags -1 moreinfo
>
> Hi Mathieu
>
> On 2024-01-13 11:47:40 +0100, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.
>
> Are the reverse dependencies known to build with the new dcmtk version?

I still do not have access to debomatic-amd64. So I have not tested them yet.

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Tue, Oct 17, 2023 at 6:04 PM Sebastian Ramacher  wrote:
>
> Hi Mathieu
>
> On 2023-10-13 16:42:34 +0200, Mathieu Malaterre wrote:
> > On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
> >  wrote:
> > >
> > > Control: tags -1 moreinfo
> > > Control: forwarded -1 
> > > https://release.debian.org/transitions/html/auto-jpeg-xl.html
> > >
> > > On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > >
> > > > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > > > removed.
> > >
> > > Are the reverse dependencies known to build with the new version?
> >
> > Nope. I've requested an account on debomatic-amd64 to run the following:
> >
> > % cat jxl.commands
> > rebuild ffmpeg_7:6.0-7 unstable experimental
> > rebuild geeqie_1:2.1-1 unstable experimental
> > rebuild gimp_2.10.34-1 unstable experimental
> > rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
> > rebuild imlib2_1.12.1-1 unstable experimental
> > rebuild kimageformats_5.107.0-3 unstable experimental
> > rebuild krita_1:5.2.0+dfsg-1 unstable experimental
> > rebuild swayimg_1.12-1 unstable experimental
> > rebuild vips_8.14.5-1 unstable experimental
> > rebuild webkit2gtk_2.42.1-2 unstable experimental
> > rebuild wpewebkit_2.42.1-1 unstable experimental
> >
> >
> > will post back when I get access.
>
> Alright, thanks. Please let us know as soon as you have the results.

Turns out, I cannot connect to debomatic-amd64 online service. Is
there an alternate solution for me to rebuild a large set of packages
automatically ?

Thanks!

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.

Current status in exp:
https://buildd.debian.org/status/package.php?p=dcmtk=experimental

Thanks

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
 wrote:
>
> Control: tags -1 moreinfo
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-jpeg-xl.html
>
> On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > removed.
>
> Are the reverse dependencies known to build with the new version?

Nope. I've requested an account on debomatic-amd64 to run the following:

% cat jxl.commands
rebuild ffmpeg_7:6.0-7 unstable experimental
rebuild geeqie_1:2.1-1 unstable experimental
rebuild gimp_2.10.34-1 unstable experimental
rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
rebuild imlib2_1.12.1-1 unstable experimental
rebuild kimageformats_5.107.0-3 unstable experimental
rebuild krita_1:5.2.0+dfsg-1 unstable experimental
rebuild swayimg_1.12-1 unstable experimental
rebuild vips_8.14.5-1 unstable experimental
rebuild webkit2gtk_2.42.1-2 unstable experimental
rebuild wpewebkit_2.42.1-1 unstable experimental


will post back when I get access.

Thanks !

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This is a minor SONAME transiton. Two (unused anywhere) symbols were
removed.

Current status in exp:
https://buildd.debian.org/status/package.php?p=jpeg-xl=experimental

Thanks

Ben file:

title = "jpeg-xl";
is_affected = .depends ~ "libjxl0.7" | .depends ~ "libjxl0.8";
is_good = .depends ~ "libjxl0.8";
is_bad = .depends ~ "libjxl0.7";

Bug#1053641: transition: libavif

[Mathieu Malaterre]

Hi,


On Sat, Oct 7, 2023 at 9:36 PM Boyuan Yang  wrote:
>
> X-Debbugs-CC: ma...@debian.org
>
> 在 2023-10-07星期六的 20:32 +0200，Sebastian Ramacher写道：
> > Control: tags -1 confirmed
> >
> > On 2023-10-07 14:06:44 -0400, Boyuan Yang wrote:
> > > I am looking at starting the transition for package libavif,
> > > which comes with a SONAME bump
> > > (libavif15, v0.11.1-3 (sid) -> libavif16, v1.0.1-1 (exp)).
> > >
> > > * jpeg-xl (Current version FTBFS unconditionally due to a different reason
> > > in Testing/Sid; my NMU fix just accepted in Sid)
> > >
> > > Do we need to wait till my NMU-ed jpeg-xl to migrate to Testing before
> > > starting the libavif transition?
> >
> > No, that's not necessary. Please go ahead.
>
> Alright, here comes the tricky part.
>
> In the test build of reverse build-dependencies, only amd64 builds are 
> examined.
> Now, the rebuilt jpeg-xl has some new FTBFS on other architectures; and while 
> some
> issues are easy to solve (e.g., missing  header for arm64), some 
> issues are
> not (like the new test failures for i386 and s390x) [1].
>
> Probably I uploaded the libavif/1.0.1-1 to Sid too soon; and while I tried to 
> cancel
> the upload with "dcut rm" and "dcut cancel", these commands never successfully
> intercept the upload ("no such upload found", "no file to delete", etc), and 
> we are
> having the new libavif in Sid now to trigger the transition. This is the worst
> condition we could have, though I consciously tried to avoid it :-(
>
> I am now wondering what would be the best way to get this transition done in 
> a sane
> way. A few choices in my mind:
>
> (1) Make a sloppy upload to jpeg-xl in Sid to ignore post-build testing 
> errors (and
> possibly newly-emerged autopkgtest errors, if any?) so that the libavif 
> transition can
> finish, and count on the upcoming jpeg-xl (0.7 -> 0.8) transition to correct 
> these
> ignored errors;
>
> (2) Fix current jpeg-xl in Sid properly. That won't be too trivial since the 
> new
> testing error is likely triggered by some unclear changes in 
> build-dependencies over
> the past several months.
>
> (3) Wait till a sane jpeg-xl 0.8 upload (with transition) is ready, and 
> entangle
> jpeg-xl transition with libavif transition.

#1051131 has been fixed yesterday. I'll go ahead and do the 0.8 upload
this week.

Thanks,

> It would be great if you have any suggestion, or even better, some good 
> patches
> on it.
>
> Thanks,
> Boyuan Yang
>
>
> [1] https://buildd.debian.org/status/package.php?p=jpeg-xl

Bug#1051384: bookworm-pu: package highway/1.0.3-3

[Mathieu Malaterre]

On Thu, Sep 7, 2023 at 1:23 PM Adam D. Barratt  wrote:
>
> Control: tags -1 + moreinfo
>
> On Thu, 2023-09-07 at 09:11 +0200, Mathieu Malaterre wrote:
> > I'd like to fix highway on armhf (neon-less) system.
> >
> > [ Reason ]
> > See #1033656
> >
>
> +highway (1.0.3-3+deb11u1) bullseye; urgency=medium
>
> Neither the version suffix nor the suite there match up with the
> subject.

I managed to mess up a simple upload...oh well.

Here is the correct debdiff this time.

Thanks


debdiff-bookworkm
Description: Binary data

Bug#1051384: bookworm-pu: package highway/1.0.3-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

I'd like to fix highway on armhf (neon-less) system.

[ Reason ]
See #1033656

[ Impact ]
Only armhf system be affected by the rebuild.

[ Tests ]
Tested on abel.d.o (Thanks Wookey!)

[ Risks ]
Very minimal risk, only compiler flags are changed (on armhf).

[ Checklist ]
  [*] *all* changes are documented in the d/changelog
  [*] I reviewed all changes and I approve them
  [*] attach debdiff against the package in (old)stable
  [*] the issue is verified as fixed in unstable

[ Changes ]
Changed one single cmake option
diff -Nru highway-1.0.3/debian/changelog highway-1.0.3/debian/changelog
--- highway-1.0.3/debian/changelog  2023-02-24 08:52:20.0 +0100
+++ highway-1.0.3/debian/changelog  2023-09-07 09:04:55.0 +0200
@@ -1,3 +1,9 @@
+highway (1.0.3-3+deb11u1) bullseye; urgency=medium
+
+  * d/rules: Fix armhf neon-less system. Closes: #1033656
+
+ -- Mathieu Malaterre   Thu, 07 Sep 2023 09:04:55 +0200
+
 highway (1.0.3-3) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru highway-1.0.3/debian/rules highway-1.0.3/debian/rules
--- highway-1.0.3/debian/rules  2023-02-24 08:51:28.0 +0100
+++ highway-1.0.3/debian/rules  2023-09-07 09:03:41.0 +0200
@@ -18,9 +18,8 @@
 endif
 
 ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH),armhf))
-  # highway implement dynamic dipatch:
-  # https://github.com/google/highway/issues/891
-  CMAKE_EXTRA_FLAGS += -DHWY_CMAKE_ARM7:BOOL=ON
+  # https://github.com/google/highway/issues/1271
+  CMAKE_EXTRA_FLAGS += -DHWY_CMAKE_ARM7:BOOL=OFF
 endif
 
 include /usr/share/dpkg/buildtools.mk

Bug#1025930: transition: openvdb

[Mathieu Malaterre]

> openvdb 10.0 is available in experimental (except mipsel):

openvdb 10.0 is now available in experimental (including mipsel):

https://buildd.debian.org/status/package.php?p=openvdb=experimental

Thanks

Bug#1025930: transition: openvdb

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to request a transition slot for openvdb 10.0.

openvdb 10.0 is available in experimental (except mipsel):

https://buildd.debian.org/status/package.php?p=openvdb=experimental

I've built all reverse dependencies without issues. I'll request the
removal of mipsel binaries.

Thanks

Ben file:

Affected: .depends ~ /\b(libopenvdb10\.0|libopenvdb9\.1)\b/
Good: .depends ~ /\b(libopenvdb10\.0)\b/
Bad: .depends ~ /\b(libopenvdb9\.1)\b/

Bug#1017043: transition: openexr

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to request a transition slot for openexr 3.x transition.
Basically this is an API change as well as a merge of ilmbase into
openexr (previously two packages).

openexr 3.1.5 is available in experimental:

https://buildd.debian.org/status/package.php?p=openexr=experimental

I've build all reverse dependencies without major issues. Package
openexr-viewers will need to be RM since abandonned upstream.

openvdb current status may interfere a bit in the process.

Thanks

Ben file:

title = "openexr";
is_affected = .depends ~ /\b(libopenexr25|openexr\-doc)\b/ | .depends ~ 
/\b(libopenexr\-3\-1\-30|libopenexr\-doc)\b/;
is_good = .depends ~ /\b(libopenexr\-3\-1\-30|libopenexr\-doc)\b/;
is_bad = .depends ~ /\b(libopenexr25|openexr\-doc)\b/;

Re: Bug#953235: vtkplotter: autopkgtest arm64 failure: No module named 'vtkIOFFMPEGPython'

[Mathieu Malaterre]

On Sun, May 10, 2020 at 10:01 PM Paul Gevers  wrote:
>
> Hi Adrian,
>
> On 10-05-2020 15:25, Paul Gevers wrote:
> > I'm running another check on "cannot allocate memory in static TLS
> > block" now, will take a while.
>
> Also for this one, only vtkplotter showed up.

Did you check #951704 ? This affect python3 package using jemalloc.

> Paul
>


-- 
Mathieu

Bug#942496: nmu: libopenvdb5.2_5.2.0-6

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

I messed up the openvdb binary upload on amd64 (build with older libopenexr23)

So please schedule a binNMU:

nmu libopenvdb5.2_5.2.0-6 . amd64  . -m 'Rebuild against libopenexr24
to correct dependency'

Thanks

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Mathieu Malaterre]

Aurélien,

Thanks for caring about 32bits arches !

On Thu, Aug 8, 2019 at 10:39 PM Aurelien Jarno  wrote:
[...]
> mips and mipsel are more affected by the issue as the virtual address
> space is limited to 2GB. Therefore on those architectures, this issue
> recently started to also affect core packages like ghc and rustc, and
> the usual tricks are not working anymore.
[...]

(maybe a bit naive) Another way to look at the issue is that ghc and
rustc are core packages on 32bits system. Would it make sense to start
having a separate core32 & core64 instead of a single one ?

Re: Fwd: Bug#921780: esajpip: FTBFS (LaTeX error)

[Mathieu Malaterre]

Hi Paul,

The usual stuff: real life. In any case I am not using esajpip much
these days. So let's finally kill it. I'll file a RM bug report ASAP.

Thanks

On Mon, Mar 11, 2019 at 7:47 PM Paul Gevers  wrote:
>
> Hi Mathieu,
>
> On 11-03-2019 18:41, Mathieu Malaterre wrote:
> > Could someone please clarify the status of esajpip package. A bug with
> > severity serious was set to the package and the package was
> > 'autoremoved'. Since the serious bug was caused by a build-dep (at
> > some point back in time), do I need to do anything for esajpip to
> > migrate back to testing (921780 is closed) ?
> >
> > Thanks
> >
> > -- Forwarded message -
> > From: Santiago Vila 
> > Date: Mon, Mar 11, 2019 at 6:00 PM
> > Subject: Re: Bug#921780: esajpip: FTBFS (LaTeX error)
> >
> > I would hope so, as this was definitely not the package's fault, but I
> > guess you will have to ask for it explicitly because of the freeze.
>
> Your package was removed from testing because you didn't respond for a
> month to a serious bug against your package. Your package will not
> migrate back to testing before the release of buster unless you can
> convince us why it should be part of the release. If you follow that
> route, please use an unblock bug to communicate about it, and please
> answer the question below in it.
>
> Why didn't you take action on the autoremoval mails that you should have
> received? It would have been so much easier.
>
> Paul
>

Fwd: Bug#921780: esajpip: FTBFS (LaTeX error)

[Mathieu Malaterre]

Dear Debian release team,

Could someone please clarify the status of esajpip package. A bug with
severity serious was set to the package and the package was
'autoremoved'. Since the serious bug was caused by a build-dep (at
some point back in time), do I need to do anything for esajpip to
migrate back to testing (921780 is closed) ?

Thanks

-- Forwarded message -
From: Santiago Vila 
Date: Mon, Mar 11, 2019 at 6:00 PM
Subject: Re: Bug#921780: esajpip: FTBFS (LaTeX error)

I would hope so, as this was definitely not the package's fault, but I
guess you will have to ask for it explicitly because of the freeze.

Bug#914131: transition: openvdb

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to proceed with the transition of openvdb from 5.0 to 5.2 now.
All reverse dependencies are good (blender). This will address #911891.

Current status in exp:
https://buildd.debian.org/status/package.php?p=openvdb=experimental

Ben file:

title = "openvdb";
is_affected = .depends ~ "libopenvdb5.0" | .depends ~ "libopenvdb5.2";
is_good = .depends ~ "libopenvdb5.2";
is_bad = .depends ~ "libopenvdb5.0";


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (900, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 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 /bin/dash
Init: systemd (via /run/systemd/system)

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Adrian,

On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz
 wrote:
[...]
> On the other hand, some packages dropped support for PowerPC32 like Mono
> but this isn't a concern for most users, I would say.
[...]

Thanks very much for stepping up as porter, you have my vote !

However I need to mention that the specific ppc/mono issue is in fact
pretty interesting. The long thread is on debian-powerpc@l.d.o but the
short version is that this issue only happen because we build the
ppc32 mono version on a ppc64 kernel, I know that since I did debug
this issue.

I have not heard from the ppc64el porters, but I suspect ppc64 will
not be a release arch. So you need to take into consideration that for
powerpc to remain a release arch, one need minimal working ppc64 port.
Could we solve the situation of ppc64 for Stretch, could it be moved
to official release arch ?

-M

Re: Porter roll call for Debian Stretch

[Mathieu Malaterre]

Hi all,

On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose  wrote:
> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
>> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>>- powerpc: No porter (RM blocker)
>>
>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
>> maintaining powerpcspe which is very similar to powerpc.
>
> No, you are not maintaining powerpcspe as a release architecture, and that's
> something different than building packages for some of the ports 
> architectures.
> If you can get powerpcspe accepted as a release architecture, then maybe you
> gain some credibility to maintain another release architecture ;)

[Let's assume that we can't find a powerpc porter in time for Stretch.]

1. Will `powperpc` automatically be downgraded to simple port ? Or is
this also not automated and the port may simply be removed (eg. sparc)
?
2. Apart from loosing the automatic debian-installer stuff, what else
are we going to loose in that scenario ?

Thanks much for pointers !

-M

Re: [Stretch] Status for architecture qualification

[Mathieu Malaterre]

Hi Hector,

On Thu, Jun 16, 2016 at 2:12 AM, Hector Oron  wrote:
[...]
> While working out ArchitectureQualification/Stretch wiki page I
> believe everything is mostly fine for release, however I got a
> personal concern on powerpc architecture. Is it well maintained? Does
> it have porters? Does it have users? Does it still make sense to carry
> along?
[...]

The debian-powerpc@l.d.o mailing list is active so I would say it
still has some users. I have been using partch.d.o for doing some work
on PowerPC. I posted a summary of work people have been doing on this
port lately:

https://lists.debian.org/debian-powerpc/2016/06/msg00046.html

However I do agree that true PowerPC hardware is actually
disappearing, and it is alive mostly thanks to being an ABI using
32bits integer for PPC64 CPU(s).

-M

Re: openjpeg / stretch

[Mathieu Malaterre]

On Thu, Jun 2, 2016 at 9:03 AM, Mathieu Malaterre <ma...@debian.org> wrote:
> On Wed, Jun 1, 2016 at 7:10 PM, Emilio Pozuelo Monfort <po...@debian.org> 
> wrote:
>> On 31/05/16 12:00, Mathieu Malaterre wrote:
>>> [adding debian-release]
>>>
>>> Hi,
>>>
>>> On Thu, May 12, 2016 at 12:48 PM, Mathieu Malaterre <ma...@debian.org> 
>>> wrote:
>>>> Hi,
>>>>
>>>> On Thu, May 12, 2016 at 12:16 PM, Moritz Muehlenhoff <j...@debian.org> 
>>>> wrote:
>>>>> Hi,
>>>>> in jessie we have the unfortunate situation of having two copies of
>>>>> openjpeg in the archive src:openjpeg and src:openjpeg2. Can you get
>>>>> rid of openjpeg for stretch? We accept two source packages for transition
>>>>> purposes, but these need to be sorted out by the subsequent release.
>>>>
>>>> That does not seems doable [*]. openjpeg 1.x and openjpeg 2.x have
>>>> different API, and it requires a significant effort to move from one
>>>> API to the other. Without upstream help from each packages, this
>>>> cannot possibly be done (at least by me).
>>>>
>>>> If someone wants to volunteer, some projects have successfully moved
>>>> from openjpeg 1.x to openjpeg 2.x (from the top of my head:
>>>> mupdf/gdal/leptonlib) so some projects may have code so that they
>>>> compile against either openjpeg 1.x or openjpeg 2.x using #idef
>>>> triggered during configuration time.
>>>>
>>>> The other option is to deactivate JPEG 2000 support from those
>>>> packages. imagemagick (accidentally) removed support for JPEG 2000
>>>> (#773530) and no one complained so far.
>>>
>>> Actually the issue is maybe a little more than just a security
>>> concern. See the bug report #825907.
>>
>> Is openjpeg not using versioned symbols?
>
> No (very very few packages are actually using this trick AFAIK).
>
>>> I'll leave it to debian-release to decide the severity of this bug.
>>> Meanwhile I'll track package(s) still using OpenJPEG 1.5.x API.
>>
>> You can do like it is being done for jasper: file bugs with 
>> severity:important
>> against all the rdeps, telling them we want to remove openjpeg from Stretch 
>> for
>> security reasons, and that the bugs will get bumped to RC in some time. Then 
>> we
>> can see how things evolve and what to do next.
>>
>> See
>>
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jasper-rm;users=j...@debian.org
>> https://release.debian.org/transitions/html/jasper-rm.html
>> https://lists.debian.org/debian-release/2016/03/msg6.html
>>
>> How does that sound?
>
> Sound good! Severity: important is not too annoying for packager, but
> clear enough. I'll do that ASAP.

Done:

https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=stretch2000=malat%40debian.org

Re: openjpeg / stretch

[Mathieu Malaterre]

On Wed, Jun 1, 2016 at 7:10 PM, Emilio Pozuelo Monfort <po...@debian.org> wrote:
> On 31/05/16 12:00, Mathieu Malaterre wrote:
>> [adding debian-release]
>>
>> Hi,
>>
>> On Thu, May 12, 2016 at 12:48 PM, Mathieu Malaterre <ma...@debian.org> wrote:
>>> Hi,
>>>
>>> On Thu, May 12, 2016 at 12:16 PM, Moritz Muehlenhoff <j...@debian.org> 
>>> wrote:
>>>> Hi,
>>>> in jessie we have the unfortunate situation of having two copies of
>>>> openjpeg in the archive src:openjpeg and src:openjpeg2. Can you get
>>>> rid of openjpeg for stretch? We accept two source packages for transition
>>>> purposes, but these need to be sorted out by the subsequent release.
>>>
>>> That does not seems doable [*]. openjpeg 1.x and openjpeg 2.x have
>>> different API, and it requires a significant effort to move from one
>>> API to the other. Without upstream help from each packages, this
>>> cannot possibly be done (at least by me).
>>>
>>> If someone wants to volunteer, some projects have successfully moved
>>> from openjpeg 1.x to openjpeg 2.x (from the top of my head:
>>> mupdf/gdal/leptonlib) so some projects may have code so that they
>>> compile against either openjpeg 1.x or openjpeg 2.x using #idef
>>> triggered during configuration time.
>>>
>>> The other option is to deactivate JPEG 2000 support from those
>>> packages. imagemagick (accidentally) removed support for JPEG 2000
>>> (#773530) and no one complained so far.
>>
>> Actually the issue is maybe a little more than just a security
>> concern. See the bug report #825907.
>
> Is openjpeg not using versioned symbols?

No (very very few packages are actually using this trick AFAIK).

>> I'll leave it to debian-release to decide the severity of this bug.
>> Meanwhile I'll track package(s) still using OpenJPEG 1.5.x API.
>
> You can do like it is being done for jasper: file bugs with severity:important
> against all the rdeps, telling them we want to remove openjpeg from Stretch 
> for
> security reasons, and that the bugs will get bumped to RC in some time. Then 
> we
> can see how things evolve and what to do next.
>
> See
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jasper-rm;users=j...@debian.org
> https://release.debian.org/transitions/html/jasper-rm.html
> https://lists.debian.org/debian-release/2016/03/msg6.html
>
> How does that sound?

Sound good! Severity: important is not too annoying for packager, but
clear enough. I'll do that ASAP.

Thanks
-M

Re: openjpeg / stretch

[Mathieu Malaterre]

[adding debian-release]

Hi,

On Thu, May 12, 2016 at 12:48 PM, Mathieu Malaterre <ma...@debian.org> wrote:
> Hi,
>
> On Thu, May 12, 2016 at 12:16 PM, Moritz Muehlenhoff <j...@debian.org> wrote:
>> Hi,
>> in jessie we have the unfortunate situation of having two copies of
>> openjpeg in the archive src:openjpeg and src:openjpeg2. Can you get
>> rid of openjpeg for stretch? We accept two source packages for transition
>> purposes, but these need to be sorted out by the subsequent release.
>
> That does not seems doable [*]. openjpeg 1.x and openjpeg 2.x have
> different API, and it requires a significant effort to move from one
> API to the other. Without upstream help from each packages, this
> cannot possibly be done (at least by me).
>
> If someone wants to volunteer, some projects have successfully moved
> from openjpeg 1.x to openjpeg 2.x (from the top of my head:
> mupdf/gdal/leptonlib) so some projects may have code so that they
> compile against either openjpeg 1.x or openjpeg 2.x using #idef
> triggered during configuration time.
>
> The other option is to deactivate JPEG 2000 support from those
> packages. imagemagick (accidentally) removed support for JPEG 2000
> (#773530) and no one complained so far.

Actually the issue is maybe a little more than just a security
concern. See the bug report #825907.

I'll leave it to debian-release to decide the severity of this bug.
Meanwhile I'll track package(s) still using OpenJPEG 1.5.x API.

-M

Bug#810568: openexr transition

[Mathieu Malaterre]

Control: tags -1 - moreinfo

All packages now do compile with newer openexr. blender is in
experimental, and thus will need a SU at some point.

-M

Bug#810568: transition: openexr

[Mathieu Malaterre]

On Thu, Jan 21, 2016 at 11:00 AM, Matteo F. Vescovi  wrote:
> Hi!
>
> On 2016-01-21 at 09:56 (CET), Emilio Pozuelo Monfort wrote:
>> Do rdeps build fine against the new versions of the libraries?
>
> FTR, better this time (based on rebuilds made last night):
>
> * aqsis_1.8.2-2 => FTBFS

patch is at #812519


> * blender_2.74+dfsg0-5 => FTBFS
> * darktable_2.0.0-1 => OK
> * exactimage_0.9.1-10 => OK
> * exrtools_0.4-1.2 => OK
> * freeimage_3.17.0+ds1-1 => FTBFS

looks good to me:

http://debomatic-amd64.debian.net/distribution#experimental/freeimage/3.17.0+ds1-1/buildlog

I cannot reproduce the issue over here

> * gegl_0.3.4-1 => OK
> * gmic_1.6.8-3 => FTBFS

looks good to me:

http://debomatic-amd64.debian.net/distribution#experimental/gmic/1.6.8-3/buildlog

> * gst-plugins-bad1.0_1.6.2-1 => OK
> * hugin_2015.0.0+dfsg-1 => OK
> * imagemagick_8:6.8.9.9-7 => OK
> * k3d_0.8.0.5-1 => OK
> * kde-runtime_4:15.08.3-1 => OK
> * kimageformats_5.16.0-1 => OK
> * libvigraimpex_1.10.0+dfsg-11 => FTBFS

Well this is an issue within the python test:

AttributeError: 'numpy.ndarray' object has no attribute 'axistags'

This looks like something changed in numpy recently...


> * luminance-hdr_2.4.0-8 => OK
> * mia_2.2.7-3 => OK
> * nvidia-texture-tools_2.0.8-1+dfsg-8 => OK
> * opencv_2.4.9.1+dfsg-1.2 => OK
> * openexr-viewers_1.0.1-6 => OK
> * openimageio_1.5.23~dfsg0-1 => OK
> * openvdb_3.1.0-2 => OK
> * pfstools_2.0.4-5 => OK
> * povray_1:3.7.0.0-8 => OK
> * synfig_1.0.2-1 => OK
> * vips_8.2.1-1 => OK
> * pink-pony_1.4.1-1 => OK
>
> Blender is non-problem, since I'll upload the experimental version to
> unstable/sid contextually to ilmbase/openexr and it's building fine
> against them.
>
> Cheers.
>
> --
> Matteo F. Vescovi || Debian Developer
> GnuPG KeyID: 4096R/0x8062398983B2CF7A

Bug#810568: transition: openexr

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi

I'd like to request a transition for openexr (and ilmbase).

Ben file:

title = "openexr";
is_affected = .depends ~ "libopenexr6v5" | .depends ~ "libopenexr6";
is_good = .depends ~ "libopenexr22";
is_bad = .depends ~ "libopenexr6v5";

Transition slot for ilmbase/openexr

[Mathieu Malaterre]

I'd like to request a transition slot for ilmbase/openexr. Is this a
good time ? Versions in exp are in good shapes.

Thanks

xmlgraphics-common status ?

[Mathieu Malaterre]

[CC me please]

Hi there,

Does anyone understand the following `excuse`:

https://release.debian.org/migration/testing.pl?package=fop

[...]
xmlgraphics-commons is only 0 days old. It must be 5 days old to go in.
[...]

Thanks much,

ilmbase 2.2.0-x upload to sid

[Mathieu Malaterre]

Hi there,

I am planning on uploading ilmbase 2.2.0-x to sid. The only rdepends is
openexr, so it should not impact anyone. This way I'll be able to upload
openexr 2.2.0-1 to experimental since it requires ilmbase = 2.2.0

Thanks

Re: ilmbase 2.2.0-x upload to sid

[Mathieu Malaterre]

On Sun, Jul 5, 2015 at 6:32 PM, Andreas Metzler ametz...@bebt.de wrote:

 On 2015-07-05 Mathieu Malaterre ma...@debian.org wrote:
  I am planning on uploading ilmbase 2.2.0-x to sid. The only rdepends is
  openexr, so it should not impact anyone. This way I'll be able to upload
  openexr 2.2.0-1 to experimental since it requires ilmbase = 2.2.0

 Hello,

 I do not get the reasoning, you can upload openexr 2.2.0-1 to
 experimental now. Packages in experimental may (build-)depend on
  packages in experimental.


The buildd will not do anything since they will pull the package from sid
(AFAIK), making the upload pretty much useless.


 Also ilmbase actually /has/ a number of rdepends apart from openexr:
 ametzler@argenau:~/GIT/writing/hugin$ grep-dctrl -FDepends libilmbase -s \
   Package -n \

 /chroots/sid/var/lib/apt/lists/ftp.de.debian.org_debian_dists_sid_main_binary-i386_Packages
 |\
   par 72
 libaqsis1 blender calligra-libs krita darktable edisplay exactimage
 libexactimage-perl php5-exactimage python-exactimage exrtools
 libfreeimage3 fyre libgegl-0.2-0 gmic gstreamer1.0-plugins-bad
 hugin-tools libilmbase-dev kdelibs5-plugins kimageformat-plugins
 libvigraimpex4 luminance-hdr nip2 libnvtt-bin libnvtt2
 libopencv-highgui2.4 libopenexr-dev libopenexr6 openexr openexr-viewers
 libopenimageio1.5 openimageio-tools libopenvdb-tools libopenvdb3.0
 python-openvdb pfstools pink-pony povray libsynfig0 libvips-tools
 libvips38 python-vipscc

 None of them actually Build-Depends on libilmbase-dev, but instead
libopenexr-dev.

2cts

Bug#786886: /usr/bin/regedit-development/wine32

[Mathieu Malaterre]

I find it odd that the symlink is now: /usr/bin/regedit-development/wine32

why not: /usr/lib/wine-development/wine32 ?

Thanks for comments.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxzBVR+iY1PDPW0oRO5q7zfWE5q3KEx=ql6pgvb_-p...@mail.gmail.com

Bug#775516: unblock: uncrustify/0.59+dfsg1-1.1

[Mathieu Malaterre]

On Fri, Jan 16, 2015 at 11:45 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 Control: tags -1 + moreinfo

 On 2015-01-16 16:07, Mathieu Malaterre wrote:

 Please unblock package uncrustify

 I've removed the non-free file from the tarball. See #753760.


 The package was removed from testing at the start of August and nothing
 happened for over five months. I'm not convinced we should be reaccepting it
 now.

Could one of the uncrustify maintainer/uploader please answer this
request ? Or are you both MIA ?

Thx


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

Bug#775506: unblock: tbb/4.2~20140122-4

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tbb

It fixes two grave bugs: #756233  #762656
It also fixes a longer term issue, as depicted in comment: #775263#17
So I understand the debdiff may be a little long, but unblocking current tbb 
from sid into testing would solve the issue for the long term.
Comments welcome

unblock tbb/4.2~20140122-4

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tbb-4.2~20140122/debian/changelog tbb-4.2~20140122/debian/changelog
--- tbb-4.2~20140122/debian/changelog	2014-06-04 15:08:56.0 +0200
+++ tbb-4.2~20140122/debian/changelog	2014-10-30 18:55:55.0 +0100
@@ -1,3 +1,33 @@
+tbb (4.2~20140122-4) unstable; urgency=medium
+  * Bump standards version to 3.9.6.
+  * Add debian/tbb.pc to clean list.
+
+  [ Mathieu Malaterre ]
+  * Don't use gcc atomics for ppc32. Closes: #762656
+
+ -- Steve Capper steven.cap...@gmail.com  Thu, 30 Oct 2014 17:55:02 +
+
+tbb (4.2~20140122-3) unstable; urgency=medium
+
+  * Unit test execution failures no longer cause build to fail; instead take a
+tally of passes/failures to make it easier to analyse which cases are prone
+to failure.
++ debian/patches/tally-unit-test-fails.patch
+  * debian/rules modified s.t. the unit tests are no longer executed twice
+
+ -- Steve Capper steven.cap...@gmail.com  Fri, 19 Sep 2014 20:35:24 +0100
+
+tbb (4.2~20140122-2) unstable; urgency=medium
+
+  * Unit test compile errors no longer ignored. Closes: #752820
+  * for i386 architecture, set march=i586 (has to match gcc): Closes: #756233
+  * Debian architecture overrides uname -m, allows pbuilder i386 builds.
+  * Amended Linux kernel version detection logic to work with x.y.
+  * Bump standards version to 3.9.5. 
+  * A couple of Lintian source-is-missing errors overridden. 
+
+ -- Steve Capper steven.cap...@gmail.com  Sat, 26 Jul 2014 18:45:08 +0100
+
 tbb (4.2~20140122-1.1) unstable; urgency=low
 
   [ Helge Deller ]
diff -Nru tbb-4.2~20140122/debian/control tbb-4.2~20140122/debian/control
--- tbb-4.2~20140122/debian/control	2014-06-04 15:08:26.0 +0200
+++ tbb-4.2~20140122/debian/control	2014-10-29 20:42:34.0 +0100
@@ -2,7 +2,7 @@
 Priority: extra
 Maintainer: Steve Capper steven.cap...@gmail.com
 Build-Depends: debhelper (= 9), dpkg-dev (= 1.16.1~), libjs-jquery
-Standards-Version: 3.9.4
+Standards-Version: 3.9.6
 Section: libs
 Homepage: http://threadingbuildingblocks.org/
 
diff -Nru tbb-4.2~20140122/debian/patches/buildi386.patch tbb-4.2~20140122/debian/patches/buildi386.patch
--- tbb-4.2~20140122/debian/patches/buildi386.patch	1970-01-01 01:00:00.0 +0100
+++ tbb-4.2~20140122/debian/patches/buildi386.patch	2014-09-19 18:10:59.0 +0200
@@ -0,0 +1,34 @@
+Description: allow i386 builds on amd64 and set march to match gcc
+Author: Steve Capper steven.cap...@gmail.com
+
+Index: tbb/build/linux.gcc.inc
+===
+--- tbb.orig/build/linux.gcc.inc
 tbb/build/linux.gcc.inc
+@@ -93,7 +93,11 @@ endif
+ 
+ ifeq (ia32,$(arch))
+ ITT_NOTIFY = -DDO_ITT_NOTIFY
+-CPLUS_FLAGS += -m32 -march=pentium4 $(ENABLE_RTM)
++ifeq ($(shell dpkg-architecture -qDEB_HOST_ARCH),i386)
++CPLUS_FLAGS += -m32 -march=i586 $(ENABLE_RTM)
++else
++CPLUS_FLAGS += -m32 -march=pentium4 $(ENABLE_RTM)
++endif
+ LIB_LINK_FLAGS += -m32
+ endif
+ 
+Index: tbb/build/linux.inc
+===
+--- tbb.orig/build/linux.inc
 tbb/build/linux.inc
+@@ -73,6 +73,9 @@ ifndef arch
+ ifeq ($(deb_host_arch),x32)
+ export arch:=x32
+ endif
++ifeq ($(deb_host_arch),i386)
++export arch:=ia32
++endif
+ ifndef arch
+ export arch:=$(uname_m)
+ $(warning Unknown arch:  $(arch))
diff -Nru tbb-4.2~20140122/debian/patches/failonbadtests.patch tbb-4.2~20140122/debian/patches/failonbadtests.patch
--- tbb-4.2~20140122/debian/patches/failonbadtests.patch	1970-01-01 01:00:00.0 +0100
+++ tbb-4.2~20140122/debian/patches/failonbadtests.patch	2014-09-19 18:10:59.0 +0200
@@ -0,0 +1,22 @@
+Description: Fail hard on serious unit test fails
+Author: Steve Capper steven.cap...@gmail.com
+
+Index: tbb/Makefile
+===
+--- tbb.orig/Makefile
 tbb/Makefile
+@@ -49,10 +49,10 @@ tbbproxy: mkdir
+ 	$(MAKE) -C $(work_dir)_release  -r -f $(tbb_root)/build/Makefile.tbbproxy cfg=release tbbproxy
+ 
+ test: tbb tbbmalloc

Bug#775516: unblock: uncrustify/0.59+dfsg1-1.1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package uncrustify

I've removed the non-free file from the tarball. See #753760.

unblock uncrustify/0.59+dfsg1-1.1

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru uncrustify-0.59/debian/changelog uncrustify-0.59+dfsg1/debian/changelog
--- uncrustify-0.59/debian/changelog	2012-05-21 14:41:39.0 +0200
+++ uncrustify-0.59+dfsg1/debian/changelog	2015-01-16 16:52:17.0 +0100
@@ -1,3 +1,10 @@
+uncrustify (0.59+dfsg1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove non-free file (project-support.jpg). Closes: #753760
+
+ -- Mathieu Malaterre ma...@debian.org  Fri, 16 Jan 2015 16:52:15 +0100
+
 uncrustify (0.59-2) unstable; urgency=low
 
   * Fix FTBFS with gcc 4.7 by fixing missing unistd.h include.
Binary files /tmp/vh3Vcyxw1Q/uncrustify-0.59/documentation/htdocs/project-support.jpg and /tmp/I7gLHejx3j/uncrustify-0.59+dfsg1/documentation/htdocs/project-support.jpg differ

Bug#775411: unblock: gl2ps/1.3.8-1.1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package gl2ps

gl2ps package currently ships an underlinked library, see #775403
debdiff is attached.

Thanks

unblock gl2ps/1.3.8-1.1

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gl2ps-1.3.8/debian/changelog gl2ps-1.3.8/debian/changelog
--- gl2ps-1.3.8/debian/changelog	2013-05-14 11:07:39.0 +0200
+++ gl2ps-1.3.8/debian/changelog	2015-01-15 11:43:24.0 +0100
@@ -1,3 +1,11 @@
+gl2ps (1.3.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix undefined symbols. Closes: 775403
++ d/p/undef.patch
+
+ -- Mathieu Malaterre ma...@debian.org  Thu, 15 Jan 2015 11:43:18 +0100
+
 gl2ps (1.3.8-1) unstable; urgency=low
 
   * Upload to unstable
diff -Nru gl2ps-1.3.8/debian/patches/series gl2ps-1.3.8/debian/patches/series
--- gl2ps-1.3.8/debian/patches/series	2012-09-18 09:13:08.0 +0200
+++ gl2ps-1.3.8/debian/patches/series	2015-01-15 11:43:44.0 +0100
@@ -1,2 +1,3 @@
 buildsys.diff
 linkGL.diff
+undef.patch
diff -Nru gl2ps-1.3.8/debian/patches/undef.patch gl2ps-1.3.8/debian/patches/undef.patch
--- gl2ps-1.3.8/debian/patches/undef.patch	1970-01-01 01:00:00.0 +0100
+++ gl2ps-1.3.8/debian/patches/undef.patch	2015-01-15 11:43:33.0 +0100
@@ -0,0 +1,24 @@
+Description: Fix undefined symbols
+Author: Mathieu Malaterre ma...@debian.org
+Bug-Debian: http://bugs.debian.org/775403
+
+--- gl2ps-1.3.8.orig/Makefile
 gl2ps-1.3.8/Makefile
+@@ -2,7 +2,7 @@ OPTFLAGS = -O2 -Wall
+ EXTRALIBS = -lGL -lm
+ CFLAGS += $(OPTFLAGS) -fPIC
+ LDFLAGS += $(EXTRALIBS)
+-LDFLAGS += -Wl,--version-script=Version -Wl,--no-add-needed
++EXTRALIBS += -Wl,--version-script=Version -Wl,--no-add-needed
+ MAJOR = 0
+ MINOR = 0
+ MICRO = 0
+@@ -24,7 +24,7 @@ clean:
+ 	rm -f $(OBJS) $(SLIBNAME)
+ 
+ $(SLIBNAME): $(OBJS)
+-	$(CC) -shared -Wl,-soname,$(SLIBNAME_WITH_MAJOR) -o $@ $(filter %.o,$^) $(LDFLAGS)
++	$(CC) -shared -Wl,-soname,$(SLIBNAME_WITH_MAJOR) -o $@ $(filter %.o,$^) $(LDFLAGS) $(EXTRALIBS)
+ 
+ install:
+ 	mkdir -p $(DESTDIR)$(SLIBDIR)

Bug#775411: unblock: gl2ps/1.3.8-1.2

[Mathieu Malaterre]

My previous upload made multiples archs FTBFS. So please instead:

unblock gl2ps/1.3.8-1.2

It now properly Depends: on libGL.so package provider.

debdiff is attached.


debdiff2
Description: Binary data

Bug#774831: unblock: pbbuttonsd/0.7.9-5

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pbbuttonsd

This upload fixes 711685, I took the liberty to also fix a lintian error 
(dpkg-dev version in B-D).
It also fixes an issue with an incorrect entry in d/control when package was 
adopted, see #774688

unblock pbbuttonsd/0.7.9-5

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru pbbuttonsd-0.7.9/debian/changelog pbbuttonsd-0.7.9/debian/changelog
--- pbbuttonsd-0.7.9/debian/changelog	2014-01-22 13:08:34.0 +0100
+++ pbbuttonsd-0.7.9/debian/changelog	2015-01-08 09:01:18.0 +0100
@@ -1,3 +1,16 @@
+pbbuttonsd (0.7.9-5) unstable; urgency=low
+
+  * Really adopt package (#774688).
+
+ -- Mathieu Malaterre ma...@debian.org  Thu, 08 Jan 2015 09:01:14 +0100
+
+pbbuttonsd (0.7.9-4) unstable; urgency=low
+
+  * Adopt package. Closes: #422162
+  * Fix for linux kernel 3.x. Closes: #711685
+
+ -- Mathieu Malaterre ma...@debian.org  Tue, 06 Jan 2015 10:12:35 +0100
+
 pbbuttonsd (0.7.9-3) unstable; urgency=low
 
   * QA upload.
diff -Nru pbbuttonsd-0.7.9/debian/control pbbuttonsd-0.7.9/debian/control
--- pbbuttonsd-0.7.9/debian/control	2014-01-22 13:05:01.0 +0100
+++ pbbuttonsd-0.7.9/debian/control	2015-01-08 09:00:35.0 +0100
@@ -1,8 +1,8 @@
 Source: pbbuttonsd
 Section: admin
 Priority: optional
-Maintainer: Debian QA Group packa...@qa.debian.org
-Build-Depends: debhelper (= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config
+Maintainer: Mathieu Malaterre ma...@debian.org
+Build-Depends: debhelper (= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config, dpkg-dev (= 1.16.1~)
 Standards-Version: 3.9.5
 
 Package: pbbuttonsd
diff -Nru pbbuttonsd-0.7.9/debian/patches/cpufreq.patch pbbuttonsd-0.7.9/debian/patches/cpufreq.patch
--- pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	2015-01-05 12:19:16.0 +0100
@@ -0,0 +1,28 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre ma...@debian.org
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c1
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre ma...@debian.org
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/cpufreq	2015-01-05 12:05:46.542701600 +0100
 pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq	2015-01-05 12:05:50.220539855 +0100
+@@ -18,7 +18,7 @@
+ case $1 in
+   powersave|custom)
+ case $KVER in
+-  2.6.*)
++  2.6.*|3.*)
+ if [ -d /sys ]; then
+   echo -n userspace  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq  /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
+@@ -41,7 +41,7 @@
+;;
+   performance)
+  case $KVER in
+-  2.6.*)
++  2.6.*|3.*)
+ if [ -d /sys ]; then
+   echo -n userspace  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq  /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
diff -Nru pbbuttonsd-0.7.9/debian/patches/laptopmode.patch pbbuttonsd-0.7.9/debian/patches/laptopmode.patch
--- pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	2015-01-05 12:19:18.0 +0100
@@ -0,0 +1,37 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre ma...@debian.org
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c2
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre ma...@debian.org
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/laptopmode.sh	2006-10-01 17:34:12.0 +0200
 pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh	2015-01-05 12:12:09.217970623 +0100
+@@ -122,7 +122,7 @@
+ 	 )
+ 	 )
+ case $KLEVEL in
+-	2.4|2.6)
++	2.4|2.6|3.*)
+ 		true
+ 		;;
+ 	*)
+@@ -222,7 +222,7 @@
+ echo 1 /proc/sys/vm/laptop_mode
+ echo 30 500 0 0 $AGE $AGE 60 20 0	 /proc/sys/vm/bdflush
+ ;;
+-			2.6)
++			2.6|3.*)
+ echo 5 /proc/sys/vm/laptop_mode
+ echo $AGE /proc/sys/vm/dirty_writeback_centisecs
+ echo $AGE /proc/sys/vm/dirty_expire_centisecs
+@@ -268,7 +268,7 @@
+ 			2.4)
+ echo 30 500 0 0 $U_AGE $B_AGE 60 20 0	 /proc/sys/vm/bdflush
+ ;;
+-			2.6)
++			2.6|3

Bug#774688: unblock: pbbuttonsd/0.7.9-3

[Mathieu Malaterre]

On Tue, Jan 6, 2015 at 8:01 PM, Sven Joachim svenj...@gmx.de wrote:
 On 2015-01-06 10:24 +0100, Mathieu Malaterre wrote:

 diff -Nru pbbuttonsd-0.7.9/debian/changelog pbbuttonsd-0.7.9/debian/changelog
 --- pbbuttonsd-0.7.9/debian/changelog 2014-01-22 13:08:34.0 +0100
 +++ pbbuttonsd-0.7.9/debian/changelog 2015-01-06 10:12:42.0 +0100
 @@ -1,3 +1,10 @@
 +pbbuttonsd (0.7.9-4) unstable; urgency=low
 +
 +  * Adopt package. Closes: #422162
 +  * Fix for linux kernel 3.x. Closes: #711685

 How about future 4.x kernels?  It seems quite possible that those will be
 released during jessie's lifetime.

In which case, someone will need to report a bug that pbbuttonsd does
or does not work for kernel 4.x when this happens.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsz+QmNc4WisO=wgzgk40x-4zrs-uv9fr53uozt1eqo...@mail.gmail.com

Bug#774688: unblock: pbbuttonsd/0.7.9-3

[Mathieu Malaterre]

On Tue, Jan 6, 2015 at 7:31 PM, Jonathan Wiltshire j...@debian.org wrote:
 Control: tag -1 moreinfo

 On Tue, Jan 06, 2015 at 10:24:40AM +0100, Mathieu Malaterre wrote:
 +pbbuttonsd (0.7.9-4) unstable; urgency=low
 +
 +  * Adopt package. Closes: #422162

 I'll happily trade the adoption for an unblock, but you don't appear to
 have updated the maintainer field:

Sorry I skrew-up. Do I need another source-upload ?


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsxakr=ad+lwp0bu5k+sgk2wnfd1ku9pexfeesg7ob9...@mail.gmail.com

Bug#774688: unblock: pbbuttonsd/0.7.9-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package pbbuttonsd

This upload fixes 711685, I took the liberty to also fix a lintian error 
(dpkg-dev version in B-D).


unblock pbbuttonsd/0.7.9-3

-- System Information:
Debian Release: 7.4
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru pbbuttonsd-0.7.9/debian/changelog pbbuttonsd-0.7.9/debian/changelog
--- pbbuttonsd-0.7.9/debian/changelog	2014-01-22 13:08:34.0 +0100
+++ pbbuttonsd-0.7.9/debian/changelog	2015-01-06 10:12:42.0 +0100
@@ -1,3 +1,10 @@
+pbbuttonsd (0.7.9-4) unstable; urgency=low
+
+  * Adopt package. Closes: #422162
+  * Fix for linux kernel 3.x. Closes: #711685
+
+ -- Mathieu Malaterre ma...@debian.org  Tue, 06 Jan 2015 10:12:35 +0100
+
 pbbuttonsd (0.7.9-3) unstable; urgency=low
 
   * QA upload.
diff -Nru pbbuttonsd-0.7.9/debian/control pbbuttonsd-0.7.9/debian/control
--- pbbuttonsd-0.7.9/debian/control	2014-01-22 13:05:01.0 +0100
+++ pbbuttonsd-0.7.9/debian/control	2015-01-06 10:11:51.0 +0100
@@ -2,7 +2,7 @@
 Section: admin
 Priority: optional
 Maintainer: Debian QA Group packa...@qa.debian.org
-Build-Depends: debhelper (= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config
+Build-Depends: debhelper (= 9), bison, gettext, libasound2-dev, libglib2.0-dev, pkg-config, dpkg-dev (= 1.16.1~)
 Standards-Version: 3.9.5
 
 Package: pbbuttonsd
diff -Nru pbbuttonsd-0.7.9/debian/patches/cpufreq.patch pbbuttonsd-0.7.9/debian/patches/cpufreq.patch
--- pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/cpufreq.patch	2015-01-05 12:19:16.0 +0100
@@ -0,0 +1,28 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre ma...@debian.org
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c1
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre ma...@debian.org
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/cpufreq	2015-01-05 12:05:46.542701600 +0100
 pbbuttonsd-0.7.9/scripts/scripts.d/cpufreq	2015-01-05 12:05:50.220539855 +0100
+@@ -18,7 +18,7 @@
+ case $1 in
+   powersave|custom)
+ case $KVER in
+-  2.6.*)
++  2.6.*|3.*)
+ if [ -d /sys ]; then
+   echo -n userspace  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq  /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
+@@ -41,7 +41,7 @@
+;;
+   performance)
+  case $KVER in
+-  2.6.*)
++  2.6.*|3.*)
+ if [ -d /sys ]; then
+   echo -n userspace  /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
+   cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq  /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
diff -Nru pbbuttonsd-0.7.9/debian/patches/laptopmode.patch pbbuttonsd-0.7.9/debian/patches/laptopmode.patch
--- pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	1970-01-01 01:00:00.0 +0100
+++ pbbuttonsd-0.7.9/debian/patches/laptopmode.patch	2015-01-05 12:19:18.0 +0100
@@ -0,0 +1,37 @@
+Description: pbbuttonsd is not rewritten for kernel 3.2
+Author: Mathieu Malaterre ma...@debian.org
+Origin: https://bugs.gentoo.org/show_bug.cgi?id=429306#c2
+Bug-Debian: http://bugs.debian.org/711685
+Reviewed-by: Mathieu Malaterre ma...@debian.org
+
+Index: pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh
+===
+--- pbbuttonsd-0.7.9.orig/scripts/scripts.d/laptopmode.sh	2006-10-01 17:34:12.0 +0200
 pbbuttonsd-0.7.9/scripts/scripts.d/laptopmode.sh	2015-01-05 12:12:09.217970623 +0100
+@@ -122,7 +122,7 @@
+ 	 )
+ 	 )
+ case $KLEVEL in
+-	2.4|2.6)
++	2.4|2.6|3.*)
+ 		true
+ 		;;
+ 	*)
+@@ -222,7 +222,7 @@
+ echo 1 /proc/sys/vm/laptop_mode
+ echo 30 500 0 0 $AGE $AGE 60 20 0	 /proc/sys/vm/bdflush
+ ;;
+-			2.6)
++			2.6|3.*)
+ echo 5 /proc/sys/vm/laptop_mode
+ echo $AGE /proc/sys/vm/dirty_writeback_centisecs
+ echo $AGE /proc/sys/vm/dirty_expire_centisecs
+@@ -268,7 +268,7 @@
+ 			2.4)
+ echo 30 500 0 0 $U_AGE $B_AGE 60 20 0	 /proc/sys/vm/bdflush
+ ;;
+-			2.6)
++			2.6|3.*)
+ echo $U_AGE /proc/sys/vm/dirty_writeback_centisecs
+ echo $B_AGE /proc/sys/vm/dirty_expire_centisecs
+ echo $DEF_DIRTY_RATIO			 /proc/sys/vm/dirty_ratio
diff -Nru pbbuttonsd-0.7.9/debian/patches/series pbbuttonsd-0.7.9/debian/patches/series
--- pbbuttonsd-0.7.9/debian/patches/series	2014-01-22 12:19

Bug#774688: Wrong version

[Mathieu Malaterre]

Sorry meant to type:

unblock pbbuttonsd/0.7.9-4


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusz7sjgxeuxqbkzk5kgzgbledm-yb45_9ztcjrheszv...@mail.gmail.com

Bug#768410: unblock: charls/1.0-6

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package charls

libgdcm2.4 is marked as `Multi-Arch: same` however two of its dependencies 
(charls/socket++) are not marked as `Multi-Arch: same`. This prevent libgdcm2.4 
package from true multiarch capabilities.
Please unblock charls which add the missing `Multi-Arch: same`. See attached 
debdiff. I'll report another unblock request for socket++ in a different bug.


unblock charls/1.0-6

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru charls-1.0/debian/changelog charls-1.0/debian/changelog
--- charls-1.0/debian/changelog	2013-12-08 12:37:30.0 +0100
+++ charls-1.0/debian/changelog	2014-11-07 09:29:46.0 +0100
@@ -1,3 +1,10 @@
+charls (1.0-6) unstable; urgency=low
+
+  * Really make the package multiarch capable. Closes: #768404
+  * Bump Std-Vers to 3.9.6, no changes needed.
+
+ -- Mathieu Malaterre ma...@debian.org  Fri, 07 Nov 2014 09:20:43 +0100
+
 charls (1.0-5) unstable; urgency=medium
 
   * Rework the symbol file to hide stl exported symbols
diff -Nru charls-1.0/debian/control charls-1.0/debian/control
--- charls-1.0/debian/control	2013-12-07 09:28:05.0 +0100
+++ charls-1.0/debian/control	2014-11-07 09:29:46.0 +0100
@@ -5,7 +5,7 @@
 Priority: optional
 Build-Depends: debhelper (= 9),
cmake
-Standards-Version: 3.9.5
+Standards-Version: 3.9.6
 Vcs-Browser: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/charls/trunk/
 Vcs-Svn: svn://anonscm.debian.org/debian-med/trunk/packages/charls/trunk/
 Homepage: http://charls.codeplex.com
@@ -13,6 +13,7 @@
 Package: libcharls-dev
 Architecture: any
 Section: libdevel
+Multi-Arch: same
 Depends: libcharls1 (= ${binary:Version}),
  ${misc:Depends}
 Description: Implementation of the JPEG-LS standard (development libraries)
@@ -29,6 +30,7 @@
 
 Package: libcharls1
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}

Bug#768413: unblock: socket++/1.12.13-8

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package socket++

libgdcm2.4 is marked as `Multi-Arch: same` however two of its
dependencies (charls/socket++) are not marked as `Multi-Arch: same`.
This prevent libgdcm2.4 package from true multiarch capabilities.
Please unblock socket++ which add the missing `Multi-Arch: same`. See
attached debdiff. charls has been reported in another bug already.


unblock socket++/1.12.13-8

-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


socket++.debdiff
Description: Binary data

Bug#762905: transition: openjpeg2 2.1.0

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I am reading the cruft report:

https://ftp-master.debian.org/cruft-report-daily.txt

[...]
* source package openjpeg2 version 2.1.0-1 no longer builds
  binary package(s): libopenjp3d6 libopenjpeg6 libopenjpeg6-dbg
libopenjpeg6-dev libopenjpip6 openjp3d-tools
  on 
amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mipsel,powerpc,ppc64el,s390x,sparc
  - suggested command:
dak rm -m [auto-cruft] NBS (no longer built by openjpeg2) -s
unstable -a 
amd64,armel,armhf,i386,kfreebsd-amd64,kfreebsd-i386,mipsel,powerpc,ppc64el,s390x,sparc
-p -R -b libopenjp3d6 libopenjpeg6 libopenjpeg6-dbg libopenjpeg6-dev
libopenjpip6 openjp3d-tools
  - broken Depends:
openjpeg2: openjpeg-tools
   openjpip-dec-server
  - broken Build-Depends:
leptonlib: libopenjpeg6-dev
[...]

The broken Build-Depends (leptonlib) is now fixed in sid. The broken
Depends is a mistake, src:openjpeg2 was building binary packages using
the same name as binaries from src:openjpeg.

Please run the suggested dak rm command.

In case that is of any use :

title = openjpeg2;
is_affected = .depends ~ libopenjpeg6-dev;
is_bad = .depends ~ libopenjpeg6;


Thanks.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsyQN9D4uU7mCNAOAHiUwHwyYfzVVLD=8rzyxsqmqvg...@mail.gmail.com

Bug#762100: nmu: libvtk-dicom0.5_0.5.5-1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

I cannot reproduce the JNI issue on kfreebsd and sparc from a buildd
machine (smetana  falla). I guess the issue was fixed in the java
package.

So please schedule a binNMU:

nmu libvtk-dicom0.5_0.5.5-1 . kfreebsd-amd64 kfreebsd-i386 sparc . -m
jni issue

Thanks


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusyojyrku_tgre-mpm4fstehuaflojyguq+hr0e3+0f...@mail.gmail.com

Re: gdcm is marked for autoremoval from testing

[Mathieu Malaterre]

As the message states: 'gdcm 2.4.2-1'... which is IMHO correct. I
guess the message could have been skipped to avoid a little noise.

2cts

On Tue, Jul 15, 2014 at 9:34 AM, Andreas Tille andr...@an3as.eu wrote:
 Hi Release team,

 I wonder why gdcm is marked for autoremoval since the bug is fixed in
 testing and unstable.  Am I missing something?

 Gianfranco, Pino:  Thanks a lot for your NMU!

 Kind regards

   Andreas.

 On Tue, Jul 15, 2014 at 04:39:10AM +, Debian testing autoremoval watch 
 wrote:
 gdcm 2.4.2-1 is marked for autoremoval from testing on 2014-08-14

 It is affected by these RC bugs:
 751432: gdcm: compatibility with poppler 0.26.x

 --
 http://fam-tille.de


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

Bug#749395: vtk6 transition should be on hold

[Mathieu Malaterre]

Anton,

  With all due respect, I think you are pusing too hard on vtk6
transition. I may be very biased but for example support for VTK6 was
pushed in GDCM only weeks ago.

  I do not believe that *forcing* for vtk6 transition will help people
move gracefully from one API to the new one. The step is really big.
As said before I would have hope for a smoother transition with first
a migration to vtk5.10.

  As you may have noticed I fill two grave bugs on vtk6 package
(#749920  #750171), I expect at a minimum that vtk6 packaging is
cleanup before true migration can occur (past vtk package maintainer
hat on).

  Furthermore you have not outlined in #749395 how you are going to
detect python-vtk, vtk-tcl and vtk-java package API breaks. As per
your request:

https://release.debian.org/transitions/html/vtk6.html

  you only required .depends ~ libvtk5.8, while clearly all
scripts based vtk package should be tested (vtk6 is an API break[*]
with removed API, namely the SetInput one are the most visible one),
see: $ apt-cache rdepends python-vtk for some possible (as you noticed
some are not listed on ben transition page).

Regards,
[*] Yes I mean API, not ABI.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CA+7wUsyVJvvbctZwkexFk9UguLR3j=X9ZBAOhxV6v4+qEv=t...@mail.gmail.com

Bug#746335: nmu: libvtk-dicom0.4_0.4.5-1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

If I read and understand the following correctly:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;bug=746216

Please schedule a binNMU:

nmu libvtk-dicom0.4_0.4.5-1 . i386 kfreebsd-amd64 kfreebsd-amd64i386
mips mipsel powerpc . -m rebuild against newer libgmp10 lib

Thanks


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusxx1gnek4c_yuce-1ueqz+lzvmxv7-lfu06dorj4cn...@mail.gmail.com

Bug#669348: transition: openjpeg

[Mathieu Malaterre]

On Sun, Mar 16, 2014 at 6:49 PM, Julien Cristau jcris...@debian.org wrote:
 Control: tag -1 confirmed

 On Mon, Feb 10, 2014 at 16:21:09 +0100, Mathieu Malaterre wrote:

 On Mon, Jan 20, 2014 at 1:16 PM, Julien Cristau jcris...@debian.org wrote:
  On Mon, Jan 20, 2014 at 12:59:52 +0100, Mathieu Malaterre wrote:
 [...]
  What exactly is holding openjpeg 1.5.1 transition ?
 
  The other way around.  freeimage depends on openjpeg, which means an
  openjpeg transition involves getting a new freeimage in to testing,
  which is not possible if freeimage in sid is broken.


 Now that freeimage is in testing, can we transition to openjpeg 1.5 ?

 Feel free to upload.  Please let this bug know when openjpeg is built on
 all archs and binNMUs can be scheduled.

buildds are all looking good !


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

Bug#669348: CMake Error at /usr/lib/x86_64-linux-gnu/openjpeg-1.5/OpenJPEGTargets.cmake:112 (message):

[Mathieu Malaterre]

Sorry I totally forgot that new CMake version move the monolithic
export thingy to another file. I need to sed another file.

Sorry for the noise, will upload asap.

ref:

CMake Error at /usr/lib/x86_64-linux-gnu/openjpeg-1.5/OpenJPEGTargets.cmake:112
(message):
  The imported target j2k_to_image references the file

 /usr/bin/j2k_to_image

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 /usr/lib/x86_64-linux-gnu/openjpeg-1.5/OpenJPEGTargets.cmake

  but not all the files it references.

Call Stack (most recent call first):
  /usr/lib/x86_64-linux-gnu/openjpeg-1.5/OpenJPEGConfig.cmake:34 (include)
  CMake/FindOpenJPEG.cmake:22 (find_package)
  CMakeLists.txt:374 (find_package)


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ca+7wusw48tkgmzaulg4pp2sidlbb_uowugp+7+geqwxynug...@mail.gmail.com

Bug#728178: transition: gdcm 2.4.0

[Mathieu Malaterre]

On Mon, Feb 3, 2014 at 4:11 PM, Mathieu Malaterre ma...@debian.org wrote:
 Steve,

 On Mon, Feb 3, 2014 at 4:04 PM, Julien Cristau jcris...@debian.org wrote:
 On Tue, Oct 29, 2013 at 09:04:35 +0100, Mathieu Malaterre wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 I'd like to request a transition slot for GDCM 2.4.0. Once #727154 is
 fixed GDCM can be moved to sid. I'll prepare a list of impacted
 packages.

 Are you planning on uploading a fixed gccxml?

 Are you working on gccxml this week ? Otherwise I'll `team upload` a
 new version this week end.

newer gccxml did fix the gdcm compilation issues.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsyHYXJKvEifEPoFUzF3=trdh0jsgukgviq2hskkov8...@mail.gmail.com

Bug#728178: transition: gdcm 2.4.0

[Mathieu Malaterre]

Steve,

On Mon, Feb 3, 2014 at 4:04 PM, Julien Cristau jcris...@debian.org wrote:
 On Tue, Oct 29, 2013 at 09:04:35 +0100, Mathieu Malaterre wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition

 I'd like to request a transition slot for GDCM 2.4.0. Once #727154 is
 fixed GDCM can be moved to sid. I'll prepare a list of impacted
 packages.

 Are you planning on uploading a fixed gccxml?

Are you working on gccxml this week ? Otherwise I'll `team upload` a
new version this week end.

cheers


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswruoqm+oas7c775ob4pbytfr8nvjn_m2g5wwa_to5...@mail.gmail.com

Bug#728178: GDCM 2.4.1 in shape for transition

[Mathieu Malaterre]

On Mon, Jan 20, 2014 at 10:41 AM, Julien Cristau jcris...@debian.org wrote:
 On Mon, Jan  6, 2014 at 10:10:32 +0100, Mathieu Malaterre wrote:

 FYI, GDCM 2.4.1 builds on all archs as can be seen:

 https://buildd.debian.org/status/package.php?p=gdcmsuite=experimental

 It is thus in shape for transition.

 Are there any API changes affecting the reverse deps?

No API changes. ABI in incompatible, thus all reverse deps needs to be rebuild.

Thanks,


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswc_a4b1udbessffbhvm65ny13b_qy2guyl4wu4qm2...@mail.gmail.com

Bug#669348: transition: openjpeg

[Mathieu Malaterre]

On Mon, Jan 20, 2014 at 10:18 AM, Julien Cristau jcris...@debian.org wrote:
 Control: block -1 with 735847

 On Thu, Apr 19, 2012 at 11:47:45 +0200, Mathieu Malaterre wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition


 I'd like to request a transition slot for openjpeg 1.5. the main reason for 
 1.5 is that it fixes JPEG 2000 support in PDF file, see #659226  #667708

 This is now going to block on #735847 (or on getting rid of freeimage,
 if possible...).

AFAIK openjpeg 1.5.1 does not depends on freeimage anymore to build:

http://packages.debian.org/source/experimental/openjpeg

What exactly is holding openjpeg 1.5.1 transition ?

Thanks,


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxsZicwvyy=WPmjJzOWK3CMmJ0WkN9XDYi3mdpoyXi=z...@mail.gmail.com

Bug#728178: GDCM 2.4.1 in shape for transition

[Mathieu Malaterre]

FYI, GDCM 2.4.1 builds on all archs as can be seen:

https://buildd.debian.org/status/package.php?p=gdcmsuite=experimental

It is thus in shape for transition.

Thanks,


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxJZiLHYZCsDua+rMivPf+uDaiK=wv0gmvuizk3hcy...@mail.gmail.com

Bug#728178: Ben file

[Mathieu Malaterre]

Ben file:

title = gdcm;
is_affected = .depends ~ libgdcm2-dev;
is_good = .depends ~ libgdcm2.4;
is_bad = .depends ~ libgdcm2.2;


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsy9vDP2WkNRv=2xTZU2C4fgUidjSoes=yea1nsvvnu...@mail.gmail.com

Bug#728178: transition: gdcm 2.4.0

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to request a transition slot for GDCM 2.4.0. Once #727154 is
fixed GDCM can be moved to sid. I'll prepare a list of impacted
packages.


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUszfJ8L0Pe5C5bfN0S6xiuq+-gFc_RPq2tQ2+0R=yvm...@mail.gmail.com

Re: Call for Jessie Release Goals

[Mathieu Malaterre]

On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire j...@debian.org wrote:
 Release goals are areas of functionality which developers would like to see
 as an aim for the next release. They will not hold up the release, but
 allow the bugs opened for that goal to be of severity 'important'.

I am not sure if this qualify as Release goals. So I'd like to ask
first what people think of using C++11 in the next release.

I know of a couple of C++ libraries which could be compiled with the
new gcc compilation option. And I have at least one application (no
shared lib) which requires C++11 to compile properly. Since C++11
introduce an ABI incompatibility [*], this may not be a Release Goal
but simply a tech-ctte decision.

Comments ?

-M

[*] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUswH4jbsGyU87g1e7d7QC=29-tq-q8pdawtuga2dgi1...@mail.gmail.com

Re: Candidates for removal from testing (2013-06-30)

[Mathieu Malaterre]

On Sun, Jun 30, 2013 at 11:32 PM, Niels Thykier ni...@thykier.net wrote:
 #678383 [pixelmed]: pixelmed: FTBFS with Java7 (uses internal Java API)

Would it be possible to filter out (in the future?) any bugs that are
marked as pending ? I have no control on this process.

Thanks,


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsz_=0-XFCROnwQ3KBT+xn_3oZszfma=nq+hzt4ee0l...@mail.gmail.com

Bug#704755: Bug#698698: Bug#704755: nmu: volview_3.4-3

[Mathieu Malaterre]

retitle 704755 unblock: kwwidgets/1.0.0~cvs20100930-8
usertags 704755 unblock -binnmu
thanks

unblock kwwidgets/1.0.0~cvs20100930-8

buildd all looks ok. volview now properly runs with
kwwidgets/1.0.0~cvs20100930-8, no need for a binnmu.

thanks


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsyzYbOT9hfrNSopGjGDo0gOUYbdBsn3yc_6u9F2=f-...@mail.gmail.com

Bug#705210: unblock: mummy/1.0.3-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package mummy

As explained on 703332#23 I prepared a testing-proposed-update package. debdiff 
attached.

unblock mummy/1.0.3-3

-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru mummy-1.0.3/debian/changelog mummy-1.0.3/debian/changelog
--- mummy-1.0.3/debian/changelog	2013-04-01 09:34:42.0 +0200
+++ mummy-1.0.3/debian/changelog	2013-04-11 11:59:20.0 +0200
@@ -1,3 +1,9 @@
+mummy (1.0.3-3) wheezy; urgency=low
+
+  * Fix ABI version. Closes: #703332
+
+ -- Mathieu Malaterre ma...@debian.org  Thu, 11 Apr 2013 09:58:20 +
+
 mummy (1.0.3-2) unstable; urgency=low
 
   * Fix ABI version. Closes: #703332

Bug#705210: unblock: mummy/1.0.3-3

[Mathieu Malaterre]

On Thu, Apr 11, 2013 at 2:22 PM, Jonathan Wiltshire j...@debian.org wrote:
 On 2013-04-11 11:53, Mathieu Malaterre wrote:
 Please prepare a diff against the current package in Wheezy and submit a
 revised debdiff for consideration. Please use version number 1.0.2-5+deb70u1
 (the conventional format) as your previous upload has now gone to the
 buildds and can't be revoked (also a good reason to ask first).

As explained on different emails (public  private), I am terribly
sorry but I have no idea what I need to do.

1.0.2-5 has been in wheezy for over a year now[1]. What should be
contained in 1.0.2-5+deb70u1, do you want me to upload 1.0.3 under a
wrong version number ?

Thanks,
[1] http://packages.qa.debian.org/m/mummy/news/20120518T163914Z.html


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusyj-hksdlgumij3qbzofh2jjotf1nybn-mekpzsqdv...@mail.gmail.com

Bug#704755: nmu: volview_3.4-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu volview_3.4-3 . ALL . -m volview does not start because of a missing 
symbol

I'd appreciate if you could binNMU volview on all arch. For some reason 
something really wrong happen on vtk 5.8.0 since volview was build
As a result volview refuses to starts with a message:

$ /usr/bin/volview
/usr/lib/VolView/VolView: symbol lookup error: 
/usr/lib/libKWWidgets.so.1.0.1009: undefined symbol: Vtkimagingtcl_Init

Simply rebuilding it entirely fixes the symptoms.

This will closes: #698698

thanks much

-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130405135524.13416.81175.report...@lirispat.univ-lyon1.fr

Bug#704755: nmu: volview_3.4-3

[Mathieu Malaterre]

Those are not dynamic libraries, but plugins with undefined symbols
which gets resolved at runtime. I guess upstream wants to be able to
resolve tcl symbols once the interpreter is loaded.

On Fri, Apr 5, 2013 at 6:01 PM, Julien Cristau jcris...@debian.org wrote:
 On Fri, Apr  5, 2013 at 15:55:24 +0200, Mathieu Malaterre wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: binnmu

 nmu volview_3.4-3 . ALL . -m volview does not start because of a missing 
 symbol

 I'd appreciate if you could binNMU volview on all arch. For some reason 
 something really wrong happen on vtk 5.8.0 since volview was build
 As a result volview refuses to starts with a message:

 $ /usr/bin/volview
 /usr/lib/VolView/VolView: symbol lookup error:
 /usr/lib/libKWWidgets.so.1.0.1009: undefined symbol: Vtkimagingtcl_Init

 Simply rebuilding it entirely fixes the symptoms.

 How is this (undefined symbol in libKWWidgets.so.1.0.1009) not a bug in
 kwwidgets (or vtk, maybe)?  So NAK...

 Cheers,
 Julien


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusy7ixbdbxbvxynnth494_tkr_f9iecsemyvo2nhuha...@mail.gmail.com

Bug#703331: nmu: libactiviz.net-cil_1:1.0~git20111214-1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

As per discussion on debian-cli, the C# lib version are incorrect:

http://lists.debian.org/debian-cli/2013/03/msg1.html

So please schedule a binNMU:

nmu libactiviz.net-cil_1:1.0~git20111214-1 . amd64 . -m rebuild against newer 
mummy lib

Thanks

-- System Information:
Debian Release: 6.0.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130318152146.1838.24860.report...@lirispat.univ-lyon1.fr

Bug#699465: t-p-u: gdcm 2.2.0-14

[Mathieu Malaterre]

Hi Julien

On Mon, Feb 4, 2013 at 11:23 PM, Julien Cristau jcris...@debian.org wrote:
 On Sat, Feb  2, 2013 at 18:51:52 +0100, Mathieu Malaterre wrote:

 Anyway I'll wait until mono properly enter testing and then -as Niels
 explained- will fix both testing+unstable

 Nope, having a fixed gdcm is a blocker for mono's migration to testing,
 please fix this ASAP in sid and testing (or let me know if you can't and
 I'll NMU).

Sorry I missed that point. I really do appreciate your offer, so
please go ahead and NMU as you need.

Thanks very much for your help !


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsyXTS_YuKNH31VA1UfNb9wz4kht-PGtPzPE0-MsQ=1...@mail.gmail.com

Bug#699465: t-p-u: gdcm 2.2.0-14

[Mathieu Malaterre]

On Thu, Jan 31, 2013 at 7:10 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On 31.01.2013 17:36, Mathieu Malaterre wrote:

 As per §5.13.3. Direct updates to testing, I'd like to ask
 permission for direct upload to testing for package gdcm.

   In order to fix #699379, I would need to upload 2.2.0-14, by-passing
 the current 2.2.1-1 sitting in unstable.


 Please attach a debdiff of the proposed upload to this bug log, as suggested
 in Neil's earlier mail.

Attached. And deb was dupload'ed.

 It looks like #699379 hasn't been fixed in unstable yet?

Correct. I do not see it as blocking though.

Thanks.


gdcm_armhf.diff
Description: Binary data

Bug#699465: t-p-u: gdcm 2.2.0-14

[Mathieu Malaterre]

On Sat, Feb 2, 2013 at 6:23 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On Sat, 2013-02-02 at 09:39 +0100, Mathieu Malaterre wrote:
 On Thu, Jan 31, 2013 at 7:10 PM, Adam D. Barratt
 a...@adam-barratt.org.uk wrote:
  On 31.01.2013 17:36, Mathieu Malaterre wrote:
 
  As per §5.13.3. Direct updates to testing, I'd like to ask
  permission for direct upload to testing for package gdcm.
 [...]
  Please attach a debdiff of the proposed upload to this bug log, as 
  suggested
  in Neil's earlier mail.

 Attached. And deb was dupload'ed.

 Unfortunately it FTBFS on armhf. The control file still lists the -cil
 packages as built on that architecture, which then fails because the
 build-dependencies aren't available.

 It looks like control.in has a substitution variable which updates both
 the build-dependency lists and the architecture lists for the binary
 packages. Was debian/control directly edited in this case instead?
 (Maybe because the mono packages in wheezy still list armhf as
 supported, which this upload is intended to be a move towards fixing.)

Correct -again-, I know I should not have done that.

Anyway I'll wait until mono properly enter testing and then -as Niels
explained- will fix both testing+unstable

Sorry for the mess,


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxh+VwFmJsz4ePTFvGjLv1JccKSk_uZikGq0uGv=hk...@mail.gmail.com

updates to testing

[Mathieu Malaterre]

Dear release team,

  As per §5.13.3. Direct updates to testing, I'd like to ask
permission for direct upload to testing for package gdcm.

  In order to fix #699379, I would need to upload 2.2.0-14, by-passing
the current 2.2.1-1 sitting in unstable.

Thanks.


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxeV2BGs=Z2skvXJrQxKOaEtqvkBM_NGw=j52ktseh...@mail.gmail.com

Bug#699465: t-p-u: gdcm 2.2.0-14

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal

As per §5.13.3. Direct updates to testing, I'd like to ask
permission for direct upload to testing for package gdcm.

  In order to fix #699379, I would need to upload 2.2.0-14, by-passing
the current 2.2.1-1 sitting in unstable.

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130131173607.14567.45556.report...@lirispat.univ-lyon1.fr

Re: updates to testing

[Mathieu Malaterre]

On Thu, Jan 31, 2013 at 6:30 PM, Neil Williams codeh...@debian.org wrote:
 On Thu, 31 Jan 2013 18:10:45 +0100
 Mathieu Malaterre ma...@debian.org wrote:

 Dear release team,

   As per §5.13.3. Direct updates to testing, I'd like to ask
 permission for direct upload to testing for package gdcm.

 You mean testing-proposed-updates.

ok

   In order to fix #699379, I would need to upload 2.2.0-14, by-passing
 the current 2.2.1-1 sitting in unstable.

 This is more likely to catch the attention of the team if you file it
 as a bug against release.debian.org, asking for permission for a t-p-u
 upload.

done

 That bug report needs to be accompanied by a full debdiff between the
 t-p-u build and the current version of the package in testing. Each
 change in that debdiff needs to be described in the t-p-u changelog.

I've registered the bug report. I'll update it once, I am done with
creating a testing chroot...

Thanks,


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusxanbtsehge0khwy3cmerb4_f0w5v+ov3ynmcx_wv5...@mail.gmail.com

Bug#698356: nmu: dicom3tools_1.0~20121227-1

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,

I messed-up the amd64 package when uploading it. Could you please rebuild it, 
this will fix #698115.
Thanks

nmu dicom3tools_1.0~20121227-1 . amd64 . -m fix  #698115

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130117160010.22529.68968.report...@lirispat.univ-lyon1.fr

Bug#696469: unblock: dcmtk/3.6.0-12

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dcmtk

libdcmtk2 package contains currently underlinked libraries. As per:

http://release.debian.org/testing/rc_policy.txt 5(f)
Shared libraries must normally be linked with all libraries they use symbols 
from.

Thus I have imported patch from Andrey Rahmatullin (see: 677721#34) to fix 
those. debdiff attached.

Thanks

unblock dcmtk/3.6.0-12

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru dcmtk-3.6.0/debian/changelog dcmtk-3.6.0/debian/changelog
--- dcmtk-3.6.0/debian/changelog	2012-12-20 13:22:26.0 +0100
+++ dcmtk-3.6.0/debian/changelog	2012-05-31 11:31:19.0 +0200
@@ -1,11 +1,3 @@
-dcmtk (3.6.0-12) unstable; urgency=low
-
-  [ Andrey Rahmatullin ]
-  * Fix underlinked libraries. Closes: #677721
-   - debian/patches/underlink.patch
-
- -- Mathieu Malaterre ma...@debian.org  Thu, 20 Dec 2012 13:20:45 +0100
-
 dcmtk (3.6.0-11) unstable; urgency=low
 
   * Fix compilation with gcc 4.7. Closes: #674361
diff -Nru dcmtk-3.6.0/debian/patches/underlink.patch dcmtk-3.6.0/debian/patches/underlink.patch
--- dcmtk-3.6.0/debian/patches/underlink.patch	2012-12-20 13:22:26.0 +0100
+++ dcmtk-3.6.0/debian/patches/underlink.patch	2012-05-31 11:19:11.0 +0200
@@ -3,33 +3,27 @@
  ar. We need to provide libraries only when dynamic library is built.
 Author: Ilya Barygin randomact...@ubuntu.com
 Bug-Debian: http://bugs.debian.org/674586
-Bug-Debian: http://bugs.debian.org/677721
 
 a/dcmsign/libsrc/Makefile.in
-+++ b/dcmsign/libsrc/Makefile.in
-@@ -17,6 +17,8 @@
- dcmdatadir = $(top_srcdir)/../dcmdata
- 
- LOCALINCLUDES = -I$(ofstddir)/include -I$(oflogdir)/include -I$(dcmdatadir)/include
-+LIBDIRS = -L$(ofstddir)/libsrc -L$(oflogdir)/libsrc -L$(dcmdatadir)/libsrc
-+LOCALLIBS = -lofstd -loflog -ldcmdata
- LOCALDEFS =
- 
- objs = dcsignat.o sicert.o sidsa.o simd5.o siprivat.o sirsa.o sisprof.o \
-@@ -34,7 +36,11 @@
+Index: dcmtk-3.6.0/dcmsign/libsrc/Makefile.in
+===
+--- dcmtk-3.6.0.orig/dcmsign/libsrc/Makefile.in	2012-05-31 10:45:58.207193330 +0200
 dcmtk-3.6.0/dcmsign/libsrc/Makefile.in	2012-05-31 10:45:59.843193307 +0200
+@@ -34,7 +34,11 @@
  
  
  $(library): $(objs)
 +ifeq ($(AR),ar)
  	$(AR) $(ARFLAGS) $@ $(objs)
 +else
-+	$(AR) $(ARFLAGS) $@ $(objs) $(LIBDIRS) $(LOCALLIBS) $(OPENSSLLIBS)
++	$(AR) $(ARFLAGS) $@ $(objs) $(OPENSSLLIBS)
 +endif
  	$(RANLIB) $@
  
  
 a/ofstd/libsrc/Makefile.in
-+++ b/ofstd/libsrc/Makefile.in
+Index: dcmtk-3.6.0/ofstd/libsrc/Makefile.in
+===
+--- dcmtk-3.6.0.orig/ofstd/libsrc/Makefile.in	2012-05-31 10:45:58.219193330 +0200
 dcmtk-3.6.0/ofstd/libsrc/Makefile.in	2012-05-31 10:45:59.843193307 +0200
 @@ -29,7 +29,11 @@
  
  
@@ -41,336 +35,4 @@
 +endif
  	$(RANLIB) $@
  
- 
 a/Makefile
-+++ b/Makefile
-@@ -7,27 +7,27 @@
- 
- include $(configdir)/Makefile.def
- 
--all:  config-all ofstd-all oflog-all dcmdata-all dcmtls-all dcmnet-all dcmqrdb-all dcmwlm-all dcmimgle-all dcmsr-all dcmsign-all dcmpstat-all dcmimage-all dcmjpeg-all dcmjpls-all
-+all:  config-all ofstd-all oflog-all dcmdata-all dcmnet-all dcmtls-all dcmqrdb-all dcmwlm-all dcmimgle-all dcmsr-all dcmsign-all dcmpstat-all dcmimage-all dcmjpeg-all dcmjpls-all
- 
--libsrc-all:  ofstd-libsrc-all oflog-libsrc-all dcmdata-libsrc-all dcmtls-libsrc-all dcmnet-libsrc-all dcmqrdb-libsrc-all dcmwlm-libsrc-all dcmimgle-libsrc-all dcmsr-libsrc-all dcmsign-libsrc-all dcmpstat-libsrc-all dcmimage-libsrc-all dcmjpeg-libsrc-all dcmjpls-libsrc-all
-+libsrc-all:  ofstd-libsrc-all oflog-libsrc-all dcmdata-libsrc-all dcmnet-libsrc-all dcmtls-libsrc-all dcmqrdb-libsrc-all dcmwlm-libsrc-all dcmimgle-libsrc-all dcmsr-libsrc-all dcmsign-libsrc-all dcmpstat-libsrc-all dcmimage-libsrc-all dcmjpeg-libsrc-all dcmjpls-libsrc-all
- 
--install:  config-install ofstd-install oflog-install dcmdata-install dcmtls-install dcmnet-install dcmqrdb-install dcmwlm-install dcmimgle-install dcmsr-install dcmsign-install dcmpstat-install dcmimage-install dcmjpeg-install dcmjpls-install dcmtk-install-doc install-man
-+install:  config-install ofstd-install oflog-install dcmdata-install dcmnet-install dcmtls-install dcmqrdb-install dcmwlm-install dcmimgle-install dcmsr-install dcmsign-install dcmpstat-install dcmimage-install dcmjpeg-install dcmjpls-install dcmtk-install-doc install-man
- 
- install-all: install install-lib install-html
- 
--install-bin:  config-install-bin ofstd-install-bin oflog-install-bin dcmdata-install-bin dcmtls-install-bin dcmnet-install-bin

Bug#695565: unblock: dicomscope/3.6.0-10

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dicomscope

Please unblock dicomscope. This will fix an underlinking issue: 
http://bugs.debian.org/694846
Patch is:
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/dicomscope/trunk/debian/patches/fixbug694846.patch?view=markup
thanks

unblock dicomscope/3.6.0-10

-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121210081842.17351.42892.report...@lirispat.univ-lyon1.fr

Bug#689438: unblock: docbook-slides/3.4.0-5

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package docbook-slides

Please unblock docbook-slides. This will allow the fix to #686516 to move to 
testing. Thanks

unblock docbook-slides/3.4.0-5

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20121002160142.534.47058.report...@lirispat.univ-lyon1.fr

Bug#687384: unblock: docbook-utils/0.6.14-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package docbook-utils

This will allow the fix to 685766 to move to testing. Thanks

unblock docbook-utils/0.6.14-3

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120912104230.9747.55257.report...@lirispat.univ-lyon1.fr

Bug#683625: unblock: docbook-slides/3.4.0-2

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package docbook-slides

Please unblock docbook-slides. This will allow the fix to #683379 to move to 
testing. Thanks

unblock docbook-slides/3.4.0-2

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120802095605.23507.95062.report...@lirispat.univ-lyon1.fr

Bug#683113: unblock: insighttoolkit/3.20.1+git20120521-3

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package insighttoolkit.

Once again, please unblock insighttoolkit. This last upload fixes an issue with 
signalling NaN behavior on gcc 4.7 on i386 platform.
This allowed running successfully the test suite of the plastimatch package 
(and thus fixes symptoms of #645101).
For more details see #682805

Thanks

unblock insighttoolkit/3.20.1+git20120521-3

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120728204532.11354.54080.report...@maester.malat.net

Bug#682990: unblock: gccxml/0.9.0+cvs20120420-4

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package gccxml

It does fix 675181 and once insighttoolkit is fixed will fix all FTBFS of 
wrapitk-python. Thanks.

unblock gccxml/0.9.0+cvs20120420-4

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120727193331.4866.86448.report...@maester.malat.net

Bug#682991: unblock: insighttoolkit/3.20.1+git20120521-2

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock


Please unblock package insighttoolkit

It fixes #667417. This is the last remaining bits to get wrapitk-python to 
build with gcc 4.7.1.

unblock insighttoolkit/3.20.1+git20120521-2

-- System Information:
Debian Release: 6.0.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.39-bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120727193506.4886.38695.report...@maester.malat.net

Bug#682990: unblock: gccxml/0.9.0+cvs20120420-4

[Mathieu Malaterre]

On Fri, Jul 27, 2012 at 11:02 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On Fri, 2012-07-27 at 21:33 +0200, Mathieu Malaterre wrote:
 Please unblock package gccxml

 It does fix 675181 and once insighttoolkit is fixed will fix all FTBFS
 of wrapitk-python. Thanks.

 ++/* GCC 4.2 parser does not support __int128 */

 4.2?

gccxml reads C/C++ headers and dumps XML. The gcc 4.2 parser was never
updated to match latest optimization in 4.x branch.
gccxml really only care about functions prototypes.

2cts
-M


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsw1dnrjfVNV7kC7JvG0fBya4C9y=yqxkwkn+y1_p3f...@mail.gmail.com

unblock gccxml

[Mathieu Malaterre]

Hi,

  I'd like to request an unblock for gccxml 0.9.0+cvs20120420-4. It
does fix 675181.

  Output of debdiff -3/-4 is attached.

Thanks,


gccxml.diff
Description: Binary data

Bug#669348: [Pkg-phototools-devel] Bug#675773: Bug#675773: libopenjpeg2: Please make libopenjpeg2 multi-arch: same

[Mathieu Malaterre]

On Thu, Jun 28, 2012 at 10:46 PM, Michael Gilbert mgilb...@debian.org wrote:
 Can I have a little context here? Why is it important enough to have
 multi-arch openjpeg to do an NMU just before the freeze?

 Hi Michael;

 It seems we need more time to discuss this, so I cancelled the upload
 for now.

 Personally I think it would be better to wait until after the openjpeg5
 transition and then work on multiarchifying the latest version of the
 library, presumably after the freeze.  If there is some urgent reason to
 push through multiarch at this time, I leave you and Mathieu (who is
 an upstream maintainer and the main person interested on the debian
 side) to sort that out.

 The goal was to get multiarch enabled in all of wine's dependencies.
 openjpeg 1.5 is already multiarched, but that has yet to hit unstable.
  There is a lot of apparent brokenness in that transition, so 1.3 may
 be with us for a while:
 http://release.debian.org/transitions/html/openjpeg.html

There is not a single 'brokenness'. openjpeg 1.5 is still in
experimental. It needs a source uploads in unstable and a couple of
deps needs binNMU that is all. API is preserved not ABI that's all.

 The libopenjpeg2 dependency addition is a mistake, and I'll remove that.

 So, I would like to go ahead with the nmu again (with the above
 fixed).  Would that be ok from your perspective?

Well for me working on #669348 would be make so much more sense
(fixing CVEs and tons of bugs), but if you have time for this, go
ahead...



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswakhnd5k+lgpun+7e6cfsrrjhjbv2wqr6z9yypukq...@mail.gmail.com

Bug#669348:

[Mathieu Malaterre]

On Sun, May 20, 2012 at 12:35 PM, Cyril Brulebois k...@debian.org wrote:
 Mathieu Malaterre ma...@debian.org (03/05/2012):
 Just for clarification, openjpeg 1.5.0-2 from experimental is in good
 shape for transition to sid.  blender has been fixed to compile with
 openjpeg 1.5.0

 This is good to know. We're having a gdal transition right now, so
 please wait a bit more to see how it goes, as gdal is also in the
 openjpeg transition.

Let me know if there is still a chance for openjpeg to enter in
transition before freeze. I can help out.

Thanks,



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusy_5szkcpwdwmmyry-dkq71+atwce-id6spbu7ps_x...@mail.gmail.com

Re: Bug#675207: Please binNMU python-ufc against latest swig

[Mathieu Malaterre]

On Mon, Jun 4, 2012 at 2:05 AM, Cyril Brulebois k...@debian.org wrote:
 (Adding the bug report to the loop.)

 Hello,

 Johannes Ring joha...@simula.no (31/05/2012):
 python-ufc needs to be rebuilt against the latest swig (2.0.7). Please
 binNMU it.

   nmu python-ufc_2.0.5-2 . ALL . -m 'Rebuild against swig 2.0.7, see 
 #675207.'

 if this package has such strict dependencies on swig, why aren't they
 exposed through strict package dependencies?

If I may, I believe this is due to: http://bugs.debian.org/674263
Any binary build with swig 2.0.5 or 2.0.6 should be rebuild IMHO.


-- 
Mathieu


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusxx8q2rfldyen9zpwtwnai0ynguu0zxdhdqffe13tv...@mail.gmail.com

Bug#669348:

[Mathieu Malaterre]

Just for clarification, openjpeg 1.5.0-2 from experimental is in good
shape for transition to sid.
blender has been fixed to compile with openjpeg 1.5.0

thanks



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswzwaj1db1mfx2zp1h9s4g8xkdgkwevq2jebcar_ao...@mail.gmail.com

Bug#669348:

[Mathieu Malaterre]

blocked 669348 by 670219
thanks

Only blender fails to rebuild and will need a source-upload for
openjpeg 1.5 transition.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusyolb117uhcdxdhge0znsft2ps-sa907lc0+zk5noi...@mail.gmail.com

Bug#669348: transition: openjpeg

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition


I'd like to request a transition slot for openjpeg 1.5. the main reason for 1.5 
is that it fixes JPEG 2000 support in PDF file, see #659226  #667708

List of impacted packages are:

gpac
gmerlin-avdecoder
poppler
libav
blender
openslide
mupdf
magics++
gdcm
koffice
freeimage

I removed the following from the list, since they do not use openjpeg directly:
ants
itksnap

openjpeg 1.5 has been uploaded to experimental using the default installation 
mecanism which install openjpeg.h into: /usr/include/openjpeg-1.5
a lot of package assumes that openjpeg.h is to be found in /usr/include.

I will therefore add a symlink openjpeg.h - openjpeg-1.5/openjpeg.h when I 
upload to unstable.

Thanks

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120419094745.29286.17699.report...@hpdesk.malat.net

Bug#663681: RM: python-libtiff/0.3.0~svn78-2

[Mathieu Malaterre]

On Sat, Mar 24, 2012 at 10:54 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On Tue, 2012-03-13 at 11:54 +0100, Mathieu Malaterre wrote:
 pylibtiff does not support the new tiff5 package. Please remove pylibtiff 
 from testing.

 That's okay right now.

 See #663490 for information

 That bug seems slightly confused.  It says it is not important it is
 critical since tiff5 entered testing and tiff4 was removed, but
 libtiff4 is still in testing; it's just provided by the tiff3 source
 package now.

Point taken. However I cannot make any sense of the python documentation:
http://docs.python.org/library/ctypes.html#finding-shared-libraries

In my case:

$ python
 import ctypes.util
 lib = ctypes.util.find_library('tiff')
 print lib
libtiff.so.5

where:

$ ls -al /usr/lib/x86_64-linux-gnu/libtiff.so.*  *
lrwxrwxrwx 1 root root 16 Feb 20 14:59
/usr/lib/x86_64-linux-gnu/libtiff.so - libtiff.so.4.3.6
lrwxrwxrwx 1 root root 16 Feb 20 14:59
/usr/lib/x86_64-linux-gnu/libtiff.so.4 - libtiff.so.4.3.6
-rw-r--r-- 1 root root 412208 Feb 20 14:59
/usr/lib/x86_64-linux-gnu/libtiff.so.4.3.6
lrwxrwxrwx 1 root root 16 Feb 20 14:48
/usr/lib/x86_64-linux-gnu/libtiff.so.5 - libtiff.so.5.0.6
-rw-r--r-- 1 root root 462488 Feb 20 14:48
/usr/lib/x86_64-linux-gnu/libtiff.so.5.0.6

I'll need to find some python-guru for that to help me out.

-- 
Mathieu



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuswiunwdfz4y5-_eoc8rdajca02dzupw7uwhrjrudaq...@mail.gmail.com

Bug#663681: RM: python-libtiff/0.3.0~svn78-2

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm


pylibtiff does not support the new tiff5 package. Please remove pylibtiff from 
testing. 

See #663490 for information

Thanks

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120313105406.4322.55691.report...@hpdesk.malat.net

Bug#657288: transition: gdcm

[Mathieu Malaterre]

On Sat, Feb 4, 2012 at 9:10 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 - binNMU insighttoolkit

 I've now scheduled that and will look at scheduling the other packages
 (see http://release.debian.org/transitions/html/gdcm.html) once
 insighttoolkit's done.

excellent !

 igstk is not using gdcm API and thus does not required a rebuild

 What about the other packages which appear to build-depend on gdcm but
 not end up with a run-time dependency?  According to the tracker, that'd
 be ants, itksnap and vtkedge.

I did checked all of them from my sid/schroot and none links to
libgdcm* directly. They do not require a rebuild.

$ readelf -d /usr/lib/libvtkKWEWidgets.so
$ readelf -d /usr/bin/itksnap
$ readelf -d /usr/bin/ANTS

Using ldd I can see gdcm*.so.2.2 appears so this looks ok to me.

Thanks
-- 
Mathieu



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuszupn37ayk8wjn3sox04yaknfzncrgbnugyynqarrp...@mail.gmail.com

Bug#657288: transition: gdcm

[Mathieu Malaterre]

Hi Adam,

On Thu, Feb 2, 2012 at 9:13 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On Wed, 2012-01-25 at 11:13 +0100, Mathieu Malaterre wrote:
 GDCM 2.2.0 introduces a new ABI, as seen on #655783 and al.
 Since API (whatever that means for C++) is preserved, would it be a good 
 time to
 - move gdcm 2.2.0 from experimental to unstable

 Apparently the lack of an explicit no - having waited less than a week
 - was taken as an implicit yes.  That's unfortunate, given that it
 means that the gdcm transition is now tied together with the mono
 transition which we were very close to finishing.

I am truly sorry for any mess I am responsible for.

 I'm hoping that we can resolve that without either having to delay mono
 for a while longer or asking for a temporary reversion to gdcm 2.0.  In
 the meantime, if you wouldn't mind holding off on further uploads of
 gdcm unless any serious issues arise that would be appreciated.

I completely understand your point and I will not upload any new gdcm.
In any case if you decide to revert to gdcm 2.0 watch very carefully
for #657288 since it introduce a change in the API without any SONAME
bump.

I initially made the very first upload of gdcm 2.2 because of #657779,
which I thought would help in the mono transition. I choose to upload
directly 2.2.0 (vs a gdcm 2.0.19) since it clearly state the SONAME
bump and I assume this would make the life of everybody else much
easier. In particular I assumed having gdcm 2.2 would help the ITK4
transition, also debated on debian-release [1].

Anyway thanks for taking the time to answer my request for gdcm transition.

[1] http://lists.debian.org/debian-release/2012/01/msg00650.html

-- 
Mathieu



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsw9+qAgRNottk39rpXi7rRB4xp3=fm9nxwh0k+hqlh...@mail.gmail.com

Re: Plans for ITK version 4

[Mathieu Malaterre]

On Sat, Jan 28, 2012 at 10:43 AM, Steve M. Robbins st...@sumost.ca wrote:
 On Tue, Jan 24, 2012 at 08:38:44AM -0500, Dominique Belhachemi wrote:
 Steve,

 Thanks for all the work.

 It would be good to have ITK4 in 'experimental'. Having coexisting
 packages is nice to have but will cause probably too much trouble
 (especially if we build all the language wrappers again)

 Since it's released, I was planning to upload straight to 'unstable'.
 Do you think there's a need to stage in 'experimental' first?

ITK will be build against gdcm. I would prefer to see gdcm transition
(#657288) to have ended (ie. gdcm 2.2.x into unstable) first.

Thanks
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsw_PWyzTOJky=bfhb_+m3avj51uwfd5jhsupga66c+...@mail.gmail.com

Re: Plans for ITK version 4

[Mathieu Malaterre]

Steve,

On Sat, Jan 28, 2012 at 7:27 PM, Steve M. Robbins st...@sumost.ca wrote:
 On Sat, Jan 28, 2012 at 03:11:18PM +0100, Mathieu Malaterre wrote:

  Since it's released, I was planning to upload straight to 'unstable'.
  Do you think there's a need to stage in 'experimental' first?

 ITK will be build against gdcm. I would prefer to see gdcm transition
 (#657288) to have ended (ie. gdcm 2.2.x into unstable) first.

 I'm not sure what your concern is; can you elaborate?

Just trying to avoir another set of #(655783 655784 655785 655786
655787 655788) because ITK will be build using gdcm 2.0

 ITK 4 builds with the gdcm in unstable so if it builds OK with the new
 gdcm, I don't see it will hinder the latter's transition.

The fact that ITK builds against 2.0 does not mean it builds fine with
2.2 from experimental. I would really like to have feedback on that
combination just as fast as you for ITK

 Moreover, I expect ITK 4 to be undergoing repeated source uploads to
 get it building everywhere (3.20.0 got up to rev -17) so it's likely
 that gdcm 2.2 gets into 'testing' before ITK 4 does for this reason
 alone.

As said above, during this time, people will get another set of RC
bugs identical to #655783 and al.

Can you just do at least one upload to experimental first ?

Thanks,
-- 
Mathieu


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsz-W8=pyfv3bhm2tubp_ecewksaqa-6ogqvbhrfab0...@mail.gmail.com

Bug#657288: transition: gdcm

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition


GDCM 2.2.0 introduces a new ABI, as seen on #655783 and al.
Since API (whatever that means for C++) is preserved, would it be a good time to
- move gdcm 2.2.0 from experimental to unstable
- binNMU insighttoolkit

igstk is not using gdcm API and thus does not required a rebuild

Thanks

-- System Information:
Debian Release: 6.0.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'testing'), (100, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120125101355.18716.9444.report...@hpdesk.malat.net

Bug#649339:

[Mathieu Malaterre]

ref:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649339#33


Please do not remove kwwidgets from testing.
1.Slicer 3.6.x is still a decent viewer even if Slicer 4.x will be
released soon.
2. I need kwwidgets for volview see #640511

Thanks,
-- 
Mathieu



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CA+7wUsxSpjG=_2gyap6y4avwo2xgz1melhymvxgudcfchuq...@mail.gmail.com

Bug#649339:

[Mathieu Malaterre]

On Fri, Dec 9, 2011 at 12:37 PM, Adam D. Barratt
a...@adam-barratt.org.uk wrote:
 On Fri, 9 Dec 2011 12:12:01 +0100, Mathieu Malaterre wrote:

 ref:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649339#33


 Please do not remove kwwidgets from testing.


 It FTBFS and could thus block the transition.  If you're concerned about the
 issue, maybe contribute to getting the FTBFS fixed?

Just to clears things up. I am in discussion with kwwidgets maintainer
and I am providing fix (ATM to be precise) for that. I did not want
the release team to start removing it while on it.

 1.Slicer 3.6.x is still a decent viewer even if Slicer 4.x will be
 released soon.
 2. I need kwwidgets for volview see #640511


 volview appears to not even be in the archive, nor in NEW?  In that case I
 fail to see how the content of testing can possibly be relevant to the
 package.

VolView requires KWWidgets and vtk = 5.8.0 that's the whole issue.


-- 
Mathieu



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusxnchertxed42xrqs+sp+3qvx+kbmupdb1d9eeorbw...@mail.gmail.com

Bug#649339:

[Mathieu Malaterre]

On Fri, Dec 9, 2011 at 1:03 PM, Alexander Reichle-Schmehl
alexan...@schmehl.info wrote:
 Hi!

 Am 09.12.2011 12:49, schrieb Mathieu Malaterre:

 volview appears to not even be in the archive, nor in NEW?  In that case I
 fail to see how the content of testing can possibly be relevant to the
 package.
 VolView requires KWWidgets and vtk = 5.8.0 that's the whole issue.

 Maybe there's a misunderstanding:  The release team removed kxwidgets
 from the _testing_ distribution (aka wheezy) due to an RC bug
 influencing indirectly other packages.

 kvwidgtes is still present in _unstable_ (aka sid), where your package
 once uploaded, will end up.

 In general removals from testing are temporarily; which means:  Once the
 rc bugs are solved (and the package is build on all archs) it can
 migrate back to testing.  (At which point your package could migrate to
 testing, too).

Sorry my bad. I was getting nervous to go through NEW again for a
compilation error.

Thanks for the clarification.
-- 
Mathieu



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wusw4zz1xf1ify_g2rpjc0qf_fa0jb_t8ounovbxzwei...@mail.gmail.com