Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Thorsten Glaser
Source: libmaxminddb
Version: 1.3.2-1
Severity: important
Tags: ftbfs
Justification: fails to build from source on ports architectures


Dependency installability problem for [140]libmaxminddb on sh4:

libmaxminddb build-depends on missing:
- [141]pandoc:sh4

Dependency installability problem for [142]libmaxminddb on x32:

libmaxminddb build-depends on missing:
- [143]pandoc:x32


Please do ensure to only ever Build-Depends-Indep on pandoc
and that the build really only needs it for the arch:all build.

This is now very critical, because bind9 recently gained a B-D
on libmaxminddb ☹
Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Thorsten Glaser-6
On Mon, 6 Apr 2020, Thorsten Glaser wrote:

> Please do ensure to only ever Build-Depends-Indep on pandoc
> and that the build really only needs it for the arch:all build.

Erk. The manpages are built like that upstream, so splitting
them into a separate package is required, which… is irksome.

However:

> This is now very critical, because bind9 recently gained a B-D
> on libmaxminddb ☹

I’ve got another idea. Would you be willing to accept a
Debian-specific (but upstreamable) patch to generate the
manpages with a shell script I’d write? This looks to be
doable easy enough, given it’s just the two files in doc/
and that the -mdoc macropackage supports the semantic
markup used already.

If so I’ll provide it shortly.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Faidon Liambotis-2
severity 956041 wishlist
thanks

On Tue, Apr 07, 2020 at 05:06:02PM +0200, Thorsten Glaser wrote:
> On Mon, 6 Apr 2020, Thorsten Glaser wrote:
>
> > Please do ensure to only ever Build-Depends-Indep on pandoc
> > and that the build really only needs it for the arch:all build.
>
> Erk. The manpages are built like that upstream, so splitting
> them into a separate package is required, which… is irksome.

Indeed, creating a separate package for two manpages is indeed a not a
great investment of time and resources -- not to mention a policy
violation¹ :)
 

> However:
>
> > This is now very critical, because bind9 recently gained a B-D
> > on libmaxminddb ☹
>
> I’ve got another idea. Would you be willing to accept a
> Debian-specific (but upstreamable) patch to generate the
> manpages with a shell script I’d write? This looks to be
> doable easy enough, given it’s just the two files in doc/
> and that the -mdoc macropackage supports the semantic
> markup used already.

I'd prefer to not have to carry a Debian-specific patch that changes the
build system for upstream's documentation. Implementing a simple
Markdown parser for the few elements the docs have right now (sections
and URLs mostly) in shell seems within reach, but it would be
error-prone with regards to any future modifications of those documents.
Breakages would likely slip through and I wouldn't even notice until a
bug report came in.

That said, if the patch is upstreamable, I'd encourage you to submit it
directly to upstream². Assuming it gets merged in some way or form, I
wouldn't mind backporting it before upstream tagged a release.

Thanks,
Faidon


1: §12.1 "Each program, utility, and function should have an associated
manual page included in the **same** package" (emphasis mine)
2: https://github.com/maxmind/libmaxminddb

Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Thorsten Glaser-6
# an FTBFS on a non-release architecture is "important"
severity 956041 important
thanks

On Wed, 8 Apr 2020, Faidon Liambotis wrote:

> Indeed, creating a separate package for two manpages is indeed a not a
> great investment of time and resources -- not to mention a policy
> violation¹ :)

Yeah… just a “should”, but still.

> I'd prefer to not have to carry a Debian-specific patch that changes the
> build system for upstream's documentation. Implementing a simple
> Markdown parser for the few elements the docs have right now (sections
> and URLs mostly) in shell seems within reach, but it would be
> error-prone with regards to any future modifications of those documents.
> Breakages would likely slip through and I wouldn't even notice until a
> bug report came in.

True.

> That said, if the patch is upstreamable, I'd encourage you to submit it
> directly to upstream². Assuming it gets merged in some way or form, I
> wouldn't mind backporting it before upstream tagged a release.

This sounds sensible, if upstream is amenable to merging it, at least
as an alternative. Do you have working relationship with upstream and
could test the waters, so to speak, whether they would merge it, or,
alternatively, accept a one-shot manual conversation of the manpages?

Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Faidon Liambotis-2
severity 956041 wishlist
thanks

On Thu, Apr 09, 2020 at 12:08:34PM +0200, Thorsten Glaser wrote:
> # an FTBFS on a non-release architecture is "important"
> severity 956041 important
> thanks

Stating that the package "FTBFSes on non-release architectures" is
twisting the situation a little bit. The only reason this FTBFSes is
that one of its build-dependencies, pandoc, is not available, in turn
due to what looks like missing build dependencies(?). AIUI, libmaxminddb
would build fine if pandoc was available, right? So unless I'm missing
something, I don't think that asking a package to drop a build
dependency because it hasn't been ported/built yet on a target
architecture is a severity important bug. I also couldn't find a bug
against either pandoc or libmaxminddb's reverse dependcies for this
issue either, so perhaps I'm not understanding fully why is libmaxminddb
special here in this chain of build dependencies.

I consider this an ask to rework/simplify upstreams' documentation build
system. That seems like a very sensible ask (especially given the
limited size of those two documents), but is really a wish rather than a
bug the way I see it. Does that makes sense?

> This sounds sensible, if upstream is amenable to merging it, at least
> as an alternative. Do you have working relationship with upstream and
> could test the waters, so to speak, whether they would merge it, or,
> alternatively, accept a one-shot manual conversation of the manpages?

Not more so than interacting with them on GitHub issues or PRs myself.
They're fairly responsive there, though! I'd rather if you filed an
issue/PR directly, however, to avoid playing a game of telephone :)

Thanks!
Faidon

Reply | Threaded
Open this post in threaded view
|

Bug#956041: libmaxminddb: FTBFS (BD-Uninstallable): Build-Depends-Arch on pandoc

Thorsten Glaser-6
On Thu, 9 Apr 2020, Faidon Liambotis wrote:

> Stating that the package "FTBFSes on non-release architectures" is
> twisting the situation a little bit.

It’s still a fact… and other packages have fixed this by requiring
pandoc only in BD-Indep.

> The only reason this FTBFSes is that one of its build-dependencies,
> pandoc, is not available, in turn due to what looks like missing build
> dependencies(?).

pandoc is written in some language whose compiler needs to be
explicitly ported to each new architecture, and is therefore
a hard blocker for *all* new ports.

> I consider this an ask to rework/simplify upstreams' documentation build
> system. That seems like a very sensible ask (especially given the
> limited size of those two documents), but is really a wish rather than a
> bug the way I see it. Does that makes sense?

Meh, it makes sense, but FTBFS, no matter the reason, is serious
for release architectures and important for non-release ones, but
let’s not play ping-pong considering we both have an agreed way
forward.

> Not more so than interacting with them on GitHub issues or PRs myself.
> They're fairly responsive there, though! I'd rather if you filed an

OK, that’s good. Will do.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg