=== mwhudson_ is now known as mwhudson === cpaelzer_ is now known as cpaelzer === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === sem2peie- is now known as sem2peie === mfo_ is now known as mfo [13:50] Can a core-dev please trigger the PPA autopkgtests listed in https://paste.ubuntu.com/p/M9J269xCWJ/? TIA. [13:52] enr0n: on it. [13:57] schopin: Thanks! [13:57] yw [14:17] 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! [14:17] Launchpad bug 1962453 in keyutils (Ubuntu Jammy) "Apply default TTL to records obtained from getaddrinfo()" [Undecided, Fix Released] https://launchpad.net/bugs/1962453 [16:26] u-d-a@ moderation please [16:32] rbasak: . [16:32] Thanks! [16:44] tjaalton: hi, this bind-dyndb-ldap Depends seems a bit excessive: bind9-libs (= ${bind9-libs:Version}) [16:44] it will add the ubuntu release to it too, i.e., Depends: bind9-libs (= 1:9.18.1-1ubuntu1) [16:44] so even no-change rebuilds of bind9 will need a no-change rebuild of bind-dyndb-ldap [16:45] can that be relaxed to just the upstream version perhaps? What do you think? [16:51] maybe this? [16:51] -BIND9_LIBS_VER = $(shell dpkg-query -f='$${Version}\n' -W bind9-libs) [16:51] +BIND9_LIBS_VER = $(shell dpkg-query -f='$${source:Upstream-Version}\n' -W bind9-libs) [17:28] it uses private symbols no? and a no change rebuild can generate different sybmols, because toolchain. [17:28] we have/had a few packages that have tight dependencies. [17:28] plus one cannot do just Upstream-version..... it needs to be like >= upstream-version <= next version [17:49] I would be happy with just == upstream version, that would allow patch builds of bind without having to rebuild bind-dyndb-ldap [17:50] but yeah, maybe this is a case of having been bitten in the past, so let's make it strict [17:57] ahasenack: yeah needs to be fairly strict, but if it can be relaxed a bit then that's fine [17:57] how does one detect failures, only when using it? Or they usually happen at build time? [18:02] I guess runtime [18:04] I suppose I could add a quick dep8 test to it [18:39] 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] bdmurray: you mean the snap? [18:51] 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] Thank you for pointing it out anyway :) [18:54] rbasak: this is the version of the snap I have installed https://paste.ubuntu.com/p/qCv8r5tWQy/ [19:05] ahasenack: runtime [19:07] ahasenack: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004729 is one example [19:07] Debian bug 1004729 in bind9-dyndb-ldap "bind9-dyndb-ldap: fails to load dyndb-ldap backend" [Grave, Open] [19:07] bdmurray: thanks. I think that might be fixed now. [19:08] rbasak: How? [19:11] 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] So I think that means it's not attached to any particular snap, but is an online thing with the store. [19:11] I could be wrong about that though [19:16] I'm still seeing the same contact url but maybe its cached somewhere [21:46] dbungert: hmm https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dnspython [22:06] would a core-dev help with some test retries? retry-autopkgtest-regressions|grep trigger=dnspython [22:07] dbungert: doing it now [22:07] jawn-smith: thanks! === themill_ is now known as themill