Looks like britney needs some help to migrate everything to testing. The
update_output.txt shows most rdeps, I can't make sense of why it's not
migrating them.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
On 1/17/20 3:04 PM, Bas Couwenberg wrote:
> In preparation of the netcdf transition as test rebuild of your package was
> done which FTBFS:
>
> makeinfo -I. gri.texi
> utf8 "\xF3" does not map to Unicode at
> /usr/share/texinfo/Texinfo/ParserNonXS.pm line 1796, line 19280.
> Malformed
On 1/17/20 11:05 AM, Bas Couwenberg wrote:
> In preparation of the netcdf-fortran transition as test rebuild of your
> package was done which FTBFS:
>
> make doc
> make[4]: Entering directory
> '/build/oasis3-3.mct+dfsg.121022/lib/mct/doc/texsrc'
> perl ../../protex/protex -b
Control: tags -1 pending
On 1/17/20 7:28 PM, Sebastiaan Couwenberg wrote:
> Thanks for reporting this issue, I've forwarded it upstream.
Upstream has committed a fix which has been included as a patch in the
package. It won't be uploaded before the ongoing transition is complete.
Kind Rega
Control: tags -1 upstream
Control: forwarded -1 https://github.com/OSGeo/gdal/issues/2173
Hi Mattia,
Thanks for reporting this issue, I've forwarded it upstream.
If upstream is unable to resolve this issue soon, I'll look into it
myself. Or we'll just have to make do without libxml2 support in
Control: tags -1 upstream
Control: forwarded -1 https://github.com/qgis/QGIS/issues/33743
This is an upstream issue with crssync which should not create these
directories by default.
Follow up in the upstream issue.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182
On 1/11/20 9:48 PM, Paul Gevers wrote:
> gdal triggers autopkgtest regressions in two packages and looking at the
> logs I am wondering if that point to a missing dependency relation, as
> the tests pass in unstable once they were binNMU'ed.
>
> In both tests, libgdal20 from testing is installed
On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>
>> Please schedule the binNMUs.
>
> Thanks for scheduling the initial batch, eve
On 1/10/20 11:06 PM, Sebastiaan Couwenberg wrote:
> On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
>> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>>
>>> Please schedule
ncl (6.6.2-1+b2) FTBFS on mips64el as part of the gdal transition, the
log shows a compiler segfault, retrying the build likely fixes that:
gb ncl_6.6.2-1 . mips64el . -m "Rebuild against libgdal26"
I tried using the self-service but that returns a Forbidden error:
You don't have permission
On 1/9/20 6:52 PM, Sebastiaan Couwenberg wrote:
> On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>>
>> Please schedule the binNMUs.
>
> Thanks for scheduling the initial batch, eve
On 1/8/20 4:53 PM, Sebastiaan Couwenberg wrote:
> gdal (3.0.2+dfsg-1) is now built & installed on all release architectures.
>
> Please schedule the binNMUs.
Thanks for scheduling the initial batch, everything has built now.
Please schedule the rest of Dependency level 1.
Kind
On 1/8/20 5:48 AM, Sebastiaan Couwenberg wrote:
> On 1/8/20 5:31 AM, Sebastiaan Couwenberg wrote:
>> On 1/7/20 10:21 PM, Paul Gevers wrote:
>>> I hinted libvigraimpex just now, once it migrates, please go ahead.
>>
>> Today GDAL 3.0.3RC1 will be released, it'
On 1/8/20 5:31 AM, Sebastiaan Couwenberg wrote:
> On 1/7/20 10:21 PM, Paul Gevers wrote:
>> I hinted libvigraimpex just now, once it migrates, please go ahead.
>
> Today GDAL 3.0.3RC1 will be released, it's probably a good idea to wait
> for its final release, likely a week
On 1/7/20 10:21 PM, Paul Gevers wrote:
> On 24-11-2019 08:44, Sebastiaan Couwenberg wrote:
>> Let's see what happens first: this, or the QGIS 3.10.4 release which
>> makes use of GDAL 3 features.
>
> So, did the release of QGIS 3.10.4 or higher already happened?
No, it's s
On 1/2/20 11:58 PM, Thorsten Alteholz wrote:
> CODE_OF_CONDUCT.md not accounted for in d/copyright (it's CC-BY-4.0).
You really had to dig for that one.
> Copyright for docs/auth.html wrong, and the file seems to be generated
> from auth.md -- can you confirm we can regenerate it with tools
On 1/2/20 9:07 PM, Samuel Thibault wrote:
> Sebastiaan Couwenberg, le jeu. 02 janv. 2020 20:51:43 +0100, a ecrit:
>> Is there a particular reason you want to build gdal on hppa, hurd &
>> kfreebsd? Is it blocking any important packages?
>
> It is directly blocking vario
Control: tags -1 wontfix moreinfo
Hi Samuel,
Thanks for the patch, but as long as the Architecture field doesn't
support excludes like Build-Depends I'm not willing to apply it.
Experience with mapnik has shown that maintaining the list of
architectures manually is a PITA.
I'd rather not have
On 12/31/19 4:20 PM, Andreas Metzler wrote:
> as Bas correctly diagnoses I am not currently building for all supported
> versions but only for the default one because it is not trivial but
> requires some work. Looking at python policy I think that is acceptable
> but not perfect.
>
> Is my
On 12/30/19 9:48 PM, Paul Gevers wrote:
> On 27-12-2019 18:08, Andreas Metzler wrote:
>> On 2019-12-26 Paul Gevers wrote:
>>> On 25-12-2019 19:29, Andreas Metzler wrote:
libvigraimpex is marked for autoremoval because of the python2 removal.
This is fixed in experimental, the new
Control: tags -1 moreinfo
On 12/23/19 10:01 PM, Andreas Beckmann wrote:
> python3-geopandas ships files with generic names at the generic location
> /usr/lib/python3/dist-packages/examples/ causing file clashes (e.g. on
> README.txt) with other packages doing the same wrong thing.
> Moving this
On 12/8/19 7:15 PM, Joachim Reichel wrote:
> openemsbinNMU would be sufficient, unrelated FTBFS
>(#946264), but not on autoremoval list (WHY?)
RC bug report is too young.
"
Packages which have RC bugs that are present in both testing and
unstable, and which have no
Control: reopen -1
On 12/7/19 8:45 AM, Debian Bug Tracking System wrote:
> We believe that the bug you reported is now fixed; the following
> package(s) have been removed from unstable:
>
> libsfcgal-dev |1.3.7-2 | armhf
>
> --- Reason ---
> ROM; Architecture
On 12/8/19 7:17 PM, Joachim Reichel wrote:
> On 08.12.19 17:45, Bas Couwenberg wrote:
>> While looking into the postgis FTBFS with the rebuild sfcal, I noticed that
>> cgal still uses the libgmp10-dev virtual package instead of libgmp-dev.
>
> looks like I missed some memo ... Am I right that
On 12/6/19 2:34 PM, Joachim Reichel wrote:
> sfcgal fixed by maintainer, but armhf and mips64el still missing
It built fine on mips64el, armhf is a new. RM bug: #946261
> pprepair FTBFS, no patch known (#944775), autoremoval in 13 days
> prepairFTBFS, no patch known
Control: tags -1 pending
Hi Joachim,
On 12/5/19 10:22 PM, Joachim Reichel wrote:
> the transition to CGAL 5.0 started (see bug #944417) and your package FTBFS. I
> intend to NMU the package with the attached diff to DELAYED/5-day.
Thanks for the patch. There is no need for an NMU, I've uploaded
Control: tags -1 pending
On 12/3/19 6:04 AM, Helmut Grohne wrote:
> On Tue, Dec 03, 2019 at 05:39:44AM +0100, Sebastiaan Couwenberg wrote:
>>> I have less clue about shapely. I couldn't identify the actual use. Is
>>> it really needed?
>>
>> It's used in example
Control: tags -1 moreinfo
On 12/2/19 9:38 PM, Helmut Grohne wrote:
> pyosmium cannot satisfy its cross Build-Depends. There are multiple
> reasons for that. The ones reported by botch[1] are mainly sphinx and
> mock, but also shapely.
pyosmium is a leaf package, does it really matter that cannot
Control: tags -1 ftbfs
On 12/2/19 7:36 PM, Bas Couwenberg wrote:
> The autopkgtest for your package are failing which block testing migration of
> its dependencies.
>
> The log shows:
>
> ==
> FAIL:
Control: tags -1 ftbfs
On 12/2/19 7:34 PM, Bas Couwenberg wrote:
> The autopkgtest for your package are failing which block testing migration of
> its dependencies.
>
> The log shows:
>
> ==
> FAIL: test_custom
On 11/23/19 10:15 PM, Paul Gevers wrote:
> On 08-11-2019 06:43, Sebastiaan Couwenberg wrote:
>> python-networkx is finally fixed, please remove the block to let gdal
>> migrate to testing, and let's move on with this transition.
>
> python-networkx doesn't want to
Control: tags -1 pending
On 11/22/19 9:33 AM, Alex Bachmer wrote:
> Solution: *$ sudo head -n 1 /usr/lib/nagios/plugins/check_haproxy_stats**
> **#!/usr/bin/perl*
Fixed in git, thanks!
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750
Control: tags -1 pending
On 11/20/19 11:21 AM, Matthias Klose wrote:
> the update to dask 2.8 requires test suite adjustments, taken from the 0.18.1
> upstream release.
>
> patch at
> http://launchpadlibrarian.net/452265984/satpy_0.16.1-3_0.16.1-3ubuntu1.diff.gz
Thanks for the patch, it's
Control: tags -1 upstream
Control: forwarded -1 https://github.com/OSGeo/gdal/issues/2030
Hi Witold,
This is not something to be fixed by the package maintainer, so I've
forwarded it upstream. You should follow up there.
Note the following from their issue template:
"
The GDAL project is made
Control: tags -1 pending
On 11/17/19 7:39 PM, Pirate Praveen wrote:
> This package fail to build with protobuf 3.10.1 in experimental with the
> following failure.
Because the java code needs to be regenerated with protoc 3.10.
> Please fix this failure so we can upload protobuf 3.10 to
These are low popcon packages with an academic upstream, if upstream is
unable to provide a fix in a timely manner I will have these packages
removed from Debian.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Theses bugs (#897756, #897775, #906230) are preventing testing migration
of insighttoolkit4 (4.13.2-dfsg1-1) because the fixed version is not
included in its changelog history.
If these bugs are also fixed in 4.13.2-dfsg1-1 the BTS fixed versions
need to be updated to reflect that.
Kind Regards,
There seems to be an issue with debci, both postgis & pgsql-ogr-fdw are
marked as a regression in the excuses, but when looking at debci itself
for both testing and unstable the tests are passing.
The previous failure was when postgres-12 was the new default, but the
package hadn't been rebuilt
On Thu, 31 Oct 2019 09:33:31 +0100 Bas Couwenberg
wrote:
> On 2019-10-31 09:21, Paul Gevers wrote:
> > On Fri, 18 Oct 2019 11:46:25 +0200 Bas Couwenberg
> > wrote:
> >> Please remove icinga from the archive, it's EOL upstream and
> >> superceded by icinga2.
> >
> > I may be wrong, but it seems
Control: severity -1 serious
On 10/1/19 7:16 PM, Sebastiaan Couwenberg wrote:
> On 8/30/19 10:20 AM, Sebastiaan Couwenberg wrote:
>> gdal (3.0.1+dfsg-1~exp3) dropped support for Python 2 and no longer
>> builds python-gdal.
>
> The next upload of GDAL 2.4.x will also drop
severity -1 serious
This package depends on python-networkx which in turn depends on
python-gdal which is no longer built since gdal (2.4.3+dfsg-1)
Kind Regards,
Bas
On 10/26/19 10:19 AM, Dmitry Shachnev wrote:
> Thanks for fixing this! Unfortunately it still FTBFS on mipsel. Do you know
> what could cause this?
My gut says it just inherent to the arch, mips* tends to be problematic.
I don't know how to fix the "Error: branch out of range" issues, so I'll
Control: tags -1 pending
On 10/25/19 6:59 PM, Matthias Klose wrote:
> fiona ftbfs when building for multiple python3 versions, patch at
> http://launchpadlibrarian.net/448415280/fiona_1.8.9-1_1.8.9-1ubuntu1.diff.gz
Thanks for the patch, it's applied in git and a new upload to unstable
will
Control: tags -1 pending
The python3-all-dev build dependency has been removed.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 pending
On 10/24/19 9:36 PM, Olly Betts wrote:
> However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
> your package has a build-dependency on libwxgtk3.0-dev which doesn't
> result in any shlib dependencies in the built packages. If this package
> is not
Control: tags -1 pending
On 10/24/19 9:24 PM, Olly Betts wrote:
> However, checking "dak rm -Rn -b libwxgtk3.0-dev" on coccia I see that
> your package has a build-dependency on libwxgtk3.0-dev which doesn't
> result in any shlib dependencies in the built packages. If this package
> is not
Control: tags -1 confirmed
On 10/23/19 4:34 PM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Your package FTBFS while rebuilding it against Qt 5.12.5, although from the
> build log
> I can not tell for sure if the problem lies in Qt itself.
I know, and I'm waiting for pyqt5 (5.12.3+dfsg-3) to
On 10/18/19 3:14 PM, Ansgar wrote:
> On Fri, 2019-10-18 at 14:22 +0200, Sebastiaan Couwenberg wrote:
>> On 10/18/19 2:11 PM, Bastian Blank wrote:
>>> On Fri, Oct 18, 2019 at 01:53:22PM +0200, Bas Couwenberg wrote:
>>>> Please remove icinga2 from armel, mips6
On 10/18/19 3:07 PM, Bastian Blank wrote:
> On Fri, Oct 18, 2019 at 02:22:17PM +0200, Sebastiaan Couwenberg wrote:
>> On 10/18/19 2:11 PM, Bastian Blank wrote:
>>> On Fri, Oct 18, 2019 at 01:53:22PM +0200, Bas Couwenberg wrote:
>>>> Please remove icinga2 from a
On 10/18/19 2:11 PM, Bastian Blank wrote:
> On Fri, Oct 18, 2019 at 01:53:22PM +0200, Bas Couwenberg wrote:
>> Please remove icinga2 from armel, mips64el, mipsel & s390x to unblock
>> testing migration due to missing builds.
>
> Those builds fail with different errors. Please handle them
On 10/12/19 1:06 PM, Alberto Luaces Fernández wrote:
>> See `dak rm -Rn openscenegraph-3.4` on mirror.ftp-master.debian.org.
>
> If somebody can do it, I would be grateful. I am a DM and I lack the required
> permissions.
See the attachment for the dak output.
I suggest to first update
On 10/12/19 12:44 PM, Alberto Luaces Fernández wrote:
> Hi, openscenegraph-3.4 can be removed from the archive safely.
Its reverse dependencies need to be dealt with first:
* flightgear
* openmw
* osgearth
* simgear
See `dak rm -Rn openscenegraph-3.4` on mirror.ftp-master.debian.org.
Once
On 10/1/19 11:08 PM, Sandro Tosi wrote:
> On Tue, Oct 1, 2019 at 1:21 PM Sebastiaan Couwenberg
> wrote:
>>
>> On 8/30/19 10:20 AM, Sebastiaan Couwenberg wrote:
>>> gdal (3.0.1+dfsg-1~exp3) dropped support for Python 2 and no longer
>>> builds python-gdal.
On 8/30/19 10:20 AM, Sebastiaan Couwenberg wrote:
> gdal (3.0.1+dfsg-1~exp3) dropped support for Python 2 and no longer
> builds python-gdal.
The next upload of GDAL 2.4.x will also drop support for Python 2 and no
longer build python-gdal.
Kind Regards,
Bas
--
GPG Key ID:
On 9/17/19 2:41 PM, Sandro Tosi wrote:
> While it's true we are trying to remove python 2 from Debian
> (https://wiki.debian.org/Python/2Removal), this shouldnt be done while
> reverse dependencies are still present in the archive (quoting from
> the previous link "NOTE: If there are reverse
Control: tags -1 pending
On 9/19/19 6:06 PM, Holger Levsen wrote:
> Please drop the transitional package libsaga (from the source package saga)
> for
> bullseye, as it has been released with stretch and buster already.
Fixed in git.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Control: tags -1 pending
Hi Helmut,
Thanks for the patch, it's applied in git and will be included in the
next upload.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: fixed -1 qgis/3.4.12+dfsg-1~exp1
On 9/4/19 12:53 PM, Sebastiaan Couwenberg wrote:
>> There may be changes for PROJ 6 in upcoming QGIS 3.4.x releases, but
>> full support will take some time until we upgrade to the 3.10 LTR in
>> early 2020.
This was fixed
block 932679 by 932197 938330 938307 937262 937258
block 932679 by 937145 936503 936704 936285
thanks
On 9/17/19 6:05 AM, Sandro Tosi wrote:
> thanks for the heads up, but please note python-networkx has still
> planty of reverse-dependencies, so we cannot drop that package yet.
> please dont
On 9/10/19 8:11 AM, Sebastiaan Couwenberg wrote:
> libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
> be removed from testing due to gnudatalanguage, which I don't
> understand. But this should be resolved when the package get autoremoved
> on the 14th.
gnu
Hi Scott,
Thanks for finally reviewing pywps.
On 9/13/19 5:23 PM, Scott Kitterman wrote:
> One of our ftp-trainees reviewed your package and made the following
> observations.
It seems that the process is broken.
This is far from the first time where an anonymous ftp-trainee commented
on a
libgeotiff (1.5.1-2) is in testing, but libgeotiff-dfsg (1.4.3-1) cannot
be removed from testing due to gnudatalanguage, which I don't
understand. But this should be resolved when the package get autoremoved
on the 14th.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint:
Control: tags -1 pending
Control: severity -1 normal
On 9/8/19 5:37 AM, Sandro Tosi wrote:
> There's an on-going effort to remove Python 2 from Bullseye,
> https://wiki.debian.org/Python/2Removal, so it would be useful if you could
> remove all python2 modules dependencies from your tasks and/or
On 9/4/19 8:53 PM, Paul Gevers wrote:
> On 04-09-2019 20:21, Bas Couwenberg wrote:
>> nmu cloudcompare_2.10.3-3 . ANY . unstable . -m "Rebuild with libpdal-dev
>> 2.0.1"
>
> Scheduled.
Thanks!
> You'll handle grass and python-pdal yourself?
Yes, both have just been uploaded to unstable as
Control: tags -1 pending
Control: forwarded -1 https://github.com/OSGeo/libgeotiff/issues/22
On 9/4/19 3:38 PM, Peter Michael Green wrote:
>> diff testlistgeo_out with testlistgeo_out.dist
>> --- testlistgeo_out 2019-09-04 06:58:26.979704475 +
>> +++ ../test/testlistgeo_out.dist
On 9/4/19 12:58 PM, Christoph Berg wrote:
> Re: Sebastiaan Couwenberg 2019-09-04
>
>> Not much we can do about this. PROJ 6 just migrated to testing and we'll
>> need to update a lot more of the stack to get them to support it fully.
>
> Oh, if that's just a transient t
On 9/4/19 12:48 PM, Sebastiaan Couwenberg wrote:
> On 9/4/19 12:18 PM, Christoph Berg wrote:
>> while upgrading my bullseye system:
>>
>> workrave (1.10.34-2+b1) wird eingerichtet ...
>> qgis-providers (3.4.11+dfsg-1) wird eingerichtet ...
>> proj_create: crs not
On 9/2/19 11:12 AM, Sebastiaan Couwenberg wrote:
> On 9/2/19 10:43 AM, Emilio Pozuelo Monfort wrote:
>> There's also an autopkgtest regression for r-cran-sf as you can see in the
>> excuses at https://packages.qa.debian.org/p/proj.html. That's blocking proj
>> from
>>
proj (6.2.0-1) & python-pyproj (2.3.1+ds-1) are now in unstable.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
On 9/2/19 10:43 AM, Emilio Pozuelo Monfort wrote:
> There's also an autopkgtest regression for r-cran-sf as you can see in the
> excuses at https://packages.qa.debian.org/p/proj.html. That's blocking proj
> from
> being a migration candidate.
That's why I filed #939002.
There is also the
On 9/1/19 7:44 PM, Antonio Valentino wrote:
> It seems that the problem can be fixed by upgrading pyproj to v2.3.1
> (see [2]).
> I made a quick test with python3-pyproj 2.3.1+ds-1~exp1 (available in
> experimental) and I can confirm that all tests pass now.
>
> I'm going to add a versioned
On 8/31/19 7:14 PM, Sebastiaan Couwenberg wrote:
>> I'm going to reassign.
>
> That doesn't seem appropriate, pyresample needs to be updated too. It
> does things like this:
>
> pyresample/test/test_geometry.py:
> projections = {'+init=epsg:3006': 'ini
On 9/1/19 12:33 PM, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Wed, 2019-08-28 at 14:16 +0200, Bas Couwenberg wrote:
>> python3-mapproxy fails to serve GetCapabilities requests as reported
>> in
>> #935887, this is fixed by including an upstream patch.
>>
>
> I assume the patch
On 8/31/19 6:58 PM, Antonio Valentino wrote:
> it seems to me that the issue is in basemap rather then pyresample.
basemap most likely also needs to be updated to support PROJ 6
correctly, as pretty much everything using PROJ should.
> As far as I can understand it has been already fixed [1,2]
Control: block -1 by 932677 932679 932683
The scripts in the python-gdal package have moved to the python3-gdal
package since 2.5.0~beta1+dfsg-1~exp1, all subsequent releases are still
in experimental pending a transition (which is blocked by the ongoing
proj transition).
There are a few rdeps
gdal (3.0.1+dfsg-1~exp3) dropped support for Python 2 and no longer
builds python-gdal.
Your package will break when the transition to gdal 3.x starts.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
On 8/28/19 6:05 AM, Sebastiaan Couwenberg wrote:
> On 8/26/19 5:42 AM, Sebastiaan Couwenberg wrote:
>> On 8/25/19 4:31 PM, Sebastiaan Couwenberg wrote:
>>> On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
>>>> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg w
On 8/26/19 5:42 AM, Sebastiaan Couwenberg wrote:
> On 8/25/19 4:31 PM, Sebastiaan Couwenberg wrote:
>> On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
>>> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
>>>> For the Debian GIS team I'
On 8/27/19 9:53 PM, Marek Lukács wrote:
> at the moment I do not have good sandbox for playing with packaging. But I
> have checked the source package of mapproxy_1.11.0-3 (Debian Buster apt).
It's easy to setup a cowbuild chroot, see:
vtk6 is failing to build with the new proj in unstable as part of the
transition. Please move the fixed packages from experimental to unstable.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 - moreinfo
Control: severity -1 important
I've installed mapproxy on a test server with stretch, it contains the
symlinks as well:
# find /usr/lib/python2.7/dist-packages/mapproxy/ -type l -exec ls -l {} \;
lrwxrwxrwx 1 root root 73 Jan 7 2018
On 8/25/19 4:31 PM, Sebastiaan Couwenberg wrote:
> On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
>> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
>>> For the Debian GIS team I'd like to transition to PROJ 6.
>>>
>>> This is a major change
On 8/25/19 3:22 PM, Jonathan Wiltshire wrote:
> On Fri, Jul 12, 2019 at 09:39:26PM +0200, Bas Couwenberg wrote:
>> For the Debian GIS team I'd like to transition to PROJ 6.
>>
>> This is a major change that affects the wider GIS ecosystem, with proj
>> being at the bottom of the dependency chain.
Control: severity -1 serious
The proj transition has started, raising severity accordingly.
Kind Regards,
bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 pending
On 8/24/19 3:51 PM, Andreas Beckmann wrote:
> dpkg: error processing archive
> /tmp/apt-dpkg-install-g8AHYp/010-qgis_3.4.10+dfsg-1_amd64.deb (--unpack):
>trying to overwrite
> '/usr/share/icons/hicolor/128x128/mimetypes/qgis-mime.png', which is also in
> package
On 8/19/19 5:27 PM, Sandro Tosi wrote:
> So, what do you want me to do? drop the python 2 package for basemap?
Yes.
> i cant do that, it has reverse dependencies (just like pyproj)
basemap is the only remaining rdep for python-pyproj, as it also for
python-shp & python-netcdf4.
pyspread is the
Control: severity -1 serious
On 7/21/19 11:00 AM, Bas Couwenberg wrote:
> pyproj upstream is going to drop support for Python 2 in the near
> future. The python-pyproj package will no longer be built then too.
pyproj 2.3.0 has been released and drops support for Python 2.
The next upload of
On Sat, 23 Sep 2017 11:47:59 +0200 "Manuel A. Fernandez Montecelo" wrote:
> This package will be removed after rdeps migrate to openscenegraph-3.4 or a
> later version (which does support Qt5), or rdeps are removed, or if nothing
> else, when the removal of Qt4 happens.
>
> (We plan to poke
The only qt4 rdeps remaining are:
* odin (#875065)
* qsapecng (#875138)
Gudjon, please remove the qt4 support from qwt to fix this issue, and
leave those two packages (which have their own RC bugs) to be fixed (or
removed) at a later time.
Kind Regards,
Bas
--
GPG Key ID:
On Sun, 10 Sep 2017 10:33:46 -0300 Lisandro Damián Nicanor Pérez Meyer
wrote:
> On 10 September 2017 at 03:25, Andreas Tille wrote:
> > libquazip builds both Qt4 and Qt5 interface. I could simply drop the
> > Qt4 interface to fix this bug by breaking nomacs and freemedforms build.
>
> I would
Control: tags -1 pending
Already fixed in git by renaming the doc-base document. Upload to
unstable fill follow soon.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 pending
The packaging in git has been updated.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 pending
The packaging in git has been updated.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Control: tags -1 - moreinfo
On 7/21/19 11:03 PM, Scott Kitterman wrote:
> On Sun, 14 Jul 2019 09:03:38 +0200 Bas Couwenberg wrote:
>> Package: ftp.debian.org
>> Severity: normal
>> Control: block -1 by 932020
>>
>> Please remove liblas from the archive, it's dead upstream, has
>> outstanding
On 7/23/19 8:45 PM, Mark Jeffcoat wrote:
> The first symptom I noticed was in psql, complaining that
> > create extension postgis;
> ERROR: could not open extension control file
> "/usr/share/postgresql/11/extension/postgis.control": No such file or
> directory
>
>
> I believe
On 7/23/19 7:17 PM, Herbert Fortes wrote:
> Can you detail more what is wrong?
See: https://ci.debian.net/packages/g/gphoto2/testing/amd64/
And the log files linked from there.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D
Hi Elena,
On Fri, 7 Jun 2019 09:21:22 +0200 Elena ``of Valhalla'' wrote:
> Of course after the release the severity can be raised back, as then it
> would apply to the majority of users indeed (but I'd just upload the
> new version of the package and be done with it).
With the buster release and
Hi Graham,
Thanks for the additional info.
On 7/20/19 9:41 PM, Graham Inggs wrote:
> On Sat, 20 Jul 2019 at 20:50, Sebastiaan Couwenberg
> wrote:
>> python-xarray 0.12.1-2 migrated to testing on 2019-07-16, so it's
>> available in testing again.
>
> Yes, src:python-xar
Control: tags -1 pending
Hi Chiara,
Thanks for your work on the FITS driver and clarifying the license issue.
The CFITSIO support has been re-enabled in the gdal package and will be
included in the next upload. Note that it has only been enabled on the
experimental branch for GDAL 3.x, I don't
On 7/13/19 9:11 AM, Sebastiaan Couwenberg wrote:
> On 7/13/19 8:25 AM, Sergey B Kirpichev wrote:
>> On Sun, 7 Jul 2019 08:29:08 +0200 Sebastiaan Couwenberg
>> wrote:
>>> Please upload a new revision to unstable with source-only changes...
>>
>> Backport for B
901 - 1000 of 2329 matches
Mail list logo
