Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:

I have uploaded a package yesterday. That package does not have any dh_auto_test
target in d/rules.

The builds all fail, as described here: https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?

I have just stumbled on the same while building a new package with
javahelper:

install: cannot change owner and permissions of ‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d
debian/_jh_build.lucene9-9.4.2 returned exit code 1

However, I have no idea why '-o 0 -g 0' options are used. They do not
seem to be used before.

Andrius

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

On 12/15/22 10:34, Andrius Merkys wrote:

However, I have no idea why '-o 0 -g 0' options are used. They do not
seem to be used before.

Recent changes in debhelper, see:


https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788effff7fdd8731

https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d

Kind Regards,

Bas

--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1

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

Greetings, fellow Debianites,

I have uploaded a package yesterday. That package does not have any dh_auto_test
target in d/rules.

The builds all fail, as described here: https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.

Any soul to help me with this question?

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁ Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄⠀⠀⠀⠀ http://msxpertsuite.org
http://www.debian.org

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

On 2022-12-15 11:44, Sebastiaan Couwenberg wrote:

On 12/15/22 10:34, Andrius Merkys wrote:

However, I have no idea why '-o 0 -g 0' options are used. They do not
seem to be used before.

Recent changes in debhelper, see:

https://salsa.debian.org/debian/debhelper/-/commit/ca66cf4bc74fe31b3d5c8131788effff7fdd8731

https://salsa.debian.org/debian/debhelper/-/commit/e41b7d15c4b005def732cb9f82ed14171499689d

Thanks for prompt response. Thus the issue is resolved in debhelper 13.11.3.

Best,
Andrius

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

Andrius Merkys:

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:

I have uploaded a package yesterday. That package does not have any
dh_auto_test
target in d/rules.

The builds all fail, as described here:
https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?

I have just stumbled on the same while building a new package with javahelper:

install: cannot change owner and permissions of ‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d
debian/_jh_build.lucene9-9.4.2 returned exit code 1

However, I have no idea why '-o 0 -g 0' options are used. They do not
seem to be used before.

Andrius

Long story short:

* Bug in fakeroot (#1023286 + #1024544)
* Me thinking it was a bug in debhelper so I tried to fix it
(which did not work and broke on the way in)
* Me realizing it was a bug in fakeroot and my change did not
even function as a work around, so I undid it (it broke on
the way out as well).

And the winners are: All the people that have (and are) able to use "Rules-Requires-Root: no" as packages with that flag would have been
completely unaffected by this entire ordeal!

Your options include:

* Migrate to "Rules-Requires-Root: no" if you can
* Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even more packages buildable with "Rules-Requires-Root: no".

Thanks,
~Niels

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

Greetings, Niels,

On Thu, Dec 15, 2022 at 10:59:10AM +0100, Niels Thykier wrote:

Andrius Merkys:

Hello,

On 2022-12-15 11:20, Filippo Rusconi wrote:

I have uploaded a package yesterday. That package does not have
any dh_auto_test
target in d/rules.

The builds all fail, as described here: >>>https://buildd.debian.org/status/package.php?p=minexpert2
and I do not understand why.
Any soul to help me with this question?

I have just stumbled on the same while building a new package with >>javahelper:

install: cannot change owner and permissions of >>‘debian/_jh_build.lucene9-9.4.2’: Operation not permitted
jh_build: error: install -m0755 -o 0 -g 0 -d >>debian/_jh_build.lucene9-9.4.2 returned exit code 1

However, I have no idea why '-o 0 -g 0' options are used. They do
not seem to be used before.

Andrius

Long story short:

* Bug in fakeroot (#1023286 + #1024544)
* Me thinking it was a bug in debhelper so I tried to fix it
(which did not work and broke on the way in)
* Me realizing it was a bug in fakeroot and my change did not
even function as a work around, so I undid it (it broke on
the way out as well).

And the winners are: All the people that have (and are) able to use >"Rules-Requires-Root: no" as packages with that flag would have been >completely unaffected by this entire ordeal!

Your options include:

* Migrate to "Rules-Requires-Root: no" if you can
* Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even
more packages buildable with "Rules-Requires-Root: no".

Thank you so much for the explanation. I'll go the Rules-Requires-Root: no route!

Sincerely,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁ Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄⠀⠀⠀⠀ http://msxpertsuite.org
http://www.debian.org


-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFMwThfW1Bndm0ZRQatITXaUz0IFAmOa/uIACgkQQatITXaU z0LwHhAAmFT4EC3tAT1sKoPw6aINeZ7aF2IASoszwc0C4nbLHe2pWUplW8P12RUe KKaJHF5NNx+9oxnH1eYSrtwnf0LzuQblcUuTxz4/be3ffrTKbqc8EdX7xiNwFzyV RSNUmRDKHFTzK1nuXYzmTi4efcVw/Vk5R+Zx56vSKqTttuY/iCOfzrqbugCxwJt3 gj+aHqfE3ivWlNn/o9UHA5wH9IHJ3IWd1nMztEctBwyCyMpz5f2F0SzSJ/Nkvobm Jv0YHFTDIsdOVHAF15s0YPmoCSJXwALhSx/9pYdTyEh5S0aJCDpy1CtCbC6QLuIG mxCjKvJgoWtYUF/bNwfh4054qM9E5jITXi6glyMacoaAEfAbaTH0936im6eMa+o8 6qryrb6RCkjGfqsVddqfBbRRSXRu06yUd/8nFvYU+CKhBeonLYzDPrmrH8o8hGKF HC+K+ioI8UXPgkREBw3iSjTqoicelVYn13kp5qT2MLfMnmo5/QZPzc/vISYPQUMY SUg/ORBfKJUBqz+6lWCFNB3n2QH/+AP1cu3uo7d2rBEfiXEjKD0bKHGsTgBRLEHj CRoPaw1RQ5cw8EHUcJu+JQbLRlmfVQwWpBKgpS97TUbTkX58I5tkOkvOF+IEMqCC XnK7PXiSXiFNvHo5Ocj6FaD3I+nPGpNe0

Quoting Niels Thykier (2022-12-15 10:59:10)

Long story short:

* Bug in fakeroot (#1023286 + #1024544)
* Me thinking it was a bug in debhelper so I tried to fix it
(which did not work and broke on the way in)
* Me realizing it was a bug in fakeroot and my change did not
even function as a work around, so I undid it (it broke on
the way out as well).

And the winners are: All the people that have (and are) able to use "Rules-Requires-Root: no" as packages with that flag would have been completely unaffected by this entire ordeal!

Your options include:

* Migrate to "Rules-Requires-Root: no" if you can
* Ensure you have debhelper (>= 13.11.3~) ("just uploaded") or
debhelper/13.11.1 (or debhelper << 13.11)

I will now go back to looking more at my prototype for getting even more packages buildable with "Rules-Requires-Root: no".

the original cause of all of this is the fakeroot bug since glibc 2.34, specifically since coreutils was rebuilt with glibc 2.34.

This is a call for help. Please have a look at #1023286 and #1024544.

Back in August, glib 2.34 reached unstable. In October, coreutils 9.1 was uploaded and used the new glibc functionality. Since then, calls to chown and other utilities use some new glibc functions on armel, armhf and i386, namely __stat64_time64, __fstatat64_time64 and __lstat64_time64.

Clint quickly fixed the problem and I submitted a test case so that this kind of issue does not fly under the radar again in the future. The test case seems to be working because now we get a build failure on mipsel because the test is not passing.

So something else is missing. It's likely another glibc function that is mipsel-specific. I tried to run ltrace on a mipsel porterbox to figure out what library calls are done by coreutils chown on mipsel but that failed with "unexpected breakpoint" errors, see #1023436.

Maybe somebody can find out what is wrong with fakeroot on mipsel? Since fakeroot is a central part of Debian package builds, it would be a shame to have this bug open for much longer...

Thanks!

cheers, josch
--==============�30171072749043341=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmOa/1kACgkQ8sulx4+9 g+F06RAAiPb9ag432rebd/ITzJG93m+v5/jsEB7VoY+gT7lMNaOYHgqaK8Qc2fu/ pGIc79tbUONGzgQJJwqnejPc5zyWl05ChZQKImJBcnUU1sOR6s2MpDVrDx9YrwNh WlQFvsL33FI1rMZlHvtWxWaol0eUA5ceklcqYkWM09Tc7RlJJ/h54uwi+kr22oyp jCjFCni+4oumrzcE+ye+8DlcjgFY/2Ps/V91LrnCvrbzym8FhQoyGCVajF40gDEq YfqVYERJm/8mdtJoBwx0Tw4DxDNHXJxtYjrO4aatkvXLQcYJN6FgWgfltkNno+Up X+1SUne4gHfAGz34IKUsjB0jN+oDXmXR1QBmZY+ZTb9Wzv6eyi+dZ1YJCdMEu9GX qxmoMhL/ZWM1mIpdHboT9c1VrgXdi0zp467fbCde1DxSwnZTiwNXAqSts71rxcZ5 MEtk8KeKK1k6tOurv2aB25LXp27gm+O21jfI0Zz7gLocG7gWmX3JsYhjYaFLQ7AK BYJnTUD+aGuaQQ7J/nJW7qsThvD5XCuhAhLIZcDlXuuomPLKVcc8BAAIphZkFwyi NWZrIUZtvM6xLJwkTni9l7Mk2xlTtdq0/pwIdrgzQ2MaavKpVRGZ9Af3FQJD+x5C GxhJtAqIX1sO8NSQBJcBTwNTf0seqOFMyJQTkNk/wzfn0aNrQEU=
=CH9Y
-----END PGP SIGNATURE-----

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

Hi Niels,

Thanks for the explanation (snipped here).

On 2022-12-15 11:59, Niels Thykier wrote:

Your options include:

 * Migrate to "Rules-Requires-Root: no" if you can

Great, this indeed gets around the issue.

Best wishes,
Andrius

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