Bug#908862: Closing this bug

2024-05-10 Thread Santiago Vila

fixed 908862 2:24.0.0-2
tags 908862 + bullseye bookworm
thanks

As I did with ceilometer, I'm fixing the metadata with this message.

Thanks.



Bug#908862: Closing this bug

2024-05-10 Thread Santiago Vila

El 10/5/24 a las 16:22, Thomas Goirand escribió:

After 5 years, I still have no clue on why Neutron couldn't build in your env. 
What I know for sure: I wouldn't build Neutron with only 8GB of RAM in a VM.

At this point, I don't see why this bug should stay open. Nobody is investing 
time on it, neither you, me or upstream. And nobody is able to re-trigger it 
but you, with not enough RAM, it seems.

Closing this bug then...

Feel free to reopen if you still think it should, but them please explain how 
it should be reproduced, and try with enough RAM. Note that stestr will spawn 
as many process as there's CPU, so the more VCPU you have, the more RAM you 
should provide too.


It seems fair to me that you close this bug.

I don't keep failed logs for neutron anymore, and I believe the reason is
that I changed my build setup recently.

Before, I was using directory-based chroots, with the "default" profile
and partition bindings defined in /etc/schroot/default/fstab.

Now I'm using file-based chroots, with the "sbuild" profile and partition
bindings defined in /etc/schroot/sbuild/fstab.

Now this bug is closed and I agree that it's better that it's closed.

However, please do not spread misinformation about the cause of the bug.

No, it was not lack of RAM. I knew it was not when I reported it, and this is
still true, as I have successful build logs with machines with 2 CPUs and 8 GB 
of RAM.

Moreover, neutron still fails in bullseye and bookworm here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html

Maybe you could ask reproducible-builds people to tell you how to reproduce it.

At least I gave you a machine to reproduce it, and you verified that the failure
happened indeed. If any of us had thought about changing the build setup
(in the same machine) maybe we could have discovered the reason at the time.

On the positive side, I think we were very close. If a similar bug happens and
you can reproduce it in a machine which I provide, I think the next logical step
should be to extend the VM offer to upstream.

Also on the positive side: If you can't reproduce any currently open bug 
reported
by Lucas Nussbaum, please contact me privately, I can provide a machine with the
exact specs he used for the build.

Thanks.