inimized between the "vanilla" linux-libre and
customized linux-libre-arm64-generic outside of device compatibility
changes to reduce surprises like this.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
es [3].
[1]: https://ci.guix.gnu.org/build/4711550/log/raw
[2]: https://mail.gnu.org/archive/html/guix-devel/2021-08/msg00077.html
[3]: http://linux-libre.fsfla.org/pub/linux-libre/releases/
CC'ing Christopher Baines since this deals with substitutes.
--
Take it easy,
Richard Sent
Making m
could simply be a
system build-time check to confirm that the kernel's .config file does
in fact have those options set.
[1]: https://issues.guix.gnu.org/66355
[2]: https://issues.guix.gnu.org/43078#2
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
gnu.org/archive/html/help-guix/2023-03/msg00121.html
[2]: https://lists.gnu.org/archive/html/help-guix/2024-05/msg00160.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
"add support for a specific board on this platform", which to me feels a
bit like a hacky solution. See linux-libre-arm64-generic and the
Pinebook Pro comments. I'd think that would belong in a
linux-libre-pinebook-pro or similar.
--
Take it easy,
Richard Sent
Making my computer w
ntist, but that error looks very similar to the error
found when building from the CLI. Given that cuirass-configuration has
fallback #t, it should be recoverable.
Possibly related: [2] and [3]
[1]: https://issues.guix.gnu.org/23103
[2]: https://issues.guix.gnu.org/55820
[3]: Guix 3f59fd6d114548480c7
ould catch errors during record creation instead of service creation,
as well as still perform validation if anything else does or will use
those records in the future.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
ause another
failure. I haven't investigated beyond that.
bqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv.gz
Description: emulated_failure_log
bqi2shgn2a99zmwbiqp1kaa7x0zpik-elogind-252.9.drv.gz
Description: native_success_log
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
tartup() failed: -110FAILED: -110ethernet@1603 Waiting for PHY auto
negotiation to complete. TIMEOUT !
phy_startup() failed: -110FAILED: -110ethernet@1604 Waiting for PHY auto
negotiation to complete. TIMEOUT !
phy_startup() failed: -110FAILED: -110StarFive #
StarFive #
[1]: ht
but it boots now.
Very strange, but seemingly the issue is resolved. I wonder if anyone
else will encounter it in the future.
Thanks!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
4.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Richard Sent writes:
> Trying to pass --fallback on the command line has no effect, even though
> both the documentation and [1] imply that should work.
This issue might have some spiciness to it. I have two machines with
identical guix commits and --fallback works on one but not the
ror: corrupt input while restoring archive from #
--8<---cut here---end--->8---
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
whatever issue is going on here seems to cause [2].
The actual issues are distinct.
[1]: https://issues.guix.gnu.org/71133
[2]: https://issues.guix.gnu.org/71160
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
New issue opened at https://issues.guix.gnu.org/71214. I'l close this
one. Thanks!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
;)
("/gnu/store/7xiwhrv7x4isj2860par69xas9lrk4av-sbcl-cl-ppcre-2.1.1" .
"/gnu/store/h7r9c6wxm7d3yk803jyw86c0pr86rxcj-sbcl-cl-ppcre-2.1.1")))
(map (match-lambda ((name . file) (cons
(assoc-ref old-outputs name) file))) %outputs (graft old-outputs %outputs
mapping)))--8<---cut here---end--->8---
Different builders? Different outputs. Different outputs? Different
50-stumpwm.conf files. Different 50-stumpwm.conf files? Sadness.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Hi Guix!
I believe I found another instance of this bug coming back to haunt
unfortunate, wayward souls. (including me! ðŸ˜).
https://issues.guix.gnu.org/62890
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Richard Sent writes:
> Packages that depend on say, A:lib graft their own copies of A:lib that
> is distinct from grafting A:out and A:lib together. This behavior
> confuses asdf-build-system and leads to breakage.
I should rephase this. asdf-build-system is doing its job just fine
u.org/66786
[2]: https://issues.guix.gnu.org/48903
[3]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00150.html
[4]: https://issues.guix.gnu.org/70244
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
int in the install, although the actual error is different.
See installer-dump-22e789d5.
What the heck is going on here? Those two images are wildly different
and are downloading wildly different sets of substitutes.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Richard Sent writes:
> What the heck is going on here? Those two images are wildly different
> and are downloading wildly different sets of substitutes.
Bad news. I connected my device to a different network with just an
ordinary consumer router and the installation succeeded (using th
Richard Sent writes:
> 1. There was a transient network issue for ~3 hours when I attempted to
> install Guix ~4 times using different installation media that caused a
> specific TLS handshake to fail.
>
> 2. A specific TLS handshake Guix undertakes during the installation
>
that looks much easier said than done. It hasn't progressed
beyond the "huh, I wonder" phase.
Funny, I just started investigating the grafting code myself to see if I
could understand what's going on and I stumble upon this 3 year old
issue just an hour after Maxim comments.
--
T
-cut here---end--->8---
This is unfortunate because it hurts it's usability as part of a CI
system. Pipelines using time-machine are filled with excess logging
messages that aren't always needed and can't be disabled unless output
redirection is available.
--
braltar :) srht-readme [env]$
--8<---cut here---end--->8---
This problem seems unique to guix shell.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
end--->8---
This would make log files much easier to parse. Instead of having
potentially thousands of lines printed to the console per "build stage",
it would be limited to 2.
[1]: https://builds.sr.ht/query/log/1238029/update-readme/log
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
's stderr.
1. Challenging to get right and this may have unforseen consequences.
Two processes writing freely to the same output at once is a bad idea.
2. The daemon has a isatty? check and sets a flag for the build agent
which is passed along to scripts/substitute.
--
Take it easy
I was informed that the link I mentioned in the first issue is
nonpublic. Here's the definitely public build output that demonstrates
the problem, albeit in trimmed form:
https://builds.sr.ht/~freakingpenguin/job/1238029
--
Take it easy,
Richard Sent
Making my computer weirder one commit
Some download links on https://guix.gnu.org/en/download/latest/ return a
JSON payload containing the following content:
> error "Could not find the requested build product."
This occurs for the links under "GNU Guix System on Linux" and "GNU Guix
System on GNU Hurd&
Christopher Baines writes:
> I've investigated this now
Thanks for looking into this!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
nt one can set GUILE_LOAD_PATH manually to work around this
issue. In my opinion this isn't very discoverable. Furthermore, it can't
_cleanly_ handle cases when GUILE_LOAD_PATH is already set or needs
multiple entries. It also makes certain commands with bash builtins
(like time...) awk
2], a good starting point is for
a new home generation to be created when activating a new system while
using guix-home-service-type.
[1]: https://issues.guix.gnu.org/69781#5
[2]: https://issues.guix.gnu.org/69781#6-lineno22
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
te. With --strict,
the current behavior is used.
Alternatively, a cleaner but potentially more involved solution may be
adding a --only-substitutes or similar flag to all commands that can
initiate builds.
[1]: (info "(guix) Substitution Failure")
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
efi bootloader installation on sbcs) ahead of
time on an external machine, so I feel there is a valid use case here.
If nothing else, I'd like a warning to be emitted if an
operating-system's file-system structure does not match what $ guix
system image generates.
--
Take it easy,
Richar
to an overly aggressive GC setting
that was temporarily enabled to save disc space. Looks like it's solved
now; I'll close this issue.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
The fix looks good to me. I don't have commit access so you may want to
send it off to guix-patches so it's not lost.
(info "(guix) Submitting Patches")
If you can, please submit in plaintext. The formatting here looks odd. :)
--
Take it easy,
Richard Sent
Making my compute
rs from the package definition using the
> field properties.
>
> See <https://issues.guix.gnu.org/71697#1>.
[1]: https://lists.gnu.org/archive/html/guix-devel/2024-06/msg00192.html
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
between
to to to
and the unfamiliar VHash structure, couldn't quite
iron it out to handle arbitrary depths. Unfortunately that code is lost,
but I'll give it another try sometime if no one else gets to this first.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
https://logs.guix.gnu.org/guix/2024-06-28.log.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
fun one to debug. Very informative 🙂. I spent far too
long bisecting a big Guix commit list before realizing this was ALSO a
grafting issue.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
le involved in the 29.4 upgrade so they are aware of
my pet theory. I don't have a smoking gun. Like I said, it's just a
hunch. Thanks for your work! :)
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
assert len(difference.details) > 0
E assert 0 > 0
E+ where 0 = len([])
E+where [] = .details
tests/comparators/test_openssh_pub_key.py:70: AssertionError
--8<---cut here---end--->8---
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
#x27;this-should-error home-redshift-service-type
"According to all known laws of aviation..."
--8<---cut here---end--->8---
[1]: https://lists.gnu.org/archive/html/help-guix/2024-07/msg0.html
--
Take it easy,
Richard Sen
rvice can be
extended with any value regardless of whether that value is used or
coherent. Ergo there's no way to check if any particular extension is
valid.
$ make check-system TESTS=cgit is a good way to verify behavior in this
context.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Issue reported upstream at
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/382.
Fixed in 0743d63f85f298131e78045ec6d73acdc50b97eb (confirmed) which will
likely be part of a 272 release.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Richard Sent writes:
> At present one can set GUILE_LOAD_PATH manually to work around this
> issue. In my opinion this isn't very discoverable. Furthermore, it can't
> _cleanly_ handle cases when GUILE_LOAD_PATH is already set or needs
> multiple entries. It also makes cert
>> In terms of side-stepping the question, do we have enough x86_64
>> hardware to continue to support i686 without degrading support for
>> x86_64? (I ask this seriously, although I'm pretty certain the answer is
>> we're well covered on that front.)
>
>Support does not just mean dedicating build
n a custom
config, or a 3rd party channel, user-facing functionality will be lost
if we remove them.
Breaking changes are okay, and if we consider this too niche of a use
case or too high of a maintenance burden it should be dropped. I do
believe it should progress into the consideration stage i
On July 30, 2024 6:50:12 PM EDT, aurtzy wrote:
>Hi Daniel,
>
>> Running M-x magit-branch generates the following error:
>>
>> transient-setup: Symbol’s function definition is void:
>> transient-prefix-object
>>
>> In order to reproduce:
>>
>> guix shell emacs emacs-magit -- emacs -Q
>>
>> M-x magi
I can confirm the same issue with git send-email.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Did some more testing and I was able to find a workaround for my version
of this issue, although I don't know if it'll solve it for others. TL;DR
is I changed my login shell from fish back to bash.
The system configuration for the nonworking machine was using fish
`(user-account (shell (file-a
Hi all,
Noticed this error when running Guix pull today. Not entirely sure of
the problem, but the console said to report it and I didn't notice any
identical bug reports recently.
Full log attached. Abridged version below.
ice-9/boot-9.scm:3330:6: In procedure resolve-interface:
no code for
When reconfiguring the system with Guix, shepherd services that have
auto-start? set to #f are started during reconfiguration. Per
https://issues.guix.gnu.org/22039#26, services shouldn't be started by
reconfigure if auto-start is #f. These services are not started on boot,
which matches expect
posting it in case anyone else runs into a
similar issue in the future.)
If anyone else has a similar setup, encounters this issue, and already
uses --no-grafts, be sure both the system and home profiles are built
with the same version of Guix.
Richard Sent
Opening a ticket so discussions a bit more organized. Hope this doesn't
step on anybody's toes.
Catch2-3.5.1 fails to build with system=i686-linux, log attached. This
is due to a test added upstream that assumes the SSE extension is
present,
SelfTest/IntrospectiveTests/RandomNumberGeneration.
pastes it literally in nginx.conf. To my understanding "/git"
would work identically without the regex match currently used, exposing
repos at "host.domain/git/path/to/repo.git", but I've not tested this.
2. git-http-nginx-location-configuration takes an optional Nginx-style
URI pattern argument that, if passed, replaces the URI generated from
git-http-configuration.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
ve those two
should be documented. That should help make them a bit more discoverable
to users.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
tps://git.sr.ht/~freakingpenguin/channel-demo if it's of any help for
reproducing the issue. Just a couple of Guile scripts + guix
time-machine wrappers.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
l.
https://www.gnu.org/software/guile/manual/html_node/Foreign-Libraries.html
I have not tested if the calculation is correct.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
Patch submitted, https://issues.guix.gnu.org/69801
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
useful feature and should be better supported. I don't
know if the ideal fix involves changing the guix-build command in
guix/scripts/build.scm to stop assuming everything is a derivation or
changing the logic in guix/derivations.scm to handle strings in addition
to derivation structs.
Possible related:
https://lists.gnu.org/archive/html/bug-guix/2022-07/msg00037.html.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
d
derivation from source "
status: 1
--8<---cut here---end--->8---
and --fallback isn't provided.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
I've encountered this issue myself, so it's not an isolated incident. I
observed that it only occured when building packages from a custom
channel (or perhaps with -L, I don't recall for sure.)
The issue seemed to disappear after a while.
--
Take it easy,
Richard Sent
Making my c
Possibly related to bug#69753.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
to /dev/console. If so that would probably make
debugging shepherd issues harder, particularly on something like a
single board computer.
Thanks for looking at this!
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
m/a/789454
[4] https://unix.stackexchange.com/a/44000
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
;/tmp/xauth_qHpzQg"
[23:31:06.028] (II) HELPER: Starting X11 session: ""
"/gnu/store/by9l6s04vi7g7q8nd3ycvaz2p9373y0h-xinitrc
\"/gnu/store/fvm9ibhr11bqj09dx5wwha5260hgw2p3-stumpwm-22.11/bin/stumpwm\""
[23:31:06.030] (II) DAEMON: Session started true
[23:31:06.044
Patch submitted at https://issues.guix.gnu.org/70226.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
it has something to do with how libvterm is a native input, not
a regular input? If it's required at runtime my understanding is it
should be the latter, not the former.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
After updating to 4e7337536ba41e888a601c92fada8a4adca9d2c6, the issue
seems to have been resolved. I'll leave this open in case anyone else
who experienced the issue earlier is still dealing with it.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
,
Richard Sent
Making my computer weirder one commit at a time.
Correction to the issue I just discovered: apparently most symbols are
fair game to be included in the hyperlink.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
ading the environmnet's
profile.
I expect this crops up in a lot more places than just home environments
and home bash service. I'd hope for a more generalized solution
that solves this problem across multiple services, not specifically
home-bash-service.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
monly occur as subwords.
Since this change can't occur in a vacuum, care should be taken not to
reduce the effectiveness of other reasonably forseeable search queries.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
he effects of that
might be.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
check if the discrepency would occur there where glibc isn't grafted.
How exactly does that graft causes the problem? No clue.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
3 (_ _)
In unknown file:
2 (channel-get-exit-status #)
In ice-9/boot-9.scm:
1685:16 1 (raise-exception _ #:continuable? _)
1685:16 0 (raise-exception _ #:continuable? _)
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Throw to key `guile-ssh-error' with args `("channel-g
Haven't had the chance to properly hack on this yet, but I believe the
code to update is located here:
https://git.savannah.gnu.org/cgit/guix/mumi.git/tree/mumi/web/view/utils.scm#n127
Let's test how we handle links like <https://example.com>.
--
Take it easy,
Richard Sent
Ma
z7rs8hd85imdz-gash-boot-0.3.0/bin/bash"
"--prefix=/gnu/store/bl3aq7fnpyxq9w2a7bqa4zqgd8z88y8x-gawk-mesboot-3.1.8"
"--enable-fast-install" "--build=x86_64-unknown-linux-gnu"
"--host=aarch64-linux-gnu" "ac_cv_func_connect=no" failed with status 1
--8<---cut here---end--->8---
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
cate
system services.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
https://issues.guix.gnu.org/76368#0
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
82 matches
Mail list logo
