Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Control: severity -1 wishlist Control: tags -1 +wontfix On Sun, Jan 01, 2023 at 11:49:26PM +0100, Santiago Vila wrote: > [ Thanks for fixing the bug in unstable so fast ] ... too fast, in fact. Per the discussion on debian-policy, it's not a bug, and this way I have a redundant dependency which actually is a bug (for a good reason: it makes it harder to reorganize unrelated packages). I've thus reverted the change -- in git, not worth a separate upload. > > I'm all for fixing bugs in stable that: > > * are obviously bugs (rather than a point of debate) > > You are the only one debating this, but it should really not be a point of > debate. Per debian-policy, indeed. Good that the debate has been resolved. [...] > [ In fact, I wonder why you bothered to add the missing B-D if you really > believe it > is not a bug. Because I considered doing so to be less effort than arguing. Which has proven to be premature. [...] > I think it is important to honor the promises we made to the users. We > promised a stable release without FTBFS bugs, and we are almost delivering > it, but not completely. > > In the end, it boils down to where do we draw the line. You think having > a reduced number of packages which FTBFS according to Policy is ok. I think > the only acceptable number of FTBFS bugs to have in a stable release is zero, > and I am working towards such goal. Here I agree, but inventing new bugs where there's no FTBFS is not helpful. "FTBFS" means the package actually fails to build from source, using any of build machinery present in the archive, on a realistic hardware/kernel/setup, for a distribution the given bug is marked as affecting. Thus, for example: a FTBFS with a future version of gcc or with buildflags that are not enabled yet is not a RC bug, becoming serious only once such a compiler/configuration is actually uploaded to unstable. Likewise, a change to the build environment where tzdata is no longer available, would be RC only in unstable but not in bullseye. > So the only thing I ask is that you do not insist that this is not a bug > when I reopen it for bullseye. Since I will be the one doing the work, > I think I should be allowed to use the BTS to track those bugs. Okay, I'm not closing the bug for bullseye. I did though reduce the severity to wishlist as it's (per the debian-policy discussion) neither RC nor even contravening bullseye's nor current unstable's policy, and the change is opposed by a number of people. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line: ⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day." ⠈⠳⣄
Processed: Re: Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Processing control commands:
> severity -1 wishlist
Bug #1027380 {Done: Adam Borowski } [src:safeclib]
safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Severity set to 'wishlist' from 'serious'
> tags -1 +wontfix
Bug #1027380 {Done: Adam Borowski } [src:safeclib]
safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Added tag(s) wontfix.
--
1027380: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027380
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
[ Thanks for fixing the bug in unstable so fast ] I'm all for fixing bugs in stable that: * are obviously bugs (rather than a point of debate) You are the only one debating this, but it should really not be a point of debate. Packages with missing build-depends are buggy and always have been. This is both in Debian Policy which we have already quoted and also in Release Policy for bullseye, which is the one that counts here: Packages must list any packages they require to build beyond those that are "build-essential" in the appropriate Build-Depends: fields. Ref: 4.2 https://release.debian.org/bullseye/rc_policy.txt Release Policy exists as a subset of Policy so that we don't have to discuss each time about which bugs we want a stable release to *never* have. If you think required packages are automatically build-essential, feel free to ask debian-policy for clarification. [ In fact, I wonder why you bothered to add the missing B-D if you really believe it is not a bug. There has not been any change in Debian Policy or Release Policy regarding this between bullseye and bookworm. Therefore, this is a bug in bullseye (or not) the same way it is a bug in bookworm (or not). ]. BTW: I'm not taking the build-essential package to determine which packages are build-essential or not, because there is already a definition in Policy, namely, those packages required to build a "hello world" program in C or C++ (Policy 4.2). I have still 87 FTBFS bugs to fix in stable. You are of course free to not help me fixing yours. Per the Developers Reference, a mass bug filing of many bugs on the same topic is required to be discussed before filing. Hmm, I have made a mistake in the wording which has led to a misunderstanding. I didn't say those 87 FTBFS bugs were of the same type. The ones about missing build-depends are already filed, and most of them are also unfixed in bookworm, so I believe they are correctly filed. The other bugs in bullseye are of very different types. Quite a number of them were already reported by Lucas Nussbaum and fixed in unstable but not in bullseye, where they also happen. An example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997580 In cases like that I have to "resurrect" the bug and usually I propose a debdiff to the maintainer for the bullseye upload, when I can. This is not fixing a bug retroactively, this is ensuring that packages in stable build in stable, something that we promised at release time and are not honoring yet (but we are very close). There are also quote a number of FTBFS bugs which happen because they contained a "time bomb": https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025096 Again, this is not fixing a package retroactively, it's that the package had a silly unit test which was destined to fail in the future. I think it is important to honor the promises we made to the users. We promised a stable release without FTBFS bugs, and we are almost delivering it, but not completely. In the end, it boils down to where do we draw the line. You think having a reduced number of packages which FTBFS according to Policy is ok. I think the only acceptable number of FTBFS bugs to have in a stable release is zero, and I am working towards such goal. So the only thing I ask is that you do not insist that this is not a bug when I reopen it for bullseye. Since I will be the one doing the work, I think I should be allowed to use the BTS to track those bugs. Thanks.
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
On Sun, Jan 01, 2023 at 01:53:31PM +0100, Santiago Vila wrote: > Adam Borowski escribió: > > nor any of people running archive rebuilds so far. > > FWIW: I am one of those people running archive rebuilds. > I rebuilt the entire bullseye distribution, and I'm trying > to make it FTBFS bug free, as mandated by both Debian Policy > and Release Policy. Bullseye has been a non-moving target for two years, thus changing requirements packages there are expected to meet is grossly belated. There are cases where adding such a requirement is worth the effort (eg. new hardware, or a hitherto unknown type of bugs), but I don't see how something with no practical benefit qualifies. This doesn't mean I intend to stop your efforts for releases currently in development -- I've already fixed this very bug in unstable (even though I disagree with the premise). But doing this for stable... come on... On Sun, Jan 01, 2023 at 01:46:06PM +0100, Santiago Vila wrote: > El 1/1/23 a las 12:58, Adam Borowski escribió: > > Control: tags -1 +unreproducible moreinfo > > I don't think the unreproducible tag applies here. > > To reproduce, just try to build it in a chroot which does > not include tzdata. If debootstrap does not do that by default, > then it follows that you should not simply accept debootstrap's defaults. No tool in Bullseye produces such build chroots, and this is what matters here. There's no practical benefit of retroactively changing packages: neither security rebuilds nor packages built by the users themselves will lack tzdata (the former because of build tools, the latter because of how Policy 2.5 defines "required"). Thus: I argue this is not a bug, and that even if it actually is a bug, there are no practical benefits of fixing it in _stable_. We are free to redefine requirements for future releases, of course. > This is Policy 4.2: > > > If build-time dependencies are specified, it must be possible to build the > > package and produce working binaries on a system with only essential and > > build-essential packages installed and also those required to satisfy the > > build-time relationships > (including any implied relationships). > > So yes, this is undoubtedly a bug, because tzdata is not build-essential. It is. It is merely not included in the _informational_ list shipped by a metapackage by that name; it explicitly says: # This package is NOT the definition of what packages are # build-essential; the real definition is in the Debian Policy Manual. # This package contains merely an informational list, which is all # most people need. However, if this package and the manual disagree, # the manual is correct. And Policy 4.2 which you just quoted says: # (including any implied relationships) I'd say that the Policy declaring systems that lack Priority:required packages to be broken fulfills this clause. > I could agree that everything would be easier if debootstrap was fixed once > and forever: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 > > If you can push for that bug to be fixed for bookworm, that would certainly > help. It seems that multiple debootstrap maintainers disagree -- and so do I. But, as I said before, I have no real objections to changing this for Bookworm. Making an upload to add the B-Dependency was less effort than arguing, and I've already one so, thus complying with whatever rule wins. > > I have nothing against adding such a B-Dependency in unstable: this is where > > new development is supposed to be done, preparing a new upload costs but a > > few mins of my time. On the other hand, updating stable requires extensive > > process and wastes the time of me, the Release Team, of people preparing the > > new point release announcement, of users testing and deploying the update. > > Of course fixing bugs takes a little bit of time, but it may also be argued > that > not fixing this kind of bugs produces weird effects which makes some people > to lose > some of their time (for example, me building the whole archive trying to keep > stable free > from any kind of FTBFS bugs). These bugs are caused only by your intentional change to build chroots you use. You can save that time by not doing that _active_ step for past releases. > If, despite having a trivial fix for the bug, you decide > not to fix it in stable and leave the fix for others, I will have less time > for other things > which I also want to fix. I know that some people will not agree, but I > believe fixing > FTBFS bugs in stable should be primarily a responsibility of the affected > maintainers. > Offloading the work to those particularly interested in stable does not scale > well. I'm all for fixing bugs in stable that: * are obviously bugs (rather than a point of debate) * have a practical effect (because our process for stable update is a lot of work) > I have still 87 FTBFS bugs to fix in stable. You are of course free to > not help me fixing yours. Per the
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Adam Borowski escribió: nor any of people running archive rebuilds so far. FWIW: I am one of those people running archive rebuilds. I rebuilt the entire bullseye distribution, and I'm trying to make it FTBFS bug free, as mandated by both Debian Policy and Release Policy. Thanks.
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
El 1/1/23 a las 12:58, Adam Borowski escribió: Control: tags -1 +unreproducible moreinfo I don't think the unreproducible tag applies here. To reproduce, just try to build it in a chroot which does not include tzdata. If debootstrap does not do that by default, then it follows that you should not simply accept debootstrap's defaults. This is Policy 4.2: If build-time dependencies are specified, it must be possible to build the package and produce working binaries on a system with only essential and build-essential packages installed and also those required to satisfy the build-time relationships > (including any implied relationships). So yes, this is undoubtedly a bug, because tzdata is not build-essential. I could agree that everything would be easier if debootstrap was fixed once and forever: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 If you can push for that bug to be fixed for bookworm, that would certainly help. I have nothing against adding such a B-Dependency in unstable: this is where new development is supposed to be done, preparing a new upload costs but a few mins of my time. On the other hand, updating stable requires extensive process and wastes the time of me, the Release Team, of people preparing the new point release announcement, of users testing and deploying the update. Of course fixing bugs takes a little bit of time, but it may also be argued that not fixing this kind of bugs produces weird effects which makes some people to lose some of their time (for example, me building the whole archive trying to keep stable free from any kind of FTBFS bugs). If, despite having a trivial fix for the bug, you decide not to fix it in stable and leave the fix for others, I will have less time for other things which I also want to fix. I know that some people will not agree, but I believe fixing FTBFS bugs in stable should be primarily a responsibility of the affected maintainers. Offloading the work to those particularly interested in stable does not scale well. I have still 87 FTBFS bugs to fix in stable. You are of course free to not help me fixing yours. Thanks.
Processed: Re: Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Processing control commands: > tags -1 +unreproducible moreinfo Bug #1027380 [src:safeclib] safeclib: FTBFS in bullseye (missing build-depends on tzdata) Added tag(s) unreproducible and moreinfo. -- 1027380: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027380 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Control: tags -1 +unreproducible moreinfo On Fri, Dec 30, 2022 at 07:04:09PM +0100, Santiago Vila wrote: > Package: src:safeclib > Version: 3.5-3 > Severity: serious > Tags: ftbfs patch > During a rebuild of all packages in bullseye, your package failed to build: > FAIL: t_gmtime_s > FAIL: t_localtime_s > PASS: t_getenv_s > PASS: t_bsearch_s > PASS: t_qsort_s I can't reproduce the failure using any of common menthods of creating a build chroot. Neither could the buildds nor any of people running archive rebuilds so far. Is there any way _relevant for bullseye_ that would produce the build chroot without a Priority:required package such as tzdata? If not, I don't believe this is a bug for stable. Not merely a serious bug, not a bug at all -- it can't happen on buildds nor on user systems. I have nothing against adding such a B-Dependency in unstable: this is where new development is supposed to be done, preparing a new upload costs but a few mins of my time. On the other hand, updating stable requires extensive process and wastes the time of me, the Release Team, of people preparing the new point release announcement, of users testing and deploying the update. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Package: src:safeclib Version: 3.5-3 Severity: serious Tags: ftbfs patch Dear maintainer: During a rebuild of all packages in bullseye, your package failed to build: [...] debian/rules build-arch dh build-arch dh_update_autotools_config -a dh_autoreconf -a [...] FAIL: t_gmtime_s FAIL: t_localtime_s PASS: t_getenv_s PASS: t_bsearch_s PASS: t_qsort_s = Safe C Library 04062019.0-ga99a05: tests/test-suite.log = # TOTAL: 124 # PASS: 122 # SKIP: 0 # XFAIL: 0 # FAIL: 2 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: t_gmtime_s FAIL t_gmtime_s (exit status: 1) FAIL: t_localtime_s === FAIL t_localtime_s (exit status: 1) [...] make[3]: *** [Makefile:4324: check-am] Error 2 make[3]: Leaving directory '/<>/tests' make[2]: *** [Makefile:1188: check-recursive] Error 1 make[2]: Leaving directory '/<>' make[1]: *** [Makefile:1492: check] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: error: make -j2 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:9: build-arch] Error 25 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 (The above is just how the build ends and not necessarily the most relevant part) Note: I'm using the "patch" tag because there is an obvious fix (indicated in the subject). About the archive rebuild: The build was made using virtual machines from Hetzner, with enough memory, enough disk, and either one or two CPUs, using a reduced chroot with only build-essential packages (plus debhelper). If you could not reproduce the bug please contact me privately, as I am willing to provide ssh access to a virtual machine where the bug is fully reproducible. If this is really a bug in one of the build-depends, please use reassign and affects, so that this is still visible in the BTS web page for this package. Thanks.
