IRC channel logs
IRC channel logs
2023-03-11.log
back to list of logs
ACTION peeks in the spam folder, what's this.
civodul: Did you get an emoji keyboard for valentine's day?
it came in a *very* big box
Like the Chinese mechanical typewriter I had as a child.
ACTION → 😴💤
is there an equivalent to
specifically the configure/build/install commands?
"nix develop - Nix Reference Manual"
nckx: even better: i got M-x emojify-insert-emoji, i'm a big fan! 😍
Rampoina: "guix shell" is similar, but it doesn't let you run phases individually
guix 🐚, that is
"Invoking guix shell (GNU Guix Reference Manual)"
Hi, I'm trying to install guixsd on a VM using the GUI installer. I'm seeing the progress bar for some packages moving super slow. Specifically "libqmi" and "guix" so far. Is that common?
It's weird. libgphoto (1.2MiB) is about the same size as libqmi (1.7MiB) but finished downloading in a couple seconds.
been using guix plenty long now, and still surprised ... installing a package installs the gnutls-*-doc package?
i know there have been complaints about the unicode progress bars, but i like 'em
Hi. Why does `guix build rust@1.65.0` appear to work whereas `./pre-inst-env guix build rust@1.65.0` prints `guix build: error: failed to evaluate expression 'rust@1.65.0':\nUnbound variable: rust@1.65.0`?
Sorry, the error message with `pre-inst-env` is `guix build: error: rust: package not found for version 1.65.0`.
kraai / Hi, I'm not sure, but on my system ./pre-inst-env runs something different from the fully resolved `which guix` in a regular shell.
Exception: #<&compound-exception components: (#<&error> #<&origin origin: "scm_from_utf8_stringn"> #<&message message: "input locale conversion error"> #<&irritants irritants: 0> #<&exception-with-kind-and-args kind: decoding-error args: ("scm_from_utf8_stringn" "input locale conversion error" 0 #vu8(60 63 120 109 108 32 118 101 114 115 105 111 110 61 34 49 46 48 34 32 101 110 99 111 100 105 110 103 61 34 85 84 70 45 56 34 63 62 10 10 60 33 68
32 80 85 66 76 73 67 32 34 45 47 47 87 51 67 47 47 68 84 68 32 88 72 84 77 76 32 49 46 48 32 84 114 97 110 115 105 116 105 111 110 97 108 47 47 69 78 34 32 34 104 116 116 112 58 47 47 119 119 119 46 119 51 46 111 114 103 47 84 82 47 120 104 116 109 108 49 47 68 84 68 47 120 104 116 109 108 49 45 116 114 97 110 115 105 116 105 111 110 97 108 46 100 116 100 34 62 10 60 104 116 109 108 32 120 109 108 110 115 61 34 104 116 116 112 58 47 47 119 119
57 57 47 120 104 116 109 108 34 32 120 109 108 58 108 97 110 103 61 34 101 110 34 32 108 97 110 103 61 34 101 110 34 62 10 60 104 101 97 100 62 10 32 32 60 116 105 116 108 101 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 116 105 116 108 101 62 10 32 32 60 108 105 110 107 32 114 101 108 61 34 115 116 121 108 101 115 104 101 101 116 34 32 116 121 112 101 61 34 116 101 120 116 47 99 115 115 34 32 104 114 101 102 61 34 47 1
115 34 32 47 62 10 60 47 104 101 97 100 62 10 10 60 98 111 100 121 62 10 10 9 60 99 101 110 116 101 114 62 60 97 32 104 114 101 102 61 34 47 34 62 60 105 109 103 32 115 114 99 61 34 47 105 109 97 103 101 115 47 100 101 98 105 97 110 46 112 110 103 34 32 97 108 116 61 34 34 32 98 111 114 100 101 114 61 34 48 34 32 104 115 112 97 99 101 61 34 48 34 32 118 115 112 97 99 101 61 34 48 34 32 104 101 105 103 104 116 61 34 54 49 34 32 47 62 60 47 97
98 114 32 47 62 10 10 60 100 105 118 32 105 100 61 34 116 105 116 108 101 98 97 114 34 62 100 101 98 105 97 110 32 80 97 115 116 101 122 111 110 101 60 47 100 105 118 62 10 10 10 10 10 10 60 100 105 118 32 105 100 61 34 99 111 110 116 101 110 116 34 62 10 10 10 10 10 10 9 10 9 10 10 9 10 9 10 9 10 9 10 9 10 9 10 10 10 10 10 60 104 49 62 80 111 115 116 105 110 103 32 49 50 55 51 54 55 52 32 102 114 111 109 32 97 110 111 110 121 109 111 117 115
sorry, the bot will stay off for the weekend
why is that happening? is there some fluid leaking?
kraai / vs
bjc / Hi, I'm not sure but it's a decoding error
the sun is setting here, so i'll you both on sunday
see
yeah, i can tell that. just wondering why the crash dump ends up here. i assume ‘current-output-port’ or something is leaking out
bjc / it worked well for typos in URLs
so the bot suffers from some kind of allergic reaction?
the theory seems to check out given the '#<&irritants irritants' message
As far as I can tell (I haven't had time to try yet) it doesn't let you run phases at all? It's unclear to me what you do once you're inside of an environment with `guix shell --development X` . With the Nix command, one inside you're able to easily download the source, compile it and install it with those commands (although imo this is still lacking a command to make a package with the current change and install it). How do you do the equivalent
steps in Guix? Manually?
AwesomeAdam54321: the postgresql trick work to start it in the build container, but the application (ruby-pg or ruby-activerecord) still seems hard-wired to want to task to a socket under /var/run/postgresql :-/
hm, a substitute server seems to be hanging connections
seems to be
shouldn't it time out and continue?
cbaines:
is not responding anymore
oh, nevermind, the page finally loaded
must be under heavy load
but 'guix build ruby-railties --substitute-urls=
' hangs minutes on "substitute:"
apteryx: Does ruby-pg or ruby-activerecord have options/settings related to postgresql?
lechner: Can we just keep that URL-repeating bot out of this channel?
lechner: I don’t think the bot should print exceptions here. Make them go to a log instead.
Rampoina: no, there's no way currently to run phases once inside the shell
I wonder how we could do that, for nix it's easier since they have a tighter control on what build systems do, whereas we basically have any scheme code that can be modified on the fly per-package
sneek, later tell kraai: rust-1.65 is not a public (exported) variable so the guix command line tools won't find it
Got it.
sneek, later tell kraai: you can use `guix build -e '(@@ (gnu packages rust) rust-1.65)'` instead probably
Will do.
How can I prevent gcc from adding -fnoexceptions to the options? I tried giving -fexceptions to CMake but -fnoexceptions overrides it because it's in front
nvm it was because -fno-exceptions was hardcoded in a different cmake file
Happy weekend Guixers
hello guix :)
sneek, later tell civodul: making hurd work will require a glibc patch
Got it.
hi guix1
guix!
i have a question about guile
can i have a few (abort) in side (call-with-prompt)
(% (begin
(abort)
(abort))) ?
I need to edit /etc/libvirt/qemu.conf to add the path of $(guix build ovmf) so libvirt can use UEFI. I did not see anything related to that in the manual. Does someone know how? Basically I just want UEFI to work in virt-manager
Guest74: it doesn't exist on your system yet, right?
you can extend etc-service-type for that
yes, there is a libvirt dir but without any confs
is there any reason /run is not a tmpfs on Guix System?
Hi gents! When defining a package, can I grant my compiler process network access so that it can pull native dependencies the internet all by itself?
The package looks like this:
Or should I define all the dependencies as separate Guix packages?
AgentKilo[m]: All the dependencies should be defined as separate Guix packages
Yeah I thought so. Guess I need a zig-build-system. But it seems the Zig package management interface is not quite stable yet. I was hoping there may be some ad-hoc solution
And another question: When using git-fetch, what are the proper steps to calculate the base32 hash for a package? I tried guix hash -x -S nar .
and guix hash -x -S nar ./some-src-dir
and andguix hash -x -S git ...`
they all produce different hashes, but none of them is the "actual hash" prompted by Guix
jpoiret: gotcha, thanks. No idea how you could do it, I'll just leave the idea in the air ;)
AgentKilo[m]: `guix hash -rx ./some/dir/`
Hmmm, I tried that, and it produced the same hash as `guix hash -x -S nar ./some/dir/`, but not the "actual hash" printed by Guix either
./some/dir/ should be the to-level dir that's cloned by git, right?
Hi. `guix lint
*top-level
Or...how do I locate the source dir for some specific package in the store? Maybe the repo I cloned manually differ from the one in the Guix store?
AgentKilo[m]: `guix show PKG` will report its location relative to the checkout.
bost: that means that package may have a release version newer than your packaged version, you should check its homepage/git repositoy to see which version is wanted.
next4th: Thanks! I see something like this running guix show zls:
Could I get some eyes on #61768 please?
Apologies... It's #61786 . Not #61768
next4th: Ah, ok. Thx. '(git-version "1.5" revision commit)' makes guix lint is happy, indeed.
Seems there's no info for me to locate the source code in the store? To clarify, I want to check the zig source code of zls, not the guile source code for the package definition.
AgentKilo[m]: guix build -S zls will get it, if the 'guix build zls' output the safe store path (if not same, the soure will be a different zls package, but near)
output the same
bost: well, you need make sure the commit is really newer than 1.5, or why you would prefer a git version than a release (tagged) one?
next4th: Ok, here are the details: I'm packaging
, it has a release tag 1.5., but in fact I'm interested in the d228d75 commit.
next4th: d228d75 is the latest one.
okay, that make sense..
next4th: Yes! guix build -S zls gives what I want! My manual clone DO differ from the source in the store though.... I need to spend some time to find out why.... Many thanks guys!
cool :)
AgentKilo[m]: did you check out the right commit/tag?
that's what often happens to me :p
shouldn't files under gnu/packages/aux-files get registered in gnu/local.mk?
mirai: they're in Makefile.am
as to why, 🤷
next4th: One more thing: The
specifies no version, revision or anything like it. I use (git-version "0" revision commit) with revision "0" then `guix lint` complains 'emacs-railscasts-theme@0-0.1340c3f: updater 'generic-git' failed to find upstream releases'. What should I do about it?
jpoiret: was this question ever raised before?
lechner: thanks
kraai, you have 2 messages!
kraai, jpoiret says: rust-1.65 is not a public (exported) variable so the guix command line tools won't find it
kraai, jpoiret says: you can use `guix build -e '(@@ (gnu packages rust) rust-1.65)'` instead probably
jpoiret: thanks!
that works.
kraai: note that rust-1.65 likely won't have a substitute
we should have a rust-latest package, but adding that would be harder than it sounds
the rust package is not defined as just (define-public rust CURRENT-RUST-VERSION)
it has a lot of changes that basically revert a bunch of modifications we make to the rust-VERSION packages to make them slightly less of a pain to build ad nauseum, iirc :)
bost: that's fine i guess, that just means the updater can't handle repo without a proper tag/release..
(about the substitute: cuirass only seems to build packages that either (1) are public, which means they will be picked up by FOLD-PACKAGES, or (2) are used by a package which is, which would of course lead to it being built as a dependency
) >:(
next4th: thx
ahhhh yes, the oft-praised logind replacement greetd pulling in millions of rust dependencies
what a time we live in
ACTION once again laments the fact that rust could have been way better
"minimal"
these days I don't think any language can escape the dependency hell-hole
(btw greetd is not the logind replacement, seatd is; it's written in C, thank goodness)
greetd does work well though. it's just a shame it's in rust
old languages manage to avoid because they're just that, old. Current society has no need for proper dependency management
so rewrite-in-rust is a conspiracy to sabotage guix?
yes
jpoiret: Yeah both repos are at the same commit. Turns out it was the excess files generated by previous builds I ran in the manually cloned repo. Should have used a clean repo :p
unmatched-paren: i do use it myself and am happy with it
time to get our act together and Guile all the things!
Welcome back civodul, you have 1 message!
civodul, jpoiret says: making hurd work will require a glibc patch
jpoiret: re Hurd, did you see
I don't really comprehend the buzz around rust
but yeah, I just wanted to see if it builds on core-updates. then i was greeted by mrustc + 10 rustc drvs, as well as all the dependencies
mirai:
borrow checker go brrrrrrrrrrrrrr
my laptop Ctrl+C it itself, didn't want to go through all of that
the safeties and whatever touted benefits exist... in languages like Ada (2012)
ellysone[m]: That brrr is of course your CPU.
civodul: not that mail, no, but the problem is that newer releases of mig also need newer gnumach
and newer gnumach need newer hurd, see where i'm going with this?
ah now that's interesting
Mach doesn't depend on the Hurd, though?
mig depends on gnumach unfortunately
no it doesn't
not to mention Ada (or SPARK) contains some very interesting tooling regarding program correctness
i mean that older hurd won't build with newer gnumach
jpoiret: did you try updating these things already? i know others such as rekado tried recently
yes
awesome
kraai:
<- if we wanted to have a rust-latest package, we'd need to have another one of these... things. modified for 1.65, no less.
jpoiret: maybe we can start with what you have?
i basically followed what zamfofex did, but also added the glibc patches
excellent
well, except for glibc :-)
what's the deal with glibc?
the glibc patches are only needed to build the cross libc
the cross libc doesn't configure properly for the mach part
okay
so you have something that works for cross-compilation?
it doesn't pass -ffreestanding when using AC_CHECK_HEADER, so #include
well, I haven't built the cross toolchain for hurd yet
because the glibc patch triggers a world rebuild :)
it'd need to be applied conditionally
but then we need a custom phase
yeah, I was thinking of that as well. Maybe only for xglibc/hurd-headers and cross-libc
right
all this is becoming unreadable :-)
yes :) especially the hurd-specific "yes we need to build glibc to build the system headers"
unmatched-paren: what's the reason for not pointing the rust package at the latest upstream release? dependency churn?
once we've sorted cross-compilation out, we'll need tarballs to build from; otherwise we'll lose native i586-gnu support due to cycles
kraai: we'd need to rebuild things, yeah
civodul: wdym cycles?
Quite A Few things, to put it lightly
:(
i'm not very familiar with the bootstrapping part
(see: librsvg, which is pretty low down in the dependency graph iirc)
kraai: also, upstream releases wayyy too often
jpoiret: take mig-boot0 in commencement.scm: it cannot use 'git-fetch'
ahhh, right
we could host our own tarballs of the latest tags
but that's ok, we can run "make dist" on our side and upload that to ftp.gnu.org/gnu/guix
i'm not sure upstream wants to release right now
since the Hurd folks are even more disorganized than we are :-)
there's no real "upstream", only Debian
that's part of the problem IMO
so we need hurd and mig only?
if we do need a Hurd update, then yes, we'll also need to host tarballs
jpoiret: oh my, they're on 1.68 now...
well, I can try to work the cross-compilation out, but that'll take some time
i was hoping we could make do with just a mig update
apparently that won't be the case
i'll try to see if we can use the mig right after the commit that fixed this
but it was not too long ago
next4th: ... and also for
`guix lint` reports 'warning: no tags were found for ...'. I guess that can be ignored as well(?)
jpoiret: for const qualifiers, it's mig commit cf4bcc3f1435eafa3ed8b5fadfa9698033d1e2df
yeah
initially i tried to apply just that patch on top of 1.8, but that didn't work
maybe we could backport it though, i haven't tried
i'll clone and git blame
what's “mig” mean in the context of the hurd?
maybe it won't be too hard to backport
bjc: "Mach Interface Generator"
ah, thanks
jpoiret: i'll let you look at it then; lemme know how it goes or if you'd like to pass it on or whatever :-)
bost: um, it seems so, for detail need to check the updater code, which i haven't :)
in other news, i pushed Mitchell's post on cross-compiling for Zephyr as a draft:
feedback welcome!
can someone confirm that they're getting only one path with this command? $ guix shell libxml2 docbook-xml docbook-xml@4.5 -- sh -c 'echo $XML_CATALOG_FILES'
mirai: /gnu/store/qx3jgv6vfq79m0g4rdrk9k5ib5nir7ml-profile/xml/dtd/docbook/catalog.xml
it should be displaying 2 paths
right
looks like search-path is broken
mirai: there's only one profile so it cannot display two entries
test /gnu/store/m4d1fspdy41xyf1hxa5qnp00h8ma5pkl-profile/xml/dtd/docbook/catalog.xml
hah interesting, pasting that path first will not sent my msg, anyways I wonder why I have a different hash than bjc
messages in irc can't start with ‘/’
civodul: one profile?
bjc Ah yea make sense. Didn't thought about that
civodul: the issue here is that the first catalog.xml from docbook-xml is chomped
it should be displaying VAR="/first/catalog.xml /second/catalog.xml"
civodul: i don't think we can backport
i've backported mig and gnumach's patches okay, but these ones will be much more painful
(it doesn't apply properly in most of the files on our used commit)
jpoiret: ok, i see
the other option would be to strip 'const' qualifier from libc...
but we're back to square one then
that could be a tactic for now if it allows us to fix Hurd support in core-updates more quickly
right
at some point we'll have to do that upgrade anyway
if we're allowed to make changes to glibc, then better patch it
so we can also get newer mig+hurd+gnumach
all on "related" commits
yeah, it's just more work, but it's more fruitful medium-term
US