#1093946 espeak-ng: de-key-ify ruby-kramdown etc

Package:
src:espeak-ng
Source:
src:espeak-ng
Submitter:
Chris Hofstaedtler
Date:
2025-01-26 18:15:04 UTC
Severity:
normal
#1093946#5
Date:
2025-01-24 01:33:20 UTC
From:
To:
Hi,

espeak-ng build-depends on ruby-kramdown, which transitively
build-depends on ruby-em-socksify. ruby-em-socksify is rc-buggy, but
cannot be autoremoved because of this transitive dependency chain,
and espeak-ng itself being a key package.

Please consider using any of the other compatible markdown
implementations.

Thanks,
Chris
#1093946#10
Date:
2025-01-24 01:44:55 UTC
From:
To:
Hello,

Chris Hofstaedtler, le ven. 24 janv. 2025 02:33:20 +0100, a ecrit:

Err, does it?  I don't see it appear in apt build-dep ruby-kramdown in a
sid chroot.

Samuel
#1093946#15
Date:
2025-01-24 19:19:41 UTC
From:
To:
espeak-ng 1.52.0+dfsg-4 Build-Depends: kramdown, so yes :)

Chris
#1093946#20
Date:
2025-01-24 19:24:33 UTC
From:
To:
Chris Hofstaedtler, le ven. 24 janv. 2025 20:19:41 +0100, a ecrit:

I still don't understand:

apt build-dep espeak-ng

doesn't bring ruby-em-socksify either.

Samuel
#1093946#25
Date:
2025-01-24 19:28:18 UTC
From:
To:
* Samuel Thibault <sthibault@debian.org> [250124 20:24]:

Yes, this is true. This is a transitive build-dep chain:

espeak-ng   build-depends   ruby-kramdown
ruby-kramdown   build-depends   ruby-stringex
ruby-stringex   build-depends   rails
rails   build-depends   ruby-webmock
ruby-webmock    build-depends   ruby-em-socksify

So you'll never see ruby-em-socksify when building espeak-ng. But
you can change the choice of markdown implementation to influence
the key package set :)

With the available data it's hard to tell if changing espeak-ng
will indeed stop making rails, ruby-webmock, ruby-em-socksify key.
But if you have the cycles, please give it a try.

Chris
#1093946#30
Date:
2025-01-24 19:40:40 UTC
From:
To:
Chris Hofstaedtler, le ven. 24 janv. 2025 20:28:18 +0100, a ecrit:

Ah, ok, uh.

I don't have cycles left. Since years...

I'll be happy to see somebody submit a patch to upstream that fallsback
to another md-to-html processor that would be less trouble (I have no
idea what could be used here, at best it'd be pandoc, which is most
probably really not a good idea :)

Samuel
#1093946#35
Date:
2025-01-24 19:41:22 UTC
From:
To:
Samuel Thibault, le ven. 24 janv. 2025 20:40:40 +0100, a ecrit:

(note: I can commit it upstream, so discussion there won't be a problem)
#1093946#40
Date:
2025-01-24 20:40:12 UTC
From:
To:
Hi

Samuel Thibault schrieb am 24.01.2025, 20:40 +0100:
[…]
[…]

What is the issue with Pandoc? Is it the maintenance burden within Debian?
Otherwise, the tool has been quite reliable from my perspective.

Cheers
Sebastian
#1093946#45
Date:
2025-01-25 01:09:57 UTC
From:
To:
Sebastian Humenda, le ven. 24 janv. 2025 21:40:12 +0100, a ecrit:

Is ghc already a key package?

Samuel
#1093946#50
Date:
2025-01-25 09:17:25 UTC
From:
To:
* Samuel Thibault <sthibault@debian.org> [250125 02:10]:

Yeah I think as a distro we don't want to put pandoc into the key
package set, or if its there, not add new reasons to keep it there.

I'll try to see about another md-to-html converter, we have a few :)

Chris
#1093946#55
Date:
2025-01-25 10:26:34 UTC
From:
To:
Hi

Chris Hofstaedtler schrieb am 25.01.2025, 10:17 +0100:
 […]

Pardon, I wasn't aware of the  consequences. Thanks that you're taking it up.
As a recommendation, python3-markdown might be an option. It probably wouldn't
render all Markdown options, yet should run with just Python with is AFAIK a
key package.

Cheers
Sebastian
#1093946#60
Date:
2025-01-26 18:12:50 UTC
From:
To:
Hello,

Sebastian Humenda, le sam. 25 janv. 2025 11:26:34 +0100, a ecrit:

I guess the espeak-ng documentation would be fine with that. Some sed
bits can probably be used to support integration with the
_layouts/webpage.html template.

Samuel