<geemili>I'm trying to run `guix pull`, but it can't find guile-git <geemili>Apparently, getting on the IRC is enough to fix it ;P <geemili>I hadn't exported the guile load path <sadiq[m]>Hi. I now always get " No space left on device" error on installing any package. my / partition has 7.0 GiB free. Where should I look for hints? <sadiq[m]>hm.. I get no space left error when downloading files via icecat too. But df -h / says I have 7.0 GiB available <sadiq[m]>hm.. df -i says 100% for /. So inode is full. ***Piece_Maker is now known as Acou_Bass
<sadiq[m]>hm.. I think it would be better to add mkfs.ext4 -T news (or something like that) in the installation manual, because the high amount of small files and symbolic links shouldn't fill in the inode space <sadiq[m]>news uses one inode every 4KiB, 1 inode every 8KiB would be enough I hope (rather than the default 1 inode every 16 KiB) <Apteryx>Can the builder exp of a build-system (such as trivial-build-system) be a gexp? (formed with ~$(...)?) <efraim>AFAIK not yet, but it might work if you import (guix? gexps) <sadiq[m]>Will guix 0.14 be released any time soon? I ran out of space and I need to do a fresh install <Apteryx>Why do we have to call (mkdir #$output) in gexps? isn't that directory created by default? If not, why? It's boring to see this everywhere. <efraim>if you're using the trivial build system then nothing is done by default <efraim>ng0_: i'm trying a test build-out of your mate-additions branch for fun, can't build atril since clisp doesn't currently build on aarch64 <Apteryx>efraim: I see. Maybe we could do one thing in the trivial-build-system (create the output dir)... Otherwise there's no point, unless I'm missing something? <efraim>i think the output dir is the minimum required for a "successful build" <efraim>maybe send it as an idea to guix-devel <rekado>sadiq[m]: have you tried garbage collection? <rekado>sadiq[m]: you can unlink all previous profile generations and then run “guix gc” <Apteryx>efraim: It doesn't seem to work, unless I'm doing something wrong. I'll send my example to guix-devel. <Apteryx>Possibly the compiler hook to lower the gexp into something tangible is missing as I'm seing stuff #<gexp-output out> in the builder.drv <Apteryx>I would expect an absolute path there instead. <efraim>starting with kernel 4.12(?) the kernel devs/ext4 devs have increased the default number inodes with a flag <Apteryx>Is it safe to attach a magit diff buffer as a patch? It's just for demonstration purpose. <efraim>i think those are the build logs, so it should probably be ok <efraim>clearing it also makes you re-get the substitutes available, which is good if you've cached a bad entry <sadiq[m]>efraim: I need to claim as much inodes I can. the cache contains around 1100 files <efraim>then yeah, i'd try clearing the cache <efraim>you could also mount the cache as a tmpfs <efraim>are you on guixsd or a foreign distro? <sadiq[m]>hm.. seems like guix gc isn't deleting many of the unused dirs. I see 11 directories the point to xxx-gnome-todo-3.26.1 <rekado>are they still referenced somewhere? are they installed to a profile? <janneke>rekado: just got round to watching your #bootstrapple ghm video <janneke>very good story and presentation, well done! <sadiq[m]>rekado: I did do many guix build gnome-todo, but may have installed only once/twice. How can I see if they are referenced somewhere? <rekado>sadiq[m]: you can also delete store items directly with “guix gc -d /gnu/store/the-thing” <sadiq[m]>rekado: if it is referenced by my profile (or some other packages), will it be deleted? <sadiq[m]>hm.. it says 'still alive'. can I poison it to death? <ng0_>efraim: atril depends somewhere on clisp? <sneek>ng0_, sirgazil says: regarding Guix website, have you tried building the wip-website-update branch? The "guix.scm" file was renamed to "build.scm". Maybe that change is related to the errors you're seeing? <sneek>ng0_, sirgazil says: FWIW, while working on the website update, I couldn't create an environment either, and had to install packages by hand. Also had to rename the "guix.scm" file to something else; otherwise, importing the guix package installed with guix would not work well. <sneek>ng0_, lfam says: No spoilers, please ;) <ng0>there are 3 grave issues with the whole bunch of mate packages. 1) I want to build mate-screensaver with the lockscreen. I need too debug how we can get it to not log you out forever. this should probably be optional, in other words not in 'mate' or added to a mate-service. 2) and 3) not grave issues, but requests I reported upstream. <ng0>2 and 3 is about caja and marco extensions/plugins. not a real issue, can certainly be worked out for anyone who has time to work on their code. <civodul>rekado: i've jused pushed an update of the 'cuirass' package, which fixes GIT_SSL_CAINFO handling (a problem that's currently preventing Cuirass from doing anything on berlin) <civodul>could you do a reconfigure of berlin, or do you want me to do that? <civodul>(also with the latest guix-maintenance.git) <rekado>civodul: did I not fix the GIT_SSL_CAINFO problem weeks ago? <rekado>or rather “worked around” that problem <rekado>I ran a reconfigure on berlin about one week ago, but I haven’t been able to check yet <rekado>I can’t access berlin right now, only through the serial console :-/ <rekado>IT must have changed the firewall rules again <rekado>here we go, running guix pull on berlin now <efraim>i feel like i'm missing something with my openssh-service, I have (service openssh-service-type) in my services list but the ports are all closed <efraim>also the time on the computer is right, but displayed wrong in xfce <ng0>In my opionin this is the right way to proceed on the screensaver issue: Add mate-desktop-service as a service (for some polkit things). Remove mate-screensaver from package 'mate'. Test if it no longer breaks when added as package to in screensaver service. <ng0>do we have notes somewhere on how to move the /gnu/store to another disk? I'll add one soon and wanted to just move the store to it <ng0>oh. nothing special. okay, thanks <rekado>this doesn’t retain hardlinks, though, does it? <ng0>it's the same as -dR --preserve=all <ng0>there's one option missing for links <ng0>-d is --no-dereference --preserve=links <ng0>efraim: are you testing towards GuixSD on armv8 with MATE or why are you interested in it? <efraim>I build everything on armv8, it has more RAM and better storage than my other machines <civodul>rekado: the code was mistaking $GIT_SSL_CAINFO for a directory, but it's a file <rekado>I asked IT to open SVN ports on the firewall; right now we can’t build the texlive stuff because that requires downloading from SVN. <roptat>hi, I was wondering whether there was a way to set the fqdn in guixsd's configuration file? <roptat>I'm using opensmtpd, and mails are being rejected because it uses "localhost" as its fqdn <roptat>I tried to look for "fqdn" or "fully qualified" in the manual, but there doesn't seem to be anything about it <roptat>one can change the fqdn used by opensmtpd by creating a file, but this file is "/gnu/store/...-opensmtpd-.../etc/mailname" on guix, it's read-only <roptat>so I could fix that by adding my fqdn in /etc/hosts, just after "127.0.0.1" and it works <roptat>now I wonder, will it survive a reboot? Is there a way to do that declaratively? <rekado>roptat: the operating-system configuration has a field “hosts-file” <rekado>where you can specify a hosts file to be used <Apteryx>Should I persist at using gexp inside a package definition? Or is this not ready for prime time yet? <sadiq[m]>is there a way to add an environment to my profile so that guix gc won't delete those packages? <amz3>civodul: basically, I have a debian stretch inside an lxc <amz3>I installed the binary 0.13 guix <amz3>I ran 'guix pull && guix package -u' <amz3>It asked to update environment with some stuff to make guile-git work <amz3>then when guix package -u was finished I tried to install guile@2.2.2 but that failed with an error I don't remember what <amz3>next time I will report the issue, it will be better engineering <civodul>sadiq[m]: you can add "packages" to your profile, but not "an environment" <civodul>that said, environments created by "guix environment" can be registered as GC roots <sadiq[m]>hm.. what should be the content of file in guix environment -r file ? <jonsger>how can I find out which formats are support in a command like "guix pack --format= .."? <jonsger>so something like "guix pack --format=?" <jonsger>civodul: I found it now. but something like "--format=?" would be very nice <civodul>sadiq[m]: "-r FILE" will just create FILE as a symlink <Apteryx>anyway to tell Emacs to ignore .go files when C-x C-f (find-file)? <Apteryx>Since ido is on by default, I think this variable should do the trick: ido-ignore-files <Apteryx>Luckily I don't develop in the Go language ;) <rekado>Apteryx: projectile-find-file ignores files that are not tracked <rekado>I have all projectile things bound to C-c p; projectile-find-file is C-c p f <rekado>I just put six new servers on the rack; will try to install them over the weekend <Apteryx>rekado: projectile doesn't seem preinstalled in Emacs, but this lead me to discover project-find-file, which is, and apparently does the same. <Apteryx>Indeed! Thanks for making this farm publicly available! It's the most reliable substitute server I've found so for; congrats! <Apteryx>for the M-x find-file fix, this is what I settled for for now: (add-to-list 'completion-ignored-extensions ".go"). Make ido great again! <Apteryx>install-file seems to fail because lacking the copy-file dependency... I would have thought that Guix would take care of this for me if I tell it that `install-file' is in (guix build utils) using the #:modules field (for the trivial-build-system) ? <Apteryx>Is my assumption that the builder's working directory is the root of whatever archive/SCM was given in the source? <Apteryx>otherwise how can access the store dir corresponding to my check'd out origin? <Apteryx>Ahh... I understand the cause of all my confusion now. As rekado told me earlier, the trivial-build-system does nothing. Maybe that's not what I should be using. <slim404>I need some help with my guix system config <slim404>so I have a french keyboard and a guix desktop system <slim404>my config.scm used to have a service configuration for slim display manager to use french keyboard <slim404> (slim-service #:startx (xorg-start-command #:configuration-file (xorg-configuration-file #:extra-config '("Option \\"XkbLayout\\" \\"fr\\"\\n")))) <slim404>this used to work, but lately I got an error : <slim404>guix system: error: service « xorg-server » fourni plus d'une fois <slim404>so I tried to (remove) slim-service from #desktop-services <slim404>(remove (lambda (service) (eq? (service-kind service) slim-service-type)) %desktop-services)) <slim404>but I did not get xwindows either :/ <Apteryx>ah, there might have been a change in the guix service definitions that would cause the xorg-server to appear twice. <sadiq[m]>won't 'guix environment foo' set runtime environment for package foo? or just build environment? <Apteryx>sadiq[m]: build. runtime would be with --ad-hoc foo <Apteryx>slim404: I don't see anything very recent except one commit by Wingo which added modesetting driver to Xorg default configuration or something like this. <slim404>Apteryx: it's not recent, my original config.scm is from ~1 year ago <sadiq[m]>Is there any built-in environment for C programming? the one that provides, gdb, gcc, binutils, valgrind, GNU global, etc? <janneke>IpswichTriptych: no, but fwiw I haven't heard it boots yet <IpswichTriptych>after "ip link set ... up" i'm getting "RNETLINK answers: Operation not possible due to RF-Kill" <Apteryx>sadiq[m]: at least you should started off gcc-toolchain metapackage. <laertus>bavier` efraim and janneke: it turns out that the reason tcsh was failing that "nice" test was that i was running guix-daemon as "nice ionice -c3 guix-daemon" <laertus>when i ran guix-daemon not under nice, then it worked <laertus>seems running guix-daemon under nice prevents the tcsh it runs from nicing itself <ng0>shouldn't this give me mate-screensaver in my system-profile? I've read the service description and code.. I've seen mate-screensaver building, but it's not in the resulting system (or at least Mate itself is not aware of it). (screen-locker-service mate-screensaver "mate-screensaver") <bavier2>laertus: interesting! glad you figured it out. <ng0>Mate is aware of it when this is in the 'mate' meta-package, but due to a problem with screen locking ability of it I must avoid it <janneke>hmm, my xbacklight is broken after update to master (intel) <janneke>xrandr --output --brightness works but manual suggests that's software only and xbacklight is better? <rekado>expected: 1asvxkfh85842816wd3yjw7g1pyhjj69lh4ni4ijjpwlicrsws67 <rekado> actual: 1zvpfypd38v8m44lkr6dz4a53avwv4rii8200cs8m4kw7vkr4m03 <lfam>rekado: In general, the linux-libre tarballs are not deterministically created, and we can't expect a long-term archive <lfam>There is the linux-libre channel if you want to ask the linux-libre people about it <rekado>erm, wait… why am I getting 4.13.1? <lfam>4.13.4 is the latest upstream <lfam>rekado: What is `guix --version`? <rekado>I just ran a guile script and .config/guix/latest was not on the GUILE_LOAD_PATH <lfam>Aha. Too bad we already lost the upstream source for 4.13.1, thought :( <lfam>It's a major problem with long-term reproducibility of GuixSD, IMO <lfam>4.13.1 was released on September 10 <laertus>lfam: do you know if guix has any plans to address that issue by, say, archiving all the sources? <rekado>in the past we have copied some of the linux-libre tarballs <lfam>laertus: We keep a content-addressed mirror of the packages' source code, but we can't keep everything forever, at least with our current resources <laertus>rekado: could you elaborate on the reasons for the lack of sustainability of that approach? <rekado>laertus: that’s really an upstream problem <laertus>rekado: not every upstream provider is going to care or agree that archives should be kept <laertus>and they might not have resources either <rekado>it doesn’t make sense for GNU to copy around linux-libre sources <lfam>laertus: Also, linux-libre is not the only upstream team that doesn't aim to provide a long-term archive of their source code. And in the long run, it all disappears or changes URL. It's just that some packages, like linux-libre, cause more pain when they don't archive their source code <rekado>I’m speaking specifically of linux-libre. <lfam>Also, the linux-libre source code releases are kept upstream for an unusually short period <laertus>when you refer to resource issues, do you mean manpower or funding or disk space? <lfam>I would say all 3 are related <lfam>Storage costs money, must be hosted somewhere (more money), and requires people to maintain it <laertus>because if it's just disk space, you could store the original and then binary diffs (or just git for source code, so its own diffing algorithm could be used to store changes) <laertus>you don't have to store huge tarballs for every change <lfam>Yeah, but it adds up one way or the other :) <lfam>I recently learned that certain types of tarballs generated by GitHub are not intended to be bit-reproducible over time as they are garbage collected at GitHub and regenerated on request <lfam>That could affect a very large number of our packages. In the long run, we can't store everything forever. In my opinion, a long-term archive needs funding as a business or government entity <laertus>i wonder if some place like archive.org could help <laertus>or just dump the stuff on github itself :) <rekado>the MDC just received hardware to store a limited subset of packages and their sources <laertus>i think there are also some distributed long-term-storage projects <lfam>Perhaps, until they end up like SourceForge. About 1.5 years ago, SourceForge changed the URL of hundreds of our package sources, which took many hours of time to fix for us <lfam>That comment was referring to GitHub <laertus>yeah, generally it's probably a bad idea to rely on any one solution <lfam>It's a hard problem, ultimately. How do you preserve information in the long term? I think it's an information theory issue at its heart <rekado>I think software heritage is going to be very useful for Guix. <ng0>I know one or two hosters without diskspace limitation who I'll be using as intermediate solution to more long-term solutions… personally I keep copies of every tarball I package and use, so for a mismatch it could be placed anywhere safe. <lfam>If Software Heritage doesn't work out, I would be willing to donate time and money to a Guix source archive <lfam>Or a 3rd party project that is friendly to Guix <lfam>ACTION forever grateful for this channel's cordial and helpful tone <laertus>i also wonder if it's possible to solicit a donation of space from AWS <ng0>I have to get back to the email and support threads I had with 3 of my providers. I think 1984 was relatively okay, and iirc they also provide (one of) the download location(s) for torproject <laertus>some of this stuff could be stored in S3, and long-term archives in their long-term archive service the name of which i'm blanking on right now <lfam>The thing with Glacier is the super-slow and expensive retrieval <rekado>ng0: “unlimited” often turns out not to be unlimited <ng0>so 1984 to my question on diskspace and traffic consumption of one of their plans was like "unlimited? yes, really unlimited".. <laertus>lfam: yeah, but it'd only be for archives.. and, anyway, the idea is to solicit a donation, so price would not be an issue <lfam>Yeah, in order to get the data out of the glacier, you first have to have an industrial revolution and melt the glaciers over 150 years ;) <ng0>I know my current unlimited at IN-Berlin is "fair-use" unlimited <laertus>lfam: anyway, if Glacier isn't suitable, maybe AWS would just donate S3 <lfam>laertus: It could be a great boon if they went for it. But perhaps that donation would be more effectively utilized by archive.org, who have experience and expertise managing archives, and could then host the software <lfam>We use them as the source of a handful of packages, IIRC <lfam>I think we (Guix) are a bit wary of taking on this project ourselves. At least, I know I am. <laertus>yeah, archive.org would be one of the most logical places to ask first <laertus>btw, does anyone know what (if anything) Nix uses for this sort of thing? <ng0>I had previous contact with them.. I think all we do is to create an archive.org collection and that's it, curate it ourselves. like.. "github" collection etc <laertus>it also might be worth researching what the major linux/bsd distros use for their packages <lfam>laertus: They have their own content-addressed archive, and we actually use it as a fallback <lfam>I think it has a serious drawback, however. It's purely content addressed, unlike ours, which also includes package name and version in the URL. <lfam>You retrieve the data by its hash. Does that make sense? <laertus>well, could there be an index that maps content hashes to package names and versions in the URL? <lfam>That's what the Guix content addressed server does <laertus>then is the capability to do that at archive.org really necessary? <lfam>It's relatively difficult to be sure you are getting the right thing from the Nix archive <lfam>To do what at archive.org? <laertus>you said "I think it has a serious drawback, however. It's purely content addressed, unlike ours, which also includes package name and version in the URL" <laertus>i was referring to the need to do that <laertus>since Guix content addressed server already does it <laertus>i think i must be missing something... <lfam>The problem that I see only manifests when the tarball can't be found from the upstream site or the Guix mirror. <lfam>Imagine that there is a new version of package foo released. Typically, this is handled by updating the version and the hash in the Guix package definition <lfam>If the source can't be found upstream, or on the Guix mirror, the Nix mirror is the final fallback option. <lfam>If the hash provided is for something besides what we expect (the wrong version of foo, or even another package), the mirror will still serve it. <lfam>And Guix will try building it... <lfam>Hopefully the build would fail, but I bet that for "merely an old version of foo", it will usually succeed, and we may not notice that we've built the wrong thing <laertus>why would the wrong hash be provided? <lfam>It could be a mistake, or it could be malicious. Guix security ultimately rests of the honesty of the committers <laertus>so the commiters provide the hash for the new version, and guix tries to fetch the source matching that hash and build it <lfam>laertus: But, what if they provide the hash of the wrong version? This has happened before <lfam>If the packager uses `guix download` to check the hash of the file, they will not notice if they forget to update the hash in the package definition, because the source requirement will already be satisfied by the file that `guix download` put in /gnu/store <lfam>This is why you should never use `guix download` when packaging things :) <laertus>lfam: so you're saying if archive.org stored not just the content hash but also the package name and version corresponding to that hash, then guix could match those against the hash, package name, and version given by the commiters? <lfam>Exactly, and that's what the Guix mirror does. <lfam>The URLs include package name, version, and hash <lfam>But the Nix mirror only uses the hash <lfam>It enables mistakes, IMO <laertus>why can't guix mirror also store the hash, package name, and version of all the content in archive.org as well? <lfam>Can't it? I think somebody just needs to do the work :) <laertus>ok, so it sounds like it's solvable without needing to use features not available from archive.org <lfam>Sorry if I confused you. I wanted to talk about issues related to content addressing, but I don't see a reason that archive.org could not be used <laertus>i'm glad you did, because i learned a ton <laertus>btw, slight detour.. but speaking of content... why does /gnu/store contain something like 46 versions of bash when i still haven't finished my first "guix package -i glibc-locales" yet? <laertus>are all those different versions really necessary? <laertus>why couldn't guix just use one single version of bash for all its builds? <laertus>it seems like it must have recompiled bash 46 times, and that seems like a waste <lfam>That's too many times :) <lfam>They might be patch files for the Bash source code <lfam>If not, can you share one of the paths? <laertus>yeah, i just did a "du" on them, and almost all of them are only 4k in size <lfam>As far as I can tell, we are only applying 12 patches to Bash currently. So, I hope there are not actually 46 of them :) <lfam>See %patch-series-4.4 in 'gnu/packages/bash.scm' <lfam>Things like bash44-007 are patches <lfam>Things like bash44-007.drv are derivations (intermediate level build scripts) to create the patches <lfam>Bash does get built a few times in the bootstrapping process, but not 46, or even 12 ;) <laertus>just wanted to make sure nothing crazy was going on.. <lfam>Also, I recommend `echo /gnu/store/*-bash-*` as a faster alternative to `ls -l ...` <lfam>Unless you need the extra info from `ls -l` <lfam>Oh, ls -1. That's different <laertus>though the above command was "ls -1" (as in the number "one") <lfam>My IRC font doesn't show the difference clearly <laertus>i'm guessing the reason that /gnu/store is flat is so that files could be more easily looked up by their hashes <laertus>and i guess there's no reason to separate it in to "packages" and "patches" directories or something <laertus>or to stick all bash-related stuff under a "bash" subdirectory <lfam>I don't know the answer to that (probably it's covered in Eelco Dolstra's Nix PHD thesis) <laertus>wow, i didn't know nix was based on a phd thesis <lfam>But I do believe that is the reason the hash precedes the name and version (easy lookup) <lfam>It's published as 'The Purely Functional Software Deployment Model' <lfam>There is a much shorter publication, Nix: A Safe and Policy-Free System for Software Deployment <lfam>And then, the reasoning behind Guix, Functional Package Management with Guix by Ludovic Courtes <laertus>it's good to know that research in this area is still ongoing <laertus>and it makes me wonder what innovations the future will bring