Hi,

I tried to update jupyter-core to 4.10.0, but didn't manage to run the
upstream test suite reliably.

I first disabled it, so the package was building with both dpkg-
buildpackage and sbuild. A bad solution.

Then I re-enabled it ; it passes with dpkg-buildpackage (there's a
catch, see [1]), but not with sbuild, and I couldn't find out why.

If someone has a clue, I'm ready to learn new tricks...

J.Puydt

[1] if python3-pytest-asyncio is installed on your system, you have to
add asyncio_mode = "auto" to the relevant section of pyproject.toml,
otherwise it breaks: pytest autoloads its asyncio plugin, which doesn't
find this settings, hence warns about it, and a warning is an error ;
see: https://github.com/pytest-dev/pytest-asyncio/issues/293

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

Hi Julien,

On Thu, May 05, 2022 at 09:51:28AM +0200, julien.puydt@gmail.com wrote:

Hi,

I tried to update jupyter-core to 4.10.0, but didn't manage to run the upstream test suite reliably.

I first disabled it, so the package was building with both dpkg-
buildpackage and sbuild. A bad solution.

Then I re-enabled it ; it passes with dpkg-buildpackage (there's a
catch, see [1]), but not with sbuild, and I couldn't find out why.

If someone has a clue, I'm ready to learn new tricks...

I've had similar problems in the past. It usually comes down to the
build requiring some package that happens to be present on your system
but not listed in the Build-Depends field, so dpkg-buildpackage works,
but sbuild doesn't. One thing I've done (boring, but has worked in
this sort of case) is to search the code for any occurrences of
"import" (patterns such as r'^\s*import\s' and
r'^\s*from\s.*\simport\s' are useful here); it might reveal a package
not listed in the install requirements.

Best wishes,

Julian

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

Le jeudi 05 mai 2022 à 09:43 +0100, Julian Gilbey a écrit :

I've had similar problems in the past.  It usually comes down to the
build requiring some package that happens to be present on your
system but not listed in the Build-Depends field, so dpkg-
buildpackage works, but sbuild doesn't.

That's indeed the usual suspect ; but here it turns out it wanted a
writable home directory.

I'll check it doesn't break everything then upload... probably
tomorrow...

Thanks!

J.Puydt

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

On Thu, May 05, 2022 at 11:07:31PM +0200, julien.puydt@gmail.com wrote:

Le jeudi 05 mai 2022 à 09:43 +0100, Julian Gilbey a écrit :

I've had similar problems in the past.  It usually comes down to the
build requiring some package that happens to be present on your
system but not listed in the Build-Depends field, so dpkg-
buildpackage works, but sbuild doesn't.

That's indeed the usual suspect ; but here it turns out it wanted a
writable home directory.

I'll check it doesn't break everything then upload... probably
tomorrow...

Thanks!

J.Puydt

Ah, of course, that's the other thing I've hit in recent times with ipython-related packages. Note that writing to the home directory at build-time is a contravention of Policy; see the thread starting at https://lists.debian.org/debian-devel/2022/04/msg00345.html where I
ask about pretty much the same thing, and a clear distinction is made
between build time and autopkgtest time. You mentioned earlier that
it's the tests that are failing; are these build-time tests or
autopkgtest tests? If they're build-time tests, you could either
disable them or create a temporary home directory. If they're
autopkgtest tests, then it depends on your test environment; see that
thread for recommendations and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010437 for a
discussion of how to set up lxc with autopkgtest.

Best wishes,

Julian

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