Hi, On Sun, Aug 16, 2026 at 01:12:59AM +0200, Aurelien Jarno wrote: > Hi, > > On 2026-08-14 11:11, Salvatore Bonaccorso wrote: > > Hi replying to full quote the mail from Moritz below, since his mail > > got rejected: > > > > <[email protected]>: host > > bendel.debian.org[2001:41b8:202:deb:216:36ff:fe40:4002] said: 550 5.7.1 > > <[email protected]>: Recipient address rejected: Mail > > appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to > > correct > > HELO and DNS MX settings or to get removed from DNSBLs; please relay via > > your ISP (inutil.org) (in reply to RCPT TO command) > > > > There is an issue with building neutron on the buildd's due to not > > including the update of python3.13 from trixie-updates, see below: > > > > The original mail: > > > > On Fri, Aug 14, 2026 at 08:58:19AM +0000, Moritz Mühlenhoff wrote: > > > On Fri, Aug 14, 2026 at 09:48:18AM +0200, Thomas Goirand wrote: > > > > > The package FTBFSes on the security buildds, the log is attached. > > > > > > > > This is *NOT* an issue with Neutron, but with the setup of your build > > > > host. > > > > It's not including trixie-updates, so it doesn't have the fix for Python > > > > 3.13. > > > > > > > > In other words, your buildd is running Python 3.13 3.13.5-2+deb13u3 > > > > instead > > > > of 3.13.5-2+deb13u4, and therefore, is affected by the garbage > > > > collector bug > > > > that appeared on the latest Trixie point release. > > > > > > > > As a consequence, you'll see random failures like this one: > > > > > > > > testtools.testresult.real._StringException > > > > > > > > which is not due to an issue in Neutron, or OpenStack in general. > > > > > > Makes sense. > > > > > > > So the question is: how can we get the buildd fixed, and include the > > > > fixed > > > > Python 3.13 3.13.5-2+deb13u4 version? > > > > > > Adding the buildd folks to the thread; could we modify the security > > > buildds > > > to include trixie-updates? > > This is now done. Note however that it was done on purpose to avoid > requiring users to use -updates with -security in their sources.list. > This could happen if case some package from -security picks-up a > dependency on a package in -updates. That said the risk is probably very > low.
thank you! One option would be to maybe disable it again after the round of neutron rebuilds. But I can understand we do not want to have a back and forth here. I remember we enabled temporarily as well the proposed-updates suites at least once (for firefox DSAs?) and the rolled back. I have given-back neutron and it now has built: * neutron/all | neutron: | Package : neutron | Version : 2:26.0.3-0+deb13u3 | Builder : buildd-x86-csail-02 | State : Uploaded Regards, Salvatore
