On Tue, Mar 24, 2026 at 12:40:54PM +0100, Helmut Grohne wrote: > On Tue, Mar 24, 2026 at 02:12:54AM +0000, Mark Brown wrote:
> > attached to it. This is not so far as I have been able to tell a > > regression fix, this is a new feature which you have requested which > > isn't so far as I can tell part of anything other than a generalised > > wouldn't it be nice to have this effort, that seems to fit squarely in > > that bucket. > This used to work for ten years and architecture cross bootstrap relies > on zlib being cross buildable. It is not an optional feature, but a > building block of our distribution. Cross building no longer is optional > for the essential package set. I recognize that my bug submission did > not clarify this at all. I see. The last time I looked at bootstrapping there was a certain amount of bodging in the early phase of bringup until you got to something self hosting. > > No, the issue is not doing cleanup. The issue is putting a number of > > separate, unexplained or poorly explained, changes in a single patch and > > are then pushing very hard to get them in as is. You can surely see how > > that both sets off all kinds of alarm bells so I feel I have to review > > these changes especially carefully (and time consumingly), and also > > causes me to prioritise other changes. Currently that's mainly the new > > upstream release. It is an issue with both understanding and trusting > > the changes. > A new upstream release sounds like a better path to move this forward to > me indeed. Let's try that route: > https://github.com/madler/zlib/pull/1210 Note that I wouldn't hold your breath for a new upstream release any time soon, there was one very recently and they tend to be infrequent. The previous release was in 2024. > > A more typical way to present this would have been as three patches, one > > with the Makefile.am patch, one with the dh_auto_configure change and > > one with the manual change, each of these with a changelog included as > > part of the patch. Having the changelog directly next to the change > > really does help with clarity. > I can see how you get there from a Linux kernel pov, but most Debian > package maintainers are find with the one patch fixing cross builds. > zlib maintenance is the exception here. It wasn't *just* the one patch thing, it was the unexplained weird bits in the middle of the patch, had the patch been unsurprising it'd probably have been fine. The reason that serieses and more detailed changelogs are common good practice is that they make surprises a lot less likely, I'm sure this is as true in Debian as it is in other projects. > Additionally, the existence of a version control system helps a lot with > preparing such isolated patches as it avoids having to resort to say > debdiff producing one pile. In not providing that you additionally raise > the effort on the contributors side. Let's not beat that dead horse. TBH I had thought that one of the selling points of dgit is that it lets you import any package so you don't need to worry so much about what's on the other end, so if the package itself is being maintained in dgit that's bonus on top of that.
signature.asc
Description: PGP signature
