Bug#755094: transition: harfbuzz

2014-07-30 Thread Emilio Pozuelo Monfort 
On 29/07/14 20:37, Julien Cristau wrote:
> On Tue, Jul 29, 2014 at 15:24:58 +0200, أحمد المحمودي wrote:
> 
>>   My question, should I add HB_VERSION_CHECK as it was before 0.9.30 ? 
>>   Or should I add it as an alias for HB_VERSION_ATLEAST ?
>>
> Bring it back with the old implementation, I would say.

Yes.

You can upload it directly to unstable (e.g. 0.9.32-1 with
HB_VERSION_CHECK/hb_version_check added back) with the old package name
(libharfbuzz0b). Then the packages in experimental with the renamed package will
be removed.

Emilio


-- 
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/53d89a2b.8000...@debian.org

Re: libquazip transition

2014-07-30 Thread Eric Maeker 
Le 27/07/2014 13:20, Emilio Pozuelo Monfort a écrit :
> On 26/07/14 22:31, Eric Maeker wrote:
>> Le 26/07/2014 15:36, Emilio Pozuelo Monfort a écrit :
>>> On 26/07/14 11:54, Emilio Pozuelo Monfort wrote:
>>> So I suggest you do the following:
>>>
>>> 1: Rename libquazip1-dev to libquazip-dev.
>>
>> This has been corrected in the v0.6.2-2 of the libquazip package (thanks
>> to Andreas).
> 
> Looking at https://ftp-master.debian.org/new/libquazip_0.6.2-2.html
> 
> I see there's still a libquazip1-dev package, and no libquazip-dev. It looks
> like you have renamed libquazip1-qt5-dev to libquazip-qt5-1-dev. That is still
> versioned. It should be libquazip-qt5-dev, and libquazip-dev. Also you didn't
> add conflicts/replaces.
> 
> Am I missing something?

No. We did add the Provides only.
I'll make all mandatory updates on this package this week. I'll ping you
back for a review of the code.

I'll also create a bug report with lintian:
When a lib source package does not include the soversion, the -dev
package shouldn't too. Currently lintian does not warn users about this.

Thanks for your attentive review.
-- 
Eric Maeker
GPG: C217 B1B7 80E8 0381 FD5B  C3A5 75D4 AE85 B952 0933



signature.asc
Description: OpenPGP digital signature

Bug#756478: transition: openscenegraph

2014-07-30 Thread Alberto Luaces Fernández 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear Release Team,

we are packaging the 3.2.1 stable release of openscenegraph, which is
API-compatible with the current version in Debian, so only binNMUs
should be needed.

Reverse dependencies are:

fgrun
flightgear
libcitygml
osgearth
ossim
qgis
simgear

Can you create a transition for us, please?

Ben file:

title = "openscenegraph";
is_affected = .build-depends ~ /libopenscenegraph-dev|libopenthreads-dev/;
is_good = .depends ~ /libopenscenegraph100|libopenthreads20/;
is_bad = .depends ~ /libopenscenegrap99|libopenthreads14/;

Thank you,

-- 
Alberto


pgpsApBxDwi_2.pgp
Description: PGP signature

Bug#755094: transition: harfbuzz

2014-07-30 Thread أحمد المحمودي 
On Wed, Jul 30, 2014 at 09:09:31AM +0200, Emilio Pozuelo Monfort wrote:
> You can upload it directly to unstable (e.g. 0.9.32-1 with
> HB_VERSION_CHECK/hb_version_check added back) with the old package name
> (libharfbuzz0b). Then the packages in experimental with the renamed package 
> will
> be removed.
---end quoted text---

  Almost done. Should I close this bug with the upload, or shall I leave 
  it open ?

-- 
 ‎أحمد المحمودي (Ahmed El-Mahmoudy)
  Digital design engineer
 GPG KeyID: 0xEDDDA1B7
 GPG Fingerprint: 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: Digital signature

Bug#755094: marked as done (transition: harfbuzz)

2014-07-30 Thread Debian Bug Tracking System 
Your message dated Wed, 30 Jul 2014 12:10:39 +0200
with message-id <53d8c49f.3050...@debian.org>
and subject line Re: Bug#755094: transition: harfbuzz
has caused the Debian Bug report #755094,
regarding transition: harfbuzz
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
755094: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755094
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

 Transition is due to upstream API change: replacement of 
 'hb_version_check' with 'hb_version_atleast'.

 The impacted source packages are:
 webkitgtk
 texlive-bin
 qtbase-opensource-src
 pango1.0
 gnome-font-viewer
 libass
 chromium-browser
 libreoffice

Ben file:

title = "harfbuzz";
is_affected = .depends ~ "libharfbuzz0b" | .depends ~ "libharfbuzz0c";
is_good = .depends ~ "libharfbuzz0c";
is_bad = .depends ~ "libharfbuzz0b";


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

Kernel: Linux 3.13.0-30-generic (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
--- End Message ---
--- Begin Message ---
On 30/07/14 11:49, أحمد المحمودي wrote:
> On Wed, Jul 30, 2014 at 09:09:31AM +0200, Emilio Pozuelo Monfort wrote:
>> You can upload it directly to unstable (e.g. 0.9.32-1 with
>> HB_VERSION_CHECK/hb_version_check added back) with the old package name
>> (libharfbuzz0b). Then the packages in experimental with the renamed package 
>> will
>> be removed.
> 
>   Almost done.

Great!

> Should I close this bug with the upload, or shall I leave it open ?

Closing now as there won't be a transition this time. Feel free to add a note to
the patch or changelog if you want to.

Emilio--- End Message ---

Bug#756508: nmu: twig_1.15.1-1

2014-07-30 Thread Roland Mas 
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"

The twig package was prepared in April, and just passed NEW; in the
meantime, PHP was upgraded in Debian, with a different API.  Hence,
one of the binary packages can't install on sid.  Since the control
file uses a dynamic variable to generate the dependencies on phpapi-*,
I suppose a binNMU would be the normal way to get an installable
package.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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: https://lists.debian.org/20140730125702.29316.60920.reportbug@polymir

Bug#756508: nmu: twig_1.15.1-1

2014-07-30 Thread Daniel Beyer 
Am Mittwoch, den 30.07.2014, 14:57 +0200 schrieb Roland Mas:
> nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"
> 
> The twig package was prepared in April, and just passed NEW; in the
> meantime, PHP was upgraded in Debian, with a different API.  Hence,
> one of the binary packages can't install on sid.  Since the control
> file uses a dynamic variable to generate the dependencies on phpapi-*,
> I suppose a binNMU would be the normal way to get an installable
> package.
> 

Hi,

in the meantime upstream released Twig 1.16.0 and I'm currently updating
the twig packaging. Instead of doing a nmu, may I asked you to upload
the new upstream release for me, since I need a sponsor for it.
I guess I should have it ready in the next few hours.

Thanks
Daniel


signature.asc
Description: This is a digitally signed message part

Bug#756508: nmu: twig_1.15.1-1

2014-07-30 Thread Julien Cristau 
On Wed, Jul 30, 2014 at 14:57:02 +0200, Roland Mas wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"
> 
> The twig package was prepared in April, and just passed NEW; in the
> meantime, PHP was upgraded in Debian, with a different API.  Hence,
> one of the binary packages can't install on sid.  Since the control
> file uses a dynamic variable to generate the dependencies on phpapi-*,
> I suppose a binNMU would be the normal way to get an installable
> package.
> 
If it just got through NEW, I guess you mean s/ALL/amd64/?

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#756508: marked as done (nmu: twig_1.15.1-1)

2014-07-30 Thread Debian Bug Tracking System 
Your message dated Wed, 30 Jul 2014 16:05:26 +0200
with message-id <20140730140526.gd3...@betterave.cristau.org>
and subject line Re: Bug#756508: nmu: twig_1.15.1-1
has caused the Debian Bug report #756508,
regarding nmu: twig_1.15.1-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
756508: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756508
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"

The twig package was prepared in April, and just passed NEW; in the
meantime, PHP was upgraded in Debian, with a different API.  Hence,
one of the binary packages can't install on sid.  Since the control
file uses a dynamic variable to generate the dependencies on phpapi-*,
I suppose a binNMU would be the normal way to get an installable
package.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- End Message ---
--- Begin Message ---
On Wed, Jul 30, 2014 at 14:57:02 +0200, Roland Mas wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"
> 
Scheduled for amd64.

Cheers,
Julien


signature.asc
Description: Digital signature
--- End Message ---

Bug#756508: nmu: twig_1.15.1-1

2014-07-30 Thread Roland Mas 
Daniel Beyer, 2014-07-30 15:23:00 +0200 :

> Am Mittwoch, den 30.07.2014, 14:57 +0200 schrieb Roland Mas:
>> nmu twig_1.15.1-1 . ALL . -m "Rebuild for phpapi-20131226"
>> 
>> The twig package was prepared in April, and just passed NEW; in the
>> meantime, PHP was upgraded in Debian, with a different API.  Hence,
>> one of the binary packages can't install on sid.  Since the control
>> file uses a dynamic variable to generate the dependencies on phpapi-*,
>> I suppose a binNMU would be the normal way to get an installable
>> package.
>> 
>
> Hi,
>
> in the meantime upstream released Twig 1.16.0 and I'm currently updating
> the twig packaging. Instead of doing a nmu, may I asked you to upload
> the new upstream release for me, since I need a sponsor for it.
> I guess I should have it ready in the next few hours.

  Certainly :-)

Roland.
-- 
Roland Mas

If you spit in the air, it lands in your face.
  -- Tevye, in Fiddler on the roof


-- 
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/874mxz6ip5@placard.fr.eu.org

Bug#756508: nmu: twig_1.15.1-1

2014-07-30 Thread Daniel Beyer 
Am Mittwoch, den 30.07.2014, 16:10 +0200 schrieb Roland Mas:
> Daniel Beyer, 2014-07-30 15:23:00 +0200 :
> > 
> > (...)
> >
> > in the meantime upstream released Twig 1.16.0 and I'm currently updating
> > the twig packaging. Instead of doing a nmu, may I asked you to upload
> > the new upstream release for me, since I need a sponsor for it.
> > I guess I should have it ready in the next few hours.
> 
>   Certainly :-)
> 
> Roland.

Hi Roland,

I just uploaded Twig on mentors. You can grab it from here:
http://mentors.debian.net/debian/pool/main/t/twig/twig_1.16.0-1.dsc

Thanks in advance for the upload.
Daniel



signature.asc
Description: This is a digitally signed message part

Bug#755539: transition: hdf5

2014-07-30 Thread Gilles Filippini 
Hi,

Please find an updated status below.

I've filed a few more bugs for fixes to build systems which don't need
any hint about the new hdf5 paths.

I've uploaded a fix for #756108 to DELAYED/2.

I've added a usertag "HDF5-transition" [1] to the bugs related to this
transition, but not for bugs related to useless build depends, because
they're not in our way.

[1]


I'll start tomorrow to file bugs with severity=wishlist + patches for
the other packages.

Please tell me what more could be needed.

I've spent *many* hours these last weeks to prepare this transition
(which is my first one BTW). And I'm committed to spent more hours to
NMU as needed after the transition starts. I would be very disappointed
in case it couldn't happen before the transition freeze.

Thanks,

_g.

= No action required =
cmor
magics++
octave-bim
octave-msh
python-shogun
vtk

= Useless build depends on hdf5 (no action required for transition) =
getdp   #755973
insighttoolkit4 #756015
oasis3  #755681
slepc   #755180

= binNMU required =
armadillo
dolfin
mathgl
nifti2dicom (after vtk6)
nip2(after vips)
ovito   (blocked by #756108)
paraview(blocked by #756108)
shogun
vips(after libmatio)
vtk6(blocked by #756108)

= Fix required - patch proposal ready =
adios
aster
cdo
cmor
code-saturne
dynare
exodusii(#756421)
feel++  (#756435)
flann   (#756471)
gdal
gmsh(#756472)
gnuplot-iostream
gpiv
gpivtools
grads
h5utils
hdf-eos5
jhdf
libcgns
libgpiv
libmatio
libpdl-io-hdf5-perl
libvigraimpex
med-fichier
meep
meep-lam4
meep-mpich2
meep-mpi-default
meep-openmpi
minc
mlpack
mpb
ncl
netcdf
nexus
octave
petsc
pktools
pygpiv
pytables
r-cran-hdf5
ruby-hdfeos5
salome-kernel
scilab
stimfit
syrthes
tessa
xdmf
xmds2
yorick-hdf5

= Depends on the removed hdf5 mpi-posix API =
h5pyeasy to fix - working on a patch
silo-llnl   not so easy but very low popcon (<80)

= Others - Not in testing anyway =
gnudatalanguage FTBFS blocked by plplot
openmeegFTBFS on sid - #730904
plplot  FTBFS on sid - #713309 and more





signature.asc
Description: OpenPGP digital signature

Bug#755539: transition: hdf5

2014-07-30 Thread Emilio Pozuelo Monfort 
On 30/07/14 20:09, Gilles Filippini wrote:
> Hi,
> 
> Please find an updated status below.
> 
> I've filed a few more bugs for fixes to build systems which don't need
> any hint about the new hdf5 paths.
> 
> I've uploaded a fix for #756108 to DELAYED/2.
> 
> I've added a usertag "HDF5-transition" [1] to the bugs related to this
> transition, but not for bugs related to useless build depends, because
> they're not in our way.
> 
> [1]
> 
> 
> I'll start tomorrow to file bugs with severity=wishlist + patches for
> the other packages.
> 
> Please tell me what more could be needed.
> 
> I've spent *many* hours these last weeks to prepare this transition
> (which is my first one BTW). And I'm committed to spent more hours to
> NMU as needed after the transition starts. I would be very disappointed
> in case it couldn't happen before the transition freeze.

To be honest, the big number of packages that need sourceful uploads concerns
me, this close to the freeze. Other RT members have expressed me their concern
as well.

Anyway...

It seems to me like you're entangling two different transitions:

- The new upstream release with a SONAME bump
- The changes to -dev packages to make the co-installable

It seems to me like it's the second one (changes in -dev packages) that requires
so many packages to be patched. Is that right? This is also what you care most
about and what you want to do before the freeze.

Can't you find a way to make the rdeps work with both the current and the new
packages? See e.g. the perl 5.20 transition, where the paths are changing and
the rdeps need fixing, but those fixes are being done *beforehand* and they work
with the old and new perl. Then when the transition starts, we'll only need 
binNMUs.

So if you care so much about this, one possibility would be to forget about the
new upstream release to avoid the SONAME bump, and to get the rdeps fixed
beforehand. After most have been fixed, you change the paths as needed and NMU
the rdeps that didn't get fixed. If I have understood things correctly, no
packages will need binNMUs, so there won't be a transition needed for this. You
just need to file the bugs and at some point do the switch and NMU what's left.

If you file the bugs now at severity important, ping the unfixed bugs in a
month, then in 1.5 or 2 months you change the paths and NMU the rest of the
fixes, you can get this done by mid-October.

Hope what I said makes some sense; it is late and I am tired.

But if you ask me about your current proposal, I'd honestly say it is too late
for jessie.

Emilio


-- 
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/53d97309.4050...@debian.org