bug#50595: Faliure in guix import go

Hello, Thanks for your report! Stephen Paul Weber writes: > $ guix import go -r bdd.fi/x/runitor > > guix import: warning: Failed to import package "bdd.fi/x/runitor". > reason: ("struct-vtable" "Wrong type argument in position 1 (expecting > struct): ~S" (#f) (#f)). It seems this is

bug#50606: Add support for other formats of Guix channels

On Thu, Sep 16, 2021 at 02:41:10PM -0300, EuAndreh via Bug reports for GNU Guix wrote: > My proposal was a little more crude: get the channel code from a tarball. In > this model there are no authentications with fingerprint or signed commits, > neither "guix pull" would know much about the

bug#50606: Add support for other formats of Guix channels

EuAndreh skribis: > My proposal was a little more crude: get the channel code from a tarball. In > this model there are no authentications with fingerprint or signed commits, > neither "guix pull" would know much about the before/after state of a channel > besides comparing the checksum of the

bug#50568: Missing source code

Hi Florian, "pelzflorian (Florian Pelz)" skribis: > On Tue, Sep 14, 2021 at 10:38:55AM +0200, Ludovic Courtès wrote: >> Hi, >> >> Maxime Devos skribis: >> >> > The Wayback Machine has some copies of software at >> > https://www.atromatic.net: >> >> Thanks, they’re now all in store on

bug#50568: Missing source code

Hi, zimoun skribis: > On Tue, 14 Sept 2021 at 10:40, Ludovic Courtès wrote: > >> Thanks, they’re now all in store on berlin. > > Do we do the usual trick to save them on SWH? I think their contents are already saved on berlin, just not the tarballs themselves. For example:

bug#50606: Add support for other formats of Guix channels

I'm very much in favor of keeping the current channel implementation leveraging aspects specific to Git, and I also don't think that adding any other DVCS is worth it.

bug#50606: Add support for other formats of Guix channels

In this model, downgrade prevention would a) be inexistant or b) require work from the upstream tarball provider, to produce tarballs with metadata files that could provide such data. Authentication could be done by relying on TLS, or requiring a signature file.

bug#50606: Add support for other formats of Guix channels

I agree with most points, but I'm not proposing creating integrations with other DVCS, en par with the current Git integration. My proposal was a little more crude: get the channel code from a tarball. In this model there are no authentications with fingerprint or signed commits, neither "guix

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

Ludovic Courtès schreef op do 16-09-2021 om 17:20 [+0200]: > +,@(let ((system (or (%current-target-system) (%current-system > +(if (or (string-prefix? "i686-" system) > +(string-prefix? "i586-" system)) (Unrelated to the build failure) you could use target-x86-32?

bug#50625: ghostscript shell scripts refer to unqualified external commands

Hi Guix, Many of the commands, e.g. ps2pdf, provided by the ghostscript package are implemented as shell scripts that do some argument or file name processing before invoking the main gs binary. These scripts invoke external commands like basename, awk, dirname, and even gs by dynamically

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

Hi, Guillaume Le Vaillant skribis: > Ludovic Courtès skribis: > >> On ‘core-updates-frozen’, CMake has one test failure on i686-linux when >> building on berlin (e.g., ): >> >> --8<---cut here---start->8--- >>

bug#50624: Importing (gnu packages lxqt) in gnu/packages/kde-frameworks.scm causes unbound variable error.

I want to use libdbusmenu-qt in kde-frameworks.scm, but just adding #:use-modules (gnu packages lxqt) and running some guix package command results in this. What should I do? Thanks. $ ./pre-inst-env guix show knotifications ;;; note: source file

bug#50605: go: Commit d36c73b8a8f breaks `go tool`

I talked with Sarah in IRC (thanks for the quick response, Sarah!), and we discovered it was because I had set =GOROOT= to ="${GUIX_PROFILE}/share/go". Go will set =${GOTOOLS}= relative to this path. Since Guix sets both of these to sensible defaults, I was able to remove the customization and

bug#50483: [R] Package r-shiny: Shiny server logic inactive

Hello, I am responsible to updating the minify build syste to use the updated uglifyjs (now node-uglify-js found in gnu/packages/uglifyjs.scm). When updating I noticed that some R packages had the input uglify-js (the old lisp one). I chose not mess with them at risk of breaking. What I failed

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

Ludovic Courtès skribis: > On ‘core-updates-frozen’, CMake has one test failure on i686-linux when > building on berlin (e.g., ): > > --8<---cut here---start->8--- > 545/558 Test #518: RunCMake.CPack_TXZ >

bug#32440: localization of guix refresh

Indeed, I didn't notice it was added, and doesn't cause issues. Closing, thanks for the reminder :) Le 16 septembre 2021 03:40:46 GMT-04:00, zimoun a écrit : >Hi Julien, > >On Tue, 14 Aug 2018 at 21:45, Julien Lepiller wrote: > >> I've just found out that guix refresh is not translated.

bug#50596: Cannot get guix copy to work...

Thanks for the follow up. Does it mean this bug can be closed? Yes, thanks.

bug#28173: texlive-texmf-minimal not reproducible

zimoun writes: Hi, On Mon, 09 Oct 2017 at 23:39, Ricardo Wurmus wrote: Ricardo Wurmus writes: texlive-texmf-minimal is no longer needed and should be removed, so I think this bug can be closed. Texlive-texmf-minimal has in fact been removed, but the bug report is still valid.

bug#50606: Add support for other formats of Guix channels

Hi, On Thu, 16 Sept 2021 at 10:18, Ludovic Courtès wrote: > EuAndreh skribis: > > Guix channel authors may want to serve channels: [...] > > - via other DVCS like Mercurial, Fossil, BitKeeper; > > - decoupled from the backing versioning tool. [...] > All in all, I’m not in favor of

bug#28303: “guix import texlive keyval” fails

zimoun writes: Hi, On Tue, 10 Oct 2017 at 08:51, l...@gnu.org (Ludovic Courtès) wrote: Ricardo Wurmus skribis: In the case of “keyval” I don’t know exactly what is wrong, but in general it looks like the importer doesn’t use subversion from the store but expects it to be available in

bug#50617: [core-updates-frozen] CMake fails to build on i686-linux

On ‘core-updates-frozen’, CMake has one test failure on i686-linux when building on berlin (e.g., ): --8<---cut here---start->8--- 545/558 Test #518: RunCMake.CPack_TXZ ***Failed

bug#50243: [core-updates-frozen] "multiple definition of..." build failures

Sarah Morgensen skribis: > arcan-sdl@0.5.5.2-1.b4dd1fb > aris@2.2 > blastem@0.6.2 > crispy-doom@5.8.0 > geeqie@1.5 > glabels@3.4.1 > gmtp@1.3.11 These are fixed in c9f7770eeec3a7b493dcbf45c96a4528f2635604 and following. signature.asc Description: PGP signature

bug#48400: Nyxt build fails because php fails x86_64

Hi, On Fri, 02 Jul 2021 at 18:35, zimoun wrote: > On Thu, 13 May 2021 at 11:24, Bone Baboon wrote: >> On a x86_64 computer Nyxt fails to build because php fails to build. [...] > Do you still have this problem? Two of us reported the build passes. And it is marked moreinfo since 4 weeks,

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

Hi Simon, zimoun writes: > This old bug [1] is about Hydra which is down now, IIRC. > > Does it make sense to keep it open? I think it's okay to close it. I'm doing so now. Thanks! Mark -- Disinformation flourishes because many people care deeply about injustice but very few

bug#50606: Add support for other formats of Guix channels

Hi, EuAndreh skribis: > As I've described in [0], one can't have a Guix channel served over Git's > "Dumb HTTP" protocol. That is caused by libgit's inability to do so [1]. > > Guix channel authors may want to serve channels: > - via "Dumb HTTP" Git repositories; > - via other DVCS like

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

Hi Mark, This old bug [1] is about Hydra which is down now, IIRC. Does it make sense to keep it open? If yes, what could be the actionable next step? On Wed, 21 Nov 2018 at 19:51, Mark H Weaver wrote: > FYI, I just spotted this output from "guix publish" on Hydra. > > Mark > > > GET

bug#33409: guile-ssh build fail when run guix pull

Hi, Sorry for the late reply about guile-ssh and guix pull [1]. 1: On Sat, 17 Nov 2018 at 07:50, "Feng Shu" wrote: > Some deprecated features have been used. Set the environment > variable GUILE_WARN_DEPRECATED to "detailed" and rerun the > program to

bug#28743: guix package dry-run upgrade incorrect behaviour with verbosity

Hi, This old bug [1] is about dry-run. IIUC, it is not now fixed as shown below. However, there is another annoying thing about the option ’--verbosity’. 1: On Sun, 08 Oct 2017 at 10:06, Oleg Pykhalov wrote: > l...@gnu.org (Ludovic Courtès) writes: >

bug#30896: Guix pull problems on armhf

Hi Jelle, On Wed, 21 Mar 2018 at 20:59, Jelle Licht wrote: > I have been running the binary Guix installation on top of Armbian on my > Rockchip RK3288 (armhf) based computing platform. > > Up till about ~8 days ago, guix pull worked as intended. Recently, > running guix pull leads to the

bug#29244: guix update -u always wants to update: python-wrapper & python-ipython

Hi On Fri, 10 Nov 2017 at 14:58, Benjamin Andresen wrote: > this is with an empty user account that has no packages installed before this: >> guixsd% guix package -u >> The following packages will be upgraded: >> python-wrapper 3.5.3 → 3.5.3 >>

bug#33293: Documentation links in guix.info site are broken

Hi Laura, On Tue, 06 Nov 2018 at 18:12, Laura Lazzati wrote: > The latest documentation manual is: https://guix.info/manual/en/ > > However when opening https://guix.info links to documentation, I get a 404 > not found for all the links I tried. > > For instance clicking defining packages in

bug#32440: localization of guix refresh

Hi Julien, On Tue, 14 Aug 2018 at 21:45, Julien Lepiller wrote: > I've just found out that guix refresh is not translated. Indeed, > guix/script/refresh.scm is not listed in po/guix/POTFILES.in as it > should be. Adding it to the file leads to an issue though. One of the > entries generated in

bug#30619: Cuirass requires TLS certificates

Hi, On Tue, 27 Feb 2018 at 17:00, l...@gnu.org (Ludovic Courtès) wrote: > Andreas Enge skribis: > >> the cuirass service requires TLS certificates to do continuous integration >> of guix (or more generally, git repositories served over https). This works >> when nss-certs is installed as a

bug#28303: “guix import texlive keyval” fails

Hi, On Tue, 10 Oct 2017 at 08:51, l...@gnu.org (Ludovic Courtès) wrote: > Ricardo Wurmus skribis: > >> In the case of “keyval” I don’t know exactly what is wrong, but in >> general it looks like the importer doesn’t use subversion from the store >> but expects it to be available in the

bug#50483: [R] Package r-shiny: Shiny server logic inactive

Hi Charles, On Thu, 16 Sep 2021 at 05:57, Charles wrote: > Hello, I am responsible to updating the minify build syste to use the > updated uglifyjs (now node-uglify-js found in > gnu/packages/uglifyjs.scm). When updating I noticed that some R > packages had the input uglify-js (the old lisp

bug#28173: texlive-texmf-minimal not reproducible

Hi, On Mon, 09 Oct 2017 at 23:39, Ricardo Wurmus wrote: > Ricardo Wurmus writes: >> texlive-texmf-minimal is no longer needed and should be removed, so I >> think this bug can be closed. > > Texlive-texmf-minimal has in fact been removed, but the bug report is > still valid. Many of the