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

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

Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied

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#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied Mathias Gibbens <gibmat@debian.org> - 2025-04-19 04:10 +0200
    Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied Santiago Vila <sanvila@debian.org> - 2025-04-19 12:30 +0200
      Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied Santiago Vila <sanvila@debian.org> - 2025-04-19 13:10 +0200
        Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied Santiago Vila <sanvila@debian.org> - 2025-04-19 19:40 +0200
    Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied Jeremy Bícha <jeremy.bicha@canonical.com> - 2025-04-19 13:40 +0200
    Bug#1103554: incus: writes to $HOME during build Santiago Vila <sanvila@debian.org> - 2025-04-20 12:20 +0200

#1242657 — Bug#1103554: incus: FTBFS: Error: mkdir /build/.config: permission denied

[Multipart message — attachments visible in raw view] — view raw

  Interesting; I haven't seen the build fail in this way before, and as
Jeremy pointed out Incus builds properly in other places on official
infrastructure.

  For background on this particular part of the build, when I was
working on LXD packaging the TZ and HOME environment variables were set
to help make the build reproducible[0]. Later with Incus, I must have
noticed something in another of the manpages that was including the
build-environment HOME, so I set the override on all the generation
commands[1].

  When the `incus` binary starts it does try to create a configuration
file under ~/.config/incus/; based on the error it seems that the
homedir is "/build/", and that it's read-only?

Mathias

[0] -- https://salsa.debian.org/go-team/packages/lxd/-/commit/84e5fec9906f39ab9e9fd7e9e9719514e269148a
[1] -- https://salsa.debian.org/go-team/packages/incus/-/commit/0e9d324dadea33eeae6682786c1beff5764a33da

[toc] | [next] | [standalone]

#1242687

El 19/4/25 a las 3:57, Mathias Gibbens escribió:
>    When the `incus` binary starts it does try to create a configuration
> file under ~/.config/incus/; based on the error it seems that the
> homedir is "/build/", and that it's read-only?

Packages must not write anything to $HOME during build.

To enforce such policy, sbuild sets $HOME to /sbuild-nonexistent.
You can see this in the full build log I provided and also in each
and every build log in buildd.debian.org. This way, packages
trying to write to $HOME will fail and we know they have a bug.

If you set $HOME again to the original $HOME, it may or may not work,
but if it fails, it's not my fault, since it's a policy violation.

I offered a VM to reproduce, and the offer still holds, please contact me
privately for details.

Thanks.

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

#1242691

El 19/4/25 a las 12:22, Santiago Vila escribió:
> I offered a VM to reproduce, and the offer still holds, please contact me
> privately for details.

I created a VM to test. The package built fine for me... but
it created .config/incus/oidctokens, which is a policy violation.

I would try to find other ways to make the package reproducible
which does not involve writing things to $HOME.

Thanks.

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

#1242735

Hi. This is a summary of all I know about the problem:

Apparently, it started to happen when using sbuild 0.89.0, which
was uploaded for unstable this week.

It seems to happen only when using schroot. Admittedly
not the default anymore in the buildds, but still a way
in which anybody might want to build packages for whatever
reason [*].

Several days ago, I did a full archive rebuild using the
unshare backend to make sure that sbuild 0.89.0 was ok for
release. This explains that I did not find the bug before,
but it's now that I tried again using schroot (not the unshare backend)
when we discovered the problem.

I've asked sbuild maintainers about this in case it might be
a regression in sbuild, but maybe sbuild is just being a little
bit more strict (for good) in what it allows the package to do.

[*] There is some similarity between this bug and packages trying
to access Internet during build. Not all sbuild backends will catch
packages trying to access Internet, and not all sbuild backends will
error when the package tries to write to $HOME. This is why I'm still
using schroot while Lucas Nussbaum has switched to the unshare backend.

I agree with Jeremy that this is worse than breaking reproducible-builds,
for the reasons he stated.

In either case, I've given Mathias a VM where at least he can verify
that the package writes to $HOME (with or without a build failure,
I still don't know why there is a difference here), and he says he
has a potential fix, so hopefully we will have a package which
works for everybody.

Thanks.

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

#1242699

On Fri, Apr 18, 2025 at 9:57 PM Mathias Gibbens <gibmat@debian.org> wrote:
>   For background on this particular part of the build, when I was
> working on LXD packaging the TZ and HOME environment variables were set
> to help make the build reproducible[0]. Later with Incus, I must have
> noticed something in another of the manpages that was including the
> build-environment HOME, so I set the override on all the generation
> commands[1].
>
>   When the `incus` binary starts it does try to create a configuration
> file under ~/.config/incus/; based on the error it seems that the
> homedir is "/build/", and that it's read-only?

Your [1] commit in particular looks wrong. When Santiago mentioned
Debian Policy, I think he was referring to § 4.9 "In particular, the
required targets must not attempt to write into HOME." [2] But your
commit explicitly rewrites HOME as ~ which is HOME. I'm guessing if
you revert the commit, it might fix Santiago's issue.

I believe that the HOME issue Santiago discovered is more important
than reproducibility. The HOME issue is a "must" but reproduciblity in
§ 4.15 [3] is a "should". Files should not be embedding the
build directory (if that was what is happening) and some work may need
to be done upstream to fix that if you want to make the build
reproducible.

[1] -- https://salsa.debian.org/go-team/packages/incus/-/commit/0e9d324dadea33eeae6682786c1beff5764a33da
[2] https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
[3] https://www.debian.org/doc/debian-policy/ch-source.html#reproducibility

Thank you,
Jeremy Bícha

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

#1242812 — Bug#1103554: incus: writes to $HOME during build

retitle 1103554 incus: writes to $HOME during build
tags 1103554 - ftbfs
thanks

Hi. For some reason I can't reproduce the build failure as such, but both Mathias
and myself were able to reproduce the fact that incus writes to $HOME
during build.

I'm therefore changing the subject to better reflect the underlying problem,
regardless of it being also a ftbfs problem or not in some cases yet
to be determined. It does not matter anymore because there is already
a fix for the underlying problem in salsa.

Thanks.

[toc] | [prev] | [standalone]

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

csiph-web