***codemac is now known as codemac1
<sirmacik>what might be the reason of stumwpm getting some different sbcl environment than I from the terminal? I'm running it from xsession file and on loading library from share/common-lisp I get sb-introspect error ***codemac1 is now known as codemac`
***codemac` is now known as codemac
<mbakke>sirmacik: maybe you need to source /etc/profile from the xsession file? <sirmacik>mbakke: haven't tried that one yet. only sourcing bashrc, thanks <mbakke>sirmacik: I guess you'll have to inspect "cat /proc/$(pidof stumpwm)/environ | tr '\0' '\n'" and inspect the difference from the terminal environment <sirmacik>mbakke: only difference is in XDG_{CONFIG,DATA}_DIRS <sirmacik>sbcl from commandline gets also /etc/xdg and /usr/local/share:/usr/share <pkill9>what might be causing this error when building a channel?:(repl-version 0 1 1) <pkill9>(exception wrong-type-arg (value "struct-ref") (value "Wrong type argument in position ~A (expecting ~A): ~S") (value (1 "struct" #f)) (value (#f))) <whk>g_bor[m]: Is it on a branch that I can play with? <ryanprior>If I have an open issue in the Guix tracker that's received no comment for a week and a half, is it a good idea to send a "bump" email, or should I just chill a while yet? <jackhill>ryanprior: I think it is appropriate to bump it. What's the issue number by the way? <jackhill>of course, it could be that no one has any ideas about it, but hopefully not :) <atw>ryanprior: dunno what etiquette is, but I made a comment on an old issue/patch. I'm going to give it a week, then bump it on IRC when I know committers are around <jackhill>ryanprior: heh, I figured since the first one had been merged :) <jackhill>ryanprior: yeah, I think it's find to bump it. nckx, Tobias, took a week or so away from Guix, but I beleive is back now. <jackhill>so that might be why response to the issue has slowed. <jackhill>You can also use this channel's bot to ping people when they're around like so: <ryanprior>I know I can use sneek, but I'm worried about being a nag '=D <sneek>Welcome back ryanprior, you have 1 message! <sneek>ryanprior, jackhill says: like so <jackhill>ryanprior: thanks for the contribution by the way. <jackhill>ryanprior: oh great, glad you know. As I understand our customs, a ping is appropriate here. <ryanprior>Oh ha I just pinged him a minute ago, he's gonna get flooded now ^^ ***jonsger1 is now known as jonsger
***flor_ is now known as flor
<ryanprior>How do we feel about packages for things like https://github.com/superfly/flyctl/ which are free software but are only useful for accessing nonfree web services? My assumption is Guix is not interested in accepting such packages since that is tantamount to recommending the nonfree web service - am I right? <xelxebar>Question about a revision request to a patch I submitted. The commenter mentions that I should probably use git-fetch instead of url-fetch, since the url points to an auto-generated tar (think github's "releases"). <xelxebar>Not sure I understand the reasoning behind this <xelxebar>Is this the standard practice? Why is one preferable over another? Are we able to snapshot git-fetch origins on software heritage? <bdju>ryanprior: I think it should be fine, we have "megacmd" and "megatools" packaged for working with MEGA. <mroh>xelxebar: because the tar could be regenerated (manually or automatically) and then our hash fails. yes, its standard practice for us. <rekado_>ryanprior: the distinction between “free” and “nonfree” is not so useful when applied to web services. <bricewge>xelxebar There was a thread about it yesterday on the ML. Bottom line no recommended method <bricewge>mroh I taught it was the case too but nckx pointed out on the ML that we are using tags most of the time and such tags aren't content addresses <bricewge>So they suffer the same issue as tarball <mroh>bricewge: nckx is of course right (as always), but I think that in practice the tar gets regenerated much more often than the same tag gets moved to another content... <ryanprior>bdju, rekado_, liberdiko: was the megacmd package discussed thoroughly with a concensus that its acceptance (& thus other software like it) is justified, or did it slip through with little comment? <rekado_>ryanprior: we also have, for example, emacs-slack <ryanprior>And I'm not implying that a thorough discussion & concensus are necessarily good uses of time, I'm honestly just asking so I can understand better =D <bdju>I actually just thought to check if any mega stuff was packaged, I wasn't a witness to it happening <xelxebar>mroh: Hrm. Well, github's release tars are de facto static. If they decide to go rogue and ninja edit them post-facto though, then we'd notice. Plus, we're already relying on dns and the whole network stack to behave nicely already. Plus, release tars often contain things like autoconf output not found in a repo. Is it worth the burden of bridging that gap in order to cover the case where github <xelxebar>release tars go bad while the repos happen to be fine? <xelxebar>bricewge: Hah. Perhaps that's why the commenter pointed that out. Have a link to the discussion? <rekado_>automatically generated tarballs are not <xelxebar>Okay. Sounds like the crux is not wanting a url to suddenly start pointing at a different source. Am I grokking the main issue correctly? <ryanprior>What are automatically generated tarballs? Is that a GitHub feature that's activated on certain repos? <xelxebar>I assume that means a url pointing to a tar source that's automatically updated, so like a "latest version" tarball url or something. *xelxebar offers internet cookies to bricewge <rekado_>ryanprior: when you tag a commit on Github, it will also generate archives <rekado_>none of these tarballs were uploaded by the author <rekado_>they are all the result of tagging commits <rekado_>these tarballs are known to change once in a while <rekado_>the result is that the hash changes over time (e.g. because the tarball was regenerated and thus the timestamps are changed) <ryanprior>Do they sometimes change while the git hash stays the same, or are the changes due to rebasing of commits in those tags? <rekado_>so instead of using these archive URLs we use the tags (or the commits they point to) directly <rekado_>no, the problem is not that of commits changing <rekado_>building a tar of the same files today will produce an archive that differs from what I built yesterday. <rekado_>unless you pass certain options to tar and the compressor <ryanprior>Okay, I think I get that, thank you for explaning <ryanprior>There's probably a big cache of source tarballs that GitHub has auto-generated based on past requests, and they'd want to evict older tarballs to save space, but then you try to download that again eventually and it's got a different hash now due to trivial timestamp reasons but it looks like it could be tampered with - is that about right? <rekado_>it does not happen often, but it did happen to us a number of times in the past <xelxebar>Is this just a function of github not using the right flags to make tar deterministic? What happens to tag-based releases if the underlying tag gets changed? <divansantana>Anyone here not using pulseaudio successfully? It seems to always cause me trouble. Would like to try purge it and see if all still works. It doesn't start on login for me despite several attempts. Sometimes just breaks etc etc <olivuser>is anyone here playing tome and owns the expansions as well? <olivuser>I'd love to know how I have to install them <bdju>divansantana: one thing I found out the hard way is that pulse runs as the user which starts it, and you probably don't want it running as root, so having a service or similar starting it can cause problems like your programs having no sound <bdju>also, pulse by design starts when something tries to use it, so you shouldn't have to do too much special there <bdju>you can `pkill pulseaudio` and then when you launch pavucontrol (for managing pulse) it starts pulseaudio again as your user <olivuser>on another note, I am wondering about the differentiation between the system packages and user packages. So far I have always tried to discern the two by asking myself "which packages would you want to be avaible for every possible user" (system) versus "which packages are specific to your needs" (user). <bdju>specifically I had tried to start mpd automatically via service and then mpd was the first thing to use pulse, but the service was systemwide and then screwed up my sound. I changed to just starting mpd in my window manager config <olivuser>But by that logic, a browser like icecat, a mail client like icedove, and an office solution like libreoffice would have to be system packages, no? <bdju>olivuser: I was conflicted about that at one point as well. a lot of things can be seen as generally useful to have system-wide. I basically just keep the bare minimum in system packages so that kernel updates and such are fast. I believe if two separate users install firefox it won't take any extra space anyway. it all just links back to the store. <olivuser>now, and tome4 players here who also own the expansions and can tell me how to install them? :P <olivuser>and totally unrelated to tome: is it possible there is actually three initial users in the OS? Like system, user, X? Because when I pull, at some point there is a mention that "profile installed with <comically low amount of packages>", while system and user profile both range above 60 packages. To whom is the low amount of packages attributed? <srandom>Hello, I'm writing a package definition. It needs to download the pre-compiled binary from github. How should I get the uname -s and uname -r of the machine in the guile code? <srandom>Or what is the correct way to obtain the target architecture information in Guix? (For example, considering cross-building) <olivuser>okay, so specifying on my tome4 question: installing a dlc to tome is easy, one simply needs to copy&paste a file to the tome4 installation folder. But since that folder lives in /gnu/store (which is read-only), I cant simply copy&paste there. What can I do? <xelxebar>Okay, so I have a go package with a makefile. It builds just fine with go-build-system but fails to install the manpage, LICENSE and desktop file, which are all installed with the makefile's `install' target. <xelxebar>Would it be better to make this a gnu-build-system package with some go native-dependencies, or better to go with go-build-system and a make native-dependency? <xelxebar>Or just go with go-build-system and manually copy over the files? <rekado_>srandom: pre-built binaries likely won’t work on Guix. If there’s source code try to build it from source instead. <efraim>I'd stick with the go build system since it takes care of all the go stuff and either manually install those files or replace 'install with "make install" <srandom>It is a statically linked rust binary <srandom>I tried to build it using cargo-build-system before, but Guix ’s support for some rust packages is not very good, I am not a rust expert, I ca n’t solve these problems, I have to use pre-compiled binary <xelxebar>efraim: Oh! There you are. This is about the bombadillo package you commented on. Thanks, by the way. <efraim>xelxebar: I thought the question seemed related to something I looked at yesterday :) ***apteryx is now known as Guest30242
***apteryx_ is now known as apteryx
<rekado_>mumi now collapses merged issues, so you only see them once in lists. <TZander>that reminds me, KDE. I should at minimum send my patches to a bugreport. I'm just NOT looking forward to writing a changelog. <civodul>you should write a blog post about mumi one of these days <rekado_>TZander: if you’re using Emacs, Magit, and Yasnippet you can use the “update” and “add” snippets to fill out changelog templates <mothacehe>janneke: hey, not much, when printing the "system" derivation, the faulty guile appears as an input. <TZander>rekado_: the template is not the issue. The huge number of packages updates in the auto upgrade for KDE is. <mothacehe>and all the faulty guile inputs come from the bootstrap chain <TZander>I'm not used to having to repeat myself in a commit message. Commit messages for me as a "why" not a "what" <TZander>if you want a "what" look at the commit <mothacehe>janneke: i'm trying to cross-build bare-bones for aarch64 on master, to see if I have the same issue. <civodul>janneke: thanks for the setxattr/getxattr test! <civodul>janneke: i was wondering: how about automatically adding the trailing \0 in setxattr (and removing it in getxattr)? <civodul>using string->pointer & pointer->string <efraim>if anyone's curious, 'guix package -p profile1 -p profile2 -I' only shows the packages installed in profile1 <civodul>ah, add that to zimoun's bug report :-) <janneke>civodul: yw, no the '0' is part of the data! <janneke>using setxattr (as well as using setfattr!) you can choose to add or not add the 0 (afaik) *civodul enters bikeshedding territory <janneke>well, i tbh i shy'ed away from reading "man setfattr" or the setfattr code <janneke>setfattr it has this special hack, where it "interprets" or doesn't interpret VALUE, if it's wrapped in double quotes <janneke>so then you get --value='"foo\0"' to be something else than --value='foo\0', apparently <janneke>civodul: so with this diff, our tests still works -- i just wanted to test two things at once <civodul>i think we should stick to setxattr(2) tho <jonsger>is there are reason to have two perl packages with different name but same content? it's perl-uri and perl-uri-escape? <civodul>and it's true that it's "const void *value", so not necessarily a string <civodul>which means a bytevector might be more appropriate <janneke>yes, -- i think that's what i meant to do... <janneke>civodul: ah, for VALUE we could push string->utf8 and utf8->string into client code -- that did not occur to me <janneke>mothacehe: ouch...which command is this, exactly? <efraim>jonsger: probably not intentional <efraim>looks like perl-uri-escape is only used by one package in (gnu packages mail) <civodul>janneke: though string->utf8 doesn't add the trailing nul <civodul>kmicu: neat! sorta like what cbaines did in the Data Service <mothacehe>janneke: ./pre-inst-env guix system build --target=aarch64-linux-gnu gnu/system/examples/bare-bones.tmpl <janneke>civodul: right; just like setxattr (2), right? -- that's up to the client <efraim>jonsger: do you want the honors? I'd suggest deprecating the perl-uri-escape in web and not in perl-web... actually maybe see about moving all the perl-uri* packages into perl-web? <janneke>mothacehe: hmm, shouldn't cuirass catch that for us? *janneke went in only 6 months from "i'm never deleting any substitutes, whoa wip-ppc fun!" to ... oh no, not another arch! <efraim>i'm sitting and waiting to see if glibc-2.32 fixes the glibc-2.31 problem on powerpc :) FWIW debian is still on 2.30 <efraim>I guess I should rebase my patches against master <sturm1>Hi folks, has anyone had Linphone working for them? It won't seem to connect to SIP accounts for me. <sturm1>(as in the SIP registration seems to fail) <janneke>mothacehe: "it works for me", wrt guile <janneke>rottlog does not cross-build for aarch64, but it seems i'm past guile *janneke runs "./pre-inst-env guix system build --target=aarch64-linux-gnu gnu/system/examples/bare-bones.tmpl --verbosity=1" on latest master <mothacehe>janneke: ok, thanks for checking! Wondering what's wrong for me. ***ae is now known as Guest40279
***Guest40279 is now known as andreas-e
<janneke>mothacehe: yw, thanks for helping with the system cross build! <jonsger>I guess the the gnu-build-system of exo doesn't handle the propagation of perl-uri correct. At least in guix package --search-pathes is no sign of PERL_* <jonsger>efraim: does backspace work for you in vim on Guix System? <rekado_>emacs-guix seems to have a broken package search <rekado_>I miss the days when emacs-guix was part of guix ***rekado_ is now known as rekado
<civodul>yeah, it's been reported a couple of times on our side and on their side <rekado>but emacs-guix is already built with Guile 3 <PotentialUser-32>My Bluetooth card works with Trisquel, PureOS and Parabola, but not with Guix. I'm using the standard gnome config file. What service should I add to the file? <srandom>What does gnome use to manage Bluetooth? <srandom>Although I do n’t know if I can work <srandom>Okay, I may not be able to help you. <Pandya>Hi! I am installing Guix on my old Desktop PC. After selecting partitions, it started downloading packages but due to temporary network problem (for 2 seconds) it stopped downloading. <Pandya>I have confirmed from TTY that pinging is working fine <Pandya>Anything I can do from TTY to resume download? <srandom>I usually get stuck when downloading. Ctrl + c; Ctrp + p; then return <Pandya>Ok. I tried Ctrl + c and Ctrl + p but nothing happened <Pandya>Why Guix doesn't build and publish full iso? <bricewge>PotentialUser-32: You need to add 'bluetooth-service' to your services field <Pandya>Computer is connected with USB Tethering <bricewge>Pandya: sorry it was for PotentialUser-32 <bricewge>I don't know If you can resume an install, I would like to know too <Pandya>If I do hard restart, downloaded data will be lost, right? <Pandya>Is there anything I can do from tty? <Pandya>I am using Graphical based installation btw. <Pandya>bricewge: where does it store download files? <srandom>Use a graphical installer to generate config.scm if possible, and then install it manually using guix system init. <reepca>if I understand correctly the cow-store service makes it so that downloaded files go to the target store instead of the "host" store. <Pandya>So, after hard restart I will not format the drive (/dev/sda7 in my case) and just apply root (/) to that partition. Will it detect already downloaded files? <reepca>I would guess that the installer probably prefers to start with fresh partitions, but I haven't actually used the guided installer yet <Pandya>I am not using guided installer, I am using manual installer:) <reepca>if there is a way to make it skip actually formatting, I would expect it to be possible to re-use already-downloaded files <Pandya>Ok. Let me do ctrl + alt + delete to restart <reepca>{help-guix,bug-guix,guix-devel}@gnu.org *janneke ponders about davexunit's "special binary bundles" and "should" <Pandya>Oh no! It's downloading from starting :( <Pandya>So, I should not take a risk of online installation. I would be happy to install Guix if complete iso is available <Pandya>I think I should contact developers <pandya2>sever said pandya is already in use and forced me to change the name <pandya2>sarandom: you were saying something... <pandya2>Ok. I will contact Guix to make full iso available <srandom>guix is rolling update and there are too many packages, I think it is difficult to provide full iso. <jonsger>efraim: is there something required for using vim plugins other then adding the packages to config.scm? <pandya2>At least base/core packages iso would be possible so that users can install Guix without Internet connection. <pandya2>I used to use Trisquel till today and thought to switch to Guix <pandya2>But requirement of Internet connection during installation is the only barrier <srandom>Well, I also have network problems. My solution is to install a GuixSD as a server in the LAN and let it provide guix publish services to other machines, which will improve some of them. <Talas>Hi all, I'm running guix on top of debian 10 and trying to get Ardour up. I think I need some pointers on how guix works to solve my issue. I installed ardour with 'guix install ardour' and when starting it complains that libasound_module_conf_pulse.so is missing. which is correct, so i did 'guix install alsa-plugins' which seems to contain <Talas>libasound_module_conf_pulse.so. However, ardour is searching the wrong place in the store and still can't find it. It seems to search in /gnu/store/xx-alsa-lib. But the library is in /gnu/store/xx-alsa-plugins. <civodul>srandom: i this a new CDN? rsync'd from berlin.guix.gnu.org? <reepca>Talas: I recall at one point having to set ALSA_PLUGIN_DIR, and it still seems to be set for me. Could be related? <srandom>I said wrong above, it is Cloudflare proxy <jonsger>efraim: shouldn't it be /run/current-system/profile <jonsger>efraim: do you have an idea how we could bring this to guix itself? <civodul>srandom: ah ok, i thought this wasn't a viable option <Talas>reepca Hmm.. I tried setting it to various things, but nothing changed. Seems I can get the same error message from "aplay -l" (from alsa-utils). https://pastebin.com/MUr4n6Fd <mothacehe>civodul: I spent this morning trying to understand why libatomic-ops was showing up in the native guile built when cross-compiling a system. Glad to see your email, I'm not crazy! <mothacehe>I also have an unrelated issue (I think), where the canonical Guile fails because 32 bits gzip-mesboot, calls lstat, which -EOVERFLOWS in compress-documentation phase. Tough day! <rekado>mbakke: outgoing NTP connections to 0.guix.pool.ntp.org are permitted for ci.guix.gnu.org <civodul>i really hate dynamic binding every day a little more <efraim>jonsger: we can add it into wherever the global vimrc is sourced from <bricewge>Is there a way to get a package's inputs from the CLI? <rekado>bricewge: guix show emacs | recsel -p dependencies ? <reepca>Talas: mine is set to ~/.guix-profile/lib/alsa-lib for what it's worth <bricewge>rekado: Thanks, now fiddling with sed to get rid of the version number <rekado>bricewge: you can also use Guile <bricewge>Yep, maybe I should start embracing the REPL now <bricewge>pkill9: You know, the tool that's used in every Guix presentation ;) <bricewge>It allow to select a field from package description in this case, but can be use with commands outputting data with the format "field: foo bar\nfield2: bar baz" *civodul never used recsel in a presentation :-P <warp>I was hoping to package the "edict" japanese dictionary files, but it's regenerated daily and has no stable URI. Is it acceptable to source from debian archives? <janneke>civodul: do i understand you[r mail] correctly when you observe that guix pack and guix system do "something that's not supported" (setting %current-target-system at top level)? <mbakke>rekado: great :) I actually noticed yesterday when multiple builds "timed out" because the clock jumped. <mbakke>rekado: so the firewall allows only one NTP server? and a dynamic DNS entry at that? <mbakke>NTP works better with multiple servers <mbakke>I wonder if we can set up PTP between Berlin and all the build nodes. *bricewge took too much time trying to find an incriminating talk from civodul with recsel in it but didn't found any, damn! <rekado>mbakke: I would need to ask for other NTP servers to be added *rekado just switched to plain icomplete from ido and ivy (never managed to get used to helm) <civodul>i use helm but i'm occasionally angry at it <rekado>together with icomplete-vertical <rekado>it got fuzzy matching in emacs 27, but I like it already <rekado>helm is too busy for me (and the faces all look weird) <rekado>ivy has some annoying behaviours that I couldn’t work around <janneke>okay, it only used to be non-free, phew <civodul>rekado: helm has this super cool M-g g thing that makes rgrep useless <janneke>bash: /gnu/store/awq53v7419i5xp0j6hd0qxbzx9w221yf-sparse-0.6.1/bin/cgcc: /usr/bin/perl: bad interpreter: No such file or directory <janneke>i'm wondering who invented this `--null' thingy in M-x grep, that I always have to delete because it breaks [git] grep output :-( <pkill9>i don't suppose anyone might know what causes this compilation error and how to fix it? error: ‘yyloc’ was not declared in this scope; did you mean ‘loc’? <rekado>is bison or flex among the inputs? <pkill9>from researching the issue, i think the program was written with bison 2.x, because running `bison --update <file>` fixes some deprecated code, and searching that compilation error mentioned problems from upgrading from bison 3.0 to 3.5, but it doesn't compile with bison 3.0 either <pkill9>but I don't know anything about bison so *shrug* <pkill9>it produces the same error with bison 3.0 <pkill9>oh i just noticed it has a coded requirement of bison 2.3 or later, so yea <pkill9>i tried to compile bison 2.7 with guix's package definition but it didn't work <pkill9>I'll try with bison 3.0's package defintion actually <rekado>the readme says: Bison (errors with version >=3, I suggest 2.7.1) <rekado>hmm, the “forgotten issues” list sometimes breaks <pkill9>why is there a circular dependency of bison and flex? How does that work? <rekado>pkill9: flex uses a new package variant that inherits from bison <janneke>grrr --keep-failed does not mean --no-build-hook for certain values of time-machine ;-) <janneke>i'm already seduced by this new, nifty default <mbakke>janneke: no need to use quasiquote and unquote in sparse's #:make-flags ;) <mbakke>or, I think (list ...) is a nicer alternative <mbakke>but no big deal, I'm sure others prefer the unquote <mbakke>just feeling nit-picky while waiting for a meeting... <janneke>i went couple of times back and forth; please fix it the way you like it best! <apteryx>civodul: I've just started using Helm. It's great, but has annoying quirks (like, why can't I select text in the minibuffer? or paste to it?) <janneke>mbakke: i agree that (list is the simpler variant, (and thus better? <mbakke>janneke: I think diversity is good too! :P <janneke>the picker, the better the code ... oh, hehe :P <janneke>"hey, get back to work!" "waiting for a meeting!" -- oh okay, carry on! <default>Hi, Im using Guix Data Service http://data.guix.gnu.org/ to follow the dependency graph, is there a way to view/DL raw files as well? Or is view in ones local disk the only way? <rekado>default: for inspecting the dependency graph I suggest using “guix graph” <pkill9>we should tell the build farms to build every previous comit of guix, so we have instant access to all the old packages with `guix time-machine` <mbakke>efraim: the qemu-minimal commit imports (ice-9 match), but does not actually use it. IMO it would be nicer instead of the let and cond though :-) <mbakke>pkill9: that would be great, but we don't have enough disk space currently to build and store all guix revisions :/ <rekado>I’m trying hard to avoid making progress on my projects, so I’m reviewing patches. <mbakke>rekado: productive procrastination is the best *rekado needs to prepare the package to send in the broken laptop for repairs… <leoprikler>I notice, that `guix lint` produces a lot of spurious warnings for gobject-introspection. Should we perhaps split that into `out` and `lib`? <leoprikler>Or use a different package like with xorg-server-for-testing <sneek>Welcome back nckx, you have 2 messages! <sneek>nckx, thvk-ivgf says: test="$(morse -s $(rot13 <<< $(pig <<< 'now with enhanced security')))"; morse -d <<< $test |rot13 # <<< huh?; #"powered by pig(c)" <sneek>nckx, raghavgururajan says: I have missed your replies to #40603, as I am not subscribed to mail-list. I just saw your replies, when I revisited the bug thread via web. I have now replied to thread. :-) <nckx>raghavgururajan: Oh right, there was a bug you wanted me to look at. Will do. <raghavgururajan>nckx: You mean spacefm or font? You can ignore the message regarding spacefm. It's been resolved. <nckx>I agree with lfam here. I'm biased and think outputs don't get the love (& UI) they deserve, but it's still a good argument. So there's my opinion. <nckx>civodul: Thanks. It's nice to be. *nckx answering random backlog, will surely miss much. *janneke reads "fixed" => time to rebase and do some testing, but first...some supper <raghavgururajan>To import! My icedove shows "unverified signature", as yours is not on any key servers. <nckx>apteryx <mouse buttons>: Wow, weird. Any news since then? <nckx>raghavgururajan: Really? It used to be on the SKS servers (previously known as *the* servers) and it's certainly on keys.openpgp.org. <nckx>I don't know how Icedove updates keys but IMO it should have found them. <nckx>raghavgururajan: Because I'm a slave to the bean. <nckx> [nckx] (~nckx@tobias.gr): ☕+ ☭ + 🄯 <nckx>‘Guix-devel post from sysadmin@gnu.org requires approval’, heh. <nckx>It's just a fun mnemonic to quickly recognise my key, although of course you should check the whole {str,th}ing. <nckx><<jackhill> ryanprior: yeah, I think it's find to bump it. nckx, Tobias, took a week or so away from Guix> That's exactly right. I'll answer that thread soon. <nckx><mroh: nckx is of course right (as always)> 😃 I'll remember that. <efraim>mbakke: doh. Qemu-minimal started with match but I had problems with cross compiling so I switched to cond and forgot to remove the import <nckx>Blackbeard: Optimistic. For absolutely no reason, but it beats being otherwise. *nckx looks forward to having ‘job’ and ‘money’ and ‘lung capacity’ again ♥ <reepca>I'm trying to make my .emacs simultaneously more portable and also able to use the emacs-* packages installed by guix. Is there a way to tell use-package "install from archives only if the file to be loaded can't be found"? IIUC :ensure only consults package-installed-p, which only checks whether the package is installed via the built-in package manager, not whether it's actually available... <ruffni>since my guix pull yesterday guix says "guile: warning: failed to install locale". is this intentional? glibc-locale is isntalled. do i need to set some ENV-var? <reepca>ah, looks like locate-library might be what I want <rekado>ruffni: you probably crossed over a libc upgrade. You may need to install a new version of glibc-locales and make sure that it is available in the guix-daemon’s execution environment. <ruffni>i did `guix package -u` after a `guix pull`. should i remove and reinstall? <rekado>please resist the impulse to reinstall <rekado>okay, then you should also reconfigure your system <rekado>I wonder if I should display the number of issues for each category; I don’t want to scare us all <ruffni>maybe just rebrand them as opportunities? <ruffni>so `guix pull` just like refreshes the repo (like `apt update`), `guix package -u` updates outdated packages, but only `guix system reconfigure` actually updates the system? i am a little confused, because i only did the former two when this started <rekado>“guix system reconfigure” will build a new generation of your system as specified in your system configuration file. <rekado>it’s responsible for all system services, global packages, and global configuration files (such as parts of /etc) <rekado>“guix upgrade” (or “guix package -u”) only upgrades packages that have been installed into a user profile. <rekado>“guix pull” gets you a new version of Guix itself, including new package definitions and features <divansantana>Anyone here not using pulseaudio successfully? Mine gives me issues and thinking of trying to purge it. <ruffni>rekado: thanks for clearing that up! so the systems glibc-locales became unreachable after a guix pull? <rekado>no, there’s just a mismatch between glibc version and version of glibc-locales <nckx>ruffni: Not unreachable, just incompatible. <nckx>The locale ‘data’ is closely tied to the exact version of glibc that it came with. <tho1efx>I seem to have some trouble getting apps installed on arm. Is that what others generally find? <tho1efx>About half of the packages I've tried have filled due to some different dependency breaking. Sometimes one and then the other. <pinoaffe>divansantana: every now and then my pulseaudio seems to crash, but apart from that I don't have any issues <olivuser>is there any possibility to manually add files to the /gnu/store? <rekado>tho1efx: the build farm capacity for armhf is underdeveloped, so we don’t have as many substitutes for that architecture <rekado>building them locally you might run out of memory <rekado>olivuser: if by manually you mean via Guix, then yes <null_radix[m]>olivuser: not off the top of my head, but it wouldnt be to hard to build with the copy build systen <rekado>olivuser: you can use Guix as a library and circumvent the package detour <rekado>but you still need to talk to the daemon <tho1efx><rekado "tho1efx: the build farm capacity"> Aarch64 likewise? <rekado>tho1efx: we use the few aarch64 nodes for both armhf and aarch64 <NieDzejkob>olivuser: guix download with a file:// url seems to work <olivuser>NieDzejkob, but is it possible to specify a particular place in the store where it is to be deposited? <olivuser>I mean if I have a file in /foo/bar and want it to go to /gnu/store/1230912asiasdf-baz/, would that work? <nckx>tho1efx: I think 50% of the aarch64 ‘build farm’ is in my living room, which tells you all you need to know about its size. <tho1efx><nckx "tho1efx: I think 50% of the aarc"> You could have a very large very noisy datac...livingroom. ;) <nckx>The ‘I should own a rack!’ conversation was shut down pretty swiftly by $partner. <chipb>olivuser: the '1230912...' part depends on the hashed content of the file, so you can't really specify the path directly. <efraim>You can mush them together into a new output like xfce does <olivuser>chipb, I may have been unclear. I know the hash of the destination, it is that I want to move files from /home to /gnu/store/1239123-existent-package/ <chipb>olivuser: would NieDzejkob's suggestion of guix download file:///path/to/file then work? <olivuser>chipb, I think the problem is that I dont see how to specify a TARGET directory. <olivuser>normally, I'd to something like 'cp /path/to/file.asdf -t /gnu/store/nt9gwenwge-target-directory' but obviously this doesnt work <olivuser>when I do what you and NieDzejkob suggested, it simply creates a new place in the store <rekado>olivuser: you cannot edit things in the store <olivuser>rekado, and adding a file to an existing directory is "editing" the store? <olivuser>so your advice with using guix as a library wont work in that case either, right? <chipb>I guess I don't understand. in what way do you require the same path? <chipb>(but rekado's probably far better help than I if he's around. ;-P) <olivuser>chipb, I tried to keep it general, but concretely, it is about a open source game (ToME) for which I have purchased addons, which are installed by adding downloaded files to the games' directory <kamil_>Hello. I hope this is the right place, but I'm having a problem with each fresh installation of Guix System in QEMU. System reconfigure throws an error saying that the nss-certs derivation's substitutes fail to be built and aborts the operation. <kamil_>The installation is fresh, and uses the default, untouched config.scm generated by the graphical installer. I've remembered to run guix pull beforehand. <rekado>olivuser: why do you want to edit the store? What’s the goal? <rekado>kamil_: this sounds like two things: 1) you’re not getting a substitute for nss-certs from ci.guix.gnu.org and 2) your locales are invalid due to an upgrade of glibc, so the build of nss-certs fails. <rekado>it’s one of those few builds that can fail when the guix-daemon’s environment doesn’t contain the right locales <rekado>kamil_: to get around this problem is a little tricky <rekado>you’d first need to run “guix install glibc-locales”, set GUIX_LOCPATH, and then start the daemon manually in that environment <rekado>and then start the daemon as usual <olivuser>rekado, installing an addon to a game (ToME) it is required to add an addon-file to the game directory <chipb>olivuser: one option would be for the game to support a plugin path-like search to other directories. <chipb>I think there's also composition-like ways of combining different store paths into a 'union' path, but I'm not sure if they utilize hardlinks if you're talking about large-ish game assets. <mroh>olivuser: another option could be: make your own game package that inherits the orginal and copy the addon files... <kamil_>I need to digest all the information... that's a silly problem. I haven't got onto trying to reproduce my Nix config, yet I'm already stuck at a pre-first-update stage before even running my first system reconfigure. :c <rekado>kamil_: yes, it’s very annoying. It’s bad timing really. <rekado>we just merged a big change set that includes the upgrade of glibc. <rekado>your installation is fine and uses the previous glibc; after “guix pull” it needs the new glibc, so the existing locales aren’t matching <olivuser>chipb, thanks but that sounds a bit too much considering my current (very limited) guile abilities <olivuser>mroh, that sounds like something I might actually be able to achieve...^^ <rekado>olivuser: the union thing isn’t too difficult. Take a look at python-pyqt+qscintilla in gnu/packages/qt.scm <nckx>Using ‘--no-substitutes’ for nss-certs worked for me. <rekado>nckx: I suppose your locales are matching the version of glibc you’re using <kamil_>rekado, so, should the next time GUIX hits a new stable release, the error message will be gone until the next time that a new glibc version is pushed? And if I understand correctly, it happens from time to time to some users? <rekado>nckx: or is that only a problem when substituting nss-certs? <rekado>kamil_: it’s a very rare problem and generally you should get binary substitutes for all packages. <rekado>not sure why there’s none for nss-cert at this point <kamil_>I meant that a new ISO is produced when a new stable release of Guix is released* <kamil_>rekado, Oh, I see. So, speaking of your workaround, what do I do to start the daemon manually in the environment you were talking about? <nckx>rekado: It sounds like I had the somehow opposite problem from kamil_ (I just saw ‘locales’ & ‘nss-certs’ and replied): *substitution* failed due to locale mismatches, *building* worked fine. <nckx>The substitute was from my own servers, not berlin. <rekado>kamil_: before you do that could you try “guix build --no-substitutes nss-certs” first? <rekado>just to be sure we’re not missing something obvious <tho1efx><nckx "I wish."> What sorts of systems are in the aarch cluster <rekado>tho1efx: a couple of Overdrive 1000 and some smaller boards <rekado>(the issue with nss-certs deserves a bug report; it’s related to cert file names that have odd encodings; still shouldn’t fail to build) <chipb>olivuser: fwiw, I think mroh's suggestion would end up looking a lot like my union suggestion. <olivuser>chipb, I guess you're right, I was talking more about the "plugin path"-like search approach <chipb>but I'm neither super guix- nor scheme-savvy myself, so I'm not sure how much help I am beyond high level. <kamil_>rekado, it's building currently derivations (successful builds are green-colored). I assume it'll take some time on my system.. Either way, it seems that it's rebuilding a huge chunk of system derivations, such as make, glibc, gcc, and even some basic GNU coreutils components like sed. <olivuser>yeah I guess it will be a lot more fiddling with even easier stuff before I am able to understand the deeper stuff. quite new to programming more generally speaking and I'm running into "I cant do this"-walls basically all the time :P <nckx>kamil_: It will rebuild everything. If you can get the derivation (.drv — hello Nix!) file name for nss-certs out of the previous failure output you could ‘guix build --no-substitutes’ only that, then build the rest of your system from substitutes. <nckx>There may be others hooked up to bayfront, dunno. <nckx>(= our ‘back up’ build farm, but that doesn't actually provide substitutes to users.) <cbaines>if the overdrive machines are aarch64, I have one <cbaines>I was getting it ready to build things, but I haven't quite got there yet <kamil_>nckx, do you mean the /gnu/store/ path? <rekado>alternative: guix environment nss-certs <nckx>kamil_: It will start with /gnu/store and end in ”.drv’, and ‘nss-certs’ will be sandwiched somewhere inbetween. <rekado>then guix build --no-substitutes nss-certs <nckx>civodul: (dover, right?) Is it also an Overdrive 1000? <bavier>civodul: cool work on guix pack engines *bavier not had enough time for hacking lately <kamil_>rekado, I followed your instructions and it was able to successfully build nss-certs-3.50.drv this time, without rebuilding the rest of Guix System :) <rekado>kamil_: now you should be able to resume the reconfiguration <kamil_>alright, let's see how it goes this time ^^ *rekado is shocked to see GUIX_LD_WRAPPER_ALLOW_IMPURITIES in two openjdk definitions <whk>I am missing something, in %base-services '(extra-special-file "/usr/bin/vi" (file-append vim "/bin/vim"))' creates symlink /usr/bin/vi -> /gnu/store/{HASH}-vim-8.2.0411/bin/vim is there an equivalent that would create a symlink from /run/current-system/profile/bin/vi -> /gnu/store/{HASH}-vim-8.2.0411/bin/vim? <ruffni>why don't you just add it to the packages section? <whk>I have vim added in packages but it doesn't create a symlink for vi (which I want to set to satisfy muscle memory). I could create alias or add /usr/bin to my path but I would prefer to have the "vi" command on each of the machines I am building by default. So was trying to see if I was just missing the command to add symlinks in {PROFILE PATH}/bin. <ruffni>i solve that with an alias in .bashrc <rekado>you could define a package just like “python-wrapper” <rekado>it only installs “python” as a link pointing to “python3” <rekado>then you’d add that package to the list of packages <whk>rekado: Rgr I will take a look. <kamil_>rekado, I'm sorry to bother you about this. I'd rather outright tell you that everything has gone great, but there's one thing I don't understand: it's been building qemu-minimal for a while now, and I fail to understand what qemu is needed for?... <rekado>hope someone here might be able to help you <kamil_>And as I was writing that message, I got another derivation that failed to build.. I must've jinxed it :/ <ruffni>kamil_ are you as well stuck in check phase for quite some time now? <kamil_>Oh, that's okay. You've helped me enough today. ^^ <kamil_>it's telling me that the build of qemu-minimal failed and the build of a grub derivation cannot be built. <ruffni>i am right now having the same issue <ruffni>but i've just restarted the thing and... well, it's doing stuff <cbaines>I think QEMU is used in the grub test suite <kamil_>I've guix system reconfigure again. Let's hope it works. <cbaines>kamil_, I assume you've enabled substitues, you're just not getting one for grub <kamil_>cbaines, I haven't touched the default config.scm. I guess the answer is yes. <kamil_>It's stuck in the check phase again :( <cbaines>unfortunately, I'm a bit short on context. You've installed Guix, run guix pull, and guix system reconfigre is failing, is that right? <ruffni>mine's stopped again, but now complaining about other packages (racket). i'll give it another try <kamil_>cbaines, that's correct. I've only run those commands after booting into the OS. <civodul>cbaines, mbakke: i think i'll move %quirks & %patches to their own module; what would be a good name: (guix quirks), (guix glitches), ...? <kamil_>and it's guix system reconfigure failing, yes. <cbaines>Cuirass looks stuck on ci.guix.gnu.org, in case no one has noticed yet <mbakke>civodul: (guix quirks) sounds good to me. <cbaines>civodul, (guix backwards-compatability) is long, but it at least describes something about the purpose <cbaines>kamil_, one way out might be to use a slightly older revision of Guix, from earlier today. If you guix pull --commit=f227dd489b0a1e6905801b1e73f85dde852b5713 you should get a substitute for grub and not have to build it <kamil_>cbaines, I'll try it out. Thanks <cbaines>ruffni, if you have the same problem, maybe what I said just above would help you too <ruffni>how would you get the hash for the older revision from within guix? i just copied it by hand.... <ruffni>like, is there an equivalent to `git log` where i could see some hashes of recent revisions? <cbaines>There isn't something in the Guix command line interface, I'd just use git log on the Git repository <cbaines>which meant I was able to pick a revision where ci.guix.gnu.org had built grub <ssb>"Failed to load ldlinux.c32" -- I guess replacing grub with extlinux was not a great idea. Good for me it is just a vm.. <kamil_>On another subject, while I'm not entirely sure that the state that NixOS is in that prevents me from using will remain an issue for long, I'd like to give Guix System a test drive to end my dilemma as to which one of these is better for me once and for all. <kamil_>What resources would you personally recommend to learn Guile? <ruffni>how familiar are you with scheme or lisp-like languages and programming in general? <kamil_>ruffni: Here's the thing, I can't program. I'd like to pick up any relatively modern language in the future, but I still haven't had motivation to do that yet.. <mehlon>and a bit of general computer science as well :) <kamil_>whk, thanks for your recommendations! <ruffni>i can recommend SICP, both as a book and as online lectures (youtube). altough the LISP-family is one of the oldest, guile is not an old or old-fashioned programming language! don't let Java* or other OOP programmers get too much into your head <kamil_>mehlon, is learning Racket going to be an issue when I want to use Guile? I'm sorry for my ignorance ^^' <whk>kamil_: np though you may want to look at mehlon's recommendation. I am coming at this from knowing multiple languages and was looking for something that just explained how scheme does/interprets things. <mehlon>nah it's fine. They're similar enough that knowledge from one transfers to the others <mehlon>it's like learning human languages. The more the merrier <mehlon>GNU Guile is a type of LISP language. Racket is also a LISP language. Mostly the difference is in what the names for things are <mehlon>With Racket you also have a nice graphical environment for trying out your code. <kamil_>whk, thank you for sharing your view ^^' I'm just hoping that I won't be spending all this time learning the entirety of LISP while I could just learn configuring Guix by trial and error, and nagging you all here <kamil_>I'm just worried that I might learn something that won't have much use outside of the GNU ecosystem <mehlon>Learning LISP is pretty simple in terms of what it does <whk>On the topic which spec ("Revised Report on the Algorithmic Language Scheme") should I be looking at for guile. The man page says support for R5RS and R6RS, guile -h lists --r6rs and --r7rs, but doesn't list the default. Side note the link for R6RS on https://www.gnu.org/software/guile/learn/ appears to be down. <mehlon>it's simple enough that technically you don't need to read a book to learn it, you can of course just copy and paste code until you get it <mehlon>same thing with Nix and its language <mehlon>but the htdp book only uses LISP as a stepping point to learn programming in general, they chose Racket because it's simple enough that you don't really need to focus too much on the specifics of it to understand what it does, unlike more complicated langauges like C, Java and Python <kamil_>mehlon, perhaps, but I'd dare to say that Nix has been much easier for me... most likely due to the fact that the default configuration.nix contained all necessary components needed to build a functional OS that suits my needs, I guess. <mehlon>Nix as of currently still wins out in terms of ease of use and completeness of functionality for me. <kamil_>I see. So, if I understand correctly, it's a long-term investment in case of the HTDP book. <mehlon>yeah it's like learning Latin, or Esperanto <kamil_>As for Nix, I'd not be here today if it wasn't for the fact that folks at GNU have made security a priority for Guix <mehlon>I'm a big fan of the whole Guile-based system idea, but I just woudn't run it on any of my devices right now <kamil_>Yesterday I was in shock to discover that nixpkgs has a lot of weak points in the chain of trust and that commtis are not signed.. <whk>kamil_: No problem I usually tell people to pick something that they can do something they want to get started so scheme is a good choice if you are interested in guix to get the basics and learn how systems work. In the long run learn a shell scripting language [sh/bash family is my preference but I know alot of people you use tcsh and ksh], a good interpreted language that is likely to be installed on any machine you use (or that allows <whk> you to run from a user login) [My goto is perl but the majority of people I work with use python (I hate the indent requirements) although scheme does look interesting], and then a compiled language [fortran, c and then java are my current types]. <whk>Guix is interesting me because of secured reproducible builds at the system level. <kamil_>mehlon, I can't use it until those issues are addressed with the introduction of flakes, which are going to replace channels AFAIK. <kamil_>I hope it's okay if I link Nix's GitHub repository here for context <mehlon>They do have stable channels that only select commits go to, and the update procedure is secured by the regular HTTPS. But I'm not too familiar on how another distro would do it <kamil_>whk, Woah. Thanks a lot! That's a lot to process. Well. I'd surely like to learn a scripting language--preferably Bash--, then as you said a good interpreted language, such as Python or Perl, and then.. well.. C. However, I'm seeing a minority of people riot against use of "memory unsafe" languages, which puts me in an awkward position, where I'm unsure if it's good idea to learn a low-level thing like C, even though there are projects <kamil_>that use it and I'd like to contribute to at the same time. <mehlon>well, they're just that, a minority. Really you should learn whatever you want to, and whatever is needed for a project you like <whk>kamil_: Ultimately you will end up using the language chosen by your job or project. The important thing is to get an understanding of how the languages work and interact with the system and then be able to apply that. If you find something that interests you and then learn the language for that it will be a good start. <kamil_>Wait until they're not a minority and you've got a problem because your project is now under heavy criticism for not using one of those. <mehlon>Even though for a new project I would probably prefer Go over Python, Rust over C, Scheme over... everything. In truth most of the code in the world is old projects <kamil_>I find the response of people to using unsafe bindings, code, whatever it's called unsettling to say the least <kamil_>whk, that's all there is to it :) In the end, I just wish everything was easier to learn <kamil_>cbaines, thanks! That worked. I'm on the newest revision of Guix right now ^^ <kamil_>mehlon, True that. There's also an indisputable fact that some of the most successful software in the world carries a baggage of decades-old legacy code that developers and even end-users depend on the behaviour of <mehlon>Perhaps in the future we'll be using machine learning and neural interfaces to program computers to do stuff. <rekado>what a bleak future that would be *rekado holds on tight to this legacy code <kamil_>Oh, hi, rekado. I've got everything sorted out <mehlon>rekado: well, some code still has to run on the Star-Trek-style computers... I'm sure we'll be fixing bugs for that for the rest of eternity <kamil_>..unless machine learning does that first <rekado>kamil_: that’s great! Hope you’ll have a better time now after this rough start! <mehlon>I don't know. People want their most basic computers to be super reliable. <mehlon>You'd need a computer that's basically smart enough to just be a person to program that. <mehlon>Even configuring the mathematical laws that a computer has to abide by is really just a very high level kind of programming <kamil_>rekado, I'm yet to learn some of Guile to write a config.scm resembling my configuration.nix ^^ I still don't know if Guix is suitable for my user case--running a virtual machine with a physical dGPU attached to it. <kamil_>Do you have a rough estimation when can we expect LVM to be supported on Guix? <tsmish[m]>I sent some draft patches for LVM support to guix-patches a bit ago. <kamil_>In my current configuration, a LVM partition, which holds my current /home, spans across my entire HDD, which is the only drive that I can use for storing user data. If I purge it, it'll break the distribution I'm using right now until I manually restore /home by creating a new partition etc. <kamil_>what's the stopper that prevented LVM to be supported to begin with? <ruffni>i'm trying to set my xorg resolution from config.scm (following the manual). guix moans: "error: resolutions: unbound variable". is there a bigger example config.scm on the interwebs? i wasn't able to find a matching one.. <rekado>tsmish[m]: neat! Could you perhaps comment on the issue with some explanation of your thinking? <rekado>ruffni: care to share your config? <rekado>you’re using a variable “resolutions” that’s not defined <whk>From the Guile REPL is there a way to inspect the contents of a module (e.g. gnu) or should I read the source? Using command line completion I can see that use-service-modules is defined after I (use-modules (gnu)) but only because I knew to look for it? <tsmish[m]>rekado: hm, concerning what exactly. First patch just tries to make targets a list if it isn't already and do checks on that list. Second, well, I used "vgchange -ay", it didn't work, then I added mknodes, it worked.