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 one).
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 genera
Hi Stephen,
On Wed, 15 Sep 2021 at 19:32, Stephen Paul Weber
wrote:
> Ah, finally found http://issues.guix.gnu.org/43739 -- guix pull as
> root and all fixed.
Thanks for the follow up.
Does it mean this bug can be closed?
All the best,
simon
If I use guix archive --export --no-grafts then import on another system, then
guix build -n --no-grafts it works as expected. If instead I use guix copy
--no-grafts then the target system gets the version *with* grafts and guix build
-n --no-grafts says it would still need to build.
signature.
Ah, finally found http://issues.guix.gnu.org/43739 -- guix pull as root and all
fixed.
signature.asc
Description: PGP signature
It seems I get the same error even with just guix archive:
$ guix archive --export -r package
... snip lots of output ...
entry(nameunitnode(type
directoryentry(namepromise_spec.rbnode(typeregulacontents�nguix archive: error:
corrupt input while restoring archive from #
signature.asc
De
Sorry for the possible confusion. These replies stacked up in my client and I
didn't notice until they were sent just now. Please disregard :)
Le 14 septembre 2021 07:37:53 GMT-04:00, Julien Lepiller a
écrit :
>Again this is exactly where I was blocked. There is a checksum being generated
>in
Hi,
Currently execution of any system tests with "make check-system
..." seems
to be broken. Tests are getting executed, and their status is
"pass" in
the log. But, some in some place around the test execution, below
exception
is fired.
--8<---cut here---start--
After installing the package perl-lingua-translit and trying to use its
accompanied utility translit the following error appears:
$ translit -l
Can't locate Lingua/Translit.pm in @INC (you may need to install the
Lingua::Translit module) (@INC contains:
/gnu/store/8zvc5mvk0xm3ygrxsgpyy5ilxb5rzj
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 Mercurial, Fossil, BitKeeper;
- decoupled f
I had the same issue on my previous attempt. It seems that using gcc-7 as an
input fixes the issue (although when I tried, I had other fixes like yours
too). Our gcc on core-updates seems to be too aggressive with this old code
base.
Le 13 septembre 2021 09:01:55 GMT-04:00, Guillaume Le Vaillan
Again this is exactly where I was blocked. There is a checksum being generated
in classlist files from java code during the build. The classlist file is
exactly the same as the one in master, so it's correctly generated. Fowever, at
some point, the process needs toqload that file, and that ultim
Aside from not being able to issue ~go tool~ commands, things like
~gopls~[1] are broken as well.
By design, ~GOTOOLDIR~ cannot be set from the user's environment[2].
This commit moved the directory, but did not update the ~GOTOOLDIR~
path.
#+begin_example
$ env |grep GOTOOLDIR
$ go env GOTO
Hi,
Thanks for the report.
IIUC, the package uglify-js from gnu/packages/lisp-xyz was previously
used to minify and now replaced by the new uglifyjs package from the new
gnu/packages/uglifyjs. Then something is incompatible.
I propose to revert to the Lisp JavaScript compressor instead of the
N
And for posterity, here’s the script I used to reproduce the problem:
it’d pick 10 packages at random and call ‘ca-certificate-bundle’ on them.
Since this bug depends on what’s in the store, I’d run it on my laptop,
which only contains a fraction of the 18K packages in Guix, so it would
reproduce
And for posterity, here’s the script I used to reproduce the problem:
it’d pick 10 packages at random and call ‘ca-certificate-bundle’ on them.
Since this bug depends on what’s in the store, I’d run it on my laptop,
which only contains a fraction of the 18K packages in Guix, so it would
reproduce
Hi!
Ludovic Courtès skribis:
> I’m wondering whether this could be due to
> fa81971cbae85b39183ccf8f51e8d96ac88fb4ac somehow.
Confirmed! In essence, ‘map/accumulate-builds’ would return the tail of
its ‘lst’ argument unprocessed when cutoff was reached (ouch!). Fixed:
https://git.savannah
Possibly related to:
https://issues.guix.gnu.org/35296 ‘gdm doesn't start at boot’
The message in Xorg.1.log is similar.
It seems suspicious to me that 'gdm-shepherd-service' doesn't have 'elogind'
in its requirements, but 'sddm-shepherd-service' does. I tried adding
'elogind' but that didn't f
Hi,
On Wed, 15 Sept 2021 at 13:02, Xinglu Chen wrote:
> Agreed, but I guess using the ‘-next’ suffix was be the easiest
> workaround for now.
Yeah but more than often, the workarounds remain longer than expected
and thus they cannot be considered as workaround. ;-)
> Maybe running ‘guix instal
Hi,
this was fixed by the patch from #50588.
Cheers,
Lars
Hi,
Lars-Dominik Braun skribis:
> I started the Guix daemon with only the CI substitute server enabled
> explicitly, disabled local discovery, ran a `guix gc` and tried again. It
> still fails with exactly the same issue.
I’m wondering whether this could be due to
fa81971cbae85b39183ccf8f51e8d9
Maxime Devos schreef op di 14-09-2021 om 14:46 [+0200]:
> Hi,
>
> The GDM service doesn't start anymore. To test, you can use the attached
> xorg-repro.tmpl (guix system vm xorg-repro.tml && run the resulting script).
> QEMU will start, and it will start booting, but nothing graphical will start.
Maxime Devos schreef op di 14-09-2021 om 14:46 [+0200]:
> GDM used to work for me with commit 75a3413b4e5c1f7443eb944a36ff364f4c4085f4,
> but was broken with e9b87da1c3000c53cf9dbf5e737aa4d6546bd909. To be bisected?
The second commit is wrong. Prsumably it should have been
9875f9bca3976bf3576eab
On Wed, Sep 15 2021, zimoun wrote:
> Hi,
>
> On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun wrote:
>
>> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
>> > I have some profiles ghc pinned to a version and upgrading those is
>> > always a mess because Guix tries to b
Hi,
On Wed, 15 Sept 2021 at 09:43, Lars-Dominik Braun wrote:
> > I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> > I have some profiles ghc pinned to a version and upgrading those is
> > always a mess because Guix tries to build the old version from source
> > instead
Hello Zacchaeus.
On Tue, Sep 14, 2021 at 06:33:17PM -0400, Zacchaeus Scheffer wrote:
> I want to put grub-efi-bootloader
> (EFI) on the new drive install (for use on another computer).
With ordinary configuration, I believe installing GRUB EFI for use on
another computer is impossible, because gr
Hi,
> I'd be very much in favor of the latter, or maybe rename it to ghc-next.
> I have some profiles ghc pinned to a version and upgrading those is
> always a mess because Guix tries to build the old version from source
> instead of using the next version.
I renamed ghc@8.8 to ghc-next in commit
27 matches
Mail list logo
