Hello!

matploblib is currently BD-Uninstallanble on multiple architectures and it's
not easily possible to build the package because there is a circular build
dependency with the package on itself [1]:

(sid-powerpc-sbuild2)root@kapitsa:/# apt build-dep python3-matplotlib
Reading package lists... Done
Picking 'matplotlib' as source package instead of 'python3-matplotlib'
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 python3-matplotlib : Depends: python3 (< 3.9) but 3.9.0-4 is to be installed
 python3-pandas : Depends: python3-pandas-lib (>= 1.1.5+dfsg) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
(sid-powerpc-sbuild2)root@kapitsa:/#

Could you make matplotlib bootstrappable so that porters can bootstrap the
package when it's necessary?

I'm currently stuck with this package and I have no clue how to break the
circular build dependency here.

Thanks,
Adrian

Hello!

It seems that most of the Python dependencies in Build-Depends in debian/control
are optional when comparing those with the build dependencies in openSUSE [1].

I used the brute-force approach now and it built for me on powerpc with those
packages set to <!stage1>:

               python3-all-dbg,
               python3-all-dev,
               python3-cairocffi [!ia64] <!stage1>,
               python3-certifi (>= 2020.6.20-1) <!stage1>,
               python3-colorspacious <!stage1>,
               python3-cxx-dev <!stage1>,
               python3-cycler (>= 0.10.0) <!stage1>,
               python3-dateutil <!stage1>,
               python3-gi <!stage1>,
               python3-ipython <!nodoc> <!stage1>,
               python3-ipywidgets <!stage1>,
               python3-kiwisolver <!stage1>,
               python3-kiwisolver-dbg <!stage1>,
               python3-mock <!stage1>,
               python3-nose <!stage1>,
               python3-numpy <!stage1>,
               python3-numpy-dbg <!stage1>,
               python3-numpydoc <!stage1>,
               python3-pandas  <!stage1>,
               python3-pil <!stage1>,
               python3-pkg-resources <!stage1>,
               python3-pyparsing (>= 1.5.6) <!stage1>,
               python3-pyqt5 [!hurd-i386] <!stage1>,
               python3-pytest <!stage1>,
               python3-scipy <!nodoc> <!stage1>,
               python3-setuptools,
               python3-six (>= 1.4) <!stage1>,
               python3-sphinx <!nodoc> <!stage1>,
               python3-sphinx-copybutton <!nodoc> <!stage1>,
               python3-sphinxcontrib.svg2pdfconverter <!nodoc> <!stage1>,
               python3-tk <!stage1>,
               python3-tk-dbg <!stage1>,
               python3-tornado <!stage1>,

Adrian

Hello,

While at it:

               python3-sphinx-gallery (>= 0.7.0) <!stage1> <!nodoc>,

I believe you meant

               python3-sphinx-gallery (>= 0.7.0) <!stage1 !nodoc>,

So that the python3-sphinx-gallery dep is disable when using the stage1
profile alone or when using the nodoc profile alone. Currently one has
to using both the stage1 and the nodoc profiles to break the

python3-matplotlib -> python3-sphinx-gallery -> python3-matplotlib

loop.

Samuel

Hi Samuel!

You just solved that mystery for me. I was already starting to question
my sanity when the --profile switch didn't work as expected :-).

Thanks a lot for pointer!

Adrian

John Paul Adrian Glaubitz, le jeu. 17 déc. 2020 23:47:42 +0100, a ecrit:

It was driving me crazy in the past couple hours as well, I was
questioning the support in sbuild, in pbuilder, and at the point of
trying mk-build-deps with the nodoc profile instead of the stage1
profile, I at last noticed that the <!nodoc> were working but not the
<!stage1> <!nodoc> :)

Samuel

I guess we'll just need to fix this bug then to make the package bootstrappable.

Adrian

they are not: they are either used to run tests or build the documentation.

this is not good enough, you just marked !stage1 for all the packages
that were on your way. please rework this patch to mark each of those
as either !nodoc or !nocheck where appropriate and run the build with
both profiles disabled; at that point i will be able to merge this.

Regards,

Well, that actually means they are optional for building the package. They should
be marked as <!nocheck> then or <!stage1>

As Samuel already pointed out, the main problem is the incorrect use of
the build profile markers. It should be <!nocheck !stage1> not <!nocheck>
<!stage1>.

So, if you could fix this for the time being, we'd already be a step further.

Adrian

On Fri, Dec 18, 2020 at 2:27 AM John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

many of these b-d predate the introduction (or wide-spread use) of
build profiles and recently introduced b-d are being tagged, so this
is an unhelpful comment.

which, btw, you suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954071

are you saying that is the only problematic b-d that prevents
matplotlib bootstrap?

Hello,

As suggested in an other bug report, moving the build-dependencies that
are only needed to build -doc/arch:all packages to Build-Depends-Indep
would also help here I guess

Kind regards,

Laurent Bigonville

On Mon, 10 Jan 2022 11:06:56 +0100 Laurent Bigonville <bigon@debian.org>  wrote:
 > Hello,
 >
 > As suggested in an other bug report, moving the build-dependencies that
 > are only needed to build -doc/arch:all packages to Build-Depends-Indep
 > would also help here I guess
 >

I've made this merge request:
https://salsa.debian.org/python-team/packages/matplotlib/-/merge_requests/1

I duplicated some of the build-dependencies to make it more clear that
they are needed by both, if that's no OK I can rework my change and only
keep one

but i am not willing to complicate the maintenance of matplotlib by
splitting b-d and b-d-i.

You provide this patch as a one-off, and then i will be the one that
will have to take care of maintaining it forever. that's not something
i'm not willing to commit to.

All of this to support the bootstrap of unofficial ports.
bootstrapping is (AFAICT) a manual operation sometimes.

I'm ok with annotating the current b-d with !stage1 where needed (or
fix the current annotations if they are incorrect), if that
facilitates your work.

Thanks,