bug#64872: guix pull: texlive-hyphen-complete: build failed (was: "guix pull: po4a: build failed")

[Christopher Baines]

Artyom Poptsov  writes:

> Hello,
>
> Sorry for the late reply!
>
> I removed
>   http_proxy=http://127.0.0.1:9080 https_proxy=http://127.0.0.1:9080
> from my "Environment" variable in "guix-daemon.service" and after I restarted
> the Guix daemon "guix pull" and "guix upgrade" went flawlessly.
>
> Thank you for your help.

I'm glad to hear you managed to resolve the issue.

Chris


signature.asc
Description: PGP signature

bug#65056: https://issues.guix.gnu.org/ cannot be accessed through Tor

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

On 13 August 2023 00:25:51 UTC, "Ludovic Courtès"  wrote:
>I think it’s worse than this.  I noticed that ci.guix.gnu.org (same
>machine) would occasionally time out on my side, without Tor, starting
>from this week (I was on vacation before, so I don’t know exactly when
>it started).  From a browser, I get this “DoS attack” HTML page:

Oh, wow.  This is new to me.

It's frustrating that $IT keeps adding new significant hurdles with apparently 
0 communications, and that our only option is often 'ask rekado, again, to ask 
things, again'.  That's not right.

Ricardo, do you think there's a chance this trend will improve (without you 
burning out)?

Otherwise, I'd like to suggest wireguarding berlin's impressive hardware 
resources to bayfront or to a new head node not hosted at the MDC, or something 
similarly provocative.  Just give up on hosting public services there, like we 
already migrated the home page.  This isn't meaningful redundancy.


Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

bug#65218: emacs-orderless 1.0 shows as 0.8 due to incorrect value in package file

[Piotr Kwieciński]

Hi Hilton,
thank you for your swift response and guidance. I'll attempt to send a
patch.
I already started to set up my local environment.

On Sat, 12 Aug 2023 at 18:12, Hilton Chain  wrote:

> Hi Piotr,
>
> On Fri, 11 Aug 2023 04:18:57 +0800,
> Piotr Kwieciński wrote:
> >
> > [1  ]
> > [2  ]
> > I have the latest version of emacs-orderless installed on using guix and
> it shows:
> >
> >  Status: External in
> ‘/gnu/store/mp2ckcr7psy9myby262zqii36cd49yja-emacs-orderless-1.0/share/emacs/site-lisp/orderless-1.0/’
> (unsigned).
> > Version: 0.8
> > Summary: Completion style for matching regexps in any order
> >
> > This is caused by an incorrect version of a package declared in
> orderless.el.
>
>
> It seems that emacs-orderless in Guix wasn't really updated to 1.0,
> only the version field was changed.
>
>
> > I'm new to the ecosystem and I'm not familiar with the process of fixing
> this.
> > The issue was fixed by the package maintainer in commit
> >
> https://github.com/oantolin/orderless/commit/847694e78c12d903d5e3f6cb365a5d3b984db537
> >
> > Would replacing commit in the package definition be enough ? Swapping
> 004cee6b8e01f8eb0cb1c683d0a637b14890600f with
> > 847694e78c12d903d5e3f6cb365a5d3b984db537
>
>
> That's not enough, the hash in (sha256 (base32 [...])) needs changing
> as well.
>
> And when updating an untagged revision to a tagged release, we usually
> drop the outer let form, and use the value from version field for
> commit.
>
> For example, the original definition:
> --8<---cut here---start->8---
> (define-public emacs-orderless
>   (let ((commit [...]))
> (package
>   (name "emacs-orderless")
>   (version [...])
>   (source
>(origin
>  (method git-fetch)
>  (uri (git-reference
>(url "https://github.com/oantolin/orderless";)
>(commit commit)))
>  (file-name (git-file-name name version))
>  (sha256
>   (base32 [...]
>   [...])))
> --8<---cut here---end--->8---
>
> would be changed to:
> --8<---cut here---start->8---
> (define-public emacs-orderless
>   (package
> (name "emacs-orderless")
> (version "1.0")
> (source
>  (origin
>(method git-fetch)
>(uri (git-reference
>  (url "https://github.com/oantolin/orderless";)
>  (commit version)))   ; <- see here
>(file-name (git-file-name name version))
>(sha256
> (base32 [...] ; <- hash is changed as well
> [...]))
> --8<---cut here---end--->8---
>
> BTW the hash can be obtained with `guix hash' [1]:
> --8<---cut here---start->8---
> git clone https://[...] emacs-orderless
>
> cd emacs-orderless
> git checkout 1.0
>
> guix hash -rx .
> --8<---cut here---end--->8---
>
> Would you like to get familiar with the process by going through the
> way [2] to make your first contribution? ;)
>
> I can send a patch if you prefer, and it may take a few days to get
> the change into Guix.
>
> Thanks
>
>
> [1]: <
> https://guix.gnu.org/en/manual/devel/en/html_node/Invoking-guix-hash.html>
> [2]: 
>
> (Not sure why this issue isn't on the mailing list, but is available
> in Debbugs.  Still under moderation?)
>


-- 
Regards
Piotr Kwiecinski

bug#65218: emacs-orderless 1.0 shows as 0.8 due to incorrect value in package file

[Piotr Kwieciński]

I have the latest version of emacs-orderless installed on using guix and it
shows:

 Status: External in
‘/gnu/store/mp2ckcr7psy9myby262zqii36cd49yja-emacs-orderless-1.0/share/emacs/site-lisp/orderless-1.0/’
(unsigned).
Version: 0.8
Summary: Completion style for matching regexps in any order

This is caused by an incorrect version of a package declared in
orderless.el.

I'm new to the ecosystem and I'm not familiar with the process of fixing
this.
The issue was fixed by the package maintainer in commit
https://github.com/oantolin/orderless/commit/847694e78c12d903d5e3f6cb365a5d3b984db537

Would replacing commit in the package definition be enough ? Swapping
004cee6b8e01f8eb0cb1c683d0a637b14890600f with
847694e78c12d903d5e3f6cb365a5d3b984db537

(define-public emacs-orderless
  (let ((commit "004cee6b8e01f8eb0cb1c683d0a637b14890600f"))
(package
  (name "emacs-orderless")
  (version "1.0")
  (source
   (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/oantolin/orderless";)
   (commit commit)))
 (sha256
  (base32 "115bwqi2yc44bgvcl7lha8p2s6jgh5hksn4wa9s0kpfxhi14jwmy"))
 (file-name (git-file-name name version
  (build-system emacs-build-system)
  (arguments
   (list
#:phases
#~(modify-phases %standard-phases
(add-after 'install 'makeinfo
  (lambda _
(invoke "makeinfo" "orderless.texi")
(install-file "orderless.info"
  (string-append #$output "/share/info")))
  (native-inputs
   (list texinfo))
  (home-page "https://github.com/oantolin/orderless";)
  (synopsis "Emacs completion style that matches multiple regexps in
any order")
  (description "This package provides an orderless completion style that
divides the pattern into space-separated components, and matches candidates
that match all of the components in any order.  Each component can match in
any one of several ways: literally, as a regexp, as an initialism, in the
flex
style, or as multiple word prefixes.")
  (license license:gpl3+

-- 
Regards
Piotr Kwiecinski

bug#65266: guix shell ocaml-core ocaml-core-unix gtk fails

[ziyed mstph]

The command
guix shell ocaml-core ocaml-core-unix gtk
fails with
builder for
`/gnu/store/s9snqp54x2g6sp6a600vw2cqs74i5m2v-gdk-pixbuf-loaders-cache-file.drv'
failed due to signal 11 (Segmentation fault).


It works if I do first
guix shell ocaml-core ocaml-core-unix gtk
and then
guix shell gtk



Guix channel:
  guix eb25c2b
commit: eb25c2b3e204a36a97ec724defe8930757ab83c0

bug#65178: Shepherd hangs (was: Getting Guix to shutdown my laptop properly with Sway and no DE)

[Hilton Chain via Bug reports for GNU Guix]

On Wed, 09 Aug 2023 20:41:44 +0800,
Hilton Chain wrote:
> I'm not sure if Shepherd hangs at usual, but most of the time I find
> it already hanging is when doing a reconfiguration.  The
> reconfiguration becomes unresponsive and it won't accept a ^C, herd
> actions also hang.  This usually happens with home reconfiguration,

Today I encountered the home reconfiguration issue.  The behavior is
similar to .

Ending part of output for the hanging reconfiguration:
--8<---cut here---start->8---
[...]
Symlinking /home/hako/.config/fontconfig/fonts.conf -> 
/gnu/store/fvvqbma1xxgisfcq7rrwihbw7jwnyliv-fonts.conf... done
Symlinking /home/hako/.gnupg/gpg-agent.conf -> 
/gnu/store/kfaz4zrxmfz6p72x47c7qrqvb873gbyi-gpg-agent.conf... done
Symlinking /home/hako/.ssh/config -> 
/gnu/store/xb6f584pwclg48fr28wl21v1mxplqp6f-ssh.conf... done
Symlinking /home/hako/.icons/default/index.theme -> 
/gnu/store/3sraq69nrs04ii0fjgk36aw2c57q6z27-icons.theme... done
 done
Finished updating symlinks.


--8<---cut here---end--->8---

And `herd status' also hangs:
--8<---cut here---start->8---
$ herd status

--8<---cut here---end--->8---

bug#65253: Acknowledgement (Renpy-launcher raises exception when opening editor.)

[Jesse Gibbons]

It turns out 'Visual Studio Code (System).edit.py' is required to fix 
this. I recommend a patch that removes the Visual Studio Code (system 
and 'official') and Atom editor options, but that could be just my own 
preference. Please do not remove the None or System Editor options.


Until a patch is sent to fix this issue, concerned users may work around 
it by creating a directory in the configured projects directory and 
copying 'None.edit.py', 'System Editor.edit.py', and 'Visual Studio Code 
(System).edit.py' from the source into that directory. 'Visual Studio 
Code (System).edit.py' can contain the contents of either of the 
alternatives.

bug#64827: texlive is broken

[Nicolas Goaziou]

Hello,

Andreas Enge  writes:

> see the last commit on the wip-texlive-mono branch; the commit message
> and the diff should be quite clear. Concerning the branch itself, it
> can be directly applied to master once it is in shape, as nothing depends
> on the monolithic texlive.

I was talking about changes ported to the modular `texlive-bin'. Those
need a dedicated branch. You're right, the changes are clear enough.

> You mean the old/new monolithic texlive from the wip branch and
> texlive-biber work together? In that case we should indeed drop biber.

I don't know if the monolithic texlive from the wip branch does, but the
current monolithic `texlive' can be installed without fuss alongside
`texlive-biber'. I don't expect additional issues with `texlive' from
the "wip" branch, tho.

Regards,
-- 
Nicolas Goaziou