<amz3>I changed the package for guile-bytestructures, managed to install it in my profile, ran the download.scm program from gnunet-guile2 and... it works!! <zero21>racket, specificly drracket package is broken, open file, save file commands close drracket for no reason and those are crucial. <clacke[m]>roptat: I think guix pull did reuse builds at some point, but later it stopped working. Or maybe its simply that guix.git is moving too fast so the next pull is always different <buenouanq>Anyone here in control of the blog or should I send emails? <buenouanq>some notes/edits need to be added to the BeagleBoneBlack post <buenouanq>namely: a reminder that you need at least a 3GB swap, that the eMMC isn't big enough to compile the image so you have to put /gnu/ under it"s own larger partition, and that just guix pull will take around 3 days <buenouanq>I'm currently timing the actual build and if all goes well will let you know how long that takes too. ***Guest1900 is now known as sturm
***sturm is now known as Guest31815
<Guest31815>Does GuixSD have a system equivalent of "guix package --delete-generations=1m"? I assume that "guix gc" won't reclaim space from past system generations unless I do something like this. <buenouanq>happy_gnu[m]: looks like the ARM Cortex-A8 only has one <buenouanq>failed again this time becasue /tmp/ ran out of space (;-___-) <Digit>ACTION decides to search for, and finds, lush, in hopes of trying to make his shell be lispian, in hopes of increasing familiarity, fluency, with lisps, to make guixsd a stronger viable reality for himself <Digit>do any of you guix daily users have your shell be one of the lispy/schemey/guiley(?) shells? i'm seeing there are quite a few, in various ways of lisp involvement. can you recommend any for conferring transferably useful lispy learning and reasonably pleasant shell use? <Digit>i'm imagining something that'd have me doing a lot more parens, n a lot less familiar shell'ness... something closer to (if i have my terminology correct) a repl. but then, i'm not so familiar with eshell, in how much lisp you can throw into it and have it understand. <Digit>ACTION realises, as he types into this erc buffer, with his eshell buffer above, maybe indeed he does not need look further, and just use the tools under his fingertips more actively intently on lisp learning <mubarak>happy_gnu[m]: what about browsing the internet? do you use emacs also? and if so, is there are any emacs plugins you use for browsing? <clacke[m]>happy_gnu: cores are irrelevant when 99% of the time is paging to disk. <clacke[m]>I guess you missed the preceding conversation <clacke[m]>buenouanq is trying to use guix on the BeagleBone Black, and the problem is that it has 0.5 GB of RAM while 'guix pull' eats 2-3 GB of VM, so on that platform the pull takes three days. <buenouanq>it only has 4GB on the eMMC, so you have to give it larger partitions for /gnu/ and /tmp/ <clacke[m]>but I guess we will know the facts when your 'time guix pull' comes back <clacke[m]>ah, you mean, yes, the pull taking time is not the only issue <buenouanq>any other dirs guix uses to build a disk image that's going to cause this to fail again? <clacke[m]>it also neess enough filesystem disk space of course <buenouanq>failed first when it was doing something in /gnu/ and ran out of space <buenouanq>failed this time when it was doing something in /tmp/ and ran out of space <clacke[m]>btw, of general interest, I have been very successful in putting /nix and /gnu on the same ZFS with online dedup <mubarak>happy_gnu[m]: that is great!. I have switched firefox "search engine" to duckduckgo for almost 6 months. I will try searx and eww. <buenouanq>what will the filesystem declaration look like if I want to put these on their own partition? <clacke[m]>8 GBs should be enough for anything. Quote me on that. <buenouanq>I haven't had to get fancy with stuff like this yet. <clacke[m]>I had trouble getting it to work on Ubuntu, I wouldn't imagine it easy on Guix. <buenouanq>but it should just be a normal mount label to /gnu/ yeah? <clacke[m]>I had to use /etc/rc.local to get things done in the right order. <buenouanq>I'm worried about boot order, like it will need something in /gnu/ to be able to mount it, but it's not mounted etc <clacke[m]>I probably don't understand ZFS enough, I guess two roots could share the same object backend? Whatever the terms for these are. <clacke[m]>Instead of learning ZFS, I put them both in /guix_nix and then bind mounted /guix_nix/gnu to /gnu and so on <clacke[m]>oh yeah, the boot order was a thing too, I had to make my s6.service (which runs guix-daemon and nix-daemon) depends on rc-local.service. <happy_gnu[m]>mubarak: I was very concerned with duckduckgo and yahoo and iirc amazon too <clacke[m]>So on GuixSD you probably need a ZFS root I guess. <happy_gnu[m]>Is it possible to get guix packages on a different computer and then just land them on the beaglebone black <buenouanq>happy_gnu[m]: hopefully some day, there's something weird about cross compiling architectures right now that prevents it <clacke[m]>first off would be to get guixsd to do zfs at all <buenouanq>if 8GB is for sure, what is the smallest I could get away with probably? <clacke[m]>I think we should expect the guixsd initramfs to be able to handle a separate /gnu <clacke[m]>You could try 4 GB for tmp, maybe someone else knows better <mubarak>yesterday I was trying to connect my laptop with Mobile hotspot(in Android phone) using wpa_supplicant. After reading wpa_supplicant(8) manual page and --help many time and nothing work. So I come back after two hours and I read wpa_supplicant(8) again and wpa_supplicant.conf(5) also. I found that in wpa_supplicant.conf(5) there is new line should be placed after ssid=AndroidAP(the hotspot name) which is "scan_ssid=1". I write it in /etc/wpa_supplicant.conf <mubarak> and it worked. It even worked in my brain before trying it, because if we thank about it we need to scan the area for a wifi with the same name as in ssid, and then pass the password to it and after discover the hotspot to connect to it. <mubarak>The configuration will be like this: <clacke[m]>I think tmp needs to hold one (as you have one core) build, that's it <clacke[m]>and the horrible things like libreoffice or firefox take more than 1 GB for sure <mubarak>Thank you clacke[m] and efraim for the help yesterday <happy_gnu[m]>I never use android like that because mobile internet is too expensive :/ <clacke[m]>I wonder in what situation it would not be required to scan for the ssid <mubarak>clacke[m]: I got it from guix reference manual <CharlieBrown>Dumb question, but... How do I update all my software in Guix? I haven't touched the package manager in months. <roptat>guix pull (equivalent to apt update), then guix package -u <roptat>as every user you want to update packages of <buenouanq>does --fallback take longer? does it result in the exact same thing? <civodul>buenouanq: --fallback changes the behavior in case a substitute could not be fetched, typically due to a server-side issue <buenouanq>so without --fallback it downloads binaries if they exist, so with it is probably much slower <buenouanq>but what is built can be assumed to be the same, yes? <buenouanq>didn't know about guix weather until now, that's neat <civodul>buenouanq: nope, --fallback doesn't make any difference, unless there's something wrong with the substitute servers or your network connection <civodul>and yes, the whole idea of substitutes (and reproducible builds) is that if you build things locally you get the same result as if you downloaded the pre-built things <civodul>ACTION .oO ( what does it mean for a build log to be nice? ) <civodul>CharlieBrown: it looks like hydra.gnu.org is overloaded, hence the failure, i'll take a look <civodul>in the meantime, you can try --fallback as the message suggests <civodul>it should be back up now (modulo caching of 504 responses) <mubarak>happy_gnu[m]: I'm sorry for a late reply, I got phone call and got away for a hour and it take me a more than hour to write and my answer. and I'm sorry guix! its a long reply, i have tried to make it shorter. So here it it: <mubarak>happy_gnu[m]: here in my country all types of network are very expensive, the only a fordable devices with good speed(by good I mean between 45 kb to 300 kp as a max speed) was usb modems(like Huawei E303). We had back then Unlimited bandwidth daily or monthly; now we are forced to subscribe for limited packages(250 MB, 1 GB, 5 GB). <mubarak>The reason I used a Android phone as a Wifi device is that I really want to install GuixSD and I don't have any wire or wireless devices, only usb modems(mostly Huawei) and networkmanager, modemmanager and usb_modeswitch(is not even in guix packages) does not come in offical .iso image also wvdail is not available as alternative. So I tried Remastering guix .iso like I did to Parabola GNU/Linux-libre desktop live-image(by remastering I mean extracting the i <mubarak>so to dir and chroot to that dir and install networkmanager, modemmanager and usb_modeswitch and exit chroot and create a custom iso and all that work just so I can connect to the internet to install a distro i want), but it didn't work I think becuse chroot expect all programs(like bash) to be in /usr/bin/bash and in guixsd iso bash in the /gnu/store/...., I even mkdir /usr/bin and created as symbolic link to bash from the store and it still compliane /usr <mubarak>/bin/bash is not exist. I even thought of using guix-binary as stage to install guixsd just like gentoo, I didn't and I haven't even tried because you need all the essential tools like binutills, glibc, gcc, ... etc to install a distribution and guix-binary is not ment for that. I also thought if I choosed bare-bone.scm as config.scm and istall a minimal guixsd and then I use another live-image distro to connect to the internet and mount sda1,sdb3 to /mnt a <mubarak>nd chroot to /mnt and install bare-bone.scm to desktop.scm and install xfce and all the packages I need. unforsuntlly i couldn't install guixsd-install 0.14 as they say in the guix refrence manual, the installation require internet access and I don't have any. Last week while I was watching TV i got idea "What if i used a Android device as a Wifi? could it work?" so I closed the tv and and login to my laptop and started to read more about the available pack <mubarak>age that come with guixsd .iso and here I'm, finally I was able to connect to the internet. <mubarak>I'm not going to use this phone as a wifi device. Only now for installation, when I install GuixSD i will also install networkmanager and modemmanager. I still have one problem left, which is usb_modeswitch is not available in guix/packages repository. So I will try to define it in scheme and compile and see if i can do it. <mubarak>You know what they say, If you love it you fight for it. :p <mubarak>Thank you all (GNU & GuixSD) developers and contributers, great work! <buenouanq>CharlieBrown: this is why I was asking about --fallback above <buenouanq>I always get errors on any pull or update it seems - I basically just always use it now by default. <efraim>mubarak: if you're super worried about data usage and have enough processing power then it _might_ be less bandwidth overall to build everything from source since we don't have delta upgrades <mubarak>efraim: its not about data usage. As i only have usb modem as only option to connect to the internet. networkmanager, modemmanager and usb_modeswitch is not in guixsd 0.14 iso, so I can't connect to the internet so I can install guixsd <mubarak>in guix wire and wireless network is the only way to install guix <mubarak>yes I know about guix-binary, but i want to install guixsd itself <mubarak>efraim: all the above talk, is a reply to happy_gnu[m], he asked me why i use android phone as a wifi becuse mobile network are expensive <mubarak>If I have wireless device or wire device or if there a guixsd-desktop .iso with network-manager, modemmanager, usb_modeswitch or wvdial added to it, I would't do all these things <mubarak>at the end, no problem :) . there is alway many ways to do one thing. <mubarak>efraim: is there a document to wiki for building guixsd from source. I have a normal laptop(toshiba, RAM: 2GB, CPU: Intel(R) Pentium(R) CPU B960 @ 2.20GHz). But it worth to know how <efraim>guix itself isn't a lot of fun to bootstrap from source, using guix to build a guixsd image isn't too hard, the makefile in the repo has a couple of disk-images that are built for releases and changing them is the same as changing the os-config file <mubarak>efraim: you mean using guix-binary in foreign distro to build guixsd image? <mubarak>that is great, I will read "Invoking guix package" again and continue from there until i get the whole picture and try it as soon as finish reading that part of the manual. <mubarak> I will come back to you if there any information is not fully understood. <adfeno>Hi #guix! ;) I am a submitter of a bug/patch in guix-patches but the upstream of the package I'm working on (and their upstream also) don't seen to want to collaborate to get the package recipe in a maintainable state. Now, due to personal lack of time I want to consider the bug/patch as dormant. How do I tell this with Debbugs? <adfeno>Note: I know how to use the control server, I just want to know what's the best command to signal that. <rekado>adfeno: you can just send an email as a reply to inform people that you abandon the patch. <adfeno>rekado: Do you think it's a good idea to archive the bug/patch? (so that the load on the email server is freed a little) <civodul>ACTION plays with qemu + binfmt_misc <zero21>racket, specificly drracket package is broken, open file, save file commands close drracket for no reason. <civodul>amz3: i know proot but that's not what i'm after here :-) <civodul>i've felt the need to do something about it and i can't stop <amz3>my understanding is that we proot, we could spawn a container for another architecture <rekado>amz3: I don’t see how that would work. proot only intercepts syscalls. <amz3>civodul: fwiw, i updated guile-bytestructures to 1.0.1, guix depends on guile-git which depends on guile-bytestructures <amz3>i sent a patch, I am wondering if it requires to go to core-updates <efraim>civodul: have you tried making qemu static binaries? The debian way is to debootstrap into a directory, copy qemu-static-$arch to directory/bin/sh and chroot to directory <efraim>I was thinking of static qemu linux-user binaries to solve the GHC issue, to cross build from x86_64 to aarch64, but from aarch64 <boegel>so, I'm very new to Guix, and started playing around with <boegel>after installing it from scratch, I ran "guix package -i fftw" to install FFTW with Guix, but that took several hours building stuff before it got stuck in some kind of lock tests... <efraim>Oh, I should submit a patch against nix/libstore/build.cc, "I am a 'aarch64..." is gramatically incorrect <boegel>isn't Guix supposed to pull in binary packages matching my system (nothing special, x86_64, CentOS7) <efraim>boegel: did you enable the substitute servers? <rekado>boegel: if you installed it from scratch you may need to authorize the substitute server keys first. <rekado>otherwise it won’t accept pre-built binaries. <boegel>ah, yes, I overlooked this bit it seems: guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <m-o>boegel: did you run step 7: "guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub <rekado>arguably, there are too many steps <boegel>yeah, there should be a script for this, really, it's pretty complex for someone new to Guix <boegel>I'll have to deduct points for this in my comparison :P <rekado>Someone did work on a pretty script, but I don’t know the current status. <civodul>let's add this script that we've been talking about forever :-) <boegel>this comparison thing is becoming really interesting, but I'm not sure how I'll squeeze this in 20 min. <boegel>civodul: well, it's the 1st talk, so plenty of time for Q&A! :P <efraim>gtk+@3 built fine on aarch64 on core-updates <boegel>someone else could of course sacrifice their talk slot for the greater good <bavier>boegel: just fyi, there is a patch on the core-updates branch that disables those lock tests in a bunch of packages <bavier>but you shouldn't hit that problem again if you got substitutes working <boegel>bavier: ok, not seeing it anymore now I'm just pulling in binaries <lapinpin>Hi, it's posible to change the store path for a guix pack? <amz3>lapinpin: it's tarball,, you can copy it anywhere <lapinpin>Yep i know, but you have to unpack on / or chroot. I juste want to export PATH CINCLUDE etc... <rekado>lapinpin: the binaries contain references to /gnu <rekado>you’d have to rewrite all of these references. <rekado>so, yes, it *is* possible, but it’s not easy. <boegel>is there a way to force recompilation of a package even though a binary package is available for it? <rekado>boegel: you can run ‘guix build --no-grafts --check foo’ to build ‘foo’ from source (and ignore grafts) and compare it with the binary that is already available locally. <rekado>we use this to build a package more than once to detect reproducibility problems. <rekado>(add -K to keep the build output even if the output differs) <lapinpin>Ok i will try to do it. If i understand, i have to redo the path of all link and change the /gnu/store to myvalue in the binaries ? <rekado>lapinpin: this may not work properly in all cases. <rekado>lapinpin: what is your goal here? <lapinpin>To create a package that i just need to extract and use export to use the tool. <lapinpin>Something like a home .guix_profile but can be use on a computer without guix <bavier>lapinpin: davexunit explored an idea like that a while back; I don't recall that it worked out <lapinpin>I create a tar, i move it to a other computer, i untar , i export and the tool are available <lapinpin>Do you think this kind of option can be useful or i totally go to the wrong direction ? <shiranaihito>does this kind of stuff matter: "warning: collision encountered"? <amz3>lapinpin: that's the purpose of guix pack, that said, you need to create the symlink to the binaries in the store yourself. <amz3>lapinpin: you can use the content of the pack as a normal user in another system without installing guix <shiranaihito>is the system config given to "guix system reconfigure" meant to contain everything that's supposed to be installed? for example, maybe i could have postgresql and nginx in a separate system config file <shiranaihito>there's some trouble with the configs for psql and nginx, and it seems maybe their guix modules have learned new things - at least i don't remember "system reconfigure" warning about a certificate configured for nginx existing <lapinpin>Nop it's not possible to use all of them. because you have to unpack on / (need root) or unpack somewhere and the hard binaries link will fail <snape>shiranaihito: I think this is a bug with the nginx service, that has been solved <snape>it should definitely not talk about certificates being there or not <snape>shiranaihito: don't worry about collisions, they are normal <amz3>lapinpin: I forgot about that, you can use chroot to work around that issue <snape>it means two packages put their files in the same place, if my understanding is correct <amz3>lapinpin: chroot /path/to/binary /path/under/var/gnu/ <snape>but usually when it happens, it's not really a problem because the files are the same or it doesn't matter if they come from one package or another. <amz3>lapinpin: you put that in a shell program, put that shelll program somewhere in $PATH and then it will be transparent for the end user <snape>shiranaihito: 'guix system reconfigure' doesn't contain the user packages <snape>you might need to do "guix package -m manifest.scm" or "guix package -i <my-package>" to install packages as a user <snape>the ones you would want to install as a user <snape>like... VLC, Icecat, Emacs... <snape>oh right. Then indeed, you may not need use packages. <snape>and you can still install packages globaly with 'guix system reconfigure' <rekado>snape, shiranaihito collisions are not normal. <rekado>collisions usually indicate that you have a profile with packages that were installed with different versions of Guix. <snape>oh sorry then. I guess it depend which ones? <rekado>collisions happen when you have two packages that provide files with the very same names. <rekado>*some* of these collisions are expected <rekado>correction: could not open the paste with eww. <snape>it means nologin is provided by two packages, and ifconfig too <lapinpin>amz3: nop, chroot need root and even whit unshare you need -r option and you loose all your mount point <snape>it's not "normal" but it's not the end of the world <snape>shiranaihito: your second paste isn't helpful because you don't show the whole file <snape>yes, but it doesn't show which packages you use within the reconfigure <shiranaihito>sorry, i removed it.. i realized i probably shouldn't leave the passwords visible :p <snape>haha yes indeed, it's not a good idea. But anyway they shouldn't be in the config.scm file <davexunit>bavier: yeah making relocatable binaries without /gnu/store is not something that has worked for me <davexunit>what has worked is special casing particular builds to be relocatable, but this is of course not general purpose. <davexunit>I have used guix to generate binary tarballs of guile + sdl2 and had someone on an ubuntu machine run a little graphical demo successfully <davexunit>but I had to make variants of every single package I wanted to ship so that shared libraries and the guile binary made no references to /gnu/store <rekado>shiranaihito: that one conflict is due to the fact that the base packages include both inetutils and net-tools. <shiranaihito>rekado but i don't think i've imported those in the file.. ? <rekado>don’t worry about that conflict. <rekado>I’m just saying that *generally* conflicts are not a good sign. <shiranaihito>rekado well, should i remove "%base-packages" from that then? they're all implicitly included somewhere? <snape>shiranaihito: no you should keep it <snape>it's fine, the conflict is not a problem <rekado>shiranaihito: don’t remove %base-packages. You’ll probably need them. <shiranaihito>it's a bit strange if "%base-packages" should be included, but will result in conflicts :) <rekado>but you can filter %base-packages if you don’t like it. <shiranaihito>rekado but where else do the conflicting packages come from, besides base-packages? <snape>shiranaihito: the real problem is that two different packages (inetutils and net-tools) provide two different versions of ifconfig. If you really need one version rather than the other, then you could either install the one you want as a user, or filter %base-packages. If you don't use ifconfig (because you use 'ip', which is more powerful for example), then fine! Don't worry. Those two packages provide other tools that are needed <g_bor>I've just noticed something. <g_bor>I've listed the content of the patches directory, and saw that perl-module-pluggable-search.patch has executable permissions. It seems that it has been pushed with wrong permissions. <g_bor>Should I file a bug on that? <bavier>g_bor: indeed; would that be a problem in any way? <bavier>i.e. the permissions are indeed executable <mbakke>Did offloading break recently, or is it just me? <mbakke>I'm getting errors such as "guix offload: error: corrupt input while restoring archive from #<input: channel (open) e7c360>" from multiple offloading machines. <mbakke>This is with guix-daemon version 0.14.0-4.c04ffad on GuixSD. <mbakke>civodul: offloading is broken on my machine :/ <mbakke>"guix offload: error: corrupt input while restoring archive from #<input: channel (open) 2062680>" <civodul>mbakke: i've experienced that too on my laptop (though i don't use it much) <mbakke>civodul: I think so, I've used offloading on this machine for almost a year w/o problems. <civodul>did your previous system generation have offloading working fine? <rekado>FWIW offloading still works on berlin.guixsd.org, which has just been reconfigured yesterday night. <rekado>the machines to which work is offloaded, however, have not been reconfigured yet. <efraim>according to apt-file, cpuid.h is available in gcc for x86 and ia64, and in general in clang <mbakke>rekado: Did you restart the guix-daemon too? <rekado>mbakke: yes, the server was rebooted. <mbakke>Will try rolling back to make sure it's not something else. <civodul>mbakke: reverting 896fec476f728183b331cbb6e2afb891207b4205 seems to help (run "sudo -E ./pre-inst-env guix-daemon ...") <mbakke>civodul: afk atm, will test in 1-2 hours <civodul>take your time, the bug won't disappear overnight :-) <bavier>I have simple package that just needs to build a shared lib from a single source with gcc <bavier>but I get a "fatal error: linux/limits.h: No such file or directory" from gcc when building <bavier>do I need something more than just gcc in inputs? <bavier>gcc-toolchain might be better I guess <civodul>bavier: if you use gnu-build-system, everything is there <bavier>uff da, now there are circular module loading problems <civodul>now you probably shouldn't be using gcc-toolchain as an input, that's a bit weird <bavier>I thought gnu-build-system would be overkill for a single invocation of gcc <bavier>I have very little clue about Lua <g_bor>bavier: It is not likely to be a problem, that it is executable, but not very nice. I don't like files on my systems with more liberate permissions than necessary... <g_bor>Also it seems to be easy to fix. <bavier>right, I'll fix it in a few hours, I was the one who committed it