Dear Maintainer,

When installing openstreetmap-carto-common package (as a dependency of
openstreetmap-carto), the configure step failed after having answered
yes to all the questions (as I remember: "do you want to download the
additionnal resources?" and "What is the name of the database? gis").

Here is the error message from apt install:

Setting up openstreetmap-carto-common (5.7.0-1) ...
INFO:root:Starting load of external data into database
Traceback (most recent call last):
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 405, in <module>
    main()
  File "/usr/share/openstreetmap-carto-common/./get-external-data.py", line 305, in main
    conn = psycopg2.connect(database=database,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/psycopg2/__init__.py", line 122, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.OperationalError: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not exist

dpkg: error processing package openstreetmap-carto-common (--configure):
 installed openstreetmap-carto-common package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of openstreetmap-carto:
 openstreetmap-carto depends on openstreetmap-carto-common; however:
  Package openstreetmap-carto-common is not configured yet.

dpkg: error processing package openstreetmap-carto (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openstreetmap-carto-common
 openstreetmap-carto
E: Sub-process /usr/bin/dpkg returned an error code (1)


It seems indeed that by default the root user does not have access to
PostgreSQL databases, and only postgres user has superuser privileges.
So maybe this script should be run as postgres user.

I'd like to mention that I tried to install this package on an almost
completely fresh install of Debian 12. I followed this tutorial until
the end [1] before noticing that the openstreetmap-carto package was
part of Debian. But I donc think that it was the source of the issue.

[1] https://switch2osm.org/serving-tiles/manually-building-a-tile-server-debian-12/

openstreetmap-carto-common has more issues, it lacks the dependencies
for the get-external-data.py script (python3-{psycopg2,requests,yaml})
causing it to fail in minimal chroot.

I think we should remove the automatic execution of get-external-data.py
in the maintainer scripts and let the user set it up for their
environment. But I'll leave that to josch.

Kind Regards,

Bas

Dear Maintainer,

Dear Maintainer,

I'd also vote for removing the postinst script from
openstreetmap-carto-common. Not just because it currently doesn't work
out-of-the-box, but also because it might not actually be that useful
anymore. The way I understand it, the get-external-data.py script (or
its predecessor) originally downloaded (shape-) files with e.g.
coastlines, extracted them and stored them in a 'data' directory where
they were referenced from the style. So it made sense to run it after
the installation in order to have this data, which is required for
rendering, already downloaded and ready.

However, for a couple versions of the style now, it doesn't store the
files anymore, it imports them into a running PostgreSQL/PostGIS
database where the corresponding tables are then used by the style (in
order to be able to actually render anything, an OSM extract or planet
must be imported into the same database, too). So I guess that this
change in behavior is what actually somewhat broke the postinst script -
originally, no database access was required, but now it is.


Manfred

Since you actually use the package, I suggest you get more involved in its maintenance, I'm just keeping it on life support and have already had it removed from the archive once before because no one was willing and able to fix node-carto until josch needed to scratch that itch.

I was waiting for him to chime in on this issue, but he hasn't touched this package since 2022.

Kind Regards,

Bas

Hi,

Am Thu, Jun 04, 2026 at 07:50:36PM +0200 schrieb Sebastiaan Couwenberg:

I can't really promise much, but I've subscribed to the package on
tracker.debian.org now and set up a watch on the repository in Salsa. If
new bug reports or other issues show up, I will try to take a look and
maybe come up with a fix or analysis/thoughts.

I see that you've removed the maintainer scripts for downloading the
data in Git - thanks for that! Certainly simplifies the package and its
maintenance a bit, too.


Kind regards,
Manfred