> what happend to libgc? It ftbfs on all 32bit architectures and its > symbol handling is essentially stripped of all the architecture-specific > patterns that we have accumulated over the years.
I will keep an eye on this with Ivan per his last mail. > * A possibly breaking change for a core package is often done to > experimental first to reduce disruption of development on unstable. > Doing so would have prevented major pain here. Well of course it wasn't supposed to be. I do apologise and there's always something to learn. > * The debian/changelog entry contains duplicates. Mea culpa as I learn gbp's automated changelog generation steps. > * Lots of symbols were dropped from the symbols file without bumping > soname. Possibly, this may lead to incorrect dependencies on libgc in > downstream builds. This was discussed. They were not supposed to be used [1]. We will need to discuss what is happening calmly. > * debian/changelog says that you removed libatomic_ops handling, but > for every new architecture libatomic_ops is still opted in leading to > unnecessary porting work even though built-in atomics generally work > well. This was done with [2]. I agree it's a bug to keep including it as a dependency, which we can handle as a bug [3] > I am also wondering whether this actually is a package hijack as there > is no visible acknowledgement from any existing maintainers to adding > Ian to uploaders. > I am quite disappointed by this upload and the downstream pain it causes > to QA. As if I would just hijack a package [4]. Please consider your tone so we can have a project where we work together instead of throw flames at each other. -i [1] https://salsa.debian.org/debian/libgc/-/merge_requests/3 [2] https://salsa.debian.org/debian/libgc/-/merge_requests/4 [3] https://salsa.debian.org/debian/libgc/-/merge_requests/8 [4] https://salsa.debian.org/debian/libgc/-/merge_requests/7
