<nckx>oriansj: I roll back to the previous hourly btrfs snapshot on the backup host, or plug in a detached drive from the week before.
<nckx>I'd be very surprised if crypto malware hit my passive (sshd excepted) back-up box but it would be annoying, nothing more.
<oriansj>ng0: make sure you backup and plan for its death (never trust an SSD past 5 years)
<smithras>nckx: Have you ever had btrfs problems? I want to use it but random internet strangers told me it wasn't stable enough and I trusted them blindly :(
<ng0>oriansj: it's not one of those cheap ones.. but yeah
<oriansj>smithras: btrfs generally is great; it however has some rough corners where it doesn't behave correctly and can lose data
<smithras>oriansj: but for normal, everyday use cases you would say that it's fine?
<nckx>Backup extremism annoys me. Layers of recent-vs-ironclad storage are fine. Hourly backups to a on-line host are not inferior to some greybeard's weekly tape unless you rig the game by ignoring all parameters but one.
<nckx>oriansj: The terabyte comes from films and games and historical software that could in theory be replaced by a bunch of magnet links & be re-downloaded some day, but who actually wants that (again: time is what I'm storing along with data), and I'm a snob who never re-encodes. I guess I am a hoarder 🙂
<ScaredySquirrel>ok guys, why when I run "sudo -i" then "guix install cheese" it installs the cheese program and says that grafts and profile hooks under /gnu/store/ will be used and made but it installs to /root/.guix-profile?
<nckx>ScaredySquirrel: % in Scheme is just a ‘regular’ character, it doesn't do anything. You can call a variable ‘(define hundred 100)’ or ‘(define hundred% 100)’, it's exactly the same. In Guix, it's a naming convention used to signal ‘this is a global systemy thing’. Most of the time.
<nckx>If list1 and list2 are in fact lists, (append list1 list2) will return what you want.
<nixo_>Hello Guix! We might have a problem on how retroarch is packaged. I've never used it, tried just now. There's the "core download" section where it downloads "$core.so.zip". Those are .so files: .config/retroarch/cores/atari800_libretro.so: file format elf64-x86-64
<nixo_>I think we should either compile them and ship them or remove the download section or something
<nixo_>Also, when downloading cores there are no license info
<nckx>I didn't verify that, though, but that it's not trivially verifiable is the bug 😛
<nckx>…the comments devolve into ‘you misread the licences/they can't impose extra restrictions on GPL [true]’ so maybe that page is bogus.
<smithras>nckx: It's weird that the module providers use non-free licenses but provide a Makefile specifically for linking their project to the GPL'd libretro
<nckx>smithras: That would be weird (but alas, not uncommon). Misunderstanding the GPL3 as some kind of ‘non-commercial’ licence is also not uncommon, so I can't vouch for the libretro blog post either. It just proves that we have to do our own research. Sigh.
<bluekeys>Hi guix, I just ran a guix pull --verbose and got a Git error: SSL error: syscall failure: Connection reset by peer. Anyone know why?
<paprika>when I try to start tor browser I get the error that it can't find firefox.real
<paprika>does this have to do with Guix not having firefox?
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ servers are currently down | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs and patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org/'
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ (Savannah) servers are currently down | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs and patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org/'
***ChanServ sets mode: -o nckx
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ servers are currently down: https://hostux.social/@fsfstatus/103193147618584644 | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs and patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.g'
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ servers are down: https://hostux.social/@fsfstatus/103193147618584644 | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<g_bor[m]>nckx: I just noticed that the issue tracker is also donw.
<g_bor[m]>It seems it feeds itself directly from the debbugs instance..
<nckx>g_bor[m]: Yep, it's just a very fancy (caching & all) front-end to debbugs.
<g_bor[m]>:) I hoped that it is a bit more caching
<nckx>g_bor[m]: Oh, you're right, I'd expected stale data, not no data.
<nckx>It's basically a fork of mu with its own database so it could probably be done.
<g_bor[m]>It's on my TODO list for a while to have a look at that codebase, bu I could not yet find the time...
<nckx>It will try d.s.g.o first but should fall back to a working mirror. All mirrors are listed in guix/download.scm.
<anadon>nckx Not working for me and I don't have the skill to fill in gaps yet. I had to do the manual install since the installer script isn't available and I'm sure something isn't as complete as it should be.
<g_bor[m]>anadon: what are you exatly tring to do?
<g_bor[m]>Is it possible that the fsf downtime affects your attempts?
<g_bor[m]>nckx: I jsut had a look at the mumi code...
<g_bor[m]>not very familiar with it yet, but status-with-cache function seems to be the place to look for.
<nckx>anadon: OK, now I understand what you mean by ‘setting upstream to be a mirror of savannah’. You can set a custom URI for the Guix channel by putting (list (channel (name 'guix) (url "https://…") (branch "master"))) in .config/guix/channels.scm .
<nckx>It should be the URI of an up-to-date Guix mirror you trust.
<anadon>A number of commands are failing due to being unable to verify X.509 certs.
<nckx>Then ‘guix pull’ will use this instead of the default Savannah one.
<nckx>vagrantc: ‘my most recent update to emacs-no-x fails to open files | reverting to the previous generation works fine | fails to edit files sometimes | just drops me in the scratch buffer with ... Wrong type argument: stringp, nil’
<bandali>raghavgururajan, yes, most savannah services are down due to a disk failure
***nckx changes topic to 'GNU Guix | ⚠️ ‘guix pull’ and more is down: https://hostux.social/@fsfstatus/103193147618584644 | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<raghavgururajan>nckx Topics are called status messages in xmpp. They appear right below the contact/group. I had to disable status messages because, the irc uses long lines in topics. It messes with the contact list view.
<raghavgururajan>nckx Oh yes I do. I can actually notice topic there. But the thing is, the bridge also acts as bouncer. So that message will be followed by recorded history. So I will be taken to bottom of window very fast.
<bandali>raghavgururajan, right, but afair, it doesn't support OMEMO and such
<safinaskar>let's say i type "guix build bash". or some other package, developed *externally*, i. e. not originating from guix devs, instead of "bash". where guix downloads its source? from upstream site or from guix servers?
<nckx>safinaskar: All sources (even for ‘official’ packages) are normally downloaded from their upstream, not Guix. However, if that fails, guix will try downloading them from a Guix mirror as last resort. If that fails, the build fails.
<safinaskar>nckx: then guix applies guix-specific patches, right?
<nckx>safinaskar: This Guix mirror is content-addressed, so the custom bash package will get it source from Guix mirrors if and only if 1) it's not in your store already 2) the URI in the source field returns an error 3) the sha256 matches that of an official bash source field.
<nckx>safinaskar: Only if your custom bash package has a (source (patches …)) field, or inherits from a package that does.
<safinaskar>nckx: where usually package is downloaded? from some .tar.gz or from git trunk?
<nckx>safinaskar: What is the scenario here? Do you want to *avoid* Guix servers, or…?
<safinaskar>nckx: i trying to understand how different guix is compared to my distro (debian)
<nckx>safinaskar: It's downloaded from wherever the package author decided, but official tarballs is recommended and most common in Guix. ‘Git trunk’ (well, master) isn't a thing in Guix — a package always points to a specific commit. Guix contains many packages that download from a git repository because there is no reliable release tarball.
*kmicu have Debian boxes, the diffrence is that Guix works xD
<anadon>So long as I can convince my company to move away from CentOS7...thing wastes more time making old things work than the time lost on fixing bug in upstream.
<kmicu>safinaskar: the most important difference is somewhere else. Grabbing sources is mostly the same process in both.
<anadon>How to I specify a dependency on a C++ version, or failing that a group of or'd compilers?
<safinaskar>okey, so build process usually downloads tarballs. but tarballs often contain generated files (configure scripts, etc). how build process usually deals with them? regenerates them or keeps as-is?
<nckx>safinaskar: If ./configure exists, it's used as-is. We don't re-bootstrap the whole thing. Autotools are meant to be used that way.
<rekado>I would like to suggest to provide git.guix.gnu.org and point it to savannah by default; let “guix pull” pull from there.
<safinaskar>nckx: ???????? such bootstrap is very cool and very useful. let's assume we want to audit whole system and then build this audited sources. But generated sources are unreadable, so the very first thing we need to do is to remove all sources except for human-written, audit *them* and build from *them*
<kmicu>safinaskar: could you link to an example where config scripts in a libre software are not readable?
<nckx>safinaskar: Agreed that it could be useful assuming the existence of such an audit. Until then, it sounds a bit like security theatre with a non-zero maintenance cost.
<nckx>As one who reads autogenned code regularly: it's certainly not pleasant, but it's not that bad. But if the ‘sources’ had in fact been audited I would support bootstrapping from them and not using ./configure.
<nckx>By autogenned I mean autotools specifically.
<vagrantc>big thing gained from updated autotools stuff is often portability to new architectures and occasional bug fixes
<vagrantc>but that can also be done on a package-by-package basis when it comes up
<safinaskar>kmicu: i mean generated files in general. say, bison-generated files are, of course, less readable than grammar files they are generated from
<nckx>safinaskar: You're right if you think that the GNU auto-and-other-build-tools get something of a free pass that other tools don't. I do think that's true.
<kmicu>safinaskar: What is the threat model here? Guix can use source repo directly but if someone has acces to config scripts then source code is doomed too.
<nckx>safinaskar: I shouldn't have said ‘pointless’; what I really meant is ‘pointless at this time and place’. There's a world in which this makes sense and is worth the significant increase in maintenance and dependency graph but I don't think we're there yet.
<vagrantc>embedding autotools generated scripts seems to be borderline on the GPL "preferred form of modification" angle
<vagrantc>if someone starts to work on riscv64 in earnest, autoreconf by default might save a lot of rounds of whack-a-mole fixing outdated autofoo
<safinaskar>kmicu: i don't think sources are actually have some backdoors. i just think about usual scientific notion of verifiability. to audit particular package, we should remove generated files and audit everything else
<nckx>If there was in fact a serious public effort to audit the ‘source’ and someone reliable were to actually volunteer to do the work of converting individual Guix packages to bootstrap (and eventually even make it the default), I don't think it would be rejected out of hand.
<kmicu>Some files are data, not code. In the same way we don’t generate Guix artworks from source.
<safinaskar>kmicu: i scientific world we usually trust researchers, we don't think they will fool us. But still we want them to public verifiable result, because this is how science works. similar principles applies to software
<nckx>safinaskar: Packages don't have to be bootstrapped from source to be verifiable.
<janneke>dddddd: hmm, guix/download.scm defines %mirrors it downloads from, as well as content-addressed fallbacks. i am not sure how easy it is to override it with your own mirror; is that what you intend to do? guix does not have its own source mirrors, afaik
*nckx uses ‘source’ here to mean ‘the very root of all sources’, not ‘what's in your average sourceball’.
<safinaskar>nckx: "and dependency graph" - i completely agree that my idea will make dependency graph bigger. for this reason we should have two modes of bootstrapping: at one mode we will use pregenerated files as much as possible (and thus we will have small dependency graph), in another mode we will have opposite
<janneke>nckx: i think dddddd was asking for source tarball downloads
<safinaskar>nckx: i think guix should implement this idea at least to all transitive dependencies of gcc. so that we can bootstrap from https://www.gnu.org/software/mes/ to full build of gcc using human-written sources only. i thought this is goal of mes project in the first place, isn't it?!
<anadon>How to I specify a dependency on a C++ version, or failing that a group of or'd compilers in a package?
<nckx>safinaskar: Hm, I'd personally rather see your ‘radical bootstrap’ than two different but supported modes. A single supported way is better.
<kmicu>safinaskar: mes doesn't help here. We still have ~30k packages to check manually.
<nckx>safinaskar: I think that's out of scope for Mes, but it's certainly its philosophical continuation.
<janneke>dddddd: there has been talk about an offline install, you could populate the store beforehand...
<nckx>safinaskar: It's also *really a lot* of work, and I feel like it's putting the cart before the horse, but maybe my feeling's wrong.
<janneke>safinaskar: the mes project works to remove all binary seeds from the bootstrap; if you do not use a substitute server, everything should be built from source, eventually. we haven't reached that point yet, though.
<nckx>Having this cool bootstrapped-from-artisanal-electrons distro gives a false sense of security if no one actually audits the whole damn thing. Supporting Autoreconf Everywhere is the *trivial* part and it's already a pain.
<alextee[m]>why does `guix upgrade` try to upgrade packages to the same versions?
<nckx>alextee[m]: Because their inputs have somehow changed.
<safinaskar>nckx: "Packages don't have to be bootstrapped from source to be verifiable" - i don't think so. i think there is non-zero probability that someone did successful trusting trust ( https://wiki.c2.com/?TheKenThompsonHack ) attack to us. and the only way to eliminate it is to rebuild absolutely everything. moreover such attack can be even on cpu
<safinaskar>level. so we should rebuild absolutely everything. create computer without help of computers. then load some software into it not using existing computers, etc
<kmicu>Thompson Hack is possible but it’s much easier and probable to push evil code to source code directly.
<kmicu>So we end up with a safe compilator which compiles evil code correctly.
<kmicu>(And we had already many examples in npm ecosystem.)
<nckx>safinaskar: I don't see how shipping pregenerated files (say, ./configure) and its source (stuff.ac &c) and saying ‘hey, just use ./configure, it's easier and needs less extra software’ is unverifiable (I can still regenerate my own ./configure, diff it against yours, and make it to the front page of the news cycle if they differ) or more vulnerable to the Thompson attack than a ‘radical’ bootstrap from the same starting point.
<nckx>Sure, an upstream might ship a pristine configure.ac and a backdoored configure, but it's ‘verifiable’ that I won't be able to reproduce that. Any competent audit will reveal that. Doesn't mean all the users of the software have to do it. And if there's no audit, they might as well have put their back door in the actual source and bootstrapping won't help.
<nckx>People with more bootstrapping-fu than me (janneke? 🙂): is that reasoning sound?
<safinaskar>nckx: "personally rather see your ‘radical bootstrap" - radical bootstrap cannot be the only supported way. current way should be supported, too. because graph for radical way will be *very* big. here is transitive build-dependencies for base packages in debian: https://bootstrap.debian.net/essential.html . so, we see there are 1000+ packages
<safinaskar>here. so, closure for gcc in radical mode will have 1000+ packages. this is a lot. so, well, radical mode should not be the only way. it will also complicate bootstrapping to a new arch
<janneke>safinaskar: debian is a really bad example to look at, bootstrapping-wise
<nckx>I disagree. Guix's strength is that we don't say ‘you could bootstrap this separate version of Guix with Mes as an academic exercise’, it's exactly that the Guix *you're* running on *your* machine was exactly so bootstrapped. Maybe not by you, but it's an exact continuation of the bootstrap process someone else did do. ‘Optional autoreconf’ is a completely different beast, it splits the road so to speak.
<nckx>No scare quotes or mocking intended, just trying to label concepts 🙂
<vagrantc>the stuff from bootstrap.debian.net i *think* is just cross-building one architecture from another for the initial bootstrap, which is considerably different than bootstrapping from mes & company
<vagrantc>so it starts with assuming you have a working compiler and so on
<vagrantc>they don't track what the bootstrap seed is
<nckx>Regardless, whatever approach is chosen at any time should be the 1 supported way, not an optional side route. That's a core strength of Guix.
<smithras>nckx: speak for yourself, I quite enjoy my artisanal electrons :)