On 5/4/23 11:33 AM, Kaelyn wrote:
Regarding solutions, I would prefer to have libstdc++ in it's own package or
output rather than bundled into gcc-toolchain:out; it feels messy and against
the grain of isolating programs in containers if I have to make the gcc and g++
compilers available in
On Mon, Aug 29, 2022 at 1:29 PM zimoun wrote:
> Do you mean update the «Building from Git» section?
Yes this is what I mean.
Maxime Devos writes:
> Maybe ./configure somehow picks up an old g++ from outside the "guix shell"
> environment.
This turned out to be the issue. I discovered my shell startup files were
mis-configured by running `guix shell --pure --check -D guix`. This is
definitely a user error, and my
Thanks, Maxime!
Does the location of the `--pure` flag matter? I.e. I was running
`guix shell -D guix --pure` (suggested by the manual)
and you're suggesting
`guix shell --pure -D guix'
On Fri, Aug 26, 2022 at 1:02 PM Maxime Devos wrote:
>
> On 26-08-2022 19:32, Katherine Cox-Buday
It gives me this error: configure: error: C++ compiler 'g++' does not
support the C++11 standard
I have to run `guix shell -D guix gcc-toolchain@12.1.0 --pure` to get
./configure to work.
Since `guix shell -D` includes the development packages for Guix,
maybe the package needs updating?
Brice Waegeneire writes:
> Good catch! This patch fixes the reported issue, I've tested it with
> success.
Thanks, Brice! This looks great!
--
Katherine
The shepherd libvirt service contains ways to configure "listening mode" (i.e.
listening over TCP) capabilities, but contains no way to actually turn this
feature on, despite referencing[1] an unimplemented `listen` option:
> You must set listen for this to have any effect.
>From libvirt's
I thought I'd chime in with another data-point:
- Lenovo ThinkPad T480s
- Normal BIOS
- Vanilla Linux kernel(s)
- kernel v5.15.16 boots fine; everything after seems to hit this bug
- Turning off bluetooth in BIOS seemed to get boot further
- Turning off wifi in BIOS allows me to boot
The spec
Pierre Langlois writes:
> I was planning on reporting it upstream when I get some time this week,
> I couldn't see any existing issue, I'm surprised nobody noticed though,
> unless it could be a guix-specific issue?
>
> It doesn't look like a big deal though, it's still perfectly
> usable :-).
It looks like it expects a ~/test.org file to be present and prompts for user
input when that is not the case.
#+begin_example
10:17 katco says: guix build emacs-org-super-agenda
The following derivation will be built:
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
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
*Observed Behavior:*
Invoking `guix deploy my-config.scm` will store `my-config.scm` in the
deployed server's store, and links that as
`/run/current-system/configuration.scm`.
*Expected Behavior*
I expected the deployed server to only be made aware of the requested
`operating-system`
I am also seeing this behavior. Further, using =guix copy= on the offending
store item doesn't seem to help as it seems like each invocation of
=guix deploy= is generating a new version of this file in the store.
As such, I cannot specify =(build-locally? #f)= in my machine configuration.
--
Thank you both! I was not aware that this belonged in the firmware
field and not the packages field. This has solved the error message
during boot. Further, adding the kernel argument successfully sets my
region as US on boot.
tags 49611 notabug
close 49611
This is not part of the bug per-say,
Attempting to do this manually with crda fails as well:
#+BEGIN_EXAMPLE
$ guix environment --ad-hoc crda
[env] $ sudo COUNTRY=US crda
Failed to set regulatory domain: -7
#+END_EXAMPLE
On Sat, Jul 17, 2021 at 4:45 PM GNU bug Tracking System
wrote:
>
> Thank you for filing a new bug report with
#+BEGIN_EXAMPLE
[8.280462] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[8.282686] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[8.284394] platform regulatory.0: Direct firmware load for
regulatory.db failed with error -2
[8.284415]
Ludovic Courtès writes:
> Katherine Cox-Buday skribis:
>
>> Ludovic Courtès writes:
>>
>>> Unfortunately that’s not enough.
>>>
>>> Like NFS, CIFS requires special support, which is currently missing from
>>> (gnu build fil
Ludovic Courtès writes:
> Unfortunately that’s not enough.
>
> Like NFS, CIFS requires special support, which is currently missing from
> (gnu build file-systems).
I apologize if I'm missing something, but this is the bug I'm attempting
to report.
--
Katherine
With a file-system declartion of:
#+BEGIN_SRC scheme
(file-system
(mount-point "/home/user/foo")
(device "//server/foo")
(type "cifs")
(options "username=user,vers=2.0,uid=1000,gid=988")
(check? #f)
(create-mount-point? #t)
(mount-may-fail? #t))
#+END_SRC
I get the following error:
It looks like it's failing when trying to build a dependency,
python-gssapi-1.6.5. Here's the log:
#+BEGIN_EXAMPLE
starting phase `set-SOURCE-DATE-EPOCH'
phase `set-SOURCE-DATE-EPOCH' succeeded after 0.0 seconds
starting phase `set-paths'
environment variable `PATH' set to
Efraim Flashner writes:
>> Your comment is kind of scary though! Shepherd is the thing I want to
>> stay up no matter what since it's responsible for monitoring and
>> restarting things. The idea that a misbehaving or poorly written service
>> could bring down the entire Shepherd process is a
#+BEGIN_EXAMPLE
10:06 katco says: guix --version
guix (GNU Guix) c660779722f4130e95cda89c0eb0cff534a89ef2
#+END_EXAMPLE
I am packaging a system called ~sbcl-1am~, and I discovered that unless
I make the package name longer, I receive this cryptic error when
issuing ~guix build -L. sbcl-1am~:
Efraim Flashner writes:
> On Wed, May 20, 2020 at 09:59:03PM -0500, Katherine Cox-Buday wrote:
>> I am running shepherd as a userspace service manager on an alien distro.
>> Occassionally (often enough as to cause concern), Shepherd is crashing.
>> I am unable t
I am running shepherd as a userspace service manager on an alien distro.
Occassionally (often enough as to cause concern), Shepherd is crashing.
I am unable to narrow down a cause, but anecdotally, it seems to happen
more often when a service it's managing fails repeatedly and is
disabled.
I'm
$ guix --version
guix (GNU Guix) 4227a73189b78b0357f611cd1b1f3eab93677caa
$ guix environment --pure --ad-hoc docker-compose -- docker-compose
Traceback (most recent call last):
File
I was receiving X.509 certificate errors when attempting to run `guix
download`. After investigating, I found that it was because my
`SSL_CERT_DIR` environmental variable had two paths separated by a
colon. The two paths were actually the same. After removing the second
path, `guix download` began
27 matches
Mail list logo
