Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1131021 > unrolled thread

Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata) Adam Borowski <kilobyte@angband.pl> - 2023-01-01 13:10 +0100
    Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata) Adam Borowski <kilobyte@angband.pl> - 2023-01-01 22:20 +0100
      Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata) Santiago Vila <sanvila@debian.org> - 2023-01-02 00:00 +0100
        Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata) Adam Borowski <kilobyte@angband.pl> - 2023-01-08 06:40 +0100

#1131021 — 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?
⠈⠳⣄⠀⠀⠀⠀

[toc] | [next] | [standalone]

#1131171

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 Developers Reference, a mass bug filing of many bugs on the same
topic is required to be discussed before filing.  This is not usually done
for obvious cases like FTBFSes on an _unmodified_ build infrastructure,
but retroactively declaring 87 packages as RC-buggy in _stable_ certainly
counts.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#1131189

[ 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.

[toc] | [prev] | [next] | [standalone]

#1132225

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."
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web