Bug#872846: temporarily readd POT-Creation-Date
On Tue, Aug 22, 2017 at 02:33:54PM +0200, Helmut Grohne wrote: > On Tue, Aug 22, 2017 at 01:53:39PM +0200, Santiago Vila wrote: > > > There is nothing that ensures that packages are built at the same time. > > > > The testing scripts ensure that all packages migrate to testing at the > > same time. This is by design. > > Testing migration irrelevant time. The installation set at build time > is. You are absolutely right here, the thing to consider in this case is the installation set at build time. > And nothing ensures that different architectures use equally > versioned installation sets. Well, yes, there is a thing that in practice ensures such thing: The fact that autobuilders are updated on a daily basis, and the fact that gettext built ok on all architectures the last time: https://buildd.debian.org/status/package.php?p=gettext So there is really no reason to assume that packages being built on unstable will be built with a mix of pre-msgfmt-change and post-msgfmnt-change depending on the architecture. Such thing will simply not happen, so none of the packages in the long list of affected packages would really have to be affected. > I do hope that fixes appear soon and this discussion becomes irrelevant. So do I, but please give some time for glibc maintainers to deal with this. I have contacted Aurelien regarding this issue. If he asks me to revert, I will. Thanks.
Bug#872846: temporarily readd POT-Creation-Date
On Tue, Aug 22, 2017 at 01:53:39PM +0200, Santiago Vila wrote: > > There is nothing that ensures that packages are built at the same time. > > The testing scripts ensure that all packages migrate to testing at the > same time. This is by design. Testing migration irrelevant time. The installation set at build time is. And nothing ensures that different architectures use equally versioned installation sets. > What you are basically asking me is that I care about unstable as if it > were stable (your mention of CVE issues suggests so, but neither > unstable or testing shortly after a stable release are supposed to > have real security support). I agree that unstable sometimes is broken, but we can only reasonably provide QA if it is not too broken. What "too broken" is is difficult to define and your definition obviously is different from mine. > Unstable is where we try new things even if they break other things. > When other things break we fix the other things and move forward. I do hope that fixes appear soon and this discussion becomes irrelevant. However that does not seem to be the case to me. > Currently, I see that glibc FTBFS in testing as well: I think unstable is where the majority of QA happens. Yeah, breakage is not a boolean, but I've been bitten too often and report stuff early now. Just make it work again. ;) Helmut
Bug#872846: temporarily readd POT-Creation-Date
> > 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. The testing scripts ensure that all packages migrate to testing at the same time. This is by design. What you are basically asking me is that I care about unstable as if it were stable (your mention of CVE issues suggests so, but neither unstable or testing shortly after a stable release are supposed to have real security support). That's not how we do things in Debian. Unstable is where we try new things even if they break other things. When other things break we fix the other things and move forward. Currently, I see that glibc FTBFS in testing as well: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glibc.html but we don't have the new gettext in testing yet, so this temporary breakage of glibc in unstable does not really make things worse than they are, since we already have a FTBFS in testing for unrelated reasons. To summarize: Unstable is unstable. OTOH, I would consider reverting the commit if we discovered more bugs like #872869 (please take a look at that one), but you will notice that the gettext upstream maintainers have been extremely quick to provide a fix. Thanks.
Bug#872846: temporarily readd POT-Creation-Date
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
Bug#872846: temporarily readd POT-Creation-Date
On Mon, Aug 21, 2017 at 09:51:36PM +0200, Helmut Grohne wrote: > Package: gettext > Version: 0.19.8.1-3 > Severity: serious > Justification: glibc ftbfs > User: helm...@debian.org > Usertags: rebootstrap > > The removal of POT-Creation-Date (#792687) is a nice thing to do, but > the archive isn't quite ready for it. > > * glibc FTBFS https://sourceware.org/bugzilla/show_bug.cgi?id=21508 and >no patch is available as of this writing. In fact, breaking other packages is hardly a good reason to revert the change. Consider the example of GCC 7. There are lots of packages that FTBFS because of new GCC 7, and I'm sure that a lot of them without patches as well, but this was never a reason not to upload GCC 7 for unstable or to revert the fact that we made GCC 7 the default gcc. We never said "the archive is not ready for it" for GCC 7, why this small change in gettext should be different? Please reassign and merge when you report the bug against glibc. This is not a bug in gettext, it's a bug in glibc at most. Thanks.
Bug#872846: temporarily readd POT-Creation-Date
On Mon, Aug 21, 2017 at 09:51:36PM +0200, Helmut Grohne wrote: > Package: gettext > Version: 0.19.8.1-3 > Severity: serious > Justification: glibc ftbfs > User: helm...@debian.org > Usertags: rebootstrap > > The removal of POT-Creation-Date (#792687) is a nice thing to do, but > the archive isn't quite ready for it. > > * glibc FTBFS https://sourceware.org/bugzilla/show_bug.cgi?id=21508 and >no patch is available as of this writing. That's a bug in an upstream bug tracker. Does our glibc also FTBFS for the same reason? Where is the Debian bug number? The way I read the upstream bug report: "tst-gettext fails", it does not seem the kind of bug which is difficult to fix. > * The commit changes .mo files and thus breaks M-A:sameness allover the >archive, e.g. #872806. Likely all packages shipping .mo files in >M-A:same packages are affected. The multiarch database on delfin.d.o >gives a clue: The commit does not really change any existing .mo file in the archive. 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. Moreover: How many of those in the list do not also violate Debian policy section 8.2? Also, bug #872806 does not seem a good example to me, because the library should not contain unversioned .mo files to begin with. 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. Thanks.
Bug#872846: temporarily readd POT-Creation-Date
Package: gettext Version: 0.19.8.1-3 Severity: serious Justification: glibc ftbfs User: helm...@debian.org Usertags: rebootstrap The removal of POT-Creation-Date (#792687) is a nice thing to do, but the archive isn't quite ready for it. * glibc FTBFS https://sourceware.org/bugzilla/show_bug.cgi?id=21508 and no patch is available as of this writing. * The commit changes .mo files and thus breaks M-A:sameness allover the archive, e.g. #872806. Likely all packages shipping .mo files in M-A:same packages are affected. The multiarch database on delfin.d.o gives a clue: SELECT distinct source FROM package WHERE multiarch = 'same' AND EXISTS (SELECT 1 FROM content WHERE package.id = content.pid AND filename LIKE './usr/share/%/%.mo') ORDER BY source; apt avahi colord-gtk cpluff cracklib2 cutter-testing-framework cwidget eb elfutils exo fcitx-anthy fcitx-cloudpinyin fcitx-googlepinyin fcitx-hangul fcitx-kkc fcitx-m17n giac girara gnutls28 grilo-plugins gsmlib gst-plugins-bad1.0 gst-plugins-base1.0 gst-plugins-good1.0 gst-plugins-ugly1.0 gstreamer1.0 gtkspell3 imhangul imhangul3 kde-gtk-config libexif libgpg-error libgphoto2 libguestfs libhdate libisds libisocodes libticables libticalcs libtifiles libvisual libvisual-plugins lunar-date mozc newt poldi popt postgresql-9.6 purpose scim-chewing scim-thai tre vips webkit2gtk webkitgtk xfce4-pulseaudio-plugin We'd likely have to binNMU these. I talked with Daniel Shahaf and we concluded that a temporary revert would be the best way forward. It shall leave time for fixing the above issues. Helmut
