<nckx>OTOH the €100 I spent on an SSD this year was a very, very good idea. <smithras>oriansj: Wow I had no idea that hex0 bootstrapping was progressing so quickly! <oriansj>nckx: one can get a good SSD for $19 (PNY) these days <oriansj>smithras: well if you join us on #bootstrappable you'll be able to keep up with the daily interactions of the developers <vagrantc>it all depends what you do and how often you 'guix gc' <oriansj>So, if one wants a larger drive (say 1TB at $93); I'd say cheap is readily available <u0_a85>Can I ignore the grub installation error by specifying the -k option in guix system init? <oriansj>u0_a85: well it is generally a bad idea to ignore a grub installation errors unless you have a recovery disk on hand and know the repair procedures <u0_a85>...my efi is bad,so I mus using grub --no-nvram to install grub. <u0_a85>Guix cannot specify this option。 <nckx>oriansj: I considered buying a ‘small’ (16/32 GiB is small now, right?) dirt-cheap SSD to put in my laptop's m.whatever slot as swap/tmp drive. <oriansj>nckx: never buy any SSD drive cheaper than PNY nor any more expansive than Intel <nckx>oriansj: So what's the catch with that model, or have prices simply halved this year, or did I just pay an idio^WSamsung tax? <nckx>My 500 GB drive cost as much as their terabyte one. <oriansj>nckx: the catch is you'll have to replace it in 2-3 years <nckx>Yesss. Quell my buyer's remorse with horror stories of 25-layer cells. <nckx>oriansj: Although that would work fine for said ‘crap drive’ use case anyway, guess I might do it after all. <oriansj>but then again Samsungs need to be replaced in 3-4 years anyway <nckx>u0_a85: You can use --no-bootloader and (must) then install grub manually. <nckx>Which is pretty trivial TBH. *smithras is glad he just replaced his over-5-year-old ssd <nckx>oriansj: Trust has nothing on hourly back-ups to the living room cloud. <oriansj>nckx: online storage is not a backup <nckx>Next you'll be telling me I'm supposed to be able to trust my computer. <oriansj>nckx: what do you think happens if cryptomalware hits your computer? <oriansj>backups need to be offline and offsite to count <ng0>i have a really good 1 TB SSD which last for 3 years now iirc <ng0>everything else is on larger disks <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. <oriansj>smithras: SUSE Enterprise Linux has considered Btrfs production ready since 2012. <oriansj>you just need to remember: In the event of drive failures you will need to rebalance the volume before you can remove the dead drive. *vagrantc writes all backups to gold etched plates <ng0>there are phones sold with btrfs out there. it's also the only case where i hit a problem with btrfs, ever. <nckx>smithras: My btrfs file system fails catastrophically about once a year. Sounds bad, but hey, backups 😛 <nckx>(Catastrophically as in no rescue tool will eat the carcass.) <smithras>okay, sounds like I should first improve my backup situation, *then* switch to btrfs :) <oriansj>nckx: I am only extreme with the backups of material that is irreplacable <oriansj>I will not allow a single bit of corruption or loss to occur on any of that material. <oriansj>For everything else, the 3-2-1 rule is good enough <nckx>In fact, the last time it happened ‘btrfs check’ very slowly and meticuously deleted every file. It was cute. <oriansj>nckx: you remember to have ECC on your machine right? <oriansj>if you start with the assumption that everything you depend upon can fail, the systems you design tend to survive much better in the long term <nckx>smithras: It may sound like I hate btrfs; I don't! I use it, and have for a decade. I've just lived next to the sausage factory long enough to notice the disappearing children, or something. <oriansj>ZFS also isn't without issue; for example ZFS does not apply new copies values to existing data in a pool NOR will it warn about a silently failing disk *ng0 can recommend Samsung SSD 850 PRO 1TB disks, among other brands. expensive but they last longer than any SSDs I had <nckx>ZFS trusts the hardware more than is generally promoted. <smithras>nckx: ok I think I understand :) the metaphors are becoming increasingly alarming though! <ng0>which is also nonsense, it works just fine without ECC, but you want it. <nckx>😃 That's just me! btrfs is fine as far as file systems go. They all suck. btrfs gets mocked too much, ZFS too little, so it goes. Don't put all your eggs in one basket, that goes for everything. <oriansj>ng0: no ECC+ZFS+200TB pool => goodbye everything <ng0>i had smaller sizes and desktop computers with ZFS from freebsd base <ng0>a server with ECC ram, and desktops without <ng0>all were fine. it just depends on what your requirements are <ng0>obviously desktop didn't have 200TB <nckx>ng0: It's not nonsense. It's paranoid (welcome to the thread), but implies that it works without or the warning wouldn't be necessary. <ng0>nckx: yeah okay, it depends on the setup <ng0>at first i didn't believe it would work out the way it did, but it did <oriansj>ng0: ECC is just to prevent one of ZFS's worst behaviors from being triggered (total data corruption cascade) <nckx>oriansj: Not a hoarder of data by their standards — my life fits in a few terabyte (actual curation would reduce it to 1) — but a hoarder of copies/reliability, sure. <nckx>Hoarder of time, mainly. I hate ‘welp there goes Saturday’ restoration scenarios. <oriansj>nckx: I store much more than my life (that is only a few GB); I also store source code, hardware designs, Scientific papers, etc <oriansj>I also use ffmpeg on my DVD collection <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 🙂 <nckx>Cool I have 203 GiB of books. <nckx>oriansj: How do you store your most precious bits? <nckx>I've a hunch that multiple copies + error correction data on HDDs (still the medium I trust most) in a warehouse is not up to best standards. <vagrantc>nckx: for some reason your 203GiB of books reminds me of a talk about printing debian: Lightning_talks_2.webm starting at 32:20 :) <oriansj>nckx: I follow the rule of 5-4-3-2-1; along with all of it in version control <oriansj>A big part of the data stash is climate data that the current administration attempted to delete ***daviid is now known as Guest29292
***daviid` is now known as daviid
<nckx>vagrantc: Saved for tomorrow. <nckx>vagrantc: It was easy to find. <oriansj>Getting a file backup in the antarctic took some doing <nckx>Yup. Maybe I just got lucky. <smithras>oriansj: I tried searching for the rule but all the results were for the 3-2-1 rule. What do the 5 and 4 mean? <nckx>5 is apparently the south pole. <oriansj>smithras: Copies on 5 different continents <oriansj>2 different ways of validating the data <smithras>oriansj: for validation, I assume hashing is one method? What would the second method be? A second hashing system or something different? <oriansj>now if there was an option to spend say $5K to get 10GB to Mars, I'd go for that too <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? <mbakke>ScaredySquirrel: for system wide packages you need to use the 'packages' field of your operating system configuration. <mbakke>Assuming you're on a Guix System. <ScaredySquirrel>what? I really don't see why it couldn't just be more automated in that case <mbakke>you could 'sudo guix install -p /run/current-system/profile cheese', but it would go away the next time you reconfigure <ScaredySquirrel>and I want (packages (append (map specification->package+output "openbox" "irssi"))) <mbakke>ScaredySquirrel: map takes a list as the last argument: (map specification->package+output '("openbox" "irssi")) <vagrantc>if guix maintained the config.scm used to build a particular system ... in simple cases it could probably output a new config.scm that would add a package... <lispmacs>to have the manual locally do I need to install a package? <mbakke>lispmacs: if you have `~/.config/guix/current/share/info` in $INFOPATH, you can use your favourite info viewer to read the Guix manual <mbakke>ScaredySquirrel: (append list1 list2) <mbakke>(append '("openbox") '("irssi")) <mbakke>you'll get used to it eventually ;) <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. ***catonano_ is now known as catonano
<ScaredySquirrel>I don't know how to like parse a file that has a list of packages and make that into a list variable ***jonsger1 is now known as jonsger
<ScaredySquirrel>ok so a guixsd question; when I have coded a new config.scm and have reconfigured it, how do I tell my shell how to find any new binaries? <vagrantc>they should most likely already be in PATH <vagrantc>e.g. /run/setuid-programs:...your user's profile dirs...:/run/current-system/profile/bin:/run/current-system/profile/sbin <vagrantc>or guix environment --ad-hoc gcc-toolchain <vagrantc>if you want it to go away when you're done with it <vagrantc>and if the packages are already there, the install process should go quite fast <vagrantc>different users can have different versions of software installed <vagrantc>essentially, each user chooses what's installed, and maintains their own profile, which is essentially mostly symlinks to files in /gnu/store/ <vagrantc>my most recent update to emacs-no-x fails to open files <vagrantc>reverting to the previous generation works fine <vagrantc>just drops me in the scratch buffer with ... Wrong type argument: stringp, nil <vagrantc>and moving aside .emacs and .emacs.d doesn't fix anything (didn't really have anything in there anyways) <apteryx>is it normal that I can't 'guix install' in a Guix VM? <apteryx>error opening lock file ...kwx-mirrors.lock: Read-only file system <lispmacs>hi, is anybody working on a xiphos package or other sword based Bible application? <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? <alextee[m]>guix pull: error: Git error: unexpected HTTP status code: 502 <efraim>I got that a few times and then 'guix pull' started working again <safinaskar>it seems there is some problem with savannah servers <alextee[m]>safinaskar: the repo seems to be having problems atm <alextee[m]>can guix handle maven packages? i'm looking for an example <zig>alextee[m]: When you search using for instance grep in guix git repository the term 'maven' there is several hit. <alextee[m]>zig: yeah i did that, but i only seem to get maven and java tools only <zig>alextee[m]: IIRC maven is not suitable for in-tree packages. <zig>because (most?) softwares using maven are not reproducible <smithras>that would explain why my 'guix pull' is hanging <zig>alextee[m]: I think you can still use maven since it is packaged, you just can not track dependencies using guix. <alextee[m]>zig: i will try, thanks. would be nice if there was an example though, would save me a lot of trouble <alextee[m]>or could be just a matter of adding maven as an input. time to experiment <nixo_>nckx: thanks, sent an email to bug-guix@gnu.org <ScaredySquirrel>lol the git.savannah.gnu.org dimain is just unreachable and it says my network is down <janneke>ScaredySquirrel: yes, the server is not responding <oriansj>ScaredySquirrel: ping works better for network checks <ScaredySquirrel>it is their end; the git server is not responding and it seems its totally offline <rekado>got a bunch of updates to R packages <bandali>yup. i know at least one of the fsf sysadmins is aware <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/'
***ChanServ sets mode: -o nckx
<cehteh>maybe the note in the topic has something to do with that <ScaredySquirrel>ok how do I extend the bootloader config with (linux-arguments "list of linux arguments")? <alloy>Hey! How could I modify a user added by a service to be in a specific group on guixsd (there is no configuration option for it in the normal service config)? <Dabian>Hi, I did a "ping git.savannah.gnu.org" .. is it down and why? Here is the response I got: PING git.savannah.gnu.org(2001:470:142:5::201 (2001:470:142:5::201)) 56 data bytes <Dabian>From 2001:504:47::59cd:0:1 icmp_seq=1 Destination unreachable: Address unreachable <Dabian>Franciman: Oh ok.. Do you know why, or are you just unable to reach it? <Dabian>Well, seems to be a known problem then. Thank you Franciman. <finfin>does anyone knows why the Guix git server is down? <bandali>to my knowledge, guix uses the savannah git server <bandali>which is currently down due to disk failure <finfin>oh i see, so it'll take a while to get back up <bandali>yeah. the fsf sysadmins are on it though <Guest392847>hello #guix! I'm looking for docs on installing packages/running services as an unprivileged user. Is this possible? Is it possible in a declaritive way? Links appreciated! <bandali>hey Guest392847, installing packages as an unprivileged user certainly is possible <Guest392847>cool! can I do it in a declaritive (i.e. my-stuff.scm) way? <bandali>as for a declarative way, it's possible too; look into manifests <bandali>am not sure about services; you'll have to wait for an answer from one of the more experienced guixers :) <Guest392847>ok thanks! I'm new so I'm not sure what to search for. I have to leave now... but I'll leave this up and look up manifests. appreciate the help :) <g_bor[m]>for services there is no framework per se. <Guest392847>ahh, good to know g_bor[m]. will play w/manifests for now :) <g_bor[m]>There are a few ways, some shared on the devel mailing list, and a channel guix-home-manager, but that is very young, and tkes things to the extreme ***ChanServ sets mode: +o nckx
***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'
***ChanServ sets mode: -o nckx
<nckx>Gah, topic's so long it got truncated… ***ChanServ sets mode: +o nckx
***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... <anadon>What tooling is there about packaging? I'm looking to package a few C++ header only libraries and my C++ application. <anadon>Also, how can I go about setting upstream to be a mirror of savannah? <anadon>nckx That is still resolving as dead for me. <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. <g_bor[m]>Is it possible that a not available id is passed, and sopa-invoke* is called on that erroring out instead of returning the cached entries at least? <anadon>g_bor[m]Right now, just pull to make sure I have everything working. After that, I want to package a few things. <rekado>mumi already collects all of the messages that it has to fetch from debbugs, so we *do* already have a local cache — we just aren’t using it yet. <rekado>ideally, soap-invoke would only be used on messages that don’t exist in mumi’s maildir yet. <rekado>this way it would fail gracefully <rekado>but that’s in the 2% that someone has yet to implement. <rekado>we aren’t actually using the forked mu at all. <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. <anadon>Huh, no certs are working. This is something I have run into before. Let me go back to the docs here... <nckx>‘no route to that server’ — I didn't give you a server. That part is up to you, or someone else here who can recommend a trustworthy one. I'm explicitly not doing that. <g_bor[m]>I think you need nss-certs installed for the certs. <g_bor[m]>It should contain nss-certs in the packages field <anadon>g_bor[m] `guix describe` does not work yet. <anadon>What is the URI of a good mirror? <nckx>Huh. My bambam commit did make it upstream. <nckx>alextee[m], anadon: Since the last commit in that GitHub repository is signed by yours truly, I can in fact recommend it 😛 <bandali>what are the commands it supports anyway? <nckx>bandali: /msg sneek help <nckx>bandali: /query sneek help ? <alextee[m]>i think this is a good time to set up a mirror of guix on my server <vagrantc>sneek just knows not to get in over it's payscale <sneek>Welcome back vagrantc, you have 1 message. <bandali>vagrantc, known is due to disk failures <nckx>(I know, it affects more than just ‘guix pull’, I was trying to be newbie-friendly.) *nckx adds ‘See topic’ to the topic again. <nckx>(Not a dig at you, raghavgururajan, sometimes I just wish there was a way to put big arrows in folks' IRC window.) <vagrantc>nckx: what was the bug you wanted to point me to? <raghavgururajan>nckx I understand. I cannot see topic on my end as I am connecting via XMPP-IRC bridge. <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 <vagrantc>nckx: maybe i can dig the bug out of the list archives, those seem to be up :) <anadon>If I ever really get the money, I'd be happy to pour it into Gnu. It sucks that a simple disk failure is able to take so much offline. <nckx>raghavgururajan: Oh, that's very unfortunate. Topics often contain important information. Is that normal in XMPP land? Is there no ‘topic’ concept at all? <raghavgururajan>Folks! I was reading gnu maintainers guidelines. I was wondering if gnu maintainers get any income through the project's fund? ***ChanServ sets mode: +o nckx
***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. <Mrtn[m]1><raghavgururajan "Folks! I was reading gnu maintai"> Nah, don't worry about that. <nckx>Yes, our topic is horribly long. Right near the limit, in fact. <raghavgururajan>Ideally, I would see "Away" under a contact. For IRC channels, I got lot of lines that fills up the space for at least ten contacts. <Mrtn[m]1><raghavgururajan "Ideally, I would see "Away" unde"> Sounds like a problem with your client? <nckx>raghavgururajan: I think they mean ‘don't worry, no payment’. <Mrtn[m]1><raghavgururajan "Mrtn Why not to worry? Those gui"> I meant, don't worry about income. Of course we worry about the guide lines. <nckx>raghavgururajan: Ideally, the bridge would export the IRC topic as something else because long topics on IRC are commonplace, but I don't know that much about XMPP anymore. <raghavgururajan>I meant ideally xmpp status messages are short when compared to topics in irc. <vagrantc>Mrtn[m]1: your client does a bit too much quoting <Mrtn[m]1>vagrantc: Thank you for the heads up. I guess it is common in Riot, because it does expandable quotes or something? <vagrantc>Mrtn[m]1: yeah, i often see it on folks with [m] in their nick. :) <Mrtn[m]1><vagrantc "Mrtn: yeah, i often see it on fo"> Is that my IRC nick? <nckx>Mrtn[m]1: In case you don't see it yourself, we see: <Mrtn[m]1> <quotee "Ideally, I would see "Away" unde"> Sounds like a problem with your client? <nckx>That's not very IRC-friendly. <vagrantc>it's pretty cool that various protocols can interact, but sometimes there are rough edges <Mrtn[m]1>nckx: Right ... I guess that is an issue with the bridge/interface. <vagrantc>raghavgururajan: you're using an xmpp to irc gateway? <nckx>Oh, I'm not complaining, I'm very glad we can all talk in one room, just wonder if there's a setting that can be tweaked to make it even smoother. I've not seen other [m] users quote like that. <Mrtn[m]1>vagrantc: Yeah, I am kinda new to the bridging ... but it works remarkably well, despite the edges, I guess. *kmicu could check how #guix looks like in xmpp but xmpp here looks like IRC… <Mrtn[m]1>nckx: I will try not to in the future ... I didn't know what it looked like on IRC. <nckx>Mrtn[m]1: If there's an option to not quote at all that's fine, that is the IRC way. Blast text into the void and let others sort the pieces. <raghavgururajan>vagrantc XMPP is pretty much my home place. I use biboumi for xmpp<-->irc and cheogram for xmpp<-->sms. <nckx>raghavgururajan: Do you see the ‘Welcome to #guix’ message when you connect? <bandali>raghavgururajan, so do you use an xmpp client on your computer? <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, aha, i see thanks :) i wish there was a decent one in emacs <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 <bandali>does it now? (with the savannah outages) <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. <rekado>in case of outages we could simply switch to some mirror on our servers. <safinaskar>nckx: is there a way to rebuild all installed packages such, that all generated files (such as configure scripts) are regenerated? <dddddd>Is downloading always from a mirror (instead of upstream, let's say one doesn't want to hit random servers all around) easily configurable/supported? <nckx>rekado: That will break https:// though, if it's properly done. <rekado>wouldn’t help if gnu.org infra is completely down of course <raghavgururajan>rekado Question. Maintaining whole repo as a mirror on guix servers. Wouldn't that cost money and resources? *rekado wonders about how to do it improperly <rekado>raghavgururajan: not any more money and resources as it already takes to run ci.guix.gnu.org and all that jazz <nckx>safinaskar: Not automatically, but you could probably write a transformation procedure that works for 95% of packages. (add-before 'bootstrap 'delete-configure …) 😛 <rekado>also: money isn’t actually a problem, weird as it may seem <rekado>we have quite a lot of money from donations that we can’t really spend well. <rekado>it’s not enough to hire people to do work, it’s also not enough to spend on service fees without feeling guilty <kmicu>Buy ARM build farm. DONE. I spent those money well. ;) <safinaskar>nckx: okey, so it seems nobody attempted to do this (such complete bootstrap) before, right? well, this is sad <rekado>the problem with ARM is: who is going to a) install the machines and b) host them? <safinaskar>nckx: i thought that guix guys are fans of everything related to various kinds of bootstrapping <rekado>I already bought three ARM machines some years back from Guix funds and these two problems are the worst. <nckx>safinaskar: Yes, the cool kind, not the pointless kind. <rekado>if we had volunteers to take care of these machines reliably then I’d be happy to just buy 20 more. <kmicu>If that’s the issue then Guix could buy remote computing power from ARM servers providers (like Nix). <rekado>I prefer to have servers that *we* control <nckx>I do not consider mindlessly running autoreconf a productive use of computing resources, but it's certainly easier on Guix than on other distros if you want to implement it. *rekado has to leave again <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. <kmicu>Hashes will change if inputs change. <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 <nckx>janneke: I don't know who dddd… is *janneke might be confusing things <dddddd>Sources or binary are fine, I was just wondering is one can use guix without ever downloading a thing from random (non-guix) servers. <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. <dddddd>Offline is nice, not exactly the point but let's explore that route. For populating the cache, is it possible to do it from guix-only servers? <nckx>Or (less likely) the package itself has received a bug fix that doesn't bump the version. <nckx>More likely a dependency has either. <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 🙂 <nckx>Both in response to safinaskar. <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 :) *vagrantc swaps debian and guix hats in real-time <nckx>smithras: Oh, so do I! They are an *awesome* link in a chain that needs to be tethered to ‘a human read this’ at some point, though, or they're just there to look cool. <nckx>* A very clever human, preferably many of them. *kmicu points out that any talk about security w/o threat modeling and risk assesment is just fashion ;) <nckx>This is why Mes + Guix genuinely excite me: I have a sha256-blockchain that tells me my (future) system was bootstrapped by janneke + oriansj's eyeballs at some point. <nckx>How buzzword-compliant is that. <nckx>kmicu: All the threats of course jeez.