severity 1103552 important
thanks

Hello.

I have reasons to believe that this might be a bug in sbuild.
Those reasons are:

The failed build logs I keep were created by sbuild 0.89.0.

When I try again with sbuild + unreleased commits from HEAD, the problem
seems to go away.

I'm Cc:ing sbuild maintainers to see if they can look at this and confirm.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

reassign 1103552 sbuild
affects 1103552 src:globus-gram-job-manager
thanks

Hi. After a few more tests, I really think this is a problem in
sbuild which is already fixed in git.

The exact nature I can't determine, but the problem only happens
when using sbuild 0.89.0 with the file backend (i.e. schroot).

When I use sbuild 0.89.0 + pending commits, the problem seems
to go away.

This problem is also difficult to reproduce for me manually,
but I can still reproduce it in my autobuilding setup.

Not sure if that's because sbuild is called by a script
which is a child of cron, or for some other reason.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 2025-04-20 15:12, Santiago Vila wrote:

Hi. After a few more tests, I really think this is a problem in
sbuild which is already fixed in git.

The exact nature I can't determine, but the problem only happens
when using sbuild 0.89.0 with the file backend (i.e. schroot).

When I use sbuild 0.89.0 + pending commits, the problem seems
to go away.

I find it very unlikely that the two commits which currently sit in
"main" on top of what is in unstable are fixing any FTBFS.
One commit fixes a bug of the last upload which prevented a user from specifying an empty (i.e. random) build path.
The other commit fixes a bug which would let sbuild fail to start with
the unshare backend when run in an environment (like docker) where
/dev/console does not exist.

Is the test maybe a bit flaky?

Thanks!

cheers, josch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 20/4/25 a las 15:59, Johannes Schauer Marin Rodrigues escribió:

I find it very unlikely that the two commits which currently sit in "main" on top of what is in unstable are fixing any FTBFS.
One commit fixes a bug of the last upload which prevented a user from specifying an empty (i.e. random) build path.
The other commit fixes a bug which would let sbuild fail to start with the unshare backend when run in an environment (like docker) where /dev/console does not exist.

Sorry, you are right, and I explained it wrong.

The commit which fixes the build problem is this one, which is not in main yet:

https://salsa.debian.org/debian/sbuild/-/merge_requests/176

I created a working sbuild.deb from that, which I
installed in my autobuilders, and they started
to build "globus-gram-job-manager" correctly again.

(This is what I was calling "git version" improperly, sorry for the confusion)

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)