[13:50] <enr0n> Can a core-dev please trigger the PPA autopkgtests listed in https://paste.ubuntu.com/p/M9J269xCWJ/? TIA.
[13:52] <schopin> enr0n: on it.
[13:57] <enr0n> schopin: Thanks!
[13:57] <schopin> yw
[14:17] <ogayot> utkarsh2102: Hi! I'm looking at merging keyutils from Debian unstable. May I ask what is your opinion on potentially forwarding the TTL patch to Debian? LP: #1962453 Thanks!
[16:26] <rbasak> u-d-a@ moderation please
[16:32] <cjwatson> rbasak: .
[16:32] <rbasak> Thanks!
[16:44] <ahasenack> tjaalton: hi, this bind-dyndb-ldap Depends seems a bit excessive:  bind9-libs (= ${bind9-libs:Version})
[16:44] <ahasenack> it will add the ubuntu release to it too, i.e., Depends: bind9-libs (= 1:9.18.1-1ubuntu1)
[16:44] <ahasenack> so even no-change rebuilds of bind9 will need a no-change rebuild of bind-dyndb-ldap
[16:45] <ahasenack> can that be relaxed to just the upstream version perhaps? What do you think?
[16:51] <ahasenack> maybe this?
[16:51] <ahasenack> -BIND9_LIBS_VER = $(shell dpkg-query -f='$${Version}\n' -W bind9-libs)
[16:51] <ahasenack> +BIND9_LIBS_VER = $(shell dpkg-query -f='$${source:Upstream-Version}\n' -W bind9-libs)
[17:28] <xnox> it uses private symbols no? and a no change rebuild can generate different sybmols, because toolchain.
[17:28] <xnox> we have/had a few packages that have tight dependencies.
[17:28] <xnox> plus one cannot do just Upstream-version..... it needs to be like >= upstream-version <= next version
[17:49] <ahasenack> I would be happy with just == upstream version, that would allow patch builds of bind without having to rebuild bind-dyndb-ldap
[17:50] <ahasenack> but yeah, maybe this is a case of having been bitten in the past, so let's make it strict
[17:57] <tjaalton> ahasenack: yeah needs to be fairly strict, but if it can be relaxed a bit then that's fine
[17:57] <ahasenack> how does one detect failures, only when using it? Or they usually happen at build time?
[18:02] <ahasenack> I guess runtime
[18:04] <ahasenack> I suppose I could add a quick dep8 test to it
[18:39] <bdmurray> rbasak: Can you update the contact information for git-ubuntu to a launchpad project that exists? It's currently set to "usd-importer"
[18:50] <rbasak> bdmurray: you mean the snap?
[18:51] <rbasak> I updated the snap contact info to point to the new project name. If you were referring to something else, please let me know what - there might be a few other places that need updating still.
[18:52] <rbasak> Thank you for pointing it out anyway :)
[18:54] <bdmurray> rbasak: this is the version of the snap I have installed https://paste.ubuntu.com/p/qCv8r5tWQy/
[19:05] <tjaalton> ahasenack: runtime
[19:07] <tjaalton> ahasenack: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004729 is one example
[19:07] <rbasak> bdmurray: thanks. I think that might be fixed now.
[19:08] <bdmurray> rbasak: How?
[19:11] <rbasak> bdmurray: I updated the contact field using the store publishing web interface thing. AFAICT, it's not in the snapcraft.yaml at all.
[19:11] <rbasak> So I think that means it's not attached to any particular snap, but is an online thing with the store.
[19:11] <rbasak> I could be wrong about that though
[19:16] <bdmurray> I'm still seeing the same contact url but maybe its cached somewhere
[21:46] <mwhudson> dbungert: hmm https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dnspython
[22:06] <dbungert> would a core-dev help with some test retries?  retry-autopkgtest-regressions|grep trigger=dnspython
[22:07] <jawn-smith> dbungert: doing it now
[22:07] <dbungert> jawn-smith: thanks!