Control: reopen -1 Hi Mark,
thank you for your effort on making zlib cross buildable. Unfortunately, the minizip configure invocation still lacks the --host flag and therefore the cross build continues to fail. Keep in mind that the upstream change only fixes half of the problem. On Tue, Mar 31, 2026 at 12:33:29AM +0100, Mark Brown wrote: > 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. That bodging does exist, but it no longer is a lot. You run a script, tell it what architecture you want and what you get is Debian binary packages for something almost resembling build-essential. zlib happens to be among those packages that you get. As much as it was a pain in early days, it is very much automated now. > 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. Ok. The important aspect here is that the patch is now (slowly) progressing towards upstream and that you are willing to cherry-pick it. That combination makes for patience. > 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. If you dgit clone zlib, what you get is one commit importing the current version. The dgit team is looking towards a state where they can automatically import packages but then what you'd get is one commit per upload. The real benefit arises when maintainers dgit push-source their own history into it as that's when dgit clone gives you actual history with meaning. To put it another way, in using dgit clone, I'd have figured that you'd probably prefer a big patch with all the changes lumped together. Let's both agree that that would not have been the right conclusion. Helmut
