Processed: [pythonmagick] FTBFS with new (experimental) imagemagick version
Processing control commands: > tag -1 +upstream Bug #758001 [pythonmagick] [pythonmagick] FTBFS with new (experimental) imagemagick version Added tag(s) upstream. > forwarded -1 > http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26088 Bug #758001 [pythonmagick] [pythonmagick] FTBFS with new (experimental) imagemagick version Set Bug forwarded-to-address to 'http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26088'. > block 740495 by -1 Bug #740495 [release.debian.org] transition: imagemagick 740495 was blocked by: 747857 747907 746228 747908 740495 was not blocking any bugs. Added blocking bug(s) of 740495: 758001 -- 740495: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740495 758001: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758001 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.b.140791849423111.transcr...@bugs.debian.org
Bug#757539: nmu: apertium language packages due to pcre3 update
On Wed, 2014-08-13 at 09:29 +0800, Paul Wise wrote: > On Mon, 2014-08-11 at 14:58 +0100, Julien Cristau wrote: > > > Sounds to me like what's needed is source changes to apertium > > I'll forward the suggestion upstream. Here is my discussion with upstream: http://sourceforge.net/p/apertium/mailman/apertium-stuff/thread/1407894993.23081.31.camel%40chianamo/#msg32711808 -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#756867: transition: gdal
On 08/13/2014 02:41 AM, Julien Cristau wrote: > On Tue, Aug 12, 2014 at 11:41:57 +0200, Sebastiaan Couwenberg wrote: > >> On 08/12/2014 11:26 AM, Emilio Pozuelo Monfort wrote: >>> On 02/08/14 20:41, Bas Couwenberg wrote: Updating GDAL from 1.10.1 to 1.11.0 involves a SONAME bump from libgdal.so.1.17.1 to libgdal.so.1.18.0. Because the binary package name doesn't change, I don't know how to format a Ben file to track this. >>> >>> Err. What? Are you bumping the SONAME without renaming the package? Why? Why >>> isn't the package named after the SONAME as it should be? What am I missing? >> >> Sorry about creating such confusion by badly wording the issue. >> >> The SONAME doesn't change, it remains at libgdal.so.1, only the library >> version changes. >> >> The package is named libgdal1h to differentiate it from its predecessor >> libgdal1 after the reintroduction of internal symbols hiding for better >> compatibility against mixing external geotiff and gdal. >> >> Because the libgdal exposes both C and C++ symbols, its reverse >> dependencies need a rebuild to make sure they continue to work in case >> they don't only use the stable C API but also the unstable C++ API. >> >> Does it make sense to you now? >> > It doesn't to me... You seem to be mixing up API and ABI, so I'm not > sure what you're saying. I think I did that before, and I must admit that ABIs are not my area of expertise. All I know is that we need to rebuild the reverse dependencies for a new GDAL version, even if the SONAME doesn't change. libLAS even needed source changes to support GDAL 1.11.0 (since it uses the unstable C++ interface). README.source in gdal documents the following: " - the C interface is considered stable, but it adds new functions at every new release. - the C++ interface is considered unstable and adds/removes/changes methods at every new minor/major release. That implies both API/ABI changes at every new release, possibly. - both C and C++ APIs coexists in the same library with a unique SONAME (the C one). - the only official API that should be used by all programs is the C one. At the moment this is generally respected, so forcing a library migration should be considered pointless in general. " Since the previous gdal transition was not well coordinated with the release team, I'd like to prevent an uncoordinated upload to unstable this time. Since only binNMUs are required with the updated libLAS in the archive, maybe a transition is the wrong way to go about this, and instead we (the Debian GIS team) should upload GDAL 1.11.0 to unstable when we're ready and request the binNMUs afterward? > Cheers, > Julien Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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/53eb33c0.9090...@xs4all.nl
Re: libquazip transition
Le 12/08/2014 16:02, Andreas Tille a écrit : > Hi Emilio, > > I did the change in SVN but a different problem popped up (failed test > suite) when building the package. We are working on it and will let you > know. Hi, I've commited a small patch of the control/changelog/*headers.install files. All goes fine with a pbuilder sid base with the 0.7-2. Thanks for your help -- Eric Maeker, Debian Med GPG: C217 B1B7 80E8 0381 FD5B C3A5 75D4 AE85 B952 0933 signature.asc Description: OpenPGP digital signature
Bug#755850: Bug#753184: Bug#755850: wheezy-pu: package foremost/1.5.7-5
Hi! On Fri, 2014-07-25 at 13:55:49 -0300, Raúl Benencia wrote: > On Wed, Jul 23, 2014 at 10:59:54PM +0100, Adam D. Barratt wrote: > > Control: tags -1 + confirmed > > > > On Wed, 2014-07-23 at 18:46 -0300, Raúl Benencia wrote: > > > I would like to see foremost 1.5.7-5 in wheezy in order to fix #753184, > > > which is causing a FTBFS. The fix is quite trivial, and it's been in > > > unstable since a couple of weeks. > > > > ... 1.5.7-5~deb7u1 would be fine, using "wheezy" as the upload target > > and assuming the resulting package has been built and tested on a wheezy > > system. > > Attached you'll find a debdiff with these changes. Also, here[0] is the > link to the package DSC. > > [0] > http://mentors.debian.net/debian/pool/main/f/foremost/foremost_1.5.7-5~deb7u1.dsc Thanks, although could you tweak a bit the changelog entry to mention what did the dpkg update break, or in other words what did you had to fix? Otherwise it's not very clear what is going on. Once that's done I'll be uploading the package. > > Please also fix the version metadata for #753184. As Guillem noted, > > re-opening the bug was not necessary. More specifically, it was wrong, > > as you've now told the BTS that the bug is not fixed in any version. > > I've fixed the metadata, thanks for pointing this out. Thanks, and sorry for not checking the BTS myself. :/ > diff -Nru foremost-1.5.7/debian/changelog foremost-1.5.7/debian/changelog > --- foremost-1.5.7/debian/changelog 2012-07-12 10:17:32.0 -0300 > +++ foremost-1.5.7/debian/changelog 2014-07-25 13:06:56.0 -0300 > @@ -1,3 +1,12 @@ > +foremost (1.5.7-5~deb7u1) wheezy; urgency=medium > + > + * Update maintainer email address. > + * Include new VCS control fields. > + * Fix FTBFS caused by dpkg update. Thanks Juhani Numminen. (Closes: > #753184) > + * Bump standards version to 3.9.5, no changes. > + > + -- Raúl Benencia Fri, 25 Jul 2014 12:00:45 -0300 > + > foremost (1.5.7-4) unstable; urgency=low Regards, Guillem -- 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/20140813112142.gd12...@gaara.hadrons.org
Bug#756867: transition: gdal
On Wed, Aug 13, 2014 at 11:45:36 +0200, Sebastiaan Couwenberg wrote:
> All I know is that we need to rebuild the reverse dependencies for a new
> GDAL version, even if the SONAME doesn't change. libLAS even needed
> source changes to support GDAL 1.11.0 (since it uses the unstable C++
> interface).
>
> README.source in gdal documents the following:
>
> "
> - the C interface is considered stable, but it adds new functions at
>every new release.
> - the C++ interface is considered unstable and adds/removes/changes
>methods at every new minor/major release. That implies both API/ABI
>changes at every new release, possibly.
> - both C and C++ APIs coexists in the same library with a unique
>SONAME (the C one).
> - the only official API that should be used by all programs is the C
>one. At the moment this is generally respected, so forcing a library
>migration should be considered pointless in general.
> "
>
OK, I'd suggest something like this:
- add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
1.10.1 or 1.11.0)
- adjust libgdal1h.symbols.* to generate a dep on
libgdal.so.1-${version} for all c++ symbols
That way it's clear from the packaging metadata what uses only the
stable C interface and what uses the unstable C++ one, and we know what
to rebuild. Does that seem plausible?
Cheers,
Julien
signature.asc
Description: Digital signature
Bug#756867: transition: gdal
On 08/13/2014 06:18 PM, Julien Cristau wrote:
> On Wed, Aug 13, 2014 at 11:45:36 +0200, Sebastiaan Couwenberg wrote:
>
>> All I know is that we need to rebuild the reverse dependencies for a new
>> GDAL version, even if the SONAME doesn't change. libLAS even needed
>> source changes to support GDAL 1.11.0 (since it uses the unstable C++
>> interface).
>>
>> README.source in gdal documents the following:
>>
>> "
>> - the C interface is considered stable, but it adds new functions at
>>every new release.
>> - the C++ interface is considered unstable and adds/removes/changes
>>methods at every new minor/major release. That implies both API/ABI
>>changes at every new release, possibly.
>> - both C and C++ APIs coexists in the same library with a unique
>>SONAME (the C one).
>> - the only official API that should be used by all programs is the C
>>one. At the moment this is generally respected, so forcing a library
>>migration should be considered pointless in general.
>> "
>>
> OK, I'd suggest something like this:
> - add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
> 1.10.1 or 1.11.0)
> - adjust libgdal1h.symbols.* to generate a dep on
> libgdal.so.1-${version} for all c++ symbols
>
> That way it's clear from the packaging metadata what uses only the
> stable C interface and what uses the unstable C++ one, and we know what
> to rebuild. Does that seem plausible?
Thanks for the helpful suggestion, it sounds like a nice solution.
I'll have a look at implementing it.
> Cheers,
> Julien
Kind Regards,
Bas
--
GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--
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/53eb9775.8020...@xs4all.nl
Bug#756867: transition: gdal
On 13/08/14 18:51, Sebastiaan Couwenberg wrote:
> On 08/13/2014 06:18 PM, Julien Cristau wrote:
>> On Wed, Aug 13, 2014 at 11:45:36 +0200, Sebastiaan Couwenberg wrote:
>>
>>> All I know is that we need to rebuild the reverse dependencies for a new
>>> GDAL version, even if the SONAME doesn't change. libLAS even needed
>>> source changes to support GDAL 1.11.0 (since it uses the unstable C++
>>> interface).
>>>
>>> README.source in gdal documents the following:
>>>
>>> "
>>> - the C interface is considered stable, but it adds new functions at
>>>every new release.
>>> - the C++ interface is considered unstable and adds/removes/changes
>>>methods at every new minor/major release. That implies both API/ABI
>>>changes at every new release, possibly.
>>> - both C and C++ APIs coexists in the same library with a unique
>>>SONAME (the C one).
>>> - the only official API that should be used by all programs is the C
>>>one. At the moment this is generally respected, so forcing a library
>>>migration should be considered pointless in general.
>>> "
>>>
>> OK, I'd suggest something like this:
>> - add Provides: libgdal.so.1-${version} to libgdal1h (${version} being
>> 1.10.1 or 1.11.0)
>> - adjust libgdal1h.symbols.* to generate a dep on
>> libgdal.so.1-${version} for all c++ symbols
>>
>> That way it's clear from the packaging metadata what uses only the
>> stable C interface and what uses the unstable C++ one, and we know what
>> to rebuild. Does that seem plausible?
>
> Thanks for the helpful suggestion, it sounds like a nice solution.
Indeed. That sounds somewhat similar to what qtbase-opensource-src does, with
the Provides: qtbase-abi-5-3-1 (that change whenever the ABI changes).
> I'll have a look at implementing it.
You can probably use dependency-templates on the symbols file, adding a
libgdal-1.10.1 template and making all the c++ symbols have a dependency on it.
See the "Advanced symbols file" on deb-symbols(5).
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/53ebd707.8050...@debian.org
Bug#757917: transition: libav11
On 12/08/14 13:41, Reinhard Tartler wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Hi, > > I would like to upload libav11 to unstable, which requires the > recompilation of any package that links against it. A prerelease for > Libav11 that passes upstream's extensive test suite is currently in > debian/experimental, and I'll make sure that the final release will be > done and uploaded before jessie freeze. Unlike previous transitions, > this should be less painful compared to Libav10 or Libav9, because > Libav11 maintains full source-code compatibility, cf. to the release > announcement: > > https://libav.org/news.html: > The API remains backward compatible, so no source changes should be > required in the code that works with Libav 10. We note however, that a > number of obsolete APIs remain deprecated and will be removed in the > future. All users are strongly encouraged to update their code. A work > in progress migration guide can be found at our wiki. If you are still > having difficulty after reading the migration guide, please do not > hesitate to file a report in our Bugzilla. We have a special category > for porting issues. > > Proposed ben file: > > Affected: .build-depends ~ > /lib(avcodec|avformat|avutil|device|filter|avresample)-dev/ > Bad: .depends ~ > /lib(avcodec55|avformat55|avutil53|device54|filter4|avresample1)/ > Good: .depends ~ > /lib(avcodec56|avformat56|avutil54|device55|filter5|avresample2)/ There already is https://release.debian.org/transitions/html/auto-libav.html This sounds good in principle, but I would like to hear about the results of a mass-rebuild of the rdeps. Emilio > Moritz, do you still have the infrastructure and/or scripts that you > used for the libav10 test rebuild so that we can verify that > everything still builds with libav11? I can give it a shot but > unlikely before this weekend. If not, maybe someone else would be > willing to fill in? > -- 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/53ebd7b9.1040...@debian.org
Bug#757917: transition: libav11
On Wed, Aug 13, 2014 at 5:25 PM, Emilio Pozuelo Monfort wrote: > > There already is https://release.debian.org/transitions/html/auto-libav.html Lovely! > This sounds good in principle, but I would like to hear about the results of a > mass-rebuild of the rdeps. > OK, I've let me amd64 workstation try to build all packages in jessie listed on the URL above. Here are the results: acoustid-fingerprinter PASS alsa-plugins PASS amarok build deps uninstallable amide PASS aubio PASS audacious-plugins PASS avifile PASS bino FAIL (unrelated to libav, #757280) blender PASS (according to sramacher) cantata PASS chromaprint PASS cmus PASS dff PASS dvbcut PASS ffdiaporama PASS ffmpeg2theora PASS ffmpegthumbnailer PASS ffmpegthumbs PASS ffms2 PASS freerdp PASS fuse-emulator-utils PASS gegl PASS gimp-gap PASS gmerlin-avdecoder PASS gmerlin-encoders PASS gmic PASS gnash PASS goldendict PASS gpac PASS gst-libav1.0 FAIL (fixed in 11~alpha2-1) guvcview PASS handbrake PASS harvid PASS hedgewars PASS idjc PASS jitsi PASS jugglemaster PASS k3b PASS kdenlivePASS kfilemetadata PASS kid3 PASS kino PASS kradio4 PASS lebiniou (using -Werror ?! - easily patchable) libextractor PASS libgroove PASS libomxil-bellagio PASS libphash PASS libpostproc PASS libquicktime PASS lightspark PASS linphone PASS lives PASS lynkeos.app PASS mediatomb PASS mlt PASS moc PASS motion PASS mpd PASS mplayer2 PASS mpv PASS nepomuk-core PASS opal FAIL (unrelated to libav11, cf. #728452) opencv PASS openscenegraph PASS ovito PASS paraview PASS qmmp PASS qutecom PASS shotdetect PASS silan PASS spek PASS squeezelite PASS strigi PASS survex PASS transcode PASS tupi PASS vdr-plugin-xineliboutput PASS vice PASS visp FAIL (unrelated to libav11, cf. #756784) vlc FAIL (silly configure check fail, will sort out with upstream) vtk FAIL (unrelated to libav11, cf. #713794) vtk6 PASS wxsvg PASS x264 PASS xbmc PASS xbmc-pvr-addons PASS xine-lib-1.2 PASS xjadeo PASS xmms2 PASS xpra PASS yorick-av PASS TL;DR summary: gst-libav: will be fixed with a new libav package that I'm about to upload vlc: silly configure check needs to be fixed, I'll sort this out with j-b upstream lebiniou: Compiling with -Werror is silly, can be easily patched 4 further packages FTBFS for reasons unrealated to libav. All in all, it seems to me that upstream is right and Libav11 is source-code compatible to libav10 for practically all packages in jessie. How to proceed from here? -- regards, Reinhard -- 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/caj0ccebtkoas8kyy7ns9dkrkugl9sqow6mrwmxt33a4c_xj...@mail.gmail.com
Re: libquazip transition
Hi Emilio, Version 0.7-2 was uploaded by Andreas and correct the headers package name. See the new queue please. I'll make some ultimate checks on the freemedforms-project source package and will ping Andreas when ready for an upload. Thanks you for your review. Éric Le 12 août 2014 à 16:02, Andreas Tille a écrit : > Hi Emilio, > > I did the change in SVN but a different problem popped up (failed test > suite) when building the package. We are working on it and will let you > know. > > Thanks for your work on the Debian release > >Andreas. > > On Mon, Aug 11, 2014 at 10:21:44PM +0200, Emilio Pozuelo Monfort wrote: >> On 10/08/14 10:13, Eric Maeker wrote: >>> Le 1 août 2014 à 10:44, Emilio Pozuelo Monfort a écrit : >>> > I'll ping you > back for a review of the code. Great, let me know when that's ready. The sooner, the better. >>> >>> Thanks to Andreas, the new package is uploaded with all corrections done. >>> >>> https://ftp-master.debian.org/new/libquazip_0.7-1.html >> >> This is looking better. Given libquazip-dev and libquazip-qt5-dev no longer >> are >> versioned, I don't think it makes sense for libquazip1-headers to be >> versioned. >> But that can probably happen in a future upload, no rush there. >> >> I binNMUed tupi and marble. freemedforms-project needs a sourceful upload to >> update the build dependency to libquazip-dev. Please do that so this >> transition >> can finally finish. >> >> Emilio > > -- > 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/031522c4-3984-41ac-b1a2-ac804e9ba...@gmail.com
