bug#73142: Erroring libsixel package's bash completions for img2sixel

[elaexuotee--- via Bug reports for GNU Guix]

Hey!

The recent move of libsixel into mpv's propagated-inputs surfaced a bug in
our libsixel's bash completions. My bash sessions now start with an error:

-bash: have: Command not found

This was introduced in commit 43df0d83 from https://issues.guix.gnu.org/72180.
In particular, tracing with `set -o xtrace' show that it originates in the
first command of share/bash-completion/completions/img2sixel:

have img2sixel

Upstream has a relevant issue: https://github.com/libsixel/libsixel/issues/81.
Our configuration step might need to set --with-bashcompltiondir.

- BW

bug#73030: bug#73076: Inputs for git:send-email

[Simon Tournier]

Hi Andreas,

On Fri, 06 Sep 2024 at 18:15, Andreas Enge  wrote:

> I think this may be a consequence of the recent core-updates merge.

Duplicate of .

Fixed by acba6223b5268ece0c6cb4b1ce346f5dc5e8affc.

Closing.

Cheers,
simon

bug#73142: Erroring libsixel package's bash completions for img2sixel

[elaexuotee--- via Bug reports for GNU Guix]

It appears that share/bash-compltion/bash_completion performs an
`unset -f have' at the end of the script. This means that only the scripts
under /etc/bash_completion.d/ have access to `have', but said directory doesn't
even exist in our case.

That said, `have' is deprecated in favor of `_have' in 2.11, anyway. I have let
upstream libsixel know, but we could work around the issue with a
single-character patch:

diff --git a/converters/shell-completion/bash/img2sixel 
b/converters/shell-completion/bash/img2sixel
index 028651b..d96a326 100644
--- a/converters/shell-completion/bash/img2sixel
+++ b/converters/shell-completion/bash/img2sixel
@@ -1,6 +1,6 @@
 # bash completion for img2sixel

-have img2sixel &&
+_have img2sixel &&
 _img2sixel()
 {
 local cur prev

bug#73155: ruby-net-smtp-0.3.3 fails to build

[Tomás Ortín via Bug reports for GNU Guix]

`ruby-net-smtp` fails to build during the `check` phase, apparently due 
to an expired certificate. The certificate seems to be bundled with the 
package, so I suppose this means the package needs to be updated.


```
Error: test_enable_starttls(Net::TestSSLContext): 
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 
peeraddr=empty-path-AF_UNIX-sockaddr state=error: certificate verify 
failed (certificate has expired)

```

bug#73155: ruby-net-smtp-0.3.3 fails to build

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Hi Tomás,

Unfortunately, updating the package to a version with a renewed certificate is 
not a solution.  It merely resets the same 'time bomb' to explode later down 
the road.  It's bad enough that nobody will be able to build a tested 
ruby-net-smtp@0.3.3 again, at least until Linux can virtualise a wall clock.

Fortunately, it appears that upstream has since added the exact commands needed 
to regenerate the certificates: 
.  We 
can generate new ones at build time.

I only wonder whether openssl would stall on build machines with insufficient 
entropy available, or whether that's not an issue.

Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.