<civodul>yes, apparently it hasn't been rebuilt in a while <dstolfa>nckx: okay, i've managed to trigger it with -j2 and it seems to happen very rarely <lfam>civodul: Yes, it's a long-standing problem, but cron getting stuck is a new wrinkle <lfam>The guix-translated-texinfo.drv doesn't build reliably with multiple threads <lfam>And it's a dependency of the up-to-date manual and cookbook derivations ***ChanServ sets mode: +o nckx
***nckx sets mode: +q evil-mode!*@*
*raghavgururajan 's X200T reached 50C temp and turned-off, while bootstrapping guix. ***ChanServ sets mode: +o litharge
***litharge sets mode: -qo evil-mode!*@* litharge
***nckx sets mode: -q evil-mode!*@*
<nckx>50C? Mine reaches 100 when I forget to limit it :-/ <nckx>X230 though, which I guess TIL matters. ***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!*@2a02:1810:1c81:e400:9994:a348:232:ecf0
***litharge sets mode: -o litharge
***ChanServ sets mode: +o litharge
***litharge sets mode: -qo *!*@2a02:1810:1c81:e400:9994:a348:232:ecf0 litharge
***ChanServ sets mode: -o nckx
***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!*@2a02:1810:1c81:e400:9994:a348:232:ecf0
<raghavgururajan>nckx: Seems like my X200T doesn't like to go above 35C, else it hisses at me with performance. ***litharge sets mode: -qo *!*@2a02:1810:1c81:e400:9994:a348:232:ecf0 litharge
<nckx>I try to keep mine under 75. More just ain't healthy for the little fellow. <raghavgururajan>nckx: Is there a way to control temp and/or fan in guix system? Looks like my CPU "Intel(R) Core(TM)2 Duo CPU L9600 @ 2.13GHz" isn't supported by thermald. <nckx>I just use cpufreq-set, and even that is a pointless wrapper around /sys. I don't personally get why thermald exists but I'm sure it's useful to someone. <nckx>It can track bans & quiets. <nckx>evil-mode was my evil twin. <dstolfa>raghavgururajan: tlp works well for me on my laptop <nckx>No, but only because I'm lazy and never ported my .xsession to proper services. (It's not like I've used X for ages either.) <nckx>If I'd make it a service I'd just write to /sys. <dstolfa>yeah, tlp is for power, but it helps with heat because you can set cpu frequency with it :D <nckx>Ah, now TLP I get. It does lots more. <dstolfa>there's also thermald (also in that link) <nckx>Didn't Yoshimi used to come with a preset bank preloaded with all the goodies in /share? Now the bank is empty, but the files are still there. <dstolfa>nckx: does `make check-system` run for you on the latest commit? <dstolfa>i get a hint: Did you forget `(use-modules (gnu ci))'? <nckx>Well, no, but it never has for as long as I can remember. <nckx>The encrypted-root LUKS tests simply freeze, for instance. <nckx>There's other stuff that has ‘always’ failed… <nckx>And since I like to play with my kernel/OS I always assume it's my fault and move on. <nckx>dstolfa: Which test fails? <dstolfa>they don't even run, i just get hint: Did you forget `(use-modules (gnu ci))'? right away <nckx>This is a very recent regression. <dstolfa>nckx: btw if you'd like me to just bisect/report without pinging, just let me know :). i'm just pinging in case i run into common issues that i'm not aware of <PotentialUser-83>howdy guix folk! newbie question: I can use 'guix system image' from a configuration file to build a custom live USB image, that I could boot from and use as a portable computer of sorts? <PotentialUser-83>(e.g. work on the configuration I want to actually install on a computer, or just have a portable config the way I like to use anywhere) <nckx>Bah, ‘record ABI mismatch; recompilation needed’, which takes a while on this machine, so bisecting won't be fast. Pinging is always welcome dstolfa, but since one of us has 20 cores, bisection would also be much appreciated. <civodul>lfam: i think the "map(PROT_NONE)" failure is gone with 0aef94e7bcbd272720f14c5343f74da5201ef90a <lfam>civodul: Alright, we'll find out :) <lfam>PotentialUser-83: Yes, that's the idea <lfam>That command can make a variety of types of images, including images for a USB flash drive <PotentialUser-83>lfam: very cool. so I can play with guix on a foreign os to figure out what I want on the image, then use that to make a live USB with guix system. sounds fun :) <lfam>Guix is pretty I/O intensive, so you may want to pick your storage device carefully <PotentialUser-83>gotcha. thinking mostly to experiment a little first (won't do massive recompiles at least) and have a nice emergency system too <nckx>Testing now. What's the ‘dumb’ patch? <nckx>I was expecting a subtle (or not) cyclic module import from the bogus ci error, but I don't quite see it. <dstolfa>nckx: it doesn't work. i just tried to add #:use-module (gnu ci) to keyboard.scm :) <nckx>Reverting it seems to fix the problem, thanks. <dstolfa>nckx: no problem! FWIW i can't see the cycle either. is there a way to make guile dump the module graph? <nckx>(Maybe it isn't a cycle. Just adding the import line without the rest of Hui's patch doesn't break it…) <nckx>Haha, no, I don't think so, that would be cheating 😉 <nckx>And convenient, which is worse. <nckx>How would you ever build character? <dstolfa>nckx: well, i tried to search for the obvious mistakes, but i don't have the brainpower to look for non-obvoius mistakes at the moment, it's past midnight and i spent the day debugging an IR type inference algorithm <nckx>Same, I'm working. 's All right. <nckx>Do you have time to — it's been like, hours — to report another bug? <drakonis>hmm, how do i debug an invalid field specifier error? <lfam>Now we should monitor it after the next change to guix.texi and see if it gets updated automatically or not <nckx>dstolfa: Can you reproduce it after bootstrapping? <dstolfa>did a ./bootstrap, reconfigured, reran it and it still has the same issue <dstolfa>huh. is your commit still reverted maybe? :) <dstolfa>i guess a clean clone will give us the answer <nckx>No, something spooky diddled my laptop whilst I was off getting coffee and now it works. <dstolfa>let's see what a clean clone does here <dstolfa>nckx: on a fresh clone, it disappeared <dstolfa>i now have two identical checkouts, one with a fresh run of ./bootstrap, and one with an incremental run of ./bootstrap, configured in the exact same way, one runs check-system, the other doesn't <nckx>Here the first & only ./bootstrap fixed the tests. More conventional & less spooky, that. <dstolfa>yeah... but why does this happen in the first place <nckx>Did you make clean-go as part of it? <dstolfa>i didn't but it rebuilt most of guix after the pull anyway so i assume it shouldn't matter? <dstolfa>(and shouldn't autoconf exist precisely to resolve these issues...?) <dstolfa>rebuilding fresh now, let's see what happens <nckx>(You're not wrong, but…) *nckx really needs to force themselves to paperwork; will return later. <dstolfa>nckx: so make clean-go && make fixed it... <dstolfa>seems like this is a build system issue? <nckx>Well, running ‘make clean-go’ is a ‘known’ requirement… amongst those in the know. It's why I ran it as part of bootstrapping (without thinking) and noticed the tests now passed. However, I think it would make sense to run it as part of ./bootstrap. It's arguably surprising that it's not and can only reduce evil statefulness. <nckx>Problem is it will still be opportunistic, because you can't always assume make works at that point. <nckx>Although you could just invoke find -delete if that's a concern. <dstolfa>right, so every git pull, i need to re-bootstrap everything from clean? <nckx>Well, no, that's the issue. <nckx>It almost always works 😉 *dstolfa sighs at fake "incremental" build systems <nckx>That saves a *lot* of time for us without 20 cores, but occasionally this happens. <nckx>Yes, it's technically just a stale-file Makefile bug and you're very welcome to chase it down, but diminishing returns & all that. <dstolfa>nckx: i've replied to the bug with what the cause was, you can close it if you'd like <dstolfa>so in case someone runs into it, they can see a way around it, but it's not an open bug <nckx>So can you, so I'll leave it up to you. <nckx>Sending your reply to nnn-done at debbugs dot gnu dot org simultaneously closes the bug. If you just want to close a bug without having something to say, as in this case, send ‘close nnn’ to control at debbugs dot gnu dot org. <nckx>Body. Subject is ignored. <nckx>(AFAIK, plz don't go fuzz testing that assertion.) <dstolfa>nckx: so the email seems to have sent, but the bug is still open. is the delay expected, or did something go wrong? <helaoban>hey guix! if there are any virtualization gurus here, I'm trying to run guix system in a vm with qemu but I'm not able to reach a console / login prompt. <helaoban>The image boots fine and I can ssh into it, but I can't get any io in the terminal directly. I can see some output from Grub, but everything goes away once the kernel starts booting and I never get a login prompt. <helaoban>I've tested this call to qemo with an alpine image and I'm able to reach a console successfully, so I know the issue is local to the guix build. <helaoban>The image is made with `guix system image --image-type=qcow2` <nckx>I am whatever the opposite of a virtualisation guru is, but I'll let that run whilst I do my taxes. <nckx>If you don't get any help here tonight, consider the help-guix mailing list. IRC is a select crowd and many are asleep. <helaoban>I'm guessing it's a tty issue but I'm a bit out of my depth here. <dstolfa>nckx: today is just one of those days :P <helaoban>i'm not ruling out it's something local to my env though! <lfam>Thank god for fiber optics <lfam>Using the command in that manual chapter with the pre-built 1.3.0 image boots me to a desktop <lfam>I'm not very familiar with -nographic and -serial mon:stdio <lfam>Is the idea that the VMs console is hosted "natively" in your terminal emulator? <lfam>Like, rather than being in a window created by your host system's X or wayland? <helaoban>lfam: yea this is specific to a headless setup in my terminal <lfam>And it works with other images? <lfam>So, I reproduced the issue by using only -nographic. The last thing I see is "Booting `GNU Guix 1.3.0-1.771b866'" <lfam>I'm not sure what QEMU offers the guest system, but I would try adding a service for agetty <lfam>By default, Guix uses only mingetty <lfam>mingetty doesn't do serial <lfam>It only does virtual consoles <helaoban>lfam: it looks like %base-services includes an 'agetty-service-type' <lfam>Indeed, I forgot it was added there <lfam>Then I'm not sure. I would still look into tweaking the agetty service <lfam>You know, just cause I don't have any other ideas <helaoban>lfam: ok good idea, I'll read up on the options and try to understand the problem a bit more. <lfam>It might be something else, I'm really not sure <cbaines>this sounds like it might overlap with the problems I'm having trying to get to a login prompt for the Honeycomb LX2 system... <lfam>Could also be a bug in the agetty service <lfam>I suspect the agetty service is not really used that often... <lfam>However, I have used it successfully <nckx>qemu-system-x86_64 -nic user,model=virtio-net-pci -enable-kvm -m 1024 -device virtio-blk,drive=myhd -drive if=none,file=/tmp/guix-system-vm-image-1.3.0.x86_64-linux.qcow2,id=myhd <nckx>boots like a champ to desktop here. <cbaines>I did try just using a system with the %base-services, rather than the installer services, but that still didn't work <nckx>So the only variable is your QEMU vs. mine. <lfam>Yeah, we are trying to boot to a virtualized serial console nckx <cbaines>I'm not sure how that mixes agetty and mingetty though <lfam>nckx: Try adding -nographic to your QEMU invocatoin <helaoban>nckx: this seems to be isolated to a headless setup, e.g qemu with -nographic. <lfam>Also, the agetty service will not work automatically in every instance. With serial devices... sometimes you have to tear your hair out for a while <lfam>helaoban: This is probably not related, but I recommend instructing GRUB to display on the serial console. You can add (terminal-outputs '(serial)) to the bootloader-configuration <lfam>(I'm not sure right now what's the difference between the 'serial' and 'console' arguments <lfam>It's been too long and I forgot <helaoban>it looks like the tty option is set to #f by default in agetty-configuration, maybe it needs to be specified? <lfam>"Valid terminal input names depend on the platform, but may include ‘console’ (native platform console), ‘serial’ (serial terminal), ‘serial_<port>’ (serial terminal with explicit port selection), ‘at_keyboard’ (PC AT keyboard), or ‘usb_keyboard’ (USB keyboard using the HID Boot Protocol, for cases where the firmware does not handle this). " <lfam>I pasted the wrong section from the GRUB manual. I shared the part about inputs rather than outputs. Anyways, close enough ;) <lfam>It's almost certainly not the problem here <helaoban>lfam: yea that's what I was going to try, i'll report back. <nckx>For GRUB, you'll want something like ‘insmod serial; terminal_output serial_com0; terminal_input serial_com0’. <nckx>lfam: console is VGA text console IIRC. <nckx>For Linux, all you need is to add console=ttyS0 to the kernel command line (either in GRUB, or with kernel-arguments in your configuration file). <nckx>agetty will do the right thing. <nckx>Although my serial console is now getting spammed by an X service that doesn't realise it can't ever start ☺ <nckx>‘sudo herd stop xorg-server’ fixed that. Another thing you can fix properly by editing your vm.scm. <nckx>This is the first time I've ever booted to a serial console. Neat. <lfam>If you thought GNU / Linux could be frustrating before... <lfam>If you ever wanted to be able to type "too fast" <nckx>Oh, QEMU totally desyncs shift and caps lock the first time you press shift. So I actually had to type console=0 (left arrow ttyS). <lfam>It really increases the puzzle factor <helaoban>nickx: cool! I'm trying to implement your suggestions but i'm working on a cheap vps and it's taking a while to re-create the image. <nckx>terminal__0 (left arrow, left arrow) output (space) serial (right arrow) com <nckx>…if you wondered why I was a bit slow to answer. <nckx>(☝ might have something to do with my :swapcaps configuration, in case nobody can reproduce.) <nckx>I know ‘guix deploy’ supports digital ocean. I can't vouch for the quality or ease of use. <lfam>I wasn't planning to reproduce that one <helaoban>nckx, lfam: success! adding console=ttyS0 to the kernel arguments dit it! <lfam>I don't think we have a service for i2pd yet <lfam>We just have the package <lfam>We have a service for tor, so maybe you could take inspiration from that and write an i2pd service :) <PotentialUser-71>Oh, I doubt it very much) I'm not a coder. And I noticed there a service for Yggdrasil, but how to turn it on? <lfam>It looks like you add an yggdrasil-service-type to your config.scm, configure it, and make the '/etc/yggdrasil-private.conf'. <lfam>Then, you'll do `sudo guix system reconfigure /etc/config.scm` and (maybe) reboot <lfam>I'm not familiar with this service. Hopefully somebody else with more experience can answer any more questions you have about it <drakonis>when is gnome getting updated raghavgururajan? <drakonis>we're stuck on a two year old gnome release <lfam>GNOME is one of the more complicated software systems that we have in Guix <drakonis>yup, definitely having issues with gnome and wine lol <tpefreedom>At least that means it would work well with b00merang themes. <raghavgururajan>drakonis: I am trying to figure something out to continue to the gnome work. My device is melty. <The_tubular>Let's get guix on my prod machine, might have a few more questions later ...! <drakonis>3.34 has some pretty nasty issues with wine lol <drakonis>if i tab in and out, it hoses the whole thing and i have to kill xorg ***orvi is now known as Guest2300
<raghavgururajan>sneek, later tell nckx: Can you have a look at #48729 to see if all look good to you? <The_tubular>Let's say I want to run nextcloud preferably in a container, what would be the the best way of achieving this with guix ? <The_tubular>Could I achieve this with guix container or would I need to use docker? <The_tubular> Only the nextcloud-client is available in the repo AFAIK <The_tubular>Also, unrelated, why is nmap in the guix repo ? Didn't they change for a "non-FOSS" liccense 2-3 months ago ? ***taylan2 is now known as taylan
***Kimapr9 is now known as Kimapr
***iskarian is now known as Guest3092
***iskarian is now known as Guest5434
<boeg>where in the source tree is %desktop-services defined? <boeg>found it - just had to look in /gnu ***terpri is now known as robin
<Guest4977>Hello guix, since yesterday I'm still fighting with my fresh cross-builded pinebook-pro.scm image running on real hardware and I'm currently stuck with: 'guix pull: error: Git error: the SSL certificate is invalid' <Guest4977>I've exported environmental variable GIT_SSL_CAINFO from 'guix environment --ad-hoc git nss-certs' and after 'herd restart guix-daemon' the error is still the same <viivien>Hello guix, I’d like to create a channel with my package. I’m considering switching my main project to AGPL. Does guix provide an easy way to keep track of the full source tarball (after modification phases) so that I can serve it with a web service? <boeg>Does anybody know how to get icon themes working when using something like i3/sway instead of GNOME and the like? I'm testing with Thunar which doesnt have any icons right now. I have installed hicolor-icon-theme as well as papirus-icon-theme but no luck. <boeg>wirez: I mean icons in apps <boeg>in like Thunar and other apps that requires an icon theme installed <jak_wolf>wirez I think boeg means in individual apps <wirez>is that in a .xinitrc or smth? <Guest4977>jak_wolf: yes I was doing similar steps except the last part from your link: '~/.guix-profile/bin/git pull' because I don't know where guix repo is stored exactly <viivien>avalenn, this distribution does not seem to insist on only shipping free software. There’s even an FAQ entry about how to run proprietary DRMs. I’m not sure many guix people will be interested. <avalenn>I am sure no Guix people will install this. But I thought the concept of putting all in Git could resonate for some. <Guest4977>jak_wolf: I can also git pull external repos it just doesn't work with 'guix pull' <Guest4977>I mean to make 'git clone' works I had to add 'export GIT_SSL_NO_VERIFY=1' <Guest4977>because it was also complaining that 'CRLfile: none' <boeg>avalenn: thank you for the link ***roptat is now known as Guest9177
<irfus>deterministic builds (with --rounds=2) for mesa are failing <irfus>^ (testing the updated definition ) <irfus>how do I find what's responsible from the build log? <rekado_>irfus: I would do “guix build --rounds=2 --no-grafts -K mesa” and then compare the two outputs. <Guest4977>Fixed, I've just realize that my system clock was showing 2013 year so I updated local datetime and guix pull works :) <jak_wolf>Guest4977 OH! the ole system clock cert issue! XD Glad you got it working <jak_wolf>And here I was about to suggest making sure to `guix pull` the build machine and build again lol <boeg>when i create a shepherd service, should I put the process into the background with & in the start constructor? <civodul>boeg: "&" is a shell construct, you cannot use it literally in the arguments to make-forkexec-constructor <boeg>really? The reason I ask is because i looked in my "udiskie" service which uses & and does work for mounting disks so it seems to not hinder anything at least <boeg>but yeah, my intuition said it was probably wrong so <boeg>also i can see i use make-system-constructor in my services <civodul>you can look for examples in (gnu services ...) <boeg>should i use make-forkexec-constructor instead? <boeg>civodul: will check it out <boeg>civodul: oh, make-system-constructor actually does run hte command in a shell <boeg>civodul: but i guess i can use make-forkexec-constructor instead <irfus>^ that's a diff of the two logs. Can somebody give a quick look-over and see if there's anything I can do to sort this out <irfus>I don't really understand why these differences are even there :( <irfus>could it be because of the build using multiple cores? <irfus>and is it necessary that builds be completely reproducible on at least my system before I submit the patch? <irfus>^ and that's the patch to core-updates in case somebody wants to help test ***terpri is now known as robin
<boeg>anybody know in which package gsettings is located? <efraim>I think I've fixed ':Guix edit foo'. Now the decision is if I should only accept ':Guix edit' or also ':Guix EdiT' and others <efraim>almost there, ':Guix edit hello freeipmi' doesn't work yet <danrobi70>Im testing guix rn. Having issue with appimages. How to run appimages with guix? <maximed>I'd presume the same way as in other distributions, but I don't actually use appimages myself <sneek>maximed, you have 1 message! <sneek>maximed, sarna says: I looked there but haven't found anything haha, I'm not that good with reading guile source yet :D but thanks! <danrobi70>no not the same way because return no such file <MysteriousSilver>it would be helpful if you explain what you did and what was the error message returned <danrobi70>well nothing special here. appiamge in ~/ and return no sucj file <xeaal>Hello guys, I'm sorry if this is a frequently asked question but how do I set environment variables in Guix? For example for my EDITOR to be emacs <danrobi70>do I need to put the appimage somewhere specific in order to be seen? I exported the path for ~/.local/bin and in there return the same no sucj file <efraim>appimages aren't supported in Guix, they expect certain libraries and binaries at certain locations, and they just aren't there with guix <efraim>I can recommend flatpaks though, they work <ss2>I'm running the installer at the moment, and local substitute discovery isn't really discovering any neighbouring hosts. <ss2>maybe it has got to do with that it is running in a VM? <xeaal>Had no luck setting a variable via ~/.profile. Am I doing it right? The contents of the file now are "export EDITOR=emacs" <efraim>xeaal: then run 'source ~/.profile' <efraim>it should be sourced automatically the next time you login <xeaal>So rebooting won't make it gone? <efraim>it should be sourced when logging in. I think the place to make sure would be /etc/profile, but I'm not sure <efraim>I keep my variables in ~/.bash_profile <efraim>or maybe it's built into bash to source it, I'm really not clear on how it works <xeaal>still doesn't work for me, even after putting variable in /etc/profile <xeaal>is there a way to set an environment variable via the guix config file? <efraim>if you're using bash then try .bash_profile <xeaal>yeah, bash_profile seems to do the job <xeaal>but still, isn't there a way to set those variables with system configuration file? <civodul>maximed: hey! i'm trying to re-introduce %build-inputs for cross-compilation (on core-updates) <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, raghavgururajan says: Can you have a look at #48729 to see if all look good to you? <maximed>civodul: I'm adding "bash-minimal" to package inputs when using "wrap-program" <maximed>my 'edit-expression'-ology is non-existent, so it will be manual <xeaal>thank you very much, I actually found the similar solution myself :) <maximed>(though helped by a linter I just sent to guix-patches@) <pkill9>you could delete it with guix gc and rebuild it <maximed>"guix gc --verify=repair /stuff" IIRC <maximed>or maybe "guix build STUFF --repair" <maximed>nckx, leoprikler: "guix build hello --repair" should work <nckx>We have a different definition of ‘specific store path’. <nckx>If you have a package object or .drv, that will absolutely work. <leoprikler>so for context, the drv itself is broken and can't be passed, not the package resulting from that drv <nckx>Well, it works (just tested) but it's not what you need. ‘guix build --repair’ builds a buildable thing, and ‘guix gc --verify=repair’ doesn't support paths yet (hence my comment above). <nckx>Can't you gc it by name? <leoprikler>yeah, but gc -D takes like .5 ms deleting the empty file and .5 years deleting unused links <nckx>(How would ‘guix build --repair broken.drv’ even know what to write to it?) <civodul>maximed: would be nice to have a high-level mechanism to describe changes on the source, sort of like Coccinelle's "semantic patches" but simply "structural patches" <civodul>maximed: in other news, gcc-cross-aarch64-linux-gnu-10.3.0.drv fails to build for me on core-updates: "aarch64-linux-gnu-ld: skipping incompatible /gnu/store/kvq1fgklb4288cn0g13jl8pvach4p3r4-glibc-cross-aarch64-linux-gnu-2.33/lib/libc.so when searching for -lc" <maximed>yes, I've been thinking of Coccinelle. Would be useful <maximed>civodul: IIRC yes, that was the error <leoprikler>because its in the process of deleting stuff and writing to hardware with me forcefully aborting it? <nckx>You're not interrupting writes to hardware… <civodul>maximed: oh maybe you sent a patch for it? (i might have missed something) <maximed>I'd suggest "--keep-failed" and take a look at the libraries (glibc & libgcc_s) (architecture, etc.) <civodul>so libc.so is a linker script, but it refers to aarch64 .so files <maximed>that LGTM aks, unless there is some big/little endian issue maybe <nckx>Anyway, if you refuse to do that you have but one option: implement ‘guix gc --verify=repair[…] FILE…’ 😉 <civodul>maximed: how did you check your Meson cross-compilation patch series? <maximed>civodul: I applied that patch for the i686-linux-gnu cross-compiler. It's somewhere at the end of the series <civodul>maximed: ah, probably the problem was just hidden by the fact that an x86_64 linker can handle i686 ELF files <maximed>& run the resulting binaries on a i686-linux-gnu <maximed>civodul: Quite possibly. Quite convenient for testing the meson patches though <efraim>civodul: I think 'guix build --system=i686-linux xz' might be a faster test case ***sneek_ is now known as sneek
<zap>abcdw: There is @@ syntax you can use in the meantime, saying just in case you didn't know <leoprikler>abcdw: Regardless of whether this is merged, I think you can use @@ to reference the Guix definition (not that it's best practise, but it exists) <abcdw>zap, leoprikler, maximed: Didn't know it works with non-exported items, thank you for the tip!) <leoprikler>shady channels use it to peek at our license code ;) <maximed>@: required variable to be exported, magic evil @@: doesn't require exported <zap>@: lawful evil @@: chaotic evil <zap>maximed: module-ref? <zap>i think there could is enough ways to import in guile to fill the whole table <maximed>What about RNRS=lawful/order? 'import' and 'export' would be lawful <maximed>@, @@ would be chaotic, because it is Guile-specific. use-modules is neutral, because while it's guile-specific, it is more 'orderely' than scattering @ and @@ around <zap>and if module-ref is not guile specific it could be lawful evil? <leoprikler>lawful, because it's "the standard", but evil because the standard is weird <maximed>@@ is evil, because it isn't nice to peek into unexported things (there is an argument to be made for being just chaotic neutral I suppose) <maximed>oh noes, the libraries I write are (lawful) evil! <leoprikler>tbf that's kinda to be expected if you're using a scheming programming language :P <maximed>‘scheming’ --> predisposition towards evil? <maximed>ISO is definitively lawful, but good? <leoprikler>in other words, your mileage may vary squared, lol <leoprikler>hmm, maybe ISO is more lawful neutral, but I kinda get some "the law is good and ISO is the law, therefore ISO is good" vibes <maximed>ISO also publishes safety standard I think. I'd say ISO is between neutral and good <maximed>but that doesn't mean all its standards are neutral or good as well <zap>the odf vs ms word story spoiled ISO reputation kinda. But I dont know all the ditails <hrnz>open standards good, iso bad. <zap>leoprikler: ah I've heard it long time ago. So my interpretation might be incorrect. But the story was that ISO cose microsoft document formats in favor of odf for standartisation <zap>can't find the reference to the story <civodul>maximed: on core-updates, the linker script libc.so read "OUTPUT_FORMAT(elf64-little)" instead of "OUTPUT_FORMAT(elf64-littleaarch64)" on master <abcdw>Thank you everyone for help, see you in a bit! <maximed>is libc.so in elf64-little or elf64-littleaarch64 format? <maximed>If it's the latter, maybe "elf64-little" can simply be substituted with "elf64-littleaarch64" <civodul>maximed: libc.so is text, it's the linker script <civodul>but "objdump -f libc.so.6" says elf64-little, including on master <maximed>maybe libgcc_s is compiled for elf64-littleaarch64 and libc.so.6 for elf64-little? <civodul>glibc commit 87d583c6e8cd0e49f64da76636ebeec033298b4d from Jan 2021 changed the way OUTPUT_FORMAT is computed... <civodul>hmmm "./pre-inst-env guix build sed -s aarch64-linux" on core-updates gives me an x86_64 binary?! <maximed>maybe add (pk 'sys (%current-system))? <maximed>Maybe it's just not being propagated by gnu-build-system or something like that, and unrelated to the toolchains ***Guest9177 is now known as roptat
<zap>anyone has a clue what can cause guix pull not to update guix? Which guix points to .config/guix/current/bin/guix but guix describe says it's from May 11th <zap>this on foreign distro btw <nckx>zap: Use ‘command -v’ instead of ‘which’ (not that I think it's likely to be the issue). <nckx>So ‘guix pull’ just happily runs without error? <roptat>zap, "type guix" is probably more accurate that which, if it's different, try "hash guix" (no output expected) <nckx>‘which’ is accurate, it just answers a different question. <zap>waat! I did rund hash guix but it did't work... Now now it did... <zap>Maybe i was logged in with oter user <nckx>zap: ‘hash guix’ tells the current shell to clear its cache of binary paths. <nckx>Each running shells has its own. <nckx>You can have a window that finds the right guix and one that doesn't. <roptat>\o/ it only took four days to update my armhf system ^^' <zap>nckx: thanks for info I was about to go search what it does <roptat>it's always a bit of an adventure :) <helaoban>is there currently a generic service to add network / modify network interfaces in guix system? <helaoban>For example I'd like to setup two VLAN devices, one configured with a static ip, the other dynamic with dhcp. <nckx>How about I add (just) a warning if ‘guix pull’ isn't invoked as $HOME/.config/guix/current/guix when that exists? <roptat>not yet, but I plan to add something like this with guile-netlink <roptat>right now, it's not easy to do, but you could create a service that invokes iproute2 to create the vlan and assign a static ip, and make dhcp-networking-service depend on it <helaoban>right now im thinking a simple wrapper service around iproute2 <helaoban>roptat: read my mind, ok, just wanted to make sure I wasn't missing something. <roptat>(it doesn't create the vlan, but it uses iproute2) <zap>i cant say that it happily did guix pull btw :) It it crashed every time with error <corrupted archife <closed file 12345>> or something like that. Then I realized that my odroid xu4 goes out of memory. And indeed guix pull filled up more than 2G at some stages. After adding swapfile and waiting few hours it did got through <roptat>zap, I have a similar issue on my armhf server, that's why updating the system always takes so long <roptat>(that and the lack of substitutes for armhf) <helaoban>roptat: that's what I was looking for, I can extend that for my purposes. <helaoban>Would be super useful to have in mainline guix! <leoprikler>phew, finally worked around my store issues and it only took one regular gc without options <roptat>again, the plan is to use guile-netlink instead <roptat>similar to iproute2, but better integrated with guile <roptat>helaoban, if you use the dhcp service, don't make the iproute2 service provision networking, or there'll be a conflict <zap>roptat: but it wasn't 'guix upgrade' i'm talking about 'guix pull' -- whether you have substitutes or not it will build allway build several derivations that fill the or I miss something <nckx>A mere 2 gigabytes is far too little memory to update the list of packages. <helaoban>roptat: looking at guile-netlink now, interesting. <nckx>zap: No substantial ones AFAIK. <helaoban>roptat: yeah, I noticed that, I'll configure dhcp for that interface manually as well. <nckx>‘guix pull’ is substitutable. <zap>roptat: sorry... typos... it will allways build several derivations that fill the RAM or I miss something <roptat>zap, I have an x86_64 server with 512MB of RAM, it's barely enough for guix pull to work when there are substitutes, adding a bit more swap lets it pass <zap>nckx: oh! didn't know that <roptat>but on armhf, I have to build the derivations for guix pull, which takes a lot more RAM <nckx>zap: Aside, make sure you're running ‘guix pull’ with -{M,c}1 (or your daemon defaults to it) or it might build multiple parts at a time. <zap>oh no... emacs \ 'build' phase <zap>wow so quick... I thought ill be waiting until the dawn <zap>nckx: thanks for aside btw i'll use it next guix pull :) <lispmacs>guix pull is broken for me. Is this well known, or do I need to file a bug report? <lispmacs>it appears to be a code and not a network issue <lispmacs>builder for `/gnu/store/x3ss3v86nll4dixzb86wmlwdv63c3rrz-module-import-compiled.drv' failed with exit code 1. log report says... <nckx>soheilkhanalipur: That doesn't look like the same problem? <nckx>It's trying to install 70-spice-webdavd.rules to eudev's /lib directory, when it should install it to phodav's. <lispmacs>then followed by the error `Unbound variable: #{\x0;\x0;\x0;\x0;\`... with \x0 repeated 10000 times <nckx>I'm afraid I can't reproduce that, lispmacs. <nckx>‘guix pull’ succeeds fine here. <nckx>TBH a variable name consisting entirely of nulls doesn't sound like an upstream typo, more like something got corrupted. <lispmacs>nckx: there was a power outage during my last pull. <nckx>Start with a ‘guix gc --verify=contents,repair’ if you haven't run it yet. <nckx>I'd also remove ~/.cache/guix. <lispmacs>nckx: do any of those commands causes builds to be deleted? I just spent two weeks building rust compilers <nckx>The ‘gc’ in there… well, it's not quite a misnomer, but it is an implementation detail. No G will be C'd ☺ <nckx>Or, like a bad superhero comic, corruption is the garbage… and it's time to take out the trash. <leoprikler>lispmacs I just recently broke my guix pull as well and a regular gc fixed it <nckx>lispmacs: Of course, if any of your Rust compilers got damaged, there's no way to repair them without substituting or rebuilding them. It's very unlikely though. <nckx>OK, so you don't mean you tried both and only a real GC helped, right? Because that would be not good. <leoprikler>I did one gc with --verify=content,repair but for some reason unbeknownst to me there seemed to be stuff it missed <leoprikler>in any case, doing a normal gc works because the new pull is not referenced by anything since it hasn't been built yet <nckx>Unfortunately, hash collisions don't actually happen in this universe. <nckx>> It's trying to install 70-spice-webdavd.rules to eudev's /lib directory, when it should install it to phodav's. <nckx>Modify phodav so it installs to its own /lib/udev/rules.d. <nckx>Somehow, some change elsewhere managed to change Meson's behaviour here, which is interesting. Maybe. <hugotty>Hello there, I'm trying to run guix on my remarkable 2 tablet using the armhf build. The daemon is up and running but now when I try to run `guix install hello` I get this error: "guix install: error: cloning builder process: Invalid argument" What could cause this? <nckx>soheilkhanalipur: I've started a git bisection to see what caused it. <nckx>hugotty: That means clone() failed. You seem to be missing the kernel namespace support which the Guix daemon needs to isolate builds when run without --disable-chroot (which is the default). Which distribution and kernel is this? <nckx>I guess it doesn't really matter unless you want to recompile your kernel. Try adding --disable-chroot to the daemon command line (if you're using systemd, that's guix-daemon.service), reload, and restart it. ***xgqt_ is now known as xgqt
<nckx>Did guix install not work? <nckx>The version separator is @, not -. <nckx>Depending on what you do, you might want to use a Guix environment to separate it from your Guile 3. <nckx>If you don't use Guile 3, no problem ☺ <hugotty>nckx: Thanks a bunch, --disable-chroot seems to have done the trick. It's running on whatever vendor kernel they ship with the device plus systemd and their e-ink gui software on top, and I am not savvy enough to be tinkering with kernels ;) <nckx>Very cool that Guix (mostly) runs on an e-ink tablet. <nckx>I hope the thermal designers had this in mind. <maximed>If the tablet melts and you invoke the warranty: ‘How did you manage to melt it?’ ‘Reading costs me a lot of energy.’ / ‘I read very intensively’ / ... <nckx>I've read paper books in the sauna. It's a valid use case. <mfg>Hi, is it possible to find the dependencies of services with guix graph or something? <nckx>mfg: guix system --help | grep graph <nckx>That'll graph services amongst themselves; not their packages if that's what you mean. <mfg>hm i see, yeah i wanted to find out which package dependebcies the services pull in... <nckx>I.e. it'll tell you that foo-service needs openssh & networking; not that it pulls in #$cups. <nckx>I'd just look at the code. ***ChanServ sets mode: +o litharge
***litharge sets mode: +q *!JLouis@*
***litharge sets mode: -o litharge
***iskarian is now known as Guest2316
<maximed>sneek: later tell civodul: I wonder if $(OBJDUMP) was aarch64-linux-gnu-objdump or simply objdump. If it is the latter, no wonder the linker script refers to the wrong format <The_tubular>What would be the best way to run nextcloud server on guix ? Preferably without Docker <lfam>I would start by looking at what Nix does <lfam>They will have basically all the same challenges as Guix <lfam>Do you have experience deploying nextcloud on other systems? <lfam>I'm not suggesting you use Nix (nor to avoid it) but rather that their service will be similar to whatever you'd have to do in Guix <lfam>Their language is not very hard to read if you know some other languages and can read shell scripts <The_tubular>Yeah, I get that the paradigm is kind of the same as Guix <sbp>sometimes you don't want to have to port the OCI container file <sbp>unless there's an automated way of doing so that I'm unaware of <sbp>I suppose it should be possible to automate it, from a quick think of what would be necessary <sbp>but I think most containers are going to be relying on distribution specific mechanisms <sbp>I'm surprised that the Guix manual mentions Docker so much. I can't imagine that Docker doesn't violate the FSDG left right and centre <sbp>I mean, if Firefox can't be packaged because it allows nonfree addons in its store, surely mentioning Docker in the Guix manual is a no go too? <nckx>I meant how does Docker recommend non-free software? <nckx>Whatever it is can probably be patched out. <nckx>(I still need to apply your patch… :-/ My CPU is racing to get work stuff done.) <sbp>yeah, this is what I'd have to check. but you don't need to patch it out because podman and buildah already exist. that's what I was hinting at: that instead of having some sort of IceCat situation where Docker has to be meticulously patched to be free, you can just recommend podman/buildah <sbp>what I'm thinking is that the manual could just mention podman and buildah where it presently mentions Docker, problem solved (if there is a problem in the first place) <nckx>But all you've done so far is ‘imagine’ there's some problem with Docker. <sbp>well, kind of. I recall seeing problems, but I don't remember the specifics. I was highlighting a potential problem, not suggesting that there is a problem for sure! <nckx>(Which is a very poor argument for replacing it with two things I've never even heard of) <sbp>as I said, I'd have to check. it'd be on me to check, I'm under no illusion about this <sbp>I mentioned it because I thought others might know more; and indeed they still might and I hope somebody who sees the foregoing can enlighten me <nckx>Thanks. It's just that there are too many people highlighting ‘potential problems’ already. That's a waste of everyone's time. <roptat>docker lets you download non-free stuff, but it's on the same level as icecat lets you download non-free software from dodgy websites :) <sbp>noted, I'll keep it to myself in future <nckx>roptat: That was my understanding as well. <vagrantc>i must admit, i am curious about the distinction between downloading random non-free things with a webbrowser and downloading add-ons in a webbrowser <roptat>the problem is not downloading addons, it's advertising non-free addons <nckx>sbp: Pointing out problems is fine! Just the hand-wringing about, hmm, it's always about the same projects, interesting 😉 <nckx>Not saying you were doing that but it triggers pattern recognition, sorry. <nckx>(It's much worse in other FSDG distributions, much better in Guix, let's keep it that way.) <vagrantc>roptat: as in there's an interface built-in to the browser to direct you to non-free things? <sbp>I've only been here a few days, so I wouldn't know <sbp>I have been reviewing the logs, but there's only so much that I can read :) ***iskarian is now known as Guest3676
<nckx>sbp: I had no idea you were new, your nick sounded much more familiar than that. Welcome. ***iyzsong- is now known as iyzsong
<vagrantc>it seems guix tends to take the pragmatic approach of "we'll do our best effort to avoid FSDG issues, but please point to *specific* issues that we can actually address" ***iskarian is now known as Guest806
<nckx>vagrantc: Specifically in the case of browsers, a menu item that takes you to a ‘store’ that lists nonfree things amongst free ones, or doesn't even care about licencing. <vagrantc>hypothetical or speculative issues are time consuming for little gain <nckx>vagrantc: Anything else is borderline theatre IMO. It's pretending your distro treats all packages equally when that's obviously impossible, so in practice it's a known list of packages ‘we’ don't like receiving disproportionate scrutiny. <nckx>Like random people insisting we audit Chromium or remove it. ***iskarian is now known as Guest5089
<roptat>nckx, audit linux-libre or remove it :p <vagrantc>yeah, i remember watching that whole "discussion" over ungoogled-chromium ... <dstolfa>there's a fine line between doing one's best to conform to FSDG, and requiring every software to be manually audited on arbitrary values of the person auditing it <sbp>that's what the FSDG says itself: <sbp>"Most distribution development teams don't have the resources to exhaustively check that their distribution meet all these criteria. Neither do we. So we expect distros to occasionally contain mistakes: nonfree software that slipped through, etc. We don't reject a distribution over mistakes." <dstolfa>there are definitely people out there who would rather have no software than something that doesn't conform 100% to their ideology or political belief (even if it does, they might find an excuse that the author of that software doesn't meet their perfect criteria) <nckx>roptat: (I mean, yes, exactly, where are the signed documents from underpaid students forced to audit it? Oh no best effort is fine *there*) <vagrantc>it seemed to go along the lines of "there's probably a problem" ... "well, i've audited thousands of files and removed all the ones identified, did i miss any?" ... "you can <vagrantc>'t possibly audit it all! there's probably still problems!" <nckx>sbp: Yep, that's why I asked for details, not because I think you're lying :) <munksgaard>I'm trying to define a package using haskell-build-system, but I cannot figure out how to specify that I want to use ghc@8.8.3 instead of (what I think is the default) ghc@8.6.5. I see that there is a #:haskell argument, but if I write ``(#:haskell ,ghc@8.8.3)` as an argument, I get an error that ghc@8.8.3 is an unbound variable <maximed>ghc@8.8.3 is CLI syntax, and does not exist within Scheme *dstolfa scp's a 100 gig file locally <nckx>munksgaard: Specifically, ghc-8.8 <maximed>Try "guix edit ghc@8.8.3", see where that version is defined, use the variable from there <nckx>since that's what the variable is called. <munksgaard>nckx: Aha! That looks like it works! Why does that not show up when I `guix search ghc`? <civodul>maximed: i've pushed a fix to core-updates that re-enables "--system" <sneek>civodul, you have 1 message! <sneek>civodul, maximed says: I wonder if $(OBJDUMP) was aarch64-linux-gnu-objdump or simply objdump. If it is the latter, no wonder the linker script refers to the wrong format <nckx>dstolfa: Not relevant if you actually want the entire thing, but sshfs is a life-saver if it's some kind of archive and you only want a tiny part. <munksgaard>maximed: I didn't know about that command, very useful! <dstolfa>nckx: it's a raw VM image that needs to go on a machine in a different VLAN (: <nckx>munksgaard: Because the CLI uses package's ‘name’ and ‘version’ fields. The Scheme code uses variable names, the (define-public THIS …) thing. <munksgaard>nckx: What's the best way to find out what the right name is? guix edit? <nckx>munksgaard: We could probably rewrite Guix to unify the two but it would murder performance and probably not be worth the edge cases. <maximed>munksgaard: specification->package can be used, but not within guix itself <nckx>If you want to script, guix show ghc@8.8 prints out the same location: field that guix edit would jump to (in a supported editor). <maximed>but good enough for random "guix.scm" you have lyingaround though <nckx>Actually not sure when you'd do that but there it is. <nckx>Ehm, well, yes, but, I, aargh. <maximed>fixing it might just be a matter of adding OBJDUMP=,(objdump-for-target) to #:make-flags <maximed>objdump-for-target doesn't exist yet though I think, but is easy to define <civodul>"aarch64-linux-gnu-objdump -f" prints elf64-littleaarch64 <maximed>it might be a good idea to automatically define OBJDUMP=..., STRIP=..., CC=..., but that seems more something for the next core-updates cycle to me <civodul>plus it's normally unnecessary, at least for Autotools-based build systems <maximed>so, set OBJDUMP in #:make-flags for now, and report it upstream? <sbp>nckx: obviously I've not had long to look into this so far, but I haven't found that the Docker *CE* software in and of itself would violate the FSDG. the Guix manual does, however, link to both the Docker and the Singularity homepages, both of which are designed to onboard people to their commercial offerings <maximed>Hopefully that's all that needs to be done <munksgaard>After specifying `(#:haskell ,ghc-8.8), it seems like all the other dependencies I've specified as inputs are no longer passed along? This is the file I'm working with: https://pastebin.com/uzi1uU1c . Upon trying to build, I get a lot of missing dependencies. If I remove line 471 those all go away (but I can't build because the `base` package and other builtins are too old). <sbp>nckx: it also links to the documentation for "docker load" on the Docker website, which I think is a more borderline case. I couldn't find a reasonable alternative either, except perhaps Ubuntu's hosting of the man page for docker load <sbp>I believe the links to the Docker and Singularity homepages are both FSDG violations. consider this my report. I can duplicate to a mailing list or issue tracker etc. if need be <munksgaard>Do I need to specify that all the other dependencies should also be built with ghc-8.8? <civodul>maximed: i've joined #glibc on oftc to see what they think <raghavgururajan>What is the difference between having alsa-service-type (which defaults to pulseaudio) or pulseaudio-service-type or both? <leoprikler>pulseaudio-service-type does your pulseaudio settings which atm defaults to disabling flat-volumes like any sane distro <mbakke>yay, gcc and guile-final built reproducibly on core-updates, on different hardware, at different moon phases <raghavgururajan>leoprikler: I see. I only have alsa-s-t and I am able to control audio with pavucontrol. <mbakke>except guile debug output, but that's okay <civodul>interesting that guile:debug differs <nckx>sbp: Meanwhile, I've installed Docker but… I don't know how to run it 😃 <nckx>It seems to be just a daemon. ***lukedashjr is now known as luke-jr
<dstolfa>then you can just do `docker ...` and have things work as expected <nckx>Great, I installed the wrong thing. Does it need the daemon running? <dstolfa>a daemon service, any user that wants to use docker in the group for it (part of system config) and then docker-cli per user profile if they wish to use its cli <nckx>Well that's not happening. If I sounded like I was defending Docker I certainly wasn't. It is not going to run a daemon on my box. <nckx>So the keyword I'm looking for is ‘registry’, correct? <nckx>The thing that would most likely violate FSDG by nudging users towards non-free software. <nckx>In the package itself, ignoring home pages for now. <dstolfa>ah, i'm not really sure. i don't use any of that, i use custom docker containers as a part of a build system only <vagrantc>it seems with guile-3.0 srfi.scm embeds the build path and something else that is non-deterministic, at least looking at the reproducible builds logs on debian <vagrantc>i know the build path wouldn't affect guix ... *nckx uninstalls docker and will never speak of this again. <dstolfa>nckx: yeah, i'm not a fan of docker but i don't get to choose here :P <vagrantc>mbakke: do you have some diffoscope output for guile:debug differences? <nckx>dstolfa: What's the FSDG way to deal with home pages? Please don't say it's to mirror and censor a copy. <nckx>Because I'd be less surprised than I want to be. <dstolfa>nckx: i haven't got a clue honestly. <dstolfa>might be worth asking on the gnu maintainer list? <nckx>If I want a magic 8 ball that will eat my face I'll buy one on Alibaba. <dstolfa>nckx: i imagine it's not too big of an issue, if linking to github is fine, then why is linking to docker not fine? <nckx>That has always been my (personal) view on the matter. <dstolfa>IMO, it doesn't matter if the software's home page recommends non-free things. what matters is that whatever you get to use as an end-product in guix doesn't by default advertise anything as that program <nckx>‘The internet is scary and trying to contain it is folly.’ <dstolfa>otherwise you may as well just remove 90% of the software <PotentialUser-40>irfus: thanks for the patch, I will try to build it tonight (I really need to log on here proper, was just browsing the log and saw your message) <dstolfa>nckx: we should remove gnome.org too then <munksgaard>So is the #:haskell argument to haskell-build-system just totally useless? I want to build the versions package using ghc-8.8, but it requires some other packages already in the guix system (ghc-megaparsec and others), and they're reported as missing dependencies when specifying ghc-8.8. I'm guessing it's because those packages were built with ghc-8.6. Do I need to manually import every single dependency and specify that they should use 8.8? <dstolfa>gnome.org lists digitalocean, aws, google and a few others on their home page. is that now a probleme too? <dstolfa>it also has twitter, facebook, linkedin, youtube, etc on its home page <nckx>FWIW I agree it makes no sense dstolfa, but I'm not aware of anyone seriously suggesting we audit the Web. (I'm sure these people *exist*, but we don't retain their counsel.) <nckx>I was just curious but I didn't mean to imply we should seriously consider that. <dstolfa>sbp: yeah, that's different from linking to free software and providing a web page that is the home page of that free software <sbp>if Firefox cannot be packaged for Guix because it links to "Mozilla’s add-on catalog, which contains non-free software", then I don't see why the Guix manual can link to the Docker homepage or the Singularity homepage <nckx>Yes, it is a matter of (literal) degrees of separation. <dstolfa>it's free software and that's the end of it <sbp>the Guix manual *links to docker.com directly* <nckx>But Guix ‘links’ to docker.com. <sbp>and the Singularity homepage too <dstolfa>sbp: almost every FSDG distro links to gnome.org which links to google, aws and DO <dstolfa>and i'm sure there are plenty of others <nckx>So the only safe site to link to is gnu.org. <sbp>I suspect it's down to degrees of separation as nckx says <nckx>Oh, wait, that links to mailing list archives full of references to non-free software (I'm sure). <sbp>but then again, why is linking to Mozilla's add-on catalog different to the Docker homepage? heh. I don't really understand <pineapples>dstolfa, nckx: Hello! Also, nckx: „Hinapples” :D <sbp>I understand that a line must be drawn somewhere <sbp>I don't understand how the lines differ in these two cases <nckx>sbp: Because it's literally a one-click installer for non-free software. <PotentialUser-40>irfus: I also have a live USB now for booting directly a computer which would benefit from newer Mesa, so that will be a good test all together <dstolfa>the mozilla store just shows software, free or non-free <dstolfa>this makes it very, very easy to install non-free software without knowing it <nckx>I'm not saying there's a firm line, but there is quite a bit of distance between that and project home pages. <nckx>I'd need to think about it more to write a thought-out response, but not linking to home pages feels wrong to me. Towards our users. <PotentialUser-40>munksgaard: I've found the haskell system to be a bit messy, lots of older packages, and so need to update a lot of them together. there's also a patch to update haskell-build-system to handle nontrivial configures <nckx>Something not right about that. <sbp>nckx: two clicks by my count. if you go to the Firefox addon store, you have to click twice before you've downloaded non-free software. it's the same number of clicks on the Docker homepage to do the same <sbp>which means by your own metric it's exactly the same <civodul>nckx: seconded; i mean, Docker is free software, it can and is being used to run free software <nckx>I'm going to stop you right there, this language isn't doing it for me sbp. <sbp>civodul: sure, but the Docker homepage has the enterprise version available <sbp>if it were a link to the Docker CE specifically, that'd avoid the link to download the non-free software <nckx>Don't (incorrectly) quote my supposed words at me like some imaginary checkmate. <munksgaard>PotentialUser-40: Yeah, that's seems close to my experience. Any idea how to help improve the situation? <sbp>I'm just trying to understand <civodul>ah well, sure, the project doesn't endorse that, but we're not going to give up on <a href="..."> <dstolfa>again, how is this any different to linking to gnome.org? <dstolfa>it's 1 click to get to non-free software on gnome.org <sbp>civodul: sure, but it's the specific reason you gave for why Firefox couldn't be packaged for Guix <dstolfa>that doesn't mean it's the same thing as a literal addon store that installs it on your computer instantly <sbp>if you're not going to give up on <a href="..."> for the Guix manual, why does Firefox have to give it up to be packaged for Guix? <PotentialUser-40>munksgaard: I'd like that patch to be merged, as that is stopping some updates I think. I have a handful of updated haskell packages that go together too, that I needed to try to build something. it is tedious but easy to go through and update them as you need, but it would be good to get everything to current versions <civodul>sbp: the two are very different, as has been explained multiple times above <civodul>i don't think we need to reask the same questions over and over <PotentialUser-40>munksgaard: so I guess submitting patches with updated versions, inevitably something will break because of newer version, fix that, rinse and repeat? <nckx>sbp: OK, sorry then. It's just that discussions like this one polarise very quickly, because it's an apex of politics and bikeshedding, and positions quickly ossify and people dig in their heels and the public nature of the ‘debate’ does no favours. I've been there before. <mbakke>vagrantc: I do, it's 700KiB. I can send it as a bug report. <sbp>nckx: understood. I don't have a stance on the issue, I'm just trying to understand. I'm using non-free software to write these words to you. I'm not a member of the FSF. I truly only want to understand the problem <sbp>the wider context is that I'm trying to understand how I feel about Guix in general, as software, as a community, as many other things, and what my potential contributions could be <PotentialUser-40>munksgaard: noted from bug report on something failing with needing cabal-doctest in configure. some packages were working around that, but I think this would help not need custom build defintions <munksgaard>PotentialUser-40: Ah yes! Yeah, that's actually my bug report, but I hadn't seen that patch. <vagrantc>mbakke: i'd be curious to see how it compares to the debian one... <nckx>Sorry for not assuming best faith, sbp. The ‘by your own logic’ phrase brought to mind people who want to force an open conversation into a final logic!™ endgame, where some conclusion is Obviously Correct and the matter is Settled. That will *never* happen here. It's a flipping FSDG Zen koan. <PotentialUser-40>munksgaard: it is my patch : ) (I really need to log in via my matrix server) <munksgaard>Thanks for the work on the patch, it works perfectly for me as well. Now I just run into other problems... <sbp>nckx: as some further context, a lot of my thoughts about Guix are situated around usability and intended audience. I've spoken to the Systemcrafter folk about this (not sure if you're aware of them), but I think I ran into the same problem <nckx>civodul: In fairness, these aren't the same people asking the same questions. These are intelligent people asking rather intelligent questions for the(ir) first time. Where is the FAQ they should have read? The log we can point them to? *nckx is just asking questions! <sbp>that a lot of what I'm thinking about, though I feel like I'm coming at it from a very neutral point of view and with very little baggage, immediately gets caught up in preconceived notions of politics and other things that people have going on <PotentialUser-40>munksgaard: welcome! I too ran into difficulties later, but in the actual haskell packages (I'm still pretty new to Haskell, was trying to get taffybar working) <dstolfa>sbp: i think the reason i assumed you were acting in somewhat bad faith was with the wording used around "consider this my report, i can duplicate it on...". to me that just sounded as if you're about to go to the FSF and complain about guix if it didn't immediately get corrected <sbp>not at all. actually the opposite: I was offering to do extra work if it was required by the Guix community or its guidelines. sometimes I report a bug somewhere and people say "this is the wrong place, please submit to [ELSEWHERE] instead". I wanted to make clear I could do that if necessary, that I was not expecting somebody else to do the work for me <sbp>if I reported it to the FSF, the first thing they'd do it report it to you ;) <sbp>but I sorta considered FSF/GNU/Guix to be all quite tightly integrated so I don't even consider it really different. I don't know how the organisation works here, that's just my shallow understanding so far <civodul>nckx: right! though i seemed to read the same argument multiple times <nckx>There's something particularly noxious about people walking into a community to present their genious ideas that of course nobody in the community can ever have discussed to death before, and why-don't-you-just. You didn't do that, but unfortunately enough have in the past that we're easily triggered. <sbp>heh, I certainly don't have any genius ideas <nckx>…and you are underestimating the internal politics of GNU by several orders of magnitude 😉 <sbp>if I were going to contribute, I'd like to contribute in ways that people like. there are lots of things that I've been thinking about. contributing build servers, helping to answer comments in here, going through the issues list and finding ones that it looks like I can solve, packaging software <sbp>some of these I've been doing already <sbp>none of these involve genius ideas, sadly ;) <PotentialUser-40>...in unrelated news, I'd like to say as a newbie that building a bootable live USB from a system config scheme file was fun and easy. and worked! <PotentialUser-40>and that was after hacking the install script a little to move /gnu/store (with a mount --bind) due to low space on my root partition. I swear, I'm never partiioning root separate again, it always needs more than I expect <nckx>sbp: Geniuses are overrated and overblown. Then I'd rather have you. <na2th>PotentialUser-40: I came here a couple of days ago and people told me the best way to build my own package was to clone guix. I thought that was kinda crazy; now I have even sent a patch! <sbp>every project can have one; so at least you can keep civodul <na2th>nckx: well, I bumped evince, it was not too much, but I am sure proud of it <nckx>There's a lot of rather tedious set-up and reading implicit in that, na2th, so that's still impressive. <PotentialUser-40>I think we could use some more tutorials out there, I think I'll write one on the easy "build your own system on a USB stick" with Guix <na2th>nckx: I think both academia and software engineer suffer too much from the "myth of the genius" <nckx>There's a ‘cookbook’ in the repository that is perfect for that, PotentialUser-40. <dstolfa>na2th: academia moreso than the general industry <nckx>It's the Guix reaction to having a Wiki whilst not wanting a Wiki. <dstolfa>it's really bad in certain academic places <PotentialUser-40>nckx ah good idea! all the pieces are in the manual or cookbook, but a step by step guide would be good to add. I'll get on it <nckx>‘Tech’ (a loathsome word) is infected with the same. <raghavgururajan>Is it safe to add this line "source /run/current-system/profile/etc/profile.d/nix.sh" manually to /etc/profile in Guix System? <dstolfa>academia sometimes also has this tendency to focus too much on critique and bringing people's work down rather than embracing the good parts. seen this too often at conferences <na2th>dstolfa: I actually think this even hurts the "geniuses", as it makes everyone live under this imposter syndrome situation <nckx>raghavgururajan: I don't think changes /etc/profile are safe from the activation scripts. civodul might know off the top of their head; I don't. <PotentialUser-40>good talking to you all, appreciate the questions asked and answered as I've been learning. i'll come back later with a proper name (potentialuser --> user) <nckx>PotentialUser-40: Looking forward to it. <na2th>nckx: I think that 'Tech' was the word I was looking for when I said "software egineering" <na2th>nckx: but what is up with the Wiki? Why are people against it? <na2th>not that I think that the cookbook is a bad solution, but I never thought about it <vagrantc>don't worry, the dunning-kruger effect helps mitigate the imposter syndrome! <na2th>vagrantc: there must be a name for the effect in which you are aware of both imposter syndrome and dunning-kruger, so you keep oscilating on how you think about yourself <nckx>na2th: I think people underestimate the level of effort, both authorial and janitorial, required to keep a wiki from being more useful than dangerous. <na2th>"Hm, I felt quite smart today. I must be stupid. Well, now I feel smarter" <dstolfa>i would call that the academic equilibrium <Kitty[m]>na2th: I am unfamiliar situation but this is probably the best "wiki" and website I've seen for a gnu/fsf styled project lol <nckx>It's not a guarantee (and the quip is in danger of becoming cliched and further losing its effect), but if you're the kind of person who even pauses to worry about Dunning-Kruger… you're probably not the problem. <civodul>raghavgururajan: the contents of /etc/profile cannot be extended from nix-service-type i believe; is that what you had in mind? <nckx>Oh, I thought they literally meant sudo emacsing the thing. <na2th>nckx: I can see how the wiki is hard-work, but what makes the cookbook easier? Is it that you must commit/send patch to update? <na2th>dstolfa and vagrantc: "The Academic equilibrium, also known as effective dunning-kruger imposter, ..." <nckx>Submit to a few pay-to-play journals and get published. <dstolfa>you don't need to do that, you can just publish a tech report <vagrantc>hah. finally got my solar hooked up so building linux-libre on the pinebook-pro feels like using power that would otherwise go to waste again :) <nckx>Is that the same as a white paper? I can never keep track. <dstolfa>nckx: it's the equivalent of posting to an academic blog more or less, but has to be formatted neatly <nckx>na2th: the (extremely simplified) reasoning could go something like: if we're going to have a wiki, we don't want low-quality submissions, so we'll have editors & reviewers anyway, so then the only difference between the wiki and the rest of Guix is the Web UI, so why not use the workflow we use for everything else anyway. <na2th>Can we exploit how guix hash packages to create a "refactor only" patch? <nckx>There's this ‘if you host a Wiki they will come’ view, which, who knows, might be true, but the fact that we're hardly inundated with submissions makes me sceptical. Review is the bottleneck for code patches, but we get barely any documentation patches as is. <na2th>When I looking around gnome.scm to patch evince I noticed that there is a common task of removing font-config; so I thought that I could create some auxiliary functions for that, or similar things <nckx>I don't think open-access publishing would cause that dam to burst. <na2th>perhaps something that becomes a "gnome build system" eventually <na2th>but I thought that this could only make sense if I changed many packages in a roll <na2th>which sucks, as it is extremely hard to check if I have broke something <nckx>The glib-or-gtk-build-system is kind of the GNOME build system. <viivien>Hello, what package has the "htpasswd" command? <nckx>viivien: Apache (httpd). <na2th>So I thought about leveraging the hashs that guix produces to see if I can refactor the scheme code without changing the packages <na2th>this would both help me develop, and I could also send as part of my patch to show that I am not breaking anything new <na2th>nckx: hm, I see what you mean; I will take a deeper look in that build system anyway <nckx>I'm not sure what you mean by ‘removing font-config’, but it's hard to modify the build part of packages in any way that's not purely cosmetic without changing the hash. <na2th>nckx: (regarding the wiki) that does make a lot of sense <na2th>nckx: I wrote in the worst possible manner; lemme rephrase <na2th>many gnome packages require a modify-phases that skips gtk update icon cache <na2th>I noticed because my build crash because of it, and it was actually easy to fix because I just had to look around other packages <na2th>nckx: but it is something "comsetic"; it is a scheme refactor with the aim of simplifying the code and not changing the packages themselves <nckx>PotentialUser-71: Welcome! Do you mean running Guix System under Xen? (If that even makes sense, Xen in my mind is a KVM alternative but maybe I'm wrong.) I ask because it's quite possible nobody's tried, and it might be quicker to try than to wait for a reliable answer. <nckx>na2th: Sorry to be dense, but what would this purely cosmetic refactoring look like? Guix (by design, for reliability) doesn't do clever things with the quoted build code before hashing it. Cosmetic differences like changing a variable name or swapping two idempotent things or the order of inputs (I think) will still change it. *nckx has to AFK, BBL TTYL. <PotentialUser-71>nckx: Hello, the concept of Xen is different from the concept of KVM, in my case I want to use this to safely isolate each of my operating systems from each other, designed for different applications. I am an active user of Qubes OS, and I wanted to organize at least a little similar mechanism on GNU Guix, most of it is clear to me, but I don't kno <PotentialUser-71>w how much it will work and be supported on Guix, for example, I don't even know how to isolate the drivers, but I hope that sooner or later my hands will reach this. <helaoban>is there a way to be dropped directly into a shell with 'guix system container'? <PotentialUser-71>I'm interested in compatibility with Xen, because I've heard that there seems to be an analog of Xen in Guix, perhaps it will work better, but I don't remember the name <helaoban>my understanding is that you have to separately run 'guix container exec <container-pid> <some-shell>' after having started the container <helaoban>unlike 'guix environment --container ' where you are dropped in directly. <zap>PotentialUser-71: From what I know about Xen (I dont know much) it hypervisor living on hardware. And you have "domanis" in xen jargon as vm. You can basically have guix system domain running on xen <nckx>PotentialUser-71: As you can tell I'm completely unfamiliar with Xen and can't answer those questions. I hope someone can. You should also send a mail to help-guix at gnu.org to reach a wider audience, but keep in mind that the number of people familiar with everything that you want to combine might be tiny or zero. You'd be treading interesting new ground if so. <na2th>nckx: I did not have something specific in mind, to be honest. I was thinking about trying to develop some helper functions for some things that come up in many places throughout the gnome.scm *nckx really AFK now buds. <zap>PotentialUser-71: "there seems to be an analog of Xen in Guix" there is guix container (that uses linux namespaces for isolation) and "guix system vm" that spawns vm from with your configuration. "guix system vm" uses KVM/qemu for virtualization. If you want to have desktop experience where some or all your programs run in isolation It will require configuration. <zap>is crosscompilation a first class feature in guix? <zap>meaning should I expect things to be built when passing --target to guix? for things like armv7l-unknown-linux-gnueabihf <zap>I gave up building on my arm board and trying to crosscompile packages and copy them 