Today's libmongoc-dev update broke kamailio which does not find the
correct include path anymore. I do not see any transition bug that
documents building the reverse dependencies, so this might be the case
for other rdeps as well.

Hi Roberto

I'm not sure if you are aware that your latest upload of mongo-c-driver
basically broke all its reverse dependencies due to it being a major
version bump including a rename of the pkg-config file and also a soname
bump.
It's thus a library transition that should be coordinated with the
release team.

It would be great if you can follow up here how you plan to get the
reverse dependencies updated.

Michael

Hi Michael and Bastian,
Yes, I'm really sorry about that.

I had uploaded 2.x to experimental a little while back (during the
freeze) and in thinking through my plan for uploading to unstable I
completely and entirely forgot to think about reverse dependencies.

At this point, I've already caused the damage (again, apologies for
that), so I think that the best thing is to get some patches sent out.
I'll start working on those ASAP.

Would the release team like to provide any specific guidance that I
should observe here? Or perhaps suggest an alternate approach?

Regards,

Am 18.08.25 um 19:50 schrieb Roberto C. Sánchez:

Thanks Roberto.

Not speaking for the release team here, btw, just a common bystander who
is affected by this change.

I've updated rsyslog to build with both v1 and v2 of mongo-c-driver

https://salsa.debian.org/debian/rsyslog/-/commit/8ea8f59756eccfae4471e7482460e922750f169c

This was basically all I needed to make rsyslog compile against against
v2. Is there more that I need to consider (deprecated APIs etc.), if so,
do you have recommendations, links to a migration guide, etc.

Regards,
Michael

Hi again Michael and Bastian and Release Team,
This morning it was brought to my attention that I was not being
sufficiently responsive to this problem that I've created and that my
communication came across as unconcerned.

Let me be the first to say that I would like to resolve this as quickly
as painlessly as possible. It was suggested to me that I make a new
upload with a version number like 2.1.0-1+really1.30.4.

This is something that I can do ASAP, and then restart by actually
following the established transition process. Would that be
OK/acceptable to the release team and to others affected by my mistake?

Regards,

Ack. My question was aimed more generally than just at you. It may have
helped if I had been a bit more careful with how I structured my reply.

That change looks right to me. Basically, if something was already
successfully building against 1.30.x (without using any deprecated APIs)
then building against 2.x is a matter of just using the new module name
(whether via pkg-config or CMake).

The SONAME bump was about finally dropping a bunch of long deprecated
things from the API. Apart from the module name change (and some minor
reshulffling of headers), there weren't any really notable changes to
the API.

Regards,

Am 19.08.25 um 18:29 schrieb Roberto C. Sánchez:

Thanks for that additional information.

The patch I applied to Debian is a bit more convoluted than necessary as
I also sent it upstream who wants to keep the package building on really
old versions on Ubuntu and CentOS. And I was a bit worried by that
comment in

https://github.com/rsyslog/rsyslog/pull/5958#pullrequestreview-3126270761

I suppose AI was just lying to me then :-)

Michael

That's understandable.
Yeah, that seems a bit suspicious to me.

Regards,

Hi!

Now, with https://tracker.debian.org/pkg/mongo-c-driver being clear from
errors, maybe we can either close this issue or at least make it non-RC,
so that mongo-c-driver can migrate to testing?

Its migration is holding postfix to migrate to testing, which makes us
unable to update postfix in trixie (or else version in trixie will become
larger than version in testing).

Thanks,

/mjt

Current transition state can be seen at
https://release.debian.org/transitions/html/auto-mongo-c-driver.html

The remaining packages do not all have a bug filed for them being FTBFS,
let alone patches. I would suggest, the mongo-c-driver Maintainers care
about that.

But to move things forward, I am making this one of the missing bugs.
There is certainly one missing for nextepc.

syslog-ng build fails with:

configure:34653: checking for libmongoc-1.0 >= 1.0.0
configure:34660: $PKG_CONFIG --exists --print-errors "libmongoc-1.0 >= $LMC_MIN_VERSION"
Package libmongoc-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libmongoc-1.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libmongoc-1.0', required by 'virtual:world', not found
configure:34663: $? = 1
configure:34677: $PKG_CONFIG --exists --print-errors "libmongoc-1.0 >= $LMC_MIN_VERSION"
Package libmongoc-1.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libmongoc-1.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libmongoc-1.0', required by 'virtual:world', not found
configure:34680: $? = 1
configure:34694: result: no
Package 'libmongoc-1.0', required by 'virtual:world', not found
configure:34724: error: Could not find mongo-c-driver, and MongoDB support was explicitly enabled.

It looks like in the last few days upstream has made commits that allow
syslog-ng to build w/ libmongoc-dev >= 2.0. I have identified the
commits and attached them as patches to this email. Note that two of the
patches required slight tweaking to apply to the Debian package.

Regards,

Source: syslog-ng
Source-Version: 4.8.1-7
 Yup and it has been already used for the package update. Attila
forgot to close this bug, doing it now.