Looks like gpg-2.0.0 is failing to build for docker using the 3.14.7
python version with alpine
3.24.

Following GPG files/packages are installed:

  #7 1.217 ( 3/29) Installing libgpg-error (1.61-r0)
  #7 1.247 ( 7/29) Installing gnupg-gpgconf (2.4.9-r1)
  #7 1.330 (19/29) Installing gnupg-dirmngr (2.4.9-r1)
  #7 1.337 (20/29) Installing gnupg-keyboxd (2.4.9-r1)
  #7 1.341 (21/29) Installing gpg (2.4.9-r1)
  #7 1.350 (22/29) Installing gpg-agent (2.4.9-r1)
  #7 1.358 (23/29) Installing gpgsm (2.4.9-r1)
  #7 1.366 (24/29) Installing gpgme (2.0.1-r1)

  #8 2.929 (41/87) Installing libgpg-error-dev (1.61-r0)
  #8 2.938 (43/87) Installing gpgme-dev (2.0.1-r1)

error from build of gpg-2.0.0  (warnings about license expression etc
not included):

job run at:#13 17.29   Building wheel for gpg (pyproject.toml): started
#13 19.43   Building wheel for gpg (pyproject.toml): finished with
status 'error'
#13 19.43   error: subprocess-exited-with-error
#13 19.43   
#13 19.43   × Building wheel for gpg (pyproject.toml) did not run
successfully.
#13 19.43   │ exit code: 1
#13 19.43   ╰─> [94 lines of output]

#13 19.43       Using gpgme.h from /usr/include/gpgme.h
#13 19.43       running build_ext
#13 19.43       building 'gpg._gpgme' extension
#13 19.43       swigging build/gpgme.i to build/gpgme_wrap.c
#13 19.43       swig -python -threads -Ibuild -outdir build/lib.linux-
x86_64-cpython-314/gpg -o build/gpgme_wrap.c build/gpgme.i

#13 19.43       build/gpgme.h:536: Warning 451: Setting a const char *
variable may leak memory.
#13 19.43       gcc -fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3
-Wall -fPIC -Ibuild -I/tmp/pip-install-bp091a21/
gpg_f9e25a413b0c41478590db1d8e5ea335 -I/usr/local/include/python3.14 -c
build/gpgme_wrap.c -o build/temp.linux-x86_64-cpython-314/build/
gpgme_wrap.o
#13 19.43       build/gpgme_wrap.c: In function '_wrap_gpgme_data_seek':
#13 19.43       build/gpgme_wrap.c:4085:14: error: implicit declaration
of function 'PyInt_Check'; did you mean 'PySet_Check'? [-Wimplicit-
function-declaration]
#13 19.43        4085 |     else if (PyInt_Check(swig_obj[1]))
#13 19.43             |              ^~~~~~~~~~~
#13 19.43             |              PySet_Check
#13 19.43       build/gpgme_wrap.c:4086:12: error: implicit declaration
of function 'PyInt_AsLong'; did you mean 'PyLong_AsLong'? [-Wimplicit-
function-declaration]
#13 19.43        4086 |     arg2 = PyInt_AsLong(swig_obj[1]);
#13 19.43             |            ^~~~~~~~~~~~
#13 19.43             |            PyLong_AsLong
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_receive_keys_start':
#13 19.43       build/gpgme_wrap.c:33667:18: error: implicit declaration
of function 'PyString_Check'; did you mean 'PyMapping_Check'? [-
Wimplicit-function-declaration]
#13 19.43       33667 |         else if (PyString_Check(o))
#13 19.43             |                  ^~~~~~~~~~~~~~
#13 19.43             |                  PyMapping_Check
#13 19.43       build/gpgme_wrap.c:33668:19: error: implicit declaration
of function 'PyString_AsString' [-Wimplicit-function-declaration]
#13 19.43       33668 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                   ^~~~~~~~~~~~~~~~~
#13 19.43       build/gpgme_wrap.c:33668:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       33668 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_receive_keys':
#13 19.43       build/gpgme_wrap.c:33754:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       33754 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_export_ext_start':
#13 19.43       build/gpgme_wrap.c:34420:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       34420 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_export_ext':
#13 19.43       build/gpgme_wrap.c:34736:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       34736 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_keylist_ext_start':
#13 19.43       build/gpgme_wrap.c:40189:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       40189 |         arg2[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function
'_wrap_gpgme_op_spawn_start':
#13 19.43       build/gpgme_wrap.c:40824:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       40824 |         arg3[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       build/gpgme_wrap.c: In function '_wrap_gpgme_op_spawn':
#13 19.43       build/gpgme_wrap.c:40969:17: error: assignment to 'char
*' from 'int' makes pointer from integer without a cast [-Wint-
conversion]
#13 19.43       40969 |         arg3[i] = PyString_AsString(o);
#13 19.43             |                 ^
#13 19.43       error: Command '['gcc', '-fno-strict-overflow', '-Wsign-
compare', '-DNDEBUG', '-g', '-O3', '-Wall', '-fPIC', '-Ibuild', '-I/tmp/
pip-install-bp091a21/gpg_f9e25a413b0c41478590db1d8e5ea335', '-I/usr/
local/include/python3.14', '-c', 'build/gpgme_wrap.c', '-o', 'build/
temp.linux-x86_64-cpython-314/build/gpgme_wrap.o']' returned non-zero
exit status 1.
#13 19.43       [end of output]

Any ideas? Has the API changed?

Full run at:

https://github.com/roundup-tracker/roundup/actions/runs/33657195767/
job/100338574413#step:3:1289

> Any ideas? Has the API changed?

I do not know, but we'll inquire.

First result is that the following patch will fix the build problem for the Dockerfile,
but we have not found out what caused the issue in the first place.
And we also do not know, if this is the correct fix.
Tests still fail afterwards.

(Analysis done by Christian Funke.)

diff -r c4db6e2ccc5e scripts/Docker/Dockerfile
--- a/scripts/Docker/Dockerfile Wed Sep 02 12:46:01 2026 -0400
+++ b/scripts/Docker/Dockerfile Fri Sep 04 16:49:02 2026 +0200
@@ -128,6 +128,7 @@
 #   modules not installed in the base library.
 # ignore warnings from pip to use virtualenv
 COPY scripts/Docker/requirements.txt .
+RUN pip install setuptools && pip install gpg --no-build-isolation
 RUN pip install --no-cache-dir -r requirements.txt
 
 # copy the elements of the release directory to the docker image

Ber said:

> And we also do not know, if this is the correct fix.
> Tests still fail afterwards.

I assume you run the roundup test suite inside the docker container?
Are the pgp tests from the test suite failing, or are other tests
failing?

-- rouilj

The tests were run in the docker container from stage 1 (the big one that builds stuff), not the final roundup one.


=========================== short test summary info ============================
FAILED test/test_demo.py::TestDemo::testDemoClassic - SystemExit: 2
FAILED test/test_demo.py::TestDemo::testDemoJinja - SystemExit: 2
FAILED test/test_demo.py::TestDemo::testDemoMinimal - SystemExit: 2
FAILED test/test_sqlite.py::sqliteSpecialActionTestCase::testInnerMain - redi...
FAILED test/test_sqlite.py::sqliteSessionTest::testBadTimestamp - redis.excep...
FAILED test/test_sqlite.py::sqliteSessionTest::testClear - redis.exceptions.C...
FAILED test/test_sqlite.py::sqliteSessionTest::testDataTypes - redis.exceptio...
FAILED test/test_sqlite.py::sqliteSessionTest::testDbType - AssertionError: '...
FAILED test/test_sqlite.py::sqliteSessionTest::testDestroy - redis.exceptions...
FAILED test/test_sqlite.py::sqliteSessionTest::testGetAll - redis.exceptions....
FAILED test/test_sqlite.py::sqliteSessionTest::testGetGetAllMissingKey - redi...
FAILED test/test_sqlite.py::sqliteSessionTest::testGetUniqueKey - redis.excep...
FAILED test/test_sqlite.py::sqliteSessionTest::testLifetime - AssertionError:...
FAILED test/test_sqlite.py::sqliteSessionTest::testList - redis.exceptions.Co...
FAILED test/test_sqlite.py::sqliteSessionTest::testSetSession - redis.excepti...
FAILED test/test_sqlite.py::sqliteSessionTest::testUpdateSession - redis.exce...
FAILED test/test_sqlite.py::sqliteSessionTest::testUpdateTimestamp - redis.ex...
FAILED test/test_sqlite.py::sqliteSessionTest::testWalMode - AttributeError: ...
===== 18 failed, 1367 passed, 1003 skipped, 1 xfailed in 575.80s (0:09:35) =====

Hi Chris:

tl;dr: If you uninstall redis or build without redis in Docker/
requirements.txt do
       the tests pass?

I'm building a docker container now with test/requirements.txt appended
to scripts/Docker/requirements.txt. I assume you installed the packages
in test/requirements.txt in the docker build to get pytest etc. I don't
think the stage 1 build includes pytest etc.

My first impression issues mentioning redis are ok. IIRC redis tests are
enabled
if the redis module is installed. However if no redis is located at the
configured
path they will fail. That's a test suite bug I should fix if I can
figure out how
to do it.

The two AssertionError and one AttributeError along with the Demo mode
failures
I don't have an explanation for.

========

In my docker container running 'python -m pytest test' with redis
enabled on my
system I get no errors.

Running 'python -v -m pytest test/test_sqlite.py test/test_demo.py' with
redis
shut down, I also get ... no errors. Unexpected given my first
impression.

Running the full test suite with redis shut down using 'pythom -m pytest
test', I get all
the same errors you did except for the 3 demo tests. The redis
connection failures/Session
tests are:

 FAILED test/test_sqlite.py::sqliteSpecialActionTestCase::testInnerMain
- redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testBadTimestamp -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testClear -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testDataTypes -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testDestroy -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testGetAll -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testGetGetAllMissingKey
- redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused. 
 FAILED test/test_sqlite.py::sqliteSessionTest::testGetUniqueKey -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testList -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testSetSession -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testUpdateSession -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.
 FAILED test/test_sqlite.py::sqliteSessionTest::testUpdateTimestamp -
redis.exceptions.ConnectionError: Error 111 connecting to
localhost:6379. Connection refused.

 FAILED test/test_sqlite.py::sqliteSessionTest::testDbType -
AssertionError: 'roundup.backends.sessions_sqlite.Sessions' not found in
'<roundup.backends.sessions_redis.Sessions object at 0x7fcb20f9c0b0>'
 FAILED test/test_sqlite.py::sqliteSessionTest::testLifetime -
AssertionError: 1788628896.575535 not greater than 1789233694.57553
 FAILED test/test_sqlite.py::sqliteSessionTest::testWalMode -
AttributeError: 'Sessions' object has no attribute 'sql'

I think these last three are a side effect of the missing redis server.

If you uninstall redis or build without redis in Docker/requirements.txt
do the tests pass?

I thought I had a fix to skip redis tests if redis module is importable
but the server is not available. But it worked for the
test_redis_session.py test and not the sqlite
tests. I have a feeling something is leaking.


I am still stumped on the demo failures. SystemExit 2 doesn't really
help.

Without redis in scripts/Docker/requirements.txt the result is:

=========================== short test summary info ============================
FAILED test/test_demo.py::TestDemo::testDemoMinimal - SystemExit: 2
FAILED test/test_demo.py::TestDemo::testDemoClassic - SystemExit: 2
FAILED test/test_demo.py::TestDemo::testDemoJinja - SystemExit: 2
FAILED test/test_cgi.py::FormTestCase::testTokenlessCsrfProtection - IndexErr...
FAILED test/test_cgi.py::TemplateUtilsTestCase::testExpandfile - IndexError: ...
====== 5 failed, 1388 passed, 999 skipped, 1 xfailed in 634.97s (0:10:34) ======

that is doing the following:
using the build container
pip install -r test/requirement.txt
python -m pytest test

Hi Chris:

I can't reproduce this using the current development version nor the 2.6
released on pypi
using the stage 2 docker image.

I am using:

  docker build -t roundup-app -f scripts/Docker/Dockerfile --build-
arg=source=pypi .

(or without --build-arg to use the current dev release inside an hg
checkout).
with the Dockerfile changed to include the pip command earlier on this
ticket that allows
pgp to be installed. Also scripts/Docker/requirements.txt has the redis
package commented out.

Then I am running the docker image roundup-app using:

   docker run -it -v $PWD:/mnt roundup-app shell

where PWD is the root of the mercurial checkout repo.

At the shell I type:

  cd /mnt
  python -m pip install -r test/requirements.txt
  python -m pytest test

and all tests pass.

= 1407 passed, 956 skipped, 4 xfailed, 26 subtests passed in 419.84s
(0:06:59) =

Also I have shut down mysql and postgresql to more closely match your
environment.
Given all the skipped test I assume those processes aren't running.

I am not sure what is happening to cause your testing to fail.

How you are stopping the build at stage 1 so you can get a shell?
What is the reason you are not using the stage 2 production image?

Can you paste the full errors not just the truncated summary error
messages.
I have seen an instance of the:

  FAILED test/test_cgi.py::TemplateUtilsTestCase::testExpandfile -
IndexError: ...

error when pdb was used or some tests were skipped. If it's the same
cause, the logging
subsystem is not properly configured to capture logger log messages.
Checking
the log capture output by index fails. But I have never seen it with a
complete test
run top to bottom.

-- rouilj

> Then I am running the docker image roundup-app using:
>   docker run -it -v $PWD:/mnt roundup-app shell
> where PWD is the root of the mercurial checkout repo.
> At the shell I type:
>  cd /mnt
>  python -m pip install -r test/requirements.txt
>  python -m pytest test
> and all tests pass.
> = 1407 passed, 956 skipped, 4 xfailed, 26 subtests passed in 419.84s
(0:06:59) =

What I did in a hg clone is:
```
docker build -t roundup-local -f scripts/Docker/Dockerfile .
docker container run --rm -it -v .:/mnt roundup-local shell
cd /mnt
python -m pip install -r test/requirements.txt
python -m pytest test
```

hg diff says:
```
hg diff
diff -r ed1e6e000097 scripts/Docker/Dockerfile
--- a/scripts/Docker/Dockerfile Sat Sep 12 21:29:03 2026 +0000
+++ b/scripts/Docker/Dockerfile Thu Sep 17 10:49:01 2026 +0200
@@ -128,6 +128,7 @@
 #   modules not installed in the base library.
 # ignore warnings from pip to use virtualenv
 COPY scripts/Docker/requirements.txt .
+RUN pip install --no-cache-dir setuptools && pip install --no-cache-dir --no-build-isolation gpg
 RUN pip install --no-cache-dir -r requirements.txt
 
 # copy the elements of the release directory to the docker image
```

However I am getting the following result:
```
=========================== 18 failed, 1390 passed, 992 skipped, 4 xfailed, 3 warnings, 26 subtests passed in 615.44s (0:10:15) ============================
```

> How you are stopping the build at stage 1 so you can get a shell?
When I did that I had the original Dockerfile cut after the install requirements bit where it tried to install gpg, to debug the issue. As such I had a container like that around.

> What is the reason you are not using the stage 2 production image?
I am now. When I didn't it was just easier to get into an interactive shell that way.

> Can you paste the full errors not just the truncated summary error
messages.

See the attachment for a full output of a run.

It looks like there are a few issues with the Docker container.

In the test output I see for test: anydbmAdminTest.testInitWithConfig_ini

  PermissionError: [Errno 13] Permission denied: 
'/mnt/share/roundup/templates/classic/config_ini.ini'

Huh. Is share/roundup/templates/classic a read only directory?
I see permission denied for other paths including __pycache__ (in the warnings output)
and roundup/test/memorydb.py.dummy. Any idea why the paths getting permission denied
can't be written?

I have to admit this is odd. It's possible there is a UID mismatch. But, I would expect a lot 
more permission failures if the uid was mismatched. What is your UID? The docker container 
builds as UID 1000. If your uid isn't 1000, you need to build using the --build-
arg="roundup_uid=3000" replacing 3000 with your uid. But as I said this is unlikely to be
the issue.

Also it looks like redis is still built into the docker container as I see failures raised
from:

  /usr/local/lib/python3.14/site-packages/redis/connection.py
  and a timestamp failure that I think happens when the test tried to use redis

Can you rebuild without redis (remove/comment it out of scripts/Docker/requirements.txt) and 
run the tests again. Hopefully that will only leave the 3 or so permission denied failures.

You can run just one of them using:

  python -m pytest --pdb -k testInitWithConfig_ini test

and see if you can figure out why you are getting permission denied when it tries to create 
the share/roundup/templates/classic/config.ini file. You can also try touching that file
from the docker shell and see if you can touch it or if you get an error.

I'm on a 16 hour shift tomorrow, so won't be back at the computer till Saturday.

Hope this helps.

-- rouilj

I have fixed the permission issues which were just due to the setup I was using.

Without redis installed there are now just 4 xfailures:

XFAIL test/test_anydbm.py::anydbmDBTest::testEmptyCreate - Create class w/o key field and no properties is undefined.
XFAIL test/test_mailgw.py::MailgwTestCase::testEmailQuotingRemove3 - OK: sig not removed - delim not first section line
XFAIL test/test_memorydb.py::memorydbDBTest::testEmptyCreate - Create class w/o key field and no properties is undefined.
XFAIL test/test_sqlite.py::sqliteDBTest::testEmptyCreate - Create class w/o key field and no properties is undefined.
= 1407 passed, 993 skipped, 4 xfailed, 1 warning, 26 subtests passed in 628.36s (0:10:28) =

Hi Chris:

> Without redis installed there are now just 4 xfailures:

Those are expected failures. So the tests all pass.

My open questions are:

  1) We are using:

    pip install setuptools && pip install gpg --no-build-isolation

  do you have any idea what changed to require a new setuptools to be
installed?

  My assumption is that whatever setuptools version is in use in the
newest docker
  image is newer than or the same as a prior docker image where gpg
2.0.0 built ok.

  What does --no-build-isolation (NBI) do in this case? I am not
installing into a virtual
  environment where I thought that was a useful flag. Does NBI prevent
gpg from building
  in a virtual environment where it could be missing some components?

  2) Do we expect the install to work in a venv?

  The docker image as it currently exists does not install/run Roundup
in a venv. However,
  I have been experimenting with installing Roundup and its supporting
modules in a venv.
  The base image sometimes has older versions of packages installed.
While a newer release
  of the base image fixed this, I was using a newer version of these
packages on the
  older base image and just hoped I didn't break any tools. By
installing in a venv I isolate
  upgraded packages from the base image. Also I am adopting venv as the
standard way to install
  Roundup. By using a venv in the Docker container I hope to reduce the
documentation needed
  for other layouts by ignoring them 8-).

Thanks for your help on this.

-- rouilj

> pip install setuptools && pip install gpg --no-build-isolation
> do you have any idea what changed to require a new setuptools to be installed?
> My assumption is that whatever setuptools version is in use in the newest docker
> image is newer than or the same as a prior docker image where gpg 2.0.0 built ok.

The sole reason that setuptools is installed is because setuptools is required to build / install gpg.

I would think it's reasonable to assume that setuptools is newer now than whenever it was last built successfully. However it is not the cause for the failure, since setuptools are installed as the first thing anyway in the scripts/Docker/requirements.txt (setuptools >= 78.1.1)

> What does --no-build-isolation (NBI) do in this case? I am not installing into a virtual
> environment where I thought that was a useful flag. Does NBI prevent gpg from building
> in a virtual environment where it could be missing some components?

I am not exactly sure why but it fixes the build. It does however not work without it without the flag.
My best guess is that it would use some incompatible version from the isolated environment. With the flag I assume it is using the system provided environment that is compatible.

> 2) Do we expect the install to work in a venv?
> The docker image as it currently exists does not install/run Roundup in a venv. However, I have been experimenting with installing Roundup and its supporting modules in a venv.
> The base image sometimes has older versions of packages installed. While a newer release of the base image fixed this, I was using a newer version of these packages on the
> older base image and just hoped I didn't break any tools. By installing in a venv I isolate upgraded packages from the base image. Also I am adopting venv as the standard way to install
> Roundup. By using a venv in the Docker container I hope to reduce the documentation needed for other layouts by ignoring them 8-).

I have no idea about roundup, however I can say that gpg install fails the same way and has the same fix (using --no-build-isolation) in a python virtual environment.

Reworked the Dockerfile a bit.

Now requirements.txt is installed first and includes
setuptools >= 78.1.1, so removed explicit setuptools install
from pip install gpg command line. Added --no-build-isolation to pip 
command to install gpg. Also added --no-cache-dir to gpg install
get newest version.

fix in changeset:   8825:95448795dbd4

Thanks Chris and Bern for the fix.

Issue 2551430 opened because the license settings in gpg's
build config will cause build issues starting feb 2027.