Hi Guix,
Using guix 80739ea480a7db667b83b45e3a08be740449f689 on x86_64, running:
`guix environment --ad-hoc racket -- drracket` produces:
```
$bytevector-uncompress: internal error uncompressing
Hi,
On Wed, 10 Mar 2021 at 20:34, joehabel--- via Bug reports for GNU Guix
wrote:
> It was a faulty SD card problem. You can close this, as I can now report that
> Guix got installed properly on Armbian running on the OrangePiPC.
Thanks, so closing.
All the best,
simon
On Wed, 10 Mar 2021 at 15:48, Christopher Howard
wrote:
> I was able to build qucs a week or two ago, but didn't report it. I
> think you can close this bug report. Thank you.
Thanks, so closing.
I was able to build qucs a week or two ago, but didn't report it. I
think you can close this bug report. Thank you.
On Thu, 2021-03-11 at 01:27 +0100, zimoun wrote:
> Hi,
>
> On Thu, 28 Jan 2021 at 09:17, Christopher Howard <
> christop...@librehacker.com> wrote:
> > When I try to install
Hi,
On Thu, 28 Jan 2021 at 09:17, Christopher Howard
wrote:
> When I try to install qucs-s, installation ultimately fails due to build
> failure of dependency
> python2-cairocffi-1.2.0. Apparently python2 is no longer allowed by cairocffi:
Indeed, python2-cairocffi is failing. However qucs-s
Hi,
On Thu, 28 Jan 2021 at 02:09, zimoun wrote:
> On Wed, 27 Jan 2021 at 08:47, "K I" wrote:
>
>> File "pkg_resources/__init__.py", line 1367
>> raise SyntaxError(e) from e
>> ^
>> SyntaxError: invalid syntax
>> command "python" "-c" "import setuptools,
>>
Pushed to maintenance.git as 82b075685b6089c7f98acb0993c003936d833776.
Closing. Thank you all!
Hi Leo,
On Mon, 01 Feb 2021 at 17:31, Leo Famulari wrote:
> As previously discussed during the recent staging cycle, VTK is failing
> to build, which in turn prevents FreeCAD from building:
[...]
> Here's what I wrote during the staging cycle:
>
> --
> For example, the vtk package is
Hi!
Andreas Enge skribis:
> Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Court鑚:
>> Could you instead try the latest patch?
>> https://issues.guix.gnu.org/47007#6
>
> it looks like my reply was missed, I tried this patch, and it solves the
> problem for me, as for Jelle. So please
Hi,
On Wed, 10 Mar 2021 at 12:17, Ludovic Courtès wrote:
>> In guix/scripts/substitute.scm:
>>411:23 2 (lookup-narinfos _ _ #:open-connection _)
>>371:26 1 (fetch-narinfos _ _ #:open-connection _)
>> In ice-9/boot-9.scm:
>> 1669:16 0 (raise-exception _ #:continuable? _)
>>
>>
It was a faulty SD card problem. You can close this, as I can now report that
Guix got installed properly on Armbian running on the OrangePiPC.
Have a good day
Mar 8, 2021, 07:08 by help-debb...@gnu.org:
> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically
Hi,
On Wed, 10 Mar 2021 at 22:11, Taylan Kammer wrote:
> >>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
> >>> and guile2.2-bytestructures builds for me.
> >>
> >> Just to say that the commit breaks "guix pull".
>
> Hmm, I can't seem to reproduce. Guix pull finished
On 10.03.2021 21:55, Taylan Kammer wrote:
> On 10.03.2021 21:12, zimoun wrote:
>> Hi,
>>
>> On Wed, 10 Mar 2021 at 20:12, Taylan Kammer wrote:
>>
>>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
>>> and guile2.2-bytestructures builds for me.
>>
>> Just to say that the
On 10.03.2021 21:12, zimoun wrote:
> Hi,
>
> On Wed, 10 Mar 2021 at 20:12, Taylan Kammer wrote:
>
>> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
>> and guile2.2-bytestructures builds for me.
>
> Just to say that the commit breaks "guix pull".
Ugh, sorry. Looking
Hi,
On Wed, 10 Mar 2021 at 20:12, Taylan Kammer wrote:
> I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
> and guile2.2-bytestructures builds for me.
Just to say that the commit breaks "guix pull".
Cheers,
simon
I just pushed the update to guile-bytestructures 1.0.10 to Guix master,
and guile2.2-bytestructures builds for me.
- Taylan
Hello, running guix pull and then guix upgrade gave me this backtrace.
The version is: guix (GNU Guix) 6e70211b20537b018e639b0114d3ccddd4924acb
Backtrace:
In guix/ui.scm:
2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
633:2 18 (guix-substitute . _)
In unknown file:
John Soo writes:
> I think the problem is that the version bound is too loose in
> cargo.toml upstream. What does the cargo.lock say on the current
> master? I am beginning to think we need to follow the cargo.lock to
> resolve dependencies first if it exists.
It's 0.2.12 in Cargo.toml and
Hey Nicolas,
I think the problem is that the version bound is too loose in cargo.toml
upstream. What does the cargo.lock say on the current master?I am beginning
to think we need to follow the cargo.lock to resolve dependencies first if it
exists.
Thanks,
John
Hello,
John Soo writes:
> I think the breaking tests do actually indicate breaking functionality
> in this case since there is a whole test suite dedicated to the
> bytestring representation.
I use ripgrep daily, and I haven't encountered a regression so far. Of
course, this proves nothing.
>
Hi,
(CC: Ricardo since they is the master about R stuff. :-))
On Tue, 09 Mar 2021 at 19:44, Mark H Weaver wrote:
> We have one notable exception in Guix: "r", which is "grandfathered in"
> so-to-speak, but perhaps it would have been excusable anyway, given its
> prominence and its large
Hello,
Am Wed, Mar 10, 2021 at 12:25:05PM +0100 schrieb Ludovic Courtès:
> Could you instead try the latest patch?
> https://issues.guix.gnu.org/47007#6
it looks like my reply was missed, I tried this patch, and it solves the
problem for me, as for Jelle. So please push.
Thanks!
Andreas
Hi Mark & Tobias,
Mark H Weaver skribis:
> I fully support your proposal to talk about single-character names in
> the manual, and also to check for them in the linter, but perhaps "r"
> should be whitelisted.
Seconded on both points! The patches look great to me.
Thanks,
Ludo’.
Efraim Flashner skribis:
> Some packages we probably don't need to automatically create debug
> outputs for. We could probably drop the debug outputs for all the
> packages that have them in commencement except for the -final ones.
>
> (ins)efraim@3900XT ~/workspace/guix$ du -sch \
>
Hi Andreas,
Andreas Enge skribis:
> incidentally I stumbled upon the same problem as Jelle today.
>
> Am Tue, Mar 09, 2021 at 05:17:10PM +0100 schrieb Ludovic Courtès:
>> Could you try the attached patch?
Could you instead try the latest patch?
https://issues.guix.gnu.org/47007#6
Thanks!
Hi Mark,
Mark H Weaver skribis:
> The problem was fixed upstream in Linux-libre 5.10.21, and presumably
> also in 5.11.4, so I'm closing this bug now.
Woow, that was far from an obvious fix. Thanks a lot!
Ludo’.
Hi,
Tobias Geerinckx-Rice via Bug reports for GNU Guix
skribis:
> ~ $ guix weather --substitute-urls=https://guix.tobias.gr
> computing 16,745 package derivations for x86_64-linux...
> looking for 18,127 store items on https://guix.tobias.gr...
> updating substitutes from
Ludovic Courtès writes:
> Here’s a more sensible patch for you to try. This time it should
> correctly determine the necessary mount flags based on statfs(2) info.
>
> Could you apply it and report back?
I can confirm that it does what it says on the tin :-).
Thanks again!
- Jelle
28 matches
Mail list logo
