newer
dovecot-2.4.2 lua5-1 build failure

dovecot_config_version 2.4.2 -> error

older
USER_PASSWORD environment variable

Genes Lists

30 Oct 2025 30 Oct '25

12:43 p.m.

I would expect this to track the current version (i.e. 2.4.2) - would be good to accept 2.4.2 and later versions as they are released:

doveconf line 9: Invalid dovecot_config_version: Currently supported versions are: 2.4.0 2.4.1 0.0.0

-- Gene

Attachments:

signature.asc (application/pgp-signature — 228 bytes)

Show replies by date

Aki Tuomi

30 Oct 30 Oct

12:50 p.m.

...

On 30/10/2025 14:43 EET Genes Lists via dovecot <dovecot@dovecot.org> wrote:

Hi

I would expect this to track the current version (i.e. 2.4.2) - would be good to accept 2.4.2 and later versions as they are released:

doveconf line 9: Invalid dovecot_config_version: Currently supported versions are: 2.4.0 2.4.1 0.0.0

-- Gene

This seems to work for me.

2.4.2-1+debian12 (0962ed2104): /etc/dovecot/dovecot.conf

Pigeonhole version 2.4.2-1+debian12 (767418c3)

dovecot_config_version = 2.4.2

Aki

Genes Lists

1:27 p.m.

On Thu, 2025-10-30 at 14:50 +0200, Aki Tuomi via dovecot wrote:

...

This seems to work for me.

2.4.2-1+debian12 (0962ed2104): /etc/dovecot/dovecot.conf

Pigeonhole version 2.4.2-1+debian12 (767418c3)

dovecot_config_version = 2.4.2

Was a build of git HEAD - stable 2.4.2 works fine - will do scratch build of git head as should behave the same! Sorry for noise - must be my own issue somehow.

thanks and apologies.

-- Gene

On Thu, 2025-10-30 at 14:50 +0200, Aki Tuomi via dovecot wrote:

 This seems to work for me.
 # 2.4.2-1+debian12 (0962ed2104): /etc/dovecot/dovecot.conf
 # Pigeonhole version 2.4.2-1+debian12 (767418c3)
 dovecot_config_version = 2.4.2

Was a build of git HEAD - stable 2.4.2 works fine - will do scratch build of git head as should behave the same! Sorry for noise - must be my own issue somehow. thanks and apologies.

Gene

Genes Lists

1:48 p.m.

On Thu, 2025-10-30 at 09:27 -0400, Genes Lists via dovecot wrote:

...

On Thu, 2025-10-30 at 14:50 +0200, Aki Tuomi via dovecot wrote:

...
This seems to work for me.

2.4.2-1+debian12 (0962ed2104): /etc/dovecot/dovecot.conf

Pigeonhole version 2.4.2-1+debian12 (767418c3)

dovecot_config_version = 2.4.2

Was a build of git HEAD - stable 2.4.2 works fine - will do scratch build

Fresh build of git HEAD (branch=main) is not aware of the 2.4.2 config for some reason. Release branch works fine.

Maybe there is a 'trick' to doing build of HEAD on git main ?

-- Gene

On Thu, 2025-10-30 at 09:27 -0400, Genes Lists via dovecot wrote:

 On Thu, 2025-10-30 at 14:50 +0200, Aki Tuomi via dovecot wrote:

   This seems to work for me.
   # 2.4.2-1+debian12 (0962ed2104): /etc/dovecot/dovecot.conf
   # Pigeonhole version 2.4.2-1+debian12 (767418c3)
   dovecot_config_version = 2.4.2

    Was a build of git HEAD - stable 2.4.2 works fine - will do scratch
 build

Fresh build of git HEAD (branch=main) is not aware of the 2.4.2 config for some reason. Release branch works fine. Maybe there is a 'trick' to doing build of HEAD on git main ?

Gene

pgnd

1:56 p.m.

note, given @ https://github.com/dovecot/core/blob/main/build-aux/git-abi-version-gen

...
if test "${VERSION:-}" != ""; then
  :
elif test -f version; then &lt;---------------
  VERSION="`cat version`"
elif test -e .git; then &lt;---------------
  VERSION="0.0.0"
else
  echo "Cannot determine version number">&2
  exit 1
fi

mangle_version $VERSION

assumes either .git or version exists

if in your workflow you pull a tarball of git head

mkdir -p tmp/
cd tmp/
wget -O main.tar.gz https://github.com/dovecot/core/tarball/main
tar xvf main.tar.gz
cd dovecot*

there's NO

ls -ald .git version
	ls: cannot access '.git': No such file or directory
	ls: cannot access 'version': No such file or directory

which will cause the fail

a local workaround is

_this_release_base="2.4.2"

or

_this_release_base="0.0.0"

then

echo ${_this_release_base} > version
echo ${_this_release_base%.*}.ABIv${_this_release_base##*.} > abi-version

you'll need to do it for pigeonhole if building, as well

Genes Lists

2:33 p.m.

On Thu, 2025-10-30 at 09:56 -0400, pgnd via dovecot wrote:

...

note, given @ https://github.com/dovecot/core/blob/main/build- aux/git-abi-version-gen

... if test "${VERSION:-}" != ""; then : elif test -f version; then <--------------- VERSION="cat version" elif test -e .git; then <--------------- VERSION="0.0.0" That is super helpful. My cas pulls from git and so ".git" is indeed present.

I see the file "version" is used in both build-aux/git-version-gen and git-abi-version-gen which are used in configure. But I don't see the file "abi-version" being used?

I will modify our work flow after the git fetch; git pull to extract the last release version from git and put it into the file(s) as you suggested.

The last version can be found for example using:

git tag -l '[0-9]\.[0-9]*' --sort=v:refname | tail -1

The script build-aux/git-version-gen could be changed to report 2.4.2-xxx+yyy-dirty instead of 0.0.0-xxx+yyy-dirty which would get written to the "version" file.

however even in that case git-abi-version-gen misses the case statement and reports abi versin as 0.0.0.ABIv0 instead of 2.4.ABIv2 as happens when version file contains just "2.4.2".

In summary, best I can tell, if I simply put the last tagged release into the version file (without any commit hash etc) it will do something reasonable and thereafter recognize our test configs using 2.4.2 config version.

Unless there is a better way.

thanks!

-- Gene

Aki Tuomi

2:50 p.m.

...

On 30/10/2025 16:33 EET Genes Lists via dovecot <dovecot@dovecot.org> wrote:

On Thu, 2025-10-30 at 09:56 -0400, pgnd via dovecot wrote:

...
note, given @ https://github.com/dovecot/core/blob/main/build- aux/git-abi-version-gen

... if test "${VERSION:-}" != ""; then : elif test -f version; then <--------------- VERSION="cat version" elif test -e .git; then <--------------- VERSION="0.0.0" That is super helpful. My cas pulls from git and so ".git" is indeed present.

I see the file "version" is used in both build-aux/git-version-gen and git-abi-version-gen which are used in configure. But I don't see the file "abi-version" being used?

I will modify our work flow after the git fetch; git pull to extract the last release version from git and put it into the file(s) as you suggested.

The last version can be found for example using:

git tag -l '[0-9]\.[0-9]*' --sort=v:refname | tail -1

The script build-aux/git-version-gen could be changed to report 2.4.2-xxx+yyy-dirty instead of 0.0.0-xxx+yyy-dirty which would get written to the "version" file.

however even in that case git-abi-version-gen misses the case statement and reports abi versin as 0.0.0.ABIv0 instead of 2.4.ABIv2 as happens when version file contains just "2.4.2".

In summary, best I can tell, if I simply put the last tagged release into the version file (without any commit hash etc) it will do something reasonable and thereafter recognize our test configs using 2.4.2 config version.

Unless there is a better way.

thanks!

-- Gene

the version file should be present in tag 2.4.2 and in release-2.4.2 branch.

Aki

Genes Lists

3:33 p.m.

On Thu, 2025-10-30 at 16:50 +0200, Aki Tuomi via dovecot wrote:

...

...
...

the version file should be present in tag 2.4.2 and in release- 2.4.2 branch.

Aki

Yep it is, it's just not there in git head.

Is there a good reason not to keep version file in HEAD as well?

As suggested by @pgnd, I will create version file with last tag before running configure. Seems like that is all that is needed.

thanks all.

-- Gene

pgnd

3:51 p.m.

...

I will create version file with last tag before running configure. Seems like that is all that is needed. this

git tag -l '[0-9]\.[0-9]*'  --sort=v:refname | tail -1

of course works IF your source is in a git repo

fwiw, in the git-less tarball rpm-build case, i use

curl -s 'https://api.github.com/repos/dovecot/core/tags' | jq -r '.[].name' | grep -E '^[0-9]+\.[0-9]+' | sort -V | tail -n1

a spec.

kludgy! but WORKSFORME

Aki Tuomi

4:51 p.m.

...

On 30/10/2025 17:33 EET Genes Lists via dovecot <dovecot@dovecot.org> wrote:

On Thu, 2025-10-30 at 16:50 +0200, Aki Tuomi via dovecot wrote:

...
...
...

the version file should be present in tag 2.4.2 and in release- 2.4.2 branch.

Aki

Yep it is, it's just not there in git head.

Is there a good reason not to keep version file in HEAD as well?

As suggested by @pgnd, I will create version file with last tag before running configure. Seems like that is all that is needed.

thanks all.

-- Gene

main branch (git HEAD) is considered v0.0.0. For various reasons. Release branches contain version file and builds with 2.4.2 as version.

If you wish to build 2.4.2 from main HEAD, you can pretend it's 2.4.2 by using VERSION envvar, or creating the version file yourself, but it's still going to be something else than 2.4.2.

Aki

Genes Lists

5:15 p.m.

On Thu, 2025-10-30 at 18:51 +0200, Aki Tuomi via dovecot wrote:

...

main branch (git HEAD) is considered v0.0.0. For various reasons. Release branches contain version file and builds with 2.4.2 as version.

If you wish to build 2.4.2 from main HEAD, you can pretend it's 2.4.2 by using VERSION envvar, or creating the version file yourself, but it's still going to be something else than 2.4.2.

Thanks Aki - we're using git head builds for testing, so they need to work and not barf on standard configs from current release version 😄

If there is a better content for "version" than simply '2.4.2', I'd be happy to use it - provided things work on standard current configs.

thanks again.

Gene

Aki Tuomi

5:32 p.m.

...

On 30/10/2025 19:15 EET Genes Lists via dovecot <dovecot@dovecot.org> wrote:

On Thu, 2025-10-30 at 18:51 +0200, Aki Tuomi via dovecot wrote:

...
main branch (git HEAD) is considered v0.0.0. For various reasons. Release branches contain version file and builds with 2.4.2 as version.

If you wish to build 2.4.2 from main HEAD, you can pretend it's 2.4.2 by using VERSION envvar, or creating the version file yourself, but it's still going to be something else than 2.4.2.

Thanks Aki - we're using git head builds for testing, so they need to work and not barf on standard configs from current release version 😄

If there is a better content for "version" than simply '2.4.2', I'd be happy to use it - provided things work on standard current configs.

thanks again.

Gene

Just don't generate version file, and use dovecot_config_version = 0.0.0. This means same as "latest". Which is one of the reason main is 0.0.0, so that you don't build from main and falsely think it's release version.

Aki

Genes Lists

5:48 p.m.

On Thu, 2025-10-30 at 19:32 +0200, Aki Tuomi via dovecot wrote:

...

...
Just don't generate version file, and use dovecot_config_version = 0.0.0. This means same as "latest". Which is one of the reason main is 0.0.0, so that you don't build from main and falsely think it's release version.

Aki

Thanks - certainly can change the test configs to use config version 0.0.0 thanks. Good to know it means 'latest'!

We cannot mix up git head build as it is built as a separate package (dovecot-git) which is marked to "conflict" with any released package. So only 1 of dovecot or dovecot-git can be installed, and it's clear which version is installed.

thanks again.

-- Gene

On Thu, 2025-10-30 at 19:32 +0200, Aki Tuomi via dovecot wrote:

 Just don't generate version file, and use `dovecot_config_version =
 0.0.0`. This means same as "latest". Which is one of the reason main is
 0.0.0, so that you don't build from main and falsely think it's release
 version.
 Aki

Thanks - certainly can change the test configs to use config version 0.0.0 thanks. Good to know it means 'latest'! We cannot mix up git head build as it is built as a separate package (dovecot-git) which is marked to "conflict" with any released package. So only 1 of dovecot or dovecot-git can be installed, and it's clear which version is installed. thanks again.

Gene

pgnd

3:06 p.m.

...

something reasonable and thereafter recognize our test configs using 2.4.2 config version. my personal preference when (rpm-)building *test* builds from HEAD is to 'label' the build with closest/latest release tag, AND the build short commit.

e.g.,

dovecot --version
	2.4.2 (65ca73d)
grep "FULL PIGEONHOLE_VERSION" sieve/pigeonhole-version.h
	#define PIGEONHOLE_VERSION_FULL PIGEONHOLE_VERSION" (306b597)"

to reliably track what i've got installed ( well, not _just_ for _test_ builds; upstream release tags can lag way behind ... )

to do that requires (required? i haven't checked latest yet ...) some more tap-dancing

the issue was that when building from tarball (no .git), update-version.sh exits early if build-dir dovecot-version.h already exists, and reports empty "()".

modifying headers sanely something like

cat > dovecot-version.h &lt;&lt;'EOF'
#ifndef DOVECOT_VERSION_H
#define DOVECOT_VERSION_H
#ifndef DOVECOT_REVISION
#define DOVECOT_REVISION "${dovecot_shortcommit)"
#endif
#ifndef DOVECOT_VERSION_FULL
#define DOVECOT_VERSION_FULL VERSION" ("DOVECOT_REVISION")"
#endif
/* lib.c requires this; upstream defaults it to DOVECOT_VERSION_FULL */
#ifndef DOVECOT_BUILD_INFO
#define DOVECOT_BUILD_INFO DOVECOT_VERSION_FULL
#endif
#endif /* DOVECOT_VERSION_H */
EOF

and, similarly -- but not quite! -- for pigeonhole,

autoreconf -I . -fiv
./configure ...

cat > pigeonhole-version.h &lt;&lt;'EOF'
#ifndef PIGEONHOLE_VERSION_H
#define PIGEONHOLE_VERSION_H
#define PIGEONHOLE_VERSION_FULL PIGEONHOLE_VERSION" (${pigeonhole_shortcommit))"
#endif /* PIGEONHOLE_VERSION_H */
EOF

works for now.

Age (days ago)

Last active (days ago)

List overview

13 comments

3 participants

participants (3)

Aki Tuomi
Genes Lists
pgnd