Hi Mark, On Tue, Mar 24, 2026 at 02:12:54AM +0000, Mark Brown wrote: > To be clear if something like that comes up I generally deal with it > more promptly, usually when someone does a transition or something (like > with the shambles with the s390 removal). The above is just for the > general wishlist packaging change stuff that has nothing in particular > 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. > Nonetheless I shall continue to attempt to review your changes, > apologies for this. Given the urgency I trust that you will respond > promptly and clearly to the review feedback below. Thank you. Let's make progress. > 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 > 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. 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. > > --- a/contrib/minizip/Makefile.am > > +++ b/contrib/minizip/Makefile.am > > @@ -39,7 +39,7 @@ > > EXTRA_PROGRAMS = miniunzip minizip > > > miniunzip_SOURCES = miniunz.c > > -miniunzip_LDADD = libminizip.la > > +miniunzip_LDADD = libminizip.la -lz > > This (from both patches) is patching the upstream source directly > without using the package's patch system. Is there some reason for this > that I am not aware of or is it just a bug? It seems that I went too far with removing unnecessary changes. Given your feedback of the size of my patch, I attempted minimizing it as much as possible. I suggest importing https://patch-diff.githubusercontent.com/raw/madler/zlib/pull/1210.patch into the Debian package. Would you be able to do that? Do you have a preference regarding explicit --build/--host versus dh_auto_configure already? Helmut
