<nixo_>Hi guix! Do anybody uses guile-wm on guixSD? I wanted to try it but it's not working <mikadoZero>nixo_: If you look at the GitHub repository for guile-wm in the issues you will see an old Guix specific issue that has not been responded to. *nckx can't sleep. mikadoZero: yeah, this seems to be a new bug :-/ Some grub-related commits were pushed today, maybe fallout. <nckx>Try a commit from Thursday or so. <nixo_>mikadoZero: oh, a wm that crashes is not what I want :( what are you using? I moved from i3wm to stumpwm but I think I prefer scheme to common lisp <mikadoZero>sneek: tell nixo_ I am using kmscon and emacs-no-x. I am using Emacs as a window manager. So that is elisp not scheme. Although xorg is not required. <sneek>nixo_, mikadoZero says: I am using kmscon and emacs-no-x. I am using Emacs as a window manager. So that is elisp not scheme. Although xorg is not required. <nixo_>sorry I got disconnected, got what? <mikadoZero>nixo_: I am using kmscon and emacs-no-x. I am using Emacs as a window manager. So that is elisp not scheme. Although xorg is not required. <OriansJ>mikadoZero: have you seen sway-wm yet? (The wayland i3 fork) <nixo_>My fear is that if I have any problem with emacs I won't be able to do anything. Also sometimes emacs is slow I don't want it to slow down everything <OriansJ>nixo_: no one here expects you to do anything that makes you uncomfortable. Use what makes you happy and change what you use if it doesn't make you happy <mikadoZero>nixo_: I was just sharing what I am using, as you had asked. I agree with OriansJ. <OriansJ>nixo_: you might wish to try guilewm if you want scheme based window manager <nixo_>OriansJ: yeah that's why I'm asking for opinions .-. I'm not happy with my current setup (because of common lisp), I'd love to use emacs as a wm too but I'm not sure if it will fit my habits. It was not charging anone <OriansJ>nixo_: have you tried xmonad yet? I know it isn't a scheme config but some people here quite enjoy it (enough to get a GHC seed into guix) <OriansJ>Althought to be honest I am partial to dwm with guile hooks (my own personal fork one could say) <nixo_>OriansJ: I tried xmonad years ago, I should really give it a try again! Also, where can I find dwm+guile? <OriansJ>nixo_: you just take regular dwm and follow the guile-c guide <nixo_>OriansJ: oh I might try with i3wm+guile then! Would be a fun week end project <nixo_>I'm going to sleep, thanks everybody for the suggestions! I already added guile support in a C++ program once, so if it goes well I'll let you know :) good bye everybody <OriansJ>nixo_: see if you can completely convert the i3wm config file to pure scheme <OriansJ>bonus points if you can pull out big chunks of C into a few small scheme bits one can throw in their configuration folder <leungbk>how can i apply a patch to a .el package? with (patches (search-patches "my.patch")) in the build recipe, the build complains that the package is not a .tar <leungbk>i'm trying to install an editor-agnostic plugin that happens to come with an emacs package. i suppose one way of packaging it without forcing the user to install emacs is to define the editor-agnostic backend and the emacs plugin as separate packages. is there a clean way of defining all this as a single package, so that the elisp library gets installed only if the person trying to install it has emacs already installed? <jackhill>sneek later tell leungbk perhaps instead of a whole separate package a separate output would do? However, does having the elisp files (and compiled elisp files) available force the user to install emacs? My untested assumption would be that it would not (just like having info files doesn't force a user to install an info reader). Of course emacs will be required to build, but if a user is able to get a ***jonsger1 is now known as jonsger
<rvgn>Can GNU Mailutils be used as exim alternative? <rvgn>Actually I am confused after reading Mailutils manual. It says mailutils can be used to read and serve emails. But I do not see any steps to setup domain for incoming messages. Am I missing something? <janneke>rvgn: no, mailutils does not provide an MTA <phenoble>I'm having an issue using the latest gcc, reproducibly, involving c++17 and std::optional: <phenoble>g++ 190319_optional.cpp -std=c++17 -o out && ./out <phenoble>In file included from 190319_optional.cpp:1: <phenoble>/gnu/store/spmb6xxvzhf99a1bzzzgz8rnx2da21n3-gcc-8.3.0/include/c++/optional:105:8: error: ‘is_trivially_destructible_v’ was not declared in this scope <phenoble>While trying to compile -anything- that #includes <optional>. This compiles using the system g++. <phenoble>I'm not sure how to proceed. Does anyone have any ideas? <roptat>I'm trying to use screen to connect to a serial port on an arm board, but all I see is garbage <roptat>my guess is that I need to specify the right baud rate, but I don't know how to specify a baud rate and how to find the baud rate of the board <OriansJ>roptat: when you do screen /dev/ttyUSB0 115200; the 115200 is the baud rate <OriansJ>there are only a few standard baud rates <roptat>I can finally debug that boot failure <roptat>oh, failed to resolve partition "my-root" <roptat>could it be that I'm missing a kernel module for the sd card reader? <OriansJ>roptat: or failed to include my-root in your mapping; (aka where would guix find that my-root = /dev/mmcblk0p1 ? <OriansJ>roptat: did you remember to have a reference in mapped-device ? <roptat>cannot guix find it, just like /dev/sd*? <OriansJ>what happens when you change the (device ...) to just use the /dev/$partition? <roptat>or should I create a new system? <OriansJ>roptat: I am going to be completely honest, I've never had success with the repl (I really wish there was much better documentation and live fire examples to learn from) <roptat>well, from the repl I can't see the partition in /dev, so I think specifying the partition directly won't work anyway ***rekado_ is now known as rekado
<rekado>phenoble: are you using the “gcc-toolchain” package? <laalf>hey! quick question: is anyone working on gnustep? what is there is far from a working DE. <Formbi>I think it was discontinued a long time ago <efraim>Dumpster dove a new motherboard and PSU. Intel 775 is Conroe? Might be time to actually use a desktop for the first time in 15 years. I'll have to check which CPU is inside first <laalf>efraim: are you trying to build a desktop or are you looking for decent 775 cpus to buy? <efraim>laalf: actually a stripped case, came with an unknown CPU and heatsink and a cd drive, no RAM or HDDs <laalf>efraim: ah alright. there are very powerful librebootable boards for desktops. <efraim>I need to check my kids' computer, it might be a slight upgrade depending on the chip <rvgn>Apart from KeePassXC, are there any other pass* managers currently available in the guix repo? Thanks! <kmicu>There is password-store. I don’t need anyting else 😺 <rvgn>kmicu Thanks! Does it have GUI? <nckx>civodul: Have you seen the bug with the new GRUB invocation? <nckx>I just encountered it too. <roptat>so at boot, /dev doesn't have my root partition (or sd card it's on, even) <roptat>I booted another distro to try and find what was needed for the partition to be found in /dev <roptat>but I'm not sure how to find that information <roptat>lspci doesn't show a single entry for instance <laalf>roptat: lsblk shows you partitions and mount points. you need to add them to your config <roptat>laalf, yes, but at boot I get a repl, from which I ran (find-files "/dev" ".") and nothing like my partition was listed <roptat>so I'm thinking that I lack a kernel module <roptat>lsblk shows -mmcblk0p1 179:1 0 29.9G 0 part / <roptat>and that's what I used in my config <roptat>but if it's not in /dev, guix cannot mount it anyway :p <civodul>nckx: do you have more info than in the bug report? ***daviid is now known as Guest36017
***Guest36017 is now known as daviid
<nckx>civodul: No. Your new output-hiding code hides the output a bit too well ;-) <civodul>nckx: look, people were complaining that it was too verbose, so... <civodul>interesting, let's follow their lead! <OriansJ>civodul: troll level a little high today? <OriansJ>or as they say in Fowlerville, that dark road only ends with a gunshot... *nckx notices that having your server logs open when posting a link in IRC is… interesting. <OriansJ>think 3K+ people who have multiple Assult rifles at home and practice shooting weekly. <OriansJ>very lovely people but it is best to stick to the main roads in that town. <janneke>sticking to the main roads is very popular anyway <OriansJ>keep in mind Michigan is approximately 250,737 sq km with 10M people <OriansJ>But why they made the world's largest wooden roller-coster is beyound me. *nckx is originally from Kansas (even lower population) and has fired diverse firearms as required by the constitution but still… militias… geh. ***Acou_Bass is now known as eddie
***eddie is now known as Guest5970
***Guest5970 is now known as Acou_Bass
<mikadoZero>In the manual section 14.1 Building from Git it says to run ‘./configure --localstatedir=DIRECTORY’. It says DIRECTORY should be localstatedir. Is there a command to look up localstatedir? <mikadoZero>I am trying to follow the documentation in the contributing section of the manual as I would like to submit some patches. After running `guix environment guix` I run `./bootstrap` and it fails. There are several warnings and error and it end with "autoreconf: /gnu/store/rfaqi3a9ls7adr4y7bgwvln3iaf69qwj-autoconf-2.69/bin/autoconf failed with exit status: 1" <mikadoZero>I have pasted it's full output to 1073501 on paste.debian.net <mikadoZero>roptat: `git status` says "On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean" <roptat>looks like you're missing pkg-config <roptat>but it should be available once you're inside the environment <lfam>Does anyone know off-hand the oldest Linux kernel we support? <lfam>Hm, too bad. I wish we could rely on getrandom (2) from 3.17 <roptat>now I feel stupid... I found the right driver, sunxi-mmc, but I put sunxi_mmc in the configuration <roptat>strangely enough, guix happily built the system <roptat>so I booted it, but it can't find sunxi_mmc <vagrantc>there are likely modules that it requires to work that can't be represented as module dependencies <roptat>how can I load that module from the repl to verify that it's indeed the one I need <lfam>Hi katco[m], are you available to chat about Go in Guix? <roptat>I try to install the guix system, but I get a repl at boot because it can't find a module <roptat>so I'd like to load that from the repl to see if that helps <roptat>(the reason why I added the module to the initramfs was because the mmc on which the root partition is was not detected) <vagrantc>usually the sunxi_mmc module also requires other modules that are more platform-specific in addition to sunxi_mmc <lfam>katco: Great! I was wondering what you know about the GOCACHE? Like, is there a reference for what goes into calculating the staleness of the compiled objects? It's sort of annoying that we aren't re-using them anymore and have to build the entire dependency graph for each package build <lfam>katco: Or do you think we should just ignore this issue? <vagrantc>roptat: which board are you working with? <rekado>efraim: yes, I think our glibc still supports 2.6 from RHEL 6. <roptat>vagrantc, a cubietruck (cubieboard 3) <roptat>I used load-linux-module* from (gnu build linux-modules) and I was able to load it, and then the mmc was available in /dev :) <katco>lfam: i am not aware of any detailed reference available for what goes into calculating the staleness -- only that it's baked into the toolchain <katco>lfam: regarding rebuilding the entire dependency graph for each package: are you referring to ci, or a user's machine? <roptat>I used sunxi_mmc in the config, and guix happily built it, but at boot it couldn't find the file because it's named sunxi-mmc <roptat>how can I continue booting now that I loaded the right module? <roptat>(I tried ,q but the kernel panicked) <lfam>katco: From what I've observed, any time a Go package with Go dependencies is built with Guix, all the Go dependencies were being re-compiled for each package. Like, the Go compiler never saw a cache hit even when we were preserving and installing the compiled libaries <lfam>katco: It used to work, before Go 1.10 <lfam>katco: But I think that the Go team is not that interested in making it possible to instrument the compiler in the way we would like, so it might not be worth fighting against the grain <katco>lfam: ah, i think i know why: https://golang.org/doc/go1.10 "The go build command now maintains a cache of recently built packages, separate from the installed packages in $GOROOT/pkg or $GOPATH/pkg." <katco>lfam: there are a lot of knobs we can tweak, so i think we should be able to get the behavior we want <lfam>It strikes me that they have implemented a memoized cache, which we want to instrument within our own memoized cache... it makes my head hurt a bit ;) <lfam>I'm re-reading your patch for Go 1.11 which addresses the scripting engine they use for tests <katco>lfam: so prior to v1.11, the go toolchain would have consulted `$GOPATH/pkg`. now, it wants to consule (by default) ${HOME}/go/(something something), and since it's not finding anything there, it tries to do a good thing and populate the cache <katco>and btw this work is in support of shifting to go modules. this might portend larger changes needed <katco>(i think these changes would be good and make go easier to support in guix) <lfam>I haven't grokked Go modules yet so I don't even know what to ask you about them :/ <lfam>But any suggestions you have would be very welcome, of course! <katco>conceptually, it's pretty simple. the big moving parts are: (1) go code no longer need live in $GOPATH (2) there are 2 new files (a) go.mod describes what module a repo provides, and all its deps with versions (2) go.sum describes the checksum of its deps to ensure idempotency (3) this new cache which is used together with go.sum to speed up builds/testing <katco>so at the root of modern go projects, you should see a (go.sum go.mod) tuple <katco>and i'd imagine that would be very useful for us trying to discover deps :) <lfam>Yes, I referred to go.mod for recent work on Syncthing <lfam>So the code does not need to be in GOPATH. How does the compiler find the code at build time? <lfam>Sorry if this is too basic, I can come back after reading more. I don't want to waste your time <katco>(1) checks $(GOCACHE) for the import path, and against the `go.sum` entry for that module (2) if it can't be found, it downloads it into the cache, and builds the cache (3) if you specify a `-mod=vendor` flag, it will _only_ check the /vendor directory <katco>nah i am happy to have this discussion :) <lfam>So we would need to either do 1 or 3, since we can't download anything into the Guix build environment <katco>i would be very reticent to try and manually reproduce $GOCACHE <katco>from guix's build perspective, one idea might be to populate the `/vendor` direcctory with the deps we know about, and the do builds with the `-mod=vendor` flag <katco>this will not reach out to any external resources <katco>i guess that doesn't get around having to rebuild everything. go does provide the ability to compile linkable libs <katco>so we could treat it more like c-style things and have packages provide the source and the linkable lib, and then when we build things with just link everything together <rvgn>Is there a feature in Guix that is similar to Ansible for IT Automation? <lfam>katco: Thanks, that seems like the way to go <rvgn>katco Thanks! I'll check that out. <katco>lfam: i think there are good things possible (1) not having to construct a "fake" gopath to build software (2) linking things together might get guix on a path our devs are more familiar with <lfam>Yeah, that would be more idiomatic for Guix. Currently our Go support is kinda weird :/ <rvgn>katco That's exactly what I was looking for. :) <lfam>katco: Would you be interested in trying to implement this? <katco>lfam: interested? very! should i? no. i have no time haha. my next block of guix time is actually to work on the common-lisp builder for a similar problem <lfam>Heh, okay, then I will take a crack at it soon-ish ™ <katco>:) i will try and keep up on the mailing list. theoretically i should be spending fridays on stuff like this, but practically it seems like something always comes up <lfam>Oh, I had another question. What do you think about my proposal from that guix-devel thread about coalescing the various sub-library packages back together? Like, removing packages such as 'go-golang-org-x-net-ipv4' and 'go-golang-org-x-net-ipv6' and simply providing 'go-golang-org-x-net' <katco>i also need to learn guile a bit better. my common-lisp brain can understand it if i squint haha <katco>lfam: yeah that was interesting. i definitely agree that when people are working with the toolchain day-to-day they're working in terms of whole repositories. i think with modules, that is cemented even more. you download an entire module, checksum an entire module, etc. i think paths increasingly become like namespaces in jars <katco>it might be useful to switch our vernacular over to "module" to represent the root of a path that has a `go.mod`. note, that it's possible for a `go.mod` to live in a leaf of a repo's tree, but the community seems to be establishing a `go.mod` in the root of the repo as best practice <rvgn>Isn't it Python better than Go? O_o <katco>rvgn: sorry, i don't understand your question <rvgn>Oh sorry! Ne'er mind. I misread above conversation. <rvgn>I thought you are trying to implement Go in Guix for unique use cases. That's why I mentioned Python is better Go (as I have been told). <lfam>I care more about the applications written in Go... there are some really cool ones :) <katco>rvgn: i think which is "better" is situational and subjective :) <katco>lfam: go certainly seems to have cornered the ops space <rvgn>katco I was thinking about design model and standards, which are objective measure. <katco>ok, my poor daughter has been waiting on me long enough. good luck lfam and i'll see you on the mailing list <rvgn>I came to know that Python Standards are similar to GNU Standards. <lfam>Thanks for your time katco! <lfam>rvgn: Like devops, software deployment, orchestration, etc <lfam>A lot of that kind of software is being written in Go now <lfam>For me, Syncthing is the primary motivator for working on Guix's Go support <rvgn>Docker, Rancher, Kubernetes etx.. <rvgn>But Python can be used for ops with modules. <Formbi>can I use guix configuration system on a foreign distro? <rvgn>Same. Guix System init [config file] <pkill9>isn't guix configuration system for the Guix distro? <pkill9>oh are you overwriting your foreign distro? <pkill9>oh then don't run guix system init <rvgn>Most guix files will be under /gnu/store. Guix also doesn't affect other directories much. But be careful about grub under /boot. <pkill9>you can use Guix as a package manager on a foreign distro, but you cann't manage the foreign distro with guix <rvgn>pkill9 You can use Guix System within foriegn distro. One of the user in this group tried it inside debian. <Formbi>it would be nice if it could work without setting up GRUB and such things <pkill9>did it still run debian but guix managing the users or something? <rvgn>Overlapping directories was only affected. Like /boot/grub. <janneke>building guile fails for me on core-updates <rvgn>pkill9 Both. debian uses /.local and guix uses ./guixprofile <janneke>GC Warning: Out of Memory! Heap size: 1 MiB. Returning NULL! <janneke>Warning: Unwind-only `out-of-memory' exception; skipping pre-unwind handler. <rvgn>pkill9 You can create separate menu entries in grub to either load debian kernel or guix kernel. <rvgn>as they exsist in diff directories <janneke> /me is going to try with #:parallel-tests? #f <rvgn>janneke Guix System inside foreign distro is not advisable for production. But you can play with that for fun. <janneke>rvgn: ime using guix on a foreign distro can be a clean way out of dependency hell, i have been doing that for ~2y now at a client <rvgn>janneke I wasn't reffering to Guix Package. I was to Guix System. :) *janneke reads conversation above and remembers <jackhill>Is it just me or is paredit confused by the description of emacs-nhexl-mode? <civodul>janneke: that Guile unit test you mention above fails quite often <civodul>i don't know if it's a function of the available memory or what <janneke>civodul: this is on a machine with 32cores, could that be a problem? <janneke>i had it fail 3 times in a row and was done with it :-/, want to prototype a new mes release + bootstrap for when arm becomes ready :) <janneke>civodul: for luck or otherwise, the #:parallel-tests? #f build just succeeded <civodul>janneke: it might be it, dunno, nothing obvious to me! <civodul>if it does solve the problem, go for it <janneke>civodul: okay, i'll be building this more often and am bound to find out if it matters or not.. ***timothy is now known as Guest62764
<ArneBab>After todays package -u my local firefox install works again! Thank you! <roptat>I'm finaly able to boot the guix system on my cubietruck \o/ <roptat>now running guix pull to update and improve the system :) <vagrantc>roptat: how did you get past the initrd? <roptat>I reinstalled everything and specified (initrd-modules (cons "sunxi-mmc" %base-initrd-modules)) <roptat>but I wonder why guix let me do that in the first place... <nckx>roptat: There are a lot of places (like kmod, I think) where _ and - are equivalent and silently corrected. I thought Guix did the right thing here too, but it only takes one place in the chain that doesn't to break things… <roptat>it works now, so I'm very happy :) <roptat>ah, I forgot to authorize substitutes, no wonder why it was rebuilding everything ^^' <roptat>oh mh... I think I'll need ntp too <nckx>Reproducible system time. 
