On Wed, Aug 19, 2020 at 05:00:24PM +0200, Thorsten Glaser wrote:
> > I must admit that I find the trade-off proposed by Adrian and Thorsten
> > quite reasonable. I've also looked for more options, but none came to my
> > mind.
>
> I’m actually in favour of one of the other solutions,
> not the
Hi Faidon,
> generating libmaxminddb's manpages with lowdown should be possible. I
> also pushed the lowdown package to NEW, so hopefully by the time that
> reaches the archive, I'll be able to push an even newer upstream that
> can be used by libmaxminddb.
good idea!
> You may be delighted to
On Wed, 19 Aug 2020, Helmut Grohne wrote:
> I must admit that I find the trade-off proposed by Adrian and Thorsten
> quite reasonable. I've also looked for more options, but none came to my
> mind.
I’m actually in favour of one of the other solutions,
not the package split.
But thanks for the
Hi Thorsten,
On Tue, Aug 18, 2020 at 10:51:23PM +0200, Thorsten Glaser wrote:
> That’s because I did a massive hack using versions of
> Haskell from snapshot.d.o and some self-compiled intermediate
> (read: old) versions to make pandoc installable-ish on x32.
> I did the unspeakable there thus…
On Tue, Aug 18, 2020 at 10:12:07PM +0200, Helmut Grohne wrote:
> > I'm not sure whether the package not being a leaf has that much to do
> > with it. Honestly, I feel like blaming libmaxminddb for bootstrappability
> > issues is a bit odd. The chain I think is:
> > isc-dhcp-client(?) -> bind9 ->
On 8/18/20 10:12 PM, Helmut Grohne wrote:
> Thorsten, can you tell more as to what precisely the problem is? I
> looked into https://buildd.debian.org/status/package.php?p=libmaxminddb.
> It doesn't look bd-uninstallable anywhere.
That's because we built the package manually, with the manpages
On Tue, 18 Aug 2020, Helmut Grohne wrote:
> Thorsten, can you tell more as to what precisely the problem is? I
> looked into https://buildd.debian.org/status/package.php?p=libmaxminddb.
It requires pandoc, which is rather unportable.
> It doesn't look bd-uninstallable anywhere.
That’s because
On Tue, Aug 18, 2020 at 09:38:17PM +0300, Faidon Liambotis wrote:
> I understand the overall problem and I do think that Debian being
> bootstrappable is a worthy and meaningful goal for what it's worth!
Thank you.
> I'm not sure whether the package not being a leaf has that much to do
> with
On Tue, 18 Aug 2020, Faidon Liambotis wrote:
> with Haskell being particularly hard to bootstrap. Did I get that right?
That, and unportable, exactly.
> 10KB combined. I disagree that splitting off its two manpages into a
> separate package is the reasonable thing to do here, I'm afraid.
This
On Tue, Aug 18, 2020 at 05:41:26PM +0200, John Paul Adrian Glaubitz wrote:
> As I explained, it's a matter of bootstrappability. Your package is not a leaf
> package which is why this particular problem cannot be ignored. Helmut Grohne
> (CC'ed) who is also working on keeping Debian bootstrappable
On Tue, 18 Aug 2020, Faidon Liambotis wrote:
> If you're looking for ways to help, there is an upstream bug about the
> pandoc dependency -- I think upstream would appreciate any contributions
> folks may have on this particular issue.
Unfortunately, they’re not so willing. All they’d agree to
Hi there,
On Tue, Aug 18, 2020 at 04:17:53PM +0200, John Paul Adrian Glaubitz wrote:
> On 8/17/20 11:36 AM, John Paul Adrian Glaubitz wrote:
> > Therefore, in order to keep Debian bootstappable, please try to get rid of
> > this
> > arch-any build dependency and move it to arch-all.
>
> Just
Hello Faidon!
On 8/18/20 5:27 PM, Faidon Liambotis wrote:
> I don't think two (very small) manpages warrant the creation of a new
> -common package. It would also be both against a policy "should", about
> including the man page in "the same package" (12.1), as well as common
> practice and user
Hi!
On 8/17/20 11:36 AM, John Paul Adrian Glaubitz wrote:
> Therefore, in order to keep Debian bootstappable, please try to get rid of
> this
> arch-any build dependency and move it to arch-all.
Just had a look at the package and I'm wondering what prevents us from building
the
manpages in
Hello!
Sorry for being late to the party.
Thorsten is right that pandoc should not be an arch-any build dependency.
The problem with pandoc is that it requires a very large number of Haskell
packages
to be built before it can be built itself. This means, that pandoc comes very
very
late when
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
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.
# 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…
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
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.
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
21 matches
Mail list logo
