<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 ~$(...)?)
<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.
<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.
<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.
<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) ?
<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)
<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
<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>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>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