On Mon, Aug 21, 2017 at 10:32:40PM +0200, Santiago Vila wrote: > That's a bug in an upstream bug tracker. > > Does our glibc also FTBFS for the same reason? Where is the Debian bug number?
Yes, it does. If you need a number, clone it. > It just makes the .mo files to be different when you rebuild the > package. But in general this is supposed to happen at the same time > in all architectures, triggered by a new Debian revision. There is nothing that ensures that packages are built at the same time. Thus I ran into precisely that issue. I didn't pull this one out of my hair. > Moreover: How many of those in the list do not also violate Debian policy > section 8.2? Guess: most. > Also, bug #872806 does not seem a good example to me, because the library > should not contain unversioned .mo files to begin with. I'd like to to provide better examples, but with the current breakage this is difficult to analyze. > So, if I have to revert, I will do, but so far I don't see this is a > catastrophic failure that requires a reversion. It currently breaks the rebootstrap qa. This happens regularly, but the difference here is that the present gettext issue is very hard to work around. Thus it "blinds" me of other bootstrap issues and makes them harder to track down. If you have ideas for reasonable workarounds, that'd be welcome. The source/binary version skew of glibc is currently fatal to dpkg. The present glibc FTBFS also prevents CVE fixes from transitioning to testing. Your comparison to gcc-7 is a straw man as for every gcc major release a full archive rebuild is performed and bug reports are filed ahead of the upload. People had months to fix. In contrast, this change was cherry-picked from upstream, so glibc is kinda unprepared here. Please reconsider (or send patches). Helmut
